Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365

2012-07-27 Thread Sakari Ailus 
Hi Prabhakar,

Thanks for the patch, and my apologies for delayed answer!

On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote:
> From: Manjunath Hadli 
> 
> add new enum entries for supporting the media-bus formats on dm365.
> These include some bayer and some non-bayer formats.
> V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used
> internal to the hardware by the resizer.
> V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format
> that is supported by dm365 hardware.
> 
> Acked-by: Laurent Pinchart 
> Acked-by: Hans Verkuil 
> Signed-off-by: Manjunath Hadli 
> Signed-off-by: Lad, Prabhakar 
> Cc: Sakari Ailus 
> Cc: Guennadi Liakhovetski 
> ---
>  Documentation/DocBook/media/v4l/subdev-formats.xml |  250 
> +++-
>  include/linux/v4l2-mediabus.h  |   10 +-
>  2 files changed, 252 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
> b/Documentation/DocBook/media/v4l/subdev-formats.xml
> index 49c532e..75dc275 100644
> --- a/Documentation/DocBook/media/v4l/subdev-formats.xml
> +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
> @@ -353,9 +353,9 @@
>   The number of bits per pixel component. All components 
> are
>   transferred on the same number of bits. Common values are 8, 10 and 
> 12.
>   
> - If the pixel components are DPCM-compressed, a mention 
> of the
> - DPCM compression and the number of bits per compressed pixel 
> component.
> - 
> + The compression (optional). If the pixel components are
> + ALAW- or DPCM-compressed, a mention of the compression scheme and the
> + number of bits per compressed pixel component.
>   The number of bus samples per pixel. Pixels that are 
> wider than
>   the bus width must be transferred in multiple samples. Common values are
>   1 and 2.
> @@ -504,6 +504,74 @@
> r1
> r0
>   
> + 
> +   V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8
> +   0x3015
> +   
> +   -
> +   -
> +   -
> +   -
> +   b7
> +   b6
> +   b5
> +   b4
> +   b3
> +   b2
> +   b1
> +   b0
> + 
> + 
> +   V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8
> +   0x3016
> +   
> +   -
> +   -
> +   -
> +   -
> +   g7
> +   g6
> +   g5
> +   g4
> +   g3
> +   g2
> +   g1
> +   g0
> + 
> + 
> +   V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8
> +   0x3017
> +   
> +   -
> +   -
> +   -
> +   -
> +   g7
> +   g6
> +   g5
> +   g4
> +   g3
> +   g2
> +   g1
> +   g0
> + 
> + 
> +   V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8
> +   0x3018
> +   
> +   -
> +   -
> +   -
> +   -
> +   r7
> +   r6
> +   r5
> +   r4
> +   r3
> +   r2
> +   r1
> +   r0
> + 
>   
> V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8
> 0x300b
> @@ -853,10 +921,16 @@
>Packed YUV Formats
>  
>Those data formats transfer pixel data as (possibly downsampled) 
> Y, U
> -  and V components. The format code is made of the following information.
> +  and V components. Some formats include dummy bits in some of their 
> samples
> +  and are collectively referred to as "YDYC" (Y-Dummy-Y-Chroma) formats.
> +  One cannot rely on the values of these dummy bits as those are 
> undefined.
> +  
> +  The format code is made of the following information.
>
>   The Y, U and V components order code, as transferred on 
> the
> - bus. Possible values are YUYV, UYVY, YVYU and VYUY.
> + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no
> + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC 
> formats.
> + 
>   The number of bits per pixel component. All components 
> are
>   transferred on the same number of bits. Common values are 8, 10 and 
> 12.
>   

I dicussed dummy vs. padding (zeros) with Laurent and we concluded we should
use zero padding instead. The difference is that when processing the pixels
no extra operations are necessary to get rid of the dummy data when the
dummy bits are actually zero --- which in practice always is the case.

I'm not aware of hardware that would assign padding bits (in this very
purpose) that are a part of writes the width of bus width something else
than zeros. It wouldn't make much sense either.

So I suggest that dummy is replaced by padding which is defined to be zero.

The letter in the format name could be 'Z', for example.

Hans: what do you think?

Kind regards,

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v2] mt9v032: Export horizontal and vertical blanking as V4L2 controls

2012-07-27 Thread Sakari Ailus 
Hi Laurent,

On Fri, Jul 27, 2012 at 01:02:04AM +0200, Laurent Pinchart wrote:
> On Thursday 26 July 2012 23:54:01 Sakari Ailus wrote:
> > On Tue, Jul 24, 2012 at 01:10:42AM +0200, Laurent Pinchart wrote:
> > > Signed-off-by: Laurent Pinchart 
> > > ---
> > > 
> > >  drivers/media/video/mt9v032.c |   36 +---
> > >  1 files changed, 33 insertions(+), 3 deletions(-)
> > > 
> > > Changes since v1:
> > > 
> > > - Make sure the total horizontal time will not go below 660 when setting
> > >   the horizontal blanking control
> > > 
> > > - Restrict the vertical blanking value to 3000 as documented in the
> > >   datasheet. Increasing the exposure time actually extends vertical
> > >   blanking, as long as the user doesn't forget to turn auto-exposure
> > >   off...
> > 
> > Does binning either horizontally or vertically affect the blanking limits?
> > If the process is analogue then the answer is typically "yes".
> 
> The datasheet doesn't specify whether binning and blanking can influence each 
> other.

Vertical binning is often analogue since digital binning would require as
much temporary memory as the row holds pixels. This means the hardware
already does binning before a/d conversion and there's only need to actually
read half the number of rows, hence the effect on frame length.

> > It's not directly related to this patch, but the effect of the driver just
> > exposing one sub-device really shows better now. Besides lacking the way to
> > specify binning as in the V4L2 subdev API (compose selection target), the
> > user also can't use the crop bounds selection target to get the size of the
> > pixel array.
> > 
> > We could either accept this for the time being and fix it later on of fix it
> > now.
> > 
> > I prefer fixing it right now but admit that this patch isn't breaking
> > anything, it rather is missing quite relevant functionality to control the
> > sensor in a generic way.
> 
> I'd rather apply this patch first, as it doesn't break anything :-) Fixing 
> the 
> problem will require discussions, and that will take time.

How so? There's nothing special in this sensor as far as I can see.

> Binning/skipping is a pretty common feature in sensors. Exposing two sub-
> devices like the SMIA++ driver does is one way to fix the problem, but do we 
> really want to do that for the vast majority of sensors ?

If we want to expose the sensor's functionality using the V4L2 subdev API
and not a sensor specific API, the answer is "yes". The bottom line is that
we have just one API to configure scaling and cropping and that API
(selections) is the same independently of where the operation is being
performed; whether it's the sensor or the ISP.

Kind regards,

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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: does not compile on ubuntu 2.6.32-41-generic

2012-07-27 Thread Hans Verkuil 
On Fri July 27 2012 17:46:45 Eduard Vaks wrote:
> it may be an old compiler I don't know
> also i can't seem to get a diff so i have included the whole file I 
> haven't tested it (well it works on my system but I don' even know if I 
> use that part of the code) but it is realativly minor.
> 
> I have just named the union that func and offset are contained in 
> because the initalizer did not work + other resulting changes:
> struct v4l2_ioctl_info {
>  unsigned int ioctl;
>  u32 flags;
>  const char * const name;
>  union {
>  u32 offset;
>  int (*func)(const struct v4l2_ioctl_ops *ops,
>  struct file *file, void *fh, void *p);
>  } u;
>  void (*debug)(const void *arg, bool write_only);
> };

A patch for this (similar to yours) is waiting to be merged:

http://patchwork.linuxtv.org/patch/13336/

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

cron job: media_tree daily build: ERRORS

2012-07-27 Thread Hans Verkuil 
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:Fri Jul 27 19:00:25 CEST 2012
git hash:931efdf58bd83af8d0578a6cc53421675daf6d41
gcc version:  i686-linux-gcc (GCC) 4.7.1
host hardware:x86_64
host os:  3.4.07-marune

linux-git-arm-eabi-davinci: ERRORS
linux-git-arm-eabi-exynos: OK
linux-git-arm-eabi-omap: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2.1-x86_64: WARNINGS
linux-3.3-x86_64: WARNINGS
linux-3.4-x86_64: WARNINGS
linux-3.5-x86_64: ERRORS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2.1-i686: WARNINGS
linux-3.3-i686: WARNINGS
linux-3.4-i686: WARNINGS
linux-3.5-i686: ERRORS
apps: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2

The V4L-DVB specification from this daily build is here:

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

Re: [PATCH v6] media: Add stk1160 new driver

2012-07-27 Thread Ezequiel Garcia 
Hi Takashi,

On Fri, Jul 27, 2012 at 5:03 AM, Takashi Iwai  wrote:
>>
>> This is achieved through snd_ac97_codec/ac97_bus drivers.
>> Mauro suggested that this ac97 handling should be put
>> inside -alsa tree, but I'm still not sure about it.
>> This approach is working well in practice, but I'm not 100%
>> confident so feedback is welcome (in particular from you alsa guys).
>
> Well, it's a pretty small stuff and ac97 isn't developed so much any
> longer, so I'm fine to put your code in the video tree.
>

Yes, I also feel the same way: it's very small code to be splitted.
Let's wait Mauro to hear his opinion.


> Looking through your patch, a remaining problem is that the dependency
> on the sound core is missing.  The "select" in Kconfig doesn't fulfill
> the dependencies automatically but forcibly sets the value.
>
> Selecting CONFIG_SND_AC97_CODEC will select most of other components
> but CONFIG_SND itself must be enabled beforehand.  Thus, you need to
> wrap CONFIG_VIDEO_STK1160 with "depends on SND".
> Or split the ac97 codec part and makes it depending on SND, and
> define dummy functions if not defined, e.g.
>
> #ifdef CONFIG_VIDEO_STK1160_AC97
> int stk1160_ac97_register(struct stk1160 *dev);
> int stk1160_ac97_unregister(struct stk1160 *dev);
> #else
> static inline int stk1160_ac97_register(struct stk1160 *dev) { return 0; }
> static inline int stk1160_ac97_unregister(struct stk1160 *dev) { return 0; }
> #endif
>

This looks nice.

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

[PATCH v3] cx18: Declare MODULE_FIRMWARE usage

2012-07-27 Thread Tim Gardner 
Cc: Andy Walls 
Cc: Mauro Carvalho Chehab 
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner 
---
 drivers/media/video/cx18/cx18-av-firmware.c |2 ++
 drivers/media/video/cx18/cx18-driver.c  |1 +
 drivers/media/video/cx18/cx18-dvb.c |6 +-
 drivers/media/video/cx18/cx18-firmware.c|   10 --
 4 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/cx18/cx18-av-firmware.c 
b/drivers/media/video/cx18/cx18-av-firmware.c
index 280aa4d..a34fd08 100644
--- a/drivers/media/video/cx18/cx18-av-firmware.c
+++ b/drivers/media/video/cx18/cx18-av-firmware.c
@@ -221,3 +221,5 @@ int cx18_av_loadfw(struct cx18 *cx)
release_firmware(fw);
return 0;
 }
+
+MODULE_FIRMWARE(FWFILE);
diff --git a/drivers/media/video/cx18/cx18-driver.c 
b/drivers/media/video/cx18/cx18-driver.c
index 7e5ffd6..c67733d 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -1357,3 +1357,4 @@ static void __exit module_cleanup(void)
 
 module_init(module_start);
 module_exit(module_cleanup);
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
diff --git a/drivers/media/video/cx18/cx18-dvb.c 
b/drivers/media/video/cx18/cx18-dvb.c
index f41922b..3eac59c 100644
--- a/drivers/media/video/cx18/cx18-dvb.c
+++ b/drivers/media/video/cx18/cx18-dvb.c
@@ -40,6 +40,8 @@
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
+#define FWFILE "dvb-cx18-mpc718-mt352.fw"
+
 #define CX18_REG_DMUX_NUM_PORT_0_CONTROL 0xd5a000
 #define CX18_CLOCK_ENABLE2  0xc71024
 #define CX18_DMUX_CLK_MASK  0x0080
@@ -135,7 +137,7 @@ static int yuan_mpc718_mt352_reqfw(struct cx18_stream 
*stream,
   const struct firmware **fw)
 {
struct cx18 *cx = stream->cx;
-   const char *fn = "dvb-cx18-mpc718-mt352.fw";
+   const char *fn = FWFILE;
int ret;
 
ret = request_firmware(fw, fn, &cx->pci_dev->dev);
@@ -603,3 +605,5 @@ static int dvb_register(struct cx18_stream *stream)
 
return ret;
 }
+
+MODULE_FIRMWARE(FWFILE);
diff --git a/drivers/media/video/cx18/cx18-firmware.c 
b/drivers/media/video/cx18/cx18-firmware.c
index b85c292..a1c1cec 100644
--- a/drivers/media/video/cx18/cx18-firmware.c
+++ b/drivers/media/video/cx18/cx18-firmware.c
@@ -376,6 +376,9 @@ void cx18_init_memory(struct cx18 *cx)
cx18_write_reg(cx, 0x0101, CX18_WMB_CLIENT14);  /* AVO */
 }
 
+#define CX18_CPU_FIRMWARE "v4l-cx23418-cpu.fw"
+#define CX18_APU_FIRMWARE "v4l-cx23418-apu.fw"
+
 int cx18_firmware_init(struct cx18 *cx)
 {
u32 fw_entry_addr;
@@ -400,7 +403,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_sw1_irq_enable(cx, IRQ_CPU_TO_EPU | IRQ_APU_TO_EPU);
cx18_sw2_irq_enable(cx, IRQ_CPU_TO_EPU_ACK | IRQ_APU_TO_EPU_ACK);
 
-   sz = load_cpu_fw_direct("v4l-cx23418-cpu.fw", cx->enc_mem, cx);
+   sz = load_cpu_fw_direct(CX18_CPU_FIRMWARE, cx->enc_mem, cx);
if (sz <= 0)
return sz;
 
@@ -408,7 +411,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_init_scb(cx);
 
fw_entry_addr = 0;
-   sz = load_apu_fw_direct("v4l-cx23418-apu.fw", cx->enc_mem, cx,
+   sz = load_apu_fw_direct(CX18_APU_FIRMWARE, cx->enc_mem, cx,
&fw_entry_addr);
if (sz <= 0)
return sz;
@@ -451,3 +454,6 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_write_reg_expect(cx, 0x14001400, 0xc78110, 0x1400, 0x14001400);
return 0;
 }
+
+MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
+MODULE_FIRMWARE(CX18_APU_FIRMWARE);
-- 
1.7.9.5

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

Re: [PATCH] ivtv: Declare MODULE_FIRMWARE usage

2012-07-27 Thread Tim Gardner 
On 07/26/2012 04:21 PM, Andy Walls wrote:
> On Thu, 2012-07-26 at 12:26 -0600, Tim Gardner wrote:
>> Cc: Andy Walls 
>> Cc: Mauro Carvalho Chehab 
>> Cc: ivtv-de...@ivtvdriver.org
>> Cc: linux-media@vger.kernel.org
>> Signed-off-by: Tim Gardner 
>> ---
>>  drivers/media/video/ivtv/ivtv-firmware.c |4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/media/video/ivtv/ivtv-firmware.c 
>> b/drivers/media/video/ivtv/ivtv-firmware.c
>> index 02c5ade..6ec7705 100644
>> --- a/drivers/media/video/ivtv/ivtv-firmware.c
>> +++ b/drivers/media/video/ivtv/ivtv-firmware.c
>> @@ -396,3 +396,7 @@ int ivtv_firmware_check(struct ivtv *itv, char *where)
>>  
>>  return res;
>>  }
>> +
>> +MODULE_FIRMWARE(CX2341X_FIRM_ENC_FILENAME);
>> +MODULE_FIRMWARE(CX2341X_FIRM_DEC_FILENAME);
>> +MODULE_FIRMWARE(IVTV_DECODE_INIT_MPEG_FILENAME);
> 
> Only the PVR-350, based on the iTVC-15/CX23415 chip, needs the
> CX2341X_FIRM_DEC_FILENAME and IVTV_DECODE_INIT_MPEG_FILENAME.  (And even
> in the case of that card, not having the IVTV_DECODE_INIT_MPEG_FILENAME
> file is non-fatal.)
> 
> I would not want anything in user-space or kernel space preventing the
> ivtv module from loading, if some of those files don't exist.
> 
> Regards,
> Andy
> 

MODULE_FIRMWARE is informational only and has no runtime impact.

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

[RFC PATCH 1/3] dma-fence: dma-buf synchronization (v5)

2012-07-27 Thread Maarten Lankhorst 
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A dma-fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence.

  + dma_fence_signal()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

TODO maybe need some helper fxn for simple devices, like a display-
only drm/kms device which simply wants to wait for exclusive fence to
be signaled, and then attach a non-exclusive fence while scanout is in
progress.

The one pending on the fence can add an async callback (and optionally
cancel it.. for example, to recover from GPU hangs):

  + dma_fence_add_callback()
  + dma_fence_cancel_callback()

Or wait synchronously (optionally with timeout or from atomic context):

  + dma_fence_wait()

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = dma_buf_get_fence(dmabuf);
  if (fence->ops == &bikeshed_fence_ops) {
dma_buf *fence_buf;
dma_bikeshed_fence_get_buf(fence, &fence_buf, &offset);
... tell the hw the memory location to wait on ...
  } else {
/* fall-back to sw sync * /
dma_fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

To facilitate other non-sw implementations, the enable_signaling callback
can be used to keep track if a device not supporting hw sync is waiting
on the fence, and in this case should arrange to call dma_fence_signal()
at some point after the condition has changed, to notify other devices
waiting on the fence.  If there are no sw waiters, this can be skipped to
avoid waking the CPU unnecessarily.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core.  So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
---
 drivers/base/Makefile |2 
 drivers/base/dma-fence.c  |  317 +
 include/linux/dma-fence.h |  123 +
 3 files changed, 441 insertions(+), 1 deletion(-)
 create mode 100644 drivers/base/dma-fence.c
 create mode 100644 include/linux/dma-fence.h

diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 5aa2d70..6e9f217 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
 obj-y  += power/
 obj-$(CONFIG_HAS_DMA)  += dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o
 obj-$(CONFIG_ISA)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-fence.c b/drivers/base/dma-fence.c
new file mode 100644
index 000..6798dc4
--- /dev/null
+++ b/drivers/base/dma-fence.c
@@ -0,0 +1,317 @@
+/*
+ * Fence mechanism for dma-buf to allow for asynchronous dma access
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark

[RFC PATCH 3/3] dma-bikeshed-fence: Hardware dma-buf implementation of fencing

2012-07-27 Thread Maarten Lankhorst 
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
dma_buf[offset] >= value has been met, accounting for wraparound.

A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.

Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.

I extended the original patch by Rob Clark.

Signed-off-by: Maarten Lankhorst 
---
 drivers/base/Makefile  |2 -
 drivers/base/dma-bikeshed-fence.c  |   44 +
 include/linux/dma-bikeshed-fence.h |   92 
 3 files changed, 137 insertions(+), 1 deletion(-)
 create mode 100644 drivers/base/dma-bikeshed-fence.c
 create mode 100644 include/linux/dma-bikeshed-fence.h

diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 6e9f217..1e7723b 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
 obj-y  += power/
 obj-$(CONFIG_HAS_DMA)  += dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-bikeshed-fence.o
 obj-$(CONFIG_ISA)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-bikeshed-fence.c 
b/drivers/base/dma-bikeshed-fence.c
new file mode 100644
index 000..fa063e8
--- /dev/null
+++ b/drivers/base/dma-bikeshed-fence.c
@@ -0,0 +1,44 @@
+/*
+ * dma-fence implementation that supports hw synchronization via hw
+ * read/write of memory semaphore
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+static int enable_signaling(struct dma_fence *fence)
+{
+   struct dma_bikeshed_fence *bikeshed_fence = to_bikeshed_fence(fence);
+   return bikeshed_fence->enable_signaling(bikeshed_fence);
+}
+
+static void bikeshed_release(struct dma_fence *fence)
+{
+   struct dma_bikeshed_fence *f = to_bikeshed_fence(fence);
+
+   if (f->release)
+   f->release(f);
+   dma_buf_put(f->sync_buf);
+}
+
+struct dma_fence_ops dma_bikeshed_fence_ops = {
+   .enable_signaling = enable_signaling,
+   .release = bikeshed_release
+};
+EXPORT_SYMBOL_GPL(dma_bikeshed_fence_ops);
diff --git a/include/linux/dma-bikeshed-fence.h 
b/include/linux/dma-bikeshed-fence.h
new file mode 100644
index 000..4f19801
--- /dev/null
+++ b/include/linux/dma-bikeshed-fence.h
@@ -0,0 +1,92 @@
+/*
+ * dma-fence implementation that supports hw synchronization via hw
+ * read/write of memory semaphore
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#ifndef __DMA_BIKESHED_FENCE_H__
+#define __DMA_BIKESHED_FENCE_H__
+
+#include 
+#include 
+#include 
+
+struct dma_bikeshed_fence {
+   struct dma_fence base;
+
+   struct dma_buf *sync_buf;
+   uint32_t seqno_ofs;
+   uint32_t seqno;
+
+   int (*enable_signaling)(struct dma_bikeshed_fence *fence);
+   void (*release)(struct dma_bikeshed_fence *fence);
+};
+
+/*
+ * TODO does it make sense to be able to enable dma-fence without dma-buf,
+ * or visa versa?
+ */
+#ifdef CONFIG_DMA_SHARED_BUFFER
+
+extern struct dma_fence_ops dma_bikeshed_fence_ops;
+
+static inline bool is_bikeshed_fence(struct dma_fence *fence)
+{
+   return fence->ops == &dma_bikeshed_fence_ops;
+}
+
+static inline struct dma_bikeshed_fence *to_bikeshed_fence(struct dma_fence 
*fence)
+{
+   if (WARN_ON(!is_bikeshed_fence(fence)))
+   return NULL;
+

[RFC PATCH 2/3] dma-buf-mgr: multiple dma-buf synchronization (v2)

2012-07-27 Thread Maarten Lankhorst 
Signed-off-by: Maarten Lankhorst 

dma-buf-mgr handles the case of reserving single or multiple dma-bufs
while trying to prevent deadlocks from buffers being reserved
simultaneously. For this to happen extra functions have been introduced:

  + dma_buf_reserve()
  + dma_buf_unreserve()
  + dma_buf_wait_unreserved()

Reserve a single buffer, optionally with a sequence to indicate this
is part of a multi-dmabuf reservation. This function will return
-EDEADLK and return immediately if reserving would cause a deadlock.
In case a single buffer is being reserved, no sequence is needed,
otherwise please use the dmabufmgr calls.

If you want to attach a exclusive dma-fence, you have to wait
until all shared fences have signalled completion. If there are none,
or if a shared fence has to be attached, wait until last exclusive
fence has signalled completion.

The new fence has to be attached before unreserving the buffer,
and in exclusive mode all previous fences will have be removed
from the buffer, and unreffed when done with it.

dmabufmgr methods:

  + dmabufmgr_reserve_buffers()
This function takes a linked list of dmabufmgr_validate's, each one
requires the following members to be set by the caller:
- validate->head, list head
- validate->bo, must be set to the dma-buf to reserve.
- validate->shared, set to true if opened in shared mode.
- validate->priv, can be used by the caller to identify this buffer.

This function will then set the following members on succesful completion:

- validate->num_fences, amount of valid fences to wait on before this
  buffer can be accessed. This can be 0.
- validate->fences[0...num_fences-1] fences to wait on

  + dmabufmgr_backoff_reservation()
This can be used when the caller encounters an error between reservation
and usage. No new fence will be attached and all reservations will be
undone without side effects.

  + dmabufmgr_fence_buffer_objects
Upon successful completion a new fence will have to be attached.
This function releases old fences and attaches the new one.

  + dmabufmgr_wait_completed_cpu
A simple cpu waiter convenience function. Waits until all fences have
signalled completion before returning.
---
 drivers/base/Makefile   |3 -
 drivers/base/dma-buf-mgr.c  |  230 +++
 drivers/base/dma-buf.c  |  113 +
 drivers/base/dma-fence.c|1 
 include/linux/dma-buf-mgr.h |   97 ++
 include/linux/dma-buf.h |   31 ++
 include/linux/dma-fence.h   |2 
 7 files changed, 475 insertions(+), 2 deletions(-)
 create mode 100644 drivers/base/dma-buf-mgr.c
 create mode 100644 include/linux/dma-buf-mgr.h

diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 1e7723b..819281a 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,8 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
 obj-y  += power/
 obj-$(CONFIG_HAS_DMA)  += dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-bikeshed-fence.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-buf-mgr.o \
+  dma-bikeshed-fence.o
 obj-$(CONFIG_ISA)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-buf-mgr.c b/drivers/base/dma-buf-mgr.c
new file mode 100644
index 000..71b5f96
--- /dev/null
+++ b/drivers/base/dma-buf-mgr.c
@@ -0,0 +1,230 @@
+/*
+ * Copyright (C) 2012 Canonical Ltd
+ *
+ * Based on ttm_bo.c which bears the following copyright notice,
+ * but is dual licensed:
+ *
+ * Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+/*
+ * Authors: Thoma

Re: [RFC PATCH 0/2] Add support for RDS decoding

2012-07-27 Thread Konke Radlow 
Yes, I realized too late that the library header file was missing from the 
submitted patch. I created a additional patch and attached it to the [RFC 
PATCH 1/2] thread.

I updated the repository. It should now be based on the most recent version of 
the tree (I used git://git.linuxtv.org/v4l-utils.git as the origin)

changing the condition in the library header from 
> #if __GNUC__ >= 4
> #define LIBV4L_PUBLIC __attribute__ ((visibility("default")))
> #else
> #define LIBV4L_PUBLIC
> #endif

to 
> #if HAVE_VISIBILITY
> #define LIBV4L_PUBLIC __attribute__ ((visibility("default")))
> #else
> #define LIBV4L_PUBLIC
> #endif

causes linker problems for me. The public library functions can no longer be 
found. I cannot figure out why it's working for programs using libv4l2.la but 
not for programs using libv4l2rds.la

greetings,
Konke 
--
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] cx25840: Declare MODULE_FIRMWARE usage

2012-07-27 Thread Tim Gardner 

On 07/26/2012 03:59 PM, Andy Walls wrote:

On Thu, 2012-07-26 at 10:44 -0600, Tim Gardner wrote:

Cc: Mauro Carvalho Chehab 
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner 
---
  drivers/media/video/cx25840/cx25840-firmware.c |   15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/cx25840/cx25840-firmware.c 
b/drivers/media/video/cx25840/cx25840-firmware.c
index 8150200..b3169f9 100644
--- a/drivers/media/video/cx25840/cx25840-firmware.c
+++ b/drivers/media/video/cx25840/cx25840-firmware.c
@@ -61,6 +61,10 @@ static void end_fw_load(struct i2c_client *client)
cx25840_write(client, 0x803, 0x03);
  }

+#define CX2388x_FIRMWARE "v4l-cx23885-avcore-01.fw"
+#define CX231xx_FIRMWARE "v4l-cx231xx-avcore-01.fw"
+#define CX25840_FIRMWARE "v4l-cx25840.fw"
+
  static const char *get_fw_name(struct i2c_client *client)
  {
struct cx25840_state *state = to_state(i2c_get_clientdata(client));
@@ -68,10 +72,10 @@ static const char *get_fw_name(struct i2c_client *client)
if (firmware[0])
return firmware;
if (is_cx2388x(state))
-   return "v4l-cx23885-avcore-01.fw";
+   return CX2388x_FIRMWARE;
if (is_cx231xx(state))
-   return "v4l-cx231xx-avcore-01.fw";
-   return "v4l-cx25840.fw";
+   return CX231xx_FIRMWARE;
+   return CX25840_FIRMWARE;
  }

  static int check_fw_load(struct i2c_client *client, int size)
@@ -164,3 +168,8 @@ int cx25840_loadfw(struct i2c_client *client)

return check_fw_load(client, size);
  }
+
+MODULE_FIRMWARE(CX2388x_FIRMWARE);
+MODULE_FIRMWARE(CX231xx_FIRMWARE);
+MODULE_FIRMWARE(CX25840_FIRMWARE);
+


How will the firmware attribute in the .module_info section be used?

For any one model of TV capture device, the cx25840 only needs one of
the above firmware files.  The others need not exist.

I would not want anything in user or kernel space to refuse to load the
module just because all 3 firmware files are not present.

Regards,
Andy



The MODULE_FIRMWARE macro is purely informational. Declaring the 
firmware files that the driver _might_ use helps me pare down the 
external firmware package to just those files that I know it must have. 
This patch will have no runtime impact.


Note that there are plenty of uses of the MODULE_FIRMWARE macro within 
the kernel.


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

Re: [PATCH v7 0/2] add dm365 specific media formats

2012-07-27 Thread Laurent Pinchart 
On Friday 27 July 2012 13:30:15 Laurent Pinchart wrote:
> On Friday 27 July 2012 16:25:03 Prabhakar Lad wrote:
> > add mediabus formats and pixel formats supported
> > as part of dm365 vpfe device.
> > The device supports media formats(transfer and storage)
> > which include-
> > 1: ALAW compressed bayer.
> > 2: UV interleaved without Y (for resizer).
> > 3: YDYU
> 
> Acked-by: Prabhakar Lad 

This is obviously a bad copy & paste.

Acked-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

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

Re: [RFC] media DT bindings

2012-07-27 Thread Hans Verkuil 
On Fri July 27 2012 13:26:36 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Tuesday 17 July 2012 21:37:05 Hans Verkuil wrote:
> > On Wed July 11 2012 16:27:52 Guennadi Liakhovetski wrote:
> > > Hi all
> > > 
> > > Background
> > > ==
> > > 
> > > With ARM adoption of flat Device Trees a need arises to move platform
> > > device descriptions and their data from platform files to DT. This has
> > > also to be done for media devices, e.g., video capture and output
> > > interfaces, data processing devices, camera sensors, TV decoders and
> > > encoders. This RFC is trying to spawn a discussion to define standard V4L
> > > DT bindings. The first version will concentrate on the capture path,
> > > mostly taking care of simple capture-interface - camera sensor / TV
> > > decoder configurations. Since the author is not working intensively yet
> > > with the Media Controller API, pad-level configuration, these topics might
> > > be underrepresented in this RFC. I hope others, actively working in these
> > > areas, will fill me in on them.
> > > 
> > > Overview
> > > 
> > > 
> > > As mentioned above, typical configurations, that we'll be dealing with
> > > consist of a DMA data capture engine, one or more data sources like camera
> > > sensors, possibly some data processing units. Data capture and processing
> > > engines are usually platform devices, whereas data source devices are
> > > typically I2C slaves. Apart from defining each device we'll also describe
> > > connections between them as well as properties of those connections.
> > > 
> > > Capture devices
> > > ==
> > > 
> > > These are usually platform devices, integrated into respective SoCs. There
> > > also exist external image processing devices, but they are rare. Obvious
> > > differences between them and integrated devices include a different bus
> > > attribution and a need to explicitly describe the connection to the SoC.
> > > As far as capture devices are concerned, their configuration will
> > > typically include a few device-specific bindings, as well as standard
> > > ones. Standard bindings will include the usual "reg," "interrupts,"
> > > "clock-frequency" properties.
> > > 
> > > It is more complex to describe external links. We need to describe
> > > configurations, used with various devices, attached to various pads. It is
> > > proposed to describe such links as child nodes. Each such link will
> > > reference a client pad, a local pad and specify the bus configuration. The
> > > media bus can be either parallel or serial, e.g., MIPI CSI-2. It is
> > > proposed to describe both the bus-width in the parallel case and the
> > > number of lanes in the serial case, using the standard "bus-width"
> > > property.
> > > 
> > > On the parallel bus common properties include signal polarities, possibly
> > > data line shift (8 if lines 15:8 are used, 2 if 9:2, and 0 if lines 7:0),
> > > protocol (e.g., BT.656). Additionally device-specific properties can be
> > > defined.
> > > 
> > > A MIPI CSI-2 bus common properties would include, apart from the number of
> > > lanes, routed to that client, the clock frequency, a channel number,
> > > possibly CRC and ECC flags.
> > > 
> > > An sh-mobile CEU DT node could look like
> > > 
> > >   ceu0@0xfe91 = {
> > >   
> > >   compatible = "renesas,sh-mobile-ceu";
> > >   reg = <0xfe91 0xa0>;
> > >   interrupts = <0x880>;
> > >   bus-width = <16>;   /* #lines routed on the board */
> > >   clock-frequency = <5000>;   /* max clock */
> > >   #address-cells = <1>;
> > >   #size-cells = <0>;
> > >   ...
> > >   ov772x-1 = {
> > >   
> > >   reg = <0>;
> > >   client = <&ov772x@0x21-0>;
> > >   local-pad = "parallel-sink";
> > >   remote-pad = "parallel-source";
> > >   bus-width = <8>;/* used data lines */
> > >   data-shift = <0>;   /* lines 7:0 are used */
> > >   hsync-active = <1>; /* active high */
> > >   vsync-active = <1>; /* active high */
> > >   pclk-sample = <1>;  /* rising */
> > >   clock-frequency = <2400>;
> > >   
> > >   };
> > >   
> > >   };
> > > 
> > > Client devices
> > > ==
> > > 
> > > Client nodes are children on their respective busses, e.g., i2c. This
> > > placement leads to these devices being possibly probed before respective
> > > host interfaces, which will fail due to known reasons. Therefore client
> > > drivers have to be adapted to request a delayed probing, as long as the
> > > respective video host hasn't probed.
> > > 
> > > Client nodes will include all the properties, usual for their busses.
> > > Additionally they will specify properties private to this device type and
> > > common for all V4L2 client devices - devi

Re: [PATCH v7 0/2] add dm365 specific media formats

2012-07-27 Thread Laurent Pinchart 
On Friday 27 July 2012 16:25:03 Prabhakar Lad wrote:
> add mediabus formats and pixel formats supported
> as part of dm365 vpfe device.
> The device supports media formats(transfer and storage)
> which include-
> 1: ALAW compressed bayer.
> 2: UV interleaved without Y (for resizer).
> 3: YDYU

Acked-by: Prabhakar Lad 

-- 
Regards,

Laurent Pinchart

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

Re: [RFC] omap3-isp G_FMT & ENUM_FMT

2012-07-27 Thread Michael Jones 

Hi Laurent,

On 07/27/2012 11:35 AM, Laurent Pinchart wrote:

On Friday 27 July 2012 11:07:50 Michael Jones wrote:

Hi Laurent,

On 07/27/2012 01:32 AM, Laurent Pinchart wrote:

Hi Michael,

[snip]

OK, so this sounds like the same behavior I'd like to add before
CREATE_BUFS and PREPARE_BUFS support is in.  My other question was if
this is the case, can we use my approach until your planned changes are in?


We can't, as it would break the use case of preallocating buffers without
providing any alternative solution. That's why I haven't fixed the
G_FMT/S_FMT/ENUM_FMT issue yet.



OK, now I understand.  Thanks for clarifying.

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] media DT bindings

2012-07-27 Thread Laurent Pinchart 
Hi Hans,

On Tuesday 17 July 2012 21:37:05 Hans Verkuil wrote:
> On Wed July 11 2012 16:27:52 Guennadi Liakhovetski wrote:
> > Hi all
> > 
> > Background
> > ==
> > 
> > With ARM adoption of flat Device Trees a need arises to move platform
> > device descriptions and their data from platform files to DT. This has
> > also to be done for media devices, e.g., video capture and output
> > interfaces, data processing devices, camera sensors, TV decoders and
> > encoders. This RFC is trying to spawn a discussion to define standard V4L
> > DT bindings. The first version will concentrate on the capture path,
> > mostly taking care of simple capture-interface - camera sensor / TV
> > decoder configurations. Since the author is not working intensively yet
> > with the Media Controller API, pad-level configuration, these topics might
> > be underrepresented in this RFC. I hope others, actively working in these
> > areas, will fill me in on them.
> > 
> > Overview
> > 
> > 
> > As mentioned above, typical configurations, that we'll be dealing with
> > consist of a DMA data capture engine, one or more data sources like camera
> > sensors, possibly some data processing units. Data capture and processing
> > engines are usually platform devices, whereas data source devices are
> > typically I2C slaves. Apart from defining each device we'll also describe
> > connections between them as well as properties of those connections.
> > 
> > Capture devices
> > ==
> > 
> > These are usually platform devices, integrated into respective SoCs. There
> > also exist external image processing devices, but they are rare. Obvious
> > differences between them and integrated devices include a different bus
> > attribution and a need to explicitly describe the connection to the SoC.
> > As far as capture devices are concerned, their configuration will
> > typically include a few device-specific bindings, as well as standard
> > ones. Standard bindings will include the usual "reg," "interrupts,"
> > "clock-frequency" properties.
> > 
> > It is more complex to describe external links. We need to describe
> > configurations, used with various devices, attached to various pads. It is
> > proposed to describe such links as child nodes. Each such link will
> > reference a client pad, a local pad and specify the bus configuration. The
> > media bus can be either parallel or serial, e.g., MIPI CSI-2. It is
> > proposed to describe both the bus-width in the parallel case and the
> > number of lanes in the serial case, using the standard "bus-width"
> > property.
> > 
> > On the parallel bus common properties include signal polarities, possibly
> > data line shift (8 if lines 15:8 are used, 2 if 9:2, and 0 if lines 7:0),
> > protocol (e.g., BT.656). Additionally device-specific properties can be
> > defined.
> > 
> > A MIPI CSI-2 bus common properties would include, apart from the number of
> > lanes, routed to that client, the clock frequency, a channel number,
> > possibly CRC and ECC flags.
> > 
> > An sh-mobile CEU DT node could look like
> > 
> > ceu0@0xfe91 = {
> > 
> > compatible = "renesas,sh-mobile-ceu";
> > reg = <0xfe91 0xa0>;
> > interrupts = <0x880>;
> > bus-width = <16>;   /* #lines routed on the board */
> > clock-frequency = <5000>;   /* max clock */
> > #address-cells = <1>;
> > #size-cells = <0>;
> > ...
> > ov772x-1 = {
> > 
> > reg = <0>;
> > client = <&ov772x@0x21-0>;
> > local-pad = "parallel-sink";
> > remote-pad = "parallel-source";
> > bus-width = <8>;/* used data lines */
> > data-shift = <0>;   /* lines 7:0 are used */
> > hsync-active = <1>; /* active high */
> > vsync-active = <1>; /* active high */
> > pclk-sample = <1>;  /* rising */
> > clock-frequency = <2400>;
> > 
> > };
> > 
> > };
> > 
> > Client devices
> > ==
> > 
> > Client nodes are children on their respective busses, e.g., i2c. This
> > placement leads to these devices being possibly probed before respective
> > host interfaces, which will fail due to known reasons. Therefore client
> > drivers have to be adapted to request a delayed probing, as long as the
> > respective video host hasn't probed.
> > 
> > Client nodes will include all the properties, usual for their busses.
> > Additionally they will specify properties private to this device type and
> > common for all V4L2 client devices - device global and per-link. I think,
> > we should make it possible to define client devices, that can at run-time
> > be connected to different sinks, even though such configurations might not
> > be very fre

Re: [RFC] media DT bindings

2012-07-27 Thread Laurent Pinchart 
Hi Sylwester,

On Wednesday 18 July 2012 19:00:15 Sylwester Nawrocki wrote:
> On 07/16/2012 01:41 PM, Guennadi Liakhovetski wrote:
> [...]
> 
> >> On 07/11/2012 04:27 PM, Guennadi Liakhovetski wrote:
> >>> Hi all
> >>> 
> >>> Background
> >>> ==
> >>> 
> >>> With ARM adoption of flat Device Trees a need arises to move platform
> >>> device descriptions and their data from platform files to DT. This has
> >>> also to be done for media devices, e.g., video capture and output
> >>> interfaces, data processing devices, camera sensors, TV decoders and
> >>> encoders. This RFC is trying to spawn a discussion to define standard
> >>> V4L DT bindings. The first version will concentrate on the capture path,
> >>> mostly taking care of simple capture-interface - camera sensor / TV
> >>> decoder configurations. Since the author is not working intensively yet
> >>> with the Media Controller API, pad-level configuration, these topics
> >>> might be underrepresented in this RFC. I hope others, actively working
> >>> in these areas, will fill me in on them.
> >> 
> >> We've done some work on device tree support for SoC camera interface
> >> with driver based on the Media Controller API, I've posted some RFC
> >> patches a few weeks ago:
> >> http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg14769.
> >> html But unfortunately didn't receive any comments,
> > 
> > You have now ;-)
>
> :)
>
> >> perhaps because the actual
> >> bindings were not abstracted enough from a specific hardware support.
> >> An updated version of these patch set can be found here:
> >> https://github.com/snawrocki/linux/commits/camera-of-2
> >> 
> >> Of course we shouldn't be forgetting that underlying bindings need to
> >> be the same, regardless of the drivers are based on soc_camera, Media
> >> Controller/subdev pad-level frameworks, or something else.
> > 
> > Of course, the more properties are common - the better. I also made sure
> > not to introduce any soc-camera specific properties. But since I mostly
> > work with those systems, I am not fully aware of requirements, imposed by
> > other hardware types, so, I hope others will contribute to this work:-)
> > 
> >> Anything linux specific in the bindings would be inappropriate.
> > 
> > Not sure what you mean here - which Linux specific bindings and why they
> > wouldn't be appropriate? Don't think our bindings would be used by any
> > other OS kernels.
> 
> The bindings should be OS agnostic, so they can be used by other operating
> systems and bootloaders. That's one of fundamental FDT assumptions, AFAIU.
> 
> It is outlined in this presentation (slide 22):
> http://events.linuxfoundation.org/images/stories/pdf/lf_elc12_abraham.pdf
> 
> >>> Overview
> >>> 
> >>> 
> >>> As mentioned above, typical configurations, that we'll be dealing with
> >>> consist of a DMA data capture engine, one or more data sources like
> >>> camera
> >>> sensors, possibly some data processing units. Data capture and
> >>> processing
> >>> engines are usually platform devices, whereas data source devices are
> >>> typically I2C slaves. Apart from defining each device we'll also
> >>> describe
> >>> connections between them as well as properties of those connections.
> >>> 
> >>> Capture devices
> >>> ==
> >>> 
> >>> These are usually platform devices, integrated into respective SoCs.
> >>> There also exist external image processing devices, but they are rare.
> >>> Obvious differences between them and integrated devices include a
> >>> different bus attribution and a need to explicitly describe the
> >>> connection to the SoC. As far as capture devices are concerned, their
> >>> configuration will typically include a few device-specific bindings, as
> >>> well as standard ones. Standard bindings will include the usual "reg,"
> >>> "interrupts," "clock-frequency" properties.
> >>> 
> >>> It is more complex to describe external links. We need to describe
> >>> configurations, used with various devices, attached to various pads. It
> >>> is proposed to describe such links as child nodes. Each such link will
> >>> reference a client pad, a local pad and specify the bus configuration.
> >>> The media bus can be either parallel or serial, e.g., MIPI CSI-2. It is
> >>> proposed to describe both the bus-width in the parallel case and the
> >>> number of lanes in the serial case, using the standard "bus-width"
> >>> property.
> >>> 
> >>> On the parallel bus common properties include signal polarities,
> >>> possibly data line shift (8 if lines 15:8 are used, 2 if 9:2, and 0 if
> >>> lines 7:0), protocol (e.g., BT.656). Additionally device-specific
> >>> properties can be defined.
> >>> 
> >>> A MIPI CSI-2 bus common properties would include, apart from the number
> >>> of lanes, routed to that client, the clock frequency, a channel number,
> >>> possibly CRC and ECC flags.
> >>> 
> >>> An sh-mobile CEU DT node could look like
> >>> 
> >>>   ceu0@0xfe91 = {
> >

[PATCH v7 2/2] v4l2: add new pixel formats supported on dm365

2012-07-27 Thread Prabhakar Lad 
From: Manjunath Hadli 

add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
to represent Bayer format frames compressed by A-LAW algorithm,
add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved)
only.

Signed-off-by: Manjunath Hadli 
Signed-off-by: Lad, Prabhakar 
Cc: Laurent Pinchart 
Cc: Sakari Ailus 
Cc: Hans Verkuil 
Cc: Guennadi Liakhovetski 
---
 .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml  |   34 +++
 Documentation/DocBook/media/v4l/pixfmt-uv8.xml |   62 
 Documentation/DocBook/media/v4l/pixfmt.xml |2 +
 include/linux/videodev2.h  |8 +++
 4 files changed, 106 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml

diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml 
b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
new file mode 100644
index 000..c934192
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+   
+ 
+   
+ V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
+ V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
+ V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
+ V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
+   
+   &manvol;
+ 
+ 
+   
+ V4L2_PIX_FMT_SBGGR10ALAW8
+   
+   
+ V4L2_PIX_FMT_SGBRG10ALAW8
+   
+   
+ V4L2_PIX_FMT_SGRBG10ALAW8
+   
+   
+ V4L2_PIX_FMT_SRGGB10ALAW8
+   
+   10-bit Bayer formats compressed to 8 bits
+ 
+ 
+   Description
+   The following four pixel formats are raw sRGB / Bayer
+   formats with 10 bits per color compressed to 8 bits each,
+   using the A-LAW algorithm. Each color component consumes 8
+   bits of memory. In other respects this format is similar to
+   .
+ 
+   
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml 
b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
new file mode 100644
index 000..c507c1f
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
@@ -0,0 +1,62 @@
+   
+ 
+   V4L2_PIX_FMT_UV8  ('UV8')
+   &manvol;
+ 
+ 
+   V4L2_PIX_FMT_UV8
+   UV plane interleaved
+ 
+ 
+   Description
+   In this format there is no Y plane, Only CbCr plane. ie
+   (UV interleaved)
+   
+   
+ V4L2_PIX_FMT_UV8
+  pixel image
+   
+
+   
+ Byte Order.
+ Each cell is one byte.
+   
+   
+ 
+ 
+   
+ start + 0:
+ Cb00
+ Cr00
+ Cb01
+ Cr01
+   
+   
+ start + 4:
+ Cb10
+ Cr10
+ Cb11
+ Cr11
+   
+   
+ start + 8:
+ Cb20
+ Cr20
+ Cb21
+ Cr21
+   
+   
+ start + 12:
+ Cb30
+ Cr30
+ Cb31
+ Cr31
+   
+ 
+   
+   
+ 
+ 
+   
+ 
+   
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index e58934c..930f55d 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the 
Linux framebuffer API.<
 &sub-srggb8;
 &sub-sbggr16;
 &sub-srggb10;
+&sub-srggb10alaw8;
 &sub-srggb10dpcm8;
 &sub-srggb12;
   
@@ -701,6 +702,7 @@ information.
 &sub-y12;
 &sub-y10b;
 &sub-y16;
+&sub-uv8;
 &sub-yuyv;
 &sub-uyvy;
 &sub-yvyu;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 5d78910..2cdf2c1 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -329,6 +329,9 @@ struct v4l2_pix_format {
 /* Palette formats */
 #define V4L2_PIX_FMT_PAL8v4l2_fourcc('P', 'A', 'L', '8') /*  8  8-bit 
palette */
 
+/* Chrominance formats */
+#define V4L2_PIX_FMT_UV8  v4l2_fourcc('U', 'V', '8', ' ') /*  8  UV 4:4 */
+
 /* Luminance+Chrominance formats */
 #define V4L2_PIX_FMT_YVU410  v4l2_fourcc('Y', 'V', 'U', '9') /*  9  YVU 4:1:0  
   */
 #define V4L2_PIX_FMT_YVU420  v4l2_fourcc('Y', 'V', '1', '2') /* 12  YVU 4:2:0  
   */
@@ -378,6 +381,11 @@ struct v4l2_pix

[PATCH v7 1/2] media: add new mediabus format enums for dm365

2012-07-27 Thread Prabhakar Lad 
From: Manjunath Hadli 

add new enum entries for supporting the media-bus formats on dm365.
These include some bayer and some non-bayer formats.
V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used
internal to the hardware by the resizer.
V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format
that is supported by dm365 hardware.

Acked-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
Signed-off-by: Manjunath Hadli 
Signed-off-by: Lad, Prabhakar 
Cc: Sakari Ailus 
Cc: Guennadi Liakhovetski 
---
 Documentation/DocBook/media/v4l/subdev-formats.xml |  250 +++-
 include/linux/v4l2-mediabus.h  |   10 +-
 2 files changed, 252 insertions(+), 8 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 49c532e..75dc275 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -353,9 +353,9 @@
The number of bits per pixel component. All components 
are
transferred on the same number of bits. Common values are 8, 10 and 
12.

-   If the pixel components are DPCM-compressed, a mention 
of the
-   DPCM compression and the number of bits per compressed pixel 
component.
-   
+   The compression (optional). If the pixel components are
+   ALAW- or DPCM-compressed, a mention of the compression scheme and the
+   number of bits per compressed pixel component.
The number of bus samples per pixel. Pixels that are 
wider than
the bus width must be transferred in multiple samples. Common values are
1 and 2.
@@ -504,6 +504,74 @@
  r1
  r0

+   
+ V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8
+ 0x3015
+ 
+ -
+ -
+ -
+ -
+ b7
+ b6
+ b5
+ b4
+ b3
+ b2
+ b1
+ b0
+   
+   
+ V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8
+ 0x3016
+ 
+ -
+ -
+ -
+ -
+ g7
+ g6
+ g5
+ g4
+ g3
+ g2
+ g1
+ g0
+   
+   
+ V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8
+ 0x3017
+ 
+ -
+ -
+ -
+ -
+ g7
+ g6
+ g5
+ g4
+ g3
+ g2
+ g1
+ g0
+   
+   
+ V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8
+ 0x3018
+ 
+ -
+ -
+ -
+ -
+ r7
+ r6
+ r5
+ r4
+ r3
+ r2
+ r1
+ r0
+   

  V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8
  0x300b
@@ -853,10 +921,16 @@
   Packed YUV Formats
 
   Those data formats transfer pixel data as (possibly downsampled) 
Y, U
-  and V components. The format code is made of the following information.
+  and V components. Some formats include dummy bits in some of their 
samples
+  and are collectively referred to as "YDYC" (Y-Dummy-Y-Chroma) formats.
+  One cannot rely on the values of these dummy bits as those are undefined.
+  
+  The format code is made of the following information.
   
The Y, U and V components order code, as transferred on 
the
-   bus. Possible values are YUYV, UYVY, YVYU and VYUY.
+   bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no
+   dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC 
formats.
+   
The number of bits per pixel component. All components 
are
transferred on the same number of bits. Common values are 8, 10 and 
12.

@@ -877,7 +951,21 @@
   U, Y, V, Y order will be named 
V4L2_MBUS_FMT_UYVY8_2X8.
   
 
-  The following table lisst existing packet YUV formats.
+list existing packet 
YUV
+   formats and describes the organization of each pixel data in each 
sample.
+   When a format pattern is split across multiple samples each of the 
samples
+   in the pattern is described.
+
+   The role of each bit transferred over the bus is identified by one
+   of the following codes.
+
+   
+  yx for luma component bit 
number x
+  ux for blue chroma component 
bit number x
+  vx for red chroma component 
bit number x
+  - for non-available bits (for positions higher than 
the bus width)
+  d for dummy bits
+   
 
   
YUV Formats
@@ -965,6 +1053,56 @@
  y1
  y0

+   
+ V4L2_MBUS_FMT_UV8_1X8
+ 0x201

[PATCH v7 0/2] add dm365 specific media formats

2012-07-27 Thread Prabhakar Lad 
add mediabus formats and pixel formats supported
as part of dm365 vpfe device.
The device supports media formats(transfer and storage)
which include-
1: ALAW compressed bayer.
2: UV interleaved without Y (for resizer).
3: YDYU

Changes for v7:
1: Fixed a comment from Laurent, removed subscript for 
   dummy tags.
2: Fixed a comment from Sakari, used the same order for
   ALAW pix fmt according to Documentation/video4linux/4CCs.txt.

Changes for v6:
1: Fixed a comment from Hans, replaced "YUYDYDYV and YVYDYDYU"
   to "YUYDYVYD and YVYDYUYD".

Changes for v5:
1: Fixed comment from Laurent, moved ALAW format above DPCM
   format to keep the alphabetically sorted, grouped textual
   description for ALAW and DPCM compression, as they're mutally
   exclusive, Changed V4L2_MBUS_FMT_YDYC8_1X16 to
   V4L2_MBUS_FMT_YDYUYDYV8_1X16.

Changes for v4:
1: Rebased the patch set on Sakari's branch
(http://git.linuxtv.org/sailus/media_tree.git/shortlog/refs/heads/media-for-3.4)
   mainly because of this patch
   http://www.spinics.net/lists/linux-media/msg44871.html>
2: Fixed comments from Sakari, changed description for
   UV8, and re-arranged &sub-uv8; in
   Documentation/DocBook/media/v4l/pixfmt.xml file.

Changes for v3:
1: Added 4cc code for A-law compressed format as per
  specified in documentation,
  http://www.spinics.net/lists/linux-media/msg43890.html

Changes for v2:
1: Added entries in subdev-formats.xml for
 V4L2_MBUS_FMT_YDYC8_1X16, V4L2_MBUS_FMT_UV8_1X8,
 V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8,
 V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8,
 V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8,
 V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8.
2: Added documentation of ALAW and UV8 pix format.

Manjunath Hadli (2):
  media: add new mediabus format enums for dm365
  v4l2: add new pixel formats supported on dm365

 .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml  |   34 +++
 Documentation/DocBook/media/v4l/pixfmt-uv8.xml |   62 +
 Documentation/DocBook/media/v4l/pixfmt.xml |2 +
 Documentation/DocBook/media/v4l/subdev-formats.xml |  250 +++-
 include/linux/v4l2-mediabus.h  |   10 +-
 include/linux/videodev2.h  |8 +
 6 files changed, 358 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml

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

Re: [PATCH] [media] davinci: vpfe: Add documentation

2012-07-27 Thread Laurent Pinchart 
Hi Manjunath,

On Friday 27 July 2012 05:49:24 Hadli, Manjunath wrote:
> On Thu, Jul 26, 2012 at 05:55:31, Laurent Pinchart wrote:
> > On Tuesday 17 July 2012 10:43:54 Hadli, Manjunath wrote:
> > > On Sun, Jul 15, 2012 at 18:16:25, Laurent Pinchart wrote:
> > > > On Wednesday 11 July 2012 21:09:26 Manjunath Hadli wrote:
> > > > > Add documentation on the Davinci VPFE driver. Document the subdevs,
> > > > > and private IOTCLs the driver implements
> > > > > 
> > > > > Signed-off-by: Manjunath Hadli 
> > > > > Signed-off-by: Lad, Prabhakar 
> > 
> > [snip]
> > 
> > > > > +Private IOCTLs
> > > > > +==
> > > > > +
> > > > > +The Davinci Video processing Front End (VPFE) driver supports
> > > > > standard V4L2
> > > > > +IOCTLs and controls where possible and practical. Much of the
> > > > > functions provided
> > > > > +by the VPFE, however, does not fall under the standard IOCTLs.
> > > > > +
> > > > > +In general, there is a private ioctl for configuring each of the
> > > > > blocks
> > > > > +containing hardware-dependent functions.
> > > > > +
> > > > > +The following private IOCTLs are supported:
> > > > > +
> > > > > +1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
> > > > > +Description:
> > > > > + Sets/Gets the parameters required by the previewer module
> > > > > +Parameter:
> > > > > + /**
> > > > > +  * struct prev_module_param- structure to configure preview
> > > > > modules
> > > > > +  * @version: Version of the preview module
> > > > 
> > > > Who is responsible for filling this field, the application or the
> > > > driver ?
> > > 
> > > The application is responsible for filling this info. He would enumerate
> > > the capabilities first and  set them using S_PARAM/G_PARAM.
> > 
> > And what's the point of the application setting the version field ? How
> > does the driver use it ?
> 
> The version may not be required. Will remove it.
> 
> > > > > +  * @len: Length of the module config structure
> > > > > +  * @module_id: Module id
> > > > > +  * @param: pointer to module config parameter.
> > > > 
> > > > What is module_id for ? What does param point to ?
> > > 
> > > There are a lot of tiny modules in the previewer/resizer which are
> > > enumerated as individual modules. The param points to the parameter set
> > > that the module expects to be set.
> > 
> > Why don't you implement something similar to
> > VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS instead ?
> 
> I feel if we implement direct IOCTLS there might be many of them. To make
> sure than independent of the number of internal modules present, having the
> same IOCTL used for all modules is a good idea.

You can set several parameters using a single ioctl, much like 
VPFE_CMD_S_CCDC_RAW_PARAMS does. You don't need one ioctl per parameter. 

PREV_ENUM_CAP, PREV_[GS]_PARAM and PREV_[GS]_CONFIG are essentially 
reinventing V4L2 controls, and I don't think that's a good idea.

> > > > > +  */
> > > > > + struct prev_module_param {
> > > > > + char version[IMP_MAX_NAME_SIZE];
> > > > 
> > > > Is there a need to express the version as a string instead of an
> > > > integer ?
> > > 
> > > It could be integer. It is generally a fixed point num, and easy to read
> > > it as a string than an integer. Can I keep it as a string?
> > 
> > Let's first decide whether a version field is needed at all :-)
> 
> Will remove.
> 
> > > > > + unsigned short len;
> > > > > + unsigned short module_id;
> > > > > + void *param;
> > > > > + };
> > > > > +
> > > > > +2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
> > > > > +Description:
> > > > > + Sets/Gets the configuration required by the previewer channel
> > > > > +Parameter:
> > > > > + /**
> > > > > +  * struct prev_channel_config - structure for configuring the
> > > > > previewer
> > > > > channel
> > > > > +  * @len: Length of the user configuration
> > > > > +  * @config: pointer to either single shot config or continuous
> > > > > +  */
> > > > > + struct prev_channel_config {
> > > > > + unsigned short len;
> > > > > + void *config;
> > > > > + };
> > > > 
> > > > What's the difference between parameters and configuration ? What does
> > > > config point to ?
> > > 
> > > Config is setting which is required for a subdev to function based on
> > > what it is set for (single shot/continuous.) common to all platforms.
> > > Parameters are the settings for individual small sub-ips which might be
> > > slightly different from one platform to another. Config points to
> > > prev_single_shot_config or  prev_continuous_config currently defined in
> > > linux/dm3656ipipe.h. I think we will move it to a common location.
> > 
> > Why don't you implement something similar to
> > VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS here as well (same
> > for the resizer configuration ioctls) ?
> 
> Ditto.
> 
> > > > > +
> > > > > +3: IOCTL: PREV_ENUM_CAP
> > > > > +De

[GIT PULL FOR 3.6] V4L2 mem-to-mem device capability flags

2012-07-27 Thread Sylwester Nawrocki 
Hi Mauro,

The following changes since commit 931efdf58bd83af8d0578a6cc53421675daf6d41:

  Merge branch 'v4l_for_linus' into staging/for_v3.6 (2012-07-14 15:45:44 -0300)

are available in the git repository at:


  git://git.infradead.org/users/kmpark/linux-samsung v4l_m2m_capabilities

for you to fetch changes up to 633157172d8c36482f2f88253ac9c49ddc267c8e:

  Feature removal: using capture and output capabilities for m2m devices 
(2012-07-26 14:30:50 +0200)

This is an addition of new V4L2 capability flags for mem-to-mem devices.


Sylwester Nawrocki (2):
  V4L: Add capability flags for memory-to-memory devices
  Feature removal: using capture and output capabilities for m2m devices

 Documentation/DocBook/media/v4l/compat.xml  |9 +
 Documentation/DocBook/media/v4l/vidioc-querycap.xml |   13 +
 Documentation/feature-removal-schedule.txt  |   14 ++
 drivers/media/video/mem2mem_testdev.c   |4 +---
 drivers/media/video/mx2_emmaprp.c   |   10 +++---
 drivers/media/video/s5p-fimc/fimc-m2m.c |7 ++-
 drivers/media/video/s5p-g2d/g2d.c   |9 +++--
 drivers/media/video/s5p-jpeg/jpeg-core.c|   10 +++---
 drivers/media/video/s5p-mfc/s5p_mfc_dec.c   |   10 --
 drivers/media/video/s5p-mfc/s5p_mfc_enc.c   |   11 ---
 include/linux/videodev2.h   |4 
 11 files changed, 84 insertions(+), 17 deletions(-)


Regards,
-- 
Sylwester Nawrocki
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: [RFC] omap3-isp G_FMT & ENUM_FMT

2012-07-27 Thread Laurent Pinchart 
On Friday 27 July 2012 11:07:50 Michael Jones wrote:
> Hi Laurent,
> 
> On 07/27/2012 01:32 AM, Laurent Pinchart wrote:
> > Hi Michael,
> > 
> > On Thursday 26 July 2012 16:22:17 Michael Jones wrote:
> >> On 07/26/2012 04:05 PM, Laurent Pinchart wrote:
> >>> On Thursday 26 July 2012 13:59:54 Michael Jones wrote:
>  Hello,
>  
>  I would like to (re)submit a couple of patches to support V4L2 behavior
>  at the V4L2 device nodes of the omap3-isp driver, but I'm guessing they
>  require some discussion first.
> >>> 
> >>> Indeed.
> >>> 
> >>> The main reason why the OMAP3 ISP driver implements G_FMT/S_FMT as it
> >>> does today is to hack around a restriction in the V4L2 API. We needed a
> >>> way to preallocate and possibly prequeue buffers for snapshot, which
> >>> wasn't possible in a standard-compliant way back then.
> >>> 
> >>> The situation has since changed, and we now have the VIDIOC_CREATE_BUFS
> >>> and VIDIOC_PREPARE_BUF ioctls. My plan is to
> >>> 
> >>> - port the OMAP3 ISP driver to videobuf2
> >>> - implement support for CREATE_BUFS and PREPARE_BUF
> >>> - fix the G_FMT/S_FMT/ENUM_FMT behaviour
> >> 
> >> What will the G_FMT/S_FMT/ENUM_FMT behavior be then?  Can you contrast
> >> it with the behavior of my patches?  If the behavior will be the same
> >> for user space, and your proposed changes won't be in very soon, can we
> >> use my patches until you make your changes?
> > 
> > At the moment the driver accepts any format you give it in a S_FMT call,
> > regardless of the format of the connected pad. The reason for that is to
> > allow VIDIOC_REQBUFS to allocate buffers for an arbitrary size.
> > 
> > With CREATE_BUFS and PREPARE_BUFS support, G_FMT, S_FMT and ENUM_FMT
> > should return the format of the connected pad.
> 
> OK, so this sounds like the same behavior I'd like to add before
> CREATE_BUFS and PREPARE_BUFS support is in.  My other question was if
> this is the case, can we use my approach until your planned changes are in?

We can't, as it would break the use case of preallocating buffers without 
providing any alternative solution. That's why I haven't fixed the 
G_FMT/S_FMT/ENUM_FMT issue yet.

-- 
Regards,

Laurent Pinchart

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

Re: [RFC] omap3-isp G_FMT & ENUM_FMT

2012-07-27 Thread Michael Jones 

Hi Laurent,

On 07/27/2012 01:32 AM, Laurent Pinchart wrote:

Hi Michael,

On Thursday 26 July 2012 16:22:17 Michael Jones wrote:

On 07/26/2012 04:05 PM, Laurent Pinchart wrote:

On Thursday 26 July 2012 13:59:54 Michael Jones wrote:

Hello,

I would like to (re)submit a couple of patches to support V4L2 behavior
at the V4L2 device nodes of the omap3-isp driver, but I'm guessing they
require some discussion first.


Indeed.

The main reason why the OMAP3 ISP driver implements G_FMT/S_FMT as it does
today is to hack around a restriction in the V4L2 API. We needed a way to
preallocate and possibly prequeue buffers for snapshot, which wasn't
possible in a standard-compliant way back then.

The situation has since changed, and we now have the VIDIOC_CREATE_BUFS
and VIDIOC_PREPARE_BUF ioctls. My plan is to

- port the OMAP3 ISP driver to videobuf2
- implement support for CREATE_BUFS and PREPARE_BUF
- fix the G_FMT/S_FMT/ENUM_FMT behaviour


What will the G_FMT/S_FMT/ENUM_FMT behavior be then?  Can you contrast
it with the behavior of my patches?  If the behavior will be the same
for user space, and your proposed changes won't be in very soon, can we
use my patches until you make your changes?


At the moment the driver accepts any format you give it in a S_FMT call,
regardless of the format of the connected pad. The reason for that is to allow
VIDIOC_REQBUFS to allocate buffers for an arbitrary size.

With CREATE_BUFS and PREPARE_BUFS support, G_FMT, S_FMT and ENUM_FMT should
return the format of the connected pad.



OK, so this sounds like the same behavior I'd like to add before 
CREATE_BUFS and PREPARE_BUFS support is in.  My other question was if 
this is the case, can we use my approach until your planned changes are in?


-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6] media: Add stk1160 new driver

2012-07-27 Thread Takashi Iwai 
At Thu, 26 Jul 2012 21:15:22 -0300,
Ezequiel Garcia wrote:
> 
> This driver adds support for stk1160 usb bridge as used in some
> video/audio usb capture devices.
> It is a complete rewrite of staging/media/easycap driver and
> it's expected as a future replacement.
> 
> Cc: Mauro Carvalho Chehab 
> Cc: Takashi Iwai 
> Cc: Hans Verkuil 
> Cc: Sylwester Nawrocki 
> Signed-off-by: Ezequiel Garcia 
> ---
> 
> Here we are once again,
> 
> As stk1160 allows communication with an ac97 codec chip, this
> driver registers a control-only sound card to allow the user
> to access ac97 controls.
> 
> This is achieved through snd_ac97_codec/ac97_bus drivers.
> Mauro suggested that this ac97 handling should be put
> inside -alsa tree, but I'm still not sure about it.
> This approach is working well in practice, but I'm not 100%
> confident so feedback is welcome (in particular from you alsa guys).

Well, it's a pretty small stuff and ac97 isn't developed so much any
longer, so I'm fine to put your code in the video tree.

Looking through your patch, a remaining problem is that the dependency
on the sound core is missing.  The "select" in Kconfig doesn't fulfill
the dependencies automatically but forcibly sets the value. 

Selecting CONFIG_SND_AC97_CODEC will select most of other components
but CONFIG_SND itself must be enabled beforehand.  Thus, you need to
wrap CONFIG_VIDEO_STK1160 with "depends on SND".
Or split the ac97 codec part and makes it depending on SND, and
define dummy functions if not defined, e.g.

#ifdef CONFIG_VIDEO_STK1160_AC97
int stk1160_ac97_register(struct stk1160 *dev);
int stk1160_ac97_unregister(struct stk1160 *dev);
#else
static inline int stk1160_ac97_register(struct stk1160 *dev) { return 0; }
static inline int stk1160_ac97_unregister(struct stk1160 *dev) { return 0; }
#endif


thanks,

Takashi
--
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