[PATCH] cx88-dvb.c: DVB net latency using Hauppauge HVR4000

[Ang Way Chuang]

Hi linux-media developers,
We are from School On Internet Asia (SOI Asia) project that uses satellite 
communication to deliver educational content.
We used Hauppauge HVR 4000 to carry IP traffic over ULE. However, there is an 
issue with high latency jitter. My boss, Husni,
identified the problem and provided a patch for this problem. We have tested 
this patch since kernel 2.6.30 on our partner
sites and it hasn't cause any issue. The default buffer size of 32 TS frames on 
cx88 causes the high latency, so our deployment
changes that to 6 TS frames. This patch made the buffer size tunable, while 
keeping the default buffer size of 32 TS frames
unchanged. Sorry, I have to use attachment for the patch. I couldn't figure out 
how to copy and paste the patch without
converting the tab to spaces in thunderbird.

Signed-off-by: Achmad Husni Thamrin 

diff --git a/drivers/media/video/cx88/cx88-dvb.c b/drivers/media/video/cx88/cx88-dvb.c
index 367a653..90717ee 100644
--- a/drivers/media/video/cx88/cx88-dvb.c
+++ b/drivers/media/video/cx88/cx88-dvb.c
@@ -67,6 +67,10 @@ static unsigned int debug;
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug,"enable debug messages [dvb]");
 
+static unsigned int dvb_buf_tscnt = 32;
+module_param(dvb_buf_tscnt, int, 0644);
+MODULE_PARM_DESC(dvb_buf_tscnt, "DVB Buffer TS count [dvb]");
+
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
 #define dprintk(level,fmt, arg...)	if (debug >= level) \
@@ -80,10 +84,10 @@ static int dvb_buf_setup(struct videobuf_queue *q,
 	struct cx8802_dev *dev = q->priv_data;
 
 	dev->ts_packet_size  = 188 * 4;
-	dev->ts_packet_count = 32;
+	dev->ts_packet_count = dvb_buf_tscnt;
 
 	*size  = dev->ts_packet_size * dev->ts_packet_count;
-	*count = 32;
+	*count = dvb_buf_tscnt;
 	return 0;
 }
 

Re: [PATCH] dma_declare_coherent_memory: push ioremap() up to caller

[Paul Mundt]

On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote:
> Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, 
> patterned upon two mach-mx3 machine types which already try to use the 
> dma_declare_coherent_memory() method for reserving a region of system 
> RAM preallocated with another dma_alloc_coherent(). Compile tested for 
> all modified files except arch/sh/drivers/pci/fixups-dreamcast.c.
> 
> Signed-off-by: Janusz Krzysztofik 

The arch/sh/drivers/pci/fixups-dreamcast.c build fine.

Acked-by: Paul Mundt 
--
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/PATCH] v4l2-ctrls: eliminate lockdep false alarms for struct v4l2_ctrl_handler.lock

[Andy Walls]

When calling v4l2_ctrl_add_handler(), lockdep would detect a potential
recursive locking problem on a situation that is by design intended and
not a recursive lock.  This happened because all struct
v4l2_ctrl_handler.lock mutexes were created as members of the same lock
class in v4l2_ctrl_handler_init(), and v4l2_ctrl_add_handler() takes the
hdl->lock on two different v4l2_ctrl_handler instances.

This change breaks the large lockdep lock class for struct
v4l2_ctrl_handler.lock and breaks it into v4l2_ctrl_handler
instantiation specific lock classes with meaningful class names.

This will validly eliminate lockdep alarms for v4l2_ctrl_handler locking
validation, as long as the relationships between drivers adding v4l2
controls to their own handler from other v4l2 drivers' control handlers
remains straightforward.

struct v4l2_ctrl_handler.lock lock classes are created with names such
that the output of cat /proc/lockdep indicates where in the v4l2 driver
code v4l2_ctrl_handle_init() is being called on instantiations:

a045f490 FD:   10 BD:8 +.+...: cx2341x:1534:(hdl)->lock
a0497d20 FD:   12 BD:2 +.+.+.: saa7115:1581:(hdl)->lock
a04ac660 FD:   14 BD:2 +.+.+.: msp3400_driver:756:(hdl)->lock
a0484b90 FD:   12 BD:1 +.+.+.: ivtv_gpio:366:(&itv->hdl_gpio)->lock
a04eb530 FD:   11 BD:2 +.+.+.: cx25840_core:1982:(&state->hdl)->lock
a04fbc80 FD:   11 BD:3 +.+.+.: wm8775:246:(&state->hdl)->lock

Some lock chains, that were previously causing the recursion alarms, are
now visible in the output of cat /proc/lockdep_chains:

irq_context: 0
[a0497d20] saa7115:1581:(hdl)->lock
[a045f490] cx2341x:1534:(hdl)->lock

irq_context: 0
[a04ac660] msp3400_driver:756:(hdl)->lock
[a045f490] cx2341x:1534:(hdl)->lock

irq_context: 0
[a0484b90] ivtv_gpio:366:(&itv->hdl_gpio)->lock
[a045f490] cx2341x:1534:(hdl)->lock

irq_context: 0
[a04eb530] cx25840_core:1982:(&state->hdl)->lock
[a045f490] cx2341x:1534:(hdl)->lock

irq_context: 0
[a04fbc80] wm8775:246:(&state->hdl)->lock
[a045f490] cx2341x:1534:(hdl)->lock


Signed-off-by: Andy Walls 


diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 9d2502c..8b7de34 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -761,10 +761,9 @@ static inline int handler_set_err(struct v4l2_ctrl_handler 
*hdl, int err)
 }
 
 /* Initialize the handler */
-int v4l2_ctrl_handler_init(struct v4l2_ctrl_handler *hdl,
-  unsigned nr_of_controls_hint)
+int _v4l2_ctrl_handler_init(struct v4l2_ctrl_handler *hdl,
+   unsigned nr_of_controls_hint)
 {
-   mutex_init(&hdl->lock);
INIT_LIST_HEAD(&hdl->ctrls);
INIT_LIST_HEAD(&hdl->ctrl_refs);
hdl->nr_of_buckets = 1 + nr_of_controls_hint / 8;
@@ -773,7 +772,7 @@ int v4l2_ctrl_handler_init(struct v4l2_ctrl_handler *hdl,
hdl->error = hdl->buckets ? 0 : -ENOMEM;
return hdl->error;
 }
-EXPORT_SYMBOL(v4l2_ctrl_handler_init);
+EXPORT_SYMBOL(_v4l2_ctrl_handler_init);
 
 /* Free all controls and control refs */
 void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 9b7bea9..3bc0f69 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -238,8 +238,21 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
   * Returns an error if the buckets could not be allocated. This error will
   * also be stored in @hdl->error.
   */
-int v4l2_ctrl_handler_init(struct v4l2_ctrl_handler *hdl,
-  unsigned nr_of_controls_hint);
+int _v4l2_ctrl_handler_init(struct v4l2_ctrl_handler *hdl,
+   unsigned nr_of_controls_hint);
+
+#define v4l2_ctrl_handler_init(hdl, nr_of_controls_hint)   \
+(  \
+   ({  \
+   static struct lock_class_key _key;  \
+   mutex_init(&(hdl)->lock);   \
+   lockdep_set_class_and_name(&(hdl)->lock, &_key, \
+  KBUILD_BASENAME ":"  \
+  __stringify(__LINE__) ":"\
+  "(" #hdl ")->lock"); \
+   }), \
+   _v4l2_ctrl_handler_init(hdl, nr_of_controls_hint)   \
+)
 
 /** v4l2_ctrl_handler_free() - Free all controls owned by the handler and free
   * the control list.


--
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_declare_coherent_memory: push ioremap() up to caller

[Janusz Krzysztofik]

Friday 24 December 2010 00:54:34 Russell King - ARM Linux napisał(a):
> On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote:
> > The patch tries to implement a solution suggested by Russell King,
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December
> >/035264.html. It is expected to solve video buffer allocation issues
> > for at least a few soc_camera I/O memory less host interface
> > drivers, designed around the videobuf_dma_contig layer, which
> > allocates video buffers using dma_alloc_coherent().
> >
> > Created against linux-2.6.37-rc5.
> >
> > Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera
> > patch, patterned upon two mach-mx3 machine types which already try
> > to use the dma_declare_coherent_memory() method for reserving a
> > region of system RAM preallocated with another
> > dma_alloc_coherent(). Compile tested for all modified files except
> > arch/sh/drivers/pci/fixups-dreamcast.c.
> >
> > Signed-off-by: Janusz Krzysztofik 
> > ---
> > I intended to quote Russell in my commit message and even asked him
> > for his permission, but since he didn't respond, I decided to
> > include a link to his original message only.
>
> There's no problem quoting messages which were sent to public mailing
> lists, especially when there's a record of what was said in public
> archives too.
>
> I think this is definitely a step forward.
>
> > ---
> > linux-2.6.37-rc5/arch/arm/mach-mx3/mach-pcm037.c.orig   2010-12-09
> > 23:07:34.0 +0100 +++
> > linux-2.6.37-rc5/arch/arm/mach-mx3/mach-pcm037.c2010-12-23
> > 18:32:24.0 +0100 @@ -431,7 +431,7 @@ static int __init
> > pcm037_camera_alloc_dm memset(buf, 0, buf_size);
> >
> > dma = dma_declare_coherent_memory(&mx3_camera.dev,
> > -   dma_handle, dma_handle, buf_size,
> > +   buf, dma_handle, buf_size,
> > DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
> >
> > /* The way we call dma_declare_coherent_memory only a malloc can
> > fail */ ---
> > linux-2.6.37-rc5/arch/arm/mach-mx3/mach-mx31moboard.c.orig  2010-12-
> >09 23:07:34.0 +0100 +++
> > linux-2.6.37-rc5/arch/arm/mach-mx3/mach-mx31moboard.c   2010-12-23
> > 18:32:24.0 +0100 @@ -486,7 +486,7 @@ static int __init
> > mx31moboard_cam_alloc_ memset(buf, 0, buf_size);
> >
> > dma = dma_declare_coherent_memory(&mx3_camera.dev,
> > -   dma_handle, dma_handle, buf_size,
> > +   buf, dma_handle, buf_size,
> > DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
> >
> > /* The way we call dma_declare_coherent_memory only a malloc can
> > fail */
>
> A side note for the mx3 folk: although it's not specified in DMA-API,
> memory allocated from dma_alloc_coherent() on ARM is already memset
> to zero by the allocation function.
>
> > --- linux-2.6.37-rc5/drivers/base/dma-coherent.c.orig   2010-12-09
> > 23:08:03.0 +0100 +++
> > linux-2.6.37-rc5/drivers/base/dma-coherent.c2010-12-23
> > 18:32:24.0 +0100 @@ -14,10 +14,9 @@ struct dma_coherent_mem
> > {
> > unsigned long   *bitmap;
> >  };
> >
> > -int dma_declare_coherent_memory(struct device *dev, dma_addr_t
> > bus_addr, +int dma_declare_coherent_memory(struct device *dev, void
> > *virt_addr, dma_addr_t device_addr, size_t size, int flags)
> >  {
> > -   void __iomem *mem_base = NULL;
> > int pages = size >> PAGE_SHIFT;
> > int bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
> >
> > @@ -30,10 +29,6 @@ int dma_declare_coherent_memory(struct d
> >
> > /* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN
> > */
> >
> > -   mem_base = ioremap(bus_addr, size);
> > -   if (!mem_base)
> > -   goto out;
> > -
> > dev->dma_mem = kzalloc(sizeof(struct dma_coherent_mem),
> > GFP_KERNEL); if (!dev->dma_mem)
> > goto out;
> > @@ -41,7 +36,7 @@ int dma_declare_coherent_memory(struct d
> > if (!dev->dma_mem->bitmap)
> > goto free1_out;
> >
> > -   dev->dma_mem->virt_base = mem_base;
> > +   dev->dma_mem->virt_base = virt_addr;
>
> I didn't see anything changing the dev->dma_mem->virt_base type to
> drop the __iomem attribute (which I suspect shouldn't be there -
> we're returning it via a void pointer anyway, so I think the whole
> coherent part of the DMA API should be __iomem-less.

There was no __iomem attribute specified for the .virt_base member of 
the struct dma_coherent_mem, pure (void *), so nothing to be changed 
there.

Thanks,
Janusz

> It also pushes the sparse address space warnings to the right place
> IMHO too.
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-media" in the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the b

Re: [PATCH] dma_declare_coherent_memory: push ioremap() up to caller

[Paul Mundt]

On Thu, Dec 23, 2010 at 11:54:34PM +, Russell King - ARM Linux wrote:
> On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote:
> > The patch tries to implement a solution suggested by Russell King, 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/035264.html.
> >  
> > It is expected to solve video buffer allocation issues for at least a 
> > few soc_camera I/O memory less host interface drivers, designed around 
> > the videobuf_dma_contig layer, which allocates video buffers using 
> > dma_alloc_coherent().
> > 
> > Created against linux-2.6.37-rc5.
> > 
> > Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, 
> > patterned upon two mach-mx3 machine types which already try to use the 
> > dma_declare_coherent_memory() method for reserving a region of system 
> > RAM preallocated with another dma_alloc_coherent(). Compile tested for 
> > all modified files except arch/sh/drivers/pci/fixups-dreamcast.c.
> > 
> > Signed-off-by: Janusz Krzysztofik 
> > ---
> > I intended to quote Russell in my commit message and even asked him for 
> > his permission, but since he didn't respond, I decided to include a link 
> > to his original message only.
> 
> There's no problem quoting messages which were sent to public mailing
> lists, especially when there's a record of what was said in public
> archives too.
> 
> I think this is definitely a step forward.
> 
The -tip folks have started using LKML-Reference tags to help with this,
although I don't believe its usage is officially documented anywhere.
--
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_declare_coherent_memory: push ioremap() up to caller

[Russell King - ARM Linux]

On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote:
> The patch tries to implement a solution suggested by Russell King, 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/035264.html.
>  
> It is expected to solve video buffer allocation issues for at least a 
> few soc_camera I/O memory less host interface drivers, designed around 
> the videobuf_dma_contig layer, which allocates video buffers using 
> dma_alloc_coherent().
> 
> Created against linux-2.6.37-rc5.
> 
> Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, 
> patterned upon two mach-mx3 machine types which already try to use the 
> dma_declare_coherent_memory() method for reserving a region of system 
> RAM preallocated with another dma_alloc_coherent(). Compile tested for 
> all modified files except arch/sh/drivers/pci/fixups-dreamcast.c.
> 
> Signed-off-by: Janusz Krzysztofik 
> ---
> I intended to quote Russell in my commit message and even asked him for 
> his permission, but since he didn't respond, I decided to include a link 
> to his original message only.

There's no problem quoting messages which were sent to public mailing
lists, especially when there's a record of what was said in public
archives too.

I think this is definitely a step forward.

> --- linux-2.6.37-rc5/arch/arm/mach-mx3/mach-pcm037.c.orig 2010-12-09 
> 23:07:34.0 +0100
> +++ linux-2.6.37-rc5/arch/arm/mach-mx3/mach-pcm037.c  2010-12-23 
> 18:32:24.0 +0100
> @@ -431,7 +431,7 @@ static int __init pcm037_camera_alloc_dm
>   memset(buf, 0, buf_size);
>  
>   dma = dma_declare_coherent_memory(&mx3_camera.dev,
> - dma_handle, dma_handle, buf_size,
> + buf, dma_handle, buf_size,
>   DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
>  
>   /* The way we call dma_declare_coherent_memory only a malloc can fail */
> --- linux-2.6.37-rc5/arch/arm/mach-mx3/mach-mx31moboard.c.orig
> 2010-12-09 23:07:34.0 +0100
> +++ linux-2.6.37-rc5/arch/arm/mach-mx3/mach-mx31moboard.c 2010-12-23 
> 18:32:24.0 +0100
> @@ -486,7 +486,7 @@ static int __init mx31moboard_cam_alloc_
>   memset(buf, 0, buf_size);
>  
>   dma = dma_declare_coherent_memory(&mx3_camera.dev,
> - dma_handle, dma_handle, buf_size,
> + buf, dma_handle, buf_size,
>   DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
>  
>   /* The way we call dma_declare_coherent_memory only a malloc can fail */

A side note for the mx3 folk: although it's not specified in DMA-API,
memory allocated from dma_alloc_coherent() on ARM is already memset
to zero by the allocation function.

> --- linux-2.6.37-rc5/drivers/base/dma-coherent.c.orig 2010-12-09 
> 23:08:03.0 +0100
> +++ linux-2.6.37-rc5/drivers/base/dma-coherent.c  2010-12-23 
> 18:32:24.0 +0100
> @@ -14,10 +14,9 @@ struct dma_coherent_mem {
>   unsigned long   *bitmap;
>  };
>  
> -int dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
> +int dma_declare_coherent_memory(struct device *dev, void *virt_addr,
>   dma_addr_t device_addr, size_t size, int flags)
>  {
> - void __iomem *mem_base = NULL;
>   int pages = size >> PAGE_SHIFT;
>   int bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
>  
> @@ -30,10 +29,6 @@ int dma_declare_coherent_memory(struct d
>  
>   /* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN */
>  
> - mem_base = ioremap(bus_addr, size);
> - if (!mem_base)
> - goto out;
> -
>   dev->dma_mem = kzalloc(sizeof(struct dma_coherent_mem), GFP_KERNEL);
>   if (!dev->dma_mem)
>   goto out;
> @@ -41,7 +36,7 @@ int dma_declare_coherent_memory(struct d
>   if (!dev->dma_mem->bitmap)
>   goto free1_out;
>  
> - dev->dma_mem->virt_base = mem_base;
> + dev->dma_mem->virt_base = virt_addr;

I didn't see anything changing the dev->dma_mem->virt_base type to
drop the __iomem attribute (which I suspect shouldn't be there - we're
returning it via a void pointer anyway, so I think the whole coherent
part of the DMA API should be __iomem-less.

It also pushes the sparse address space warnings to the right place
IMHO too.
--
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] dma_declare_coherent_memory: push ioremap() up to caller

[Janusz Krzysztofik]

The patch tries to implement a solution suggested by Russell King, 
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/035264.html.
 
It is expected to solve video buffer allocation issues for at least a 
few soc_camera I/O memory less host interface drivers, designed around 
the videobuf_dma_contig layer, which allocates video buffers using 
dma_alloc_coherent().

Created against linux-2.6.37-rc5.

Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, 
patterned upon two mach-mx3 machine types which already try to use the 
dma_declare_coherent_memory() method for reserving a region of system 
RAM preallocated with another dma_alloc_coherent(). Compile tested for 
all modified files except arch/sh/drivers/pci/fixups-dreamcast.c.

Signed-off-by: Janusz Krzysztofik 
---
I intended to quote Russell in my commit message and even asked him for 
his permission, but since he didn't respond, I decided to include a link 
to his original message only.

 Documentation/DMA-API.txt  |   18 +++
 arch/arm/mach-mx3/mach-mx31moboard.c   |2 -
 arch/arm/mach-mx3/mach-pcm037.c|2 -
 arch/sh/drivers/pci/fixups-dreamcast.c |6 +++
 drivers/base/dma-coherent.c|   12 +--
 drivers/base/dma-mapping.c |4 +-
 drivers/media/video/sh_mobile_ceu_camera.c |   20 +++-
 drivers/scsi/NCR_Q720.c|   15 +++--
 drivers/usb/gadget/langwell_udc.c  |   25 
 drivers/usb/gadget/langwell_udc.h  |1
 drivers/usb/host/ohci-sm501.c  |   45 -
 drivers/usb/host/ohci-tmio.c   |   14 -
 include/asm-generic/dma-coherent.h |2 -
 include/linux/dma-mapping.h|6 +--
 14 files changed, 122 insertions(+), 50 deletions(-)

--- linux-2.6.37-rc5/include/linux/dma-mapping.h.orig   2010-12-09 
23:09:05.0 +0100
+++ linux-2.6.37-rc5/include/linux/dma-mapping.h2010-12-23 
18:32:24.0 +0100
@@ -164,7 +164,7 @@ static inline int dma_get_cache_alignmen
 
 #ifndef ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY
 static inline int
-dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
+dma_declare_coherent_memory(struct device *dev, void *virt_addr,
dma_addr_t device_addr, size_t size, int flags)
 {
return 0;
@@ -195,13 +195,13 @@ extern void *dmam_alloc_noncoherent(stru
 extern void dmam_free_noncoherent(struct device *dev, size_t size, void *vaddr,
  dma_addr_t dma_handle);
 #ifdef ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY
-extern int dmam_declare_coherent_memory(struct device *dev, dma_addr_t 
bus_addr,
+extern int dmam_declare_coherent_memory(struct device *dev, void *virt_addr,
dma_addr_t device_addr, size_t size,
int flags);
 extern void dmam_release_declared_memory(struct device *dev);
 #else /* ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY */
 static inline int dmam_declare_coherent_memory(struct device *dev,
-   dma_addr_t bus_addr, dma_addr_t device_addr,
+   void *virt_addr, dma_addr_t device_addr,
size_t size, gfp_t gfp)
 {
return 0;
--- linux-2.6.37-rc5/include/asm-generic/dma-coherent.h.orig2010-12-09 
23:09:04.0 +0100
+++ linux-2.6.37-rc5/include/asm-generic/dma-coherent.h 2010-12-23 
18:32:24.0 +0100
@@ -15,7 +15,7 @@ int dma_release_from_coherent(struct dev
  */
 #define ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY
 extern int
-dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
+dma_declare_coherent_memory(struct device *dev, void *virt_addr,
dma_addr_t device_addr, size_t size, int flags);
 
 extern void
--- linux-2.6.37-rc5/Documentation/DMA-API.txt.orig 2010-12-09 
23:07:27.0 +0100
+++ linux-2.6.37-rc5/Documentation/DMA-API.txt  2010-12-23 18:32:24.0 
+0100
@@ -477,20 +477,25 @@ continuing on for size.  Again, you *mus
 boundaries when doing this.
 
 int
-dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
+dma_declare_coherent_memory(struct device *dev, void *virt_addr,
dma_addr_t device_addr, size_t size, int
flags)
 
 Declare region of memory to be handed out by dma_alloc_coherent when
 it's asked for coherent memory for this device.
 
-bus_addr is the physical address to which the memory is currently
-assigned in the bus responding region (this will be used by the
-platform to perform the mapping).
+virt_addr is the virtual address to which the pysical memory in the bus
+responding region is currently mapped (this will be handed out by
+dma_alloc_coherent() directly as its return value). Both a pointer to
+the ioremaped memory on the peripheral's bus, as well as a
+dma_all

RE: [patch] [media] cx231xxx: fix typo in saddr_len check

[Sri Deevi]

I am ok with the changes.

Signed-off-by: Srinivasa Deevi 

Sri

-Original Message-
From: Dan Carpenter [mailto:erro...@gmail.com] 
Sent: Thursday, December 23, 2010 11:39 AM
To: Sri Deevi
Cc: 'Andy Walls'; linux-media@vger.kernel.org; mche...@infradead.org
Subject: [patch] [media] cx231xxx: fix typo in saddr_len check

The original code compared "saddr_len" with zero twice in a nonsensical
way.  I asked the list, and Andy Walls and Sri Deevi say that the second
check should be if "saddr_len == 1".

Signed-off-by: Dan Carpenter 

diff --git a/drivers/media/video/cx231xx/cx231xx-core.c 
b/drivers/media/video/cx231xx/cx231xx-core.c
index 44d124c..7d62d58 100644
--- a/drivers/media/video/cx231xx/cx231xx-core.c
+++ b/drivers/media/video/cx231xx/cx231xx-core.c
@@ -1515,7 +1515,7 @@ int cx231xx_read_i2c_master(struct cx231xx *dev, u8 
dev_addr, u16 saddr,
 
if (saddr_len == 0)
saddr = 0;
-   else if (saddr_len == 0)
+   else if (saddr_len == 1)
saddr &= 0xff;
 
/* prepare xfer_data struct */
@@ -1566,7 +1566,7 @@ int cx231xx_write_i2c_master(struct cx231xx *dev, u8 
dev_addr, u16 saddr,
 
if (saddr_len == 0)
saddr = 0;
-   else if (saddr_len == 0)
+   else if (saddr_len == 1)
saddr &= 0xff;
 
/* prepare xfer_data struct */
@@ -1600,7 +1600,7 @@ int cx231xx_read_i2c_data(struct cx231xx *dev, u8 
dev_addr, u16 saddr,
 
if (saddr_len == 0)
saddr = 0;
-   else if (saddr_len == 0)
+   else if (saddr_len == 1)
saddr &= 0xff;
 
/* prepare xfer_data struct */
@@ -1641,7 +1641,7 @@ int cx231xx_write_i2c_data(struct cx231xx *dev, u8 
dev_addr, u16 saddr,
 
if (saddr_len == 0)
saddr = 0;
-   else if (saddr_len == 0)
+   else if (saddr_len == 1)
saddr &= 0xff;
 
/* prepare xfer_data struct */

Conexant E-mail Firewall (Conexant.Com) made the following annotations
-
** Legal Disclaimer  

"This email may contain confidential and privileged material for the sole use 
of the intended recipient. Any unauthorized review, use or distribution by 
others is strictly prohibited. If you have received the message in error, 
please advise the sender by reply email and delete the message. Thank you." 

** 

-

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch] [media] cx231xxx: fix typo in saddr_len check

[Dan Carpenter]

The original code compared "saddr_len" with zero twice in a nonsensical
way.  I asked the list, and Andy Walls and Sri Deevi say that the second
check should be if "saddr_len == 1".

Signed-off-by: Dan Carpenter 

diff --git a/drivers/media/video/cx231xx/cx231xx-core.c 
b/drivers/media/video/cx231xx/cx231xx-core.c
index 44d124c..7d62d58 100644
--- a/drivers/media/video/cx231xx/cx231xx-core.c
+++ b/drivers/media/video/cx231xx/cx231xx-core.c
@@ -1515,7 +1515,7 @@ int cx231xx_read_i2c_master(struct cx231xx *dev, u8 
dev_addr, u16 saddr,
 
if (saddr_len == 0)
saddr = 0;
-   else if (saddr_len == 0)
+   else if (saddr_len == 1)
saddr &= 0xff;
 
/* prepare xfer_data struct */
@@ -1566,7 +1566,7 @@ int cx231xx_write_i2c_master(struct cx231xx *dev, u8 
dev_addr, u16 saddr,
 
if (saddr_len == 0)
saddr = 0;
-   else if (saddr_len == 0)
+   else if (saddr_len == 1)
saddr &= 0xff;
 
/* prepare xfer_data struct */
@@ -1600,7 +1600,7 @@ int cx231xx_read_i2c_data(struct cx231xx *dev, u8 
dev_addr, u16 saddr,
 
if (saddr_len == 0)
saddr = 0;
-   else if (saddr_len == 0)
+   else if (saddr_len == 1)
saddr &= 0xff;
 
/* prepare xfer_data struct */
@@ -1641,7 +1641,7 @@ int cx231xx_write_i2c_data(struct cx231xx *dev, u8 
dev_addr, u16 saddr,
 
if (saddr_len == 0)
saddr = 0;
-   else if (saddr_len == 0)
+   else if (saddr_len == 1)
saddr &= 0xff;
 
/* prepare xfer_data struct */
--
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: V4L2 driver for Qualcomm MSM camera.

[Shuzhen Wang]

Hello, 

This is the architecture overview we put together for Qualcomm MSM camera
support in linux-media tree. Your comments are very much appreciated!


Introduction


This is the video4linux driver for Qualcomm MSM (Mobile Station Modem)
camera.

The driver supports video and camera functionality on Qualcomm MSM SoC.
It supports camera sensors provided by OEMs with parallel/MIPI
interfaces, and operates in continuous streaming, snapshot, or video
recording modes.

Hardware description


MSM camera hardware contains the following components:
1. One or more camera sensors controlled via I2C bus, and data outputs
on AXI or MIPI bus.
2. Video Front End (VFE) core is an image signal processing hardware
pipeline that takes the sensor output, does the necessary processing,
and outputs to a buffer for V4L2 application. VFE is clocked by PCLK
(pixel clock) from the sensor.

Software description


The driver encapsulates the low-level hardware management and aligns
the interface to V4L2 driver framework. There is also a user space
camera service daemon which handles events from driver and changes
settings accordingly.

During boot-up, the sensor is probed for and if the probe succeeds
/dev/video0 and /dev/msm_camera/config0 device nodes are created. The
/dev/video0 node is used for video buffer allocation in the kernel and for
receiving V4L2 ioctls for controlling the camera hardware (VFE, sensors).
The /dev/msm_camera/config0 node is used for sending commands and other
statistics available from the hardware to the camera service daemon. Note
that if more than one camera sensor is detected, there will be /dev/video1
and /dev/msm_camera/config1 device nodes created as well.

Design
==

For MSM camera IC, significant portion of image processing and optimization
codes are proprietary, so they cannot sit in kernel space. This plays an
important role when making design decisions.

Our design is to have a light-weighted kernel driver, and put the
proprietary code in a user space daemon. The daemon polls on events
from /dev/msm_camera/config0 device in the form of v4l2_event. The events
could either be asynchronous (generated by the hardware), or synchronous
(control command from the application). Based on the events it receives,
the daemon will send appropriate control commands to the hardware.

   +-+++
   | Application || Service Daemon |
   +-+++ User Space
 ..
   +--+  Kernel Space
   |V4L2  |
   +--+
   +-+ ++ +---+
   | VFE/ISP | | Sensor | | Flash |
   +-+ ++ +---+

Power Management


None at this point.

SMP/multi-core
==

Mutex is used for synchronization of threads accessing the driver
simultaneously. Between hardware interrupt handler and threads,
we use spinlock to make sure locking is done properly.

Security


None.

Interface
=

The driver uses V4L2 API for user kernel interaction. Refer to
http://v4l2spec.bytesex.org/spec-single/v4l2.html.

Between camera service daemon and the driver, we have customized IOCTL
commands associated with /dev/msm_camera/config0 node, that controls MSM
camera hardware. The list of IOCTLs are (declarations can be found in
include/media/msm_camera.h):

MSM_CAM_IOCTL_GET_SENSOR_INFO
Get the basic information such as name, flash support for the
detected sensor.
MSM_CAM_IOCTL_SENSOR_IO_CFG
Get or set sensor configurations: fps, line_pf, pixels_pl,
exposure and gain, etc. The setting is stored in sensor_cfg_data
structure.
MSM_CAM_IOCTL_CONFIG_VFE
Change settings of different components of VFE hardware.
MSM_CAM_IOCTL_CTRL_CMD_DONE
Notify the driver that the ctrl command is finished.
MSM_CAM_IOCTL_RELEASE_STATS_BUFFER
Notify the driver that the service daemon has done processing the
stats buffer, and is returning it to the driver.
MSM_CAM_IOCTL_AXI_CONFIG
Configure AXI bus parameters (frame buffer addresses, offsets) to
the VFE hardware.

Driver parameters
=

None.

Config options
==

MSM_CAMERA in drivers/media/video/msm/Kconfig file

Dependencies


PMIC, I2C, Clock, GPIO

User space utilities


A daemon process in the user space called mm-qcamera-daemon is polling
on events from the driver. This daemon is required in order for the V4L2
client application to run, and it's started by the init script.

Other
=

To do
=

1. Eliminate creation of /dev/msm_camera/config0 by routing private
ioctls through /dev/video0.
2. Create sub devices for sensor and VFE.



--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The 

[RFC/PATCH] v4l: Add S5P MIPI-CSI2 interface subdev driver

[Sylwester Nawrocki]

Add the v4l2 subdev/platform device driver for S5P SoC MIPI-CSI2
slave devices.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 

---

Hello,

this patch adds a v4l2 subdev/platform device driver for S5P SoC MIPI-CSI2
slave devices.On S5PVXXX SoC there might be up two MIPI-CSI channels.
This driver creates for each channel a subdev instance which is intended
to interwork with the s5pc-fimc host driver. I am going to post 
the patches for the s5p fimc driver in near future so it can be seen how 
the subdevs are used.
We are looking forward to use the media controller framework
with S5P SoC for camera devices control, since the SoC architecture
is relatively complex and flexible in configuration.
There are up to 4 camera host interfaces with scaler, rotator
and color format converter, up to 2 MIPI-CSI2 interfaces and
there are also available datapaths to and from up to 2 LCD controllers.

Regards,
--
Sylwester Nawrocki
Samsung Poland R&D Center

---
 drivers/media/video/Kconfig |8 +
 drivers/media/video/Makefile|1 +
 drivers/media/video/s5p-mipi_csis.c |  592 +++
 3 files changed, 601 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/s5p-mipi_csis.c

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index da08267..04441aa 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -732,6 +732,13 @@ config VIDEO_VIA_CAMERA
   Chrome9 chipsets.  Currently only tested on OLPC xo-1.5 systems
   with ov7670 sensors.
 
+config VIDEO_S5P_MIPI_CSIS
+   bool "S5P MIPI-CSI2 slave iterface support"
+   depends on VIDEO_V4L2
+   ---help---
+ This is video4linux driver for MIPI CSI2 interfaces
+ in Samsung S5P SoCs.
+
 config SOC_CAMERA
tristate "SoC camera support"
depends on VIDEO_V4L2 && HAS_DMA && I2C
@@ -1000,6 +1007,7 @@ config  VIDEO_SAMSUNG_S5P_FIMC
depends on VIDEO_DEV && VIDEO_V4L2 && PLAT_S5P
select VIDEOBUF_DMA_CONTIG
select V4L2_MEM2MEM_DEV
+   select VIDEO_SAMSUNG_MIPI_CSIS
help
  This is a v4l2 driver for the S5P camera interface
  (video postprocessor)
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 482f14b..8cc093f 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -164,6 +164,7 @@ obj-$(CONFIG_VIDEO_PXA27x)  += pxa_camera.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)  += sh_mobile_ceu_camera.o
 obj-$(CONFIG_VIDEO_OMAP1)  += omap1_camera.o
+obj-$(CONFIG_VIDEO_S5P_MIPI_CSIS)  += s5p-mipi_csis.o
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC)   += s5p-fimc/
 
 obj-$(CONFIG_ARCH_DAVINCI) += davinci/
diff --git a/drivers/media/video/s5p-mipi_csis.c 
b/drivers/media/video/s5p-mipi_csis.c
new file mode 100644
index 000..823f49f
--- /dev/null
+++ b/drivers/media/video/s5p-mipi_csis.c
@@ -0,0 +1,592 @@
+/*
+ * Samsung S5P SoC series MIPI-CSI2 slave interface driver
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd
+ * Contact: Sylwester Nawrocki, 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Enable module debug trace. Set to 1 to enable.");
+
+#define MODULE_NAME"s5p-mipi-csis"
+
+/* Register map definition */
+
+/* CSI global control. */
+#define S5P_CSIS_CTRL  0x00
+#define S5P_CSIS_CTRL_DPDN_DEFAULT (0 << 31)
+#define S5P_CSIS_CTRL_DPDN_SWAP(1 << 31)
+#define S5P_CSIS_CTRL_ALIGN_32BIT  (1 << 20)
+#define S5P_CSIS_CTRL_UPDATE_SHADOW(1 << 16)
+#define S5P_CSIS_CTRL_WCLK_EXTCLK  (1 << 8)
+#define S5P_CSIS_CTRL_RESET(1 << 4)
+#define S5P_CSIS_CTRL_ENABLE   (1 << 0)
+
+/* D-PHY control. */
+#define S5P_CSIS_DPHYCTRL  0x04
+#define S5P_CSIS_DPHYCTRL_HSS_MASK (0x1F << 27)
+#define S5P_CSIS_DPHYCTRL_ENABLE   (0x1F << 0)
+
+#define S5P_CSIS_CONFIG0x08
+#define S5P_CSIS_CFG_FMT_YCBCR422_8BIT (0x1E << 2)
+#define S5P_CSIS_CFG_FMT_RAW8  (0x2A << 2)
+#define S5P_CSIS_CFG_FMT_RAW10 (0x2B << 2)
+#define S5P_CSIS_CFG_FMT_RAW12 (0x2C << 2)
+#define S5P_CSIS_CFG_FMT_USER1 (0x30 << 2)
+#define S5P_CSIS_CFG_FMT_MASK  (0x3F << 2)
+#define S5P_CSIS_CFG_NR_LANE_MASK  3
+
+/* Interrupt mask. */
+#define S5P_CSIS_INTMSK0x10
+#define S5P_CSIS_INTMSK_EN_ALL 0xF03F
+#define S5P_CSIS_INTSRC0x14
+
+/* Pixel resolution.

em28xx pinnacle pctv

[daniele]

> lsusb
> Bus 002 Device 002: ID eb1a:2870 eMPIA Technology, Inc. Pinnacle PCTV
> Stick
> 
> Linux ubuntu 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC
> 2010 x86_64 GNU/Linux
> 
> I'm sorry to disturb, but it's an year I can resolve this question...
> My pinnacle pctv usb2 dvb-t was working very well with linux once, now
i
> can't make it scans channels... it finds only five type of
> channels(RETECAPRI and similar cause I'm in italy).
> i'm using these modules
> http://jiemeb.free.fr/pinnacle/
> 
> ANY HELP appreciated.

--
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: smatch report: cx231xx: incorrect check in cx231xx_write_i2c_data()

[Dan Carpenter]

On Thu, Dec 23, 2010 at 01:34:52PM -0500, Andy Walls wrote:
> and noting that "req_data->saddr_dat" holds what was "saddr";
> the if statement, and the many others like it, [...]

The others I see are:
cx231xx_write_i2c_data()
cx231xx_read_i2c_data()
cx231xx_write_i2c_master()
cx231xx_read_i2c_master()

regards,
dan carpenter


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: smatch report: cx231xx: incorrect check in cx231xx_write_i2c_data()

[Andy Walls]

On Thu, 2010-12-23 at 19:43 +0300, Dan Carpenter wrote:
> Hi,
> 
> I was doing an audit and I came across this.
> 
> drivers/media/video/cx231xx/cx231xx-core.c +1644 cx231xx_write_i2c_data(14)
>   warn: 'saddr_len' is non-zero. Did you mean 'saddr'
> 
>   1642  if (saddr_len == 0)
>   1643  saddr = 0;
>   1644  else if (saddr_len == 0)
>   1645  saddr &= 0xff;
> 
> We check "saddr_len == 0" twice which doesn't make sense.  I'm not sure
> what the correct fix is though.

Given that "saddr" probably means "sub-address", that "saddr_len"
probably means "sub-address length", that saddr is only a 16 bit value,
and this switch in cx231xx_send_usb_command():

/* set index value */
switch (saddr_len) {
case 0:
ven_req.wIndex = 0; /* need check */
break;
case 1:
ven_req.wIndex = (req_data->saddr_dat & 0xff);
break;
case 2:
ven_req.wIndex = req_data->saddr_dat;
break;
}

and noting that "req_data->saddr_dat" holds what was "saddr";
the if statement, and the many others like it, should probably be:

if (saddr_len == 0)
saddr = 0;
else if (saddr_len == 1)   <- == 1
saddr &= 0xff;


Regards,
Andy

>   It's been this way since the driver was
> merged.
> 
> regards,
> dan carpenter



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[cron job] v4l-dvb daily build: WARNINGS

[Hans Verkuil]

This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Thu Dec 23 19:00:21 CET 2010
git master:   59365d136d205cc20fe666ca7f89b1c5001b0d5a
git media-master: gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.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: [PATCHv8 00/12] Contiguous Memory Allocator

[David Brown]

Felipe Contreras  writes:

> On Thu, Dec 23, 2010 at 4:16 PM, Russell King - ARM Linux

> A generic solution (that I think I already proposed) would be to
> reserve a chunk of memory for the CMA that can be removed from the
> normally mapped kernel memory through memblock at boot time. The size
> of this memory region would be configurable through kconfig. Then, the
> CMA would have a "dma" flag or something, and take chunks out of it
> until there's no more, and then return errors. That would work for
> ARM.

That sounds an awful lot like the Android kernel's pmem implementation.

Solving this problem is important for us as well, but, I'm not sure I
see a better solution that something like Felipe suggests.

The disadvantage, of course, being that the memory isn't available for
the system when the user isn't doing the multi-media.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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 v10 5/8] davinci vpbe: platform specific additions

[Sergei Shtylyov]

Hello.

Manjunath Hadli wrote:


This patch implements the overall device creation for the Video
display driver



Signed-off-by: Manjunath Hadli 
Acked-by: Muralidharan Karicheri 
Acked-by: Hans Verkuil 

[...]


diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..eb87867 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -370,6 +370,7 @@ static struct platform_device dm644x_mdio_device = {
  * soc description mux  mode   mode  muxdbg
  * reg  offset mask  mode
  */
+


   Stray newline?

[...]

+static struct resource dm644x_venc_resources[] = {
+   /* venc registers io space */
+   {
+   .start  = 0x01C72400,
+   .end= 0x01C72400 + 0x17f,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+

[...]

+static struct resource dm644x_v4l2_disp_resources[] = {
+   {
+   .start  = IRQ_VENCINT,
+   .end= IRQ_VENCINT,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = 0x01C724B8,
+   .end= 0x01C724B8 + 0x3,
+   .flags  = IORESOURCE_MEM,
+   },
+};


   Still intersects with dm644x_venc_resources[]. Is it intended?


 static int __init dm644x_init_devices(void)
 {
if (!cpu_is_davinci_dm644x())
return 0;
 
-	/* Add ccdc clock aliases */

-   clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL);
-   clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL);
platform_device_register(&dm644x_edma_device);
-


   Should've left this newline alone...

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

smatch report: cx231xx: incorrect check in cx231xx_write_i2c_data()

[Dan Carpenter]

Hi,

I was doing an audit and I came across this.

drivers/media/video/cx231xx/cx231xx-core.c +1644 cx231xx_write_i2c_data(14)
warn: 'saddr_len' is non-zero. Did you mean 'saddr'

  1642  if (saddr_len == 0)
  1643  saddr = 0;
  1644  else if (saddr_len == 0)
  1645  saddr &= 0xff;

We check "saddr_len == 0" twice which doesn't make sense.  I'm not sure
what the correct fix is though.  It's been this way since the driver was
merged.

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv8 00/12] Contiguous Memory Allocator

[Tomasz Fujak]

On 2010-12-23 15:20, Russell King - ARM Linux wrote:
> On Thu, Dec 23, 2010 at 03:08:21PM +0100, Tomasz Fujak wrote:
>> On 2010-12-23 14:51, Russell King - ARM Linux wrote:
>>> On Thu, Dec 23, 2010 at 02:41:26PM +0100, Michal Nazarewicz wrote:
 Russell King - ARM Linux  writes:
> Has anyone addressed my issue with it that this is wide-open for
> abuse by allocating large chunks of memory, and then remapping
> them in some way with different attributes, thereby violating the
> ARM architecture specification?
>
> In other words, do we _actually_ have a use for this which doesn't
> involve doing something like allocating 32MB of memory from it,
> remapping it so that it's DMA coherent, and then performing DMA
> on the resulting buffer?
 Huge pages.

 Also, don't treat it as coherent memory and just flush/clear/invalidate
 cache before and after each DMA transaction.  I never understood what's
 wrong with that approach.
>>> If you've ever used an ARM system with a VIVT cache, you'll know what's
>>> wrong with this approach.
>>>
>>> ARM systems with VIVT caches have extremely poor task switching
>>> performance because they flush the entire data cache at every task switch
>>> - to the extent that it makes system performance drop dramatically when
>>> they become loaded.
>>>
>>> Doing that for every DMA operation will kill the advantage we've gained
>>> from having VIPT caches and ASIDs stone dead.
>> This statement effectively means: don't map dma-able memory to the CPU
>> unless it's uncached. Have I missed anything?
> I'll give you another solution to the problem - lobby ARM Ltd to have
> this restriction lifted from the architecture specification, which
> will probably result in the speculative prefetching also having to be
> removed.
>
Isn't disabling Speculative Accesses forwarding to the AXI bus the
solution to our woes?
At least on the A8, which happens to be paired with non-IOMMU capable
IPs on our SoCs.
On A9 the bit is gone (or has it moved?), but we have IOMMU here so the
CMA isn't needed.

http://infocenter.arm.com/
Cortex-A8 Technical Reference ManualRevision: r3p2
3.2.26. c1, Auxiliary Control Register
CP15, c1, c0, bit 4: Enables speculative accesses on AXI

> That would be my preferred solution if I had the power to do so, but
> I have to live with what ARM Ltd (and their partners such as yourselves)
> decide should end up in the architecture specification.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 8/8] davinci vpbe: Readme text for Dm6446 vpbe

[Alex Deucher]

On Thu, Dec 23, 2010 at 6:55 AM, Manjunath Hadli  wrote:
> Please refer to this file for detailed documentation of
> davinci vpbe v4l2 driver
>
> Signed-off-by: Manjunath Hadli 
> Acked-by: Muralidharan Karicheri 
> Acked-by: Hans Verkuil 
> ---
>  Documentation/video4linux/README.davinci-vpbe |   93 
> +
>  1 files changed, 93 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/video4linux/README.davinci-vpbe
>
> diff --git a/Documentation/video4linux/README.davinci-vpbe 
> b/Documentation/video4linux/README.davinci-vpbe
> new file mode 100644
> index 000..7a460b0
> --- /dev/null
> +++ b/Documentation/video4linux/README.davinci-vpbe
> @@ -0,0 +1,93 @@
> +
> +                VPBE V4L2 driver design
> + ==
> +
> + File partitioning
> + -
> + V4L2 display device driver
> +         drivers/media/video/davinci/vpbe_display.c
> +         drivers/media/video/davinci/vpbe_display.h
> +
> + VPBE display controller
> +         drivers/media/video/davinci/vpbe.c
> +         drivers/media/video/davinci/vpbe.h
> +
> + VPBE venc sub device driver
> +         drivers/media/video/davinci/vpbe_venc.c
> +         drivers/media/video/davinci/vpbe_venc.h
> +         drivers/media/video/davinci/vpbe_venc_regs.h
> +
> + VPBE osd driver
> +         drivers/media/video/davinci/vpbe_osd.c
> +         drivers/media/video/davinci/vpbe_osd.h
> +         drivers/media/video/davinci/vpbe_osd_regs.h
> +
> + Functional partitioning
> + ---
> +
> + Consists of the following (in the same order as the list under file
> + partitioning):-
> +
> + 1. V4L2 display driver
> +    Implements creation of video2 and video3 device nodes and
> +    provides v4l2 device interface to manage VID0 and VID1 layers.
> +
> + 2. Display controller
> +    Loads up VENC, OSD and external encoders such as ths8200. It provides
> +    a set of API calls to V4L2 drivers to set the output/standards
> +    in the VENC or external sub devices. It also provides
> +    a device object to access the services from OSD subdevice
> +    using sub device ops. The connection of external encoders to VENC LCD
> +    controller port is done at init time based on default output and standard
> +    selection or at run time when application change the output through
> +    V4L2 IOCTLs.
> +
> +    When connected to an external encoder, vpbe controller is also 
> responsible
> +    for setting up the interface between VENC and external encoders based on
> +    board specific settings (specified in board-xxx-evm.c). This allows
> +    interfacing external encoders such as ths8200. The setup_if_config()
> +    is implemented for this as well as configure_venc() (part of the next 
> patch)
> +    API to set timings in VENC for a specific display resolution. As of this
> +    patch series, the interconnection and enabling and setting of the 
> external
> +    encoders is not present, and would be a part of the next patch series.
> +
> + 3. VENC subdevice module
> +    Responsible for setting outputs provided through internal DACs and also
> +    setting timings at LCD controller port when external encoders are 
> connected
> +    at the port or LCD panel timings required. When external encoder/LCD 
> panel
> +    is connected, the timings for a specific standard/preset is retrieved 
> from
> +    the board specific table and the values are used to set the timings in
> +    venc using non-standard timing mode.
> +
> +    Support LCD Panel displays using the VENC. For example to support a Logic
> +    PD display, it requires setting up the LCD controller port with a set of
> +    timings for the resolution supported and setting the dot clock. So we 
> could
> +    add the available outputs as a board specific entry (i.e add the 
> "LogicPD"
> +    output name to board-xxx-evm.c). A table of timings for various LCDs
> +    supported can be maintained in the board specific setup file to support
> +    various LCD displays.As of this patch a basic driver is present, and this
> +    support for external encoders and displays forms a part of the next
> +    patch series.
> +

For 2. and 3., any plans to eventually migrate to a KMS interface?  It
seems like a lot of device specific controls here.

Alex


> + 4. OSD module
> +    OSD module implements all OSD layer management and hardware specific
> +    features. The VPBE module interacts with the OSD for enabling and
> +    disabling appropriate features of the OSD.
> +
> + Current status:-
> +
> + A fully functional working version of the V4L2 driver is available. This
> + driver has been tested with NTSC and PAL standards and buffer streaming.
> +
> + Following are TBDs.
> +
> + vpbe display controller
> +    - Add support for external encoders.
> +    - add support for selecting external encoder as default at probe time.
> +
> + vpbe venc sub device
> +    - add timings for supporting ths8200
> + 

Re: [PATCHv8 00/12] Contiguous Memory Allocator

[Michal Nazarewicz]

>> On Thu, Dec 23, 2010 at 03:04:07PM +0100, Tomasz Fujak wrote:
>>> In other words, should we take your response as yet another NAK?
>>> Or would you try harder and at least point us to some direction that
>>> would not doom the effort from the very beginning.

> On Thu, Dec 23, 2010 at 4:16 PM, Russell King - ARM Linux
>  wrote:
>> What the fsck do you think I've been doing?  This is NOT THE FIRST time
>> I've raised this issue.  I gave up raising it after the first couple
>> of attempts because I wasn't being listened to.
>>
>> You say about _me_ not being very helpful.  How about the CMA proponents
>> start taking the issue I've raised seriously, and try to work out how
>> to solve it?  And how about blaming them for the months of wasted time
>> on this issue _because_ _they_ have chosen to ignore it?

Felipe Contreras  writes:
> I've also raised the issue for ARM. However, I don't see what is the
> big problem.
>
> A generic solution (that I think I already proposed) would be to
> reserve a chunk of memory for the CMA that can be removed from the
> normally mapped kernel memory through memblock at boot time. The size
> of this memory region would be configurable through kconfig. Then, the
> CMA would have a "dma" flag or something, 

Having exactly that usage in mind, in v8 I've added notion of private
CMA contexts which can be used for DMA coherent RAM as well as memory
mapped devices.

> and take chunks out of it until there's no more, and then return
> errors. That would work for ARM.

-- 
Best regards, _ _
 .o. | Liege of Serenly Enlightened Majesty of  o' \,=./ `o
 ..o | Computer Science,  Michal "mina86" Nazarewicz   (o o)
 ooo +--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 8/8] davinci vpbe: Readme text for Dm6446 vpbe

[Manjunath Hadli]

Please refer to this file for detailed documentation of
davinci vpbe v4l2 driver

Signed-off-by: Manjunath Hadli 
Acked-by: Muralidharan Karicheri 
Acked-by: Hans Verkuil 
---
 Documentation/video4linux/README.davinci-vpbe |   93 +
 1 files changed, 93 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/video4linux/README.davinci-vpbe

diff --git a/Documentation/video4linux/README.davinci-vpbe 
b/Documentation/video4linux/README.davinci-vpbe
new file mode 100644
index 000..7a460b0
--- /dev/null
+++ b/Documentation/video4linux/README.davinci-vpbe
@@ -0,0 +1,93 @@
+
+VPBE V4L2 driver design
+ ==
+
+ File partitioning
+ -
+ V4L2 display device driver
+ drivers/media/video/davinci/vpbe_display.c
+ drivers/media/video/davinci/vpbe_display.h
+
+ VPBE display controller
+ drivers/media/video/davinci/vpbe.c
+ drivers/media/video/davinci/vpbe.h
+
+ VPBE venc sub device driver
+ drivers/media/video/davinci/vpbe_venc.c
+ drivers/media/video/davinci/vpbe_venc.h
+ drivers/media/video/davinci/vpbe_venc_regs.h
+
+ VPBE osd driver
+ drivers/media/video/davinci/vpbe_osd.c
+ drivers/media/video/davinci/vpbe_osd.h
+ drivers/media/video/davinci/vpbe_osd_regs.h
+
+ Functional partitioning
+ ---
+
+ Consists of the following (in the same order as the list under file
+ partitioning):-
+
+ 1. V4L2 display driver
+Implements creation of video2 and video3 device nodes and
+provides v4l2 device interface to manage VID0 and VID1 layers.
+
+ 2. Display controller
+Loads up VENC, OSD and external encoders such as ths8200. It provides
+a set of API calls to V4L2 drivers to set the output/standards
+in the VENC or external sub devices. It also provides
+a device object to access the services from OSD subdevice
+using sub device ops. The connection of external encoders to VENC LCD
+controller port is done at init time based on default output and standard
+selection or at run time when application change the output through
+V4L2 IOCTLs.
+
+When connected to an external encoder, vpbe controller is also responsible
+for setting up the interface between VENC and external encoders based on
+board specific settings (specified in board-xxx-evm.c). This allows
+interfacing external encoders such as ths8200. The setup_if_config()
+is implemented for this as well as configure_venc() (part of the next 
patch)
+API to set timings in VENC for a specific display resolution. As of this
+patch series, the interconnection and enabling and setting of the external
+encoders is not present, and would be a part of the next patch series.
+
+ 3. VENC subdevice module
+Responsible for setting outputs provided through internal DACs and also
+setting timings at LCD controller port when external encoders are connected
+at the port or LCD panel timings required. When external encoder/LCD panel
+is connected, the timings for a specific standard/preset is retrieved from
+the board specific table and the values are used to set the timings in
+venc using non-standard timing mode.
+
+Support LCD Panel displays using the VENC. For example to support a Logic
+PD display, it requires setting up the LCD controller port with a set of
+timings for the resolution supported and setting the dot clock. So we could
+add the available outputs as a board specific entry (i.e add the "LogicPD"
+output name to board-xxx-evm.c). A table of timings for various LCDs
+supported can be maintained in the board specific setup file to support
+various LCD displays.As of this patch a basic driver is present, and this
+support for external encoders and displays forms a part of the next
+patch series.
+
+ 4. OSD module
+OSD module implements all OSD layer management and hardware specific
+features. The VPBE module interacts with the OSD for enabling and
+disabling appropriate features of the OSD.
+
+ Current status:-
+
+ A fully functional working version of the V4L2 driver is available. This
+ driver has been tested with NTSC and PAL standards and buffer streaming.
+
+ Following are TBDs.
+
+ vpbe display controller
+- Add support for external encoders.
+- add support for selecting external encoder as default at probe time.
+
+ vpbe venc sub device
+- add timings for supporting ths8200
+- add support for LogicPD LCD.
+
+ FB drivers
+- Add support for fbdev drivers.- Ready and part of subsequent patches.
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 5/8] davinci vpbe: platform specific additions

[Manjunath Hadli]

This patch implements the overall device creation for the Video
display driver

Signed-off-by: Manjunath Hadli 
Acked-by: Muralidharan Karicheri 
Acked-by: Hans Verkuil 
---
 arch/arm/mach-davinci/dm644x.c  |  173 +--
 arch/arm/mach-davinci/include/mach/dm644x.h |4 +
 2 files changed, 169 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..eb87867 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -370,6 +370,7 @@ static struct platform_device dm644x_mdio_device = {
  * soc description mux  mode   mode  muxdbg
  * reg  offset mask  mode
  */
+
 static const struct mux_config dm644x_pins[] = {
 #ifdef CONFIG_DAVINCI_MUX
 MUX_CFG(DM644X, HDIREN,0,   16,1,1, true)
@@ -654,6 +655,146 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
 }
 
+static struct resource dm644x_osd_resources[] = {
+   {
+   .start  = 0x01C72600,
+   .end= 0x01C72600 + 0x1ff,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm644x_osd_dev = {
+   .name   = VPBE_OSD_SUBDEV_NAME,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_osd_resources),
+   .resource   = dm644x_osd_resources,
+   .dev = {
+   .dma_mask   = &dm644x_osd_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = DM644X_VPBE,
+   },
+};
+
+static struct resource dm644x_venc_resources[] = {
+   /* venc registers io space */
+   {
+   .start  = 0x01C72400,
+   .end= 0x01C72400 + 0x17f,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32);
+
+#define VPSS_CLKCTL 0x01C40044
+
+static void __iomem *vpss_clkctl_reg;
+
+/* TBD. Check what VENC_CLOCK_SEL settings for HDTV and EDTV */
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64 mode)
+{
+   int ret = 0;
+
+   if (NULL == vpss_clkctl_reg)
+   return -EINVAL;
+   switch (type) {
+   case VPBE_ENC_STD:
+   __raw_writel(0x18, vpss_clkctl_reg);
+   break;
+   case VPBE_ENC_DV_PRESET:
+   switch ((unsigned int)mode) {
+   case V4L2_DV_480P59_94:
+   case V4L2_DV_576P50:
+__raw_writel(0x19, vpss_clkctl_reg);
+   break;
+   case V4L2_DV_720P60:
+   case V4L2_DV_1080I60:
+   case V4L2_DV_1080P30:
+   /*
+* For HD, use external clock source since
+* HD requires higher clock rate
+*/
+   __raw_writel(0xa, vpss_clkctl_reg);
+   break;
+   default:
+   ret  = -EINVAL;
+   break;
+   }
+   break;
+   default:
+   ret  = -EINVAL;
+   }
+   return ret;
+}
+
+static inline u32 dm644x_reg_modify(void *reg, u32 val, u32 mask)
+{
+   u32 new_val = (__raw_readl(reg) & ~mask) | (val & mask);
+   __raw_writel(new_val, reg);
+   return new_val;
+}
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+   {
+   .start  = IRQ_VENCINT,
+   .end= IRQ_VENCINT,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = 0x01C724B8,
+   .end= 0x01C724B8 + 0x3,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device vpbe_v4l2_display = {
+   .name   = "vpbe-v4l2",
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+   .resource   = dm644x_v4l2_disp_resources,
+   .dev = {
+   .dma_mask   = &vpbe_display_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   },
+};
+
+struct venc_platform_data dm644x_venc_pdata = {
+   .venc_type  = DM644X_VPBE,
+   .setup_clock= dm644x_venc_setup_clock,
+};
+
+static struct platform_device dm644x_venc_dev = {
+   .name   = VPBE_VENC_SUBDEV_NAME,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_venc_resources),
+   .resource   = dm644x_venc_resources,
+   .dev = {
+   .dma_mask   = &dm644x_venc_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = &dm644x_venc_pdata,
+   },
+};
+
+static u64 dm644x_vpbe_dma_mask = DMA_BIT_MASK(32);
+
+static st

Re: [PATCHv8 00/12] Contiguous Memory Allocator

[Felipe Contreras]

On Thu, Dec 23, 2010 at 4:16 PM, Russell King - ARM Linux
 wrote:
> On Thu, Dec 23, 2010 at 03:04:07PM +0100, Tomasz Fujak wrote:
>> In other words, should we take your response as yet another NAK?
>> Or would you try harder and at least point us to some direction that
>> would not doom the effort from the very beginning.
>
> What the fsck do you think I've been doing?  This is NOT THE FIRST time
> I've raised this issue.  I gave up raising it after the first couple
> of attempts because I wasn't being listened to.
>
> You say about _me_ not being very helpful.  How about the CMA proponents
> start taking the issue I've raised seriously, and try to work out how
> to solve it?  And how about blaming them for the months of wasted time
> on this issue _because_ _they_ have chosen to ignore it?

I've also raised the issue for ARM. However, I don't see what is the
big problem.

A generic solution (that I think I already proposed) would be to
reserve a chunk of memory for the CMA that can be removed from the
normally mapped kernel memory through memblock at boot time. The size
of this memory region would be configurable through kconfig. Then, the
CMA would have a "dma" flag or something, and take chunks out of it
until there's no more, and then return errors. That would work for
ARM.

Cheers.

-- 
Felipe Contreras
--
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 2.6.37-rc8] V4L/RC fixes

[Mauro Carvalho Chehab]

Linus,

Please pull from:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
v4l_for_linus

For a series of fixes for V4L and RC. Most of the patches are due to a bug 
at the mceusb parser that weren't working with some MCE Remote Controller 
variants.
There are also some regressions and bugs at s5p-fimc driver and a few other
bugs at soc_camera/mx2_camera, nuvoton, lirc and streamzap drivers. 

Thanks!
Mauro

-

The following changes since commit 90a8a73c06cc32b609a880d48449d7083327e11a:

  Linux 2.6.37-rc7 (2010-12-21 11:26:40 -0800)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
v4l_for_linus

Baruch Siach (1):
  [media] mx2_camera: fix pixel clock polarity configuration

Dan Carpenter (2):
  [media] lirc_dev: stray unlock in lirc_dev_fop_poll()
  [media] lirc_dev: fixes in lirc_dev_fop_read()

Guennadi Liakhovetski (1):
  [media] soc-camera: fix static build of the sh_mobile_csi2.c driver

Jarod Wilson (10):
  [media] mceusb: add support for Conexant Hybrid TV RDU253S
  [media] nuvoton-cir: improve buffer parsing responsiveness
  [media] mceusb: fix up reporting of trailing space
  [media] mceusb: buffer parsing fixups for 1st-gen device
  [media] IR: add tv power scancode to rc6 mce keymap
  [media] mceusb: fix keybouce issue after parser simplification
  [media] streamzap: merge timeout space with trailing space
  [media] mceusb: add another Fintek device ID
  [media] mceusb: fix inverted mask inversion logic
  [media] mceusb: set a default rx timeout

Paul Bender (1):
  [media] rc: fix sysfs entry for mceusb and streamzap

Sylwester Nawrocki (6):
  [media] s5p-fimc: BKL lock removal - compilation fix
  [media] s5p-fimc: Fix vidioc_g_crop/cropcap on camera sensor
  [media] s5p-fimc: Explicitly add required header file
  [media] s5p-fimc: Convert m2m driver to unlocked_ioctl
  [media] s5p-fimc: Use correct fourcc code for 32-bit RGB format
  [media] s5p-fimc: Fix output DMA handling in S5PV310 IP revisions

 drivers/media/IR/keymaps/rc-rc6-mce.c   |   21 ++--
 drivers/media/IR/lirc_dev.c |   29 +++--
 drivers/media/IR/mceusb.c   |  174 +--
 drivers/media/IR/nuvoton-cir.c  |   10 ++-
 drivers/media/IR/streamzap.c|   21 ++--
 drivers/media/video/mx2_camera.c|2 -
 drivers/media/video/s5p-fimc/fimc-capture.c |   51 -
 drivers/media/video/s5p-fimc/fimc-core.c|   54 +
 drivers/media/video/s5p-fimc/fimc-core.h|   24 +++--
 drivers/media/video/s5p-fimc/regs-fimc.h|3 +
 drivers/media/video/sh_mobile_ceu_camera.c  |2 +-
 11 files changed, 257 insertions(+), 134 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: [PATCHv8 00/12] Contiguous Memory Allocator

[Russell King - ARM Linux]

On Thu, Dec 23, 2010 at 03:08:21PM +0100, Tomasz Fujak wrote:
> On 2010-12-23 14:51, Russell King - ARM Linux wrote:
> > On Thu, Dec 23, 2010 at 02:41:26PM +0100, Michal Nazarewicz wrote:
> >> Russell King - ARM Linux  writes:
> >>> Has anyone addressed my issue with it that this is wide-open for
> >>> abuse by allocating large chunks of memory, and then remapping
> >>> them in some way with different attributes, thereby violating the
> >>> ARM architecture specification?
> >>>
> >>> In other words, do we _actually_ have a use for this which doesn't
> >>> involve doing something like allocating 32MB of memory from it,
> >>> remapping it so that it's DMA coherent, and then performing DMA
> >>> on the resulting buffer?
> >> Huge pages.
> >>
> >> Also, don't treat it as coherent memory and just flush/clear/invalidate
> >> cache before and after each DMA transaction.  I never understood what's
> >> wrong with that approach.
> > If you've ever used an ARM system with a VIVT cache, you'll know what's
> > wrong with this approach.
> >
> > ARM systems with VIVT caches have extremely poor task switching
> > performance because they flush the entire data cache at every task switch
> > - to the extent that it makes system performance drop dramatically when
> > they become loaded.
> >
> > Doing that for every DMA operation will kill the advantage we've gained
> > from having VIPT caches and ASIDs stone dead.
> This statement effectively means: don't map dma-able memory to the CPU
> unless it's uncached. Have I missed anything?

I'll give you another solution to the problem - lobby ARM Ltd to have
this restriction lifted from the architecture specification, which
will probably result in the speculative prefetching also having to be
removed.

That would be my preferred solution if I had the power to do so, but
I have to live with what ARM Ltd (and their partners such as yourselves)
decide should end up in the architecture specification.
--
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: [PATCHv8 00/12] Contiguous Memory Allocator

[Russell King - ARM Linux]

On Thu, Dec 23, 2010 at 03:04:07PM +0100, Tomasz Fujak wrote:
> On 2010-12-23 14:48, Russell King - ARM Linux wrote:
> > On Thu, Dec 23, 2010 at 02:35:00PM +0100, Tomasz Fujak wrote:
> >> Dear Mr. King,
> >>
> >> AFAIK the CMA is the fourth attempt since 2008 taken to solve the
> >> multimedia memory allocation issue on some embedded devices. Most
> >> notably on ARM, that happens to be present in the SoCs we care about
> >> along the IOMMU-incapable multimedia IPs.
> >>
> >> I understand that you have your guidelines taken from the ARM
> >> specification, but this approach is not helping us.
> > I'm sorry you feel like that, but I'm living in reality.  If we didn't
> > have these architecture restrictions then we wouldn't have this problem
> > in the first place.
> Do we really have them, or just the documents say they exist?

Yes.  We have seen CPUs which lockup or crash as a result of mismatched
attributes in the page tables.

> > What I'm trying to do here is to ensure that we remain _legal_ to the
> > architecture specification - which for this issue means that we avoid
> > corrupting people's data.
> As legal as the mentioned dma_coherent?

See my other comment in an earlier email.  See the patch which prevents
ioremap() being used on system memory.  There is active movement at the
present time to sorting these violations out and find solutions for
them.

The last thing we need is a new API which introduces new violations.

> > Maybe you like having a system which randomly corrupts people's data?
> > I most certainly don't.  But that's the way CMA is heading at the moment
> > on ARM.
> Has this been experienced? I had some ARM-compatible boards on my desk
> (xscale, v6 and v7) and none of them crashed due to this behavior. And
> we *do* have multiple memory mappings, with different attributes.

Xscale doesn't suffer from the problem.  V6 doesn't aggressively speculate.
V7 speculates more aggressively, and corruption has been seen there.

> > It is not up to me to solve these problems - that's for the proposer of
> > the new API to do so.  So, please, don't try to lump this problem on
> > my shoulders.  It's not my problem to sort out.
> Just great. Nothing short of spectacular - this way the IA32 is going to
> take the embedded market piece by piece once the big two advance their
> foundry processes.

Look, I've been pointing out this problem ever since the very _first_
CMA patches were posted to the list, yet the CMA proponents have decided
to brush those problems aside each and every time I've raised them.

So, you should be asking _why_ the CMA proponents are choosing to ignore
this issue completely, rather than working to resolve it.

If it's resolved, then the problem goes away.

> In other words, should we take your response as yet another NAK?
> Or would you try harder and at least point us to some direction that
> would not doom the effort from the very beginning.

What the fsck do you think I've been doing?  This is NOT THE FIRST time
I've raised this issue.  I gave up raising it after the first couple
of attempts because I wasn't being listened to.

You say about _me_ not being very helpful.  How about the CMA proponents
start taking the issue I've raised seriously, and try to work out how
to solve it?  And how about blaming them for the months of wasted time
on this issue _because_ _they_ have chosen to ignore it?
--
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: [PATCHv8 00/12] Contiguous Memory Allocator

[Tomasz Fujak]

On 2010-12-23 14:51, Russell King - ARM Linux wrote:
> On Thu, Dec 23, 2010 at 02:41:26PM +0100, Michal Nazarewicz wrote:
>> Russell King - ARM Linux  writes:
>>> Has anyone addressed my issue with it that this is wide-open for
>>> abuse by allocating large chunks of memory, and then remapping
>>> them in some way with different attributes, thereby violating the
>>> ARM architecture specification?
>>>
>>> In other words, do we _actually_ have a use for this which doesn't
>>> involve doing something like allocating 32MB of memory from it,
>>> remapping it so that it's DMA coherent, and then performing DMA
>>> on the resulting buffer?
>> Huge pages.
>>
>> Also, don't treat it as coherent memory and just flush/clear/invalidate
>> cache before and after each DMA transaction.  I never understood what's
>> wrong with that approach.
> If you've ever used an ARM system with a VIVT cache, you'll know what's
> wrong with this approach.
>
> ARM systems with VIVT caches have extremely poor task switching
> performance because they flush the entire data cache at every task switch
> - to the extent that it makes system performance drop dramatically when
> they become loaded.
>
> Doing that for every DMA operation will kill the advantage we've gained
> from having VIPT caches and ASIDs stone dead.
This statement effectively means: don't map dma-able memory to the CPU
unless it's uncached. Have I missed anything?

> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv8 00/12] Contiguous Memory Allocator

[Tomasz Fujak]

On 2010-12-23 14:48, Russell King - ARM Linux wrote:
> On Thu, Dec 23, 2010 at 02:35:00PM +0100, Tomasz Fujak wrote:
>> Dear Mr. King,
>>
>> AFAIK the CMA is the fourth attempt since 2008 taken to solve the
>> multimedia memory allocation issue on some embedded devices. Most
>> notably on ARM, that happens to be present in the SoCs we care about
>> along the IOMMU-incapable multimedia IPs.
>>
>> I understand that you have your guidelines taken from the ARM
>> specification, but this approach is not helping us.
> I'm sorry you feel like that, but I'm living in reality.  If we didn't
> have these architecture restrictions then we wouldn't have this problem
> in the first place.
Do we really have them, or just the documents say they exist?
> What I'm trying to do here is to ensure that we remain _legal_ to the
> architecture specification - which for this issue means that we avoid
> corrupting people's data.
As legal as the mentioned dma_coherent?
> Maybe you like having a system which randomly corrupts people's data?
> I most certainly don't.  But that's the way CMA is heading at the moment
> on ARM.
Has this been experienced? I had some ARM-compatible boards on my desk
(xscale, v6 and v7) and none of them crashed due to this behavior. And
we *do* have multiple memory mappings, with different attributes.
> It is not up to me to solve these problems - that's for the proposer of
> the new API to do so.  So, please, don't try to lump this problem on
> my shoulders.  It's not my problem to sort out.
Just great. Nothing short of spectacular - this way the IA32 is going to
take the embedded market piece by piece once the big two advance their
foundry processes.
Despite having the translator, so much burden in the legacy ISA and the
fact that most of the embedded engineers from the high end are
accustomed to the ARM.

In other words, should we take your response as yet another NAK?
Or would you try harder and at least point us to some direction that
would not doom the effort from the very beginning.
I understand that the role of an oracle is so much easier, but the time
is running and devising subsequent solutions is not the use of
engineers' time.

Best regards
---
Tomasz Fujak

> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv8 00/12] Contiguous Memory Allocator

[Russell King - ARM Linux]

On Thu, Dec 23, 2010 at 02:41:26PM +0100, Michal Nazarewicz wrote:
> Russell King - ARM Linux  writes:
> > Has anyone addressed my issue with it that this is wide-open for
> > abuse by allocating large chunks of memory, and then remapping
> > them in some way with different attributes, thereby violating the
> > ARM architecture specification?
> >
> > In other words, do we _actually_ have a use for this which doesn't
> > involve doing something like allocating 32MB of memory from it,
> > remapping it so that it's DMA coherent, and then performing DMA
> > on the resulting buffer?
> 
> Huge pages.
> 
> Also, don't treat it as coherent memory and just flush/clear/invalidate
> cache before and after each DMA transaction.  I never understood what's
> wrong with that approach.

If you've ever used an ARM system with a VIVT cache, you'll know what's
wrong with this approach.

ARM systems with VIVT caches have extremely poor task switching
performance because they flush the entire data cache at every task switch
- to the extent that it makes system performance drop dramatically when
they become loaded.

Doing that for every DMA operation will kill the advantage we've gained
from having VIPT caches and ASIDs stone dead.
--
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: [PATCHv8 00/12] Contiguous Memory Allocator

[Russell King - ARM Linux]

On Thu, Dec 23, 2010 at 02:35:00PM +0100, Tomasz Fujak wrote:
> Dear Mr. King,
> 
> AFAIK the CMA is the fourth attempt since 2008 taken to solve the
> multimedia memory allocation issue on some embedded devices. Most
> notably on ARM, that happens to be present in the SoCs we care about
> along the IOMMU-incapable multimedia IPs.
> 
> I understand that you have your guidelines taken from the ARM
> specification, but this approach is not helping us.

I'm sorry you feel like that, but I'm living in reality.  If we didn't
have these architecture restrictions then we wouldn't have this problem
in the first place.

What I'm trying to do here is to ensure that we remain _legal_ to the
architecture specification - which for this issue means that we avoid
corrupting people's data.

Maybe you like having a system which randomly corrupts people's data?
I most certainly don't.  But that's the way CMA is heading at the moment
on ARM.

It is not up to me to solve these problems - that's for the proposer of
the new API to do so.  So, please, don't try to lump this problem on
my shoulders.  It's not my problem to sort out.
--
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: [PATCHv8 00/12] Contiguous Memory Allocator

[Russell King - ARM Linux]

On Thu, Dec 23, 2010 at 02:09:44PM +0100, Marek Szyprowski wrote:
> Hello,
> 
> On Thursday, December 23, 2010 1:19 PM Russell King - ARM Linux wrote:
> 
> > On Thu, Dec 23, 2010 at 11:58:08AM +0100, Marek Szyprowski wrote:
> > > Actually this contiguous memory allocator is a better replacement for
> > > alloc_pages() which is used by dma_alloc_coherent(). It is a generic
> > > framework that is not tied only to ARM architecture.
> > 
> > ... which is open to abuse.  What I'm trying to find out is - if it
> > can't be used for DMA, what is it to be used for?
> > 
> > Or are we inventing an everything-but-ARM framework?
> 
> We are trying to get something that really works and SOLVES some of the
> problems with real devices that require contiguous memory for DMA.

So, here you've confirmed that it's for DMA.

> > > > In other words, do we _actually_ have a use for this which doesn't
> > > > involve doing something like allocating 32MB of memory from it,
> > > > remapping it so that it's DMA coherent, and then performing DMA
> > > > on the resulting buffer?
> > >
> > > This is an arm specific problem, also related to dma_alloc_coherent()
> > > allocator. To be 100% conformant with ARM specification we would
> > > probably need to unmap all pages used by the dma_coherent allocator
> > > from the LOW MEM area. This is doable, but completely not related
> > > to the CMA and this patch series.
> > 
> > You've already been told why we can't unmap pages from the kernel
> > direct mapping.
> 
> It requires some amount of work but I see no reason why we shouldn't be
> able to unmap that pages to stay 100% conformant with ARM spec.

I have considered - and tried - to do that with the dma_alloc_coherent()
spec, but it is NOT POSSIBLE to do so - too many factors stand in the
way of making it work, such as the need bring the system to a complete
halt to modify all the L1 page tables and broadcast the TLB operations
to invalidate the old mappings.  None of that can be done from all the
contexts under which dma_alloc_coherent() is called from.

> Please notice that there are also use cases where the memory will not be
> accessed by the CPU at all (like DMA transfers between multimedia devices
> and the system memory).

Rubbish - if you think that, then you have very little understanding of
modern CPUs.  Modern CPUs speculatively access _any_ memory which is
visible to them, and as the ARM architecture progresses, the speculative
prefetching will become more aggressive.  So if you have memory mapped
in the kernel direct map, then you _have_ to assume that the CPU will
fire off accesses to that memory at any time, loading it into its cache.

> > Okay, so I'm just going to assume that CMA has _no_ _business_ being
> > used on ARM, and is not something that should interest anyone in the
> > ARM community.
> 
> Go ahead! Remeber to remove dma_coherent because it also breaks the spec. :)
> Oh, I forgot. We can also remove all device drivers that might use DMA. :)

The only solution I've come up for dma_alloc_coherent() is to reserve
the entire coherent DMA region at boot time, taking it out of the
kernel's view of available memory and thereby preventing it from ever
being mapped or the kernel using that memory for any other purpose.
That's about the best we can realistically do for ARM to conform to the
spec.

Every time I've brought this issue up with you, you've brushed it aside.
So if you feel that the right thing to do is to ignore such issues, you
won't be surprised if I keep opposing your efforts to get this into
mainline.

If you're serious about making this work, then provide some proper code
which shows how to use this for DMA on ARM systems without violating
the architecture specification.  Until you do, I see no hope that CMA
will ever be suitable for use on ARM.
--
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: [PATCHv8 00/12] Contiguous Memory Allocator

[Michal Nazarewicz]

Russell King - ARM Linux  writes:
> Has anyone addressed my issue with it that this is wide-open for
> abuse by allocating large chunks of memory, and then remapping
> them in some way with different attributes, thereby violating the
> ARM architecture specification?
>
> In other words, do we _actually_ have a use for this which doesn't
> involve doing something like allocating 32MB of memory from it,
> remapping it so that it's DMA coherent, and then performing DMA
> on the resulting buffer?

Huge pages.

Also, don't treat it as coherent memory and just flush/clear/invalidate
cache before and after each DMA transaction.  I never understood what's
wrong with that approach.

-- 
Best regards, _ _
 .o. | Liege of Serenly Enlightened Majesty of  o' \,=./ `o
 ..o | Computer Science,  Michal "mina86" Nazarewicz   (o o)
 ooo +--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL for 2.6.38] ivtv and cx18 fixes

[Andy Walls]

Mauro,

Please PULL what few changes I have presently for 2.6.38.  Any patches I
work over the Holidays, I don't think I can reasonably target for
2.6.38.

Merry Christmas.

Regards,
Andy
 

The following changes since commit dedb94adebe0fbdd9cafdbb170337810d8638bc9:

  [media] timblogiw: Fix a merge conflict with v4l2_i2c_new_subdev_board 
changes (2010-12-11 09:07:52 -0200)

are available in the git repository at:
  ssh://linuxtv.org/git/awalls/media_tree.git ivtv-cx18-for-38

Andy Walls (4):
  ivtv, cx18: Make ioremap failure messages more useful for users
  cx18: Only allocate a struct cx18_dvb for the DVB TS stream
  ivtv: ivtv_write_vbi() should use copy_from_user() for user data buffers
  ivtv: Return EFAULT when copy_from_user() fails in 
ivtv_write_vbi_from_user()

 drivers/media/video/cx18/cx18-driver.c  |9 ++-
 drivers/media/video/cx18/cx18-driver.h  |9 ++-
 drivers/media/video/cx18/cx18-dvb.c |   32 +
 drivers/media/video/cx18/cx18-mailbox.c |6 +-
 drivers/media/video/cx18/cx18-streams.c |   45 
 drivers/media/video/cx18/cx18-streams.h |3 +-
 drivers/media/video/ivtv/ivtv-driver.c  |   28 ++--
 drivers/media/video/ivtv/ivtv-fileops.c |4 +-
 drivers/media/video/ivtv/ivtv-vbi.c |  115 +--
 drivers/media/video/ivtv/ivtv-vbi.h |5 +-
 10 files changed, 174 insertions(+), 82 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: [PATCHv8 00/12] Contiguous Memory Allocator

[Tomasz Fujak]

Dear Mr. King,

AFAIK the CMA is the fourth attempt since 2008 taken to solve the
multimedia memory allocation issue on some embedded devices. Most
notably on ARM, that happens to be present in the SoCs we care about
along the IOMMU-incapable multimedia IPs.

I understand that you have your guidelines taken from the ARM
specification, but this approach is not helping us. The mainline kernel
is server- and desktop-centric for various reasons I am not going to
dwell into. We're trying hard to solve the physical memory fragmentation
issue for some time now, only to hear "this is not acceptable, go
somewhere else". So we did - the CMA is targeted towards mm, NOT the
ARM. While I do not exactly know how you see your role in ARM kernel
development, we have shown a few times that this issue is important for
us, and we'd like to solve it. So if you could give a glimpse of what is
acceptable, given the existing circumstances, we could possibly help
developing that solution. Namely:
1. ARM-compatible SoC
2. Multimedia IP blocks requiring large amounts of contiguous memory
2. No IOMMU or SG in said blocks
4. Unused memory reserved for said multimedia drivers should  be used by
the kernel
5. Multimedia allocation scenarios must always be working (under some
constraints of course), within sane time limit
6. The solution shall have minimal delta to upstream linux (none?)

While the obvious CMA uses are the ones you'd mostly like to avoid, we
haven't tried to post anything like that along.
This way no obvious spec abuse is made, and we minimize the delta to the
upstream - it's even better than current state, when you have dma
coherent memory doing exactly what you claim is forbidden (unpredictable
results could possibly happen).

As the feedback from the first CMA patches confirm, the issue we're
trying to solve here is real. Yet no real solution exists to my
knowledge. I understand the ARM holding my try to just wait till all the
relevant chips do have an IOMMU, but here and now there is a SOC we are
going to use. No IMOMMU, no SG. So would you please help us - or if for
some reason you can't, just not make our work any harder?

BTW why is the lowmem unmap not feasible? Is it the section entries in
the page tables scattered throughout the system? I was unable to find
the answer so far.

Best regards
-- 
Tomasz Fujak
Samsung Electronics Poland R&D

On 2010-12-23 13:19, Russell King - ARM Linux wrote:
> On Thu, Dec 23, 2010 at 11:58:08AM +0100, Marek Szyprowski wrote:
>> Actually this contiguous memory allocator is a better replacement for
>> alloc_pages() which is used by dma_alloc_coherent(). It is a generic
>> framework that is not tied only to ARM architecture.
> ... which is open to abuse.  What I'm trying to find out is - if it
> can't be used for DMA, what is it to be used for?
>
> Or are we inventing an everything-but-ARM framework?
>
>>> In other words, do we _actually_ have a use for this which doesn't
>>> involve doing something like allocating 32MB of memory from it,
>>> remapping it so that it's DMA coherent, and then performing DMA
>>> on the resulting buffer?
>> This is an arm specific problem, also related to dma_alloc_coherent()
>> allocator. To be 100% conformant with ARM specification we would
>> probably need to unmap all pages used by the dma_coherent allocator
>> from the LOW MEM area. This is doable, but completely not related
>> to the CMA and this patch series.
> You've already been told why we can't unmap pages from the kernel
> direct mapping.
>
> Okay, so I'm just going to assume that CMA has _no_ _business_ being
> used on ARM, and is not something that should interest anyone in the
> ARM community.
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

--
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: [PATCHv8 00/12] Contiguous Memory Allocator

[Marek Szyprowski]

Hello,

On Thursday, December 23, 2010 1:19 PM Russell King - ARM Linux wrote:

> On Thu, Dec 23, 2010 at 11:58:08AM +0100, Marek Szyprowski wrote:
> > Actually this contiguous memory allocator is a better replacement for
> > alloc_pages() which is used by dma_alloc_coherent(). It is a generic
> > framework that is not tied only to ARM architecture.
> 
> ... which is open to abuse.  What I'm trying to find out is - if it
> can't be used for DMA, what is it to be used for?
> 
> Or are we inventing an everything-but-ARM framework?

We are trying to get something that really works and SOLVES some of the
problems with real devices that require contiguous memory for DMA.

> > > In other words, do we _actually_ have a use for this which doesn't
> > > involve doing something like allocating 32MB of memory from it,
> > > remapping it so that it's DMA coherent, and then performing DMA
> > > on the resulting buffer?
> >
> > This is an arm specific problem, also related to dma_alloc_coherent()
> > allocator. To be 100% conformant with ARM specification we would
> > probably need to unmap all pages used by the dma_coherent allocator
> > from the LOW MEM area. This is doable, but completely not related
> > to the CMA and this patch series.
> 
> You've already been told why we can't unmap pages from the kernel
> direct mapping.

It requires some amount of work but I see no reason why we shouldn't be
able to unmap that pages to stay 100% conformant with ARM spec.

Please notice that there are also use cases where the memory will not be
accessed by the CPU at all (like DMA transfers between multimedia devices
and the system memory).

> Okay, so I'm just going to assume that CMA has _no_ _business_ being
> used on ARM, and is not something that should interest anyone in the
> ARM community.

Go ahead! Remeber to remove dma_coherent because it also breaks the spec. :)
Oh, I forgot. We can also remove all device drivers that might use DMA. :)



Merry Christmas and Happy New Year for everyone! :)

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal

[Hans Verkuil]

On Thursday, December 23, 2010 14:04:38 Andy Walls wrote:
> On Thu, 2010-12-23 at 10:02 +0100, Laurent Pinchart wrote:
> > Hi Hans,
> > 
> > On Monday 20 December 2010 14:09:40 Hans Verkuil wrote:
> > > On Monday, December 20, 2010 13:48:51 Laurent Pinchart wrote:
> > > >
> > > > What if the application wants to change the resolution during capture ?
> > > > It will have to stop capture, call REQBUFS(0), change the format,
> > > > request buffers and restart capture. If filehandle ownership is dropped
> > > > after REQBUFS(0) that will open the door to a race condition.
> > > 
> > > That's why S_PRIORITY was invented.
> > 
> > Right, I should implement that. I think the documentation isn't clear 
> > though. 
> > What is the background priority for exactly ? 
> 
> http://linuxtv.org/downloads/v4l-dvb-apis/app-pri.html
> 
> "Another objective is to permit low priority applications working in
> background, which can be preempted by user controlled applications and
> automatically regain control of the device at a later time."
> 
> 
> A use case would be for a daemon that does background channel scanning
> or VBI data collection when the user isn't doing something else with the
> video device.
> 
> For a camera, maybe it would be an application that does device health
> monitoring, some sort of continuous calibration, or motion detection
> when the device isn't in use by the user for viewing.
> 
> 
> > And the "unset" priority ?
> 
> When checking for the maximum priority in use, it indicates that no
> nodes have any priorities. See v4l2_prio_max().  For a driver that
> supports priorities, it means no device nodes are opened, since any
> device node being open would get a priority of
> V4L2_PRIORITY_INTERACTIVE/_DEFAULT by default in v4l2_prio_open().
> 
> V4L2_PRIORITY_UNSET is also used to indicate to the v4l2_prio_*()
> functions that a struct v4l2_prio_state hasn't been initialized (i.e.
> has just been kzalloc()'ed).
> 
> > Are 
> > other applications allowed to change controls when an application has the 
> > record priority ?
> 
> According to the spec, no:
> 
> "V4L2_PRIORITY_RECORD 3 Highest priority. Only one file descriptor can
> have this priority, it blocks any other fd from changing device
> properties."
> 
> Once an automated, scheduled-recording process is recording, one really
> wouldn't want another process changing them.  I personally would not
> like unpredictable volume level variations on my TV show recordings.
> 
> 
> In cx18-controls.c one can find an implementation example for the old
> control framework:
> 
> int cx18_s_ext_ctrls(struct file *file, void *fh, struct 
> v4l2_ext_controls *c)
> {   
> struct cx18_open_id *id = fh;   
> struct cx18 *cx = id->cx;   
> int ret;
> struct v4l2_control ctrl;   
> 
> ret = v4l2_prio_check(&cx->prio, id->prio);
> if (ret)
> return ret;
> [...]
> 
> However, the new control framework in v4l2-ctrl.c seems to be missing
> any v4l2_prio_check() calls. The ioctl() handling in v4l2-ioctl.c
> doesn't have any either.

Oops, I'd forgotten about that. The priority support really should be
moved into the v4l2 core framework where it belongs. I'll see if I can spend
some time on that after Christmas.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal

[Andy Walls]

On Thu, 2010-12-23 at 10:02 +0100, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Monday 20 December 2010 14:09:40 Hans Verkuil wrote:
> > On Monday, December 20, 2010 13:48:51 Laurent Pinchart wrote:
> > >
> > > What if the application wants to change the resolution during capture ?
> > > It will have to stop capture, call REQBUFS(0), change the format,
> > > request buffers and restart capture. If filehandle ownership is dropped
> > > after REQBUFS(0) that will open the door to a race condition.
> > 
> > That's why S_PRIORITY was invented.
> 
> Right, I should implement that. I think the documentation isn't clear though. 
> What is the background priority for exactly ? 

http://linuxtv.org/downloads/v4l-dvb-apis/app-pri.html

"Another objective is to permit low priority applications working in
background, which can be preempted by user controlled applications and
automatically regain control of the device at a later time."


A use case would be for a daemon that does background channel scanning
or VBI data collection when the user isn't doing something else with the
video device.

For a camera, maybe it would be an application that does device health
monitoring, some sort of continuous calibration, or motion detection
when the device isn't in use by the user for viewing.


> And the "unset" priority ?

When checking for the maximum priority in use, it indicates that no
nodes have any priorities. See v4l2_prio_max().  For a driver that
supports priorities, it means no device nodes are opened, since any
device node being open would get a priority of
V4L2_PRIORITY_INTERACTIVE/_DEFAULT by default in v4l2_prio_open().

V4L2_PRIORITY_UNSET is also used to indicate to the v4l2_prio_*()
functions that a struct v4l2_prio_state hasn't been initialized (i.e.
has just been kzalloc()'ed).

> Are 
> other applications allowed to change controls when an application has the 
> record priority ?

According to the spec, no:

"V4L2_PRIORITY_RECORD 3 Highest priority. Only one file descriptor can
have this priority, it blocks any other fd from changing device
properties."

Once an automated, scheduled-recording process is recording, one really
wouldn't want another process changing them.  I personally would not
like unpredictable volume level variations on my TV show recordings.


In cx18-controls.c one can find an implementation example for the old
control framework:

int cx18_s_ext_ctrls(struct file *file, void *fh, struct 
v4l2_ext_controls *c)
{   
struct cx18_open_id *id = fh;   
struct cx18 *cx = id->cx;   
int ret;
struct v4l2_control ctrl;   

ret = v4l2_prio_check(&cx->prio, id->prio);
if (ret)
return ret;
[...]

However, the new control framework in v4l2-ctrl.c seems to be missing
any v4l2_prio_check() calls. The ioctl() handling in v4l2-ioctl.c
doesn't have any either.


> In general I find the priority ioctls underspecified, that's why I haven't 
> implemented them yet.

Yes, it appears some of the details should be gleaned from the existing
driver implementations before they are/were converted to the new control
framework.

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv8 00/12] Contiguous Memory Allocator

[Russell King - ARM Linux]

On Thu, Dec 23, 2010 at 11:58:08AM +0100, Marek Szyprowski wrote:
> Actually this contiguous memory allocator is a better replacement for
> alloc_pages() which is used by dma_alloc_coherent(). It is a generic
> framework that is not tied only to ARM architecture.

... which is open to abuse.  What I'm trying to find out is - if it
can't be used for DMA, what is it to be used for?

Or are we inventing an everything-but-ARM framework?

> > In other words, do we _actually_ have a use for this which doesn't
> > involve doing something like allocating 32MB of memory from it,
> > remapping it so that it's DMA coherent, and then performing DMA
> > on the resulting buffer?
> 
> This is an arm specific problem, also related to dma_alloc_coherent()
> allocator. To be 100% conformant with ARM specification we would
> probably need to unmap all pages used by the dma_coherent allocator
> from the LOW MEM area. This is doable, but completely not related
> to the CMA and this patch series.

You've already been told why we can't unmap pages from the kernel
direct mapping.

Okay, so I'm just going to assume that CMA has _no_ _business_ being
used on ARM, and is not something that should interest anyone in the
ARM community.
--
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 v10 5/8] davinci vpbe: platform specific additions-khilman

[Sergei Shtylyov]

Hello.

On 23-12-2010 14:54, Manjunath Hadli wrote:


This patch implements the overall device creation for the Video
display driver



Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil

[...]


diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..02ec74b 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -654,6 +654,146 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)

[...]

+/* TBD. Check what VENC_CLOCK_SEL settings for HDTV and EDTV */
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64 mode)
+{
+   int ret = 0;
+
+   if (NULL == vpss_clkctl_reg)
+   return -EINVAL;
+   switch (type) {
+   case VPBE_ENC_STD:
+   __raw_writel(0x18, vpss_clkctl_reg);
+   break;
+   case VPBE_ENC_DV_PRESET:
+   switch ((unsigned int)mode) {
+   case V4L2_DV_480P59_94:
+   case V4L2_DV_576P50:
+__raw_writel(0x19, vpss_clkctl_reg);
+   break;
+   case V4L2_DV_720P60:
+   case V4L2_DV_1080I60:
+   case V4L2_DV_1080P30:
+   /*
+* For HD, use external clock source since HD requires higher
+* clock rate
+*/


   Indent the comment correctly, please.


+   __raw_writel(0xa, vpss_clkctl_reg);
+   break;
+   default:
+   ret  = -EINVAL;
+   break;
+   }
+   break;
+   default:
+   ret  = -EINVAL;
+   }
+   return ret;
+}

[...]

+static struct resource dm644x_v4l2_disp_resources[] = {
+   {
+   .start  = IRQ_VENCINT,
+   .end= IRQ_VENCINT,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = 0x01C724B8,
+   .end= 0x01C724B8 + 0x4,


   s/0x4/0x3/?

[...]

+static struct platform_device dm644x_venc_dev = {
+   .name   = VPBE_VENC_SUBDEV_NAME,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_venc_resources),
+   .resource   = dm644x_venc_resources,
+   .dev = {
+   .dma_mask   =&dm644x_venc_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = (void *)&dm644x_venc_pdata,


   There's no need to explicitly cast to 'void *'.

WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v10 0/8] davinci vpbe: dm6446 v4l2 driver

[Hadli, Manjunath]

On Thu, Dec 23, 2010 at 17:23:37, Hadli, Manjunath wrote:
> version10: addressed Kevin's and Sergei's comments
> on:
> 1.Lines spacing.
> 2.Language errors
  3.Now based on Kevin Hilman's tree :)
> 
> Manjunath Hadli (8):
>   davinci vpbe: V4L2 display driver for DM644X SoC
>   davinci vpbe: VPBE display driver
>   davinci vpbe: OSD(On Screen Display) block
>   davinci vpbe: VENC( Video Encoder) implementation
>   davinci vpbe: platform specific additions-khilman
>   davinci vpbe: board specific additions
>   davinci vpbe: Build infrastructure for VPBE driver
>   davinci vpbe: Readme text for Dm6446 vpbe
> 
>  Documentation/video4linux/README.davinci-vpbe |   93 ++
>  arch/arm/mach-davinci/board-dm644x-evm.c  |   81 +-
>  arch/arm/mach-davinci/dm644x.c|  172 ++-
>  arch/arm/mach-davinci/include/mach/dm644x.h   |4 +
>  drivers/media/video/davinci/Kconfig   |   22 +
>  drivers/media/video/davinci/Makefile  |2 +
>  drivers/media/video/davinci/vpbe.c|  836 ++
>  drivers/media/video/davinci/vpbe_display.c| 2099 
> +
>  drivers/media/video/davinci/vpbe_osd.c| 1211 ++
>  drivers/media/video/davinci/vpbe_osd_regs.h   |  389 +
>  drivers/media/video/davinci/vpbe_venc.c   |  568 +++
>  drivers/media/video/davinci/vpbe_venc_regs.h  |  189 +++
>  include/media/davinci/vpbe.h  |  186 +++
>  include/media/davinci/vpbe_display.h  |  146 ++
>  include/media/davinci/vpbe_osd.h  |  397 +
>  include/media/davinci/vpbe_types.h|   93 ++
>  include/media/davinci/vpbe_venc.h |   38 +
>  17 files changed, 6505 insertions(+), 21 deletions(-)  create mode 100644 
> Documentation/video4linux/README.davinci-vpbe
>  create mode 100644 drivers/media/video/davinci/vpbe.c
>  create mode 100644 drivers/media/video/davinci/vpbe_display.c
>  create mode 100644 drivers/media/video/davinci/vpbe_osd.c
>  create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
>  create mode 100644 drivers/media/video/davinci/vpbe_venc.c
>  create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
>  create mode 100644 include/media/davinci/vpbe.h  create mode 100644 
> include/media/davinci/vpbe_display.h
>  create mode 100644 include/media/davinci/vpbe_osd.h  create mode 100644 
> include/media/davinci/vpbe_types.h
>  create mode 100644 include/media/davinci/vpbe_venc.h
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 8/8] davinci vpbe: Readme text for Dm6446 vpbe

[Manjunath Hadli]

Please refer to this file for detailed documentation of
davinci vpbe v4l2 driver

Signed-off-by: Manjunath Hadli 
Acked-by: Muralidharan Karicheri 
Acked-by: Hans Verkuil 
---
 Documentation/video4linux/README.davinci-vpbe |   93 +
 1 files changed, 93 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/video4linux/README.davinci-vpbe

diff --git a/Documentation/video4linux/README.davinci-vpbe 
b/Documentation/video4linux/README.davinci-vpbe
new file mode 100644
index 000..7a460b0
--- /dev/null
+++ b/Documentation/video4linux/README.davinci-vpbe
@@ -0,0 +1,93 @@
+
+VPBE V4L2 driver design
+ ==
+
+ File partitioning
+ -
+ V4L2 display device driver
+ drivers/media/video/davinci/vpbe_display.c
+ drivers/media/video/davinci/vpbe_display.h
+
+ VPBE display controller
+ drivers/media/video/davinci/vpbe.c
+ drivers/media/video/davinci/vpbe.h
+
+ VPBE venc sub device driver
+ drivers/media/video/davinci/vpbe_venc.c
+ drivers/media/video/davinci/vpbe_venc.h
+ drivers/media/video/davinci/vpbe_venc_regs.h
+
+ VPBE osd driver
+ drivers/media/video/davinci/vpbe_osd.c
+ drivers/media/video/davinci/vpbe_osd.h
+ drivers/media/video/davinci/vpbe_osd_regs.h
+
+ Functional partitioning
+ ---
+
+ Consists of the following (in the same order as the list under file
+ partitioning):-
+
+ 1. V4L2 display driver
+Implements creation of video2 and video3 device nodes and
+provides v4l2 device interface to manage VID0 and VID1 layers.
+
+ 2. Display controller
+Loads up VENC, OSD and external encoders such as ths8200. It provides
+a set of API calls to V4L2 drivers to set the output/standards
+in the VENC or external sub devices. It also provides
+a device object to access the services from OSD subdevice
+using sub device ops. The connection of external encoders to VENC LCD
+controller port is done at init time based on default output and standard
+selection or at run time when application change the output through
+V4L2 IOCTLs.
+
+When connected to an external encoder, vpbe controller is also responsible
+for setting up the interface between VENC and external encoders based on
+board specific settings (specified in board-xxx-evm.c). This allows
+interfacing external encoders such as ths8200. The setup_if_config()
+is implemented for this as well as configure_venc() (part of the next 
patch)
+API to set timings in VENC for a specific display resolution. As of this
+patch series, the interconnection and enabling and setting of the external
+encoders is not present, and would be a part of the next patch series.
+
+ 3. VENC subdevice module
+Responsible for setting outputs provided through internal DACs and also
+setting timings at LCD controller port when external encoders are connected
+at the port or LCD panel timings required. When external encoder/LCD panel
+is connected, the timings for a specific standard/preset is retrieved from
+the board specific table and the values are used to set the timings in
+venc using non-standard timing mode.
+
+Support LCD Panel displays using the VENC. For example to support a Logic
+PD display, it requires setting up the LCD controller port with a set of
+timings for the resolution supported and setting the dot clock. So we could
+add the available outputs as a board specific entry (i.e add the "LogicPD"
+output name to board-xxx-evm.c). A table of timings for various LCDs
+supported can be maintained in the board specific setup file to support
+various LCD displays.As of this patch a basic driver is present, and this
+support for external encoders and displays forms a part of the next
+patch series.
+
+ 4. OSD module
+OSD module implements all OSD layer management and hardware specific
+features. The VPBE module interacts with the OSD for enabling and
+disabling appropriate features of the OSD.
+
+ Current status:-
+
+ A fully functional working version of the V4L2 driver is available. This
+ driver has been tested with NTSC and PAL standards and buffer streaming.
+
+ Following are TBDs.
+
+ vpbe display controller
+- Add support for external encoders.
+- add support for selecting external encoder as default at probe time.
+
+ vpbe venc sub device
+- add timings for supporting ths8200
+- add support for LogicPD LCD.
+
+ FB drivers
+- Add support for fbdev drivers.- Ready and part of subsequent patches.
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 3/8] davinci vpbe: OSD(On Screen Display) block

[Manjunath Hadli]

This patch implements the functionality of the OSD block
of the VPBE.The OSD in total supports 4 planes or Video
sources - 2 mainly RGB and 2 Video. The patch implements general
handling of all the planes, with specific emphasis on the Video
plane capabilities as the Video planes are supported through the
V4L2 driver.

Signed-off-by: Manjunath Hadli 
Acked-by: Muralidharan Karicheri 
Acked-by: Hans Verkuil 
---
 drivers/media/video/davinci/vpbe_osd.c  | 1211 +++
 drivers/media/video/davinci/vpbe_osd_regs.h |  389 +
 include/media/davinci/vpbe_osd.h|  397 +
 3 files changed, 1997 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpbe_osd.c
 create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
 create mode 100644 include/media/davinci/vpbe_osd.h

diff --git a/drivers/media/video/davinci/vpbe_osd.c 
b/drivers/media/video/davinci/vpbe_osd.c
new file mode 100644
index 000..2599c83
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_osd.c
@@ -0,0 +1,1211 @@
+/*
+ * Copyright (C) 2007-2010 Texas Instruments Inc
+ * Copyright (C) 2007 MontaVista Software, Inc.
+ *
+ * Andy Lowe (al...@mvista.com), MontaVista Software
+ * - Initial version
+ * Murali Karicheri (mkarich...@gmail.com), Texas Instruments Ltd.
+ * - ported to sub device interface
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "vpbe_osd_regs.h"
+
+#define MODULE_NAMEVPBE_OSD_SUBDEV_NAME
+
+/* register access routines */
+static inline u32 osd_read(struct osd_state *sd, u32 offset)
+{
+   struct osd_state *osd = sd;
+   return __raw_readl(osd->osd_base + offset);
+}
+
+static inline u32 osd_write(struct osd_state *sd, u32 val, u32 offset)
+{
+   struct osd_state *osd = sd;
+   __raw_writel(val, osd->osd_base + offset);
+   return val;
+}
+
+static inline u32 osd_set(struct osd_state *sd, u32 mask, u32 offset)
+{
+   struct osd_state *osd = sd;
+
+   u32 addr = osd->osd_base + offset;
+   u32 val = __raw_readl(addr) | mask;
+
+   __raw_writel(val, addr);
+   return val;
+}
+
+static inline u32 osd_clear(struct osd_state *sd, u32 mask, u32 offset)
+{
+   struct osd_state *osd = sd;
+   u32 addr = osd->osd_base + offset;
+   u32 val = __raw_readl(addr) & ~mask;
+
+   __raw_writel(val, addr);
+   return val;
+}
+
+static inline u32 osd_modify(struct osd_state *sd, u32 mask, u32 val,
+u32 offset)
+{
+   struct osd_state *osd = sd;
+
+   u32 addr = osd->osd_base + offset;
+   u32 new_val = (__raw_readl(addr) & ~mask) | (val & mask);
+   __raw_writel(new_val, addr);
+   return new_val;
+}
+
+/* define some macros for layer and pixfmt classification */
+#define is_osd_win(layer) (((layer) == WIN_OSD0) || ((layer) == WIN_OSD1))
+#define is_vid_win(layer) (((layer) == WIN_VID0) || ((layer) == WIN_VID1))
+#define is_rgb_pixfmt(pixfmt) \
+   (((pixfmt) == PIXFMT_RGB565) || ((pixfmt) == PIXFMT_RGB888))
+#define is_yc_pixfmt(pixfmt) \
+   (((pixfmt) == PIXFMT_YCbCrI) || ((pixfmt) == PIXFMT_YCrCbI) || \
+   ((pixfmt) == PIXFMT_NV12))
+#define MAX_WIN_SIZE OSD_VIDWIN0XP_V0X
+#define MAX_LINE_LENGTH (OSD_VIDWIN0OFST_V0LO << 5)
+
+
+/**
+ * _osd_dm6446_vid0_pingpong() - field inversion fix for DM6446
+ * @sd - ptr to struct osd_state
+ * @field_inversion - inversion flag
+ * @fb_base_phys - frame buffer address
+ * @lconfig - ptr to layer config
+ *
+ * This routine implements a workaround for the field signal inversion silicon
+ * erratum described in Advisory 1.3.8 for the DM6446.  The fb_base_phys and
+ * lconfig parameters apply to the vid0 window.  This routine should be called
+ * whenever the vid0 layer configuration or start address is modified, or when
+ * the OSD field inversion setting is modified.
+ * Returns: 1 if the ping-pong buffers need to be toggled in the vsync isr, or
+ *  0 otherwise
+ */
+static int _osd_dm6446_vid0_pingpong(struct osd_state *sd,
+int field_inversion,
+unsigned long fb_base_phys,
+  

[PATCH v10 7/8] davinci vpbe: Build infrastructure for VPBE driver

[Manjunath Hadli]

This patch adds the build infra-structure for Davinci
VPBE dislay driver

Signed-off-by: Manjunath Hadli 
Acked-by: Muralidharan Karicheri 
Acked-by: Hans Verkuil 
---
 drivers/media/video/davinci/Kconfig  |   22 ++
 drivers/media/video/davinci/Makefile |2 ++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/davinci/Kconfig 
b/drivers/media/video/davinci/Kconfig
index 6b19540..a7f11e7 100644
--- a/drivers/media/video/davinci/Kconfig
+++ b/drivers/media/video/davinci/Kconfig
@@ -91,3 +91,25 @@ config VIDEO_ISIF
 
   To compile this driver as a module, choose M here: the
   module will be called vpfe.
+
+config VIDEO_DM644X_VPBE
+   tristate "DM644X VPBE HW module"
+   select VIDEO_VPSS_SYSTEM
+   select VIDEOBUF_DMA_CONTIG
+   help
+   Enables VPBE modules used for display on a DM644x
+   SoC.
+
+   To compile this driver as a module, choose M here: the
+   module will be called vpbe.
+
+
+config VIDEO_VPBE_DISPLAY
+   tristate "VPBE V4L2 Display driver"
+   select VIDEO_DM644X_VPBE
+   default y
+   help
+   Enables VPBE V4L2 Display driver on a DMXXX device
+
+   To compile this driver as a module, choose M here: the
+   module will be called vpbe_display.
diff --git a/drivers/media/video/davinci/Makefile 
b/drivers/media/video/davinci/Makefile
index a379557..ae7dafb 100644
--- a/drivers/media/video/davinci/Makefile
+++ b/drivers/media/video/davinci/Makefile
@@ -16,3 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o
 obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o
 obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o
 obj-$(CONFIG_VIDEO_ISIF) += isif.o
+obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o
+obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 6/8] davinci vpbe: board specific additions

[Manjunath Hadli]

This patch implements tables for display timings,outputs and
other board related functionalities.

Signed-off-by: Manjunath Hadli 
Acked-by: Muralidharan Karicheri 
Acked-by: Hans Verkuil 

---
 arch/arm/mach-davinci/board-dm644x-evm.c |   81 +-
 1 files changed, 68 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 0ca90b8..27facba 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -176,18 +176,6 @@ static struct platform_device davinci_evm_nandflash_device 
= {
.resource   = davinci_evm_nandflash_resource,
 };
 
-static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device davinci_fb_device = {
-   .name   = "davincifb",
-   .id = -1,
-   .dev = {
-   .dma_mask   = &davinci_fb_dma_mask,
-   .coherent_dma_mask  = DMA_BIT_MASK(32),
-   },
-   .num_resources = 0,
-};
-
 static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -616,8 +604,73 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
 }
 
+#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* venc standards timings */
+static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = {
+   {"ntsc", VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480,
+   {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0},
+   {"pal", VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576,
+   {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0},
+};
+
+/* venc dv preset timings */
+static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = {
+   {"480p59_94", VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480,
+   {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0},
+   {"576p50", VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576,
+   {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0},
+};
+
+/*
+ * The outputs available from VPBE + encoders. Keep the order same
+ * as that of encoders. First that from venc followed by that from
+ * encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm644x_vpbe_outputs[] = {
+   {
+   .output = {
+   .index = 0,
+   .name = "Composite",
+   .type = V4L2_OUTPUT_TYPE_ANALOG,
+   .std = VENC_STD_ALL,
+   .capabilities = V4L2_OUT_CAP_STD,
+   },
+   .subdev_name = VPBE_VENC_SUBDEV_NAME,
+   .default_mode = "ntsc",
+   .num_modes = ARRAY_SIZE(vbpe_enc_std_timings),
+   .modes = vbpe_enc_std_timings,
+   },
+   {
+   .output = {
+   .index = 1,
+   .name = "Component",
+   .type = V4L2_OUTPUT_TYPE_ANALOG,
+   .capabilities = V4L2_OUT_CAP_PRESETS,
+   },
+   .subdev_name = VPBE_VENC_SUBDEV_NAME,
+   .default_mode = "480p59_94",
+   .num_modes = ARRAY_SIZE(vbpe_enc_preset_timings),
+   .modes = vbpe_enc_preset_timings,
+   },
+};
+
+static struct vpbe_display_config vpbe_display_cfg = {
+   .module_name = "dm644x-vpbe-display",
+   .i2c_adapter_id = 1,
+   .osd = {
+   .module_name = VPBE_OSD_SUBDEV_NAME,
+   },
+   .venc = {
+   .module_name = VPBE_VENC_SUBDEV_NAME,
+   },
+   .num_outputs = ARRAY_SIZE(dm644x_vpbe_outputs),
+   .outputs = dm644x_vpbe_outputs,
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
-   &davinci_fb_device,
&rtc_dev,
 };
 
@@ -630,6 +683,8 @@ davinci_evm_map_io(void)
 {
/* setup input configuration for VPFE input devices */
dm644x_set_vpfe_config(&vpfe_cfg);
+   /* setup configuration for vpbe devices */
+   dm644x_set_vpbe_display_config(&vpbe_display_cfg);
dm644x_init();
 }
 
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 5/8] davinci vpbe: platform specific additions-khilman

[Manjunath Hadli]

This patch implements the overall device creation for the Video
display driver

Signed-off-by: Manjunath Hadli 
Acked-by: Muralidharan Karicheri 
Acked-by: Hans Verkuil 
---
 arch/arm/mach-davinci/dm644x.c  |  172 +--
 arch/arm/mach-davinci/include/mach/dm644x.h |4 +
 2 files changed, 168 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..02ec74b 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -654,6 +654,146 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
 }
 
+static struct resource dm644x_osd_resources[] = {
+   {
+   .start  = 0x01C72600,
+   .end= 0x01C72600 + 0x1ff,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm644x_osd_dev = {
+   .name   = VPBE_OSD_SUBDEV_NAME,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_osd_resources),
+   .resource   = dm644x_osd_resources,
+   .dev = {
+   .dma_mask   = &dm644x_osd_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = (void *)DM644X_VPBE,
+   },
+};
+
+static struct resource dm644x_venc_resources[] = {
+   /* venc registers io space */
+   {
+   .start  = 0x01C72400,
+   .end= 0x01C72400 + 0x17f,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32);
+
+#define VPSS_CLKCTL 0x01C40044
+
+static void __iomem *vpss_clkctl_reg;
+
+/* TBD. Check what VENC_CLOCK_SEL settings for HDTV and EDTV */
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64 mode)
+{
+   int ret = 0;
+
+   if (NULL == vpss_clkctl_reg)
+   return -EINVAL;
+   switch (type) {
+   case VPBE_ENC_STD:
+   __raw_writel(0x18, vpss_clkctl_reg);
+   break;
+   case VPBE_ENC_DV_PRESET:
+   switch ((unsigned int)mode) {
+   case V4L2_DV_480P59_94:
+   case V4L2_DV_576P50:
+__raw_writel(0x19, vpss_clkctl_reg);
+   break;
+   case V4L2_DV_720P60:
+   case V4L2_DV_1080I60:
+   case V4L2_DV_1080P30:
+   /*
+* For HD, use external clock source since HD requires higher
+* clock rate
+*/
+   __raw_writel(0xa, vpss_clkctl_reg);
+   break;
+   default:
+   ret  = -EINVAL;
+   break;
+   }
+   break;
+   default:
+   ret  = -EINVAL;
+   }
+   return ret;
+}
+
+static inline u32 dm644x_reg_modify(void *reg, u32 val, u32 mask)
+{
+   u32 new_val = (__raw_readl(reg) & ~mask) | (val & mask);
+   __raw_writel(new_val, reg);
+   return new_val;
+}
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+   {
+   .start  = IRQ_VENCINT,
+   .end= IRQ_VENCINT,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = 0x01C724B8,
+   .end= 0x01C724B8 + 0x4,
+   .flags  = IORESOURCE_MEM,
+   },
+
+};
+
+static struct platform_device vpbe_v4l2_display = {
+   .name   = "vpbe-v4l2",
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+   .resource   = dm644x_v4l2_disp_resources,
+   .dev = {
+   .dma_mask   = &vpbe_display_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   },
+};
+struct venc_platform_data dm644x_venc_pdata = {
+   .venc_type = DM644X_VPBE,
+   .setup_clock = dm644x_venc_setup_clock,
+};
+
+static struct platform_device dm644x_venc_dev = {
+   .name   = VPBE_VENC_SUBDEV_NAME,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_venc_resources),
+   .resource   = dm644x_venc_resources,
+   .dev = {
+   .dma_mask   = &dm644x_venc_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = (void *)&dm644x_venc_pdata,
+   },
+};
+
+static u64 dm644x_vpbe_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm644x_vpbe_dev = {
+   .name   = "vpbe_controller",
+   .id = -1,
+   .dev = {
+   .dma_mask   = &dm644x_vpbe_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   },
+};
+
+void dm644x_set_vpbe_display_config(struct vpbe_display_config *cfg)
+{
+   dm644x_vpbe_

[PATCH v10 4/8] davinci vpbe: VENC( Video Encoder) implementation

[Manjunath Hadli]

This patch adds the VENC or the Video encoder, whichis responsible
for the blending of al source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the analog DACs. The venc block is implemented
as a subdevice, allowing for additional extenal and internal encoders
of other kind to plug-in.

Signed-off-by: Manjunath Hadli 
Acked-by: Muralidharan Karicheri 
Acked-by: Hans Verkuil 
---
 drivers/media/video/davinci/vpbe_venc.c  |  568 ++
 drivers/media/video/davinci/vpbe_venc_regs.h |  189 +
 include/media/davinci/vpbe_venc.h|   38 ++
 3 files changed, 795 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpbe_venc.c
 create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
 create mode 100644 include/media/davinci/vpbe_venc.h

diff --git a/drivers/media/video/davinci/vpbe_venc.c 
b/drivers/media/video/davinci/vpbe_venc.c
new file mode 100644
index 000..a4849eb
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -0,0 +1,568 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "vpbe_venc_regs.h"
+
+#define MODULE_NAMEVPBE_VENC_SUBDEV_NAME
+
+static int debug = 2;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Debug level 0-2");
+
+struct venc_state {
+   struct v4l2_subdev sd;
+   struct venc_callback *callback;
+   struct venc_platform_data *pdata;
+   struct device *pdev;
+   u32 output;
+   v4l2_std_id std;
+   spinlock_t lock;
+   void __iomem *venc_base;
+   void __iomem *vdaccfg_reg;
+};
+
+static inline struct venc_state *to_state(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct venc_state, sd);
+}
+
+static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset)
+{
+   struct venc_state *venc = to_state(sd);
+
+   return __raw_readl(venc->venc_base + offset);
+}
+
+static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val)
+{
+   struct venc_state *venc = to_state(sd);
+   __raw_writel(val, (venc->venc_base + offset));
+   return val;
+}
+
+static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset,
+u32 val, u32 mask)
+{
+   u32 new_val = (venc_read(sd, offset) & ~mask) | (val & mask);
+
+   venc_write(sd, offset, new_val);
+   return new_val;
+}
+
+static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val)
+{
+   struct venc_state *venc = to_state(sd);
+
+   __raw_writel(val, venc->vdaccfg_reg);
+
+   val = __raw_readl(venc->vdaccfg_reg);
+   return val;
+}
+
+/* This function sets the dac of the VPBE for various outputs
+ */
+static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
+{
+   int ret = 0;
+
+   switch (out_index) {
+   case 0:
+   v4l2_dbg(debug, 1, sd, "Setting output to Composite\n");
+   venc_write(sd, VENC_DACSEL, 0);
+   break;
+   case 1:
+   v4l2_dbg(debug, 1, sd, "Setting output to S-Video\n");
+   venc_write(sd, VENC_DACSEL, 0x210);
+   break;
+   case  2:
+   venc_write(sd, VENC_DACSEL, 0x543);
+   break;
+   default:
+   ret = -EINVAL;
+   }
+   return ret;
+}
+
+static void enabledigitaloutput(struct v4l2_subdev *sd, int benable)
+{
+   v4l2_dbg(debug, 2, sd, "enabledigitaloutput\n");
+
+   if (benable) {
+   venc_write(sd, VENC_VMOD, 0);
+   venc_write(sd, VENC_CVBS, 0);
+   venc_write(sd, VENC_LCDOUT, 0);
+   venc_write(sd, VENC_HSPLS, 0);
+   venc_write(sd, VENC_HSTART, 0);
+   venc_write(sd, VENC_HVALID, 0);
+   venc_write(sd, VENC_HINT, 0);
+   venc_write(sd, VENC_VSPLS, 0);
+   venc_write(sd, VENC_VSTART, 0);
+   venc_write(sd, VENC_VVALID, 0);

[PATCH v10 2/8] davinci vpbe: VPBE display driver

[Manjunath Hadli]

This patch implements the coe functionality of the dislay driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the man V4L2 driver.This implements
the cre of each of the V4L2 IOCTLs.

Signed-off-by: Manjunath Hadli 
Acked-by: Muralidharan Karicheri 
Acked-by: Hans Verkuil 
---
 drivers/media/video/davinci/vpbe.c |  836 
 include/media/davinci/vpbe.h   |  186 
 2 files changed, 1022 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpbe.c
 create mode 100644 include/media/davinci/vpbe.h

diff --git a/drivers/media/video/davinci/vpbe.c 
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..aa0aac9
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,836 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+
+#define VPBE_DEFAULT_OUTPUT"Composite"
+#define VPBE_DEFAULT_MODE  "ntsc"
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static  struct osd_state *osd_device;
+static struct venc_platform_data *venc_device;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, "vpbe output name (default:Composite)");
+MODULE_PARM_DESC(ef_mode, "vpbe output mode name (default:ntsc");
+MODULE_PARM_DESC(debug, "Debug level 0-1");
+
+MODULE_DESCRIPTION("TI DMXXX VPBE Display controller");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Texas Instruments");
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+   struct vpbe_display_config *vpbe_config = vpbe_dev->cfg;
+   int index = vpbe_dev->current_sd_index;
+
+   return ((index == 0) ? &vpbe_config->venc :
+   &vpbe_config->ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_display_config *vpbe_config,
+int index)
+{
+   char *encoder_name = vpbe_config->outputs[index].subdev_name;
+   int i;
+
+   /* Venc is always first */
+   if (!strcmp(encoder_name, vpbe_config->venc.module_name))
+   return 0;
+
+   for (i = 0; i < vpbe_config->num_ext_encoders; i++) {
+   if (!strcmp(encoder_name,
+vpbe_config->ext_encoders[i].module_name))
+   return i+1;
+   }
+   return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+ struct v4l2_cropcap *cropcap)
+{
+   if (NULL == cropcap)
+   return -EINVAL;
+   cropcap->bounds.left = 0;
+   cropcap->bounds.top = 0;
+   cropcap->bounds.width = vpbe_dev->current_timings.xres;
+   cropcap->bounds.height = vpbe_dev->current_timings.yres;
+   cropcap->defrect = cropcap->bounds;
+   return 0;
+}
+
+/**
+ * vpbe_enum_outputs - enumerate outputs
+ * @vpbe_dev - vpbe device ptr
+ * @output - ptr to v4l2_output structure
+ *
+ * Enumerates the outputs available at the vpbe display
+ * returns the status, -EINVAL if end of output list
+ */
+static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev,
+struct v4l2_output *output)
+{
+   struct vpbe_display_config *vpbe_config = vpbe_dev->cfg;
+   int temp_index = output->index;
+
+   if (temp_index >= vpbe_config->num_outputs)
+   return -EINVAL;
+
+   *output = vpbe_config->outputs[te

[PATCH v10 0/8] davinci vpbe: dm6446 v4l2 driver

[Manjunath Hadli]

version10: addressed Kevin's and Sergei's comments
on:
1.Lines spacing.
2.language errors now based on Kevin Hilman's tree

Manjunath Hadli (8):
  davinci vpbe: V4L2 display driver for DM644X SoC
  davinci vpbe: VPBE display driver
  davinci vpbe: OSD(On Screen Display) block
  davinci vpbe: VENC( Video Encoder) implementation
  davinci vpbe: platform specific additions-khilman
  davinci vpbe: board specific additions
  davinci vpbe: Build infrastructure for VPBE driver
  davinci vpbe: Readme text for Dm6446 vpbe

 Documentation/video4linux/README.davinci-vpbe |   93 ++
 arch/arm/mach-davinci/board-dm644x-evm.c  |   81 +-
 arch/arm/mach-davinci/dm644x.c|  172 ++-
 arch/arm/mach-davinci/include/mach/dm644x.h   |4 +
 drivers/media/video/davinci/Kconfig   |   22 +
 drivers/media/video/davinci/Makefile  |2 +
 drivers/media/video/davinci/vpbe.c|  836 ++
 drivers/media/video/davinci/vpbe_display.c| 2099 +
 drivers/media/video/davinci/vpbe_osd.c| 1211 ++
 drivers/media/video/davinci/vpbe_osd_regs.h   |  389 +
 drivers/media/video/davinci/vpbe_venc.c   |  568 +++
 drivers/media/video/davinci/vpbe_venc_regs.h  |  189 +++
 include/media/davinci/vpbe.h  |  186 +++
 include/media/davinci/vpbe_display.h  |  146 ++
 include/media/davinci/vpbe_osd.h  |  397 +
 include/media/davinci/vpbe_types.h|   93 ++
 include/media/davinci/vpbe_venc.h |   38 +
 17 files changed, 6505 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/video4linux/README.davinci-vpbe
 create mode 100644 drivers/media/video/davinci/vpbe.c
 create mode 100644 drivers/media/video/davinci/vpbe_display.c
 create mode 100644 drivers/media/video/davinci/vpbe_osd.c
 create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
 create mode 100644 drivers/media/video/davinci/vpbe_venc.c
 create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
 create mode 100644 include/media/davinci/vpbe.h
 create mode 100644 include/media/davinci/vpbe_display.h
 create mode 100644 include/media/davinci/vpbe_osd.h
 create mode 100644 include/media/davinci/vpbe_types.h
 create mode 100644 include/media/davinci/vpbe_venc.h

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 02/13] v4l: Add multi-planar ioctl handling code

[Marek Szyprowski]

Hello,

On Wednesday, December 22, 2010 9:39 PM Hans Verkuil wrote:

> On Wednesday, December 22, 2010 18:10:26 Pawel Osciak wrote:
> > From: Pawel Osciak 
> >
> > Add multi-planar API core ioctl handling and conversion functions.
> >
> > Signed-off-by: Pawel Osciak 
> > Signed-off-by: Kyungmin Park 
> > Reviewed-by: Marek Szyprowski 
> > ---
> >  drivers/media/video/v4l2-ioctl.c |  453 
> > ++
> >  include/media/v4l2-ioctl.h   |   16 ++
> >  2 files changed, 425 insertions(+), 44 deletions(-)
> >
> > diff --git a/drivers/media/video/v4l2-ioctl.c 
> > b/drivers/media/video/v4l2-ioctl.c
> > index 8516669..e2f6abb 100644
> > --- a/drivers/media/video/v4l2-ioctl.c
> > +++ b/drivers/media/video/v4l2-ioctl.c
> 
> 
> 
> OK, looks good.
> 
> Marek, this patch + the other patches from your v8 patch series are good to
> go as far as I am concerned. So you can add my tag to the whole series:
> 
> Reviewed-by: Hans Verkuil 
> 
> The only note I want to make is that the V4L2 DocBook spec needs to be updated
> for the multiplanar API. But in my opinion that patch can be done in January.

Thanks for your review and help! I've uploaded a new version with your tag to:
git://git.infradead.org/users/kmpark/linux-2.6-samsung vb2 branch.
You can quickly access it here:
http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/vb2
(it should be available in a few hours).

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv8 00/12] Contiguous Memory Allocator

[Marek Szyprowski]

Hello,

On Thursday, December 23, 2010 11:07 AM Russell King - ARM Linux wrote:

> On Thu, Dec 23, 2010 at 06:30:57PM +0900, Kyungmin Park wrote:
> > Hi Andrew,
> >
> > any comments? what's the next step to merge it for 2.6.38 kernel. we
> > want to use this feature at mainline kernel.
> 
> Has anyone addressed my issue with it that this is wide-open for
> abuse by allocating large chunks of memory, and then remapping
> them in some way with different attributes, thereby violating the
> ARM architecture specification?

Actually this contiguous memory allocator is a better replacement for
alloc_pages() which is used by dma_alloc_coherent(). It is a generic
framework that is not tied only to ARM architecture.

> In other words, do we _actually_ have a use for this which doesn't
> involve doing something like allocating 32MB of memory from it,
> remapping it so that it's DMA coherent, and then performing DMA
> on the resulting buffer?

This is an arm specific problem, also related to dma_alloc_coherent()
allocator. To be 100% conformant with ARM specification we would
probably need to unmap all pages used by the dma_coherent allocator
from the LOW MEM area. This is doable, but completely not related
to the CMA and this patch series.

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv8 00/12] Contiguous Memory Allocator

[Russell King - ARM Linux]

On Thu, Dec 23, 2010 at 06:30:57PM +0900, Kyungmin Park wrote:
> Hi Andrew,
> 
> any comments? what's the next step to merge it for 2.6.38 kernel. we
> want to use this feature at mainline kernel.

Has anyone addressed my issue with it that this is wide-open for
abuse by allocating large chunks of memory, and then remapping
them in some way with different attributes, thereby violating the
ARM architecture specification?

In other words, do we _actually_ have a use for this which doesn't
involve doing something like allocating 32MB of memory from it,
remapping it so that it's DMA coherent, and then performing DMA
on the resulting buffer?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?

[Hans Verkuil]

On Thursday, December 23, 2010 10:38:31 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Thursday 23 December 2010 10:31:19 Hans Verkuil wrote:
> > On Thursday, December 23, 2010 10:19:38 Laurent Pinchart wrote:
> > > On Wednesday 15 December 2010 11:03:37 Hans Verkuil wrote:
> > > > > On Wednesday 15 December 2010 08:57:29 Hans Verkuil wrote:
> > > > > 
> > > > > Hence my question, should we add a way to pass rectangles (basically
> > > > > a structv4l2_rect) through the control ioctls ? It would make sense.
> > > > 
> > > > I thought it over and came to the conclusion that we should not do
> > > > that. Instead we can create four separate controls.
> > > 
> > > That's not very clean, is it ?
> > 
> > Why not? It's perfectly consistent with the way controls work.
> 
> Because it multiplies the number of required controls by 4. There's also no 
> way for applications to know that the controls are grouped together.

4 values, 4 controls. Simple.

> > > > The problem we run into when adding more complex types is that we can
> > > > no longer communicate min and max values (something that we definitely
> > > > want when dealing with coordinates).
> > > 
> > > Why not ? We should still support querying min/max/def values on a struct
> > > v4l2_ctrl. This would of course require an extended queryctrl ioctl.
> > 
> > Which will make apps even more complicated. I thought about this as well,
> > but it's a road that will lead to chaos.
> 
> Sorry, I don't see why a v4l2_rect type will lead to chaos. That doesn't mean 
> we need to support any data structure as control data, just a very limited 
> number V4L2 standard ones.

For every new control type applications will have to add support for that.
Especially for GUIs that is actually a lot of work. Do you want to take on the
job of modifying all V4L2 apps whenever you add a new type? I don't. Adding new
controls is easy and cheap, adding new types is hard and difficult.

The STRING and INTEGER64 types were the first types added in a long time (and
I'm sorry I added INTEGER64 since it is actually not used by any driver at the
moment). And it was a lot of work adding string support to v4l2-ctl and qv4l2.

And I think these are still the only apps in existence that support these two
types.
 
> > > > Another reason is how the control mechanism is designed: they only
> > > > support the basic types (int, bool, string, enum, int64 and a 'button'
> > > > aka action). And the controls are grouped into classes which are named
> > > > through the 'ctrl_class' control.
> > > > 
> > > > So effectively controls represent a field in a class (or struct) and
> > > > each class can be presented as a tab page in a control panel.
> > > > 
> > > > Simple and straightforward.
> > > > 
> > > > If we start to add complex types, then it becomes really hard to define
> > > > the meta data of the control since you are really defining a
> > > > 'mini-class'.
> > > 
> > > I agree that arbitrary complex controls might not be a good idea, but
> > > v4l2_rect is a pretty standard data structure in V4L2 and something that
> > > can be useful for different controls.
> > > 
> > > > It sounds nice initially, but we really should not do this since I
> > > > believe it will lead to chaos later on. You want complex types, then
> > > > use ioctls, not controls. Or split up the complex type into multiple
> > > > simple types.
> > > 
> > > Then let's use an ioctl for focus control. I don't like it.
> > 
> > I would vote for 4 controls. Since FOCUS_MODE_AUTO is a control it makes no
> > sense to make an ioctl to set the rectangle. That would be a strange mix.
> > 
> > And having 4 controls for the rectangle will actually look good in GUIs,
> 
> Applications will display the controls without knowing they are related. 
> Having a v4l2_rect type would actually allow applications to display the 
> control better.

As I said, are you going to add support for this in all apps? Especially since
many apps just show a list of controls, so if you just ensure that the four
rect controls come one after the other, then they will show up just fine.

> > and with S_EXT_CTRLS you can set all focus-related controls in one call.
> 
> Then don't tell me that an extended queryctrl ioctl would make apps even more 
> complicated, when you advocate using four separate values to change a single 
> control ;-)

???

Most generic apps just enumerate controls, so 1 or 100 controls doesn't matter
to them.

Adding a new type does, though.

Just add four controls for this. It works everywhere and doesn't require any new
APIs and application changes.

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: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?

[Laurent Pinchart]

Hi Hans,

On Thursday 23 December 2010 10:31:19 Hans Verkuil wrote:
> On Thursday, December 23, 2010 10:19:38 Laurent Pinchart wrote:
> > On Wednesday 15 December 2010 11:03:37 Hans Verkuil wrote:
> > > > On Wednesday 15 December 2010 08:57:29 Hans Verkuil wrote:
> > > > 
> > > > Hence my question, should we add a way to pass rectangles (basically
> > > > a structv4l2_rect) through the control ioctls ? It would make sense.
> > > 
> > > I thought it over and came to the conclusion that we should not do
> > > that. Instead we can create four separate controls.
> > 
> > That's not very clean, is it ?
> 
> Why not? It's perfectly consistent with the way controls work.

Because it multiplies the number of required controls by 4. There's also no 
way for applications to know that the controls are grouped together.

> > > The problem we run into when adding more complex types is that we can
> > > no longer communicate min and max values (something that we definitely
> > > want when dealing with coordinates).
> > 
> > Why not ? We should still support querying min/max/def values on a struct
> > v4l2_ctrl. This would of course require an extended queryctrl ioctl.
> 
> Which will make apps even more complicated. I thought about this as well,
> but it's a road that will lead to chaos.

Sorry, I don't see why a v4l2_rect type will lead to chaos. That doesn't mean 
we need to support any data structure as control data, just a very limited 
number V4L2 standard ones.

> > > Another reason is how the control mechanism is designed: they only
> > > support the basic types (int, bool, string, enum, int64 and a 'button'
> > > aka action). And the controls are grouped into classes which are named
> > > through the 'ctrl_class' control.
> > > 
> > > So effectively controls represent a field in a class (or struct) and
> > > each class can be presented as a tab page in a control panel.
> > > 
> > > Simple and straightforward.
> > > 
> > > If we start to add complex types, then it becomes really hard to define
> > > the meta data of the control since you are really defining a
> > > 'mini-class'.
> > 
> > I agree that arbitrary complex controls might not be a good idea, but
> > v4l2_rect is a pretty standard data structure in V4L2 and something that
> > can be useful for different controls.
> > 
> > > It sounds nice initially, but we really should not do this since I
> > > believe it will lead to chaos later on. You want complex types, then
> > > use ioctls, not controls. Or split up the complex type into multiple
> > > simple types.
> > 
> > Then let's use an ioctl for focus control. I don't like it.
> 
> I would vote for 4 controls. Since FOCUS_MODE_AUTO is a control it makes no
> sense to make an ioctl to set the rectangle. That would be a strange mix.
> 
> And having 4 controls for the rectangle will actually look good in GUIs,

Applications will display the controls without knowing they are related. 
Having a v4l2_rect type would actually allow applications to display the 
control better.

> and with S_EXT_CTRLS you can set all focus-related controls in one call.

Then don't tell me that an extended queryctrl ioctl would make apps even more 
complicated, when you advocate using four separate values to change a single 
control ;-)

-- 
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: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal

[Hans Verkuil]

On Thursday, December 23, 2010 10:27:25 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Thursday 23 December 2010 10:20:17 Hans Verkuil wrote:
> > On Thursday, December 23, 2010 10:02:33 Laurent Pinchart wrote:
> > > On Monday 20 December 2010 14:09:40 Hans Verkuil wrote:
> > > > On Monday, December 20, 2010 13:48:51 Laurent Pinchart wrote:
> > > > > What if the application wants to change the resolution during capture
> > > > > ? It will have to stop capture, call REQBUFS(0), change the format,
> > > > > request buffers and restart capture. If filehandle ownership is
> > > > > dropped after REQBUFS(0) that will open the door to a race
> > > > > condition.
> > > > 
> > > > That's why S_PRIORITY was invented.
> > > 
> > > Right, I should implement that. I think the documentation isn't clear
> > > though. What is the background priority for exactly ?
> > 
> > As the documentation mentions, it can be used for background processes
> > monitoring VBI (e.g. teletext) transmissions. I'm not aware of any such
> > applications, though.
> > 
> > PRIORITY_DEFAULT and PRIORITY_RECORD are the only two relevant prios in
> > practice.
> > 
> > > And the "unset" priority ?
> > 
> > Internal prio only. I think it's the value when no file handle is open.
> 
> Aren't priorities associated with file handles ?

Yes, but there is also a global prio.

> > > Are other applications allowed to change controls when an application has
> > > the record priority ?
> > 
> > No. Only read-only ioctls can be executed.
> 
> Then we got an issue here. I want an application to be able to acquire 
> exclusive streaming rights on the device (so that there won't be race 
> conditions when changing the resolution), but still allow other applications 
> to change controls.

Why? The whole idea of prios is that once you are PRIO_RECORD no one else
can mess with settings. Allowing other apps access to controls will make it
possible to e.g. change the contrast to some crappy value. Not acceptable.

If the only thing you want to use PRIO_RECORD for in apps is to prevent this
'race condition' (I don't really see this as a real race, to be honest), then
the app can raise the prio to RECORD just before STREAMOFF, change the 
resolution,
start streaming again and lower it to the default prio.

Regards,

Hans

> > > In general I find the priority ioctls underspecified, that's why I
> > > haven't implemented them yet.
> > 
> > Use the prio support functions in v4l2-common. They are easy to use and do
> > the job.
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?

[Hans Verkuil]

On Thursday, December 23, 2010 10:19:38 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Wednesday 15 December 2010 11:03:37 Hans Verkuil wrote:
> > > On Wednesday 15 December 2010 08:57:29 Hans Verkuil wrote:
> > >
> > > Hence my question, should we add a way to pass rectangles (basically a
> > > structv4l2_rect) through the control ioctls ? It would make sense.
> > 
> > I thought it over and came to the conclusion that we should not do that.
> > Instead we can create four separate controls.
> 
> That's not very clean, is it ?

Why not? It's perfectly consistent with the way controls work.

> > The problem we run into when adding more complex types is that we can no
> > longer communicate min and max values (something that we definitely want
> > when dealing with coordinates).
> 
> Why not ? We should still support querying min/max/def values on a struct 
> v4l2_ctrl. This would of course require an extended queryctrl ioctl.

Which will make apps even more complicated. I thought about this as well, but
it's a road that will lead to chaos.
 
> > Another reason is how the control mechanism is designed: they only support
> > the basic types (int, bool, string, enum, int64 and a 'button' aka
> > action). And the controls are grouped into classes which are named through
> > the 'ctrl_class' control.
> > 
> > So effectively controls represent a field in a class (or struct) and each
> > class can be presented as a tab page in a control panel.
> > 
> > Simple and straightforward.
> > 
> > If we start to add complex types, then it becomes really hard to define
> > the meta data of the control since you are really defining a 'mini-class'.
> 
> I agree that arbitrary complex controls might not be a good idea, but 
> v4l2_rect is a pretty standard data structure in V4L2 and something that can 
> be useful for different controls.
> 
> > It sounds nice initially, but we really should not do this since I believe
> > it will lead to chaos later on. You want complex types, then use ioctls,
> > not controls. Or split up the complex type into multiple simple types.
> 
> Then let's use an ioctl for focus control. I don't like it.

I would vote for 4 controls. Since FOCUS_MODE_AUTO is a control it makes no
sense to make an ioctl to set the rectangle. That would be a strange mix.

And having 4 controls for the rectangle will actually look good in GUIs, and
with S_EXT_CTRLS you can set all focus-related controls in one call.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv8 00/12] Contiguous Memory Allocator

[Kyungmin Park]

Hi Andrew,

any comments? what's the next step to merge it for 2.6.38 kernel. we
want to use this feature at mainline kernel.

Any idea and comments are welcome.

Thank you,
Kyungmin Park

On Thu, Dec 16, 2010 at 5:34 AM, Michal Nazarewicz
 wrote:
> Hello everyone,
>
> This is yet another version of CMA this time stripped from a lot of
> code and with working migration implementation.
>
>   The Contiguous Memory Allocator (CMA) makes it possible for
>   device drivers to allocate big contiguous chunks of memory after
>   the system has booted.
>
> For more information see 7th patch in the set.
>
>
> This version fixes some things Kamezawa suggested plus it separates
> code that uses MIGRATE_CMA from the rest of the code.  This I hope
> will help to grasp the overall idea of CMA.
>
>
> The current version is just an allocator that handles allocation of
> contiguous memory blocks.  The difference between this patchset and
> Kamezawa's alloc_contig_pages() are:
>
> 1. alloc_contig_pages() requires MAX_ORDER alignment of allocations
>   which may be unsuitable for embeded systems where a few MiBs are
>   required.
>
>   Lack of the requirement on the alignment means that several threads
>   might try to access the same pageblock/page.  To prevent this from
>   happening CMA uses a mutex so that only one cm_alloc()/cm_free()
>   function may run at one point.
>
> 2. CMA may use its own migratetype (MIGRATE_CMA) which behaves
>   similarly to ZONE_MOVABLE but can be put in arbitrary places.
>
>   This is required for us since we need to define two disjoint memory
>   ranges inside system RAM.  (ie. in two memory banks (do not confuse
>   with nodes)).
>
> 3. alloc_contig_pages() scans memory in search for range that could be
>   migrated.  CMA on the other hand maintains its own allocator to
>   decide where to allocate memory for device drivers and then tries
>   to migrate pages from that part if needed.  This is not strictly
>   required but I somehow feel it might be faster.
>
>
> Links to previous versions of the patchset:
> v7: 
> v6: 
> v5: (intentionally left out as CMA v5 was identical to CMA v4)
> v4: 
> v3: 
> v2: 
> v1: 
>
>
> Changelog:
>
> v8: 1. The alloc_contig_range() function has now been separated from
>       CMA and put in page_allocator.c.  This function tries to
>       migrate all LRU pages in specified range and then allocate the
>       range using alloc_contig_freed_pages().
>
>    2. Support for MIGRATE_CMA has been separated from the CMA code.
>       I have not tested if CMA works with ZONE_MOVABLE but I see no
>       reasons why it shouldn't.
>
>    3. I have added a @private argument when creating CMA contexts so
>       that one can reserve memory and not share it with the rest of
>       the system.  This way, CMA acts only as allocation algorithm.
>
> v7: 1. A lot of functionality that handled driver->allocator_context
>       mapping has been removed from the patchset.  This is not to say
>       that this code is not needed, it's just not worth posting
>       everything in one patchset.
>
>       Currently, CMA is "just" an allocator.  It uses it's own
>       migratetype (MIGRATE_CMA) for defining ranges of pageblokcs
>       which behave just like ZONE_MOVABLE but dispite the latter can
>       be put in arbitrary places.
>
>    2. The migration code that was introduced in the previous version
>       actually started working.
>
>
> v6: 1. Most importantly, v6 introduces support for memory migration.
>       The implementation is not yet complete though.
>
>       Migration support means that when CMA is not using memory
>       reserved for it, page allocator can allocate pages from it.
>       When CMA wants to use the memory, the pages have to be moved
>       and/or evicted as to make room for CMA.
>
>       To make it possible it must be guaranteed that only movable and
>       reclaimable pages are allocated in CMA controlled regions.
>       This is done by introducing a MIGRATE_CMA migrate type that
>       guarantees exactly that.
>
>       Some of the migration code is "borrowed" from Kamezawa
>       Hiroyuki's alloc_contig_pages() implementation.  The main
>       difference is that thanks to MIGRATE_CMA migrate type CMA
>       assumes that memory controlled by CMA are is always movable or
>       reclaimable so that it makes allocation decisions regardless of
>       the whether some pages are actually allocated and migrates them
>       if needed.
>
>       The most interesting patches from the patchset that implement
>       the functionality are:
>
>         09/13: mm: alloc_contig_free_pages() added
>         10/13: mm: MIGRATE_CMA migr

Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal

[Laurent Pinchart]

Hi Hans,

On Thursday 23 December 2010 10:20:17 Hans Verkuil wrote:
> On Thursday, December 23, 2010 10:02:33 Laurent Pinchart wrote:
> > On Monday 20 December 2010 14:09:40 Hans Verkuil wrote:
> > > On Monday, December 20, 2010 13:48:51 Laurent Pinchart wrote:
> > > > What if the application wants to change the resolution during capture
> > > > ? It will have to stop capture, call REQBUFS(0), change the format,
> > > > request buffers and restart capture. If filehandle ownership is
> > > > dropped after REQBUFS(0) that will open the door to a race
> > > > condition.
> > > 
> > > That's why S_PRIORITY was invented.
> > 
> > Right, I should implement that. I think the documentation isn't clear
> > though. What is the background priority for exactly ?
> 
> As the documentation mentions, it can be used for background processes
> monitoring VBI (e.g. teletext) transmissions. I'm not aware of any such
> applications, though.
> 
> PRIORITY_DEFAULT and PRIORITY_RECORD are the only two relevant prios in
> practice.
> 
> > And the "unset" priority ?
> 
> Internal prio only. I think it's the value when no file handle is open.

Aren't priorities associated with file handles ?

> > Are other applications allowed to change controls when an application has
> > the record priority ?
> 
> No. Only read-only ioctls can be executed.

Then we got an issue here. I want an application to be able to acquire 
exclusive streaming rights on the device (so that there won't be race 
conditions when changing the resolution), but still allow other applications 
to change controls.

> > In general I find the priority ioctls underspecified, that's why I
> > haven't implemented them yet.
> 
> Use the prio support functions in v4l2-common. They are easy to use and do
> the job.

-- 
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: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal

[Hans Verkuil]

On Thursday, December 23, 2010 10:02:33 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Monday 20 December 2010 14:09:40 Hans Verkuil wrote:
> > On Monday, December 20, 2010 13:48:51 Laurent Pinchart wrote:
> > >
> > > What if the application wants to change the resolution during capture ?
> > > It will have to stop capture, call REQBUFS(0), change the format,
> > > request buffers and restart capture. If filehandle ownership is dropped
> > > after REQBUFS(0) that will open the door to a race condition.
> > 
> > That's why S_PRIORITY was invented.
> 
> Right, I should implement that. I think the documentation isn't clear though. 
> What is the background priority for exactly ?

As the documentation mentions, it can be used for background processes 
monitoring
VBI (e.g. teletext) transmissions. I'm not aware of any such applications, 
though.

PRIORITY_DEFAULT and PRIORITY_RECORD are the only two relevant prios in 
practice.

> And the "unset" priority ?

Internal prio only. I think it's the value when no file handle is open.

> Are 
> other applications allowed to change controls when an application has the 
> record priority ?

No. Only read-only ioctls can be executed.

> In general I find the priority ioctls underspecified, that's why I haven't 
> implemented them yet.

Use the prio support functions in v4l2-common. They are easy to use and do the
job.

Regards,

Hans

> On a side note, I've just tested the latest uvcvideo driver, and I've 
> successfully captured video using a second application after calling 
> REQBUFS(0) in a first application.
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?

[Laurent Pinchart]

Hi Hans,

On Wednesday 15 December 2010 11:03:37 Hans Verkuil wrote:
> > On Wednesday 15 December 2010 08:57:29 Hans Verkuil wrote:
> >
> > Hence my question, should we add a way to pass rectangles (basically a
> > structv4l2_rect) through the control ioctls ? It would make sense.
> 
> I thought it over and came to the conclusion that we should not do that.
> Instead we can create four separate controls.

That's not very clean, is it ?

> The problem we run into when adding more complex types is that we can no
> longer communicate min and max values (something that we definitely want
> when dealing with coordinates).

Why not ? We should still support querying min/max/def values on a struct 
v4l2_ctrl. This would of course require an extended queryctrl ioctl.

> Another reason is how the control mechanism is designed: they only support
> the basic types (int, bool, string, enum, int64 and a 'button' aka
> action). And the controls are grouped into classes which are named through
> the 'ctrl_class' control.
> 
> So effectively controls represent a field in a class (or struct) and each
> class can be presented as a tab page in a control panel.
> 
> Simple and straightforward.
> 
> If we start to add complex types, then it becomes really hard to define
> the meta data of the control since you are really defining a 'mini-class'.

I agree that arbitrary complex controls might not be a good idea, but 
v4l2_rect is a pretty standard data structure in V4L2 and something that can 
be useful for different controls.

> It sounds nice initially, but we really should not do this since I believe
> it will lead to chaos later on. You want complex types, then use ioctls,
> not controls. Or split up the complex type into multiple simple types.

Then let's use an ioctl for focus control. I don't like it.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2.1] [media] s5p-fimc: Configure scaler registers depending on FIMC version

[Sylwester Nawrocki]

Hi Hyunwoong,

On 12/23/2010 02:26 AM, Hyunwoong Kim wrote:
> The main scaler has four SFRs for main scaler ratio depending on FIMC version.
> FIMC 4.x has only two SFRs and FIMC 5.x has four SFRs for main scaler.
> Those are MainHorRatio, MainHorRatio_ext, MainVerRatio and MainverRatio_ext.
> 
> The FIMC 5.x has 15 bit resolution for scaling ratio as below.
> {MainHorRatio,MainHorRatio_ext} = {[14:6],[5:0]}.
> {MainVerRatio,MainVerRatio_ext} = {[14:6],[5:0]}.
> MainHorRatio = CISCCTRL[24:16], MainHorRatio_ext = CIEXTEN[15:10]
> MainVerRatio = CISCCTRL[8:0],   MainVerRatio_ext = CIEXTEN[5:0]
> 
> This patch supports FIMC 4.x and FIMC 5.x using 
> platform_device_id::driver_data.
> 
> Reviewed-by: Jonghun Han 
> Signed-off-by: Hyunwoong Kim 
> ---
> Depends on the below patch
> - [PATCH v3.2] [media] s5p-fimc: fix the value of YUV422 1-plane formats
> 
> Changes since V2:
> - Code sync with 
> http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/vb2-mfc-fimc
> 
> Changes since V1:
> - Change the summary line.
> - Change the definitions of extended mainscaler ratios
>   commented by Sylwester Nawrocki.
> - Change the conditional expressions.
> 
>  drivers/media/video/s5p-fimc/fimc-capture.c |7 +++-
>  drivers/media/video/s5p-fimc/fimc-core.c|   22 ++--
>  drivers/media/video/s5p-fimc/fimc-core.h|7 +++-
>  drivers/media/video/s5p-fimc/fimc-reg.c |   52 +++---
>  drivers/media/video/s5p-fimc/regs-fimc.h|   12 +-
>  5 files changed, 87 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c 
> b/drivers/media/video/s5p-fimc/fimc-capture.c
> index 4e4441f..b1cb937 100644
> --- a/drivers/media/video/s5p-fimc/fimc-capture.c
> +++ b/drivers/media/video/s5p-fimc/fimc-capture.c
> @@ -210,6 +210,7 @@ static int start_streaming(struct vb2_queue *q)
>   struct fimc_ctx *ctx = q->drv_priv;
>   struct fimc_dev *fimc = ctx->fimc_dev;
>   struct s3c_fimc_isp_info *isp_info;
> + struct samsung_fimc_variant *variant = ctx->fimc_dev->variant;
>   int ret;
>  
>   ret = v4l2_subdev_call(fimc->vid_cap.sd, video, s_stream, 1);
> @@ -232,7 +233,11 @@ static int start_streaming(struct vb2_queue *q)
>   return ret;
>   }
>   fimc_hw_set_input_path(ctx);
> - fimc_hw_set_scaler(ctx);
> + fimc_hw_set_prescaler(ctx);
> + if (variant->has_mainscaler_ext)
> + fimc_hw_set_mainscaler_ext(ctx);
> + else
> + fimc_hw_set_mainscaler(ctx);
>   fimc_hw_set_target_format(ctx);
>   fimc_hw_set_rotation(ctx);
>   fimc_hw_set_effect(ctx);
> diff --git a/drivers/media/video/s5p-fimc/fimc-core.c 
> b/drivers/media/video/s5p-fimc/fimc-core.c
> index 6e388ff..2b65961 100644
> --- a/drivers/media/video/s5p-fimc/fimc-core.c
> +++ b/drivers/media/video/s5p-fimc/fimc-core.c
> @@ -246,6 +246,7 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
>   struct fimc_scaler *sc = &ctx->scaler;
>   struct fimc_frame *s_frame = &ctx->s_frame;
>   struct fimc_frame *d_frame = &ctx->d_frame;
> + struct samsung_fimc_variant *variant = ctx->fimc_dev->variant;
>   int tx, ty, sx, sy;
>   int ret;
>  
> @@ -284,8 +285,14 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
>   sc->pre_dst_width = sx / sc->pre_hratio;
>   sc->pre_dst_height = sy / sc->pre_vratio;
>  
> - sc->main_hratio = (sx << 8) / (tx << sc->hfactor);
> - sc->main_vratio = (sy << 8) / (ty << sc->vfactor);
> + if (variant->has_mainscaler_ext) {
> + sc->main_hratio = (sx << 14) / (tx << sc->hfactor);
> + sc->main_vratio = (sy << 14) / (ty << sc->vfactor);
> + } else {
> + sc->main_hratio = (sx << 8) / (tx << sc->hfactor);
> + sc->main_vratio = (sy << 8) / (ty << sc->vfactor);
> +
> + }
>  
>   sc->scaleup_h = (tx >= sx) ? 1 : 0;
>   sc->scaleup_v = (ty >= sy) ? 1 : 0;
> @@ -569,6 +576,7 @@ static void fimc_dma_run(void *priv)
>  {
>   struct fimc_ctx *ctx = priv;
>   struct fimc_dev *fimc;
> + struct samsung_fimc_variant *variant = ctx->fimc_dev->variant;
>   unsigned long flags;
>   u32 ret;
>  
> @@ -601,7 +609,12 @@ static void fimc_dma_run(void *priv)
>   err("Scaler setup error");
>   goto dma_unlock;
>   }
> - fimc_hw_set_scaler(ctx);
> +
> + fimc_hw_set_prescaler(ctx);
> + if (variant->has_mainscaler_ext)
> + fimc_hw_set_mainscaler_ext(ctx);
> + else
> + fimc_hw_set_mainscaler(ctx);
>   fimc_hw_set_target_format(ctx);
>   fimc_hw_set_rotation(ctx);
>   fimc_hw_set_effect(ctx);
> @@ -1720,6 +1733,7 @@ static struct samsung_fimc_variant 
> fimc1_variant_s5pv210 = {
>   .pix_hoff= 1,
>   .has

Re: [PATCH v3.2] [media] s5p-fimc: fix the value of YUV422 1-plane formats

[Sylwester Nawrocki]

Hi Hyunwoong,

I am going to handle this patch through my tree.
Finally it applies cleanly.

Thanks,
Sylwester

On 12/23/2010 02:26 AM, Hyunwoong Kim wrote:
> Some color formats are mismatched in s5p-fimc driver.
> CIOCTRL[1:0], order422_out, should be set 2b'00 not 2b'11
> to use V4L2_PIX_FMT_YUYV. Because in V4L2 standard V4L2_PIX_FMT_YUYV means
> "start + 0: Y'00 Cb00 Y'01 Cr00 Y'02 Cb01 Y'03 Cr01". According to datasheet
> 2b'00 is right value for V4L2_PIX_FMT_YUYV.
> 
> -
> bit |MSBLSB
> -
> 00  |  Cr1Y3Cb1Y2Cr0Y1Cb0Y0
> -
> 01  |  Cb1Y3Cr1Y2Cb0Y1Cr0Y0
> -
> 10  |  Y3Cr1Y2Cb1Y1Cr0Y0Cb0
> -
> 11  |  Y3Cb1Y2Cr1Y1Cb0Y0Cr0
> -
> 
> V4L2_PIX_FMT_YVYU, V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_VYUY are also mismatched
> with datasheet. MSCTRL[17:16], order2p_in, is also mismatched
> in V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YVYU.
> 
> Reviewed-by: Jonghun Han 
> Signed-off-by: Hyunwoong Kim 
> ---
> Changes since V3:
> - Code sync with 
> http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/vb2-mfc-fimc
> 
> Changes since V2:
> - Correct the name of Output DMA control register
> - Change definitions of YUV422 input/outut format with datasheet
>   commented by Sylwester Nawrocki.
> 
> Changes since V1:
> - make corrections directly in function fimc_set_yuv_order
>   commented by Sylwester Nawrocki.
> - remove S5P_FIMC_IN_* and S5P_FIMC_OUT_* definitions from fimc-core.h
> 
>  drivers/media/video/s5p-fimc/fimc-core.c |   16 
>  drivers/media/video/s5p-fimc/fimc-core.h |   12 
>  drivers/media/video/s5p-fimc/regs-fimc.h |   12 ++--
>  3 files changed, 14 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/media/video/s5p-fimc/fimc-core.c 
> b/drivers/media/video/s5p-fimc/fimc-core.c
> index 2374fd8..6e388ff 100644
> --- a/drivers/media/video/s5p-fimc/fimc-core.c
> +++ b/drivers/media/video/s5p-fimc/fimc-core.c
> @@ -448,34 +448,34 @@ static void fimc_set_yuv_order(struct fimc_ctx *ctx)
>   /* Set order for 1 plane input formats. */
>   switch (ctx->s_frame.fmt->color) {
>   case S5P_FIMC_YCRYCB422:
> - ctx->in_order_1p = S5P_FIMC_IN_YCRYCB;
> + ctx->in_order_1p = S5P_MSCTRL_ORDER422_CBYCRY;
>   break;
>   case S5P_FIMC_CBYCRY422:
> - ctx->in_order_1p = S5P_FIMC_IN_CBYCRY;
> + ctx->in_order_1p = S5P_MSCTRL_ORDER422_YCRYCB;
>   break;
>   case S5P_FIMC_CRYCBY422:
> - ctx->in_order_1p = S5P_FIMC_IN_CRYCBY;
> + ctx->in_order_1p = S5P_MSCTRL_ORDER422_YCBYCR;
>   break;
>   case S5P_FIMC_YCBYCR422:
>   default:
> - ctx->in_order_1p = S5P_FIMC_IN_YCBYCR;
> + ctx->in_order_1p = S5P_MSCTRL_ORDER422_CRYCBY;
>   break;
>   }
>   dbg("ctx->in_order_1p= %d", ctx->in_order_1p);
>  
>   switch (ctx->d_frame.fmt->color) {
>   case S5P_FIMC_YCRYCB422:
> - ctx->out_order_1p = S5P_FIMC_OUT_YCRYCB;
> + ctx->out_order_1p = S5P_CIOCTRL_ORDER422_CBYCRY;
>   break;
>   case S5P_FIMC_CBYCRY422:
> - ctx->out_order_1p = S5P_FIMC_OUT_CBYCRY;
> + ctx->out_order_1p = S5P_CIOCTRL_ORDER422_YCRYCB;
>   break;
>   case S5P_FIMC_CRYCBY422:
> - ctx->out_order_1p = S5P_FIMC_OUT_CRYCBY;
> + ctx->out_order_1p = S5P_CIOCTRL_ORDER422_YCBYCR;
>   break;
>   case S5P_FIMC_YCBYCR422:
>   default:
> - ctx->out_order_1p = S5P_FIMC_OUT_YCBYCR;
> + ctx->out_order_1p = S5P_CIOCTRL_ORDER422_CRYCBY;
>   break;
>   }
>   dbg("ctx->out_order_1p= %d", ctx->out_order_1p);
> diff --git a/drivers/media/video/s5p-fimc/fimc-core.h 
> b/drivers/media/video/s5p-fimc/fimc-core.h
> index 1f1beaa..d684138 100644
> --- a/drivers/media/video/s5p-fimc/fimc-core.h
> +++ b/drivers/media/video/s5p-fimc/fimc-core.h
> @@ -94,18 +94,6 @@ enum fimc_color_fmt {
>  
>  #define fimc_fmt_is_rgb(x) ((x) & 0x10)
>  
> -/* Y/Cb/Cr components order at DMA output for 1 plane YCbCr 4:2:2 formats. */
> -#define  S5P_FIMC_OUT_CRYCBY S5P_CIOCTRL_ORDER422_CRYCBY
> -#define  S5P_FIMC_OUT_CBYCRY S5P_CIOCTRL_ORDER422_YCRYCB
> -#define  S5P_FIMC_OUT_YCRYCB S5P_CIOCTRL_ORDER422_CBYCRY
> -#define  S5P_FIMC_OUT_YCBYCR S5P_CIOCTRL_ORDER422_YCBYCR
> -
> -/* Input Y/Cb/Cr components order for 1 plane YCbCr 4:2:2 color formats. */
> -#define  S5P_FIMC_IN_CRYCBY  S5P_MSCTRL_ORDER422_CRYCBY
>

Re: [RFC/PATCH v7 03/12] media: Entities, pads and links

[Laurent Pinchart]

Hi Hans,

On Tuesday 21 December 2010 17:22:39 Hans Verkuil wrote:
> Hi Laurent,
> 
> I promised to look at the new type names, so here is my opinion:

Thanks.

> On Monday, December 20, 2010 12:36:26 Laurent Pinchart wrote:
> 
> 
> 
> > +
> > +#define MEDIA_ENTITY_TYPE_SHIFT16
> > +#define MEDIA_ENTITY_TYPE_MASK 0x00ff
> > +#define MEDIA_ENTITY_SUBTYPE_MASK  0x
> > +
> > +#define MEDIA_ENTITY_TYPE_DEVNODE  (1 << MEDIA_ENTITY_TYPE_SHIFT)
> > +#define MEDIA_ENTITY_TYPE_DEVNODE_V4L  
> > (MEDIA_ENTITY_TYPE_DEVNODE + 
1)
> > +#define MEDIA_ENTITY_TYPE_DEVNODE_FB   
> > (MEDIA_ENTITY_TYPE_DEVNODE + 2)
> > +#define MEDIA_ENTITY_TYPE_DEVNODE_ALSA 
> > (MEDIA_ENTITY_TYPE_DEVNODE + 
3)
> > +#define MEDIA_ENTITY_TYPE_DEVNODE_DVB  
> > (MEDIA_ENTITY_TYPE_DEVNODE + 
4)
> > +
> > +#define MEDIA_ENTITY_TYPE_V4L2_SUBDEV  (2 << 
> > MEDIA_ENTITY_TYPE_SHIFT)
> > +#define
> > MEDIA_ENTITY_TYPE_V4L2_SUBDEV_SENSOR(MEDIA_ENTITY_TYPE_V4L2_SUBDEV 
> > + 1)
> > +#define
> > MEDIA_ENTITY_TYPE_V4L2_SUBDEV_FLASH (MEDIA_ENTITY_TYPE_V4L2_SUBDEV + 2)
> > +#define
> > MEDIA_ENTITY_TYPE_V4L2_SUBDEV_LENS  (MEDIA_ENTITY_TYPE_V4L2_SUBDEV + 3) +
> > +#define MEDIA_ENTITY_FLAG_DEFAULT  (1 << 0)
> > +
> > +#define MEDIA_LINK_FLAG_ENABLED(1 << 0)
> > +#define MEDIA_LINK_FLAG_IMMUTABLE  (1 << 1)
> > +
> > +#define MEDIA_PAD_FLAG_INPUT   (1 << 0)
> > +#define MEDIA_PAD_FLAG_OUTPUT  (1 << 1)
> 
> Using V4L2_SUBDEV instead of just SUBDEV is definitely an improvement.
> 
> However, I think the defines are getting way too long and I would propose
> to use the ME_ prefix instead of MEDIA_ENTITY_. Also ML_ instead of
> MEDIA_LINK_ and MP_ instead of MEDIA_PAD_.
> 
> That way it is less of an alphabet soup when reading code.

I agree that the names are too long, but I'm concerned that the ME_, ML_ and 
MP_ prefixes might cause namespace clashes.

-- 
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: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal

[Laurent Pinchart]

Hi Hans,

On Monday 20 December 2010 14:09:40 Hans Verkuil wrote:
> On Monday, December 20, 2010 13:48:51 Laurent Pinchart wrote:
> >
> > What if the application wants to change the resolution during capture ?
> > It will have to stop capture, call REQBUFS(0), change the format,
> > request buffers and restart capture. If filehandle ownership is dropped
> > after REQBUFS(0) that will open the door to a race condition.
> 
> That's why S_PRIORITY was invented.

Right, I should implement that. I think the documentation isn't clear though. 
What is the background priority for exactly ? And the "unset" priority ? Are 
other applications allowed to change controls when an application has the 
record priority ?

In general I find the priority ioctls underspecified, that's why I haven't 
implemented them yet.

On a side note, I've just tested the latest uvcvideo driver, and I've 
successfully captured video using a second application after calling 
REQBUFS(0) in a first application.

-- 
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: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal

[Laurent Pinchart]

On Thursday 23 December 2010 09:34:27 Laurent Pinchart wrote:
> Hi Mauro,
> 
> On Tuesday 21 December 2010 12:10:18 Mauro Carvalho Chehab wrote:
> > You didn't understand me: uvcvideo is returning -EBUSY to format changes
> > with buffers freed.
> 
> As explained in my answer to Hans, that's on purpose.
> 
> The uvcvideo driver releases buffers when calling REQBUFS(0). However, the
> file handle is still marked as owning the device for streaming purpose, so
> other applications can't change the format or request buffers.
> 
> The reason for that is to avoid race conditions when an application wants
> to change the resolution during capture. As the application has to stop
> capture, call REQBUFS(0), change the format, request buffers  and restart
> capture, it prevents another application from racing it after REQBUFS(0).

And it's actually not correct. I've just tested the latest uvcvideo version, 
and I can start capture in a second application after calling REQBUFS(0) in 
the first one.

> As Hans correctly pointed out, this should be implemented using the
> priority ioctls. I will fix that.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal

[Laurent Pinchart]

Hi Mauro,

On Tuesday 21 December 2010 12:10:18 Mauro Carvalho Chehab wrote:
>
> You didn't understand me: uvcvideo is returning -EBUSY to format changes
> with buffers freed.

As explained in my answer to Hans, that's on purpose.

The uvcvideo driver releases buffers when calling REQBUFS(0). However, the 
file handle is still marked as owning the device for streaming purpose, so 
other applications can't change the format or request buffers.

The reason for that is to avoid race conditions when an application wants to 
change the resolution during capture. As the application has to stop capture, 
call REQBUFS(0), change the format, request buffers  and restart capture, it 
prevents another application from racing it after REQBUFS(0).

As Hans correctly pointed out, this should be implemented using the priority 
ioctls. I will fix that.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html