date:20160620

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:   Tue Jun 21 04:00:24 CEST 2016
git branch: test
git hash:   59f0bc11848f8f3242bc1fefae670e745929cd7b
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.5.0-264

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: OK
linux-4.7-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
linux-4.7-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API 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: [very-RFC 0/8] TSN driver for the kernel

2016-06-20 Thread Takashi Sakamoto


On 2016年06月20日 18:06, Henrik Austad wrote:

On Sun, Jun 19, 2016 at 11:45:47PM +0900, Takashi Sakamoto wrote:

(remove C.C. to lkml. This is not so major feature.)

On Jun 19 2916 07:45, Henrik Austad wrote:

snip

802.1Q gives you low latency through the network, but more importantly, no
dropped frames. gPTP gives you a central reference to time.


When such a long message is required, it means that we don't have
enough premises for this discussion.


Isn't a discussion part of how information is conveyed and finding parts
that require more knowledge?


You have just interests in gPTP and transferring AVTPDUs, while no
interests in the others such as "what the basic ideas of TSN come
from" and "the reason that IEEE 1722 refers to IEC 61883 series
which is originally designed for IEEE 1394 bus" and "the reason that
I was motivated to join in this discussion even though not a netdev
developer".


I'm sorry, I'm not sure I follow you here. What do you mean I don't have
any interest in where TSN comes from? or the reason why 1722 use IEC 61883?
What about "they picked 61883 because it made sense?"

gPTP itself is *not* about transffering audio-data, it is about agreeing on
a common time so that when you *do* transfer audio-data, the samplerate
actually means something.

Let me ask you this; if you have 2 sound-cards in your computer and you
want to attach a mic to one and speakers to the other, how do you solve
streaming of audio from the mic to the speaker If you answer does not
contain something akin to "different timing-domain issues", I'd be very
surprised.

If you are interested in TSN for transferring *anything*, _including_
audio, you *have* to take gPTP into consideration. Just as you have to
think about stream reservation, compliant hardware and all the different
subsystems you are going to run into, either via kernel or via userspace.


Here, could I ask you a question? Do you know a role of cycle start
packet of IEEE Std 1394?


No, I do not.

I have only passing knowledge of the firewire standard, I've looked at the
encoding described in 1722 and added that to the alsa shim as an example of
how to use TSN. As I stated, this was a *very* early version and I would
like to use TSN for audio - and more work is needed.


If you think it's not related to this discussion, please tell it to
me. Then I'll drop out from this thread.


There are tons of details left and right, and as I said, I'm not  all to
familiar with firewire. I know that one of the authors behind the firewire
standard happened to be part of 1722 standard.

I am currently working my way through the firewire-stak paper you've
written, and I have gotten a lot of pointers to other areas I need to dig
into so I should be busy for a while.

That being said, Richard's point about a way to find sample-rate of a
hardware device and ways to influence that, is important for AVB/TSN.


History Repeats itself.


?


OK. Bye.


Takashi Sakamoto
--
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 0/3] dma-buf: debugfs fixes

2016-06-20 Thread Sumit Semwal

Hi Mathias,

On 19 June 2016 at 18:01, Mathias Krause  wrote:
> This small series is the v2 of the patch posted initially here:
>
>   http://www.spinics.net/lists/linux-media/msg101347.html
>
> It not only fixes the type mix-up and addresses Daniel's remark (patch 1),
> it also smoothes out the error handling in dma_buf_init_debugfs() (patch 2)
> and removes the then unneeded function dma_buf_debugfs_create_file() (patch
> 3).
>
> Please apply!
>
Thanks for your patchset; applied via drm-misc!

> Mathias Krause (3):
>   dma-buf: propagate errors from dma_buf_describe() on debugfs read
>   dma-buf: remove dma_buf directory on bufinfo file creation errors
>   dma-buf: remove dma_buf_debugfs_create_file()
>
>  drivers/dma-buf/dma-buf.c |   44 ++--
>  include/linux/dma-buf.h   |2 --
>  2 files changed, 14 insertions(+), 32 deletions(-)
>
> --
> 1.7.10.4
>



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
--
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/7] v4l: Correct the ordering of LSBs of the 10-bit raw packed formats

2016-06-20 Thread Dave Stevenson


Hi Hans.

On 20/06/16 18:03, Hans Verkuil wrote:

On 06/20/2016 06:20 PM, Sakari Ailus wrote:

The 10-bit packed raw bayer format documented that the data of the first
pixel of a four-pixel group was found in the first byte and the two
highest bits of the fifth byte. This was not entirely correct. The two
bits in the fifth byte are the two lowest bits. The second pixel occupies
the second byte and third and fourth least significant bits and so on.

Signed-off-by: Sakari Ailus 

As mentioned, this needs confirmation. I wonder, isn't this specified in the UVC
spec?

Regards,

Hans
I'm assuming this is intended to be the same format as generated by many 
Bayer sensors.
Those are defined in both the SMIA CCP2 (section 7.9), and MIPI CSI2 
(section 11.4.4) specs. Whilst nominally restricted, they are both 
available via unofficial websites if you Google for them (I'm happy to 
send links, but didn't want to break mailing list rules by just posting 
them).
CSI2 draft spec Figure 98 "RAW10 Data Transmission on CSI-2 Bus Bitwise 
Illustration" is probably the clearest confirmation of the bit ordering.


dcraw from http://www.cybercom.net/~dcoffin/dcraw/ can consume Raw10 via 
nokia_load_raw

for (dp=data, col=0; col < raw_width; dp+=5, col+=4)
  FORC4 RAW(row,col+c) = (dp[c] << 2) | (dp[4] >> (c << 1) & 3);

And checking against the Raspberry Pi hardware simulator, the RAW10 
parser code has

for (i = 0; i < width; i++) {
   switch ((i + tile_x) & 3) {
  case 0:  val = (buf[0] << 2) | (buf[4] & 3); break;
  case 1:  val = (buf[1] << 2) | ((buf[4] >> 2) & 3); 
break;
  case 2:  val = (buf[2] << 2) | ((buf[4] >> 4) & 3); 
break;

  default: val = (buf[3] << 2) | ((buf[4] >> 6) & 3);


All of those agree with Sakari's update that the first pixel's LSBits 
are in bits 1..0 of byte 5, 2nd pixel in bits 3..2, etc.


Regards,
  Dave
(working on the Pi CSI2 receiver V4L2 driver as there is now sufficient 
data in the public domain to do it. I'll be wanting these formats!)

--
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] leds: Add no-op gpio_led_register_device when LED subsystem is disabled

2016-06-20 Thread Andrew F. Davis

Some systems use 'gpio_led_register_device' to make an in-memory copy of
their LED device table so the original can be removed as .init.rodata.
When the LED subsystem is not enabled source in the led directory is not
built and so this function may be undefined. Fix this here.

Signed-off-by: Andrew F. Davis 
---
 include/linux/leds.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/linux/leds.h b/include/linux/leds.h
index d2b1306..a4a3da6 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -386,8 +386,16 @@ struct gpio_led_platform_data {
unsigned long *delay_off);
 };

+#ifdef CONFIG_NEW_LEDS
 struct platform_device *gpio_led_register_device(
int id, const struct gpio_led_platform_data *pdata);
+#else
+static inline struct platform_device *gpio_led_register_device(
+   int id, const struct gpio_led_platform_data *pdata)
+{
+   return 0;
+}
+#endif

 enum cpu_led_event {
CPU_LED_IDLE_START, /* CPU enters idle */
-- 
2.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] media: Driver for Toshiba et8ek8 5MP sensor

Hi Pali,

On Sat, Jun 18, 2016 at 05:37:33PM +0200, Pali Rohár wrote:
> On Saturday 18 June 2016 17:22:59 Pavel Machek wrote:
> > > +/*
> > > + *
> > > + * Stingray sensor mode settings for Scooby
> > > + *
> > > + *
> > > + */
> > 
> > I'd fix it to normal comment style... and possibly remove it. Can you
> > understand what it says?
> > 
> > > + },
> > > + .regs = {
> > > + { ET8EK8_REG_8BIT, 0x1239, 0x4F },  /**/
> > > + { ET8EK8_REG_8BIT, 0x1238, 0x02 },  /**/
> > > + { ET8EK8_REG_8BIT, 0x123B, 0x70 },  /**/
> > > + { ET8EK8_REG_8BIT, 0x123A, 0x05 },  /**/
> > > + { ET8EK8_REG_8BIT, 0x121B, 0x63 },  /**/
> > > + { ET8EK8_REG_8BIT, 0x1220, 0x85 },  /**/
> > > + { ET8EK8_REG_8BIT, 0x1221, 0x00 },  /**/
> > > + { ET8EK8_REG_8BIT, 0x1222, 0x58 },  /**/
> > > + { ET8EK8_REG_8BIT, 0x1223, 0x00 },  /**/
> > > + { ET8EK8_REG_8BIT, 0x121D, 0x63 },  /**/
> > > + { ET8EK8_REG_8BIT, 0x125D, 0x83 },  /**/
> > > + { ET8EK8_REG_TERM, 0, 0}
> > > + }
> > 
> > I'd remove the empty comments...
> > 
> > > +struct et8ek8_meta_reglist meta_reglist = {
> > > + .version = "V14 03-June-2008",
> > 
> > Do we need the version?
> > 
> > > + .reglist = {
> > > + { .ptr = _poweron_mode2_16vga_2592x1968_12_07fps },
> > > + { .ptr = _16vga_2592x1968_13_12fps_dpcm10_8 },
> > > + { .ptr = _4vga_1296x984_29_99fps_dpcm10_8 },
> > > + { .ptr = _svga_864x656_29_88fps },
> > > + { .ptr = _vga_648x492_29_93fps },
> > > + { .ptr = _16vga_2592x1968_3_99fps },
> > > + { .ptr = _648x492_5fps },
> > > + { .ptr = _4vga_1296x984_5fps },
> > > + { .ptr = _4vga_1296x984_25fps_dpcm10_8 },
> > > + { .ptr = 0 }
> > > + }
> > > +};
> > 
> > I'd say .ptr = NULL.
> > 
> 
> Anyway, this code was generated from configuration ini files and perl 
> script available from: https://gitorious.org/omap3camera/camera-firmware
> 
> Originally in Maemo above C structure is compiled into binary file and 
> via request_firmware() loaded from userspace to kernel driver.
> 
> For me this sounds like a big overkill, so I included above reglist code 
> direcly into et8ek8 kernel driver to avoid request_firmware() and 
> separate userspace storage...

The idea at the time was that it'd be possible to support changes in the
register list without software changes as well as using different register
lists on a different device.

That's not really how device drivers are written. Considering that the use
cases for this very sensor driver seem rather different now than they did
then, I think it's safe to assume there won't be significant (if any at all)
changes to these configurations going forward.

I don't think there's really any value as such in maintaining the
compatibility with the data structures used in the camera-firmware
repository above.

> 
> And for smia-sensor (front webcam) in that gitorious repository is also 
> reglist structure. It is not needed? Can somebody investigate why it is 
> not needed?

The front camera is SMIA compliant and works (at least should!) with the
smiapp driver. I vaguely remember using it with platform data long, long
time ago. And I'm sure someone was working on it, I just don't remember now
who. :-)

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: 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: Nokia N900 cameras -- pipeline setup in python (was Re: [RFC PATCH 00/24] Make Nokia N900 cameras working)

Hi Pavel,

On Fri, Jun 17, 2016 at 07:12:14PM +0200, Pavel Machek wrote:
> Hi!
> 
> > First, I re-did pipeline setup in python, it seems slightly less hacky
> > then in shell.
> > 
> > I tried to modify fcam-dev to work with the new interface, but was not
> > successful so far. I can post patches if someone is interested
> > (mplayer works for me, but that's not too suitable for taking photos).
> > 
> > I tried to get gstreamer to work, with something like:
> 
> While trying to debug gstreamer, I ran v4l2-compliance, and it seems
> to suggest that QUERYCAP is required... but it is not present on
> /dev/video2 or video6.

It's not saying that it wouldn't be present, but the content appears wrong.
It should have the real bus information there rather than just "media".

See e.g. drivers/media/platform/vsp1/vsp1_drv.c . I suppose that should be
right.

Feel free to submit a patch. :-)

> 
> Any ideas? (Kernel is based on Ivaylo 's github tree, IIRC).
> 
> Thanks,
>   Pavel
> 
> pavel@n900:/my/v4l-utils/utils$ ./v4l2-compliance/v4l2-compliance -d 
> /dev/video6
> Driver Info:
>   Driver name   : ispvideo
>   Card type : OMAP3 ISP resizer output
>   Bus info  : media
>   Driver version: 4.6.0
>   Capabilities  : 0x8423
>   Video Capture
>   Video Output
>   Streaming
>   Extended Pix Format
>   Device Capabilities
>   Device Caps   : 0x0421
>   Video Capture
>   Streaming
>   Extended Pix Format
> 
> Compliance test for device /dev/video6 (not using libv4l2):
> 
> Required ioctls:
>   fail: v4l2-compliance.cpp(537): missing bus_info prefix 
> ('media')
>   test VIDIOC_QUERYCAP: FAIL
> 
> Allow for multiple opens:
>   test second video open: OK
>   fail: v4l2-compliance.cpp(537): missing bus_info prefix 
> ('media')
>   test VIDIOC_QUERYCAP: FAIL
>   test VIDIOC_G/S_PRIORITY: OK
> 
> pavel@n900:/my/v4l-utils/utils$ sudo ./v4l2-compliance/v4l2-compliance -d 
> /dev/video2
> Driver Info:
>   Driver name   : ispvideo
>   Card type : OMAP3 ISP CCDC output
> ...
> Compliance test for device /dev/video2 (not using libv4l2):
> 
> Required ioctls:
>   fail: v4l2-compliance.cpp(537): missing bus_info prefix 
> ('media')
>   test VIDIOC_QUERYCAP: FAIL
> 

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: 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

[PATCH 07/12] drivers/media: Employ atomic_fetch_inc()

2016-06-20 Thread Davidlohr Bueso

Now that we have fetch_inc() we can stop using inc_return() - 1.

These are very similar to the existing OP-RETURN primitives we already
have, except they return the value of the atomic variable _before_
modification.

Cc: Hans Verkuil 
Cc: Andy Walls 
Cc: linux-media@vger.kernel.org
Signed-off-by: Davidlohr Bueso 
---
 drivers/media/pci/cobalt/cobalt-driver.c | 2 +-
 drivers/media/pci/cx18/cx18-driver.c | 2 +-
 drivers/media/v4l2-core/v4l2-device.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/cobalt/cobalt-driver.c 
b/drivers/media/pci/cobalt/cobalt-driver.c
index 8d6f04fc8013..70dfcb0c6a72 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.c
+++ b/drivers/media/pci/cobalt/cobalt-driver.c
@@ -683,7 +683,7 @@ static int cobalt_probe(struct pci_dev *pci_dev,
int i;
 
/* FIXME - module parameter arrays constrain max instances */
-   i = atomic_inc_return(_instance) - 1;
+   i = atomic_fetch_inc(_instance);
 
cobalt = kzalloc(sizeof(struct cobalt), GFP_ATOMIC);
if (cobalt == NULL)
diff --git a/drivers/media/pci/cx18/cx18-driver.c 
b/drivers/media/pci/cx18/cx18-driver.c
index 260e462d91b4..5cb3408c6859 100644
--- a/drivers/media/pci/cx18/cx18-driver.c
+++ b/drivers/media/pci/cx18/cx18-driver.c
@@ -908,7 +908,7 @@ static int cx18_probe(struct pci_dev *pci_dev,
struct cx18 *cx;
 
/* FIXME - module parameter arrays constrain max instances */
-   i = atomic_inc_return(_instance) - 1;
+   i = atomic_fetch_inc(_instance);
if (i >= CX18_MAX_CARDS) {
printk(KERN_ERR "cx18: cannot manage card %d, driver has a "
   "limit of 0 - %d\n", i, CX18_MAX_CARDS - 1);
diff --git a/drivers/media/v4l2-core/v4l2-device.c 
b/drivers/media/v4l2-core/v4l2-device.c
index 06fa5f1b2cff..1bc5b68c2724 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -76,7 +76,7 @@ EXPORT_SYMBOL_GPL(v4l2_device_put);
 int v4l2_device_set_name(struct v4l2_device *v4l2_dev, const char *basename,
atomic_t *instance)
 {
-   int num = atomic_inc_return(instance) - 1;
+   int num = atomic_fetch_inc(instance);
int len = strlen(basename);
 
if (basename[len - 1] >= '0' && basename[len - 1] <= '9')
-- 
2.6.6

--
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 19/24] v4l: vsp1: clu: Support runtime modification of controls

Allow reconfiguration of the look-up table and processing mode at
runtime.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_clu.c | 41 +-
 drivers/media/platform/vsp1/vsp1_clu.h |  4 
 2 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 913070ec09e7..2f77c2c60ad2 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -55,7 +55,9 @@ static int clu_set_table(struct vsp1_clu *clu, struct 
v4l2_ctrl *ctrl)
for (i = 0; i < 17 * 17 * 17; ++i)
vsp1_dl_fragment_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
 
+   spin_lock_irq(>lock);
swap(clu->clu, dlb);
+   spin_unlock_irq(>lock);
 
vsp1_dl_fragment_free(dlb);
return 0;
@@ -208,32 +210,39 @@ static void clu_configure(struct vsp1_entity *entity,
  struct vsp1_dl_list *dl, bool full)
 {
struct vsp1_clu *clu = to_clu(>subdev);
-   struct v4l2_mbus_framefmt *format;
+   struct vsp1_dl_body *dlb;
+   unsigned long flags;
u32 ctrl = VI6_CLU_CTRL_AAI | VI6_CLU_CTRL_MVS | VI6_CLU_CTRL_EN;
 
-   if (!full)
+   /* The format can't be changed during streaming, only verify it at
+* stream start and store the information internally for future partial
+* reconfiguration calls.
+*/
+   if (full) {
+   struct v4l2_mbus_framefmt *format;
+
+   format = vsp1_entity_get_pad_format(>entity,
+   clu->entity.config,
+   CLU_PAD_SINK);
+   clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
return;
-
-   format = vsp1_entity_get_pad_format(>entity, clu->entity.config,
-   CLU_PAD_SINK);
-
-   mutex_lock(clu->ctrls.lock);
+   }
 
/* 2D mode can only be used with the YCbCr pixel encoding. */
-   if (clu->mode == V4L2_CID_VSP1_CLU_MODE_2D &&
-   format->code == MEDIA_BUS_FMT_AYUV8_1X32)
+   if (clu->mode == V4L2_CID_VSP1_CLU_MODE_2D && clu->yuv_mode)
ctrl |= VI6_CLU_CTRL_AX1I_2D | VI6_CLU_CTRL_AX2I_2D
 |  VI6_CLU_CTRL_OS0_2D | VI6_CLU_CTRL_OS1_2D
 |  VI6_CLU_CTRL_OS2_2D | VI6_CLU_CTRL_M2D;
 
-   if (clu->clu) {
-   vsp1_dl_list_add_fragment(dl, clu->clu);
-   clu->clu = NULL;
-   }
+   vsp1_clu_write(clu, dl, VI6_CLU_CTRL, ctrl);
 
-   mutex_unlock(clu->ctrls.lock);
+   spin_lock_irqsave(>lock, flags);
+   dlb = clu->clu;
+   clu->clu = NULL;
+   spin_unlock_irqrestore(>lock, flags);
 
-   vsp1_clu_write(clu, dl, VI6_CLU_CTRL, ctrl);
+   if (dlb)
+   vsp1_dl_list_add_fragment(dl, dlb);
 }
 
 static const struct vsp1_entity_operations clu_entity_ops = {
@@ -253,6 +262,8 @@ struct vsp1_clu *vsp1_clu_create(struct vsp1_device *vsp1)
if (clu == NULL)
return ERR_PTR(-ENOMEM);
 
+   spin_lock_init(>lock);
+
clu->entity.ops = _entity_ops;
clu->entity.type = VSP1_ENTITY_CLU;
 
diff --git a/drivers/media/platform/vsp1/vsp1_clu.h 
b/drivers/media/platform/vsp1/vsp1_clu.h
index 33a69029c719..036e0a2f1a42 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.h
+++ b/drivers/media/platform/vsp1/vsp1_clu.h
@@ -13,6 +13,8 @@
 #ifndef __VSP1_CLU_H__
 #define __VSP1_CLU_H__
 
+#include 
+
 #include 
 #include 
 #include 
@@ -30,6 +32,8 @@ struct vsp1_clu {
 
struct v4l2_ctrl_handler ctrls;
 
+   bool yuv_mode;
+   spinlock_t lock;
unsigned int mode;
struct vsp1_dl_body *clu;
 };
-- 
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

[PATCH 18/24] v4l: vsp1: lut: Support runtime modification of controls

Allow reconfiguration of the look-up table at runtime.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_lut.c | 25 +++--
 drivers/media/platform/vsp1/vsp1_lut.h |  3 +++
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_lut.c 
b/drivers/media/platform/vsp1/vsp1_lut.c
index 0bd26dd5f706..e34237824a5a 100644
--- a/drivers/media/platform/vsp1/vsp1_lut.c
+++ b/drivers/media/platform/vsp1/vsp1_lut.c
@@ -52,7 +52,9 @@ static int lut_set_table(struct vsp1_lut *lut, struct 
v4l2_ctrl *ctrl)
vsp1_dl_fragment_write(dlb, VI6_LUT_TABLE + 4 * i,
   ctrl->p_new.p_u32[i]);
 
+   spin_lock_irq(>lock);
swap(lut->lut, dlb);
+   spin_unlock_irq(>lock);
 
vsp1_dl_fragment_free(dlb);
return 0;
@@ -184,20 +186,21 @@ static void lut_configure(struct vsp1_entity *entity,
  struct vsp1_dl_list *dl, bool full)
 {
struct vsp1_lut *lut = to_lut(>subdev);
+   struct vsp1_dl_body *dlb;
+   unsigned long flags;
 
-   if (!full)
+   if (full) {
+   vsp1_lut_write(lut, dl, VI6_LUT_CTRL, VI6_LUT_CTRL_EN);
return;
-
-   vsp1_lut_write(lut, dl, VI6_LUT_CTRL, VI6_LUT_CTRL_EN);
-
-   mutex_lock(lut->ctrls.lock);
-
-   if (lut->lut) {
-   vsp1_dl_list_add_fragment(dl, lut->lut);
-   lut->lut = NULL;
}
 
-   mutex_unlock(lut->ctrls.lock);
+   spin_lock_irqsave(>lock, flags);
+   dlb = lut->lut;
+   lut->lut = NULL;
+   spin_unlock_irqrestore(>lock, flags);
+
+   if (dlb)
+   vsp1_dl_list_add_fragment(dl, dlb);
 }
 
 static const struct vsp1_entity_operations lut_entity_ops = {
@@ -217,6 +220,8 @@ struct vsp1_lut *vsp1_lut_create(struct vsp1_device *vsp1)
if (lut == NULL)
return ERR_PTR(-ENOMEM);
 
+   spin_lock_init(>lock);
+
lut->entity.ops = _entity_ops;
lut->entity.type = VSP1_ENTITY_LUT;
 
diff --git a/drivers/media/platform/vsp1/vsp1_lut.h 
b/drivers/media/platform/vsp1/vsp1_lut.h
index 021898fc0ce5..f8c4e8f0a79d 100644
--- a/drivers/media/platform/vsp1/vsp1_lut.h
+++ b/drivers/media/platform/vsp1/vsp1_lut.h
@@ -13,6 +13,8 @@
 #ifndef __VSP1_LUT_H__
 #define __VSP1_LUT_H__
 
+#include 
+
 #include 
 #include 
 #include 
@@ -29,6 +31,7 @@ struct vsp1_lut {
 
struct v4l2_ctrl_handler ctrls;
 
+   spinlock_t lock;
struct vsp1_dl_body *lut;
 };
 
-- 
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

[PATCH 01/24] v4l: Add metadata buffer type and format

The metadata buffer type is used to transfer metadata between userspace
and kernelspace through a V4L2 buffers queue. It comes with a new
metadata capture capability and format description.

Signed-off-by: Laurent Pinchart 
---
 Documentation/DocBook/media/v4l/dev-meta.xml  | 93 +++
 Documentation/DocBook/media/v4l/v4l2.xml  |  1 +
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 19 ++
 drivers/media/v4l2-core/v4l2-dev.c| 16 +++--
 drivers/media/v4l2-core/v4l2-ioctl.c  | 34 ++
 drivers/media/v4l2-core/videobuf2-v4l2.c  |  3 +
 include/media/v4l2-ioctl.h|  8 +++
 include/uapi/linux/videodev2.h| 14 
 8 files changed, 182 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml

diff --git a/Documentation/DocBook/media/v4l/dev-meta.xml 
b/Documentation/DocBook/media/v4l/dev-meta.xml
new file mode 100644
index ..9b5b1fba2007
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/dev-meta.xml
@@ -0,0 +1,93 @@
+  Metadata Interface
+
+  
+Experimental
+This is an  experimental 
+interface and may change in the future.
+  
+
+  
+Metadata refers to any non-image data that supplements video frames with
+additional information. This may include statistics computed over the image
+or frame capture parameters supplied by the image source. This interface is
+intended for transfer of metadata to userspace and control of that operation.
+  
+
+  
+The metadata interface is implemented on video capture devices. The device can
+be dedicated to metadata or can implement both video and metadata capture as
+specified in its reported capabilities.
+  
+
+  
+Querying Capabilities
+
+
+Devices supporting the metadata interface set the
+V4L2_CAP_META_CAPTURE flag in the
+capabilities field of 
+returned by the  ioctl. That flag means the device can capture
+metadata to memory.
+
+
+At least one of the read/write or streaming I/O methods must be supported.
+
+  
+
+  
+Data Format Negotiation
+
+
+The metadata device uses the format ioctls to
+select the capture format. The metadata buffer content format is bound to that
+selectable format. In addition to the basic
+format ioctls, the  ioctl
+must be supported as well.
+
+
+
+To use the format ioctls applications set the
+type field of a  to
+V4L2_BUF_TYPE_META_CAPTURE and use the 
+meta member of the fmt
+union as needed per the desired operation.
+Currently there are two fields, dataformat and
+buffersize, of struct  that are
+used. Content of the dataformat is the V4L2 FourCC
+code of the data format. The buffersize field is the
+maximum buffer size in bytes required for data transfer, set by the driver in
+order to inform applications.
+
+
+
+  struct v4l2_meta_format
+  
+
+
+  
+__u32
+dataformat
+
+The data format, set by the application. This is a little endian
+four character code.
+V4L2 defines metadata formats in .
+   
+  
+  
+__u32
+buffersize
+
+Maximum size in bytes required for data. Value is set by the driver.
+   
+  
+  
+__u8
+reserved[24]
+This array is reserved for future extensions.
+Drivers and applications must set it to zero.
+  
+
+  
+
+
+  
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
b/Documentation/DocBook/media/v4l/v4l2.xml
index 42e626d6c936..5c83b5d342dd 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -605,6 +605,7 @@ and discussions on the V4L mailing list.
   
   
   
+  
   
   
   
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index bacecbd68a6d..da2d836e8887 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -161,6 +161,20 @@ static inline int put_v4l2_sdr_format(struct 
v4l2_sdr_format *kp, struct v4l2_sd
return 0;
 }
 
+static inline int get_v4l2_meta_format(struct v4l2_meta_format *kp, struct 
v4l2_meta_format __user *up)
+{
+   if (copy_from_user(kp, up, sizeof(struct v4l2_meta_format)))
+   return -EFAULT;
+   return 0;
+}
+
+static inline int put_v4l2_meta_format(struct v4l2_meta_format *kp, struct 
v4l2_meta_format __user *up)
+{
+   if (copy_to_user(up, kp, sizeof(struct v4l2_meta_format)))
+   return -EFAULT;
+   return 0;
+}
+
 struct v4l2_format32 {
__u32   type;   /* enum v4l2_buf_type */
union {
@@ -170,6 +184,7 @@ struct v4l2_format32 {
struct v4l2_vbi_format  vbi;
struct v4l2_sliced_vbi_format   sliced;
struct v4l2_sdr_format  sdr;
+

[PATCH 00/24] R-Car VSP1: Histogram, look-up table and flip support

Hello,

Here's my current set of pending VSP1 patches, based on top of the
"[PATCH v2 00/13] R-Car VSP improvements for v4.7 - Round 2" series. For
convenience I've pushed the patches and their dependencies to

git://linuxtv.org/pinchartl/media.git vsp1/flip

The series contains new features as well as several fixes. In particular the
driver now supports histogram generation through the HGO (01/24 to 04/24),
doesn't generate warnings to the kernel log due to uninitialized functions
(05/24 to 10/24), supports the LUT and CLU (12/24 to 19/24), supports
horizontal and vertical flipping (20/24 to 22/24) and doesn't attempt to
access freed buffers anymore (24/24).

I plan to send a pull request for v4.8 as soon as the previous pull request
gets merged.

Laurent Pinchart (24):
  v4l: Add metadata buffer type and format
  v4l: Define a pixel format for the R-Car VSP1 1-D histogram engine
  v4l: vsp1: Add HGO support
  v4l: vsp1: Don't create HGO entity when the userspace API is disabled
  media: Add video processing entity functions
  media: Add video statistics computation functions
  v4l: vsp1: Base link creation on availability of entities
  v4l: vsp1: Don't register media device when userspace API is disabled
  v4l: vsp1: Don't create LIF entity when the userspace API is enabled
  v4l: vsp1: Set entities functions
  v4l: vsp1: pipe: Fix typo in comment
  v4l: vsp1: dl: Don't free fragments with interrupts disabled
  v4l: vsp1: lut: Initialize the mutex
  v4l: vsp1: lut: Expose configuration through a control
  v4l: vsp1: Add Cubic Look Up Table (CLU) support
  v4l: vsp1: sru: Fix intensity control ID
  v4l: vsp1: Support runtime modification of controls
  v4l: vsp1: lut: Support runtime modification of controls
  v4l: vsp1: clu: Support runtime modification of controls
  v4l: vsp1: Simplify alpha propagation
  v4l: vsp1: rwpf: Support runtime modification of controls
  v4l: vsp1: wpf: Add flipping support
  v4l: vsp1: Constify operation structures
  v4l: vsp1: Stop the pipeline upon the first STREAMOFF

 Documentation/DocBook/media/v4l/dev-meta.xml   |  93 
 Documentation/DocBook/media/v4l/media-types.xml|  64 +++
 .../DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml | 307 +
 Documentation/DocBook/media/v4l/pixfmt.xml |   9 +
 Documentation/DocBook/media/v4l/v4l2.xml   |   1 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/vsp1/Makefile   |   4 +-
 drivers/media/platform/vsp1/vsp1.h |   8 +
 drivers/media/platform/vsp1/vsp1_bru.c |  12 +-
 drivers/media/platform/vsp1/vsp1_clu.c | 292 
 drivers/media/platform/vsp1/vsp1_clu.h |  48 ++
 drivers/media/platform/vsp1/vsp1_dl.c  |  72 ++-
 drivers/media/platform/vsp1/vsp1_drm.c |   8 +-
 drivers/media/platform/vsp1/vsp1_drv.c |  91 ++--
 drivers/media/platform/vsp1/vsp1_entity.c  | 140 +-
 drivers/media/platform/vsp1/vsp1_entity.h  |  12 +-
 drivers/media/platform/vsp1/vsp1_hgo.c | 500 +
 drivers/media/platform/vsp1/vsp1_hgo.h |  50 +++
 drivers/media/platform/vsp1/vsp1_histo.c   | 307 +
 drivers/media/platform/vsp1/vsp1_histo.h   |  68 +++
 drivers/media/platform/vsp1/vsp1_hsit.c|  14 +-
 drivers/media/platform/vsp1/vsp1_lif.c |  16 +-
 drivers/media/platform/vsp1/vsp1_lut.c | 101 +++--
 drivers/media/platform/vsp1/vsp1_lut.h |   7 +-
 drivers/media/platform/vsp1/vsp1_pipe.c|  62 ++-
 drivers/media/platform/vsp1/vsp1_pipe.h|   8 +-
 drivers/media/platform/vsp1/vsp1_regs.h|  40 +-
 drivers/media/platform/vsp1/vsp1_rpf.c |  31 +-
 drivers/media/platform/vsp1/vsp1_rwpf.c|   6 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h|  14 +-
 drivers/media/platform/vsp1/vsp1_sru.c |  14 +-
 drivers/media/platform/vsp1/vsp1_uds.c |  16 +-
 drivers/media/platform/vsp1/vsp1_uds.h |   2 +-
 drivers/media/platform/vsp1/vsp1_video.c   |  36 +-
 drivers/media/platform/vsp1/vsp1_wpf.c | 159 ++-
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c  |  19 +
 drivers/media/v4l2-core/v4l2-dev.c |  16 +-
 drivers/media/v4l2-core/v4l2-ioctl.c   |  35 ++
 drivers/media/v4l2-core/videobuf2-v4l2.c   |   3 +
 include/media/v4l2-ioctl.h |   8 +
 include/uapi/linux/media.h |  10 +
 include/uapi/linux/videodev2.h |  17 +
 include/uapi/linux/vsp1.h  |  34 --
 43 files changed, 2515 insertions(+), 240 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml
 create mode 100644 drivers/media/platform/vsp1/vsp1_clu.c
 create

[PATCH 20/24] v4l: vsp1: Simplify alpha propagation

We don't need to walk the pipeline when propagating the alpha value as
all the information needed for propagation is already available from the
pipeline structure.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_pipe.c | 42 +++--
 drivers/media/platform/vsp1/vsp1_pipe.h |  4 +---
 drivers/media/platform/vsp1/vsp1_rpf.c  |  2 +-
 drivers/media/platform/vsp1/vsp1_uds.c  |  4 +++-
 drivers/media/platform/vsp1/vsp1_uds.h  |  2 +-
 5 files changed, 14 insertions(+), 40 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index b695bee9e55c..0dd7c163c8d5 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -317,46 +317,20 @@ void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
  * to be scaled, we disable alpha scaling when the UDS input has a fixed alpha
  * value. The UDS then outputs a fixed alpha value which needs to be programmed
  * from the input RPF alpha.
- *
- * This function can only be called from a subdev s_stream handler as it
- * requires a valid display list context.
  */
 void vsp1_pipeline_propagate_alpha(struct vsp1_pipeline *pipe,
-  struct vsp1_entity *input,
-  struct vsp1_dl_list *dl,
-  unsigned int alpha)
+  struct vsp1_dl_list *dl, unsigned int alpha)
 {
-   struct vsp1_entity *entity;
-   struct media_pad *pad;
+   if (!pipe->uds)
+   return;
 
-   /* The alpha value doesn't need to be propagated to the HGO, use
-* vsp1_entity_remote_pad() to traverse the graph.
+   /* The BRU background color has a fixed alpha value set to 255, the
+* output alpha value is thus always equal to 255.
 */
+   if (pipe->uds_input->type == VSP1_ENTITY_BRU)
+   alpha = 255;
 
-   pad = vsp1_entity_remote_pad(>pads[RWPF_PAD_SOURCE]);
-
-   while (pad) {
-   if (!is_media_entity_v4l2_subdev(pad->entity))
-   break;
-
-   entity = 
to_vsp1_entity(media_entity_to_v4l2_subdev(pad->entity));
-
-   /* The BRU background color has a fixed alpha value set to 255,
-* the output alpha value is thus always equal to 255.
-*/
-   if (entity->type == VSP1_ENTITY_BRU)
-   alpha = 255;
-
-   if (entity->type == VSP1_ENTITY_UDS) {
-   struct vsp1_uds *uds = to_uds(>subdev);
-
-   vsp1_uds_set_alpha(uds, dl, alpha);
-   break;
-   }
-
-   pad = >pads[entity->source_pad];
-   pad = vsp1_entity_remote_pad(pad);
-   }
+   vsp1_uds_set_alpha(pipe->uds, dl, alpha);
 }
 
 void vsp1_pipelines_suspend(struct vsp1_device *vsp1)
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 2cbf1a5ea1fb..bd42effe405e 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -119,9 +119,7 @@ bool vsp1_pipeline_ready(struct vsp1_pipeline *pipe);
 void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe);
 
 void vsp1_pipeline_propagate_alpha(struct vsp1_pipeline *pipe,
-  struct vsp1_entity *input,
-  struct vsp1_dl_list *dl,
-  unsigned int alpha);
+  struct vsp1_dl_list *dl, unsigned int alpha);
 
 void vsp1_pipelines_suspend(struct vsp1_device *vsp1);
 void vsp1_pipelines_resume(struct vsp1_device *vsp1);
diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c 
b/drivers/media/platform/vsp1/vsp1_rpf.c
index bcfa5bce12fb..2a734b131110 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -206,7 +206,7 @@ static void rpf_configure(struct vsp1_entity *entity,
vsp1_rpf_write(rpf, dl, VI6_RPF_MULT_ALPHA, mult);
}
 
-   vsp1_pipeline_propagate_alpha(pipe, >entity, dl, rpf->alpha);
+   vsp1_pipeline_propagate_alpha(pipe, dl, rpf->alpha);
 
vsp1_rpf_write(rpf, dl, VI6_RPF_MSK_CTRL, 0);
vsp1_rpf_write(rpf, dl, VI6_RPF_CKEY_CTRL, 0);
diff --git a/drivers/media/platform/vsp1/vsp1_uds.c 
b/drivers/media/platform/vsp1/vsp1_uds.c
index e916f454e3a4..5291f8b36688 100644
--- a/drivers/media/platform/vsp1/vsp1_uds.c
+++ b/drivers/media/platform/vsp1/vsp1_uds.c
@@ -40,9 +40,11 @@ static inline void vsp1_uds_write(struct vsp1_uds *uds, 
struct vsp1_dl_list *dl,
  * Scaling Computation
  */
 
-void vsp1_uds_set_alpha(struct vsp1_uds *uds, struct vsp1_dl_list *dl,
+void vsp1_uds_set_alpha(struct vsp1_entity *entity, struct vsp1_dl_list *dl,
unsigned int alpha)
 {
+   struct vsp1_uds *uds =

[PATCH 23/24] v4l: vsp1: Constify operation structures

The structures are never modified, make them const.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_bru.c   | 4 ++--
 drivers/media/platform/vsp1/vsp1_clu.c   | 4 ++--
 drivers/media/platform/vsp1/vsp1_hgo.c   | 4 ++--
 drivers/media/platform/vsp1/vsp1_histo.c | 2 +-
 drivers/media/platform/vsp1/vsp1_hsit.c  | 4 ++--
 drivers/media/platform/vsp1/vsp1_lif.c   | 4 ++--
 drivers/media/platform/vsp1/vsp1_lut.c   | 4 ++--
 drivers/media/platform/vsp1/vsp1_rpf.c   | 2 +-
 drivers/media/platform/vsp1/vsp1_sru.c   | 4 ++--
 drivers/media/platform/vsp1/vsp1_uds.c   | 4 ++--
 drivers/media/platform/vsp1/vsp1_video.c | 4 ++--
 drivers/media/platform/vsp1/vsp1_wpf.c   | 4 ++--
 12 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index dfd48cf4a11a..8268b87727a7 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -249,7 +249,7 @@ static int bru_set_selection(struct v4l2_subdev *subdev,
return 0;
 }
 
-static struct v4l2_subdev_pad_ops bru_pad_ops = {
+static const struct v4l2_subdev_pad_ops bru_pad_ops = {
.init_cfg = vsp1_entity_init_cfg,
.enum_mbus_code = bru_enum_mbus_code,
.enum_frame_size = bru_enum_frame_size,
@@ -259,7 +259,7 @@ static struct v4l2_subdev_pad_ops bru_pad_ops = {
.set_selection = bru_set_selection,
 };
 
-static struct v4l2_subdev_ops bru_ops = {
+static const struct v4l2_subdev_ops bru_ops = {
.pad= _pad_ops,
 };
 
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 2f77c2c60ad2..b63d2dbe5ea3 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -189,7 +189,7 @@ static int clu_set_format(struct v4l2_subdev *subdev,
  * V4L2 Subdevice Operations
  */
 
-static struct v4l2_subdev_pad_ops clu_pad_ops = {
+static const struct v4l2_subdev_pad_ops clu_pad_ops = {
.init_cfg = vsp1_entity_init_cfg,
.enum_mbus_code = clu_enum_mbus_code,
.enum_frame_size = clu_enum_frame_size,
@@ -197,7 +197,7 @@ static struct v4l2_subdev_pad_ops clu_pad_ops = {
.set_fmt = clu_set_format,
 };
 
-static struct v4l2_subdev_ops clu_ops = {
+static const struct v4l2_subdev_ops clu_ops = {
.pad= _pad_ops,
 };
 
diff --git a/drivers/media/platform/vsp1/vsp1_hgo.c 
b/drivers/media/platform/vsp1/vsp1_hgo.c
index 25983f37d711..aee49f370558 100644
--- a/drivers/media/platform/vsp1/vsp1_hgo.c
+++ b/drivers/media/platform/vsp1/vsp1_hgo.c
@@ -380,7 +380,7 @@ static int hgo_set_format(struct v4l2_subdev *subdev,
return 0;
 }
 
-static struct v4l2_subdev_pad_ops hgo_pad_ops = {
+static const struct v4l2_subdev_pad_ops hgo_pad_ops = {
.enum_mbus_code = hgo_enum_mbus_code,
.enum_frame_size = hgo_enum_frame_size,
.get_fmt = hgo_get_format,
@@ -389,7 +389,7 @@ static struct v4l2_subdev_pad_ops hgo_pad_ops = {
.set_selection = hgo_set_selection,
 };
 
-static struct v4l2_subdev_ops hgo_ops = {
+static const struct v4l2_subdev_ops hgo_ops = {
.pad= _pad_ops,
 };
 
diff --git a/drivers/media/platform/vsp1/vsp1_histo.c 
b/drivers/media/platform/vsp1/vsp1_histo.c
index e9eb22835483..97b1cb891e90 100644
--- a/drivers/media/platform/vsp1/vsp1_histo.c
+++ b/drivers/media/platform/vsp1/vsp1_histo.c
@@ -155,7 +155,7 @@ static void histo_stop_streaming(struct vb2_queue *vq)
spin_unlock_irqrestore(>irqlock, flags);
 }
 
-static struct vb2_ops histo_video_queue_qops = {
+static const struct vb2_ops histo_video_queue_qops = {
.queue_setup = histo_queue_setup,
.buf_prepare = histo_buffer_prepare,
.buf_queue = histo_buffer_queue,
diff --git a/drivers/media/platform/vsp1/vsp1_hsit.c 
b/drivers/media/platform/vsp1/vsp1_hsit.c
index 42d74fc1119f..6e5077beb38c 100644
--- a/drivers/media/platform/vsp1/vsp1_hsit.c
+++ b/drivers/media/platform/vsp1/vsp1_hsit.c
@@ -107,7 +107,7 @@ static int hsit_set_format(struct v4l2_subdev *subdev,
return 0;
 }
 
-static struct v4l2_subdev_pad_ops hsit_pad_ops = {
+static const struct v4l2_subdev_pad_ops hsit_pad_ops = {
.init_cfg = vsp1_entity_init_cfg,
.enum_mbus_code = hsit_enum_mbus_code,
.enum_frame_size = hsit_enum_frame_size,
@@ -115,7 +115,7 @@ static struct v4l2_subdev_pad_ops hsit_pad_ops = {
.set_fmt = hsit_set_format,
 };
 
-static struct v4l2_subdev_ops hsit_ops = {
+static const struct v4l2_subdev_ops hsit_ops = {
.pad= _pad_ops,
 };
 
diff --git a/drivers/media/platform/vsp1/vsp1_lif.c 
b/drivers/media/platform/vsp1/vsp1_lif.c
index b7b69b043bdb..a720063f38c5 100644
--- a/drivers/media/platform/vsp1/vsp1_lif.c
+++ b/drivers/media/platform/vsp1/vsp1_lif.c
@@ -104,7 +104,7 @@ static int lif_set_format(struct v4l2_subdev *subdev,
return 0;
 }
 
-static struct v4l2_subdev_pad_ops

[PATCH 21/24] v4l: vsp1: rwpf: Support runtime modification of controls

Allow reconfiguration of the alpha value at runtime.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_rpf.c  | 21 -
 drivers/media/platform/vsp1/vsp1_rwpf.c |  2 --
 drivers/media/platform/vsp1/vsp1_rwpf.h |  3 +++
 drivers/media/platform/vsp1/vsp1_wpf.c  | 10 +++---
 4 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c 
b/drivers/media/platform/vsp1/vsp1_rpf.c
index 2a734b131110..39b0580878ce 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -73,8 +73,15 @@ static void rpf_configure(struct vsp1_entity *entity,
u32 pstride;
u32 infmt;
 
-   if (!full)
+   if (!full) {
+   vsp1_rpf_write(rpf, dl, VI6_RPF_VRTCOL_SET,
+  rpf->alpha << VI6_RPF_VRTCOL_SET_LAYA_SHIFT);
+   vsp1_rpf_write(rpf, dl, VI6_RPF_MULT_ALPHA, rpf->mult_alpha |
+  (rpf->alpha << VI6_RPF_MULT_ALPHA_RATIO_SHIFT));
+
+   vsp1_pipeline_propagate_alpha(pipe, dl, rpf->alpha);
return;
+   }
 
/* Source size, stride and crop offsets.
 *
@@ -171,9 +178,6 @@ static void rpf_configure(struct vsp1_entity *entity,
   (fmtinfo->alpha ? VI6_RPF_ALPH_SEL_ASEL_PACKED
   : VI6_RPF_ALPH_SEL_ASEL_FIXED));
 
-   vsp1_rpf_write(rpf, dl, VI6_RPF_VRTCOL_SET,
-  rpf->alpha << VI6_RPF_VRTCOL_SET_LAYA_SHIFT);
-
if (entity->vsp1->info->gen == 3) {
u32 mult;
 
@@ -191,8 +195,7 @@ static void rpf_configure(struct vsp1_entity *entity,
mult = VI6_RPF_MULT_ALPHA_A_MMD_RATIO
 | (premultiplied ?
VI6_RPF_MULT_ALPHA_P_MMD_RATIO :
-   VI6_RPF_MULT_ALPHA_P_MMD_NONE)
-| (rpf->alpha << VI6_RPF_MULT_ALPHA_RATIO_SHIFT);
+   VI6_RPF_MULT_ALPHA_P_MMD_NONE);
} else {
/* When the input doesn't contain an alpha channel the
 * global alpha value is applied in the unpacking unit,
@@ -203,11 +206,9 @@ static void rpf_configure(struct vsp1_entity *entity,
 | VI6_RPF_MULT_ALPHA_P_MMD_NONE;
}
 
-   vsp1_rpf_write(rpf, dl, VI6_RPF_MULT_ALPHA, mult);
+   rpf->mult_alpha = mult;
}
 
-   vsp1_pipeline_propagate_alpha(pipe, dl, rpf->alpha);
-
vsp1_rpf_write(rpf, dl, VI6_RPF_MSK_CTRL, 0);
vsp1_rpf_write(rpf, dl, VI6_RPF_CKEY_CTRL, 0);
 
@@ -253,6 +254,8 @@ struct vsp1_rwpf *vsp1_rpf_create(struct vsp1_device *vsp1, 
unsigned int index)
goto error;
}
 
+   v4l2_ctrl_handler_setup(>ctrls);
+
return rpf;
 
 error:
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.c 
b/drivers/media/platform/vsp1/vsp1_rwpf.c
index 3b6e032e7806..cd3562d1d9cf 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.c
@@ -243,8 +243,6 @@ static const struct v4l2_ctrl_ops vsp1_rwpf_ctrl_ops = {
 
 int vsp1_rwpf_init_ctrls(struct vsp1_rwpf *rwpf)
 {
-   rwpf->alpha = 255;
-
v4l2_ctrl_handler_init(>ctrls, 1);
v4l2_ctrl_new_std(>ctrls, _rwpf_ctrl_ops,
  V4L2_CID_ALPHA_COMPONENT, 0, 255, 1, 255);
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h 
b/drivers/media/platform/vsp1/vsp1_rwpf.h
index 9ff7c78f239e..801cacc12e07 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.h
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
@@ -49,6 +49,9 @@ struct vsp1_rwpf {
 
unsigned int alpha;
 
+   u32 mult_alpha;
+   u32 outfmt;
+
unsigned int offsets[2];
struct vsp1_rwpf_memory mem;
 
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
b/drivers/media/platform/vsp1/vsp1_wpf.c
index af22d8043a70..dab902c2e676 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -104,8 +104,11 @@ static void wpf_configure(struct vsp1_entity *entity,
u32 outfmt = 0;
u32 srcrpf = 0;
 
-   if (!full)
+   if (!full) {
+   vsp1_wpf_write(wpf, dl, VI6_WPF_OUTFMT, wpf->outfmt |
+  (wpf->alpha << VI6_WPF_OUTFMT_PDV_SHIFT));
return;
+   }
 
/* Cropping */
crop = vsp1_rwpf_get_crop(wpf, wpf->entity.config);
@@ -151,8 +154,7 @@ static void wpf_configure(struct vsp1_entity *entity,
if (sink_format->code != source_format->code)
outfmt |= VI6_WPF_OUTFMT_CSC;
 
-   outfmt |= wpf->alpha << VI6_WPF_OUTFMT_PDV_SHIFT;
-   vsp1_wpf_write(wpf, dl, VI6_WPF_OUTFMT, outfmt);
+   wpf->outfmt = outfmt;
 
vsp1_dl_list_write(dl, VI6_DPR_WPF_FPORCH(wpf->entity.index),

[PATCH 24/24] v4l: vsp1: Stop the pipeline upon the first STREAMOFF

The device is stopped when STREAMOFF is called on the last video node in
the pipeline. This results in possible memory corruption and/or crashes,
as userspace could free buffers while the hardware is still writing to
them, and the frame completion interrupt handler could try to access
buffers that don't exist anymore.

Fix this by stopping the pipeline upon the first STREAMOFF call, not the
last.

Reported-by: Kuninori Morimoto 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index f2cb19bd86ca..7d491b7b29e2 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -686,7 +686,7 @@ static void vsp1_video_stop_streaming(struct vb2_queue *vq)
int ret;
 
mutex_lock(>lock);
-   if (--pipe->stream_count == 0) {
+   if (--pipe->stream_count == pipe->num_inputs) {
/* Stop the pipeline. */
ret = vsp1_pipeline_stop(pipe);
if (ret == -ETIMEDOUT)
-- 
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

[PATCH 14/24] v4l: vsp1: lut: Expose configuration through a control

Replace the custom ioctl with a V4L2 control in order to standardize the
API.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_lut.c | 76 +++---
 drivers/media/platform/vsp1/vsp1_lut.h |  6 +--
 include/uapi/linux/vsp1.h  | 34 ---
 3 files changed, 54 insertions(+), 62 deletions(-)
 delete mode 100644 include/uapi/linux/vsp1.h

diff --git a/drivers/media/platform/vsp1/vsp1_lut.c 
b/drivers/media/platform/vsp1/vsp1_lut.c
index 9a2c55b3570a..70f189ee235c 100644
--- a/drivers/media/platform/vsp1/vsp1_lut.c
+++ b/drivers/media/platform/vsp1/vsp1_lut.c
@@ -13,7 +13,6 @@
 
 #include 
 #include 
-#include 
 
 #include 
 
@@ -35,43 +34,60 @@ static inline void vsp1_lut_write(struct vsp1_lut *lut, 
struct vsp1_dl_list *dl,
 }
 
 /* 
-
- * V4L2 Subdevice Core Operations
+ * Controls
  */
 
-static int lut_set_table(struct vsp1_lut *lut, struct vsp1_lut_config *config)
+#define V4L2_CID_VSP1_LUT_TABLE(V4L2_CID_USER_BASE | 
0x1001)
+
+static int lut_set_table(struct vsp1_lut *lut, struct v4l2_ctrl *ctrl)
 {
struct vsp1_dl_body *dlb;
unsigned int i;
 
-   dlb = vsp1_dl_fragment_alloc(lut->entity.vsp1, ARRAY_SIZE(config->lut));
+   dlb = vsp1_dl_fragment_alloc(lut->entity.vsp1, 256);
if (!dlb)
return -ENOMEM;
 
-   for (i = 0; i < ARRAY_SIZE(config->lut); ++i)
+   for (i = 0; i < 256; ++i)
vsp1_dl_fragment_write(dlb, VI6_LUT_TABLE + 4 * i,
-  config->lut[i]);
+  ctrl->p_new.p_u32[i]);
 
-   mutex_lock(>lock);
swap(lut->lut, dlb);
-   mutex_unlock(>lock);
 
vsp1_dl_fragment_free(dlb);
return 0;
 }
 
-static long lut_ioctl(struct v4l2_subdev *subdev, unsigned int cmd, void *arg)
+static int lut_s_ctrl(struct v4l2_ctrl *ctrl)
 {
-   struct vsp1_lut *lut = to_lut(subdev);
-
-   switch (cmd) {
-   case VIDIOC_VSP1_LUT_CONFIG:
-   return lut_set_table(lut, arg);
+   struct vsp1_lut *lut =
+   container_of(ctrl->handler, struct vsp1_lut, ctrls);
 
-   default:
-   return -ENOIOCTLCMD;
+   switch (ctrl->id) {
+   case V4L2_CID_VSP1_LUT_TABLE:
+   lut_set_table(lut, ctrl);
+   break;
}
+
+   return 0;
 }
 
+static const struct v4l2_ctrl_ops lut_ctrl_ops = {
+   .s_ctrl = lut_s_ctrl,
+};
+
+static const struct v4l2_ctrl_config lut_table_control = {
+   .ops = _ctrl_ops,
+   .id = V4L2_CID_VSP1_LUT_TABLE,
+   .name = "Look-Up Table",
+   .type = V4L2_CTRL_TYPE_U32,
+   .min = 0x,
+   .max = 0x00ff,
+   .step = 1,
+   .def = 0,
+   .dims = { 256},
+};
+
 /* 
-
  * V4L2 Subdevice Pad Operations
  */
@@ -147,10 +163,6 @@ static int lut_set_format(struct v4l2_subdev *subdev,
  * V4L2 Subdevice Operations
  */
 
-static struct v4l2_subdev_core_ops lut_core_ops = {
-   .ioctl = lut_ioctl,
-};
-
 static struct v4l2_subdev_pad_ops lut_pad_ops = {
.init_cfg = vsp1_entity_init_cfg,
.enum_mbus_code = lut_enum_mbus_code,
@@ -160,7 +172,6 @@ static struct v4l2_subdev_pad_ops lut_pad_ops = {
 };
 
 static struct v4l2_subdev_ops lut_ops = {
-   .core   = _core_ops,
.pad= _pad_ops,
 };
 
@@ -176,12 +187,14 @@ static void lut_configure(struct vsp1_entity *entity,
 
vsp1_lut_write(lut, dl, VI6_LUT_CTRL, VI6_LUT_CTRL_EN);
 
-   mutex_lock(>lock);
+   mutex_lock(lut->ctrls.lock);
+
if (lut->lut) {
vsp1_dl_list_add_fragment(dl, lut->lut);
lut->lut = NULL;
}
-   mutex_unlock(>lock);
+
+   mutex_unlock(lut->ctrls.lock);
 }
 
 static const struct vsp1_entity_operations lut_entity_ops = {
@@ -201,8 +214,6 @@ struct vsp1_lut *vsp1_lut_create(struct vsp1_device *vsp1)
if (lut == NULL)
return ERR_PTR(-ENOMEM);
 
-   mutex_init(>lock);
-
lut->entity.ops = _entity_ops;
lut->entity.type = VSP1_ENTITY_LUT;
 
@@ -211,5 +222,20 @@ struct vsp1_lut *vsp1_lut_create(struct vsp1_device *vsp1)
if (ret < 0)
return ERR_PTR(ret);
 
+   /* Initialize the control handler. */
+   v4l2_ctrl_handler_init(>ctrls, 1);
+   v4l2_ctrl_new_custom(>ctrls, _table_control, NULL);
+
+   lut->entity.subdev.ctrl_handler = >ctrls;
+
+   if (lut->ctrls.error) {
+   dev_err(vsp1->dev, "lut: failed to initialize controls\n");
+   ret = lut->ctrls.error;
+   vsp1_entity_destroy(>entity);
+   return ERR_PTR(ret);
+   }
+
+   v4l2_ctrl_handler_setup(>ctrls);
+
return lut;
 }
diff --git a/drivers/media/platform/vsp1/vsp1_lut.h

[PATCH 15/24] v4l: vsp1: Add Cubic Look Up Table (CLU) support

The CLU processing block is a 2D/3D lookup table that converts the input
three color component data into desired three color components using a
lookup table.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/Makefile  |   2 +-
 drivers/media/platform/vsp1/vsp1.h|   3 +
 drivers/media/platform/vsp1/vsp1_clu.c| 278 ++
 drivers/media/platform/vsp1/vsp1_clu.h|  44 +
 drivers/media/platform/vsp1/vsp1_drv.c|  25 ++-
 drivers/media/platform/vsp1/vsp1_entity.c |   1 +
 drivers/media/platform/vsp1/vsp1_entity.h |   1 +
 drivers/media/platform/vsp1/vsp1_regs.h   |   9 +
 8 files changed, 356 insertions(+), 7 deletions(-)
 create mode 100644 drivers/media/platform/vsp1/vsp1_clu.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_clu.h

diff --git a/drivers/media/platform/vsp1/Makefile 
b/drivers/media/platform/vsp1/Makefile
index a12356bf2135..8ab6a063569e 100644
--- a/drivers/media/platform/vsp1/Makefile
+++ b/drivers/media/platform/vsp1/Makefile
@@ -1,7 +1,7 @@
 vsp1-y := vsp1_drv.o vsp1_entity.o vsp1_pipe.o
 vsp1-y += vsp1_dl.o vsp1_drm.o vsp1_video.o
 vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o
-vsp1-y += vsp1_hsit.o vsp1_lif.o vsp1_lut.o
+vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o
 vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o
 vsp1-y += vsp1_hgo.o vsp1_histo.o
 vsp1-y += vsp1_lif.o
diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 6bf6d54c0ae4..f5e58cea36cc 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -31,6 +31,7 @@ struct vsp1_drm;
 struct vsp1_entity;
 struct vsp1_platform_data;
 struct vsp1_bru;
+struct vsp1_clu;
 struct vsp1_hgo;
 struct vsp1_hsit;
 struct vsp1_lif;
@@ -48,6 +49,7 @@ struct vsp1_uds;
 #define VSP1_HAS_SRU   (1 << 2)
 #define VSP1_HAS_BRU   (1 << 3)
 #define VSP1_HAS_HGO   (1 << 4)
+#define VSP1_HAS_CLU   (1 << 5)
 
 struct vsp1_device_info {
u32 version;
@@ -68,6 +70,7 @@ struct vsp1_device {
struct rcar_fcp_device *fcp;
 
struct vsp1_bru *bru;
+   struct vsp1_clu *clu;
struct vsp1_hgo *hgo;
struct vsp1_hsit *hsi;
struct vsp1_hsit *hst;
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
new file mode 100644
index ..cb14072e57a8
--- /dev/null
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -0,0 +1,278 @@
+/*
+ * vsp1_clu.c  --  R-Car VSP1 Cubic Look-Up Table
+ *
+ * Copyright (C) 2015-2016 Renesas Electronics Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "vsp1.h"
+#include "vsp1_clu.h"
+#include "vsp1_dl.h"
+
+#define CLU_MIN_SIZE   4U
+#define CLU_MAX_SIZE   8190U
+
+/* 
-
+ * Device Access
+ */
+
+static inline void vsp1_clu_write(struct vsp1_clu *clu, struct vsp1_dl_list 
*dl,
+ u32 reg, u32 data)
+{
+   vsp1_dl_list_write(dl, reg, data);
+}
+
+/* 
-
+ * Controls
+ */
+
+#define V4L2_CID_VSP1_CLU_TABLE(V4L2_CID_USER_BASE | 
0x1001)
+#define V4L2_CID_VSP1_CLU_MODE (V4L2_CID_USER_BASE | 0x1002)
+#define V4L2_CID_VSP1_CLU_MODE_2D  0
+#define V4L2_CID_VSP1_CLU_MODE_3D  1
+
+static int clu_set_table(struct vsp1_clu *clu, struct v4l2_ctrl *ctrl)
+{
+   struct vsp1_dl_body *dlb;
+   unsigned int i;
+
+   dlb = vsp1_dl_fragment_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+   if (!dlb)
+   return -ENOMEM;
+
+   vsp1_dl_fragment_write(dlb, VI6_CLU_ADDR, 0);
+   for (i = 0; i < 17 * 17 * 17; ++i)
+   vsp1_dl_fragment_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
+
+   swap(clu->clu, dlb);
+
+   vsp1_dl_fragment_free(dlb);
+   return 0;
+}
+
+static int clu_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct vsp1_clu *clu =
+   container_of(ctrl->handler, struct vsp1_clu, ctrls);
+
+   switch (ctrl->id) {
+   case V4L2_CID_VSP1_CLU_TABLE:
+   clu_set_table(clu, ctrl);
+   break;
+
+   case V4L2_CID_VSP1_CLU_MODE:
+   clu->mode = ctrl->val;
+

[PATCH 22/24] v4l: vsp1: wpf: Add flipping support

Vertical flipping is available on both Gen2 and Gen3, while horizontal
flipping is only available on Gen3.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1.h  |   2 +
 drivers/media/platform/vsp1/vsp1_drv.c  |  15 ++--
 drivers/media/platform/vsp1/vsp1_regs.h |   7 ++
 drivers/media/platform/vsp1/vsp1_rpf.c  |   2 +-
 drivers/media/platform/vsp1/vsp1_rwpf.c |   4 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h |  11 ++-
 drivers/media/platform/vsp1/vsp1_wpf.c  | 143 ++--
 7 files changed, 167 insertions(+), 17 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index f5e58cea36cc..a9b1d251f71a 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -50,6 +50,8 @@ struct vsp1_uds;
 #define VSP1_HAS_BRU   (1 << 3)
 #define VSP1_HAS_HGO   (1 << 4)
 #define VSP1_HAS_CLU   (1 << 5)
+#define VSP1_HAS_WPF_VFLIP (1 << 6)
+#define VSP1_HAS_WPF_HFLIP (1 << 7)
 
 struct vsp1_device_info {
u32 version;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 7e5bd48db2d6..dae1fa47acd7 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -585,7 +585,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPS_H2,
.gen = 2,
.features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO
- | VSP1_HAS_LUT | VSP1_HAS_SRU,
+ | VSP1_HAS_LUT | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.uds_count = 3,
.wpf_count = 4,
@@ -594,7 +594,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
}, {
.version = VI6_IP_VERSION_MODEL_VSPR_H2,
.gen = 2,
-   .features = VSP1_HAS_BRU | VSP1_HAS_SRU,
+   .features = VSP1_HAS_BRU | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.uds_count = 3,
.wpf_count = 4,
@@ -614,7 +614,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPS_M2,
.gen = 2,
.features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO
- | VSP1_HAS_LUT | VSP1_HAS_SRU,
+ | VSP1_HAS_LUT | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.uds_count = 1,
.wpf_count = 4,
@@ -624,7 +624,8 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPI_GEN3,
.gen = 3,
.features = VSP1_HAS_CLU | VSP1_HAS_HGO | VSP1_HAS_LUT
- | VSP1_HAS_SRU,
+ | VSP1_HAS_SRU | VSP1_HAS_WPF_HFLIP
+ | VSP1_HAS_WPF_VFLIP,
.rpf_count = 1,
.uds_count = 1,
.wpf_count = 1,
@@ -632,7 +633,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
}, {
.version = VI6_IP_VERSION_MODEL_VSPBD_GEN3,
.gen = 3,
-   .features = VSP1_HAS_BRU,
+   .features = VSP1_HAS_BRU | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.wpf_count = 1,
.num_bru_inputs = 5,
@@ -641,7 +642,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPBC_GEN3,
.gen = 3,
.features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO
- | VSP1_HAS_LUT,
+ | VSP1_HAS_LUT | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.wpf_count = 1,
.num_bru_inputs = 5,
@@ -649,7 +650,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
}, {
.version = VI6_IP_VERSION_MODEL_VSPD_GEN3,
.gen = 3,
-   .features = VSP1_HAS_BRU | VSP1_HAS_LIF,
+   .features = VSP1_HAS_BRU | VSP1_HAS_LIF | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.wpf_count = 2,
.num_bru_inputs = 5,
diff --git a/drivers/media/platform/vsp1/vsp1_regs.h 
b/drivers/media/platform/vsp1/vsp1_regs.h
index 517a2a6606a3..d8213481edbe 100644
--- a/drivers/media/platform/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -255,6 +255,8 @@
 #define VI6_WPF_OUTFMT_PDV_MASK(0xff << 24)
 #define VI6_WPF_OUTFMT_PDV_SHIFT   24
 #define VI6_WPF_OUTFMT_PXA (1 << 23)
+#define VI6_WPF_OUTFMT_ROT (1 << 18)
+#define VI6_WPF_OUTFMT_HFLP(1 << 17)
 #define VI6_WPF_OUTFMT_FLP (1 << 16)
 #define VI6_WPF_OUTFMT_SPYCS

[PATCH 16/24] v4l: vsp1: sru: Fix intensity control ID

The intensity control reused the V4L2_CID_CONTRAST control ID by
mistake. Fix it by using an ID from the device-specific IDs range.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_sru.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_sru.c 
b/drivers/media/platform/vsp1/vsp1_sru.c
index 9dc7c77c74f8..1a01f9a43875 100644
--- a/drivers/media/platform/vsp1/vsp1_sru.c
+++ b/drivers/media/platform/vsp1/vsp1_sru.c
@@ -37,7 +37,7 @@ static inline void vsp1_sru_write(struct vsp1_sru *sru, 
struct vsp1_dl_list *dl,
  * Controls
  */
 
-#define V4L2_CID_VSP1_SRU_INTENSITY(V4L2_CID_USER_BASE + 1)
+#define V4L2_CID_VSP1_SRU_INTENSITY(V4L2_CID_USER_BASE | 0x1001)
 
 struct vsp1_sru_param {
u32 ctrl0;
-- 
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

[PATCH 17/24] v4l: vsp1: Support runtime modification of controls

Controls are applied to the hardware in the configure operation of the
VSP entities, which is only called when starting the video stream. To
enable runtime modification of controls we need to call the configure
operations for every frame. Doing so is currently not safe, as most
parameters shouldn't be modified during streaming. Furthermore the
configure operation can sleep, preventing it from being called from the
frame completion interrupt handler for the next frame.

Fix this by adding an argument to the configure operation to tell
entities whether to perform a full configuration (as done now) or a
partial runtime configuration. In the latter case the operation will
only configure the subset of parameters related to runtime-configurable
controls, and won't be allowed to sleep when doing so.

Because partial reconfiguration can depend on parameters computed when
performing a full configuration, the core guarantees that the configure
operation will always be called with full and partial modes in that
order at stream start. Entities thus don't have to duplicate
configuration steps in the full and partial code paths.

This change affects the VSP driver core only, all entities return
immediately from the configure operation when called for a partial
runtime configuration. Entities will be modified one by one in further
commits.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_bru.c| 5 -
 drivers/media/platform/vsp1/vsp1_clu.c| 5 -
 drivers/media/platform/vsp1/vsp1_drm.c| 6 --
 drivers/media/platform/vsp1/vsp1_entity.h | 2 +-
 drivers/media/platform/vsp1/vsp1_hgo.c| 5 -
 drivers/media/platform/vsp1/vsp1_hsit.c   | 5 -
 drivers/media/platform/vsp1/vsp1_lif.c| 5 -
 drivers/media/platform/vsp1/vsp1_lut.c| 5 -
 drivers/media/platform/vsp1/vsp1_rpf.c| 5 -
 drivers/media/platform/vsp1/vsp1_sru.c| 5 -
 drivers/media/platform/vsp1/vsp1_uds.c| 5 -
 drivers/media/platform/vsp1/vsp1_video.c  | 8 +++-
 drivers/media/platform/vsp1/vsp1_wpf.c| 5 -
 13 files changed, 52 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index 835593dd88b3..dfd48cf4a11a 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -269,13 +269,16 @@ static struct v4l2_subdev_ops bru_ops = {
 
 static void bru_configure(struct vsp1_entity *entity,
  struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl)
+ struct vsp1_dl_list *dl, bool full)
 {
struct vsp1_bru *bru = to_bru(>subdev);
struct v4l2_mbus_framefmt *format;
unsigned int flags;
unsigned int i;
 
+   if (!full)
+   return;
+
format = vsp1_entity_get_pad_format(>entity, bru->entity.config,
bru->entity.source_pad);
 
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index cb14072e57a8..913070ec09e7 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -205,12 +205,15 @@ static struct v4l2_subdev_ops clu_ops = {
 
 static void clu_configure(struct vsp1_entity *entity,
  struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl)
+ struct vsp1_dl_list *dl, bool full)
 {
struct vsp1_clu *clu = to_clu(>subdev);
struct v4l2_mbus_framefmt *format;
u32 ctrl = VI6_CLU_CTRL_AAI | VI6_CLU_CTRL_MVS | VI6_CLU_CTRL_EN;
 
+   if (!full)
+   return;
+
format = vsp1_entity_get_pad_format(>entity, clu->entity.config,
CLU_PAD_SINK);
 
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index ff961b2c084e..0a98a3c49b73 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -491,8 +491,10 @@ void vsp1_du_atomic_flush(struct device *dev)
 
vsp1_entity_route_setup(entity, pipe, pipe->dl);
 
-   if (entity->ops->configure)
-   entity->ops->configure(entity, pipe, pipe->dl);
+   if (entity->ops->configure) {
+   entity->ops->configure(entity, pipe, pipe->dl, true);
+   entity->ops->configure(entity, pipe, pipe->dl, false);
+   }
 
/* The memory buffer address must be applied after configuring
 * the RPF to make sure the crop offset are computed.
diff --git a/drivers/media/platform/vsp1/vsp1_entity.h 
b/drivers/media/platform/vsp1/vsp1_entity.h
index d2e55fda5f59..4fc2cd1c6620 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.h
+++ b/drivers/media/platform/vsp1/vsp1_entity.h
@@ -74,7 +74,7 @@ struct

[PATCH 07/24] v4l: vsp1: Base link creation on availability of entities

Check the entity pointer instead of the feature flag to see if the
entity is available before creating related links. The two methods are
currently equivalent, but will differ in the future as we implement
support for ignoring some of the entities present in the hardware.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 0d3624a05ef1..c42576825ad4 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -149,7 +149,7 @@ static int vsp1_uapi_create_links(struct vsp1_device *vsp1)
return ret;
}
 
-   if (vsp1->info->features & VSP1_HAS_HGO) {
+   if (vsp1->hgo) {
ret = media_create_pad_link(>hgo->entity.subdev.entity,
HGO_PAD_SOURCE,
>hgo->histo.video.entity, 0,
@@ -159,7 +159,7 @@ static int vsp1_uapi_create_links(struct vsp1_device *vsp1)
return ret;
}
 
-   if (vsp1->info->features & VSP1_HAS_LIF) {
+   if (vsp1->lif) {
ret = media_create_pad_link(>wpf[0]->entity.subdev.entity,
RWPF_PAD_SOURCE,
>lif->entity.subdev.entity,
-- 
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

[PATCH 11/24] v4l: vsp1: pipe: Fix typo in comment

The vsp1_pipeline wq field is a wait queue, not a work queue. Fix the
comment accordingly.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_pipe.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 3ecd3c1794a9..2cbf1a5ea1fb 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -61,7 +61,7 @@ enum vsp1_pipeline_state {
  * @pipe: the media pipeline
  * @irqlock: protects the pipeline state
  * @state: current state
- * @wq: work queue to wait for state change completion
+ * @wq: wait queue to wait for state change completion
  * @frame_end: frame end interrupt handler
  * @lock: protects the pipeline use count and stream count
  * @kref: pipeline reference count
-- 
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

[PATCH 09/24] v4l: vsp1: Don't create LIF entity when the userspace API is enabled

The LIF is only used when feeding the VSP output to the DU. The only way
to do so is by controlling the VSP directly from the DU driver and
disabling the VSP userspace API. There is thus no need to create a LIF
entity when the userspace API is enabled, as it can't be used in that
case.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drv.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index cd56cad3abd9..7b9d95a6af23 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -182,19 +182,15 @@ static int vsp1_uapi_create_links(struct vsp1_device 
*vsp1)
 
for (i = 0; i < vsp1->info->wpf_count; ++i) {
/* Connect the video device to the WPF. All connections are
-* immutable except for the WPF0 source link if a LIF is
-* present.
+* immutable.
 */
struct vsp1_rwpf *wpf = vsp1->wpf[i];
-   unsigned int flags = MEDIA_LNK_FL_ENABLED;
-
-   if (!(vsp1->info->features & VSP1_HAS_LIF) || i != 0)
-   flags |= MEDIA_LNK_FL_IMMUTABLE;
 
ret = media_create_pad_link(>entity.subdev.entity,
RWPF_PAD_SOURCE,
>video->video.entity, 0,
-   flags);
+   MEDIA_LNK_FL_IMMUTABLE |
+   MEDIA_LNK_FL_ENABLED);
if (ret < 0)
return ret;
}
@@ -293,7 +289,11 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
list_add_tail(>hgo->entity.list_dev, >entities);
}
 
-   if (vsp1->info->features & VSP1_HAS_LIF) {
+   /* The LIF is only supported when used in conjunction with the DU, in
+* which case the userspace API is disabled. If the userspace API is
+* enabled skip the LIF, even when present.
+*/
+   if (vsp1->info->features & VSP1_HAS_LIF && !vsp1->info->uapi) {
vsp1->lif = vsp1_lif_create(vsp1);
if (IS_ERR(vsp1->lif)) {
ret = PTR_ERR(vsp1->lif);
-- 
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

[PATCH 12/24] v4l: vsp1: dl: Don't free fragments with interrupts disabled

Freeing a fragment requires freeing DMA coherent memory, which can be
performed with interrupts disabled as per the DMA mapping API contract.
The fragments can't thus be freed synchronously when a display list is
recycled. Instead, move the fragments to a garbage list and use a work
queue to run the garbage collection.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 72 ---
 1 file changed, 58 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index e238d9b9376b..37c3518aa2a8 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vsp1.h"
 #include "vsp1_dl.h"
@@ -92,11 +93,13 @@ enum vsp1_dl_mode {
  * @index: index of the related WPF
  * @mode: display list operation mode (header or headerless)
  * @vsp1: the VSP1 device
- * @lock: protects the active, queued and pending lists
+ * @lock: protects the free, active, queued, pending and gc_fragments lists
  * @free: array of all free display lists
  * @active: list currently being processed (loaded) by hardware
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
+ * @gc_work: fragments garbage collector work struct
+ * @gc_fragments: array of display list fragments waiting to be freed
  */
 struct vsp1_dl_manager {
unsigned int index;
@@ -108,6 +111,9 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *active;
struct vsp1_dl_list *queued;
struct vsp1_dl_list *pending;
+
+   struct work_struct gc_work;
+   struct list_head gc_fragments;
 };
 
 /* 
-
@@ -262,21 +268,10 @@ static struct vsp1_dl_list *vsp1_dl_list_alloc(struct 
vsp1_dl_manager *dlm)
return dl;
 }
 
-static void vsp1_dl_list_free_fragments(struct vsp1_dl_list *dl)
-{
-   struct vsp1_dl_body *dlb, *next;
-
-   list_for_each_entry_safe(dlb, next, >fragments, list) {
-   list_del(>list);
-   vsp1_dl_body_cleanup(dlb);
-   kfree(dlb);
-   }
-}
-
 static void vsp1_dl_list_free(struct vsp1_dl_list *dl)
 {
vsp1_dl_body_cleanup(>body0);
-   vsp1_dl_list_free_fragments(dl);
+   list_splice_init(>fragments, >dlm->gc_fragments);
kfree(dl);
 }
 
@@ -311,7 +306,16 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list *dl)
if (!dl)
return;
 
-   vsp1_dl_list_free_fragments(dl);
+   /* We can't free fragments here as DMA memory can only be freed in
+* interruptible context. Move all fragments to the display list
+* manager's list of fragments to be freed, they will be
+* garbage-collected by the work queue.
+*/
+   if (!list_empty(>fragments)) {
+   list_splice_init(>fragments, >dlm->gc_fragments);
+   schedule_work(>dlm->gc_work);
+   }
+
dl->body0.num_entries = 0;
 
list_add_tail(>list, >dlm->free);
@@ -550,6 +554,40 @@ void vsp1_dlm_reset(struct vsp1_dl_manager *dlm)
dlm->pending = NULL;
 }
 
+/*
+ * Free all fragments awaiting to be garbage-collected.
+ *
+ * This function must be called without the display list manager lock held.
+ */
+static void vsp1_dlm_fragments_free(struct vsp1_dl_manager *dlm)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+
+   while (!list_empty(>gc_fragments)) {
+   struct vsp1_dl_body *dlb;
+
+   dlb = list_first_entry(>gc_fragments, struct vsp1_dl_body,
+  list);
+   list_del(>list);
+
+   spin_unlock_irqrestore(>lock, flags);
+   vsp1_dl_fragment_free(dlb);
+   spin_lock_irqsave(>lock, flags);
+   }
+
+   spin_unlock_irqrestore(>lock, flags);
+}
+
+static void vsp1_dlm_garbage_collect(struct work_struct *work)
+{
+   struct vsp1_dl_manager *dlm =
+   container_of(work, struct vsp1_dl_manager, gc_work);
+
+   vsp1_dlm_fragments_free(dlm);
+}
+
 struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device *vsp1,
unsigned int index,
unsigned int prealloc)
@@ -568,6 +606,8 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
 
spin_lock_init(>lock);
INIT_LIST_HEAD(>free);
+   INIT_LIST_HEAD(>gc_fragments);
+   INIT_WORK(>gc_work, vsp1_dlm_garbage_collect);
 
for (i = 0; i < prealloc; ++i) {
struct vsp1_dl_list *dl;
@@ -589,8 +629,12 @@ void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm)
if (!dlm)
return;
 
+   cancel_work_sync(>gc_work);
+
list_for_each_entry_safe(dl, next,

[PATCH 02/24] v4l: Define a pixel format for the R-Car VSP1 1-D histogram engine

The format is used on the R-Car VSP1 video queues that carry
1-D histogram statistics data.

Signed-off-by: Laurent Pinchart 
Acked-by: Sakari Ailus 
---
 .../DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml | 307 +
 Documentation/DocBook/media/v4l/pixfmt.xml |   9 +
 drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
 include/uapi/linux/videodev2.h |   3 +
 4 files changed, 320 insertions(+)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml

diff --git a/Documentation/DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml 
b/Documentation/DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml
new file mode 100644
index ..b40bd10695d2
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml
@@ -0,0 +1,307 @@
+
+  
+V4L2_META_FMT_VSP1_HGO ('VSPH')
+
+  
+  
+
+  V4L2_META_FMT_VSP1_HGO
+
+Renesas R-Car VSP1 1-D Histogram Data
+  
+  
+Description
+
+This format describes histogram data generated by the Renesas R-Car VSP1 1-D
+Histogram (HGO) engine.
+
+
+The VSP1 HGO is a histogram computation engine that can operate on RGB, YCrCb
+or HSV data. It operates on a possibly cropped and subsampled input image and
+computes the minimum, maximum and sum of all pixels as well as per-channel
+histograms.
+
+The HGO can compute histograms independently per channel, on the maximum of the
+three channels (RGB data only) or on the Y channel only (YCbCr only). It can
+additionally output the histogram with 64 or 256 bins, resulting in four
+possible modes of operation.
+  
+   
+ 
+   In 64 bins normal mode, the HGO operates
+   on the three channels independently to compute three 64-bins
+   histograms. RGB, YCbCr and HSV image formats are supported.
+ 
+   
+   
+ 
+   In 64 bins maximum mode, the HGO operates
+   on the maximum of the (R, G, B) channels to compute a single
+   64-bins histogram. Only the RGB image format is supported.
+ 
+   
+   
+ 
+   In 256 bins normal mode, the HGO operates
+   on the Y channel to compute a single 256-bins histogram. Only the
+   YCbCr image format is supported.
+ 
+   
+   
+ 
+   In 256 bins maximum mode, the HGO operates
+   on the maximum of the (R, G, B) channels to compute a single
+   256-bins histogram. Only the RGB image format is supported.
+ 
+   
+  
+
+
+
+All data is stored in memory in little endian format. Each cell in the tables
+below contains one byte.
+
+
+  VSP1 HGO Data - 64 Bins, Normal Mode (792 bytes)
+  
+   
+   
+   
+   
+   
+   
+   
+ 
+   Offset
+   Memory
+ 
+ 
+   
+   [31:24]
+   [23:16]
+   [15:8]
+   [7:0]
+ 
+   
+   
+ 
+   0
+   -
+   R/Cr/H max [7:0]
+   -
+   R/Cr/H min [7:0]
+ 
+ 
+   4
+   -
+   G/Y/S max [7:0]
+   -
+   G/Y/S min [7:0]
+ 
+ 
+   8
+   -
+   B/Cb/V max [7:0]
+   -
+   B/Cb/V min [7:0]
+ 
+ 
+   12
+   R/Cr/H sum [31:0]
+ 
+ 
+   16
+   G/Y/S sum [31:0]
+ 
+ 
+   20
+   B/Cb/V sum [31:0]
+ 
+ 
+   24
+   R/Cr/H bin 0 [31:0]
+ 
+ 
+   
+   ...
+ 
+ 
+   276
+   R/Cr/H bin 63 [31:0]
+ 
+ 
+   280
+   G/Y/S bin 0 [31:0]
+ 
+ 
+   
+   ...
+ 
+ 
+   532
+   G/Y/S bin 63 [31:0]
+ 
+ 
+   536
+   B/Cb/V bin 0 [31:0]
+ 
+ 
+   
+   ...
+ 
+ 
+   788
+   B/Cb/V bin 63 [31:0]
+ 
+   
+  
+
+
+  VSP1 HGO Data - 64 Bins, Max Mode (264 bytes)
+  
+   
+   
+   
+   
+   
+   
+   
+ 
+   Offset
+   Memory
+ 
+ 
+   
+   [31:24]
+   [23:16]
+   [15:8]
+   [7:0]
+ 
+   
+   
+ 
+   0
+   -
+   max(R,G,B) max [7:0]
+   -
+   max(R,G,B) min [7:0]
+ 
+ 
+   4
+   max(R,G,B) sum [31:0]
+ 
+ 
+   8
+   max(R,G,B) bin 0 [31:0]
+ 
+ 
+   
+   ...
+ 
+ 
+   260
+   max(R,G,B) bin 63 [31:0]
+ 
+   
+  
+
+
+

[PATCH 04/24] v4l: vsp1: Don't create HGO entity when the userspace API is disabled

The HGO is never used in the DRM pipeline, there is thus no need to
create an HGO entity when the userspace API is disabled.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 3e94e1921656..0d3624a05ef1 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -282,7 +282,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
 
list_add_tail(>hst->entity.list_dev, >entities);
 
-   if (vsp1->info->features & VSP1_HAS_HGO) {
+   if (vsp1->info->features & VSP1_HAS_HGO && vsp1->info->uapi) {
vsp1->hgo = vsp1_hgo_create(vsp1);
if (IS_ERR(vsp1->hgo)) {
ret = PTR_ERR(vsp1->hgo);
-- 
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

[PATCH 03/24] v4l: vsp1: Add HGO support

The HGO is a Histogram Generator One-Dimension. It computes per-channel
histograms over a configurable region of the image with optional
subsampling.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/Kconfig|   1 +
 drivers/media/platform/vsp1/Makefile  |   2 +
 drivers/media/platform/vsp1/vsp1.h|   3 +
 drivers/media/platform/vsp1/vsp1_drm.c|   2 +-
 drivers/media/platform/vsp1/vsp1_drv.c|  37 ++-
 drivers/media/platform/vsp1/vsp1_entity.c | 136 +++-
 drivers/media/platform/vsp1/vsp1_entity.h |   7 +-
 drivers/media/platform/vsp1/vsp1_hgo.c| 496 ++
 drivers/media/platform/vsp1/vsp1_hgo.h|  50 +++
 drivers/media/platform/vsp1/vsp1_histo.c  | 307 ++
 drivers/media/platform/vsp1/vsp1_histo.h  |  68 
 drivers/media/platform/vsp1/vsp1_pipe.c   |  30 +-
 drivers/media/platform/vsp1/vsp1_pipe.h   |   2 +
 drivers/media/platform/vsp1/vsp1_regs.h   |  24 +-
 drivers/media/platform/vsp1/vsp1_video.c  |  22 +-
 15 files changed, 1148 insertions(+), 39 deletions(-)
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.h
 create mode 100644 drivers/media/platform/vsp1/vsp1_histo.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_histo.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index a3304466e628..0141af8cfdbc 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -266,6 +266,7 @@ config VIDEO_RENESAS_VSP1
depends on (ARCH_RENESAS && OF) || COMPILE_TEST
depends on !ARM64 || VIDEO_RENESAS_FCP
select VIDEOBUF2_DMA_CONTIG
+   select VIDEOBUF2_VMALLOC
---help---
  This is a V4L2 driver for the Renesas VSP1 video processing engine.
 
diff --git a/drivers/media/platform/vsp1/Makefile 
b/drivers/media/platform/vsp1/Makefile
index 95b3ac2ea7ef..a12356bf2135 100644
--- a/drivers/media/platform/vsp1/Makefile
+++ b/drivers/media/platform/vsp1/Makefile
@@ -3,5 +3,7 @@ vsp1-y  += vsp1_dl.o vsp1_drm.o 
vsp1_video.o
 vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o
 vsp1-y += vsp1_hsit.o vsp1_lif.o vsp1_lut.o
 vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o
+vsp1-y += vsp1_hgo.o vsp1_histo.o
+vsp1-y += vsp1_lif.o
 
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1.o
diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 7cb0f5e428df..6bf6d54c0ae4 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -31,6 +31,7 @@ struct vsp1_drm;
 struct vsp1_entity;
 struct vsp1_platform_data;
 struct vsp1_bru;
+struct vsp1_hgo;
 struct vsp1_hsit;
 struct vsp1_lif;
 struct vsp1_lut;
@@ -46,6 +47,7 @@ struct vsp1_uds;
 #define VSP1_HAS_LUT   (1 << 1)
 #define VSP1_HAS_SRU   (1 << 2)
 #define VSP1_HAS_BRU   (1 << 3)
+#define VSP1_HAS_HGO   (1 << 4)
 
 struct vsp1_device_info {
u32 version;
@@ -66,6 +68,7 @@ struct vsp1_device {
struct rcar_fcp_device *fcp;
 
struct vsp1_bru *bru;
+   struct vsp1_hgo *hgo;
struct vsp1_hsit *hsi;
struct vsp1_hsit *hst;
struct vsp1_lif *lif;
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 14730119687f..ff961b2c084e 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -489,7 +489,7 @@ void vsp1_du_atomic_flush(struct device *dev)
}
}
 
-   vsp1_entity_route_setup(entity, pipe->dl);
+   vsp1_entity_route_setup(entity, pipe, pipe->dl);
 
if (entity->ops->configure)
entity->ops->configure(entity, pipe, pipe->dl);
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 70e7a81e8255..3e94e1921656 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -29,6 +29,7 @@
 #include "vsp1_bru.h"
 #include "vsp1_dl.h"
 #include "vsp1_drm.h"
+#include "vsp1_hgo.h"
 #include "vsp1_hsit.h"
 #include "vsp1_lif.h"
 #include "vsp1_lut.h"
@@ -104,7 +105,8 @@ static int vsp1_create_sink_links(struct vsp1_device *vsp1,
if (source->type == sink->type)
continue;
 
-   if (source->type == VSP1_ENTITY_LIF ||
+   if (source->type == VSP1_ENTITY_HGO ||
+   source->type == VSP1_ENTITY_LIF ||
source->type == VSP1_ENTITY_WPF)
continue;
 
@@ -147,6 +149,16 @@ static int vsp1_uapi_create_links(struct vsp1_device *vsp1)
return ret;
}
 
+   if

[PATCH 10/24] v4l: vsp1: Set entities functions

Initialize the function field of all subdev entities instantiated by the
driver. This gets rids of multiple warnings printed by the media
controller core.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_bru.c| 3 ++-
 drivers/media/platform/vsp1/vsp1_entity.c | 3 ++-
 drivers/media/platform/vsp1/vsp1_entity.h | 2 +-
 drivers/media/platform/vsp1/vsp1_hgo.c| 3 ++-
 drivers/media/platform/vsp1/vsp1_hsit.c   | 5 +++--
 drivers/media/platform/vsp1/vsp1_lif.c| 7 ++-
 drivers/media/platform/vsp1/vsp1_lut.c| 3 ++-
 drivers/media/platform/vsp1/vsp1_rpf.c| 3 ++-
 drivers/media/platform/vsp1/vsp1_sru.c| 3 ++-
 drivers/media/platform/vsp1/vsp1_uds.c| 3 ++-
 drivers/media/platform/vsp1/vsp1_wpf.c| 3 ++-
 11 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index b1068c018011..835593dd88b3 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -390,7 +390,8 @@ struct vsp1_bru *vsp1_bru_create(struct vsp1_device *vsp1)
bru->entity.type = VSP1_ENTITY_BRU;
 
ret = vsp1_entity_init(vsp1, >entity, "bru",
-  vsp1->info->num_bru_inputs + 1, _ops);
+  vsp1->info->num_bru_inputs + 1, _ops,
+  MEDIA_ENT_F_PROC_VIDEO_COMPOSER);
if (ret < 0)
return ERR_PTR(ret);
 
diff --git a/drivers/media/platform/vsp1/vsp1_entity.c 
b/drivers/media/platform/vsp1/vsp1_entity.c
index 42f9b00ffc3b..6893f9d33941 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.c
+++ b/drivers/media/platform/vsp1/vsp1_entity.c
@@ -443,7 +443,7 @@ static const struct vsp1_route vsp1_routes[] = {
 
 int vsp1_entity_init(struct vsp1_device *vsp1, struct vsp1_entity *entity,
 const char *name, unsigned int num_pads,
-const struct v4l2_subdev_ops *ops)
+const struct v4l2_subdev_ops *ops, u32 function)
 {
struct v4l2_subdev *subdev;
unsigned int i;
@@ -491,6 +491,7 @@ int vsp1_entity_init(struct vsp1_device *vsp1, struct 
vsp1_entity *entity,
subdev = >subdev;
v4l2_subdev_init(subdev, ops);
 
+   subdev->entity.function = function;
subdev->entity.ops = >media_ops;
subdev->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/media/platform/vsp1/vsp1_entity.h 
b/drivers/media/platform/vsp1/vsp1_entity.h
index d599c8cc99b7..63e3990eb495 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.h
+++ b/drivers/media/platform/vsp1/vsp1_entity.h
@@ -106,7 +106,7 @@ static inline struct vsp1_entity *to_vsp1_entity(struct 
v4l2_subdev *subdev)
 
 int vsp1_entity_init(struct vsp1_device *vsp1, struct vsp1_entity *entity,
 const char *name, unsigned int num_pads,
-const struct v4l2_subdev_ops *ops);
+const struct v4l2_subdev_ops *ops, u32 function);
 void vsp1_entity_destroy(struct vsp1_entity *entity);
 
 extern const struct v4l2_subdev_internal_ops vsp1_subdev_internal_ops;
diff --git a/drivers/media/platform/vsp1/vsp1_hgo.c 
b/drivers/media/platform/vsp1/vsp1_hgo.c
index a8b0d6ed00a5..4f15e1090384 100644
--- a/drivers/media/platform/vsp1/vsp1_hgo.c
+++ b/drivers/media/platform/vsp1/vsp1_hgo.c
@@ -465,7 +465,8 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device *vsp1)
hgo->entity.ops = _entity_ops;
hgo->entity.type = VSP1_ENTITY_HGO;
 
-   ret = vsp1_entity_init(vsp1, >entity, "hgo", 2, _ops);
+   ret = vsp1_entity_init(vsp1, >entity, "hgo", 2, _ops,
+  MEDIA_ENT_F_PROC_VIDEO_STATISTICS);
if (ret < 0)
return ERR_PTR(ret);
 
diff --git a/drivers/media/platform/vsp1/vsp1_hsit.c 
b/drivers/media/platform/vsp1/vsp1_hsit.c
index 68b8567b374d..41b09e49e659 100644
--- a/drivers/media/platform/vsp1/vsp1_hsit.c
+++ b/drivers/media/platform/vsp1/vsp1_hsit.c
@@ -161,8 +161,9 @@ struct vsp1_hsit *vsp1_hsit_create(struct vsp1_device 
*vsp1, bool inverse)
else
hsit->entity.type = VSP1_ENTITY_HST;
 
-   ret = vsp1_entity_init(vsp1, >entity, inverse ? "hsi" : "hst", 2,
-  _ops);
+   ret = vsp1_entity_init(vsp1, >entity, inverse ? "hsi" : "hst",
+  2, _ops,
+  MEDIA_ENT_F_PROC_VIDEO_PIXEL_ENC_CONV);
if (ret < 0)
return ERR_PTR(ret);
 
diff --git a/drivers/media/platform/vsp1/vsp1_lif.c 
b/drivers/media/platform/vsp1/vsp1_lif.c
index 0217393f22df..60d26b600768 100644
--- a/drivers/media/platform/vsp1/vsp1_lif.c
+++ b/drivers/media/platform/vsp1/vsp1_lif.c
@@ -165,7 +165,12 @@ struct vsp1_lif *vsp1_lif_create(struct vsp1_device *vsp1)
lif->entity.ops = _entity_ops;
lif->entity.type = VSP1_ENTITY_LIF;
 
-   ret =

[PATCH 08/24] v4l: vsp1: Don't register media device when userspace API is disabled

The media device doesn't need to be exposed to userspace when the VSP is
fully controlled by the DU driver. Don't register it in that case.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drv.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index c42576825ad4..cd56cad3abd9 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -218,7 +218,8 @@ static void vsp1_destroy_entities(struct vsp1_device *vsp1)
}
 
v4l2_device_unregister(>v4l2_dev);
-   media_device_unregister(>media_dev);
+   if (vsp1->info->uapi)
+   media_device_unregister(>media_dev);
media_device_cleanup(>media_dev);
 
if (!vsp1->info->uapi)
@@ -403,14 +404,15 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
/* Register subdev nodes if the userspace API is enabled or initialize
 * the DRM pipeline otherwise.
 */
-   if (vsp1->info->uapi)
+   if (vsp1->info->uapi) {
ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
-   else
-   ret = vsp1_drm_init(vsp1);
-   if (ret < 0)
-   goto done;
+   if (ret < 0)
+   goto done;
 
-   ret = media_device_register(mdev);
+   ret = media_device_register(mdev);
+   } else {
+   ret = vsp1_drm_init(vsp1);
+   }
 
 done:
if (ret < 0)
-- 
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

[PATCH 05/24] media: Add video processing entity functions

Add composer, pixel formatter, pixel encoding converter and scaler
functions.

Signed-off-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
Acked-by: Sakari Ailus 
---
 Documentation/DocBook/media/v4l/media-types.xml | 55 +
 include/uapi/linux/media.h  |  9 
 2 files changed, 64 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/media-types.xml 
b/Documentation/DocBook/media/v4l/media-types.xml
index 5e3f20fdcf17..60fe841f8846 100644
--- a/Documentation/DocBook/media/v4l/media-types.xml
+++ b/Documentation/DocBook/media/v4l/media-types.xml
@@ -121,6 +121,61 @@
MEDIA_ENT_F_AUDIO_MIXER
Audio Mixer Function Entity.
  
+ 
+   MEDIA_ENT_F_PROC_VIDEO_COMPOSER
+   Video composer (blender). An entity capable of video
+  composing must have at least two sink pads and one source
+  pad, and composes input video frames onto output video
+  frames. Composition can be performed using alpha blending,
+  color keying, raster operations (ROP), stitching or any other
+  means.
+   
+ 
+ 
+   
MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER
+   Video pixel formatter. An entity capable of pixel formatting
+  must have at least one sink pad and one source pad. Read
+  pixel formatters read pixels from memory and perform a subset
+  of unpacking, cropping, color keying, alpha multiplication
+  and pixel encoding conversion. Write pixel formatters perform
+  a subset of dithering, pixel encoding conversion and packing
+  and write pixels to memory.
+   
+ 
+ 
+   
MEDIA_ENT_F_PROC_VIDEO_PIXEL_ENC_CONV
+   Video pixel encoding converter. An entity capable of pixel
+  enconding conversion must have at least one sink pad and one
+  source pad, and convert the encoding of pixels received on
+  its sink pad(s) to a different encoding output on its source
+  pad(s). Pixel encoding conversion includes but isn't limited
+  to RGB to/from HSV, RGB to/from YUV and CFA (Bayer) to RGB
+  conversions.
+   
+ 
+ 
+   MEDIA_ENT_F_PROC_VIDEO_LUT
+   Video look-up table. An entity capable of video lookup table
+  processing must have one sink pad and one source pad. It uses
+  the values of the pixels received on its sink pad to look up
+  entries in internal tables and output them on its source pad.
+  The lookup processing can be performed on all components
+  separately or combine them for multi-dimensional table
+  lookups.
+   
+ 
+ 
+   MEDIA_ENT_F_PROC_VIDEO_SCALER
+   Video scaler. An entity capable of video scaling must have
+  at least one sink pad and one source pad, and scale the
+  video frame(s) received on its sink pad(s) to a different
+  resolution output on its source pad(s). The range of
+  supported scaling ratios is entity-specific and can differ
+  between the horizontal and vertical directions (in particular
+  scaling can be supported in one direction only). Binning and
+  skipping are considered as scaling.
+   
+ 

   
 
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index df59edee25d1..3136686c4bd0 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -95,6 +95,15 @@ struct media_device_info {
 #define MEDIA_ENT_F_AUDIO_MIXER(MEDIA_ENT_F_BASE + 0x03003)
 
 /*
+ * Processing entities
+ */
+#define MEDIA_ENT_F_PROC_VIDEO_COMPOSER(MEDIA_ENT_F_BASE + 
0x4001)
+#define MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER (MEDIA_ENT_F_BASE + 0x4002)
+#define MEDIA_ENT_F_PROC_VIDEO_PIXEL_ENC_CONV  (MEDIA_ENT_F_BASE + 0x4003)
+#define MEDIA_ENT_F_PROC_VIDEO_LUT (MEDIA_ENT_F_BASE + 0x4004)
+#define MEDIA_ENT_F_PROC_VIDEO_SCALER  (MEDIA_ENT_F_BASE + 0x4005)
+
+/*
  * Connectors
  */
 /* It is a responsibility of the entity drivers to add connectors and links */
-- 
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

[PATCH 06/24] media: Add video statistics computation functions

The video statistics function describes entities such as video histogram
engines or 3A statistics engines.

Signed-off-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
Acked-by: Sakari Ailus 
---
 Documentation/DocBook/media/v4l/media-types.xml | 9 +
 include/uapi/linux/media.h  | 1 +
 2 files changed, 10 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/media-types.xml 
b/Documentation/DocBook/media/v4l/media-types.xml
index 60fe841f8846..95aa1f9c836a 100644
--- a/Documentation/DocBook/media/v4l/media-types.xml
+++ b/Documentation/DocBook/media/v4l/media-types.xml
@@ -176,6 +176,15 @@
   skipping are considered as scaling.

  
+ 
+   
MEDIA_ENT_F_PROC_VIDEO_STATISTICS
+   Video statistics computation (histogram, 3A, ...). An entity
+  capable of statistics computation must have one sink pad and
+  one source pad. It computes statistics over the frames
+  received on its sink pad and outputs the statistics data on
+  its source pad.
+   
+ 

   
 
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 3136686c4bd0..7acf0f634f70 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -102,6 +102,7 @@ struct media_device_info {
 #define MEDIA_ENT_F_PROC_VIDEO_PIXEL_ENC_CONV  (MEDIA_ENT_F_BASE + 0x4003)
 #define MEDIA_ENT_F_PROC_VIDEO_LUT (MEDIA_ENT_F_BASE + 0x4004)
 #define MEDIA_ENT_F_PROC_VIDEO_SCALER  (MEDIA_ENT_F_BASE + 0x4005)
+#define MEDIA_ENT_F_PROC_VIDEO_STATISTICS  (MEDIA_ENT_F_BASE + 0x4006)
 
 /*
  * Connectors
-- 
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

[PATCH 13/24] v4l: vsp1: lut: Initialize the mutex

The LUT mutex isn't initialized when creating the LUT, fix it.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_lut.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_lut.c 
b/drivers/media/platform/vsp1/vsp1_lut.c
index 2c367cb9755c..9a2c55b3570a 100644
--- a/drivers/media/platform/vsp1/vsp1_lut.c
+++ b/drivers/media/platform/vsp1/vsp1_lut.c
@@ -201,6 +201,8 @@ struct vsp1_lut *vsp1_lut_create(struct vsp1_device *vsp1)
if (lut == NULL)
return ERR_PTR(-ENOMEM);
 
+   mutex_init(>lock);
+
lut->entity.ops = _entity_ops;
lut->entity.type = VSP1_ENTITY_LUT;
 
-- 
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 5/5] media: Support variable size IOCTL arguments

Hi Hans,

On Fri, Jun 17, 2016 at 06:21:05PM +0200, Hans Verkuil wrote:
> On 05/05/2016 01:06 AM, Sakari Ailus wrote:
> > Instead of checking for a strict size for the IOCTL arguments, place
> > minimum and maximum limits.
> > 
> > As an additional bonus, IOCTL handlers will be able to check whether the
> > caller actually set (using the argument size) the field vs. assigning it
> > to zero. Separate macro can be provided for that.
> > 
> > This will be easier for applications as well since there is no longer the
> > problem of setting the reserved fields zero, or at least it is a lesser
> > problem.
> > 
> > Signed-off-by: Sakari Ailus 
> 
> Acked-by: Hans Verkuil 
> 
> I think it is important to have exact matches instead of using a min-max
> range. Issues related to alignment problems on different architectures
> (32/64 bits, how padding in struct is handled, etc.) that could cause a
> different size should be caught by the validation check. Any size other
> than this discrete list of allowed sizes is an indication that something
> is seriously wrong on the kernel or userspace side.

Depending on how many fields are added to a new version of a struct, it may
end up that the size of a malformed user IOCTL still matches with a
different version of a struct. I don't think you benefit too much from such
a list, yet there will be a growing number of different versions of the
struct available. We could (and should) certainly hide them to another
header file though.

There's a cost, small but still a cost, in going through such a list to find
the right size.

The IOCTL arguments should always be packed, too, and follow sane field
alignment.

I have no strong opinion on the matter but would like to find an agreement
for the purpose of being able to rely on this functionality in the new
request and event IOCTLs.

> 
> If we get ioctls that have a variable-sized array at the end, then that
> should be signaled differently in the media_ioctl_info struct. We'll
> handle that when that happens.

Yes, we can add a flag for handling those when we get the first one.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: 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: Nokia N900 cameras -- pipeline setup in python (was Re: [RFC PATCH 00/24] Make Nokia N900 cameras working)

2016-06-20 Thread Pavel Machek

On Fri 2016-06-17 19:12:14, Pavel Machek wrote:
> Hi!
> 
> > First, I re-did pipeline setup in python, it seems slightly less hacky
> > then in shell.
> > 
> > I tried to modify fcam-dev to work with the new interface, but was not
> > successful so far. I can post patches if someone is interested
> > (mplayer works for me, but that's not too suitable for taking photos).
> > 
> > I tried to get gstreamer to work, with something like:
> 
> While trying to debug gstreamer, I ran v4l2-compliance, and it seems
> to suggest that QUERYCAP is required... but it is not present on
> /dev/video2 or video6.
> 
> Any ideas? (Kernel is based on Ivaylo 's github tree, IIRC).

I got fcam-dev to grab jpeg-s from the camera. Unfortunately, 800x600,
no autogain, no autofocus. But lot of fun with memory management :-).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 v2 1/7] v4l: Correct the ordering of LSBs of the 10-bit raw packed formats

On 06/20/2016 06:20 PM, Sakari Ailus wrote:
> The 10-bit packed raw bayer format documented that the data of the first
> pixel of a four-pixel group was found in the first byte and the two
> highest bits of the fifth byte. This was not entirely correct. The two
> bits in the fifth byte are the two lowest bits. The second pixel occupies
> the second byte and third and fourth least significant bits and so on.
> 
> Signed-off-by: Sakari Ailus 

As mentioned, this needs confirmation. I wonder, isn't this specified in the UVC
spec?

Regards,

Hans

> ---
>  .../DocBook/media/v4l/pixfmt-srggb10p.xml  | 32 
> +++---
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
> index a8cc102..747822b 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
> @@ -47,10 +47,10 @@
> G01high
> B02high
> G03high
> -   B00low(bits 7--6)
> -  G01low(bits 5--4)
> -  B02low(bits 3--2)
> -  G03low(bits 1--0)
> +   G03low(bits 7--6)
> +  B02low(bits 5--4)
> +  G01low(bits 3--2)
> +  B00low(bits 1--0)
> 
>   
>   
> @@ -59,10 +59,10 @@
> R11high
> G12high
> R13high
> -   G10low(bits 7--6)
> -  R11low(bits 5--4)
> -  G12low(bits 3--2)
> -  R13low(bits 1--0)
> +   R13low(bits 7--6)
> +  G12low(bits 5--4)
> +  R11low(bits 3--2)
> +  G10low(bits 1--0)
> 
>   
>   
> @@ -71,10 +71,10 @@
> G21high
> B22high
> G23high
> -   B20low(bits 7--6)
> -  G21low(bits 5--4)
> -  B22low(bits 3--2)
> -  G23low(bits 1--0)
> +   G23low(bits 7--6)
> +  B22low(bits 5--4)
> +  G21low(bits 3--2)
> +  B20low(bits 1--0)
> 
>   
>   
> @@ -83,10 +83,10 @@
> R31high
> G32high
> R33high
> -   G30low(bits 7--6)
> -  R31low(bits 5--4)
> -  G32low(bits 3--2)
> -  R33low(bits 1--0)
> +   R33low(bits 7--6)
> +  G32low(bits 5--4)
> +  R31low(bits 3--2)
> +  G30low(bits 1--0)
> 
>   
> 
> 
--
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 2/7] v4l: Fix number of zeroed high order bits in 12-bit raw format defs

On 06/20/2016 06:20 PM, Sakari Ailus wrote:
> The number of high order bits in samples was documented to be 6 for 12-bit
> data. This is clearly wrong, fix it.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Hans

> ---
>  Documentation/DocBook/media/v4l/pixfmt-srggb12.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
> index 0c8e4ad..4394101 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
> @@ -31,7 +31,7 @@ pixel image
>  
>
>   Byte Order.
> - Each cell is one byte, high 6 bits in high bytes are 0.
> + Each cell is one byte, high 4 bits in high bytes are 0.
> 
>   
> 
> 
--
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 3/7] v4l: Clean up raw bayer pixel format definitions

On 06/20/2016 06:20 PM, Sakari Ailus wrote:
> - Explicitly state that the most significant n bits are zeroed on 10 and
>   12 bpp formats.
> - Remove extra comma from the last entry of the format list
> - Add a missing colon before a list
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Hans

> ---
>  Documentation/DocBook/media/v4l/pixfmt-srggb10.xml  | 5 +++--
>  Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml | 2 +-
>  Documentation/DocBook/media/v4l/pixfmt-srggb12.xml  | 5 +++--
>  3 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> index f34d03e..cd3f915 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> @@ -23,7 +23,7 @@ unused high bits filled with zeros. Each n-pixel row 
> contains n/2 green samples
>  and n/2 blue or red samples, with alternating red and blue rows. Bytes are
>  stored in memory in little endian order. They are conventionally described
>  as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
> -formats
> +formats:
>  
>  
>V4L2_PIX_FMT_SBGGR10 4  4
> @@ -31,7 +31,8 @@ pixel image
>  
>
>   Byte Order.
> - Each cell is one byte, high 6 bits in high bytes are 0.
> + Each cell is one byte, the 6 most significant bits in the high
> +   bytes are 0.
> 
>   
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
> index 747822b..18bb722 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
> @@ -3,7 +3,7 @@
>   V4L2_PIX_FMT_SRGGB10P ('pRAA'),
>V4L2_PIX_FMT_SGRBG10P ('pgAA'),
>V4L2_PIX_FMT_SGBRG10P ('pGAA'),
> -  V4L2_PIX_FMT_SBGGR10P ('pBAA'),
> +  V4L2_PIX_FMT_SBGGR10P ('pBAA')
>
>   
>
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
> index 4394101..2d8efeb 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
> @@ -23,7 +23,7 @@ unused high bits filled with zeros. Each n-pixel row 
> contains n/2 green samples
>  and n/2 blue or red samples, with alternating red and blue rows. Bytes are
>  stored in memory in little endian order. They are conventionally described
>  as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
> -formats
> +formats:
>  
>  
>V4L2_PIX_FMT_SBGGR12 4  4
> @@ -31,7 +31,8 @@ pixel image
>  
>
>   Byte Order.
> - Each cell is one byte, high 4 bits in high bytes are 0.
> + Each cell is one byte, the 4 most significant bits in the high
> +   bytes are 0.
> 
>   
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/7] v4l: Correct the ordering of LSBs of the 10-bit raw packed formats

The 10-bit packed raw bayer format documented that the data of the first
pixel of a four-pixel group was found in the first byte and the two
highest bits of the fifth byte. This was not entirely correct. The two
bits in the fifth byte are the two lowest bits. The second pixel occupies
the second byte and third and fourth least significant bits and so on.

Signed-off-by: Sakari Ailus 
---
 .../DocBook/media/v4l/pixfmt-srggb10p.xml  | 32 +++---
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml 
b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
index a8cc102..747822b 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
@@ -47,10 +47,10 @@
  G01high
  B02high
  G03high
- B00low(bits 7--6)
-G01low(bits 5--4)
-B02low(bits 3--2)
-G03low(bits 1--0)
+ G03low(bits 7--6)
+B02low(bits 5--4)
+G01low(bits 3--2)
+B00low(bits 1--0)
  


@@ -59,10 +59,10 @@
  R11high
  G12high
  R13high
- G10low(bits 7--6)
-R11low(bits 5--4)
-G12low(bits 3--2)
-R13low(bits 1--0)
+ R13low(bits 7--6)
+G12low(bits 5--4)
+R11low(bits 3--2)
+G10low(bits 1--0)
  


@@ -71,10 +71,10 @@
  G21high
  B22high
  G23high
- B20low(bits 7--6)
-G21low(bits 5--4)
-B22low(bits 3--2)
-G23low(bits 1--0)
+ G23low(bits 7--6)
+B22low(bits 5--4)
+G21low(bits 3--2)
+B20low(bits 1--0)
  


@@ -83,10 +83,10 @@
  R31high
  G32high
  R33high
- G30low(bits 7--6)
-R31low(bits 5--4)
-G32low(bits 3--2)
-R33low(bits 1--0)
+ R33low(bits 7--6)
+G32low(bits 5--4)
+R31low(bits 3--2)
+G30low(bits 1--0)
  

  
-- 
1.9.1

--
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 3/3] dma-buf: remove dma_buf_debugfs_create_file()

2016-06-20 Thread Mathias Krause

On 20 June 2016 at 15:31, Daniel Vetter  wrote:
> On Sun, Jun 19, 2016 at 02:31:31PM +0200, Mathias Krause wrote:
>> [...]
>> With no users left, we can remove dma_buf_debugfs_create_file().
>>
>> While at it, simplify the error handling in dma_buf_init_debugfs()
>> slightly.
>>
>> Signed-off-by: Mathias Krause 
>
> ah, here's the 2nd part, feel free to ignore my earlier comments. On the
> series:

Yeah, I've split the original patch into three to separate bug fixes
(patch 1+2) from enhancements (this patch) -- just in case anybody
wants to backport the fixes.

Also, this way this patch can easily be left out without missing the
fixes, in case new debugfs files below dma_buf/ are expected in the
near future. Those might want to make use of
dma_buf_debugfs_create_file(). But, as there haven't been any since
its introduction in commit
b89e35636bc7 ("dma-buf: Add debugfs support") in 2013, I guess, we can
just remove that function. ;)
>
> Reviewed-by: Daniel Vetter 

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

[PATCH v2 6/7] v4l: Add 14-bit raw bayer pixel format definitions

The formats added by this patch are:

V4L2_PIX_FMT_SBGGR14
V4L2_PIX_FMT_SGBRG14
V4L2_PIX_FMT_SGRBG14
V4L2_PIX_FMT_SRGGB14

Signed-off-by: Jouni Ukkonen 
Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/DocBook/media/v4l/pixfmt-srggb14.xml | 91 ++
 Documentation/DocBook/media/v4l/pixfmt.xml |  1 +
 include/uapi/linux/videodev2.h |  4 +
 3 files changed, 96 insertions(+)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb14.xml

diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml 
b/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml
new file mode 100644
index 000..3b9d2cc
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml
@@ -0,0 +1,91 @@
+
+  
+   V4L2_PIX_FMT_SRGGB14 ('RG14'),
+V4L2_PIX_FMT_SGRBG14 ('BA14'),
+V4L2_PIX_FMT_SGBRG14 ('GB14'),
+V4L2_PIX_FMT_SBGGR14 ('BG14')
+
+   
+  
+  
+   V4L2_PIX_FMT_SRGGB14
+   V4L2_PIX_FMT_SGRBG14
+   V4L2_PIX_FMT_SGBRG14
+   V4L2_PIX_FMT_SBGGR14
+   14-bit Bayer formats expanded to 16 bits
+  
+  
+   Description
+
+   These four pixel formats are raw sRGB / Bayer formats with
+14 bits per colour. Each colour component is stored in a 16-bit word, with 2
+unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
+and n/2 blue or red samples, with alternating red and blue rows. Bytes are
+stored in memory in little endian order. They are conventionally described
+as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
+formats:
+
+
+  V4L2_PIX_FMT_SBGGR14 4  4
+pixel image
+
+  
+   Byte Order.
+   Each cell is one byte, the 2 most significant bits in the high
+ bytes are 0.
+ 
+   
+ 
+ 
+   
+ start+0:
+ B00low
+ B00high
+ G01low
+ G01high
+ B02low
+ B02high
+ G03low
+ G03high
+   
+   
+ start+8:
+ G10low
+ G10high
+ R11low
+ R11high
+ G12low
+ G12high
+ R13low
+ R13high
+   
+   
+ start+16:
+ B20low
+ B20high
+ G21low
+ G21high
+ B22low
+ B22high
+ G23low
+ G23high
+   
+   
+ start+24:
+ G30low
+ G30high
+ R31low
+ R31high
+ G32low
+ G32high
+ R33low
+ R33high
+   
+ 
+   
+ 
+   
+  
+
+  
+
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 457337e..29e9d7c 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -1594,6 +1594,7 @@ access the palette, this must be done with ioctls of the 
Linux framebuffer API.<
 
 
 
+
   
 
   
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 7ace868..2c4b076 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -581,6 +581,10 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_SGBRG12P v4l2_fourcc('p', 'G', 'C', 'C')
 #define V4L2_PIX_FMT_SGRBG12P v4l2_fourcc('p', 'g', 'C', 'C')
 #define V4L2_PIX_FMT_SRGGB12P v4l2_fourcc('p', 'R', 'C', 'C')
+#define V4L2_PIX_FMT_SBGGR14 v4l2_fourcc('B', 'G', '1', '4') /* 14  BGBG.. 
GRGR.. */
+#define V4L2_PIX_FMT_SGBRG14 v4l2_fourcc('G', 'B', '1', '4') /* 14  GBGB.. 
RGRG.. */
+#define V4L2_PIX_FMT_SGRBG14 v4l2_fourcc('B', 'A', '1', '4') /* 14  GRGR.. 
BGBG.. */
+#define V4L2_PIX_FMT_SRGGB14 v4l2_fourcc('R', 'G', '1', '4') /* 14  RGRG.. 
GBGB.. */
 #define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16  BGBG.. 
GRGR.. */
 
 /* compressed formats */
-- 
1.9.1

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

[PATCH v2 5/7] media: Add 1X14 14-bit raw bayer media bus code definitions

From: Jouni Ukkonen 

The codes will be called:

MEDIA_BUS_FMT_SBGGR14_1X14
MEDIA_BUS_FMT_SGBRG14_1X14
MEDIA_BUS_FMT_SGRBG14_1X14
MEDIA_BUS_FMT_SRGGB14_1X14

Signed-off-by: Jouni Ukkonen 
Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/DocBook/media/v4l/subdev-formats.xml | 162 +++--
 include/uapi/linux/media-bus-format.h  |   6 +-
 2 files changed, 154 insertions(+), 14 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 199c84e..6d45dc8 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -1098,22 +1098,24 @@ see .
 
   
Bayer Formats
-   
+   
  
  
  
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
  
  

@@ -1126,6 +1128,8 @@ see .
  
  
  Bit
+ 13
+ 12
  11
  10
  9
@@ -1149,6 +1153,8 @@ see .
  -
  -
  -
+ -
+ -
  b7
  b6
  b5
@@ -1166,6 +1172,8 @@ see .
  -
  -
  -
+ -
+ -
  g7
  g6
  g5
@@ -1183,6 +1191,8 @@ see .
  -
  -
  -
+ -
+ -
  g7
  g6
  g5
@@ -1200,6 +1210,8 @@ see .
  -
  -
  -
+ -
+ -
  r7
  r6
  r5
@@ -1217,6 +1229,8 @@ see .
  -
  -
  -
+ -
+ -
  b7
  b6
  b5
@@ -1234,6 +1248,8 @@ see .
  -
  -
  -
+ -
+ -
  g7
  g6
  g5
@@ -1251,6 +1267,8 @@ see .
  -
  -
  -
+ -
+ -
  g7
  g6
  g5
@@ -1268,6 +1286,8 @@ see .
  -
  -
  -
+ -
+ -
  r7
  r6
  r5
@@ -1285,6 +1305,8 @@ see .
  -
  -
  -
+ -
+ -
  b7
  b6
  b5
@@ -1302,6 +1324,8 @@ see .
  -
  -
  -
+ -
+ -
  g7
  g6
  g5
@@ -1319,6 +1343,8 @@ see .
  -
  -
  -
+ -
+ -
  g7
  g6
  g5
@@ -1336,6 +1362,8 @@ see .
  -
  -
  -
+ -
+ -
  r7
  r6
  r5
@@ -1353,6 +1381,8 @@ see .
  -
  -
  -
+ -
+ -
  0
  0
  0
@@ -1370,6 +1400,8 @@ see .
  -
  -
  -
+ -
+ -
  b7
  b6
  b5
@@ -1387,6 +1419,8 @@ see .
  -
  -
  -
+ -
+ -
  b7
  b6
  b5
@@ -1404,6 +1438,8 @@ see .
  -
  -
  -
+ -
+ -
  0
  0
  0
@@ -1421,6 +1457,8 @@ see .
  -
  -
  -
+ -
+ -
  b9
  b8
  b7
@@ -1438,6 +1476,8 @@ see .
  -
  -
  -
+ -
+ -
  b1
  b0
  0
@@ -1455,6 +1495,8 @@ see .
  -
  -
  -
+ -
+ -
  b1
  b0
  0
@@ -1472,6 +1514,8 @@ see .
  -
  -
  -
+ -
+ -
  b9
  b8
  b7
@@ -1487,6 +1531,8 @@ see .
  
  -
  -
+ -
+ -
  b9
  b8
  b7
@@ -1504,6 +1550,8 @@ see .
  
  -
  -
+ -
+ -
  g9
  g8
  g7
@@ -1521,6 +1569,8 @@ see .
  
  -
  -
+

[PATCH v2 0/7] New raw bayer format definitions, fixes

Hi all,

These patches fix and add new raw bayer format definitions. 12-bit packed
V4L2 format definition is added as well as definitions of 14-bit media bus
codes as well as unpacked and packed V4L2 formats.

No driver uses them right now, yet they're common formats needed by newer
devices that use higher bit depths so adding them would make sense.

since v1:

- Fix issues Hans pointed out in his review,

- add one patch to fix similar issues in already defined 10-bit and 12-bit
  formats found in 14-bit format definitions.

The previous set with the review comments can be found here:



-- 
Kind regards,
Sakari

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

[PATCH v2 7/7] v4l: Add packed Bayer raw14 pixel formats

These formats are compressed 14-bit raw bayer formats with four different
pixel orders. They are similar to 10-bit variants. The formats added by
this patch are

V4L2_PIX_FMT_SBGGR14P
V4L2_PIX_FMT_SGBRG14P
V4L2_PIX_FMT_SGRBG14P
V4L2_PIX_FMT_SRGGB14P

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 .../DocBook/media/v4l/pixfmt-srggb14p.xml  | 118 +
 Documentation/DocBook/media/v4l/pixfmt.xml |   1 +
 include/uapi/linux/videodev2.h |   5 +
 3 files changed, 124 insertions(+)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb14p.xml

diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb14p.xml 
b/Documentation/DocBook/media/v4l/pixfmt-srggb14p.xml
new file mode 100644
index 000..97bdaee2
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb14p.xml
@@ -0,0 +1,118 @@
+
+  
+   V4L2_PIX_FMT_SRGGB14P ('pREE'),
+V4L2_PIX_FMT_SGRBG14P ('pgEE'),
+V4L2_PIX_FMT_SGBRG14P ('pGEE'),
+V4L2_PIX_FMT_SBGGR14P ('pBEE')
+
+   
+  
+  
+   V4L2_PIX_FMT_SRGGB14P
+   V4L2_PIX_FMT_SGRBG14P
+   V4L2_PIX_FMT_SGBRG14P
+   V4L2_PIX_FMT_SBGGR14P
+   14-bit packed Bayer formats
+  
+  
+   Description
+
+   These four pixel formats are packed raw sRGB / Bayer
+   formats with 14 bits per colour. Every four consecutive colour
+   components are packed into 7 bytes. Each of the first 4 bytes
+   contain the 8 high order bits of the pixels, and the fifth, sixth
+   and seventh bytes contains the six least significant bits of each
+   pixel, in the same order.
+
+   Each n-pixel row contains n/2 green samples and n/2 blue
+   or red samples, with alternating green-red and green-blue
+   rows. They are conventionally described as GRGR... BGBG...,
+   RGRG... GBGB..., etc. Below is an example of one of these
+   formats:
+
+
+  V4L2_PIX_FMT_SBGGR14P 4  4
+  pixel image
+
+  
+   Byte Order.
+   Each cell is one byte. The bits in subscript denote bits
+ of the sample. The bits of the cell byte can be found in
+ parentheses.
+
+ 
+   
+ 
+ 
+   
+ start+0:
+ B00 bits 13--8
+ G01 bits 13--8
+ B02 bits 13--8
+ G03 bits 13--8
+ G01 bits 1--0(bits 7--6)
+B00 bits 5--0(bits 5--0)
+ 
+ B02 bits 3--0(bits 7--4)
+G01 bits 5--2(bits 3--0)
+ 
+ G03 bits 5--0(bits 7--2)
+B02 bits 5--4(bits 1--0)
+ 
+   
+   
+ start+7:
+ G10 bits 13--8
+ R11 bits 13--8
+ G12 bits 13--8
+ R13 bits 13--8
+ R11 bits 1--0(bits 7--6)
+B10 bits 5--0(bits 5--0)
+ 
+ R12 bits 3--0(bits 7--4)
+G11 bits 5--2(bits 3--0)
+ 
+ R13 bits 5--0(bits 7--2)
+B12 bits 5--4(bits 1--0)
+ 
+   
+   
+ start+14:
+ B20 bits 13--8
+ G21 bits 13--8
+ B22 bits 13--8
+ G23 bits 13--8
+ G21 bits 1--0(bits 7--6)
+B20 bits 5--0(bits 5--0)
+ 
+ B22 bits 3--0(bits 7--4)
+G21 bits 5--2(bits 3--0)
+ 
+ G23 bits 5--0(bits 7--2)
+B22 bits 5--4(bits 1--0)
+ 
+   
+   
+ start+21:
+ G30 bits 13--8
+ R31 bits 13--8
+ G32 bits 13--8
+ R33 bits 13--8
+ R31 bits 1--0(bits 7--6)
+B30 bits 5--0(bits 5--0)
+ 
+ R32 bits 3--0(bits 7--4)
+G31 bits 5--2(bits 3--0)
+ 
+ R33 bits 5--0(bits 7--2)
+B32 bits 5--4(bits 1--0)
+ 
+   
+ 
+   
+ 
+   
+  
+
+  
+
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 29e9d7c..296a50a 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -1595,6 +1595,7 @@ access the palette, this must be done with ioctls of the 
Linux framebuffer API.<
 
 
 
+
   
 
   
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2c4b076..63d141e 100644
---

[PATCH v2 3/7] v4l: Clean up raw bayer pixel format definitions

- Explicitly state that the most significant n bits are zeroed on 10 and
  12 bpp formats.
- Remove extra comma from the last entry of the format list
- Add a missing colon before a list

Signed-off-by: Sakari Ailus 
---
 Documentation/DocBook/media/v4l/pixfmt-srggb10.xml  | 5 +++--
 Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml | 2 +-
 Documentation/DocBook/media/v4l/pixfmt-srggb12.xml  | 5 +++--
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml 
b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
index f34d03e..cd3f915 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
@@ -23,7 +23,7 @@ unused high bits filled with zeros. Each n-pixel row contains 
n/2 green samples
 and n/2 blue or red samples, with alternating red and blue rows. Bytes are
 stored in memory in little endian order. They are conventionally described
 as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
-formats
+formats:
 
 
   V4L2_PIX_FMT_SBGGR10 4  4
@@ -31,7 +31,8 @@ pixel image
 
   
Byte Order.
-   Each cell is one byte, high 6 bits in high bytes are 0.
+   Each cell is one byte, the 6 most significant bits in the high
+ bytes are 0.
  

  
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml 
b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
index 747822b..18bb722 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
@@ -3,7 +3,7 @@
V4L2_PIX_FMT_SRGGB10P ('pRAA'),
 V4L2_PIX_FMT_SGRBG10P ('pgAA'),
 V4L2_PIX_FMT_SGBRG10P ('pGAA'),
-V4L2_PIX_FMT_SBGGR10P ('pBAA'),
+V4L2_PIX_FMT_SBGGR10P ('pBAA')
 

   
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml 
b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
index 4394101..2d8efeb 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
@@ -23,7 +23,7 @@ unused high bits filled with zeros. Each n-pixel row contains 
n/2 green samples
 and n/2 blue or red samples, with alternating red and blue rows. Bytes are
 stored in memory in little endian order. They are conventionally described
 as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
-formats
+formats:
 
 
   V4L2_PIX_FMT_SBGGR12 4  4
@@ -31,7 +31,8 @@ pixel image
 
   
Byte Order.
-   Each cell is one byte, high 4 bits in high bytes are 0.
+   Each cell is one byte, the 4 most significant bits in the high
+ bytes are 0.
  

  
-- 
1.9.1

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

[PATCH v2 4/7] v4l: Add packed Bayer raw12 pixel formats

These formats are compressed 12-bit raw bayer formats with four different
pixel orders. They are similar to 10-bit variants. The formats added by
this patch are

V4L2_PIX_FMT_SBGGR12P
V4L2_PIX_FMT_SGBRG12P
V4L2_PIX_FMT_SGRBG12P
V4L2_PIX_FMT_SRGGB12P

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 .../DocBook/media/v4l/pixfmt-srggb12p.xml  | 103 +
 Documentation/DocBook/media/v4l/pixfmt.xml |   1 +
 include/uapi/linux/videodev2.h |   5 +
 3 files changed, 109 insertions(+)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml

diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml 
b/Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml
new file mode 100644
index 000..12f0ac1
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml
@@ -0,0 +1,103 @@
+
+  
+   V4L2_PIX_FMT_SRGGB12P ('pRCC'),
+V4L2_PIX_FMT_SGRBG12P ('pgCC'),
+V4L2_PIX_FMT_SGBRG12P ('pGCC'),
+V4L2_PIX_FMT_SBGGR12P ('pBCC')
+
+   
+  
+  
+   V4L2_PIX_FMT_SRGGB12P
+   V4L2_PIX_FMT_SGRBG12P
+   V4L2_PIX_FMT_SGBRG12P
+   V4L2_PIX_FMT_SBGGR12P
+   12-bit packed Bayer formats
+  
+  
+   Description
+
+   These four pixel formats are packed raw sRGB / Bayer
+   formats with 12 bits per colour. Every four consecutive colour
+   components are packed into 6 bytes. Each of the first 4 bytes
+   contain the 8 high order bits of the pixels, and the fifth and
+   sixth bytes contains the four least significants bits of each
+   pixel, in the same order.
+
+   Each n-pixel row contains n/2 green samples and n/2 blue
+   or red samples, with alternating green-red and green-blue
+   rows. They are conventionally described as GRGR... BGBG...,
+   RGRG... GBGB..., etc. Below is an example of one of these
+   formats:
+
+
+  V4L2_PIX_FMT_SBGGR12P 4  4
+  pixel image
+
+  
+   Byte Order.
+   Each cell is one byte.
+ 
+   
+ 
+ 
+   
+ start+0:
+ B00high
+ G01high
+ G01low(bits 7--4)
+B00low(bits 3--0)
+ 
+ B02high
+ G03high
+ G03low(bits 7--4)
+B02low(bits 3--0)
+ 
+   
+   
+ start+6:
+ G10high
+ R11high
+ R11low(bits 7--4)
+G10low(bits 3--0)
+ 
+ G12high
+ R13high
+ R13low(bits 7--4)
+G12low(bits 3--0)
+ 
+   
+   
+ start+12:
+ B20high
+ G21high
+ G21low(bits 7--4)
+B20low(bits 3--0)
+ 
+ B22high
+ G23high
+ G23low(bits 7--4)
+B22low(bits 3--0)
+ 
+   
+   
+ start+18:
+ G30high
+ R31high
+ R31low(bits 7--4)
+G30low(bits 3--0)
+ 
+ G32high
+ R33high
+ R33low(bits 7--4)
+G32low(bits 3--0)
+ 
+   
+ 
+   
+ 
+   
+  
+
+  
+
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 5a08aee..457337e 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -1593,6 +1593,7 @@ access the palette, this must be done with ioctls of the 
Linux framebuffer API.<
 
 
 
+
   
 
   
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 8f95191..7ace868 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -576,6 +576,11 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_SGBRG12 v4l2_fourcc('G', 'B', '1', '2') /* 12  GBGB.. 
RGRG.. */
 #define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12  GRGR.. 
BGBG.. */
 #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG.. 
GBGB.. */
+   /* 12bit raw bayer packed, 6 bytes for every 4 pixels */
+#define V4L2_PIX_FMT_SBGGR12P v4l2_fourcc('p', 'B', 'C', 'C')
+#define V4L2_PIX_FMT_SGBRG12P v4l2_fourcc('p', 'G', 'C', 'C')
+#define V4L2_PIX_FMT_SGRBG12P v4l2_fourcc('p', 'g', 'C', 'C')
+#define V4L2_PIX_FMT_SRGGB12P v4l2_fourcc('p', 'R', 'C', 'C')
 #define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16  BGBG.. 
GRGR.. */
 
 /* compressed formats

Re: [PATCH v4 8/9] Input: atmel_mxt_ts - add support for reference data

On 06/20/2016 06:18 PM, Nick Dyer wrote:
> On 20/06/2016 17:09, Hans Verkuil wrote:
>> On 06/17/2016 04:16 PM, Nick Dyer wrote:
>>> @@ -2325,11 +2344,20 @@ static int mxt_vidioc_querycap(struct file *file, 
>>> void *priv,
>>>  static int mxt_vidioc_enum_input(struct file *file, void *priv,
>>>struct v4l2_input *i)
>>>  {
>>> -   if (i->index > 0)
>>> +   if (i->index >= MXT_V4L_INPUT_MAX)
>>> return -EINVAL;
>>>  
>>> i->type = V4L2_INPUT_TYPE_TOUCH_SENSOR;
>>> -   strlcpy(i->name, "Mutual References", sizeof(i->name));
>>> +
>>> +   switch (i->index) {
>>> +   case MXT_V4L_INPUT_REFS:
>>> +   strlcpy(i->name, "Mutual References", sizeof(i->name));
>>> +   break;
>>> +   case MXT_V4L_INPUT_DELTAS:
>>> +   strlcpy(i->name, "Mutual Deltas", sizeof(i->name));
>>
>> I don't think this name is very clear. I have no idea how to interpret 
>> "Mutual"
>> in this context.
> 
> "Mutual" is a touch domain specific term, it means the delta value is for
> the capacitance between the horizontal and vertical lines at a particular
> "node" on the touchscreen matrix, see
> https://en.wikipedia.org/wiki/Touchscreen#Mutual_capacitance
> 
> I'll put in a comment.

As I mentioned in an earlier review, we need a v4l-touch interface description 
anyway.
I think it might be useful to describe some of these touch-specific terms there.
That way that could be a useful reference for end-users.

Nobody reads comments, but people do read the spec (well, I do).

Regards,

Hans

> 
>>
>>> +   break;
>>> +   }
>>> +
>>> return 0;
>>>  }
>>>  
>>> @@ -2337,12 +2365,16 @@ static int mxt_set_input(struct mxt_data *data, 
>>> unsigned int i)
>>>  {
>>> struct v4l2_pix_format *f = >dbg.format;
>>>  
>>> -   if (i > 0)
>>> +   if (i >= MXT_V4L_INPUT_MAX)
>>> return -EINVAL;
>>>  
>>> +   if (i == MXT_V4L_INPUT_DELTAS)
>>> +   f->pixelformat = V4L2_PIX_FMT_YS16;
>>> +   else
>>> +   f->pixelformat = V4L2_PIX_FMT_Y16;
>>
>> You probably need a V4L2_TOUCH_FMT_U16 or something for this as well. It 
>> certainly
>> needs to be documented.
> 
> OK, will change this.
> 
> --
> 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

[PATCH v2 2/7] v4l: Fix number of zeroed high order bits in 12-bit raw format defs

The number of high order bits in samples was documented to be 6 for 12-bit
data. This is clearly wrong, fix it.

Signed-off-by: Sakari Ailus 
---
 Documentation/DocBook/media/v4l/pixfmt-srggb12.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml 
b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
index 0c8e4ad..4394101 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
@@ -31,7 +31,7 @@ pixel image
 
   
Byte Order.
-   Each cell is one byte, high 6 bits in high bytes are 0.
+   Each cell is one byte, high 4 bits in high bytes are 0.
  

  
-- 
1.9.1

--
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 v4 9/9] Input: synaptics-rmi4 - add support for F54 diagnostics

On 06/17/2016 04:16 PM, Nick Dyer wrote:
> Function 54 implements access to various RMI4 diagnostic features.
> 
> This patch adds support for retrieving this data. It registers a V4L2
> device to output the data to user space.
> 
> Signed-off-by: Nick Dyer 
> ---
>  drivers/input/rmi4/Kconfig  |  11 +
>  drivers/input/rmi4/Makefile |   1 +
>  drivers/input/rmi4/rmi_bus.c|   3 +
>  drivers/input/rmi4/rmi_driver.h |   1 +
>  drivers/input/rmi4/rmi_f54.c| 743 
> 
>  5 files changed, 759 insertions(+)
>  create mode 100644 drivers/input/rmi4/rmi_f54.c
> 
> diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
> index f73df24..f3418b6 100644
> --- a/drivers/input/rmi4/Kconfig
> +++ b/drivers/input/rmi4/Kconfig
> @@ -61,3 +61,14 @@ config RMI4_F30
>  
> Function 30 provides GPIO and LED support for RMI4 devices. This
> includes support for buttons on TouchPads and ClickPads.
> +
> +config RMI4_F54
> + bool "RMI4 Function 54 (Analog diagnostics)"
> + depends on RMI4_CORE
> + depends on VIDEO_V4L2
> + select VIDEOBUF2_VMALLOC
> + help
> +   Say Y here if you want to add support for RMI4 function 54
> +
> +   Function 54 provides access to various diagnostic features in certain
> +   RMI4 touch sensors.
> diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
> index 95c00a7..0bafc85 100644
> --- a/drivers/input/rmi4/Makefile
> +++ b/drivers/input/rmi4/Makefile
> @@ -7,6 +7,7 @@ rmi_core-$(CONFIG_RMI4_2D_SENSOR) += rmi_2d_sensor.o
>  rmi_core-$(CONFIG_RMI4_F11) += rmi_f11.o
>  rmi_core-$(CONFIG_RMI4_F12) += rmi_f12.o
>  rmi_core-$(CONFIG_RMI4_F30) += rmi_f30.o
> +rmi_core-$(CONFIG_RMI4_F54) += rmi_f54.o
>  
>  # Transports
>  obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
> diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
> index b368b05..3aedc65 100644
> --- a/drivers/input/rmi4/rmi_bus.c
> +++ b/drivers/input/rmi4/rmi_bus.c
> @@ -315,6 +315,9 @@ static struct rmi_function_handler *fn_handlers[] = {
>  #ifdef CONFIG_RMI4_F30
>   _f30_handler,
>  #endif
> +#ifdef CONFIG_RMI4_F54
> + _f54_handler,
> +#endif
>  };
>  
>  static void __rmi_unregister_function_handlers(int start_idx)
> diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
> index 6e140fa..8dfbebe 100644
> --- a/drivers/input/rmi4/rmi_driver.h
> +++ b/drivers/input/rmi4/rmi_driver.h
> @@ -102,4 +102,5 @@ extern struct rmi_function_handler rmi_f01_handler;
>  extern struct rmi_function_handler rmi_f11_handler;
>  extern struct rmi_function_handler rmi_f12_handler;
>  extern struct rmi_function_handler rmi_f30_handler;
> +extern struct rmi_function_handler rmi_f54_handler;
>  #endif
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> new file mode 100644
> index 000..bd06788
> --- /dev/null
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -0,0 +1,743 @@
> +/*
> + * Copyright (c) 2012-2015 Synaptics Incorporated
> + *
> + * 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 "rmi_driver.h"
> +
> +#define F54_NAME "rmi4_f54"
> +
> +/* F54 data offsets */
> +#define F54_REPORT_DATA_OFFSET  3
> +#define F54_FIFO_OFFSET 1
> +#define F54_NUM_TX_OFFSET   1
> +#define F54_NUM_RX_OFFSET   0
> +
> +/* F54 commands */
> +#define F54_GET_REPORT  1
> +#define F54_FORCE_CAL   2
> +
> +/* Fixed sizes of reports */
> +#define F54_QUERY_LEN27
> +#define F54_FULL_RAW_CAP_MIN_MAX_SIZE   4
> +#define F54_HIGH_RESISTANCE_SIZE(rx, tx) \
> + (2 * ((rx) * (tx) + (rx) + (tx) + 3))
> +#define F54_MAX_REPORT_SIZE(rx, tx)  F54_HIGH_RESISTANCE_SIZE((rx), (tx))
> +
> +/* F54 capabilities */
> +#define F54_CAP_BASELINE (1 << 2)
> +#define F54_CAP_IMAGE8   (1 << 3)
> +#define F54_CAP_IMAGE16  (1 << 6)
> +
> +enum f54_report_type {
> + F54_REPORT_NONE = 0,
> + F54_8BIT_IMAGE = 1,
> + F54_16BIT_IMAGE = 2,
> + F54_RAW_16BIT_IMAGE = 3,
> + F54_HIGH_RESISTANCE = 4,
> + F54_TX_TO_TX_SHORT = 5,
> + F54_RX_TO_RX1 = 7,
> + F54_TRUE_BASELINE = 9,
> + F54_FULL_RAW_CAP_MIN_MAX = 13,
> + F54_RX_OPENS1 = 14,
> + F54_TX_OPEN = 15,
> + F54_TX_TO_GROUND = 16,
> + F54_RX_TO_RX2 = 17,
> + F54_RX_OPENS2 = 18,
> + F54_FULL_RAW_CAP = 19,
> + F54_FULL_RAW_CAP_RX_COUPLING_COMP = 20,
> + F54_MAX_REPORT_TYPE,
> +};
> +
> +struct f54_data {
> + struct rmi_function *fn;
> +
> + u8 qry[F54_QUERY_LEN];
> + u8 num_rx_electrodes;
> + u8 num_tx_electrodes;
> + u8 capabilities;
> + u16

Re: [PATCH v4 8/9] Input: atmel_mxt_ts - add support for reference data

2016-06-20 Thread Nick Dyer

On 20/06/2016 17:09, Hans Verkuil wrote:
> On 06/17/2016 04:16 PM, Nick Dyer wrote:
>> @@ -2325,11 +2344,20 @@ static int mxt_vidioc_querycap(struct file *file, 
>> void *priv,
>>  static int mxt_vidioc_enum_input(struct file *file, void *priv,
>> struct v4l2_input *i)
>>  {
>> -if (i->index > 0)
>> +if (i->index >= MXT_V4L_INPUT_MAX)
>>  return -EINVAL;
>>  
>>  i->type = V4L2_INPUT_TYPE_TOUCH_SENSOR;
>> -strlcpy(i->name, "Mutual References", sizeof(i->name));
>> +
>> +switch (i->index) {
>> +case MXT_V4L_INPUT_REFS:
>> +strlcpy(i->name, "Mutual References", sizeof(i->name));
>> +break;
>> +case MXT_V4L_INPUT_DELTAS:
>> +strlcpy(i->name, "Mutual Deltas", sizeof(i->name));
> 
> I don't think this name is very clear. I have no idea how to interpret 
> "Mutual"
> in this context.

"Mutual" is a touch domain specific term, it means the delta value is for
the capacitance between the horizontal and vertical lines at a particular
"node" on the touchscreen matrix, see
https://en.wikipedia.org/wiki/Touchscreen#Mutual_capacitance

I'll put in a comment.

> 
>> +break;
>> +}
>> +
>>  return 0;
>>  }
>>  
>> @@ -2337,12 +2365,16 @@ static int mxt_set_input(struct mxt_data *data, 
>> unsigned int i)
>>  {
>>  struct v4l2_pix_format *f = >dbg.format;
>>  
>> -if (i > 0)
>> +if (i >= MXT_V4L_INPUT_MAX)
>>  return -EINVAL;
>>  
>> +if (i == MXT_V4L_INPUT_DELTAS)
>> +f->pixelformat = V4L2_PIX_FMT_YS16;
>> +else
>> +f->pixelformat = V4L2_PIX_FMT_Y16;
> 
> You probably need a V4L2_TOUCH_FMT_U16 or something for this as well. It 
> certainly
> needs to be documented.

OK, will change this.

--
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 v4 8/9] Input: atmel_mxt_ts - add support for reference data

On 06/17/2016 04:16 PM, Nick Dyer wrote:
> There are different datatypes available from a maXTouch chip. Add
> support to retrieve reference data as well.
> 
> Signed-off-by: Nick Dyer 
> ---
>  drivers/input/touchscreen/atmel_mxt_ts.c | 58 
> 
>  1 file changed, 51 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
> b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 5281325d..bb01fb0 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -135,6 +135,7 @@ struct t9_range {
>  /* MXT_DEBUG_DIAGNOSTIC_T37 */
>  #define MXT_DIAGNOSTIC_PAGEUP0x01
>  #define MXT_DIAGNOSTIC_DELTAS0x10
> +#define MXT_DIAGNOSTIC_REFS  0x11
>  #define MXT_DIAGNOSTIC_SIZE  128
>  
>  #define MXT_FAMILY_1386  160
> @@ -249,6 +250,12 @@ struct mxt_dbg {
>   int input;
>  };
>  
> +enum v4l_dbg_inputs {
> + MXT_V4L_INPUT_DELTAS,
> + MXT_V4L_INPUT_REFS,
> + MXT_V4L_INPUT_MAX,
> +};
> +
>  static const struct v4l2_file_operations mxt_video_fops = {
>   .owner = THIS_MODULE,
>   .open = v4l2_fh_open,
> @@ -2273,6 +2280,7 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
>   struct mxt_data *data = vb2_get_drv_priv(vb->vb2_queue);
>   u16 *ptr;
>   int ret;
> + u8 mode;
>  
>   ptr = vb2_plane_vaddr(vb, 0);
>   if (!ptr) {
> @@ -2280,7 +2288,18 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
>   goto fault;
>   }
>  
> - ret = mxt_read_diagnostic_debug(data, MXT_DIAGNOSTIC_DELTAS, ptr);
> + switch (data->dbg.input) {
> + case MXT_V4L_INPUT_DELTAS:
> + default:
> + mode = MXT_DIAGNOSTIC_DELTAS;
> + break;
> +
> + case MXT_V4L_INPUT_REFS:
> + mode = MXT_DIAGNOSTIC_REFS;
> + break;
> + }
> +
> + ret = mxt_read_diagnostic_debug(data, mode, ptr);
>   if (ret)
>   goto fault;
>  
> @@ -2325,11 +2344,20 @@ static int mxt_vidioc_querycap(struct file *file, 
> void *priv,
>  static int mxt_vidioc_enum_input(struct file *file, void *priv,
>  struct v4l2_input *i)
>  {
> - if (i->index > 0)
> + if (i->index >= MXT_V4L_INPUT_MAX)
>   return -EINVAL;
>  
>   i->type = V4L2_INPUT_TYPE_TOUCH_SENSOR;
> - strlcpy(i->name, "Mutual References", sizeof(i->name));
> +
> + switch (i->index) {
> + case MXT_V4L_INPUT_REFS:
> + strlcpy(i->name, "Mutual References", sizeof(i->name));
> + break;
> + case MXT_V4L_INPUT_DELTAS:
> + strlcpy(i->name, "Mutual Deltas", sizeof(i->name));

I don't think this name is very clear. I have no idea how to interpret "Mutual"
in this context.

> + break;
> + }
> +
>   return 0;
>  }
>  
> @@ -2337,12 +2365,16 @@ static int mxt_set_input(struct mxt_data *data, 
> unsigned int i)
>  {
>   struct v4l2_pix_format *f = >dbg.format;
>  
> - if (i > 0)
> + if (i >= MXT_V4L_INPUT_MAX)
>   return -EINVAL;
>  
> + if (i == MXT_V4L_INPUT_DELTAS)
> + f->pixelformat = V4L2_PIX_FMT_YS16;
> + else
> + f->pixelformat = V4L2_PIX_FMT_Y16;

You probably need a V4L2_TOUCH_FMT_U16 or something for this as well. It 
certainly
needs to be documented.

Regards,

Hans

> +
>   f->width = data->xy_switch ? data->ysize : data->xsize;
>   f->height = data->xy_switch ? data->xsize : data->ysize;
> - f->pixelformat = V4L2_PIX_FMT_YS16;
>   f->field = V4L2_FIELD_NONE;
>   f->colorspace = V4L2_COLORSPACE_RAW;
>   f->bytesperline = f->width * sizeof(u16);
> @@ -2380,10 +2412,22 @@ static int mxt_vidioc_fmt(struct file *file, void 
> *priv, struct v4l2_format *f)
>  static int mxt_vidioc_enum_fmt(struct file *file, void *priv,
>struct v4l2_fmtdesc *fmt)
>  {
> - if (fmt->index > 0 || fmt->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + if (fmt->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + return -EINVAL;
> +
> + switch (fmt->index) {
> + case 0:
> + fmt->pixelformat = V4L2_PIX_FMT_Y16;
> + break;
> +
> + case 1:
> + fmt->pixelformat = V4L2_PIX_FMT_YS16;
> + break;
> +
> + default:
>   return -EINVAL;
> + }
>  
> - fmt->pixelformat = V4L2_PIX_FMT_YS16;
>   return 0;
>  }
>  
> 
--
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 5/6] v4l: Add 14-bit raw bayer pixel format definitions

On 06/20/2016 06:03 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> Hans Verkuil wrote:
>> On 05/27/2016 02:44 PM, Sakari Ailus wrote:
>>> The formats added by this patch are:
>>>
>>> V4L2_PIX_FMT_SBGGR14
>>> V4L2_PIX_FMT_SGBRG14
>>> V4L2_PIX_FMT_SGRBG14
>>> V4L2_PIX_FMT_SRGGB14
>>>
>>> Signed-off-by: Jouni Ukkonen 
>>> Signed-off-by: Sakari Ailus 
>>> ---
>>>  Documentation/DocBook/media/v4l/pixfmt-srggb14.xml | 90 
>>> ++
>>>  Documentation/DocBook/media/v4l/pixfmt.xml |  1 +
>>>  include/uapi/linux/videodev2.h |  4 +
>>>  3 files changed, 95 insertions(+)
>>>  create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb14.xml
>>>
>>> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml 
>>> b/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml
>>> new file mode 100644
>>> index 000..7e82d7e
>>> --- /dev/null
>>> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml
>>> @@ -0,0 +1,90 @@
>>> +
>>> +  
>>> +   V4L2_PIX_FMT_SRGGB14 ('RG14'),
>>> +V4L2_PIX_FMT_SGRBG14 ('BA14'),
>>> +V4L2_PIX_FMT_SGBRG14 ('GB14'),
>>> +V4L2_PIX_FMT_SBGGR14 ('BG14'),
>>
>> Same comma problem.
> 
> Fixed.
> 
>>
>>> +
>>> +   
>>> +  
>>> +  
>>> +   >> id="V4L2-PIX-FMT-SRGGB14">V4L2_PIX_FMT_SRGGB14
>>> +   >> id="V4L2-PIX-FMT-SGRBG14">V4L2_PIX_FMT_SGRBG14
>>> +   >> id="V4L2-PIX-FMT-SGBRG14">V4L2_PIX_FMT_SGBRG14
>>> +   >> id="V4L2-PIX-FMT-SBGGR14">V4L2_PIX_FMT_SBGGR14
>>> +   14-bit Bayer formats expanded to 16 bits
>>> +  
>>> +  
>>> +   Description
>>> +
>>> +   These four pixel formats are raw sRGB / Bayer formats with
>>> +14 bits per colour. Each colour component is stored in a 16-bit word, with 
>>> 2
>>> +unused high bits filled with zeros. Each n-pixel row contains n/2 green 
>>> samples
>>> +and n/2 blue or red samples, with alternating red and blue rows. Bytes are
>>> +stored in memory in little endian order. They are conventionally described
>>> +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of 
>>> these
>>> +formats
>>
>> s/formats/formats:/
> 
> Fixed.
> 
>>> +
>>> +
>>> +  V4L2_PIX_FMT_SBGGR14 4  4
>>> +pixel image
>>> +
>>> +  
>>> +   Byte Order.
>>> +   Each cell is one byte, high 2 bits in high bytes are 0.
>>
>> s/high 2/the high 2/
> 
> After re-reading the patch, I changed this to "Each cell is one byte,
> the 2 most significant bits in the high bytes are 0".

That is indeed better, although I would also say "two most" instead of "2 most".
It's slightly weird to have "one byte" followed by "2 most". Could be me, 
though.

Regards,

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

Re: [PATCH 5/6] v4l: Add 14-bit raw bayer pixel format definitions

Hi Hans,

Hans Verkuil wrote:
> On 05/27/2016 02:44 PM, Sakari Ailus wrote:
>> The formats added by this patch are:
>>
>>  V4L2_PIX_FMT_SBGGR14
>>  V4L2_PIX_FMT_SGBRG14
>>  V4L2_PIX_FMT_SGRBG14
>>  V4L2_PIX_FMT_SRGGB14
>>
>> Signed-off-by: Jouni Ukkonen 
>> Signed-off-by: Sakari Ailus 
>> ---
>>  Documentation/DocBook/media/v4l/pixfmt-srggb14.xml | 90 
>> ++
>>  Documentation/DocBook/media/v4l/pixfmt.xml |  1 +
>>  include/uapi/linux/videodev2.h |  4 +
>>  3 files changed, 95 insertions(+)
>>  create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb14.xml
>>
>> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml 
>> b/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml
>> new file mode 100644
>> index 000..7e82d7e
>> --- /dev/null
>> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml
>> @@ -0,0 +1,90 @@
>> +
>> +  
>> +V4L2_PIX_FMT_SRGGB14 ('RG14'),
>> + V4L2_PIX_FMT_SGRBG14 ('BA14'),
>> + V4L2_PIX_FMT_SGBRG14 ('GB14'),
>> + V4L2_PIX_FMT_SBGGR14 ('BG14'),
> 
> Same comma problem.

Fixed.

> 
>> + 
>> +
>> +  
>> +  
>> +> id="V4L2-PIX-FMT-SRGGB14">V4L2_PIX_FMT_SRGGB14
>> +> id="V4L2-PIX-FMT-SGRBG14">V4L2_PIX_FMT_SGRBG14
>> +> id="V4L2-PIX-FMT-SGBRG14">V4L2_PIX_FMT_SGBRG14
>> +> id="V4L2-PIX-FMT-SBGGR14">V4L2_PIX_FMT_SBGGR14
>> +14-bit Bayer formats expanded to 16 bits
>> +  
>> +  
>> +Description
>> +
>> +These four pixel formats are raw sRGB / Bayer formats with
>> +14 bits per colour. Each colour component is stored in a 16-bit word, with 2
>> +unused high bits filled with zeros. Each n-pixel row contains n/2 green 
>> samples
>> +and n/2 blue or red samples, with alternating red and blue rows. Bytes are
>> +stored in memory in little endian order. They are conventionally described
>> +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of 
>> these
>> +formats
> 
> s/formats/formats:/

Fixed.

>> +
>> +
>> +  V4L2_PIX_FMT_SBGGR14 4  4
>> +pixel image
>> +
>> +  
>> +Byte Order.
>> +Each cell is one byte, high 2 bits in high bytes are 0.
> 
> s/high 2/the high 2/

After re-reading the patch, I changed this to "Each cell is one byte,
the 2 most significant bits in the high bytes are 0".

> 
>> +  
>> +
>> +  
>> +  
>> +
>> +  start+0:
>> +  B00low
>> +  B00high
>> +  G01low
>> +  G01high
>> +  B02low
>> +  B02high
>> +  G03low
>> +  G03high
>> +
>> +
>> +  start+8:
>> +  G10low
>> +  G10high
>> +  R11low
>> +  R11high
>> +  G12low
>> +  G12high
>> +  R13low
>> +  R13high
>> +
>> +
>> +  start+16:
>> +  B20low
>> +  B20high
>> +  G21low
>> +  G21high
>> +  B22low
>> +  B22high
>> +  G23low
>> +  G23high
>> +
>> +
>> +  start+24:
>> +  G30low
>> +  G30high
>> +  R31low
>> +  R31high
>> +  G32low
>> +  G32high
>> +  R33low
>> +  R33high
>> +
>> +  
>> +
>> +  
>> +
>> +  
>> +
>> +  
>> +
>> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
>> b/Documentation/DocBook/media/v4l/pixfmt.xml
>> index 457337e..29e9d7c 100644
>> --- a/Documentation/DocBook/media/v4l/pixfmt.xml
>> +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
>> @@ -1594,6 +1594,7 @@ access the palette, this must be done with ioctls of 
>> the Linux framebuffer API.<
>>  
>>  
>>  
>> +
>>
>>  
>>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 7ace868..2c4b076 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -581,6 +581,10 @@ struct v4l2_pix_format {
>>  #define V4L2_PIX_FMT_SGBRG12P v4l2_fourcc('p', 'G', 'C', 'C')
>>  #define V4L2_PIX_FMT_SGRBG12P v4l2_fourcc('p', 'g', 'C', 'C')
>>  #define V4L2_PIX_FMT_SRGGB12P v4l2_fourcc('p', 'R', 'C', 'C')
>> +#define V4L2_PIX_FMT_SBGGR14 v4l2_fourcc('B', 'G', '1', '4') /* 14  BGBG.. 
>> GRGR.. */
>> +#define V4L2_PIX_FMT_SGBRG14 v4l2_fourcc('G', 'B', '1', '4') /* 14  GBGB.. 
>> RGRG.. */
>> +#define V4L2_PIX_FMT_SGRBG14 v4l2_fourcc('B', 'A', '1', '4') /* 14  GRGR.. 
>> BGBG.. */
>> +#define V4L2_PIX_FMT_SRGGB14 v4l2_fourcc('R', 'G', '1', '4') /* 14  RGRG.. 
>> GBGB.. */
>>  #define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16  BGBG.. 
>> GRGR.. */
>>  
>>  /* compressed formats */
>>
> 
> Regards,
> 
>   Hans
> 

-- 
Kind regards,

Sakari

[PATCH] [media] staging: davinci_vpfe: fix W=1 build warnings

2016-06-20 Thread Arnd Bergmann

When building with "make W=1", we get multiple harmless build warnings
for the vpfe driver:

drivers/staging/media/davinci_vpfe/dm365_resizer.c:241:1: error: 'static' is 
not at beginning of declaration [-Werror=old-style-declaration]
drivers/staging/media/davinci_vpfe/dm365_resizer.c: In function 
'resizer_set_defualt_configuration':
drivers/staging/media/davinci_vpfe/dm365_resizer.c:831:16: error: initialized 
field overwritten [-Werror=override-init]
drivers/staging/media/davinci_vpfe/dm365_resizer.c:831:16: note: (near 
initialization for 'rsz_default_config.rsz_rsc_param[0].h_typ_c')
drivers/staging/media/davinci_vpfe/dm365_resizer.c:849:16: error: initialized 
field overwritten [-Werror=override-init]
drivers/staging/media/davinci_vpfe/dm365_resizer.c:849:16: note: (near 
initialization for 'rsz_default_config.rsz_rsc_param[1].h_typ_c')

All of them are trivial to fix without changing the behavior of the
driver, as "static const" is interpreted the same as "const static",
and VPFE_RSZ_INTP_CUBIC is defined as zero, so the initializations
are not really needed.

Signed-off-by: Arnd Bergmann 
---
 drivers/staging/media/davinci_vpfe/dm365_resizer.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.c 
b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
index 3cd56cc132c7..567f995fd0f9 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
@@ -237,9 +237,8 @@ resizer_calculate_resize_ratios(struct vpfe_resizer_device 
*resizer, int index)
((informat->width) * 256) / (outformat->width);
 }
 
-void
-static resizer_enable_422_420_conversion(struct resizer_params *param,
-int index, bool en)
+static void resizer_enable_422_420_conversion(struct resizer_params *param,
+ int index, bool en)
 {
param->rsz_rsc_param[index].cen = en;
param->rsz_rsc_param[index].yen = en;
@@ -825,7 +824,7 @@ resizer_set_defualt_configuration(struct 
vpfe_resizer_device *resizer)
.o_hsz = WIDTH_O - 1,
.v_dif = 256,
.v_typ_y = VPFE_RSZ_INTP_CUBIC,
-   .h_typ_c = VPFE_RSZ_INTP_CUBIC,
+   .v_typ_c = VPFE_RSZ_INTP_CUBIC,
.h_dif = 256,
.h_typ_y = VPFE_RSZ_INTP_CUBIC,
.h_typ_c = VPFE_RSZ_INTP_CUBIC,
@@ -843,7 +842,7 @@ resizer_set_defualt_configuration(struct 
vpfe_resizer_device *resizer)
.o_hsz = WIDTH_O - 1,
.v_dif = 256,
.v_typ_y = VPFE_RSZ_INTP_CUBIC,
-   .h_typ_c = VPFE_RSZ_INTP_CUBIC,
+   .v_typ_c = VPFE_RSZ_INTP_CUBIC,
.h_dif = 256,
.h_typ_y = VPFE_RSZ_INTP_CUBIC,
.h_typ_c = VPFE_RSZ_INTP_CUBIC,
-- 
2.9.0

--
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 v4] [media] omap3isp: support 64-bit version of omap3isp_stat_data

2016-06-20 Thread Arnd Bergmann

C libraries with 64-bit time_t use an incompatible format for
struct omap3isp_stat_data. This changes the kernel code to
support either version, by moving over the normal handling
to the 64-bit variant, and adding compatiblity code to handle
the old binary format with the existing ioctl command code.

Fortunately, the command code includes the size of the structure,
so the difference gets handled automatically.

Signed-off-by: Arnd Bergmann 
---
This patch was originally part of a longer series, along with other patches
that we still have to rewrite for the generic ioctl interface, but the
OMAP specific ioctl commands are completely independent of that, so I think
we can just merge this version for 4.8.

in v4, I'm fixing a build regression that was introduced v3, which
separated this patch from the v4l_timeval type that I had in the
earlier versions.
---
 drivers/media/platform/omap3isp/isph3a_aewb.c |  2 ++
 drivers/media/platform/omap3isp/isph3a_af.c   |  2 ++
 drivers/media/platform/omap3isp/isphist.c |  2 ++
 drivers/media/platform/omap3isp/ispstat.c | 18 +-
 drivers/media/platform/omap3isp/ispstat.h |  2 ++
 include/uapi/linux/omap3isp.h | 22 ++
 6 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/omap3isp/isph3a_aewb.c 
b/drivers/media/platform/omap3isp/isph3a_aewb.c
index ccaf92f39236..2d567725608f 100644
--- a/drivers/media/platform/omap3isp/isph3a_aewb.c
+++ b/drivers/media/platform/omap3isp/isph3a_aewb.c
@@ -250,6 +250,8 @@ static long h3a_aewb_ioctl(struct v4l2_subdev *sd, unsigned 
int cmd, void *arg)
return omap3isp_stat_config(stat, arg);
case VIDIOC_OMAP3ISP_STAT_REQ:
return omap3isp_stat_request_statistics(stat, arg);
+   case VIDIOC_OMAP3ISP_STAT_REQ_TIME32:
+   return omap3isp_stat_request_statistics_time32(stat, arg);
case VIDIOC_OMAP3ISP_STAT_EN: {
unsigned long *en = arg;
return omap3isp_stat_enable(stat, !!*en);
diff --git a/drivers/media/platform/omap3isp/isph3a_af.c 
b/drivers/media/platform/omap3isp/isph3a_af.c
index 92937f7eecef..2ac02371318b 100644
--- a/drivers/media/platform/omap3isp/isph3a_af.c
+++ b/drivers/media/platform/omap3isp/isph3a_af.c
@@ -314,6 +314,8 @@ static long h3a_af_ioctl(struct v4l2_subdev *sd, unsigned 
int cmd, void *arg)
return omap3isp_stat_config(stat, arg);
case VIDIOC_OMAP3ISP_STAT_REQ:
return omap3isp_stat_request_statistics(stat, arg);
+   case VIDIOC_OMAP3ISP_STAT_REQ_TIME32:
+   return omap3isp_stat_request_statistics_time32(stat, arg);
case VIDIOC_OMAP3ISP_STAT_EN: {
int *en = arg;
return omap3isp_stat_enable(stat, !!*en);
diff --git a/drivers/media/platform/omap3isp/isphist.c 
b/drivers/media/platform/omap3isp/isphist.c
index 7138b043a4aa..669b97b079ee 100644
--- a/drivers/media/platform/omap3isp/isphist.c
+++ b/drivers/media/platform/omap3isp/isphist.c
@@ -436,6 +436,8 @@ static long hist_ioctl(struct v4l2_subdev *sd, unsigned int 
cmd, void *arg)
return omap3isp_stat_config(stat, arg);
case VIDIOC_OMAP3ISP_STAT_REQ:
return omap3isp_stat_request_statistics(stat, arg);
+   case VIDIOC_OMAP3ISP_STAT_REQ_TIME32:
+   return omap3isp_stat_request_statistics_time32(stat, arg);
case VIDIOC_OMAP3ISP_STAT_EN: {
int *en = arg;
return omap3isp_stat_enable(stat, !!*en);
diff --git a/drivers/media/platform/omap3isp/ispstat.c 
b/drivers/media/platform/omap3isp/ispstat.c
index 1b9217d3b1b6..481604e4ec52 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -496,7 +496,8 @@ int omap3isp_stat_request_statistics(struct ispstat *stat,
return PTR_ERR(buf);
}
 
-   data->ts = buf->ts;
+   data->ts.tv_sec = buf->ts.tv_sec;
+   data->ts.tv_usec = buf->ts.tv_usec;
data->config_counter = buf->config_counter;
data->frame_number = buf->frame_number;
data->buf_size = buf->buf_size;
@@ -508,6 +509,21 @@ int omap3isp_stat_request_statistics(struct ispstat *stat,
return 0;
 }
 
+int omap3isp_stat_request_statistics_time32(struct ispstat *stat,
+   struct omap3isp_stat_data_time32 *data)
+{
+   struct omap3isp_stat_data data64;
+   int ret;
+
+   ret = omap3isp_stat_request_statistics(stat, );
+
+   data->ts.tv_sec = data64.ts.tv_sec;
+   data->ts.tv_usec = data64.ts.tv_usec;
+   memcpy(>buf, , sizeof(*data) - sizeof(data->ts));
+
+   return ret;
+}
+
 /*
  * omap3isp_stat_config - Receives new statistic engine configuration.
  * @new_conf: Pointer to config structure.
diff --git a/drivers/media/platform/omap3isp/ispstat.h 
b/drivers/media/platform/omap3isp/ispstat.h
index 6d9b0244f320..0afa89de09de

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

2016-06-20 Thread Richard Cochran

On Mon, Jun 20, 2016 at 02:31:48PM +0200, Richard Cochran wrote:
> Where is this "audio_time" program of which you speak?

Never mind, found it in alsa-lib.

I still would appreciate an answer to my other questions, though...
 
Thanks,
Richard
--
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 3/6] v4l: Add packed Bayer raw12 pixel formats

Hi Hans,

Thanks for the review!

Hans Verkuil wrote:
> On 05/27/2016 02:44 PM, Sakari Ailus wrote:
>> These formats are compressed 12-bit raw bayer formats with four different
>> pixel orders. They are similar to 10-bit variants. The formats added by
>> this patch are
>>
>>  V4L2_PIX_FMT_SBGGR12P
>>  V4L2_PIX_FMT_SGBRG12P
>>  V4L2_PIX_FMT_SGRBG12P
>>  V4L2_PIX_FMT_SRGGB12P
>>
>> Signed-off-by: Sakari Ailus 
>> ---
>>  .../DocBook/media/v4l/pixfmt-srggb12p.xml  | 103 
>> +
>>  Documentation/DocBook/media/v4l/pixfmt.xml |   1 +
>>  include/uapi/linux/videodev2.h |   5 +
>>  3 files changed, 109 insertions(+)
>>  create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml
>>
>> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml 
>> b/Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml
>> new file mode 100644
>> index 000..affa366
>> --- /dev/null
>> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml
>> @@ -0,0 +1,103 @@
>> +
>> +  
>> +V4L2_PIX_FMT_SRGGB12P ('pRCC'),
>> + V4L2_PIX_FMT_SGRBG12P ('pgCC'),
>> + V4L2_PIX_FMT_SGBRG12P ('pGCC'),
>> + V4L2_PIX_FMT_SBGGR12P ('pBCC'),
> 
> Nitpick: the last comma should be removed otherwise the title would end with 
> it.
> 
> Looks good otherwise.
> 
> With the comma removed:
> 
> Acked-by: Hans Verkuil 

Indeed. Looks like this comes from the 10-bit definitions. I'll fix that
one as well.

-- 
Sakari Ailus
sakari.ai...@linux.intel.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 1/6] v4l: Correct the ordering of LSBs of the 10-bit raw packed formats

Hi Hans,

Hans Verkuil wrote:
> On 05/27/2016 02:44 PM, Sakari Ailus wrote:
>> The 10-bit packed raw bayer format documented that the data of the first
>> pixel of a four-pixel group was found in the first byte and the two
>> highest bits of the fifth byte. This was not entirely correct. The two
>> bits in the fifth byte are the two lowest bits. The second pixel occupies
>> the second byte and third and fourth least significant bits and so on.
> 
> This is used by the uvc driver. Has this been verified against a UVC webcam
> that supports this format? Laurent, do you have such a device?

I bet Laurent hasn't got one. Guennadi, could you comment on this?

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.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 6/6] v4l: Add packed Bayer raw14 pixel formats

On 05/27/2016 02:44 PM, Sakari Ailus wrote:
> These formats are compressed 14-bit raw bayer formats with four different
> pixel orders. They are similar to 10-bit variants. The formats added by
> this patch are
> 
>   V4L2_PIX_FMT_SBGGR14P
>   V4L2_PIX_FMT_SGBRG14P
>   V4L2_PIX_FMT_SGRBG14P
>   V4L2_PIX_FMT_SRGGB14P
> 
> Signed-off-by: Sakari Ailus 
> ---
>  .../DocBook/media/v4l/pixfmt-srggb14p.xml  | 118 
> +
>  Documentation/DocBook/media/v4l/pixfmt.xml |   1 +
>  include/uapi/linux/videodev2.h |   5 +
>  3 files changed, 124 insertions(+)
>  create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb14p.xml
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb14p.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-srggb14p.xml
> new file mode 100644
> index 000..ecb06ef
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb14p.xml
> @@ -0,0 +1,118 @@
> +
> +  
> + V4L2_PIX_FMT_SRGGB14P ('pREE'),
> +  V4L2_PIX_FMT_SGRBG14P ('pgEE'),
> +  V4L2_PIX_FMT_SGBRG14P ('pGEE'),
> +  V4L2_PIX_FMT_SBGGR14P ('pBEE'),

Again comma too many.

> +  
> + 
> +  
> +  
> +  id="V4L2-PIX-FMT-SRGGB14P">V4L2_PIX_FMT_SRGGB14P
> +  id="V4L2-PIX-FMT-SGRBG14P">V4L2_PIX_FMT_SGRBG14P
> +  id="V4L2-PIX-FMT-SGBRG14P">V4L2_PIX_FMT_SGBRG14P
> +  id="V4L2-PIX-FMT-SBGGR14P">V4L2_PIX_FMT_SBGGR14P
> + 14-bit packed Bayer formats
> +  
> +  
> + Description
> +
> + These four pixel formats are packed raw sRGB / Bayer
> + formats with 14 bits per colour. Every four consecutive colour
> + components are packed into 7 bytes. Each of the first 4 bytes
> + contain the 8 high order bits of the pixels, and the fifth, sixth
> + and seventh bytes contains the six least significants bits of each

s/significants/significant/

After fixing this:

Acked-by: Hans Verkuil 

Regards,

Hans

> + pixel, in the same order.
> +
> + Each n-pixel row contains n/2 green samples and n/2 blue
> + or red samples, with alternating green-red and green-blue
> + rows. They are conventionally described as GRGR... BGBG...,
> + RGRG... GBGB..., etc. Below is an example of one of these
> + formats:
> +
> +
> +  V4L2_PIX_FMT_SBGGR14P 4  4
> +  pixel image
> +
> +  
> + Byte Order.
> + Each cell is one byte. The bits in subscript denote bits
> +   of the sample. The bits of the cell byte can be found in
> +   parentheses.
> +
> +   
> + 
> +   
> +   
> + 
> +   start+0:
> +   B00 bits 13--8
> +   G01 bits 13--8
> +   B02 bits 13--8
> +   G03 bits 13--8
> +   G01 bits 1--0(bits 7--6)
> +  B00 bits 5--0(bits 5--0)
> +   
> +   B02 bits 3--0(bits 7--4)
> +  G01 bits 5--2(bits 3--0)
> +   
> +   G03 bits 5--0(bits 7--2)
> +  B02 bits 5--4(bits 1--0)
> +   
> + 
> + 
> +   start+7:
> +   G10 bits 13--8
> +   R11 bits 13--8
> +   G12 bits 13--8
> +   R13 bits 13--8
> +   R11 bits 1--0(bits 7--6)
> +  B10 bits 5--0(bits 5--0)
> +   
> +   R12 bits 3--0(bits 7--4)
> +  G11 bits 5--2(bits 3--0)
> +   
> +   R13 bits 5--0(bits 7--2)
> +  B12 bits 5--4(bits 1--0)
> +   
> + 
> + 
> +   start+14:
> +   B20 bits 13--8
> +   G21 bits 13--8
> +   B22 bits 13--8
> +   G23 bits 13--8
> +   G21 bits 1--0(bits 7--6)
> +  B20 bits 5--0(bits 5--0)
> +   
> +   B22 bits 3--0(bits 7--4)
> +  G21 bits 5--2(bits 3--0)
> +   
> +   G23 bits 5--0(bits 7--2)
> +  B22 bits 5--4(bits 1--0)
> +   
> + 
> + 
> +   start+21:
> +   G30 bits 13--8
> +   R31 bits 13--8
> +   G32 bits 13--8
> +   R33 bits 13--8
> +   R31 bits 1--0(bits 7--6)
> +  B30 bits 5--0(bits 5--0)
> +   
> +   R32 bits 3--0(bits 7--4)
> +  G31 bits 5--2(bits 3--0)
> +   
> +   R33 bits 5--0(bits 7--2)
> +  B32 bits 5--4(bits 1--0)
> +   
> + 
> +   
> + 
> +   
> + 
> +  
> +
> +  
> +
> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
> b/Documentation/DocBook/media/v4l/pixfmt.xml
> index 29e9d7c..296a50a 100644
>

Re: [PATCH 4/6] media: Add 1X14 14-bit raw bayer media bus code definitions

On 05/27/2016 02:44 PM, Sakari Ailus wrote:
> From: Jouni Ukkonen 
> 
> The codes will be called:
> 
>   MEDIA_BUS_FMT_SBGGR14_1X14
>   MEDIA_BUS_FMT_SGBRG14_1X14
>   MEDIA_BUS_FMT_SGRBG14_1X14
>   MEDIA_BUS_FMT_SRGGB14_1X14
> 
> Signed-off-by: Jouni Ukkonen 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Hans

> ---
>  Documentation/DocBook/media/v4l/subdev-formats.xml | 162 
> +++--
>  include/uapi/linux/media-bus-format.h  |   6 +-
>  2 files changed, 154 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
> b/Documentation/DocBook/media/v4l/subdev-formats.xml
> index 199c84e..6d45dc8 100644
> --- a/Documentation/DocBook/media/v4l/subdev-formats.xml
> +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
> @@ -1098,22 +1098,24 @@ see .
>  
>
>   Bayer Formats
> - 
> + 
> 
> 
> 
> -   
> -   
> -   
> -   
> -   
> -   
> -   
> -   
> -   
> -   
> -   
> -   
> +   
> +   
> +   
> +   
> +   
> +   
> +   
> +   
> +   
> +   
> +   
> +   
> +   
> +   
> 
> 
>   
> @@ -1126,6 +1128,8 @@ see .
> 
> 
> Bit
> +   13
> +   12
> 11
> 10
> 9
> @@ -1149,6 +1153,8 @@ see .
> -
> -
> -
> +   -
> +   -
> b7
> b6
> b5
> @@ -1166,6 +1172,8 @@ see .
> -
> -
> -
> +   -
> +   -
> g7
> g6
> g5
> @@ -1183,6 +1191,8 @@ see .
> -
> -
> -
> +   -
> +   -
> g7
> g6
> g5
> @@ -1200,6 +1210,8 @@ see .
> -
> -
> -
> +   -
> +   -
> r7
> r6
> r5
> @@ -1217,6 +1229,8 @@ see .
> -
> -
> -
> +   -
> +   -
> b7
> b6
> b5
> @@ -1234,6 +1248,8 @@ see .
> -
> -
> -
> +   -
> +   -
> g7
> g6
> g5
> @@ -1251,6 +1267,8 @@ see .
> -
> -
> -
> +   -
> +   -
> g7
> g6
> g5
> @@ -1268,6 +1286,8 @@ see .
> -
> -
> -
> +   -
> +   -
> r7
> r6
> r5
> @@ -1285,6 +1305,8 @@ see .
> -
> -
> -
> +   -
> +   -
> b7
> b6
> b5
> @@ -1302,6 +1324,8 @@ see .
> -
> -
> -
> +   -
> +   -
> g7
> g6
> g5
> @@ -1319,6 +1343,8 @@ see .
> -
> -
> -
> +   -
> +   -
> g7
> g6
> g5
> @@ -1336,6 +1362,8 @@ see .
> -
> -
> -
> +   -
> +   -
> r7
> r6
> r5
> @@ -1353,6 +1381,8 @@ see .
> -
> -
> -
> +   -
> +   -
> 0
> 0
> 0
> @@ -1370,6 +1400,8 @@ see .
> -
> -
> -
> +   -
> +   -
> b7
> b6
> b5
> @@ -1387,6 +1419,8 @@ see .
> -
> -
> -
> +   -
> +   -
> b7
> b6
> b5
> @@ -1404,6 +1438,8 @@ see .
> -
> -
> -
> +   -
> +   -
> 0
> 0
> 0
> @@ -1421,6 +1457,8 @@ see .
> -
> -
> -
> +   -
> +   -
> b9
> b8
> b7
> @@ -1438,6 +1476,8 @@ see .
> -
> -
> -
> +   -
> +   -
> b1
> b0
> 0
> @@ -1455,6 +1495,8 @@ see .
> -
> -
> -
> +   -
> +   -
> b1
> b0
> 0
> @@ -1472,6 +1514,8 @@ see .
> -
> -
> -
> +   -
> +   -
> b9
> b8
> b7
> @@ -1487,6 +1531,8 @@ see .
> 
> -
> -
> +   -
> +   -
> b9
> b8
> b7
> @@ -1504,6 +1550,8 @@ see .
> 
> -
> -
> +

Re: [PATCH 3/6] v4l: Add packed Bayer raw12 pixel formats

On 05/27/2016 02:44 PM, Sakari Ailus wrote:
> These formats are compressed 12-bit raw bayer formats with four different
> pixel orders. They are similar to 10-bit variants. The formats added by
> this patch are
> 
>   V4L2_PIX_FMT_SBGGR12P
>   V4L2_PIX_FMT_SGBRG12P
>   V4L2_PIX_FMT_SGRBG12P
>   V4L2_PIX_FMT_SRGGB12P
> 
> Signed-off-by: Sakari Ailus 
> ---
>  .../DocBook/media/v4l/pixfmt-srggb12p.xml  | 103 
> +
>  Documentation/DocBook/media/v4l/pixfmt.xml |   1 +
>  include/uapi/linux/videodev2.h |   5 +
>  3 files changed, 109 insertions(+)
>  create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml
> new file mode 100644
> index 000..affa366
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12p.xml
> @@ -0,0 +1,103 @@
> +
> +  
> + V4L2_PIX_FMT_SRGGB12P ('pRCC'),
> +  V4L2_PIX_FMT_SGRBG12P ('pgCC'),
> +  V4L2_PIX_FMT_SGBRG12P ('pGCC'),
> +  V4L2_PIX_FMT_SBGGR12P ('pBCC'),

Nitpick: the last comma should be removed otherwise the title would end with it.

Looks good otherwise.

With the comma removed:

Acked-by: Hans Verkuil 

Regards,

Hans

> +  
> + 
> +  
> +  
> +  id="V4L2-PIX-FMT-SRGGB12P">V4L2_PIX_FMT_SRGGB12P
> +  id="V4L2-PIX-FMT-SGRBG12P">V4L2_PIX_FMT_SGRBG12P
> +  id="V4L2-PIX-FMT-SGBRG12P">V4L2_PIX_FMT_SGBRG12P
> +  id="V4L2-PIX-FMT-SBGGR12P">V4L2_PIX_FMT_SBGGR12P
> + 12-bit packed Bayer formats
> +  
> +  
> + Description
> +
> + These four pixel formats are packed raw sRGB / Bayer
> + formats with 12 bits per colour. Every four consecutive colour
> + components are packed into 6 bytes. Each of the first 4 bytes
> + contain the 8 high order bits of the pixels, and the fifth and
> + sixth bytes contains the four least significants bits of each
> + pixel, in the same order.
> +
> + Each n-pixel row contains n/2 green samples and n/2 blue
> + or red samples, with alternating green-red and green-blue
> + rows. They are conventionally described as GRGR... BGBG...,
> + RGRG... GBGB..., etc. Below is an example of one of these
> + formats:
> +
> +
> +  V4L2_PIX_FMT_SBGGR12P 4  4
> +  pixel image
> +
> +  
> + Byte Order.
> + Each cell is one byte.
> +   
> + 
> +   
> +   
> + 
> +   start+0:
> +   B00high
> +   G01high
> +   G01low(bits 7--4)
> +  B00low(bits 3--0)
> +   
> +   B02high
> +   G03high
> +   G03low(bits 7--4)
> +  B02low(bits 3--0)
> +   
> + 
> + 
> +   start+6:
> +   G10high
> +   R11high
> +   R11low(bits 7--4)
> +  G10low(bits 3--0)
> +   
> +   G12high
> +   R13high
> +   R13low(bits 7--4)
> +  G12low(bits 3--0)
> +   
> + 
> + 
> +   start+12:
> +   B20high
> +   G21high
> +   G21low(bits 7--4)
> +  B20low(bits 3--0)
> +   
> +   B22high
> +   G23high
> +   G23low(bits 7--4)
> +  B22low(bits 3--0)
> +   
> + 
> + 
> +   start+18:
> +   G30high
> +   R31high
> +   R31low(bits 7--4)
> +  G30low(bits 3--0)
> +   
> +   G32high
> +   R33high
> +   R33low(bits 7--4)
> +  G32low(bits 3--0)
> +   
> + 
> +   
> + 
> +   
> + 
> +  
> +
> +  
> +
> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
> b/Documentation/DocBook/media/v4l/pixfmt.xml
> index 5a08aee..457337e 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> @@ -1593,6 +1593,7 @@ access the palette, this must be done with ioctls of 
> the Linux framebuffer API.<
>  
>  
>  
> +
>
>  
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 8f95191..7ace868 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -576,6 +576,11 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_SGBRG12 v4l2_fourcc('G', 'B', '1', '2') /* 12  GBGB.. 
> RGRG.. */
>  #define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12  GRGR.. 
> BGBG.. */
>  #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG..

Re: [PATCH 5/6] v4l: Add 14-bit raw bayer pixel format definitions

On 05/27/2016 02:44 PM, Sakari Ailus wrote:
> The formats added by this patch are:
> 
>   V4L2_PIX_FMT_SBGGR14
>   V4L2_PIX_FMT_SGBRG14
>   V4L2_PIX_FMT_SGRBG14
>   V4L2_PIX_FMT_SRGGB14
> 
> Signed-off-by: Jouni Ukkonen 
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/DocBook/media/v4l/pixfmt-srggb14.xml | 90 
> ++
>  Documentation/DocBook/media/v4l/pixfmt.xml |  1 +
>  include/uapi/linux/videodev2.h |  4 +
>  3 files changed, 95 insertions(+)
>  create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb14.xml
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml
> new file mode 100644
> index 000..7e82d7e
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb14.xml
> @@ -0,0 +1,90 @@
> +
> +  
> + V4L2_PIX_FMT_SRGGB14 ('RG14'),
> +  V4L2_PIX_FMT_SGRBG14 ('BA14'),
> +  V4L2_PIX_FMT_SGBRG14 ('GB14'),
> +  V4L2_PIX_FMT_SBGGR14 ('BG14'),

Same comma problem.

> +  
> + 
> +  
> +  
> +  id="V4L2-PIX-FMT-SRGGB14">V4L2_PIX_FMT_SRGGB14
> +  id="V4L2-PIX-FMT-SGRBG14">V4L2_PIX_FMT_SGRBG14
> +  id="V4L2-PIX-FMT-SGBRG14">V4L2_PIX_FMT_SGBRG14
> +  id="V4L2-PIX-FMT-SBGGR14">V4L2_PIX_FMT_SBGGR14
> + 14-bit Bayer formats expanded to 16 bits
> +  
> +  
> + Description
> +
> + These four pixel formats are raw sRGB / Bayer formats with
> +14 bits per colour. Each colour component is stored in a 16-bit word, with 2
> +unused high bits filled with zeros. Each n-pixel row contains n/2 green 
> samples
> +and n/2 blue or red samples, with alternating red and blue rows. Bytes are
> +stored in memory in little endian order. They are conventionally described
> +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
> +formats

s/formats/formats:/

> +
> +
> +  V4L2_PIX_FMT_SBGGR14 4  4
> +pixel image
> +
> +  
> + Byte Order.
> + Each cell is one byte, high 2 bits in high bytes are 0.

s/high 2/the high 2/

> +   
> + 
> +   
> +   
> + 
> +   start+0:
> +   B00low
> +   B00high
> +   G01low
> +   G01high
> +   B02low
> +   B02high
> +   G03low
> +   G03high
> + 
> + 
> +   start+8:
> +   G10low
> +   G10high
> +   R11low
> +   R11high
> +   G12low
> +   G12high
> +   R13low
> +   R13high
> + 
> + 
> +   start+16:
> +   B20low
> +   B20high
> +   G21low
> +   G21high
> +   B22low
> +   B22high
> +   G23low
> +   G23high
> + 
> + 
> +   start+24:
> +   G30low
> +   G30high
> +   R31low
> +   R31high
> +   G32low
> +   G32high
> +   R33low
> +   R33high
> + 
> +   
> + 
> +   
> + 
> +  
> +
> +  
> +
> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
> b/Documentation/DocBook/media/v4l/pixfmt.xml
> index 457337e..29e9d7c 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> @@ -1594,6 +1594,7 @@ access the palette, this must be done with ioctls of 
> the Linux framebuffer API.<
>  
>  
>  
> +
>
>  
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 7ace868..2c4b076 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -581,6 +581,10 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_SGBRG12P v4l2_fourcc('p', 'G', 'C', 'C')
>  #define V4L2_PIX_FMT_SGRBG12P v4l2_fourcc('p', 'g', 'C', 'C')
>  #define V4L2_PIX_FMT_SRGGB12P v4l2_fourcc('p', 'R', 'C', 'C')
> +#define V4L2_PIX_FMT_SBGGR14 v4l2_fourcc('B', 'G', '1', '4') /* 14  BGBG.. 
> GRGR.. */
> +#define V4L2_PIX_FMT_SGBRG14 v4l2_fourcc('G', 'B', '1', '4') /* 14  GBGB.. 
> RGRG.. */
> +#define V4L2_PIX_FMT_SGRBG14 v4l2_fourcc('B', 'A', '1', '4') /* 14  GRGR.. 
> BGBG.. */
> +#define V4L2_PIX_FMT_SRGGB14 v4l2_fourcc('R', 'G', '1', '4') /* 14  RGRG.. 
> GBGB.. */
>  #define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16  BGBG.. 
> GRGR.. */
>  
>  /* compressed formats */
> 

Regards,

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

Re: [PATCH 1/6] v4l: Correct the ordering of LSBs of the 10-bit raw packed formats

On 05/27/2016 02:44 PM, Sakari Ailus wrote:
> The 10-bit packed raw bayer format documented that the data of the first
> pixel of a four-pixel group was found in the first byte and the two
> highest bits of the fifth byte. This was not entirely correct. The two
> bits in the fifth byte are the two lowest bits. The second pixel occupies
> the second byte and third and fourth least significant bits and so on.

This is used by the uvc driver. Has this been verified against a UVC webcam
that supports this format? Laurent, do you have such a device?

Just in case UVC actually supports this as it is documented today.

Regards,

Hans

> 
> Signed-off-by: Sakari Ailus 
> ---
>  .../DocBook/media/v4l/pixfmt-srggb10p.xml  | 32 
> +++---
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
> index a8cc102..747822b 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
> @@ -47,10 +47,10 @@
> G01high
> B02high
> G03high
> -   B00low(bits 7--6)
> -  G01low(bits 5--4)
> -  B02low(bits 3--2)
> -  G03low(bits 1--0)
> +   G03low(bits 7--6)
> +  B02low(bits 5--4)
> +  G01low(bits 3--2)
> +  B00low(bits 1--0)
> 
>   
>   
> @@ -59,10 +59,10 @@
> R11high
> G12high
> R13high
> -   G10low(bits 7--6)
> -  R11low(bits 5--4)
> -  G12low(bits 3--2)
> -  R13low(bits 1--0)
> +   R13low(bits 7--6)
> +  G12low(bits 5--4)
> +  R11low(bits 3--2)
> +  G10low(bits 1--0)
> 
>   
>   
> @@ -71,10 +71,10 @@
> G21high
> B22high
> G23high
> -   B20low(bits 7--6)
> -  G21low(bits 5--4)
> -  B22low(bits 3--2)
> -  G23low(bits 1--0)
> +   G23low(bits 7--6)
> +  B22low(bits 5--4)
> +  G21low(bits 3--2)
> +  B20low(bits 1--0)
> 
>   
>   
> @@ -83,10 +83,10 @@
> R31high
> G32high
> R33high
> -   G30low(bits 7--6)
> -  R31low(bits 5--4)
> -  G32low(bits 3--2)
> -  R33low(bits 1--0)
> +   R33low(bits 7--6)
> +  G32low(bits 5--4)
> +  R31low(bits 3--2)
> +  G30low(bits 1--0)
> 
>   
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] v4l: Fix number of zeroed high order bits in 12-bit raw format defs

On 05/27/2016 02:44 PM, Sakari Ailus wrote:
> The number of high order bits in samples was documented to be 6 for 12-bit
> data. This is clearly wrong, fix it.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Thanks,

Hans

> ---
>  Documentation/DocBook/media/v4l/pixfmt-srggb12.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
> index 0c8e4ad..4394101 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
> @@ -31,7 +31,7 @@ pixel image
>  
>
>   Byte Order.
> - Each cell is one byte, high 6 bits in high bytes are 0.
> + Each cell is one byte, high 4 bits in high bytes are 0.
> 
>   
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bug: dvbv5-scan fails on HD transponder (dvb-s2)

2016-06-20 Thread Robert Logan

Card/scan works fine picking up non-HD. Never getting any HD channels.
UK based. STB picks up all channels fine. Transponder details from
Astra-28.2E dvb-s, and matches BBC details.

On latest clone of master git repo, using only BBCHD transponder:
# Transponder 50
[CHANNEL]
DELIVERY_SYSTEM = DVBS2
FREQUENCY = 10847000
POLARIZATION = VERTICAL
SYMBOL_RATE = 2300
INNER_FEC = 2/3
MODULATION = PSK/8
INVERSION = AUTO

dvbv5-scan -f -p  -T2 -W100 -C gb BBCHD -lENHANCED -a0 -vvv:
Using LNBf ENHANCED
Astra
10700 to 11700 MHz
Single LO, IF = 9750 MHz
using demux '/dev/dvb/adapter0/demux0'
Device Conexant CX24117/CX24132 (/dev/dvb/adapter0/frontend0) capabilities:
 CAN_2G_MODULATION
 CAN_FEC_1_2
 CAN_FEC_2_3
 CAN_FEC_3_4
 CAN_FEC_4_5
 CAN_FEC_5_6
 CAN_FEC_6_7
 CAN_FEC_7_8
 CAN_FEC_AUTO
 CAN_INVERSION_AUTO
 CAN_QPSK
 CAN_RECOVER
DVB API Version 5.10, Current v5 delivery system: DVBS2
Supported delivery systems:
 DVBS
[DVBS2]
ERRORcommand BANDWIDTH_HZ (5) not found during retrieve
Cannot calc frequency shift. Either bandwidth/symbol-rate is unavailable (yet).
Scanning frequency #1 10847000
frequency: 10847.00 MHz, high_band: 0
SEC: set voltage to 13V
DiSEqC TONE: OFF
L-Band frequency: 1097.00 MHz (offset = 9750.00 MHz)
FREQUENCY = 10847000
INVERSION = AUTO
SYMBOL_RATE = 2300
INNER_FEC = 2/3
MODULATION = PSK/8
PILOT = 4294967295
ROLLOFF = AUTO
POLARIZATION = VERTICAL
STREAM_ID = 0
DELIVERY_SYSTEM = DVBS2
Status:
CARRIER
SIGNAL
BER: 0, Strength: 46024, SNR: 0, UCB: 0
DEBUGStats for STATUS = 3
DEBUGStats for STATUS = 3
DEBUGStats for STATUS = 3
DEBUGStats for POST BER = 0
Carrier(0x03) Signal= 70.23% C/N= 0.00% UCB= 0 postBER= 0
Status:
CARRIER
SIGNAL
BER: 0, Strength: 45924, SNR: 0, UCB: 0
DEBUGStats for STATUS = 3
DEBUGStats for STATUS = 3
DEBUGStats for POST BER = 0
Carrier(0x03) Signal= 70.08% C/N= 0.00% UCB= 0 postBER= 0
Status:
CARRIER
SIGNAL
BER: 0, Strength: 46024, SNR: 0, UCB: 0
DEBUGStats for STATUS = 3
DEBUGStats for STATUS = 3
DEBUGStats for POST BER = 0
Carrier(0x03) Signal= 70.23% C/N= 0.00% UCB= 0 postBER= 0
etc ends

lspci -vvv:
01:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885
PCI Video and Audio Decoder (rev 04)
Subsystem: Device 6981:
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Kernel driver in use: cx23885
Kernel modules: cx23885
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/4] vb2: Merge vb2_internal_dqbuf and vb2_dqbuf

On Mon, Jun 20, 2016 at 02:47:23PM +0200, Ricardo Ribalda Delgado wrote:
> After all the code refactoring, vb2_internal_dqbuf is only called by
> vb2_dqbuf.
> 
> Since the function it is very simple, there is no need to have two
> functions.
> 
> Signed-off-by: Ricardo Ribalda Delgado 

Hi, Ricardo!

Patches 2--4: 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: 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: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

2016-06-20 Thread Pekka Paalanen

On Mon, 20 Jun 2016 09:45:26 -0400
Rob Clark  wrote:

> On Mon, Jun 20, 2016 at 8:37 AM, Pekka Paalanen  wrote:
> > On Fri, 17 Jun 2016 11:44:34 -0400
> > Rob Clark  wrote:
> >  
> >> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen  
> >> wrote:  
> >> > On Fri, 17 Jun 2016 08:26:04 -0400
> >> > Rob Clark  wrote:
> >> >  
> >> >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen  
> >> >> wrote:  
> >> >> > On Thu, 16 Jun 2016 10:40:51 -0400
> >> >> > Rob Clark  wrote:
> >> >> >  
> >> >> >> So, if we wanted to extend this to support the fourcc-modifiers that
> >> >> >> we have on the kernel side for compressed/tiled/etc formats, what
> >> >> >> would be the right approach?
> >> >> >>
> >> >> >> A new version of the existing extension or a new
> >> >> >> EGL_EXT_image_dma_buf_import2 extension, or ??  
> >> >> >
> >> >> > Hi Rob,
> >> >> >
> >> >> > there are actually several things it might be nice to add:
> >> >> >
> >> >> > - a fourth plane, to match what DRM AddFB2 supports
> >> >> >
> >> >> > - the 64-bit fb modifiers
> >> >> >
> >> >> > - queries for which pixel formats are supported by EGL, so a display
> >> >> >   server can tell the applications that before the application goes 
> >> >> > and
> >> >> >   tries with a random bunch of them, shooting in the dark
> >> >> >
> >> >> > - queries for which modifiers are supported for each pixel format, 
> >> >> > ditto
> >> >> >
> >> >> > I discussed these with Emil in the past, and it seems an appropriate
> >> >> > approach might be the following.
> >> >> >
> >> >> > Adding the 4th plane can be done as revising the existing
> >> >> > EGL_EXT_image_dma_buf_import extension. The plane count is tied to
> >> >> > pixel formats (and modifiers?), so the user does not need to know
> >> >> > specifically whether the EGL implementation could handle a 4th plane 
> >> >> > or
> >> >> > not. It is implied by the pixel format.
> >> >> >
> >> >> > Adding the fb modifiers needs to be a new extension, so that users can
> >> >> > tell if they are supported or not. This is to avoid the following 
> >> >> > false
> >> >> > failure: if user assumes modifiers are always supported, it will 
> >> >> > (may?)
> >> >> > provide zero modifiers explicitly. If EGL implementation does not
> >> >> > handle modifiers this would be rejected as unrecognized attributes,
> >> >> > while if the zero modifiers were not given explicitly, everything 
> >> >> > would
> >> >> > just work.  
> >> >>
> >> >> hmm, if we design it as "not passing modifier" == "zero modifier", and
> >> >> "never explicitly pass a zero modifier" then modifiers could be added
> >> >> without a new extension.  Although I agree that queries would need a
> >> >> new extension.. so perhaps not worth being clever.  
> >> >
> >> > Indeed.
> >> >  
> >> >> > The queries obviously(?) need a new extension. It might make sense
> >> >> > to bundle both modifier support and the queries in the same new
> >> >> > extension.
> >> >> >
> >> >> > We have some rough old WIP code at
> >> >> > https://git.collabora.com/cgit/user/lfrb/mesa.git/log/?h=T1410-modifiers
> >> >> > https://git.collabora.com/cgit/user/lfrb/egl-specs.git/log/?h=T1410
> >> >> >
> >> >> >  
> >> >> >> On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey  
> >> >> >> wrote:  
> >> >> >> > Hi All,
> >> >> >> >
> >> >> >> > The final spec has had enum values assigned and been published on 
> >> >> >> > Khronos:
> >> >> >> >
> >> >> >> > http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
> >> >> >> >
> >> >> >> > Thanks to all who've provided input.  
> >> >> >
> >> >> > May I also pull your attention to a detail with the existing spec and
> >> >> > Mesa behaviour I am asking about in
> >> >> > https://lists.freedesktop.org/archives/mesa-dev/2016-June/120249.html
> >> >> > "What is EGL_EXT_image_dma_buf_import image orientation as a GL 
> >> >> > texture?"
> >> >> > Doing a dmabuf import seems to imply an y-flip AFAICT.  
> >> >>
> >> >> I would have expected that *any* egl external image (dma-buf or
> >> >> otherwise) should have native orientation rather than gl orientation.
> >> >> It's somewhat useless otherwise.  
> >> >
> >> > In that case importing dmabuf works differently than importing a
> >> > wl_buffer (wl_drm), because for the latter, the y-invert flag is
> >> > returned such that the orientation will match GL. And the direct
> >> > scanout path goes through GBM since you have to import a wl_buffer, and
> >> > I haven't looked what GBM does wrt. y-flip if anything.
> >> >  
> >> >> I didn't read it carefully yet (would need caffeine first ;-)) but
> >> >> EGL_KHR_image_base does say "This extension defines a new EGL resource
> >> >> type that is suitable for sharing 2D arrays of image data between
> >> >> client APIs" which to me implies native orientation.  So that

Re: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

2016-06-20 Thread Rob Clark

On Mon, Jun 20, 2016 at 8:37 AM, Pekka Paalanen  wrote:
> On Fri, 17 Jun 2016 11:44:34 -0400
> Rob Clark  wrote:
>
>> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen  wrote:
>> > On Fri, 17 Jun 2016 08:26:04 -0400
>> > Rob Clark  wrote:
>> >
>> >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen  
>> >> wrote:
>> >> > On Thu, 16 Jun 2016 10:40:51 -0400
>> >> > Rob Clark  wrote:
>> >> >
>> >> >> So, if we wanted to extend this to support the fourcc-modifiers that
>> >> >> we have on the kernel side for compressed/tiled/etc formats, what
>> >> >> would be the right approach?
>> >> >>
>> >> >> A new version of the existing extension or a new
>> >> >> EGL_EXT_image_dma_buf_import2 extension, or ??
>> >> >
>> >> > Hi Rob,
>> >> >
>> >> > there are actually several things it might be nice to add:
>> >> >
>> >> > - a fourth plane, to match what DRM AddFB2 supports
>> >> >
>> >> > - the 64-bit fb modifiers
>> >> >
>> >> > - queries for which pixel formats are supported by EGL, so a display
>> >> >   server can tell the applications that before the application goes and
>> >> >   tries with a random bunch of them, shooting in the dark
>> >> >
>> >> > - queries for which modifiers are supported for each pixel format, ditto
>> >> >
>> >> > I discussed these with Emil in the past, and it seems an appropriate
>> >> > approach might be the following.
>> >> >
>> >> > Adding the 4th plane can be done as revising the existing
>> >> > EGL_EXT_image_dma_buf_import extension. The plane count is tied to
>> >> > pixel formats (and modifiers?), so the user does not need to know
>> >> > specifically whether the EGL implementation could handle a 4th plane or
>> >> > not. It is implied by the pixel format.
>> >> >
>> >> > Adding the fb modifiers needs to be a new extension, so that users can
>> >> > tell if they are supported or not. This is to avoid the following false
>> >> > failure: if user assumes modifiers are always supported, it will (may?)
>> >> > provide zero modifiers explicitly. If EGL implementation does not
>> >> > handle modifiers this would be rejected as unrecognized attributes,
>> >> > while if the zero modifiers were not given explicitly, everything would
>> >> > just work.
>> >>
>> >> hmm, if we design it as "not passing modifier" == "zero modifier", and
>> >> "never explicitly pass a zero modifier" then modifiers could be added
>> >> without a new extension.  Although I agree that queries would need a
>> >> new extension.. so perhaps not worth being clever.
>> >
>> > Indeed.
>> >
>> >> > The queries obviously(?) need a new extension. It might make sense
>> >> > to bundle both modifier support and the queries in the same new
>> >> > extension.
>> >> >
>> >> > We have some rough old WIP code at
>> >> > https://git.collabora.com/cgit/user/lfrb/mesa.git/log/?h=T1410-modifiers
>> >> > https://git.collabora.com/cgit/user/lfrb/egl-specs.git/log/?h=T1410
>> >> >
>> >> >
>> >> >> On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey  
>> >> >> wrote:
>> >> >> > Hi All,
>> >> >> >
>> >> >> > The final spec has had enum values assigned and been published on 
>> >> >> > Khronos:
>> >> >> >
>> >> >> > http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>> >> >> >
>> >> >> > Thanks to all who've provided input.
>> >> >
>> >> > May I also pull your attention to a detail with the existing spec and
>> >> > Mesa behaviour I am asking about in
>> >> > https://lists.freedesktop.org/archives/mesa-dev/2016-June/120249.html
>> >> > "What is EGL_EXT_image_dma_buf_import image orientation as a GL 
>> >> > texture?"
>> >> > Doing a dmabuf import seems to imply an y-flip AFAICT.
>> >>
>> >> I would have expected that *any* egl external image (dma-buf or
>> >> otherwise) should have native orientation rather than gl orientation.
>> >> It's somewhat useless otherwise.
>> >
>> > In that case importing dmabuf works differently than importing a
>> > wl_buffer (wl_drm), because for the latter, the y-invert flag is
>> > returned such that the orientation will match GL. And the direct
>> > scanout path goes through GBM since you have to import a wl_buffer, and
>> > I haven't looked what GBM does wrt. y-flip if anything.
>> >
>> >> I didn't read it carefully yet (would need caffeine first ;-)) but
>> >> EGL_KHR_image_base does say "This extension defines a new EGL resource
>> >> type that is suitable for sharing 2D arrays of image data between
>> >> client APIs" which to me implies native orientation.  So that just
>> >> sounds like a mesa bug somehow?
>> >
>> > That specific sentence implies nothing about orientation to me.
>> > Furthermore, the paragraph continues:
>> >
>> > "Although the intended purpose is sharing 2D image data, the
>> > underlying interface makes no assumptions about the format or
>> > purpose of the resource being shared, leaving

Re: [PATCH 3/3] dma-buf: remove dma_buf_debugfs_create_file()

2016-06-20 Thread Daniel Vetter

On Sun, Jun 19, 2016 at 02:31:31PM +0200, Mathias Krause wrote:
> There is only a single user of dma_buf_debugfs_create_file() and that
> one got the function pointer cast wrong. With that one fixed, there is
> no need to have a wrapper for debugfs_create_file(), just call it
> directly.
> 
> With no users left, we can remove dma_buf_debugfs_create_file().
> 
> While at it, simplify the error handling in dma_buf_init_debugfs()
> slightly.
> 
> Signed-off-by: Mathias Krause 

ah, here's the 2nd part, feel free to ignore my earlier comments. On the
series:

Reviewed-by: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> ---
>  drivers/dma-buf/dma-buf.c |   29 +
>  include/linux/dma-buf.h   |2 --
>  2 files changed, 9 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f03e51561199..20ce0687b111 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -895,22 +895,22 @@ static struct dentry *dma_buf_debugfs_dir;
>  
>  static int dma_buf_init_debugfs(void)
>  {
> + struct dentry *d;
>   int err = 0;
>  
> - dma_buf_debugfs_dir = debugfs_create_dir("dma_buf", NULL);
> + d = debugfs_create_dir("dma_buf", NULL);
> + if (IS_ERR(d))
> + return PTR_ERR(d);
>  
> - if (IS_ERR(dma_buf_debugfs_dir)) {
> - err = PTR_ERR(dma_buf_debugfs_dir);
> - dma_buf_debugfs_dir = NULL;
> - return err;
> - }
> + dma_buf_debugfs_dir = d;
>  
> - err = dma_buf_debugfs_create_file("bufinfo", NULL);
> -
> - if (err) {
> + d = debugfs_create_file("bufinfo", S_IRUGO, dma_buf_debugfs_dir,
> + NULL, _buf_debug_fops);
> + if (IS_ERR(d)) {
>   pr_debug("dma_buf: debugfs: failed to create node bufinfo\n");
>   debugfs_remove_recursive(dma_buf_debugfs_dir);
>   dma_buf_debugfs_dir = NULL;
> + err = PTR_ERR(d);
>   }
>  
>   return err;
> @@ -921,17 +921,6 @@ static void dma_buf_uninit_debugfs(void)
>   if (dma_buf_debugfs_dir)
>   debugfs_remove_recursive(dma_buf_debugfs_dir);
>  }
> -
> -int dma_buf_debugfs_create_file(const char *name,
> - int (*write)(struct seq_file *))
> -{
> - struct dentry *d;
> -
> - d = debugfs_create_file(name, S_IRUGO, dma_buf_debugfs_dir,
> - write, _buf_debug_fops);
> -
> - return PTR_ERR_OR_ZERO(d);
> -}
>  #else
>  static inline int dma_buf_init_debugfs(void)
>  {
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 4551c6f2a6c4..e0b0741ae671 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -242,6 +242,4 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct 
> *,
>unsigned long);
>  void *dma_buf_vmap(struct dma_buf *);
>  void dma_buf_vunmap(struct dma_buf *, void *vaddr);
> -int dma_buf_debugfs_create_file(const char *name,
> - int (*write)(struct seq_file *));
>  #endif /* __DMA_BUF_H__ */
> -- 
> 1.7.10.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] dma-buf: propagate errors from dma_buf_describe() on debugfs read

2016-06-20 Thread Daniel Vetter

On Sun, Jun 19, 2016 at 02:31:29PM +0200, Mathias Krause wrote:
> The callback function dma_buf_describe() returns an int not void so the
> function pointer cast in dma_buf_show() is wrong. dma_buf_describe() can
> also fail when acquiring the mutex gets interrupted so always returning
> 0 in dma_buf_show() is wrong, too.
> 
> Fix both issues by avoiding the indirection via dma_buf_show() and call
> dma_buf_describe() directly. Rename it to dma_buf_debug_show() to get it
> in line with the other functions.
> 
> This type mismatch was caught by the PaX RAP plugin.
> 
> Signed-off-by: Mathias Krause 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> Cc: Brad Spengler 
> Cc: PaX Team 
> ---
>  drivers/dma-buf/dma-buf.c |   14 +++---
>  1 file changed, 3 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 6355ab38d630..7094b19bb495 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -824,7 +824,7 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
>  EXPORT_SYMBOL_GPL(dma_buf_vunmap);
>  
>  #ifdef CONFIG_DEBUG_FS
> -static int dma_buf_describe(struct seq_file *s)
> +static int dma_buf_debug_show(struct seq_file *s, void *unused)
>  {
>   int ret;
>   struct dma_buf *buf_obj;
> @@ -879,17 +879,9 @@ static int dma_buf_describe(struct seq_file *s)
>   return 0;
>  }
>  
> -static int dma_buf_show(struct seq_file *s, void *unused)
> -{
> - void (*func)(struct seq_file *) = s->private;
> -
> - func(s);
> - return 0;
> -}
> -
>  static int dma_buf_debug_open(struct inode *inode, struct file *file)
>  {
> - return single_open(file, dma_buf_show, inode->i_private);
> + return single_open(file, dma_buf_debug_show, NULL);
>  }
>  
>  static const struct file_operations dma_buf_debug_fops = {
> @@ -913,7 +905,7 @@ static int dma_buf_init_debugfs(void)
>   return err;
>   }
>  
> - err = dma_buf_debugfs_create_file("bufinfo", dma_buf_describe);
> + err = dma_buf_debugfs_create_file("bufinfo", NULL);

This indirection now doesn't make much sense I think. I think more
sensible to instead pass drm_buf_debug_show, since that's the
parametrization that matters. Or just inline that one too.
-Daniel

>  
>   if (err)
>   pr_debug("dma_buf: debugfs: failed to create node bufinfo\n");
> -- 
> 1.7.10.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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 2/4] vb2: Merge vb2_internal_dqbuf and vb2_dqbuf

After all the code refactoring, vb2_internal_dqbuf is only called by
vb2_dqbuf.

Since the function it is very simple, there is no need to have two
functions.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c | 39 ++--
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 6d14df3d615d..7dff2b688a9f 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -621,27 +621,6 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
 }
 EXPORT_SYMBOL_GPL(vb2_qbuf);
 
-static int vb2_internal_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b,
-   bool nonblocking)
-{
-   int ret;
-
-   if (b->type != q->type) {
-   dprintk(1, "invalid buffer type\n");
-   return -EINVAL;
-   }
-
-   ret = vb2_core_dqbuf(q, NULL, b, nonblocking);
-
-   /*
-*  After calling the VIDIOC_DQBUF V4L2_BUF_FLAG_DONE must be
-*  cleared.
-*/
-   b->flags &= ~V4L2_BUF_FLAG_DONE;
-
-   return ret;
-}
-
 /**
  * vb2_dqbuf() - Dequeue a buffer to the userspace
  * @q: videobuf2 queue
@@ -665,11 +644,27 @@ static int vb2_internal_dqbuf(struct vb2_queue *q, struct 
v4l2_buffer *b,
  */
 int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool nonblocking)
 {
+   int ret;
+
if (vb2_fileio_is_active(q)) {
dprintk(1, "file io in progress\n");
return -EBUSY;
}
-   return vb2_internal_dqbuf(q, b, nonblocking);
+
+   if (b->type != q->type) {
+   dprintk(1, "invalid buffer type\n");
+   return -EINVAL;
+   }
+
+   ret = vb2_core_dqbuf(q, NULL, b, nonblocking);
+
+   /*
+*  After calling the VIDIOC_DQBUF V4L2_BUF_FLAG_DONE must be
+*  cleared.
+*/
+   b->flags &= ~V4L2_BUF_FLAG_DONE;
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(vb2_dqbuf);
 
-- 
2.8.1

--
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 4/4] vb2: Fix comment

The comment was referencing the wrong function.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/videobuf2-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 633fc1ab1d7a..ba6ab8b7311f 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1845,7 +1845,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
 * Make sure to call buf_finish for any queued buffers. Normally
 * that's done in dqbuf, but that's not going to happen when we
 * cancel the whole queue. Note: this code belongs here, not in
-* __vb2_dqbuf() since in vb2_internal_dqbuf() there is a critical
+* __vb2_dqbuf() since in vb2_core_dqbuf() there is a critical
 * call to __fill_user_buffer() after buf_finish(). That order can't
 * be changed, so we can't move the buf_finish() to __vb2_dqbuf().
 */
-- 
2.8.1

--
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 1/4] vb2: V4L2_BUF_FLAG_DONE is set after DQBUF

According to the doc, V4L2_BUF_FLAG_DONE is cleared after DQBUF:

V4L2_BUF_FLAG_DONE 0x0004  ... After calling the VIDIOC_QBUF or
VIDIOC_DQBUF it is always cleared ...

Unfortunately, it seems that videobuf2 keeps it set after DQBUF. This
can be tested with vivid and dev_debug:

[257604.338082] video1: VIDIOC_DQBUF: 71:33:25.00260479 index=3,
type=vid-cap, flags=0x2004, field=none, sequence=163,
memory=userptr, bytesused=460800, offset/userptr=0x344b000,
length=460800

This patch forces FLAG_DONE to 0 after calling DQBUF.

Reported-by: Dimitrios Katsaros 
Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 7f366f1b0377..6d14df3d615d 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -633,6 +633,12 @@ static int vb2_internal_dqbuf(struct vb2_queue *q, struct 
v4l2_buffer *b,
 
ret = vb2_core_dqbuf(q, NULL, b, nonblocking);
 
+   /*
+*  After calling the VIDIOC_DQBUF V4L2_BUF_FLAG_DONE must be
+*  cleared.
+*/
+   b->flags &= ~V4L2_BUF_FLAG_DONE;
+
return ret;
 }
 
-- 
2.8.1

--
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 3/4] vb2: Merge vb2_internal_qbuf and vb2_qbuf

After all the code refactoring, vb2_internal_dqbuf is only called by
vb2_dqbuf.

Since the function it is very simple, there is no need to have
two functions.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 7dff2b688a9f..9cfbb6e4bc28 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -427,7 +427,7 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb,
if (V4L2_TYPE_IS_OUTPUT(b->type)) {
/*
 * For output buffers mask out the timecode flag:
-* this will be handled later in vb2_internal_qbuf().
+* this will be handled later in vb2_qbuf().
 * The 'field' is valid metadata for this output buffer
 * and so that needs to be copied here.
 */
@@ -586,13 +586,6 @@ int vb2_create_bufs(struct vb2_queue *q, struct 
v4l2_create_buffers *create)
 }
 EXPORT_SYMBOL_GPL(vb2_create_bufs);
 
-static int vb2_internal_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
-{
-   int ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
-
-   return ret ? ret : vb2_core_qbuf(q, b->index, b);
-}
-
 /**
  * vb2_qbuf() - Queue a buffer from userspace
  * @q: videobuf2 queue
@@ -612,12 +605,15 @@ static int vb2_internal_qbuf(struct vb2_queue *q, struct 
v4l2_buffer *b)
  */
 int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
 {
+   int ret;
+
if (vb2_fileio_is_active(q)) {
dprintk(1, "file io in progress\n");
return -EBUSY;
}
 
-   return vb2_internal_qbuf(q, b);
+   ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
+   return ret ? ret : vb2_core_qbuf(q, b->index, b);
 }
 EXPORT_SYMBOL_GPL(vb2_qbuf);
 
-- 
2.8.1

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

[PATCH v2 1/4] vb2: Merge vb2_internal_dqbuf and vb2_dqbuf

After all the code refactoring, vb2_internal_dqbuf is only called by
vb2_dqbuf.

Since the function it is very simple, there is no need to have two
functions.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 7f366f1b0377..07d8b409ce05 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -621,21 +621,6 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
 }
 EXPORT_SYMBOL_GPL(vb2_qbuf);
 
-static int vb2_internal_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b,
-   bool nonblocking)
-{
-   int ret;
-
-   if (b->type != q->type) {
-   dprintk(1, "invalid buffer type\n");
-   return -EINVAL;
-   }
-
-   ret = vb2_core_dqbuf(q, NULL, b, nonblocking);
-
-   return ret;
-}
-
 /**
  * vb2_dqbuf() - Dequeue a buffer to the userspace
  * @q: videobuf2 queue
@@ -659,11 +644,21 @@ static int vb2_internal_dqbuf(struct vb2_queue *q, struct 
v4l2_buffer *b,
  */
 int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool nonblocking)
 {
+   int ret;
+
if (vb2_fileio_is_active(q)) {
dprintk(1, "file io in progress\n");
return -EBUSY;
}
-   return vb2_internal_dqbuf(q, b, nonblocking);
+
+   if (b->type != q->type) {
+   dprintk(1, "invalid buffer type\n");
+   return -EINVAL;
+   }
+
+   ret = vb2_core_dqbuf(q, NULL, b, nonblocking);
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(vb2_dqbuf);
 
-- 
2.8.1

--
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 4/4] vb2: V4L2_BUF_FLAG_DONE is set after DQBUF


On 06/20/2016 02:30 PM, Ricardo Ribalda Delgado wrote:

According to the doc, V4L2_BUF_FLAG_DONE is cleared after DQBUF:

V4L2_BUF_FLAG_DONE 0x0004  ... After calling the VIDIOC_QBUF or
VIDIOC_DQBUF it is always cleared ...

Unfortunately, it seems that videobuf2 keeps it set after DQBUF. This
can be tested with vivid and dev_debug:

[257604.338082] video1: VIDIOC_DQBUF: 71:33:25.00260479 index=3,
type=vid-cap, flags=0x2004, field=none, sequence=163,
memory=userptr, bytesused=460800, offset/userptr=0x344b000,
length=460800

This patch forces FLAG_DONE to 0 after calling DQBUF.


Can you change this to be patch 1/4? That makes it much easier to backport to
older kernels. I'm not sure if I'll actually do that, but putting this patch
at the end makes it harder than it needs to be.

Regards,

Hans



Reported-by: Dimitrios Katsaros 
Signed-off-by: Ricardo Ribalda Delgado 
---
  drivers/media/v4l2-core/videobuf2-v4l2.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index ba3467468e55..9cfbb6e4bc28 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -654,6 +654,12 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, 
bool nonblocking)

ret = vb2_core_dqbuf(q, NULL, b, nonblocking);

+   /*
+*  After calling the VIDIOC_DQBUF V4L2_BUF_FLAG_DONE must be
+*  cleared.
+*/
+   b->flags &= ~V4L2_BUF_FLAG_DONE;
+
return ret;
  }
  EXPORT_SYMBOL_GPL(vb2_dqbuf);



--
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: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

2016-06-20 Thread Pekka Paalanen

On Fri, 17 Jun 2016 11:44:34 -0400
Rob Clark  wrote:

> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen  wrote:
> > On Fri, 17 Jun 2016 08:26:04 -0400
> > Rob Clark  wrote:
> >  
> >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen  
> >> wrote:  
> >> > On Thu, 16 Jun 2016 10:40:51 -0400
> >> > Rob Clark  wrote:
> >> >  
> >> >> So, if we wanted to extend this to support the fourcc-modifiers that
> >> >> we have on the kernel side for compressed/tiled/etc formats, what
> >> >> would be the right approach?
> >> >>
> >> >> A new version of the existing extension or a new
> >> >> EGL_EXT_image_dma_buf_import2 extension, or ??  
> >> >
> >> > Hi Rob,
> >> >
> >> > there are actually several things it might be nice to add:
> >> >
> >> > - a fourth plane, to match what DRM AddFB2 supports
> >> >
> >> > - the 64-bit fb modifiers
> >> >
> >> > - queries for which pixel formats are supported by EGL, so a display
> >> >   server can tell the applications that before the application goes and
> >> >   tries with a random bunch of them, shooting in the dark
> >> >
> >> > - queries for which modifiers are supported for each pixel format, ditto
> >> >
> >> > I discussed these with Emil in the past, and it seems an appropriate
> >> > approach might be the following.
> >> >
> >> > Adding the 4th plane can be done as revising the existing
> >> > EGL_EXT_image_dma_buf_import extension. The plane count is tied to
> >> > pixel formats (and modifiers?), so the user does not need to know
> >> > specifically whether the EGL implementation could handle a 4th plane or
> >> > not. It is implied by the pixel format.
> >> >
> >> > Adding the fb modifiers needs to be a new extension, so that users can
> >> > tell if they are supported or not. This is to avoid the following false
> >> > failure: if user assumes modifiers are always supported, it will (may?)
> >> > provide zero modifiers explicitly. If EGL implementation does not
> >> > handle modifiers this would be rejected as unrecognized attributes,
> >> > while if the zero modifiers were not given explicitly, everything would
> >> > just work.  
> >>
> >> hmm, if we design it as "not passing modifier" == "zero modifier", and
> >> "never explicitly pass a zero modifier" then modifiers could be added
> >> without a new extension.  Although I agree that queries would need a
> >> new extension.. so perhaps not worth being clever.  
> >
> > Indeed.
> >  
> >> > The queries obviously(?) need a new extension. It might make sense
> >> > to bundle both modifier support and the queries in the same new
> >> > extension.
> >> >
> >> > We have some rough old WIP code at
> >> > https://git.collabora.com/cgit/user/lfrb/mesa.git/log/?h=T1410-modifiers
> >> > https://git.collabora.com/cgit/user/lfrb/egl-specs.git/log/?h=T1410
> >> >
> >> >  
> >> >> On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey  
> >> >> wrote:  
> >> >> > Hi All,
> >> >> >
> >> >> > The final spec has had enum values assigned and been published on 
> >> >> > Khronos:
> >> >> >
> >> >> > http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
> >> >> >
> >> >> > Thanks to all who've provided input.  
> >> >
> >> > May I also pull your attention to a detail with the existing spec and
> >> > Mesa behaviour I am asking about in
> >> > https://lists.freedesktop.org/archives/mesa-dev/2016-June/120249.html
> >> > "What is EGL_EXT_image_dma_buf_import image orientation as a GL texture?"
> >> > Doing a dmabuf import seems to imply an y-flip AFAICT.  
> >>
> >> I would have expected that *any* egl external image (dma-buf or
> >> otherwise) should have native orientation rather than gl orientation.
> >> It's somewhat useless otherwise.  
> >
> > In that case importing dmabuf works differently than importing a
> > wl_buffer (wl_drm), because for the latter, the y-invert flag is
> > returned such that the orientation will match GL. And the direct
> > scanout path goes through GBM since you have to import a wl_buffer, and
> > I haven't looked what GBM does wrt. y-flip if anything.
> >  
> >> I didn't read it carefully yet (would need caffeine first ;-)) but
> >> EGL_KHR_image_base does say "This extension defines a new EGL resource
> >> type that is suitable for sharing 2D arrays of image data between
> >> client APIs" which to me implies native orientation.  So that just
> >> sounds like a mesa bug somehow?  
> >
> > That specific sentence implies nothing about orientation to me.
> > Furthermore, the paragraph continues:
> >
> > "Although the intended purpose is sharing 2D image data, the
> > underlying interface makes no assumptions about the format or
> > purpose of the resource being shared, leaving those decisions
> > to the application and associated client APIs."
> >
> > Might "format" include orientation?
> >
> > How does "native orientation" connect

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

2016-06-20 Thread Richard Cochran

On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote:
> Documentation/sound/alsa/timestamping.txt says:

   Examples of typestamping with HDaudio:

   1. DMA timestamp, no compensation for DMA+analog delay
   $ ./audio_time  -p --ts_type=1

Where is this "audio_time" program of which you speak?

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

[PATCH v2 4/4] vb2: V4L2_BUF_FLAG_DONE is set after DQBUF

According to the doc, V4L2_BUF_FLAG_DONE is cleared after DQBUF:

V4L2_BUF_FLAG_DONE 0x0004  ... After calling the VIDIOC_QBUF or
VIDIOC_DQBUF it is always cleared ...

Unfortunately, it seems that videobuf2 keeps it set after DQBUF. This
can be tested with vivid and dev_debug:

[257604.338082] video1: VIDIOC_DQBUF: 71:33:25.00260479 index=3,
type=vid-cap, flags=0x2004, field=none, sequence=163,
memory=userptr, bytesused=460800, offset/userptr=0x344b000,
length=460800

This patch forces FLAG_DONE to 0 after calling DQBUF.

Reported-by: Dimitrios Katsaros 
Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index ba3467468e55..9cfbb6e4bc28 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -654,6 +654,12 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, 
bool nonblocking)
 
ret = vb2_core_dqbuf(q, NULL, b, nonblocking);
 
+   /*
+*  After calling the VIDIOC_DQBUF V4L2_BUF_FLAG_DONE must be
+*  cleared.
+*/
+   b->flags &= ~V4L2_BUF_FLAG_DONE;
+
return ret;
 }
 EXPORT_SYMBOL_GPL(vb2_dqbuf);
-- 
2.8.1

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

[PATCH v2 3/4] vb2: Fix comment

The comment was referencing the wrong function.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/videobuf2-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 633fc1ab1d7a..ba6ab8b7311f 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1845,7 +1845,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
 * Make sure to call buf_finish for any queued buffers. Normally
 * that's done in dqbuf, but that's not going to happen when we
 * cancel the whole queue. Note: this code belongs here, not in
-* __vb2_dqbuf() since in vb2_internal_dqbuf() there is a critical
+* __vb2_dqbuf() since in vb2_core_dqbuf() there is a critical
 * call to __fill_user_buffer() after buf_finish(). That order can't
 * be changed, so we can't move the buf_finish() to __vb2_dqbuf().
 */
-- 
2.8.1

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

[PATCH v2 2/4] vb2: Merge vb2_internal_qbuf and vb2_qbuf

After all the code refactoring, vb2_internal_dqbuf is only called by
vb2_dqbuf.

Since the function it is very simple, there is no need to have
two functions.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 07d8b409ce05..ba3467468e55 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -427,7 +427,7 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb,
if (V4L2_TYPE_IS_OUTPUT(b->type)) {
/*
 * For output buffers mask out the timecode flag:
-* this will be handled later in vb2_internal_qbuf().
+* this will be handled later in vb2_qbuf().
 * The 'field' is valid metadata for this output buffer
 * and so that needs to be copied here.
 */
@@ -586,13 +586,6 @@ int vb2_create_bufs(struct vb2_queue *q, struct 
v4l2_create_buffers *create)
 }
 EXPORT_SYMBOL_GPL(vb2_create_bufs);
 
-static int vb2_internal_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
-{
-   int ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
-
-   return ret ? ret : vb2_core_qbuf(q, b->index, b);
-}
-
 /**
  * vb2_qbuf() - Queue a buffer from userspace
  * @q: videobuf2 queue
@@ -612,12 +605,15 @@ static int vb2_internal_qbuf(struct vb2_queue *q, struct 
v4l2_buffer *b)
  */
 int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
 {
+   int ret;
+
if (vb2_fileio_is_active(q)) {
dprintk(1, "file io in progress\n");
return -EBUSY;
}
 
-   return vb2_internal_qbuf(q, b);
+   ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
+   return ret ? ret : vb2_core_qbuf(q, b->index, b);
 }
 EXPORT_SYMBOL_GPL(vb2_qbuf);
 
-- 
2.8.1

--
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] v4l2-compliance: Check V4L2_BUF_FLAG_DONE

According to the doc, V4L2_BUF_FLAG_DONE is cleared after DQBUF and
QBUF:

V4L2_BUF_FLAG_DONE 0x0004  ... After calling the VIDIOC_QBUF or
VIDIOC_DQBUF it is always cleared ..

This patch implements this check.

Signed-off-by: Ricardo Ribalda Delgado 
---

Hello Hans!

Maybe you do not want to add this check to every dqbuf/qbuf in the code.
Please let me know to make a v2 of this patch.

Thanks!

 utils/v4l2-compliance/v4l2-test-buffers.cpp | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp 
b/utils/v4l2-compliance/v4l2-test-buffers.cpp
index 6c5ed5579f12..4d25870942bd 100644
--- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
+++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
@@ -719,7 +719,9 @@ static int captureBufs(struct node *node, const cv4l_queue 
,
fail_on_test(memcmp(_timecode(), 
_buf.timecode,

sizeof(orig_buf.timecode)));
}
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
fail_on_test(buf.qbuf(node));
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
if (--count == 0)
break;
}
@@ -746,7 +748,9 @@ static int captureBufs(struct node *node, const cv4l_queue 
,
fail_on_test(memcmp(_timecode(), 
_buf.timecode,

sizeof(orig_buf.timecode)));
}
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
fail_on_test(buf.qbuf(node));
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
}
if (use_poll)
fcntl(node->g_fd(), F_SETFL, fd_flags);
@@ -778,6 +782,7 @@ static int setupM2M(struct node *node, cv4l_queue )
 
fail_on_test(buf.querybuf(node, i));
fail_on_test(buf.qbuf(node));
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
}
if (v4l_type_is_video(q.g_type())) {
cv4l_fmt fmt(q.g_type());
@@ -828,6 +833,7 @@ static int bufferOutputErrorTest(struct node *node, const 
buffer _buf)
}
}
fail_on_test(buf.qbuf(node, false));
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
for (unsigned p = 0; p < buf.g_num_planes(); p++) {
fail_on_test(buf.g_bytesused(p) != buf.g_length(p));
fail_on_test(buf.g_data_offset(p));
@@ -864,6 +870,7 @@ static int setupMmap(struct node *node, cv4l_queue )
}
 
fail_on_test(buf.qbuf(node));
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
fail_on_test(!buf.qbuf(node));
fail_on_test(!buf.prepare_buf(node));
// Test with invalid buffer index
@@ -926,6 +933,7 @@ int testMmap(struct node *node, unsigned frame_count)
 
fail_on_test(buf.querybuf(node, i));
fail_on_test(buf.qbuf(node));
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
}
// calling STREAMOFF...
fail_on_test(node->streamoff(q.g_type()));
@@ -936,6 +944,7 @@ int testMmap(struct node *node, unsigned frame_count)
 
fail_on_test(buf.querybuf(node, i));
fail_on_test(buf.qbuf(node));
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
}
// Now request buffers again, freeing the old buffers.
// Good check for whether all the internal vb2 calls are in
@@ -1041,6 +1050,7 @@ static int setupUserPtr(struct node *node, cv4l_queue )
}
 
fail_on_test(buf.qbuf(node));
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
fail_on_test(buf.querybuf(node, i));
fail_on_test(buf.check(q, Queued, i));
}
@@ -1142,6 +1152,7 @@ static int setupDmaBuf(struct node *expbuf_node, struct 
node *node,
}
 
fail_on_test(buf.qbuf(node));
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
fail_on_test(buf.querybuf(node, i));
fail_on_test(buf.check(q, Queued, i));
}
@@ -1319,6 +1330,7 @@ static int testStreaming(struct node *node, unsigned 
frame_count)
if (alternate)
field ^= 1;
fail_on_test(node->qbuf(buf));
+   fail_on_test(buf.g_flags() & V4L2_BUF_FLAG_DONE);
}
fail_on_test(node->streamon());
 
@@ -1327,10 +1339,12 @@ static int testStreaming(struct node *node, unsigned 
frame_count)

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

2016-06-20 Thread Richard Cochran

On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote:
> The ALSA API provides support for 'audio' timestamps (playback/capture rate
> defined by audio subsystem) and 'system' timestamps (typically linked to
> TSC/ART) with one option to take synchronized timestamps should the hardware
> support them.

Thanks for the info.  I just skimmed Documentation/sound/alsa/timestamping.txt.

That is fairly new, only since v4.1.  Are then any apps in the wild
that I can look at?  AFAICT, OpenAVB, gstreamer, etc, don't use the
new API.

> The intent was that the 'audio' timestamps are translated to a shared time
> reference managed in userspace by gPTP, which in turn would define if
> (adaptive) audio sample rate conversion is needed. There is no support at
> the moment for a 'play_at' function in ALSA, only means to control a
> feedback loop.

Documentation/sound/alsa/timestamping.txt says:

  If supported in hardware, the absolute link time could also be used
  to define a precise start time (patches WIP)

Two questions:

1. Where are the patches?  (If some are coming, I would appreciate
   being on CC!)

2. Can you mention specific HW that would support this?

Thanks,
Richard
--
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 v4 2/9] [media] v4l2-core: Add VFL_TYPE_TOUCH_SENSOR

On 06/17/2016 04:16 PM, Nick Dyer wrote:
> Some touch controllers send out raw touch data in a similar way to a
> greyscale frame grabber. Add a new device type for these devices.
> 
> Use a new device prefix v4l-touch for these devices, to stop generic
> capture software from treating them as webcams.
> 
> Signed-off-by: Nick Dyer 
> ---
>  drivers/input/touchscreen/sur40.c|  4 ++--
>  drivers/media/v4l2-core/v4l2-dev.c   | 13 ++---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 15 ++-
>  include/media/v4l2-dev.h |  3 ++-
>  include/uapi/linux/videodev2.h   |  1 +

The new interface also needs to be documented in the media DocBook: section 4
describes all the interfaces, so a new one should be added here.

Sorry, just realized this.

I recommend that you grep for swradio:

git grep swradio Documentation/DocBook/media

and add a line there for v4l-touch as well. It also looks like a new interface
define is needed as a media type.

Regards,

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

Re: [PATCH v4 1/9] [media] Add signed 16-bit pixel format

2016-06-20 Thread Nick Dyer

Hi Hans-

On 20/06/2016 12:00, Hans Verkuil wrote:
> On 06/17/2016 04:16 PM, Nick Dyer wrote:
>> This will be used for output of raw touch delta data. This format is
>> used by Atmel maXTouch (atmel_mxt_ts) and also Synaptics RMI4.
>>
>> Signed-off-by: Nick Dyer 
>> ---
>>  Documentation/DocBook/media/v4l/pixfmt-ys16.xml | 79 
>> +
>>  Documentation/DocBook/media/v4l/pixfmt.xml  |  1 +
>>  drivers/media/v4l2-core/v4l2-ioctl.c|  1 +
>>  include/uapi/linux/videodev2.h  |  1 +
>>  4 files changed, 82 insertions(+)
>>  create mode 100644 Documentation/DocBook/media/v4l/pixfmt-ys16.xml
>>
>> diff --git a/Documentation/DocBook/media/v4l/pixfmt-ys16.xml 
>> b/Documentation/DocBook/media/v4l/pixfmt-ys16.xml
>> new file mode 100644
>> index 000..f92d65e
>> --- /dev/null
>> +++ b/Documentation/DocBook/media/v4l/pixfmt-ys16.xml
>> @@ -0,0 +1,79 @@
>> +
>> +  
>> +V4L2_PIX_FMT_YS16 ('YS16')
>> +
>> +  
>> +  
>> +V4L2_PIX_FMT_YS16
>> +Grey-scale image
>> +  
>> +  
>> +Description
>> +
>> +This is a signed grey-scale image with a depth of 16 bits per
>> +pixel. The most significant byte is stored at higher memory addresses
>> +(little-endian).
> 
> This is too generic. I think something like V4L2_TOUCH_FMT_DELTA_S16 is much
> more appropriate since this is neither luma (Y) data nor a picture in the
> classic sense. Since we already use V4L2_SDR_FMT_* defines for software 
> defined
> radio formats, it makes sense to use V4L2_TOUCH_FMT_* for these touch panel
> formats.

OK, that sounds sensible to me.

> The description can be based around what you told here:
> 
> https://lkml.org/lkml/2016/5/27/278
> 
> It's also important that you clearly state what the delta is against. A delta
> implies a difference from something, but what that something is isn't 
> explained.

To explain, in PCAP capacitive touch, a touch input is determined by
comparing the raw capacitance measurement to a no-touch reference (or
"baseline") measurement. Hence:

Delta = Raw - Reference

The reference measurement takes account of variations in the capacitance
characteristics across the nodes of the touch sensor, for example
manufacturing irregularities or edge effects.

I'll put something about this in the docs.

> I'm sorry for being pedantic about this, but it should be possible to make an
> application that can correctly interpret this data based on this format
> description. Otherwise there would be no point in documenting this...

No problem: thanks for your clear feedback.

--
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: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

2016-06-20 Thread Henrik Austad

On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote:
> 
> >Presentation time is either set by
> >a) Local sound card performing capture (in which case it will be 'capture
> >   time')
> >b) Local media application sending a stream accross the network
> >   (time when the sample should be played out remotely)
> >c) Remote media application streaming data *to* host, in which case it will
> >   be local presentation time on local  soundcard
> >
> >>This value is dominant to the number of events included in an IEC 61883-1
> >>packet. If this TSN subsystem decides it, most of these items don't need
> >>to be in ALSA.
> >
> >Not sure if I understand this correctly.
> >
> >TSN should have a reference to the timing-domain of each *local*
> >sound-device (for local capture or playback) as well as the shared
> >time-reference provided by gPTP.
> >
> >Unless an End-station acts as GrandMaster for the gPTP-domain, time set
> >forth by gPTP is inmutable and cannot be adjusted. It follows that the
> >sample-frequency of the local audio-devices must be adjusted, or the
> >audio-streams to/from said devices must be resampled.
> 
> The ALSA API provides support for 'audio' timestamps
> (playback/capture rate defined by audio subsystem) and 'system'
> timestamps (typically linked to TSC/ART) with one option to take
> synchronized timestamps should the hardware support them.

Ok, this sounds promising, and very much in line with what AVB would need.

> The intent was that the 'audio' timestamps are translated to a
> shared time reference managed in userspace by gPTP, which in turn
> would define if (adaptive) audio sample rate conversion is needed.
> There is no support at the moment for a 'play_at' function in ALSA,
> only means to control a feedback loop.

Ok, I understand that the 'play_at' is difficult to obtain, but it sounds 
like it is doable to achieve something useful.

Looks like I will be looking into what to put in the .trigger-handler in 
the ALSA shim and experimenting with this to see how it make sense to 
connect it from the TSN-stream.

Thanks!

-- 
Henrik Austad


signature.asc
Description: Digital signature

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

2016-06-20 Thread Pierre-Louis Bossart




Presentation time is either set by
a) Local sound card performing capture (in which case it will be 'capture
   time')
b) Local media application sending a stream accross the network
   (time when the sample should be played out remotely)
c) Remote media application streaming data *to* host, in which case it will
   be local presentation time on local  soundcard


This value is dominant to the number of events included in an IEC 61883-1
packet. If this TSN subsystem decides it, most of these items don't need
to be in ALSA.


Not sure if I understand this correctly.

TSN should have a reference to the timing-domain of each *local*
sound-device (for local capture or playback) as well as the shared
time-reference provided by gPTP.

Unless an End-station acts as GrandMaster for the gPTP-domain, time set
forth by gPTP is inmutable and cannot be adjusted. It follows that the
sample-frequency of the local audio-devices must be adjusted, or the
audio-streams to/from said devices must be resampled.


The ALSA API provides support for 'audio' timestamps (playback/capture 
rate defined by audio subsystem) and 'system' timestamps (typically 
linked to TSC/ART) with one option to take synchronized timestamps 
should the hardware support them.
The intent was that the 'audio' timestamps are translated to a shared 
time reference managed in userspace by gPTP, which in turn would define 
if (adaptive) audio sample rate conversion is needed. There is no 
support at the moment for a 'play_at' function in ALSA, only means to 
control a feedback loop.






--
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 v4 1/9] [media] Add signed 16-bit pixel format

On 06/17/2016 04:16 PM, Nick Dyer wrote:
> This will be used for output of raw touch delta data. This format is
> used by Atmel maXTouch (atmel_mxt_ts) and also Synaptics RMI4.
> 
> Signed-off-by: Nick Dyer 
> ---
>  Documentation/DocBook/media/v4l/pixfmt-ys16.xml | 79 
> +
>  Documentation/DocBook/media/v4l/pixfmt.xml  |  1 +
>  drivers/media/v4l2-core/v4l2-ioctl.c|  1 +
>  include/uapi/linux/videodev2.h  |  1 +
>  4 files changed, 82 insertions(+)
>  create mode 100644 Documentation/DocBook/media/v4l/pixfmt-ys16.xml
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-ys16.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-ys16.xml
> new file mode 100644
> index 000..f92d65e
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/pixfmt-ys16.xml
> @@ -0,0 +1,79 @@
> +
> +  
> +V4L2_PIX_FMT_YS16 ('YS16')
> +
> +  
> +  
> +V4L2_PIX_FMT_YS16
> +Grey-scale image
> +  
> +  
> +Description
> +
> +This is a signed grey-scale image with a depth of 16 bits per
> +pixel. The most significant byte is stored at higher memory addresses
> +(little-endian).

This is too generic. I think something like V4L2_TOUCH_FMT_DELTA_S16 is much
more appropriate since this is neither luma (Y) data nor a picture in the
classic sense. Since we already use V4L2_SDR_FMT_* defines for software defined
radio formats, it makes sense to use V4L2_TOUCH_FMT_* for these touch panel
formats.

The description can be based around what you told here:

https://lkml.org/lkml/2016/5/27/278

It's also important that you clearly state what the delta is against. A delta
implies a difference from something, but what that something is isn't explained.

I'm sorry for being pedantic about this, but it should be possible to make an
application that can correctly interpret this data based on this format
description. Otherwise there would be no point in documenting this...

Regards,

Hans

> +
> +
> +  V4L2_PIX_FMT_YS16 4  4
> +pixel image
> +
> +  
> + Byte Order.
> + Each cell is one byte.
> +   
> + 
> +   
> +   
> + 
> +   start+0:
> +   Y'00low
> +   Y'00high
> +   Y'01low
> +   Y'01high
> +   Y'02low
> +   Y'02high
> +   Y'03low
> +   Y'03high
> + 
> + 
> +   start+8:
> +   Y'10low
> +   Y'10high
> +   Y'11low
> +   Y'11high
> +   Y'12low
> +   Y'12high
> +   Y'13low
> +   Y'13high
> + 
> + 
> +   start+16:
> +   Y'20low
> +   Y'20high
> +   Y'21low
> +   Y'21high
> +   Y'22low
> +   Y'22high
> +   Y'23low
> +   Y'23high
> + 
> + 
> +   start+24:
> +   Y'30low
> +   Y'30high
> +   Y'31low
> +   Y'31high
> +   Y'32low
> +   Y'32high
> +   Y'33low
> +   Y'33high
> + 
> +   
> + 
> +   
> + 
> +  
> +
> +  
> +
> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
> b/Documentation/DocBook/media/v4l/pixfmt.xml
> index 5a08aee..f3e3e6d 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> @@ -1619,6 +1619,7 @@ information.
>  
>  
>  
> +
>  
>  
>  
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 28e5be2..ecf7e0b 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1164,6 +1164,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>   case V4L2_PIX_FMT_Y10:  descr = "10-bit Greyscale"; break;
>   case V4L2_PIX_FMT_Y12:  descr = "12-bit Greyscale"; break;
>   case V4L2_PIX_FMT_Y16:  descr = "16-bit Greyscale"; break;
> + case V4L2_PIX_FMT_YS16: descr = "16-bit Greyscale (Signed)"; 
> break;
>   case V4L2_PIX_FMT_Y16_BE:   descr = "16-bit Greyscale BE"; break;
>   case V4L2_PIX_FMT_Y10BPACK: descr = "10-bit Greyscale (Packed)"; 
> break;
>   case V4L2_PIX_FMT_PAL8: descr = "8-bit Palette"; break;
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 8f95191..e0125cf 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -493,6 +493,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12  
> Greyscale */
>  #define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16  
> Greyscale */
>  #define V4L2_PIX_FMT_Y16_BE  v4l2_fourcc_be('Y', '1', '6', ' ')

Re: [19/38] ARM: dts: imx6-sabrelite: add video capture ports and connections

2016-06-20 Thread Jack Mitchell




On 20/06/16 11:16, Gary Bisson wrote:

Jack, All,

On Mon, Jun 20, 2016 at 10:44:44AM +0100, Jack Mitchell wrote:



I've tried that patch have a some comments:
- When applied, no capture shows up any more, instead I have two m2m
  v4l2 devices [1].
- OV5640 Mipi is assigned the same address as OV5642, therefore both


Yes, I only have one device attached in my scenario.


Thanks for confirming.


  can't work at the same time right now. There's a register in the
  camera that allows to modify its I2C address, see this patch [2].
- How is the mclk working in this patch? It should be using the PWM3


As mentioned I have an eCon sensor board [1] which generates it's own clock
on the board and as such I don't need the PWM signal, just the two GPIOs.


Oh ok, thanks I didn't this sensor board was different than ours [1].

But in your patch, you specifically disable pwm3, what's the reason for
it?


Yes, it uses the GPIO on the PWM3 pin (beats me why...) so I had to 
specifically disable it to stop the pin muxing clash.





  output to generate a ~22MHz clock. I would expect the use of a
  pwm-clock node [3].

Also another remark on both OV5642 and OV5640 patches, is it recommended
to use 0x8000 pin muxing value? This leaves it to the bootloader to


I also wondered about this, but didn't know if the pinmux driver did this
based on the define name? I tried it both ways and it worked so I just left
it as it was.


Actually my phrasing is wrong, the muxing is ok. Yes depending on the
name a pin will be muxed to one function or another. The problem is the
pad configuration (pull-up, pull-down etc..). I am not surprised that it
works, because the bootloader should properly set those. But it would be
safer IMO not to rely on it.


Ah ok, makes sense.



Regards,
Gary

[1] https://boundarydevices.com/product/nit6x_5mp_mipi/


--
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] vb2: V4L2_BUF_FLAG_DONE is set after DQBUF

On 06/20/2016 12:12 PM, Ricardo Ribalda Delgado wrote:
> Good catch :)
> 
> I will prepare the new version. Btw, can I also merge
> vb2_internal_dqbuf and vb2_dqbuf in one function? Seems a bit
> overkilled that split.

No, that's not possible. vb2_internal_dqbuf is used in the threading
code to implement read() and vb2_fileio_is_active() returns true in that
case.

> 
> Regarding v42l_compliance... I can take care of that if you dare :)

It would be great if you can add a test for this.

Regards,

Hans

> 
> Best regards!
> 
> On Mon, Jun 20, 2016 at 11:53 AM, Hans Verkuil  wrote:
>> On 06/20/2016 11:01 AM, Ricardo Ribalda Delgado wrote:
>>> According to the doc, V4L2_BUF_FLAG_DONE is cleared after DQBUF:
>>>
>>> V4L2_BUF_FLAG_DONE 0x0004  ... After calling the VIDIOC_QBUF or
>>> VIDIOC_DQBUF it is always cleared ...
>>>
>>> Unfortunately, it seems that videobuf2 keeps it set after DQBUF. This
>>> can be tested with vivid and dev_debug:
>>>
>>> [257604.338082] video1: VIDIOC_DQBUF: 71:33:25.00260479 index=3,
>>> type=vid-cap, flags=0x2004, field=none, sequence=163,
>>> memory=userptr, bytesused=460800, offset/userptr=0x344b000,
>>> length=460800
>>>
>>> This patch changes the order when fill_user_buffer() is called,
>>> to follow the documentation.
>>>
>>> Reported-by: Dimitrios Katsaros 
>>> Signed-off-by: Ricardo Ribalda Delgado 
>>
>> Sorry, this won't work. Calling __vb2_dqbuf will overwrite the state
>> VB2_BUF_STATE_ERROR and so the V4L2_BUF_FLAG_ERROR flag will never be
>> set. The same is true for the last 'if' in the __fill_v4l2_buffer()
>> function.
>>
>> I think it might be better to keep this code and instead change the
>> vb2_internal_dqbuf function to just clear the DONE flag after calling
>> vb2_core_dqbuf.
>>
>> It would be nice to have a v4l2_compliance check for this as well.
>>
>> Regards,
>>
>> Hans
>>
>>> ---
>>>  drivers/media/v4l2-core/videobuf2-core.c | 8 
>>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
>>> b/drivers/media/v4l2-core/videobuf2-core.c
>>> index 633fc1ab1d7a..63981f28075e 100644
>>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>>> @@ -1771,10 +1771,6 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int 
>>> *pindex, void *pb,
>>>   if (pindex)
>>>   *pindex = vb->index;
>>>
>>> - /* Fill buffer information for the userspace */
>>> - if (pb)
>>> - call_void_bufop(q, fill_user_buffer, vb, pb);
>>> -
>>>   /* Remove from videobuf queue */
>>>   list_del(>queued_entry);
>>>   q->queued_count--;
>>> @@ -1784,6 +1780,10 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int 
>>> *pindex, void *pb,
>>>   /* go back to dequeued state */
>>>   __vb2_dqbuf(vb);
>>>
>>> + /* Fill buffer information for the userspace */
>>> + if (pb)
>>> + call_void_bufop(q, fill_user_buffer, vb, pb);
>>> +
>>>   dprintk(1, "dqbuf of buffer %d, with state %d\n",
>>>   vb->index, vb->state);
>>>
>>>
> 
> 
> 
--
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: [19/38] ARM: dts: imx6-sabrelite: add video capture ports and connections

2016-06-20 Thread Gary Bisson

Jack, All,

On Mon, Jun 20, 2016 at 10:44:44AM +0100, Jack Mitchell wrote:
> 
> > I've tried that patch have a some comments:
> > - When applied, no capture shows up any more, instead I have two m2m
> >   v4l2 devices [1].
> > - OV5640 Mipi is assigned the same address as OV5642, therefore both
> 
> Yes, I only have one device attached in my scenario.

Thanks for confirming.

> >   can't work at the same time right now. There's a register in the
> >   camera that allows to modify its I2C address, see this patch [2].
> > - How is the mclk working in this patch? It should be using the PWM3
> 
> As mentioned I have an eCon sensor board [1] which generates it's own clock
> on the board and as such I don't need the PWM signal, just the two GPIOs.

Oh ok, thanks I didn't this sensor board was different than ours [1].

But in your patch, you specifically disable pwm3, what's the reason for
it?

> >   output to generate a ~22MHz clock. I would expect the use of a
> >   pwm-clock node [3].
> > 
> > Also another remark on both OV5642 and OV5640 patches, is it recommended
> > to use 0x8000 pin muxing value? This leaves it to the bootloader to
> 
> I also wondered about this, but didn't know if the pinmux driver did this
> based on the define name? I tried it both ways and it worked so I just left
> it as it was.

Actually my phrasing is wrong, the muxing is ok. Yes depending on the
name a pin will be muxed to one function or another. The problem is the
pad configuration (pull-up, pull-down etc..). I am not surprised that it
works, because the bootloader should properly set those. But it would be
safer IMO not to rely on it.

Regards,
Gary

[1] https://boundarydevices.com/product/nit6x_5mp_mipi/
--
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: [19/38] ARM: dts: imx6-sabrelite: add video capture ports and connections

2016-06-20 Thread Jack Mitchell

On 20/06/16 10:33, Gary Bisson wrote:

Steve, Jack, All,

On Fri, Jun 17, 2016 at 12:01:41PM -0700, Steve Longerbeam wrote:

On 06/17/2016 08:18 AM, Gary Bisson wrote:

Steve, All,

On Thu, Jun 16, 2016 at 10:32:31AM +0200, Gary Bisson wrote:

Steve, All,

On Tue, Jun 14, 2016 at 03:49:15PM -0700, Steve Longerbeam wrote:

Defines the host video capture device node and an OV5642 camera sensor
node on i2c2. The host capture device connects to the OV5642 via the
parallel-bus mux input on the ipu1_csi0_mux.

Note there is a pin conflict with GPIO6. This pin functions as a power
input pin to the OV5642, but ENET requires it to wake-up the ARM cores
on normal RX and TX packet done events (see 6261c4c8). So by default,
capture is disabled, enable by uncommenting __OV5642_CAPTURE__ macro.
Ethernet will still work just not quite as well.

Actually the following patch fixes this issue and has already been
applied on Shawn's tree:
https://patchwork.kernel.org/patch/9153523/

Also, this follow-up patch declared the HW workaround for SabreLite:
https://patchwork.kernel.org/patch/9153525/

So ideally, once those two patches land on your base tree, you could get
rid of the #define and remove the HW workaround declaration.

Finally, I'll test the series on Sabre-Lite this week.

I've applied this series on top of Shawn tree (for-next branch) in order
not to worry about the GPIO6 workaround.

Although the camera seems to get enumerated properly, I can't seem to
get anything from it. See log:
http://pastebin.com/xnw1ujUq

Hi Gary, the driver does not implement vidioc_cropcap, it has
switched to the new selection APIs and v4l2src should be using
vidioc_g_selection instead of vidioc_cropcap.

I confirm this was the issue, your patch fixes it.

In your cover letter, you said that you have not run through
v4l2-compliance. How have you tested the capture?

I use v4l2-ctl, and have used v4l2src in the past, but that was before
switching to the selection APIs. Try the attached hack that adds
vidioc_cropcap back in, and see how far you get on SabreLite with
v4l2src. I tried the following on SabreAuto:

gst-launch-1.0 v4l2src io_mode=4 !
"video/x-raw,format=RGB16,width=640,height=480" ! fbdevsink

I confirm that works with OV5642 on SabreLite:
Tested-by: Gary Bisson

Also, why isn't the OV5640 MIPI camera declared on the SabreLite device
tree?

See Jack Mitchell's patch at http://ix.io/TTg. Thanks Jack! I will work on
incorporating it.

Hi Gary,

I've tried that patch have a some comments:
- When applied, no capture shows up any more, instead I have two m2m
v4l2 devices [1].
- OV5640 Mipi is assigned the same address as OV5642, therefore both

Yes, I only have one device attached in my scenario.

can't work at the same time right now. There's a register in the
camera that allows to modify its I2C address, see this patch [2].
- How is the mclk working in this patch? It should be using the PWM3

As mentioned I have an eCon sensor board [1] which generates it's own
clock on the board and as such I don't need the PWM signal, just the two
GPIOs.

output to generate a ~22MHz clock. I would expect the use of a
pwm-clock node [3].

Also another remark on both OV5642 and OV5640 patches, is it recommended
to use 0x8000 pin muxing value? This leaves it to the bootloader to

I also wondered about this, but didn't know if the pinmux driver did
this based on the define name? I tried it both ways and it worked so I
just left it as it was.

Cheers,
Jack.

[1] https://www.e-consystems.com/iMX6-MIPI-Camera-Board.asp

properly setup the I/O. It sounds safer to properly set them up in the
device tree in my opinion in order not to be dependent on the bootloader.

All the above remarks said, thanks for this work on i.MX camera support,
that feature will be highly appreciated.

Regards,
Gary

[1] http://pastebin.com/i5MrhB1h
[2] https://github.com/boundarydevices/linux-imx6/commit/f915806d
[3]
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/clock/pwm-clock.txt
--
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] vb2: V4L2_BUF_FLAG_DONE is set after DQBUF

Good catch :)

I will prepare the new version. Btw, can I also merge
vb2_internal_dqbuf and vb2_dqbuf in one function? Seems a bit
overkilled that split.

Regarding v42l_compliance... I can take care of that if you dare :)

Best regards!

On Mon, Jun 20, 2016 at 11:53 AM, Hans Verkuil  wrote:
> On 06/20/2016 11:01 AM, Ricardo Ribalda Delgado wrote:
>> According to the doc, V4L2_BUF_FLAG_DONE is cleared after DQBUF:
>>
>> V4L2_BUF_FLAG_DONE 0x0004  ... After calling the VIDIOC_QBUF or
>> VIDIOC_DQBUF it is always cleared ...
>>
>> Unfortunately, it seems that videobuf2 keeps it set after DQBUF. This
>> can be tested with vivid and dev_debug:
>>
>> [257604.338082] video1: VIDIOC_DQBUF: 71:33:25.00260479 index=3,
>> type=vid-cap, flags=0x2004, field=none, sequence=163,
>> memory=userptr, bytesused=460800, offset/userptr=0x344b000,
>> length=460800
>>
>> This patch changes the order when fill_user_buffer() is called,
>> to follow the documentation.
>>
>> Reported-by: Dimitrios Katsaros 
>> Signed-off-by: Ricardo Ribalda Delgado 
>
> Sorry, this won't work. Calling __vb2_dqbuf will overwrite the state
> VB2_BUF_STATE_ERROR and so the V4L2_BUF_FLAG_ERROR flag will never be
> set. The same is true for the last 'if' in the __fill_v4l2_buffer()
> function.
>
> I think it might be better to keep this code and instead change the
> vb2_internal_dqbuf function to just clear the DONE flag after calling
> vb2_core_dqbuf.
>
> It would be nice to have a v4l2_compliance check for this as well.
>
> Regards,
>
> Hans
>
>> ---
>>  drivers/media/v4l2-core/videobuf2-core.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
>> b/drivers/media/v4l2-core/videobuf2-core.c
>> index 633fc1ab1d7a..63981f28075e 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> @@ -1771,10 +1771,6 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int 
>> *pindex, void *pb,
>>   if (pindex)
>>   *pindex = vb->index;
>>
>> - /* Fill buffer information for the userspace */
>> - if (pb)
>> - call_void_bufop(q, fill_user_buffer, vb, pb);
>> -
>>   /* Remove from videobuf queue */
>>   list_del(>queued_entry);
>>   q->queued_count--;
>> @@ -1784,6 +1780,10 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int 
>> *pindex, void *pb,
>>   /* go back to dequeued state */
>>   __vb2_dqbuf(vb);
>>
>> + /* Fill buffer information for the userspace */
>> + if (pb)
>> + call_void_bufop(q, fill_user_buffer, vb, pb);
>> +
>>   dprintk(1, "dqbuf of buffer %d, with state %d\n",
>>   vb->index, vb->state);
>>
>>



-- 
Ricardo Ribalda
--
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] vb2: V4L2_BUF_FLAG_DONE is set after DQBUF

On 06/20/2016 11:01 AM, Ricardo Ribalda Delgado wrote:
> According to the doc, V4L2_BUF_FLAG_DONE is cleared after DQBUF:
> 
> V4L2_BUF_FLAG_DONE 0x0004  ... After calling the VIDIOC_QBUF or
> VIDIOC_DQBUF it is always cleared ...
> 
> Unfortunately, it seems that videobuf2 keeps it set after DQBUF. This
> can be tested with vivid and dev_debug:
> 
> [257604.338082] video1: VIDIOC_DQBUF: 71:33:25.00260479 index=3,
> type=vid-cap, flags=0x2004, field=none, sequence=163,
> memory=userptr, bytesused=460800, offset/userptr=0x344b000,
> length=460800
> 
> This patch changes the order when fill_user_buffer() is called,
> to follow the documentation.
> 
> Reported-by: Dimitrios Katsaros 
> Signed-off-by: Ricardo Ribalda Delgado 

Sorry, this won't work. Calling __vb2_dqbuf will overwrite the state
VB2_BUF_STATE_ERROR and so the V4L2_BUF_FLAG_ERROR flag will never be
set. The same is true for the last 'if' in the __fill_v4l2_buffer()
function.

I think it might be better to keep this code and instead change the
vb2_internal_dqbuf function to just clear the DONE flag after calling
vb2_core_dqbuf.

It would be nice to have a v4l2_compliance check for this as well.

Regards,

Hans

> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 633fc1ab1d7a..63981f28075e 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -1771,10 +1771,6 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int 
> *pindex, void *pb,
>   if (pindex)
>   *pindex = vb->index;
>  
> - /* Fill buffer information for the userspace */
> - if (pb)
> - call_void_bufop(q, fill_user_buffer, vb, pb);
> -
>   /* Remove from videobuf queue */
>   list_del(>queued_entry);
>   q->queued_count--;
> @@ -1784,6 +1780,10 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int 
> *pindex, void *pb,
>   /* go back to dequeued state */
>   __vb2_dqbuf(vb);
>  
> + /* Fill buffer information for the userspace */
> + if (pb)
> + call_void_bufop(q, fill_user_buffer, vb, pb);
> +
>   dprintk(1, "dqbuf of buffer %d, with state %d\n",
>   vb->index, vb->state);
>  
> 
--
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: [19/38] ARM: dts: imx6-sabrelite: add video capture ports and connections

2016-06-20 Thread Gary Bisson

Steve, Jack, All,

On Fri, Jun 17, 2016 at 12:01:41PM -0700, Steve Longerbeam wrote:
> 
> On 06/17/2016 08:18 AM, Gary Bisson wrote:
> > Steve, All,
> > 
> > On Thu, Jun 16, 2016 at 10:32:31AM +0200, Gary Bisson wrote:
> > > Steve, All,
> > > 
> > > On Tue, Jun 14, 2016 at 03:49:15PM -0700, Steve Longerbeam wrote:
> > > > Defines the host video capture device node and an OV5642 camera sensor
> > > > node on i2c2. The host capture device connects to the OV5642 via the
> > > > parallel-bus mux input on the ipu1_csi0_mux.
> > > > 
> > > > Note there is a pin conflict with GPIO6. This pin functions as a power
> > > > input pin to the OV5642, but ENET requires it to wake-up the ARM cores
> > > > on normal RX and TX packet done events (see 6261c4c8). So by default,
> > > > capture is disabled, enable by uncommenting __OV5642_CAPTURE__ macro.
> > > > Ethernet will still work just not quite as well.
> > > Actually the following patch fixes this issue and has already been
> > > applied on Shawn's tree:
> > > https://patchwork.kernel.org/patch/9153523/
> > > 
> > > Also, this follow-up patch declared the HW workaround for SabreLite:
> > > https://patchwork.kernel.org/patch/9153525/
> > > 
> > > So ideally, once those two patches land on your base tree, you could get
> > > rid of the #define and remove the HW workaround declaration.
> > > 
> > > Finally, I'll test the series on Sabre-Lite this week.
> > I've applied this series on top of Shawn tree (for-next branch) in order
> > not to worry about the GPIO6 workaround.
> > 
> > Although the camera seems to get enumerated properly, I can't seem to
> > get anything from it. See log:
> > http://pastebin.com/xnw1ujUq
> 
> Hi Gary, the driver does not implement vidioc_cropcap, it has
> switched to the new selection APIs and v4l2src should be using
> vidioc_g_selection instead of vidioc_cropcap.

I confirm this was the issue, your patch fixes it.

> > In your cover letter, you said that you have not run through
> > v4l2-compliance. How have you tested the capture?
> 
> I use v4l2-ctl, and have used v4l2src in the past, but that was before
> switching to the selection APIs. Try the attached hack that adds
> vidioc_cropcap back in, and see how far you get on SabreLite with
> v4l2src. I tried  the following on SabreAuto:
> 
> gst-launch-1.0 v4l2src io_mode=4 !
> "video/x-raw,format=RGB16,width=640,height=480" ! fbdevsink

I confirm that works with OV5642 on SabreLite:
Tested-by: Gary Bisson 

> > Also, why isn't the OV5640 MIPI camera declared on the SabreLite device
> > tree?
> 
> See Jack Mitchell's patch at http://ix.io/TTg. Thanks Jack! I will work on
> incorporating it.

I've tried that patch have a some comments:
- When applied, no capture shows up any more, instead I have two m2m
  v4l2 devices [1].
- OV5640 Mipi is assigned the same address as OV5642, therefore both
  can't work at the same time right now. There's a register in the
  camera that allows to modify its I2C address, see this patch [2].
- How is the mclk working in this patch? It should be using the PWM3
  output to generate a ~22MHz clock. I would expect the use of a
  pwm-clock node [3].

Also another remark on both OV5642 and OV5640 patches, is it recommended
to use 0x8000 pin muxing value? This leaves it to the bootloader to
properly setup the I/O. It sounds safer to properly set them up in the
device tree in my opinion in order not to be dependent on the bootloader.

All the above remarks said, thanks for this work on i.MX camera support,
that feature will be highly appreciated.

Regards,
Gary

[1] http://pastebin.com/i5MrhB1h
[2] https://github.com/boundarydevices/linux-imx6/commit/f915806d
[3] 
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/clock/pwm-clock.txt
--
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] vb2: V4L2_BUF_FLAG_DONE is set after DQBUF