cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Fri Sep 14 04:00:17 CEST 2018
media-tree git hash:78cf8c842c111df656c63b5d04997ea4e40ef26a
media_build git hash:   73a39eb63460f29cbe9bc056ae0b05ce9e813b11
v4l-utils git hash: 72e6d7e7064c756baa1c53f1c80e50712c1f7af5
edid-decode git hash:   b2da1516df3cc2756bfe8d1fa06d7bf2562ba1f4
gcc version:i686-linux-gcc (GCC) 8.2.0
sparse version: 0.5.2
smatch version: 0.5.1
host hardware:  x86_64
host os:4.17.0-3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.101-i686: WARNINGS
linux-3.0.101-x86_64: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.102-i686: WARNINGS
linux-3.2.102-x86_64: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.113-i686: WARNINGS
linux-3.4.113-x86_64: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.10-i686: WARNINGS
linux-3.7.10-x86_64: WARNINGS
linux-3.8.13-i686: WARNINGS
linux-3.8.13-x86_64: WARNINGS
linux-3.9.11-i686: WARNINGS
linux-3.9.11-x86_64: WARNINGS
linux-3.10.108-i686: WARNINGS
linux-3.10.108-x86_64: WARNINGS
linux-3.11.10-i686: WARNINGS
linux-3.11.10-x86_64: WARNINGS
linux-3.12.74-i686: WARNINGS
linux-3.12.74-x86_64: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.79-i686: WARNINGS
linux-3.14.79-x86_64: WARNINGS
linux-3.15.10-i686: WARNINGS
linux-3.15.10-x86_64: WARNINGS
linux-3.16.57-i686: WARNINGS
linux-3.16.57-x86_64: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.119-i686: OK
linux-3.18.119-x86_64: OK
linux-3.19.8-i686: WARNINGS
linux-3.19.8-x86_64: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.52-i686: WARNINGS
linux-4.1.52-x86_64: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.152-i686: OK
linux-4.4.152-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.124-i686: OK
linux-4.9.124-x86_64: OK
linux-4.10.17-i686: OK
linux-4.10.17-x86_64: OK
linux-4.11.12-i686: OK
linux-4.11.12-x86_64: OK
linux-4.12.14-i686: OK
linux-4.12.14-x86_64: OK
linux-4.13.16-i686: OK
linux-4.13.16-x86_64: OK
linux-4.14.67-i686: OK
linux-4.14.67-x86_64: OK
linux-4.15.18-i686: OK
linux-4.15.18-x86_64: OK
linux-4.16.18-i686: OK
linux-4.16.18-x86_64: OK
linux-4.17.19-i686: OK
linux-4.17.19-x86_64: OK
linux-4.18.5-i686: OK
linux-4.18.5-x86_64: OK
linux-4.19-rc1-i686: OK
linux-4.19-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS

Logs weren't copied as they are too large (2368 kB)

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

[PATCH -next] media: dvb-usb-v2/gl861: Use kmemdup rather than duplicating its implementation in gl861_i2c_write_ex

[YueHaibing]

Use kmemdup rather than duplicating its implementation

Signed-off-by: YueHaibing 
---
 drivers/media/usb/dvb-usb-v2/gl861.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/gl861.c 
b/drivers/media/usb/dvb-usb-v2/gl861.c
index 0559417..80fed44 100644
--- a/drivers/media/usb/dvb-usb-v2/gl861.c
+++ b/drivers/media/usb/dvb-usb-v2/gl861.c
@@ -200,11 +200,10 @@ struct friio_config {
u8 *buf;
int ret;
 
-   buf = kmalloc(wlen, GFP_KERNEL);
+   buf = kmemdup(wbuf, wlen, GFP_KERNEL);
if (!buf)
return -ENOMEM;
 
-   memcpy(buf, wbuf, wlen);
ret = usb_control_msg(d->udev, usb_sndctrlpipe(d->udev, 0),
 GL861_REQ_I2C_RAW, GL861_WRITE,
 addr << (8 + 1), 0x0100, buf, wlen, 2000);

Re: RFC: stop support for 2.6 kernel in the daily build

[Jasmin J.]

Hello Hans!

> I'm inclined to drop support for 2.6 altogether.
RHEL 6 is on kernel 2.6.32, which we do not support since long time.
Most other distributions switched to 3.x also years in the past.
So lets drop 2.6.x then!

As you know I maintain a media-tree DKMS package and this should work for older
Kernels. I personally have a VDR based on Ubuntu 14.04 system with the original
3.13 Kernel. So this is the minimum version for me.

When you want to support RHEL 7, then the version goes down to 3.10.

> Whether we should also drop support for 3.0-3.9 is another matter.
We can decide now to remove those versions also and wait if people are
complaining. At least this is what I would do.

I would suggest to remove all kernels prior to 3.10 from your build system and
wait what people will say over the next months.

BR,
   Jasmin

[PATCH] tvp5150: avoid going past array on v4l2_querymenu()

[Mauro Carvalho Chehab]

The parameters of v4l2_ctrl_new_std_menu_items() are tricky: instead of
the number of possible values, it requires the number of the maximum
value. In other words, the ARRAY_SIZE() value should be decremented,
otherwise it will go past the array bounds, as warned by KASAN:

[  279.839688] BUG: KASAN: global-out-of-bounds in v4l2_querymenu+0x10d/0x180 
[videodev]
[  279.839709] Read of size 8 at addr c10a4cb0 by task 
v4l2-compliance/16676

[  279.839736] CPU: 1 PID: 16676 Comm: v4l2-compliance Not tainted 4.18.0-rc2+ 
#120
[  279.839741] Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
[  279.839743] Call Trace:
[  279.839758]  dump_stack+0x71/0xab
[  279.839807]  ? v4l2_querymenu+0x10d/0x180 [videodev]
[  279.839817]  print_address_description+0x1c9/0x270
[  279.839863]  ? v4l2_querymenu+0x10d/0x180 [videodev]
[  279.839871]  kasan_report+0x237/0x360
[  279.839918]  v4l2_querymenu+0x10d/0x180 [videodev]
[  279.839964]  __video_do_ioctl+0x2c8/0x590 [videodev]
[  279.840011]  ? copy_overflow+0x20/0x20 [videodev]
[  279.840020]  ? avc_ss_reset+0xa0/0xa0
[  279.840028]  ? check_stack_object+0x21/0x60
[  279.840036]  ? __check_object_size+0xe7/0x240
[  279.840080]  video_usercopy+0xed/0x730 [videodev]
[  279.840123]  ? copy_overflow+0x20/0x20 [videodev]
[  279.840167]  ? v4l_enumstd+0x40/0x40 [videodev]
[  279.840177]  ? __handle_mm_fault+0x9f9/0x1ba0
[  279.840186]  ? __pmd_alloc+0x2c0/0x2c0
[  279.840193]  ? __vfs_write+0xb6/0x350
[  279.840200]  ? kernel_read+0xa0/0xa0
[  279.840244]  ? video_usercopy+0x730/0x730 [videodev]
[  279.840284]  v4l2_ioctl+0xa1/0xb0 [videodev]
[  279.840295]  do_vfs_ioctl+0x117/0x8a0
[  279.840303]  ? selinux_file_ioctl+0x211/0x2f0
[  279.840313]  ? ioctl_preallocate+0x120/0x120
[  279.840319]  ? selinux_capable+0x20/0x20
[  279.840332]  ksys_ioctl+0x70/0x80
[  279.840342]  __x64_sys_ioctl+0x3d/0x50
[  279.840351]  do_syscall_64+0x6d/0x1c0
[  279.840361]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  279.840367] RIP: 0033:0x7fdfb46275d7
[  279.840369] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48
[  279.840474] RSP: 002b:7ffee1179038 EFLAGS: 0202 ORIG_RAX: 
0010
[  279.840483] RAX: ffda RBX: 7ffee1179180 RCX: 7fdfb46275d7
[  279.840488] RDX: 7ffee11790c0 RSI: c02c5625 RDI: 0003
[  279.840493] RBP: 0002 R08: 0020 R09: 009f0902
[  279.840497] R10:  R11: 0202 R12: 7ffee117a5a0
[  279.840501] R13: 7ffee11790c0 R14: 0002 R15: 

[  279.840515] The buggy address belongs to the variable:
[  279.840535]  tvp5150_test_patterns+0x10/0xe360 [tvp5150]

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/tvp5150.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index b5d44c25d1da..133073518744 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1633,7 +1633,7 @@ static int tvp5150_probe(struct i2c_client *c,
2700, 1, 2700);
v4l2_ctrl_new_std_menu_items(>hdl, _ctrl_ops,
 V4L2_CID_TEST_PATTERN,
-ARRAY_SIZE(tvp5150_test_patterns),
+ARRAY_SIZE(tvp5150_test_patterns) - 1,
 0, 0, tvp5150_test_patterns);
sd->ctrl_handler = >hdl;
if (core->hdl.error) {
-- 
2.17.1

[GIT PULL for 4.20] Big V4L2 fwnode patchset

[Sakari Ailus]

Hi Mauro,

This set contains the big V4L2 fwnode framework rework, including mine and
Steve's patches. What is now possible includes tonnes of bugs fixed,
default V4L2 fwnode endpoint configuration as well as less manual DT
parsing in the i.MX driver.

This is also the first time I'm signing the tag for a pull request. I
wonder if verification works out...

Please pull.


The following changes since commit cc1e6315e83db0e517dd9279050b88adc83a7eba:

  media: replace strcpy() by strscpy() (2018-09-11 13:32:17 -0400)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git tags/v4l2-fwnode-next-v3.1

for you to fetch changes up to 35b7344fc09c98c809da5b84c13d36f1e58ef095:

  smiapp: Query the V4L2 endpoint for a specific bus type (2018-09-13 13:01:46 
+0300)


fwnode patches for 4.20


Sakari Ailus (23):
  v4l: fwnode: Add debug prints for V4L2 endpoint property parsing
  v4l: fwnode: Use fwnode_graph_for_each_endpoint
  v4l: fwnode: The CSI-2 clock is continuous if it's not non-continuous
  dt-bindings: media: Specify bus type for MIPI D-PHY, others, explicitly
  v4l: fwnode: Add definitions for CSI-2 D-PHY, parallel and Bt.656 busses
  v4l: mediabus: Recognise CSI-2 D-PHY and C-PHY
  v4l: fwnode: Let the caller provide V4L2 fwnode endpoint
  v4l: fwnode: Detect bus type correctly
  v4l: fwnode: Make use of newly specified bus types
  v4l: fwnode: Read lane inversion information despite lane numbering
  v4l: fwnode: Only assign configuration if there is no error
  v4l: fwnode: Support driver-defined lane mapping defaults
  v4l: fwnode: Support default CSI-2 lane mapping for drivers
  v4l: fwnode: Parse the graph endpoint as last
  v4l: fwnode: Use default parallel flags
  v4l: fwnode: Initialise the V4L2 fwnode endpoints to zero
  v4l: fwnode: Only zero the struct if bus type is set to V4L2_MBUS_UNKNOWN
  v4l: fwnode: Use media bus type for bus parser selection
  v4l: fwnode: Print bus type
  v4l: fwnode: Use V4L2 fwnode endpoint media bus type if set
  v4l: fwnode: Support parsing of CSI-2 C-PHY endpoints
  v4l: fwnode: Update V4L2 fwnode endpoint parsing documentation
  smiapp: Query the V4L2 endpoint for a specific bus type

Steve Longerbeam (17):
  media: v4l2-fwnode: ignore endpoints that have no remote port parent
  media: v4l2: async: Allow searching for asd of any type
  media: v4l2: async: Add v4l2_async_notifier_add_subdev
  media: v4l2: async: Add convenience functions to allocate and add asd's
  media: v4l2-fwnode: Switch to v4l2_async_notifier_add_subdev
  media: v4l2-fwnode: Add a convenience function for registering subdevs 
with notifiers
  media: platform: video-mux: Register a subdev notifier
  media: imx: csi: Register a subdev notifier
  media: imx: mipi csi-2: Register a subdev notifier
  media: staging/imx: of: Remove recursive graph walk
  media: staging/imx: Loop through all registered subdevs for media links
  media: staging/imx: Rename root notifier
  media: staging/imx: Switch to v4l2_async_notifier_add_*_subdev
  media: staging/imx: TODO: Remove one assumption about OF graph parsing
  media: platform: Switch to v4l2_async_notifier_add_subdev
  media: v4l2: async: Remove notifier subdevs array
  v4l2-subdev.rst: Update doc regarding subdev descriptors

 .../devicetree/bindings/media/video-interfaces.txt |   4 +-
 Documentation/media/kapi/v4l2-subdev.rst   |  30 +-
 drivers/gpu/ipu-v3/ipu-csi.c   |   6 +-
 drivers/media/i2c/adv7180.c|   2 +-
 drivers/media/i2c/adv7604.c|   2 +-
 drivers/media/i2c/mt9v032.c|   2 +-
 drivers/media/i2c/ov2659.c |  14 +-
 drivers/media/i2c/ov5640.c |   4 +-
 drivers/media/i2c/ov5645.c |   2 +-
 drivers/media/i2c/ov5647.c |   2 +-
 drivers/media/i2c/ov7251.c |   4 +-
 drivers/media/i2c/ov7670.c |   2 +-
 drivers/media/i2c/s5c73m3/s5c73m3-core.c   |   4 +-
 drivers/media/i2c/s5k5baf.c|   6 +-
 drivers/media/i2c/s5k6aa.c |   2 +-
 drivers/media/i2c/smiapp/smiapp-core.c |  34 +-
 drivers/media/i2c/soc_camera/ov5642.c  |   2 +-
 drivers/media/i2c/tc358743.c   |  28 +-
 drivers/media/i2c/tda1997x.c   |   2 +-
 drivers/media/i2c/tvp514x.c|   2 +-
 drivers/media/i2c/tvp5150.c|   2 +-
 drivers/media/i2c/tvp7002.c|   2 +-
 drivers/media/pci/intel/ipu3/ipu3-cio2.c   |  16 +-
 drivers/media/platform/Kconfig  

Re: [PATCH v5 5/6] media: Add controls for JPEG quantization tables

[Paul Kocialkowski]

Hi,

On Thu, 2018-09-13 at 14:14 +0200, Paul Kocialkowski wrote:
> Hi,
> 
> On Wed, 2018-09-05 at 19:00 -0300, Ezequiel Garcia wrote:
> > From: Shunqian Zheng 
> > 
> > Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace
> > configure the JPEG quantization tables.
> > 
> > Signed-off-by: Shunqian Zheng 
> > Signed-off-by: Ezequiel Garcia 
> > ---
> >  .../media/uapi/v4l/extended-controls.rst  | 31 +++
> >  .../media/videodev2.h.rst.exceptions  |  1 +
> >  drivers/media/v4l2-core/v4l2-ctrls.c  | 10 ++
> >  include/uapi/linux/v4l2-controls.h| 12 +++
> >  include/uapi/linux/videodev2.h|  1 +
> >  5 files changed, 55 insertions(+)
> > 
> > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> > b/Documentation/media/uapi/v4l/extended-controls.rst
> > index 9f7312bf3365..1335d27d30f3 100644
> > --- a/Documentation/media/uapi/v4l/extended-controls.rst
> > +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> > @@ -3354,7 +3354,38 @@ JPEG Control IDs
> >  Specify which JPEG markers are included in compressed stream. This
> >  control is valid only for encoders.
> >  
> > +.. _jpeg-quant-tables-control:
> 
> I just had a look at how the Allwinner VPU handles JPEG decoding and it
> seems to require the following information (in addition to
> quantization):
> 
> * Horizontal and vertical sampling factors for each Y/U/V component:
> 
> The number of components and sampling factors are coded separately in
> the bitstream, but it's probably easier to use the already-existing
> V4L2_CID_JPEG_CHROMA_SUBSAMPLING control for specifying that.
> 
> However, this is potentially very much related to the destination
> format. If we decide that this format should match the format resulting
> from decompression, we don't need to specify it through an external
> control. On the other hand, it's possible that the VPU has format
> conversion block integrated in its pipeline so it would also make sense
> to consider the destination format as independent.
> 
> * Custom Huffman tables (DC and AC), both for luma and chroma
> 
> It seems that there is a default table when no Huffman table is provided
> in the bitstream (I'm not too sure how standard that is, just started
> learning about JPEG). We probably need a specific control for that.
> 
> * Reset interval
> 
> That's extracted from the bitstream as well and there's a
> V4L2_CID_JPEG_RESTART_INTERVAL control already.
> 
> In addition to these points, I see that among all the JPEG profiles,
> some have to do with arithmetic coding which will probably require a
> specific control on its own (not sure how it should look at this point
> though).
> 
> What do you think?

For clarification: these are required for decoding, not for encoding.

For encoding, it seems that the Allwinner hardware only requires
quantization tables.

Cheers,

Paul

> > +``V4L2_CID_JPEG_QUANTIZATION (struct)``
> > +Specifies the luma and chroma quantization matrices for encoding
> > +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The :ref:`itu-t81`
> > +specification allows 8-bit quantization coefficients for
> > +baseline profile images, and 8-bit or 16-bit for extended profile
> > +images. Supporting or not 16-bit precision coefficients is 
> > driver-specific.
> > +Coefficients must be set in JPEG zigzag scan order.
> > +
> > +
> > +.. c:type:: struct v4l2_ctrl_jpeg_quantization
> > +
> > +.. cssclass:: longtable
> > +
> > +.. flat-table:: struct v4l2_ctrl_jpeg_quantization
> > +:header-rows:  0
> > +:stub-columns: 0
> > +:widths:   1 1 2
> > +
> > +* - __u8
> > +  - ``precision``
> > +  - Specifies the coefficient precision. User shall set 0
> > +for 8-bit, and 1 for 16-bit.
> > +
> > +* - __u16
> > +  - ``luma_quantization_matrix[64]``
> > +  - Sets the luma quantization table.
> > +
> > +* - __u16
> > +  - ``chroma_quantization_matrix[64]``
> > +  - Sets the chroma quantization table.
> >  
> >  .. flat-table::
> >  :header-rows:  0
> > diff --git a/Documentation/media/videodev2.h.rst.exceptions 
> > b/Documentation/media/videodev2.h.rst.exceptions
> > index ca9f0edc579e..a0a38e92bf38 100644
> > --- a/Documentation/media/videodev2.h.rst.exceptions
> > +++ b/Documentation/media/videodev2.h.rst.exceptions
> > @@ -129,6 +129,7 @@ replace symbol V4L2_CTRL_TYPE_STRING 
> > :c:type:`v4l2_ctrl_type`
> >  replace symbol V4L2_CTRL_TYPE_U16 :c:type:`v4l2_ctrl_type`
> >  replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type`
> >  replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type`
> > +replace symbol V4L2_CTRL_TYPE_JPEG_QUANTIZATION :c:type:`v4l2_ctrl_type`
> >  
> >  # V4L2 capability defines
> >  replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index 599c1cbff3b9..305bd7a9b7f1 100644
> > --- 

cx23885 - regression between 4.17.x and 4.18.x

[David R]

Hi

Just a heads up. I'm having to revert cx23885-core.c to the 4.17 version
to obtain stability with my old AMD Phenom/ASUS M4A785TD and Hauppauge
WinTV-HVR-5525. The latest code drops out and refuses to return video
streams in hours or a few days max. The 4.17 version is fine and stable
over weeks/months.

04:00.0 Multimedia video controller: Conexant Systems, Inc. CX23887/8
PCIe Broadcast Audio and Video Decoder with 3D Comb (rev 04)
    Subsystem: Hauppauge computer works Inc. Device f038
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
    Kernel driver in use: cx23885

Cheers
David

Re: [PATCH v2] staging: cedrus: Fix checkpatch issues

[Paul Kocialkowski]

Hi,

On Thu, 2018-09-13 at 11:53 -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 13 Sep 2018 16:40:47 +0200
> Maxime Ripard  escreveu:
> 
> 
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > @@ -82,10 +82,7 @@ static struct cedrus_format *cedrus_find_format(u32 
> > pixelformat, u32 directions,
> >  static bool cedrus_check_format(u32 pixelformat, u32 directions,
> > unsigned int capabilities)
> >  {
> > -   struct cedrus_format *fmt = cedrus_find_format(pixelformat, directions,
> > -  capabilities);
> > -
> > -   return fmt != NULL;
> > +   return cedrus_find_format(pixelformat, directions, capabilities);
> >  }
> 
> Hmm... just occurred to me... Why do you need this? I mean, you 
> could simply do something like:
> 
> $ git filter-branch -f --tree-filter 'for i in $(git grep -l 
> cedrus_check_format); do \
>   sed -E s,\\bcedrus_check_format\\b,cedrus_find_format,g -i $i; done ' 
> origin/master..
> 
> (or just do a sed -E s,\\bcedrus_check_format\\b,cedrus_find_format,g as
> a separate patch)
> 
> and get rid of cedrus_check_format() for good.

Agreed, the name is probably explicit enough anyway. I probably should
have done that in the first place anyway.

Cheers,

Paul

-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2] staging: cedrus: Fix checkpatch issues

[Hans Verkuil]

On 09/13/2018 04:53 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 13 Sep 2018 16:40:47 +0200
> Maxime Ripard  escreveu:
> 
> 
>> --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
>> @@ -82,10 +82,7 @@ static struct cedrus_format *cedrus_find_format(u32 
>> pixelformat, u32 directions,
>>  static bool cedrus_check_format(u32 pixelformat, u32 directions,
>>  unsigned int capabilities)
>>  {
>> -struct cedrus_format *fmt = cedrus_find_format(pixelformat, directions,
>> -   capabilities);
>> -
>> -return fmt != NULL;
>> +return cedrus_find_format(pixelformat, directions, capabilities);
>>  }
> 
> Hmm... just occurred to me... Why do you need this? I mean, you 
> could simply do something like:
> 
> $ git filter-branch -f --tree-filter 'for i in $(git grep -l 
> cedrus_check_format); do \
>   sed -E s,\\bcedrus_check_format\\b,cedrus_find_format,g -i $i; done ' 
> origin/master..
> 
> (or just do a sed -E s,\\bcedrus_check_format\\b,cedrus_find_format,g as
> a separate patch)
> 
> and get rid of cedrus_check_format() for good.

That looks like a nice follow-up patch. It's a staging driver, it doesn't
have to be perfect.

I'll prepare a pull request tomorrow.

Regards,

Hans

Re: [PATCH v2] staging: cedrus: Fix checkpatch issues

[Mauro Carvalho Chehab]

Em Thu, 13 Sep 2018 16:40:47 +0200
Maxime Ripard  escreveu:


> --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> @@ -82,10 +82,7 @@ static struct cedrus_format *cedrus_find_format(u32 
> pixelformat, u32 directions,
>  static bool cedrus_check_format(u32 pixelformat, u32 directions,
>   unsigned int capabilities)
>  {
> - struct cedrus_format *fmt = cedrus_find_format(pixelformat, directions,
> -capabilities);
> -
> - return fmt != NULL;
> + return cedrus_find_format(pixelformat, directions, capabilities);
>  }

Hmm... just occurred to me... Why do you need this? I mean, you 
could simply do something like:

$ git filter-branch -f --tree-filter 'for i in $(git grep -l 
cedrus_check_format); do \
sed -E s,\\bcedrus_check_format\\b,cedrus_find_format,g -i $i; done ' 
origin/master..

(or just do a sed -E s,\\bcedrus_check_format\\b,cedrus_find_format,g as
a separate patch)

and get rid of cedrus_check_format() for good.

Thanks,
Mauro

[PATCH v10 1/5] media: videobuf2-core: Rework and rename helper for request buffer count

[Maxime Ripard]

From: Paul Kocialkowski 

The helper indicating whether buffers are associated with the request is
reworked and renamed to return the number of associated buffer objects.

This is useful for drivers that need to check how many buffers are in
the request to validate it.

Existing users of the helper don't need particular adaptation since the
meaning of zero/non-zero remains consistent.

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard 
---
 .../media/common/videobuf2/videobuf2-core.c| 18 --
 .../media/common/videobuf2/videobuf2-v4l2.c|  2 +-
 include/media/videobuf2-core.h |  4 ++--
 3 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index cb86b02afd4a..194b9188ad3e 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1368,23 +1368,21 @@ bool vb2_request_object_is_buffer(struct 
media_request_object *obj)
 }
 EXPORT_SYMBOL_GPL(vb2_request_object_is_buffer);
 
-bool vb2_request_has_buffers(struct media_request *req)
+unsigned int vb2_request_buffer_cnt(struct media_request *req)
 {
struct media_request_object *obj;
unsigned long flags;
-   bool has_buffers = false;
+   unsigned int buffer_cnt = 0;
 
spin_lock_irqsave(>lock, flags);
-   list_for_each_entry(obj, >objects, list) {
-   if (vb2_request_object_is_buffer(obj)) {
-   has_buffers = true;
-   break;
-   }
-   }
+   list_for_each_entry(obj, >objects, list)
+   if (vb2_request_object_is_buffer(obj))
+   buffer_cnt++;
spin_unlock_irqrestore(>lock, flags);
-   return has_buffers;
+
+   return buffer_cnt;
 }
-EXPORT_SYMBOL_GPL(vb2_request_has_buffers);
+EXPORT_SYMBOL_GPL(vb2_request_buffer_cnt);
 
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
 {
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 6831a2eb1859..a17033ab2c22 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -1139,7 +1139,7 @@ int vb2_request_validate(struct media_request *req)
struct media_request_object *obj;
int ret = 0;
 
-   if (!vb2_request_has_buffers(req))
+   if (!vb2_request_buffer_cnt(req))
return -ENOENT;
 
list_for_each_entry(obj, >objects, list) {
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 6c76b9802589..e86981d615ae 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -1191,10 +1191,10 @@ int vb2_verify_memory_type(struct vb2_queue *q,
 bool vb2_request_object_is_buffer(struct media_request_object *obj);
 
 /**
- * vb2_request_has_buffers() - return true if the request contains buffers
+ * vb2_request_buffer_cnt() - return the number of buffers in the request
  *
  * @req:   the request.
  */
-bool vb2_request_has_buffers(struct media_request *req);
+unsigned int vb2_request_buffer_cnt(struct media_request *req);
 
 #endif /* _MEDIA_VIDEOBUF2_CORE_H */
-- 
2.17.1

[PATCH v10 2/5] media: v4l: Add definitions for MPEG-2 slice format and metadata

[Maxime Ripard]

From: Paul Kocialkowski 

Stateless video decoding engines require both the MPEG-2 slices and
associated metadata from the video stream in order to decode frames.

This introduces definitions for a new pixel format, describing buffers
with MPEG-2 slice data, as well as control structure sfor passing the
frame metadata to drivers.

This is based on work from both Florent Revest and Hugues Fruchet.

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard 
---
 .../media/uapi/v4l/extended-controls.rst  | 176 ++
 .../media/uapi/v4l/pixfmt-compressed.rst  |  16 ++
 .../media/uapi/v4l/vidioc-queryctrl.rst   |  14 +-
 .../media/videodev2.h.rst.exceptions  |   2 +
 drivers/media/v4l2-core/v4l2-ctrls.c  |  63 +++
 drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
 include/media/v4l2-ctrls.h|  18 +-
 include/uapi/linux/v4l2-controls.h|  65 +++
 include/uapi/linux/videodev2.h|   5 +
 9 files changed, 351 insertions(+), 9 deletions(-)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index 9f7312bf3365..65a1d873196b 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1497,6 +1497,182 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
 
 
 
+.. _v4l2-mpeg-mpeg2:
+
+``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (struct)``
+Specifies the slice parameters (as extracted from the bitstream) for the
+associated MPEG-2 slice data. This includes the necessary parameters for
+configuring a stateless hardware decoding pipeline for MPEG-2.
+The bitstream parameters are defined according to :ref:`mpeg2part2`.
+
+.. c:type:: v4l2_ctrl_mpeg2_slice_params
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_mpeg2_slice_params
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u32
+  - ``bit_size``
+  - Size (in bits) of the current slice data.
+* - __u32
+  - ``data_bit_offset``
+  - Offset (in bits) to the video data in the current slice data.
+* - struct :c:type:`v4l2_mpeg2_sequence`
+  - ``sequence``
+  - Structure with MPEG-2 sequence metadata, merging relevant fields from
+   the sequence header and sequence extension parts of the bitstream.
+* - struct :c:type:`v4l2_mpeg2_picture`
+  - ``picture``
+  - Structure with MPEG-2 picture metadata, merging relevant fields from
+   the picture header and picture coding extension parts of the bitstream.
+* - __u8
+  - ``quantiser_scale_code``
+  - Code used to determine the quantization scale to use for the IDCT.
+* - __u8
+  - ``backward_ref_index``
+  - Index for the V4L2 buffer to use as backward reference, used with
+   B-coded and P-coded frames.
+* - __u8
+  - ``forward_ref_index``
+  - Index for the V4L2 buffer to use as forward reference, used with
+   B-coded frames.
+
+.. c:type:: v4l2_mpeg2_sequence
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_mpeg2_sequence
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u16
+  - ``horizontal_size``
+  - The width of the displayable part of the frame's luminance component.
+* - __u16
+  - ``vertical_size``
+  - The height of the displayable part of the frame's luminance component.
+* - __u32
+  - ``vbv_buffer_size``
+  - Used to calculate the required size of the video buffering verifier,
+   defined (in bits) as: 16 * 1024 * vbv_buffer_size.
+* - __u8
+  - ``profile_and_level_indication``
+  - The current profile and level indication as extracted from the
+   bitstream.
+* - __u8
+  - ``progressive_sequence``
+  - Indication that all the frames for the sequence are progressive instead
+   of interlaced.
+* - __u8
+  - ``chroma_format``
+  - The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4).
+
+.. c:type:: v4l2_mpeg2_picture
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_mpeg2_picture
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``picture_coding_type``
+  - Picture coding type for the frame covered by the current slice
+   (V4L2_MPEG2_PICTURE_CODING_TYPE_I, V4L2_MPEG2_PICTURE_CODING_TYPE_P or
+   V4L2_MPEG2_PICTURE_CODING_TYPE_B).
+* - __u8
+  - ``f_code[2][2]``
+  - Motion vector codes.
+* - __u8
+  - ``intra_dc_precision``
+  - Precision of Discrete Cosine transform (0: 8 bits precision,
+   1: 9 bits precision, 2: 10 bits precision, 3: 11 bits precision).
+* - __u8
+  - ``picture_structure``
+  - Picture structure (1: interlaced top field, 2: interlaced bottom field,
+   3: progressive frame).
+* - __u8
+  - ``top_field_first``
+  - If set to 1 and interlaced stream, 

[PATCH v10 5/5] media: platform: Add Cedrus VPU decoder driver

[Maxime Ripard]

From: Paul Kocialkowski 

This introduces the Cedrus VPU driver that supports the VPU found in
Allwinner SoCs, also known as Video Engine. It is implemented through
a V4L2 M2M decoder device and a media device (used for media requests).
So far, it only supports MPEG-2 decoding.

Since this VPU is stateless, synchronization with media requests is
required in order to ensure consistency between frame headers that
contain metadata about the frame to process and the raw slice data that
is used to generate the frame.

This driver was made possible thanks to the long-standing effort
carried out by the linux-sunxi community in the interest of reverse
engineering, documenting and implementing support for the Allwinner VPU.

Signed-off-by: Paul Kocialkowski 
Acked-by: Maxime Ripard 
Signed-off-by: Hans Verkuil 
[hans.verk...@cisco.com: dropped obsolete MEDIA_REQUEST_API from Kconfig]
---
 MAINTAINERS   |   7 +
 drivers/staging/media/Kconfig |   2 +
 drivers/staging/media/Makefile|   1 +
 drivers/staging/media/sunxi/Kconfig   |  15 +
 drivers/staging/media/sunxi/Makefile  |   1 +
 drivers/staging/media/sunxi/cedrus/Kconfig|  14 +
 drivers/staging/media/sunxi/cedrus/Makefile   |   3 +
 drivers/staging/media/sunxi/cedrus/TODO   |   7 +
 drivers/staging/media/sunxi/cedrus/cedrus.c   | 431 ++
 drivers/staging/media/sunxi/cedrus/cedrus.h   | 167 ++
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |  70 +++
 .../staging/media/sunxi/cedrus/cedrus_dec.h   |  27 +
 .../staging/media/sunxi/cedrus/cedrus_hw.c| 327 +++
 .../staging/media/sunxi/cedrus/cedrus_hw.h|  30 +
 .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 246 
 .../staging/media/sunxi/cedrus/cedrus_regs.h  | 235 
 .../staging/media/sunxi/cedrus/cedrus_video.c | 542 ++
 .../staging/media/sunxi/cedrus/cedrus_video.h |  30 +
 18 files changed, 2155 insertions(+)
 create mode 100644 drivers/staging/media/sunxi/Kconfig
 create mode 100644 drivers/staging/media/sunxi/Makefile
 create mode 100644 drivers/staging/media/sunxi/cedrus/Kconfig
 create mode 100644 drivers/staging/media/sunxi/cedrus/Makefile
 create mode 100644 drivers/staging/media/sunxi/cedrus/TODO
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus.c
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus.h
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_dec.c
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_dec.h
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_hw.c
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_hw.h
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_regs.h
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_video.c
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_video.h

diff --git a/MAINTAINERS b/MAINTAINERS
index a5b256b25905..6d69f3ad1aa9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -663,6 +663,13 @@ L: linux-cry...@vger.kernel.org
 S: Maintained
 F: drivers/crypto/sunxi-ss/
 
+ALLWINNER VPU DRIVER
+M: Maxime Ripard 
+M: Paul Kocialkowski 
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/staging/media/sunxi/cedrus/
+
 ALPHA PORT
 M: Richard Henderson 
 M: Ivan Kokshaysky 
diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index db5cf67047ad..b3620a8f2d9f 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig"
 
 source "drivers/staging/media/omap4iss/Kconfig"
 
+source "drivers/staging/media/sunxi/Kconfig"
+
 source "drivers/staging/media/tegra-vde/Kconfig"
 
 source "drivers/staging/media/zoran/Kconfig"
diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
index 503fbe47fa58..42948f805548 100644
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@ -5,5 +5,6 @@ obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074/
 obj-$(CONFIG_SOC_CAMERA_MT9T031)   += mt9t031/
 obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci_vpfe/
 obj-$(CONFIG_VIDEO_OMAP4)  += omap4iss/
+obj-$(CONFIG_VIDEO_SUNXI)  += sunxi/
 obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/
 obj-$(CONFIG_VIDEO_ZORAN)  += zoran/
diff --git a/drivers/staging/media/sunxi/Kconfig 
b/drivers/staging/media/sunxi/Kconfig
new file mode 100644
index ..c78d92240ceb
--- /dev/null
+++ b/drivers/staging/media/sunxi/Kconfig
@@ -0,0 +1,15 @@
+config VIDEO_SUNXI
+   bool "Allwinner sunXi family Video Devices"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   help
+ If you have an Allwinner SoC based on the sunXi family, say Y.
+
+ Note that this option doesn't include new drivers in the
+ kernel: saying N will just cause Kconfig to skip all the
+ questions about Allwinner 

[PATCH v10 0/5] Cedrus driver for the Allwinner Video Engine, using media requests

[Maxime Ripard]

This is the ninth iteration of the updated Cedrus driver,
that supports the Video Engine found on most Allwinner SoCs, starting
with the A10. It was tested on the A13, A20, A33 and H3.

The initial version of this driver[0] was originally written and
submitted by Florent Revest using a previous version of the request API
that is necessary to provide coherency between controls and the buffers
they apply to.

The driver was adapted to use the latest version of the media request
API[1], as submitted by Hans Verkuil. Media request API support is a
hard requirement for the Cedrus driver.

The driver itself currently only supports MPEG2 and more codecs will be
added eventually. The default output frame format provided by the Video
Engine is a multi-planar tiled YUV format (based on NV12). A specific
format is introduced in the V4L2 API to describe it. Starting with the
A33, the Video Engine can also output untiled YUV formats.

This implementation is based on the significant work that was conducted
by various members of the linux-sunxi community for understanding and
documenting the Video Engine's innards.

In addition to the media requests API, the following series are required
for Cedrus:
* vicodec: the Virtual Codec driver
* allwinner: a64: add SRAM controller / system control
* SRAM patches from the Cedrus VPU driver series version 5

Changes since v10:
* Moved to strscpy
* Fixed the checkpatch warning
* Fixed the wrongful P-frames mention in the MPEG2 documentation
* Removed the DT patches

Changes since v8:
* Removed dummy job_abort as it is now optional;
* Fixed video device registration order;
* Fixed queue_setup for properly handling CREATE_BUFFERS;
* Switched to single-planar API and applied associated reworks,
  since our formats are not multi-planar V4L2 pixel formats.
* Added validation of the number of buffers associated with the request,
  by modifying the relevant helper as instructed;
* Used strlcpy where needed;
* Applied various minor fixups from suggestions;
* Added some comments for clarity.

Changes since v7:
* Rebased on the latest Request API;
* Brought back comment about DRAM width;
* Fixed building as a module;
* Fixed copyright headers.

Changes since v6:
* Reworked MPEG2 controls to stick closer to the bitstream;
* Updated controls documentation accordingly and added requested fixes;
* Renamed tiled format to V4L2_PIX_FMT_SUNXI_TILED_NV12;
* Added various minor driver fixes based on Hans' feedback;
* Fixed dst frame alignment based on Jernej's feedback and tests;
* Removed set bits for the disabled secondary output.

Changes since v5:
* Added MPEG2 quantization matrices definitions and support;
* Cleaned up registers definitions;
* Moved the driver to staging as requested;
* Removed label and newline in device-tree sources;
* Made it possible to build the driver for COMPILE_TEST;
* Fixed various strict checkpatch warnings;
* Used v4l2_m2m_register_media_controller and MEDIA_ENT_F_PROC_VIDEO_DECODER;
* Moved capabilities to compatible-specific variants;
* Removed overkill buffer checks in device_run;
* Renamed from Sunxi-Cedrus to Cedrus.

Changes since v4:
* updated to version 16 of the media requests API;
* added support for VPU-based untiling (starting with the A33);
* added support for the H3, with SRAM support;
* reworked SRAM support and associated compatibles;
* improved failure paths;
* added some MPEG2 input data validation;
* reworked video/format functions to handle multiple formats;
* removed in-driver buffer queues;
* used a threaded irq instead of a workqueue;
* merged various improvements and cleanups from Maxime;
* renamed MPEG2_SLICE_HEADER to MPEG2_SLICE_PARAMS;
* added prefixes to MPEG2 picture coding types;
* used single-buffer allocations to ensure contiguous planes

Changes since v3:
* updated to version 15 of the media request API;
* got rid of untested MPEG1 support;
* added definitons for picture coding types;
* added documentation about MPEG2 slice header fields;
* added documentation about MPEG2 slice format;
* added documentation about the MB32 NV12 format;
* added MPEG2 slice header validation;
* removed the assigned-clocks property;
* reworked and fixed error paths;
* harmonized debug prints, with v4l2 helpers when applicable;
* checked the series through checkpatch;
* switched to SPDX license headers;
* renamed MPEG2 frame header to slice header for consistency and clarity;
* removed A20 SRAM compatible from the driver's list.

Changes since v2:
* updated to version 13 of the media request API;
* integrated various changes from Maxime Ripard;
* reworked memory reservation to use CMA, dynamic allocation and allow
  DMABUF;
* removed reserved memory binding since the CMA pool is the default one
  (and allow ENODEV in the driver, for that use case);
* added SRAM controller support for the SRAM region used by the VE;
* updated the device-tree bindings the for SRAM region;
* added per-platform bindings;
* added A13 support;
* renamed VE node name and label;
* 

[PATCH v10 4/5] dt-bindings: media: Document bindings for the Cedrus VPU driver

[Maxime Ripard]

From: Paul Kocialkowski 

This adds a device-tree binding document that specifies the properties
used by the Cedrus VPU driver, as well as examples.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
Acked-by: Maxime Ripard 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cedrus.txt  | 54 +++
 1 file changed, 54 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cedrus.txt

diff --git a/Documentation/devicetree/bindings/media/cedrus.txt 
b/Documentation/devicetree/bindings/media/cedrus.txt
new file mode 100644
index ..a089a0c1ff05
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cedrus.txt
@@ -0,0 +1,54 @@
+Device-tree bindings for the VPU found in Allwinner SoCs, referred to as the
+Video Engine (VE) in Allwinner literature.
+
+The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped starting
+from the DRAM base. This requires specific memory allocation and handling.
+
+Required properties:
+- compatible   : must be one of the following compatibles:
+   - "allwinner,sun4i-a10-video-engine"
+   - "allwinner,sun5i-a13-video-engine"
+   - "allwinner,sun7i-a20-video-engine"
+   - "allwinner,sun8i-a33-video-engine"
+   - "allwinner,sun8i-h3-video-engine"
+- reg  : register base and length of VE;
+- clocks   : list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names  : should contain "ahb", "mod" and "ram" entries;
+- resets   : phandle for reset;
+- interrupts   : VE interrupt number;
+- allwinner,sram   : SRAM region to use with the VE.
+
+Optional properties:
+- memory-region: CMA pool to use for buffers allocation 
instead of the
+ default CMA pool.
+
+Example:
+
+reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+   cma_pool: cma@4a00 {
+   compatible = "shared-dma-pool";
+   size = <0x600>;
+   alloc-ranges = <0x4a00 0x600>;
+   reusable;
+   linux,cma-default;
+   };
+};
+
+video-codec@1c0e000 {
+   compatible = "allwinner,sun7i-a20-video-engine";
+   reg = <0x01c0e000 0x1000>;
+
+   clocks = < CLK_AHB_VE>, < CLK_VE>,
+< CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+
+   resets = < RST_VE>;
+   interrupts = ;
+   allwinner,sram = <_sram 1>;
+};
-- 
2.17.1

[PATCH v10 3/5] media: v4l: Add definition for the Sunxi tiled NV12 format

[Maxime Ripard]

From: Paul Kocialkowski 

This introduces support for the Sunxi tiled NV12 format, where each
component of the YUV frame is divided into macroblocks. Hence, the size
of each plane requires specific alignment. The pixels inside each
macroblock are coded in linear order (line after line from top to
bottom).

This tiled NV12 format is used by the video engine on Allwinner
platforms: it is the default format for decoded frames (and the only
one available in the oldest supported platforms).

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard 
---
 Documentation/media/uapi/v4l/pixfmt-reserved.rst | 13 +
 drivers/media/v4l2-core/v4l2-ioctl.c |  1 +
 include/uapi/linux/videodev2.h   |  1 +
 3 files changed, 15 insertions(+)

diff --git a/Documentation/media/uapi/v4l/pixfmt-reserved.rst 
b/Documentation/media/uapi/v4l/pixfmt-reserved.rst
index 38af1472a4b4..0c399858bda2 100644
--- a/Documentation/media/uapi/v4l/pixfmt-reserved.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-reserved.rst
@@ -243,7 +243,20 @@ please make a proposal on the linux-media mailing list.
It is an opaque intermediate format and the MDP hardware must be
used to convert ``V4L2_PIX_FMT_MT21C`` to ``V4L2_PIX_FMT_NV12M``,
``V4L2_PIX_FMT_YUV420M`` or ``V4L2_PIX_FMT_YVU420``.
+* .. _V4L2-PIX-FMT-SUNXI-TILED-NV12:
 
+  - ``V4L2_PIX_FMT_SUNXI_TILED_NV12``
+  - 'ST12'
+  - Two-planar NV12-based format used by the video engine found on 
Allwinner
+   (codenamed sunxi) platforms, with 32x32 tiles for the luminance plane
+   and 32x64 tiles for the chrominance plane. The data in each tile is
+   stored in linear order, within the tile bounds. Each tile follows the
+   previous one linearly in memory (from left to right, top to bottom).
+
+   The associated buffer dimensions are aligned to match an integer number
+   of tiles, resulting in 32-aligned resolutions for the luminance plane
+   and 16-aligned resolutions for the chrominance plane (with 2x2
+   subsampling).
 
 .. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
 
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 1a8feaf6c3f7..c148c44caffb 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1337,6 +1337,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_SE401:descr = "GSPCA SE401"; break;
case V4L2_PIX_FMT_S5C_UYVY_JPG: descr = "S5C73MX interleaved 
UYVY/JPEG"; break;
case V4L2_PIX_FMT_MT21C:descr = "Mediatek Compressed 
Format"; break;
+   case V4L2_PIX_FMT_SUNXI_TILED_NV12: descr = "Sunxi Tiled NV12 
Format"; break;
default:
WARN(1, "Unknown pixelformat 0x%08x\n", 
fmt->pixelformat);
if (fmt->description[0])
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 314ec7a5f046..7412a255d9ce 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -677,6 +677,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_Z16  v4l2_fourcc('Z', '1', '6', ' ') /* Depth data 
16-bit */
 #define V4L2_PIX_FMT_MT21Cv4l2_fourcc('M', 'T', '2', '1') /* Mediatek 
compressed block mode  */
 #define V4L2_PIX_FMT_INZI v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel Planar 
Greyscale 10-bit and Depth 16-bit */
+#define V4L2_PIX_FMT_SUNXI_TILED_NV12 v4l2_fourcc('S', 'T', '1', '2') /* Sunxi 
Tiled NV12 Format */
 
 /* 10bit raw bayer packed, 32 bytes for every 25 pixels, last LSB 6 bits 
unused */
 #define V4L2_PIX_FMT_IPU3_SBGGR10  v4l2_fourcc('i', 'p', '3', 'b') /* IPU3 
packed 10-bit BGGR bayer */
-- 
2.17.1

[PATCH RESEND v2] staging: cedrus: Fix checkpatch issues

[Maxime Ripard]

Checkpatch, when used with --strict, reports a number of issues on the
cedrus driver.

Fix those warnings, except for a few, minor, lines too long warnings.

Signed-off-by: Maxime Ripard 
---

Resent since some changes were left uncommitted.

Changes from v1:
  - Removed the find_control wrapping
  - Added the bit length to the required variable
  - Added __ to the macro arguments

 drivers/staging/media/sunxi/cedrus/cedrus.c   | 10 +-
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  8 +---
 .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 19 ++-
 .../staging/media/sunxi/cedrus/cedrus_regs.h  | 18 ++
 .../staging/media/sunxi/cedrus/cedrus_video.c |  6 ++
 5 files changed, 36 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 1f5f20a1f849..82558455384a 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -48,7 +48,7 @@ void *cedrus_find_control_data(struct cedrus_ctx *ctx, u32 id)
 {
unsigned int i;
 
-   for (i = 0; ctx->ctrls[i] != NULL; i++)
+   for (i = 0; ctx->ctrls[i]; i++)
if (ctx->ctrls[i]->id == id)
return ctx->ctrls[i]->p_cur.p;
 
@@ -147,10 +147,10 @@ static int cedrus_request_validate(struct media_request 
*req)
continue;
 
ctrl_test = v4l2_ctrl_request_hdl_ctrl_find(hdl,
-   cedrus_controls[i].id);
+   
cedrus_controls[i].id);
if (!ctrl_test) {
v4l2_info(>dev->v4l2_dev,
-"Missing required codec control\n");
+ "Missing required codec control\n");
return -ENOENT;
}
}
@@ -310,8 +310,8 @@ static int cedrus_probe(struct platform_device *pdev)
dev->mdev.ops = _m2m_media_ops;
dev->v4l2_dev.mdev = >mdev;
 
-   ret = v4l2_m2m_register_media_controller(dev->m2m_dev,
-   vfd, MEDIA_ENT_F_PROC_VIDEO_DECODER);
+   ret = v4l2_m2m_register_media_controller(dev->m2m_dev, vfd,
+
MEDIA_ENT_F_PROC_VIDEO_DECODER);
if (ret) {
v4l2_err(>v4l2_dev,
 "Failed to initialize V4L2 M2M media controller\n");
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h 
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 3262341e8c9a..3f61248c57ac 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -44,7 +44,7 @@ struct cedrus_control {
u32 id;
u32 elem_size;
enum cedrus_codec   codec;
-   boolrequired;
+   unsigned char   required:1;
 };
 
 struct cedrus_mpeg2_run {
@@ -150,12 +150,14 @@ static inline dma_addr_t cedrus_dst_buf_addr(struct 
cedrus_ctx *ctx,
return buf ? cedrus_buf_addr(buf, >dst_fmt, plane) : 0;
 }
 
-static inline struct cedrus_buffer *vb2_v4l2_to_cedrus_buffer(const struct 
vb2_v4l2_buffer *p)
+static inline struct cedrus_buffer *
+vb2_v4l2_to_cedrus_buffer(const struct vb2_v4l2_buffer *p)
 {
return container_of(p, struct cedrus_buffer, m2m_buf.vb);
 }
 
-static inline struct cedrus_buffer *vb2_to_cedrus_buffer(const struct 
vb2_buffer *p)
+static inline struct cedrus_buffer *
+vb2_to_cedrus_buffer(const struct vb2_buffer *p)
 {
return vb2_v4l2_to_cedrus_buffer(to_vb2_v4l2_buffer(p));
 }
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
index 029eb1626bf4..9abd39cae38c 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
@@ -157,14 +157,22 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx, 
struct cedrus_run *run)
 
/* Forward and backward prediction reference buffers. */
 
-   fwd_luma_addr = cedrus_dst_buf_addr(ctx, 
slice_params->forward_ref_index, 0);
-   fwd_chroma_addr = cedrus_dst_buf_addr(ctx, 
slice_params->forward_ref_index, 1);
+   fwd_luma_addr = cedrus_dst_buf_addr(ctx,
+   slice_params->forward_ref_index,
+   0);
+   fwd_chroma_addr = cedrus_dst_buf_addr(ctx,
+ slice_params->forward_ref_index,
+ 1);
 
cedrus_write(dev, VE_DEC_MPEG_FWD_REF_LUMA_ADDR, fwd_luma_addr);
cedrus_write(dev, VE_DEC_MPEG_FWD_REF_CHROMA_ADDR, fwd_chroma_addr);
 
-   bwd_luma_addr = cedrus_dst_buf_addr(ctx, 
slice_params->backward_ref_index, 0);
-   bwd_chroma_addr = cedrus_dst_buf_addr(ctx, 
slice_params->backward_ref_index, 1);
+   

[PATCH v2] staging: cedrus: Fix checkpatch issues

[Maxime Ripard]

Checkpatch, when used with --strict, reports a number of issues on the
cedrus driver.

Fix those warnings, except for a few, minor, lines too long warnings.

Signed-off-by: Maxime Ripard 
---

Changes from v1:
  - Removed the find_control wrapping
  - Added the bit length to the required variable
  - Added __ to the macro arguments

 drivers/staging/media/sunxi/cedrus/cedrus.c   | 10 +-
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  8 +---
 .../staging/media/sunxi/cedrus/cedrus_dec.c   | 10 ++
 .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 19 ++-
 .../staging/media/sunxi/cedrus/cedrus_regs.h  | 18 ++
 .../staging/media/sunxi/cedrus/cedrus_video.c |  6 ++
 6 files changed, 42 insertions(+), 29 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 1f5f20a1f849..82558455384a 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -48,7 +48,7 @@ void *cedrus_find_control_data(struct cedrus_ctx *ctx, u32 id)
 {
unsigned int i;
 
-   for (i = 0; ctx->ctrls[i] != NULL; i++)
+   for (i = 0; ctx->ctrls[i]; i++)
if (ctx->ctrls[i]->id == id)
return ctx->ctrls[i]->p_cur.p;
 
@@ -147,10 +147,10 @@ static int cedrus_request_validate(struct media_request 
*req)
continue;
 
ctrl_test = v4l2_ctrl_request_hdl_ctrl_find(hdl,
-   cedrus_controls[i].id);
+   
cedrus_controls[i].id);
if (!ctrl_test) {
v4l2_info(>dev->v4l2_dev,
-"Missing required codec control\n");
+ "Missing required codec control\n");
return -ENOENT;
}
}
@@ -310,8 +310,8 @@ static int cedrus_probe(struct platform_device *pdev)
dev->mdev.ops = _m2m_media_ops;
dev->v4l2_dev.mdev = >mdev;
 
-   ret = v4l2_m2m_register_media_controller(dev->m2m_dev,
-   vfd, MEDIA_ENT_F_PROC_VIDEO_DECODER);
+   ret = v4l2_m2m_register_media_controller(dev->m2m_dev, vfd,
+
MEDIA_ENT_F_PROC_VIDEO_DECODER);
if (ret) {
v4l2_err(>v4l2_dev,
 "Failed to initialize V4L2 M2M media controller\n");
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h 
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 3262341e8c9a..3f61248c57ac 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -44,7 +44,7 @@ struct cedrus_control {
u32 id;
u32 elem_size;
enum cedrus_codec   codec;
-   boolrequired;
+   unsigned char   required:1;
 };
 
 struct cedrus_mpeg2_run {
@@ -150,12 +150,14 @@ static inline dma_addr_t cedrus_dst_buf_addr(struct 
cedrus_ctx *ctx,
return buf ? cedrus_buf_addr(buf, >dst_fmt, plane) : 0;
 }
 
-static inline struct cedrus_buffer *vb2_v4l2_to_cedrus_buffer(const struct 
vb2_v4l2_buffer *p)
+static inline struct cedrus_buffer *
+vb2_v4l2_to_cedrus_buffer(const struct vb2_v4l2_buffer *p)
 {
return container_of(p, struct cedrus_buffer, m2m_buf.vb);
 }
 
-static inline struct cedrus_buffer *vb2_to_cedrus_buffer(const struct 
vb2_buffer *p)
+static inline struct cedrus_buffer *
+vb2_to_cedrus_buffer(const struct vb2_buffer *p)
 {
return vb2_v4l2_to_cedrus_buffer(to_vb2_v4l2_buffer(p));
 }
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..788811a1414e 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -43,10 +43,12 @@ void cedrus_device_run(void *priv)
 
switch (ctx->src_fmt.pixelformat) {
case V4L2_PIX_FMT_MPEG2_SLICE:
-   run.mpeg2.slice_params = cedrus_find_control_data(ctx,
-   V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
-   run.mpeg2.quantization = cedrus_find_control_data(ctx,
-   V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
+   run.mpeg2.slice_params =
+   cedrus_find_control_data(ctx,
+
V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
+   run.mpeg2.quantization =
+   cedrus_find_control_data(ctx,
+
V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
break;
 
default:
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
index 029eb1626bf4..9abd39cae38c 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
+++ 

Edit your photos 11

[Jimmy]

Hi,

We are waiting for your photos.
Please send photos to hansre...@outlook.com for further editing.

Our team is ready to edit your photos. Do you have photos for editing?
We are team who can do following work for you.
Cutting out your photos, or retouching if needed.

It is for products photos or portrait photos, catalog photos.

Please send photo editing work to hansre...@outlook.com

Thanks,
Jimmy Button
Email: hansre...@outlook.com

Re: [PATCH] staging: cedrus: Fix checkpatch issues

[Hans Verkuil]

On 09/13/18 15:54, Mauro Carvalho Chehab wrote:
>>  switch (ctx->src_fmt.pixelformat) {
>>  case V4L2_PIX_FMT_MPEG2_SLICE:
>> -run.mpeg2.slice_params = cedrus_find_control_data(ctx,
>> -V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
>> -run.mpeg2.quantization = cedrus_find_control_data(ctx,
>> -V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
>> +run.mpeg2.slice_params =
>> +cedrus_find_control_data(ctx,
>> + 
>> V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
>> +run.mpeg2.quantization =
>> +cedrus_find_control_data(ctx,
>> + 
>> V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
> 
> Nah, this an example where we should violate the 80-columns limit, in order
> to make easier for humans to understand.
> 
> I would code it as:
> 
>   run.mpeg2.slice_params = cedrus_find_control_data(ctx,
> 
> V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);

Why not keep this unchanged? There is nothing wrong IMHO with
the original:

run.mpeg2.slice_params = cedrus_find_control_data(ctx,
V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);

Perfectly readable, and certainly better then Maxime's or your version.

Regards,

Hans

Re: [PATCH] staging: cedrus: Fix checkpatch issues

[Mauro Carvalho Chehab]

Em Thu, 13 Sep 2018 11:30:23 +0200
Maxime Ripard  escreveu:

> Checkpatch, when used with --strict, reports a number of issues on the
> cedrus driver.
> 
> Fix those warnings, except for a few, minor, lines too long warnings.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/staging/media/sunxi/cedrus/cedrus.c   | 10 +-
>  drivers/staging/media/sunxi/cedrus/cedrus.h   |  8 +---
>  .../staging/media/sunxi/cedrus/cedrus_dec.c   | 10 ++
>  .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 19 ++-
>  .../staging/media/sunxi/cedrus/cedrus_regs.h  | 16 +---
>  .../staging/media/sunxi/cedrus/cedrus_video.c |  6 ++
>  6 files changed, 41 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
> b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index 0a9363c7db06..d312dec5ab79 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -48,7 +48,7 @@ void *cedrus_find_control_data(struct cedrus_ctx *ctx, u32 
> id)
>  {
>   unsigned int i;
>  
> - for (i = 0; ctx->ctrls[i] != NULL; i++)
> + for (i = 0; ctx->ctrls[i]; i++)
>   if (ctx->ctrls[i]->id == id)
>   return ctx->ctrls[i]->p_cur.p;
>  
> @@ -147,10 +147,10 @@ static int cedrus_request_validate(struct media_request 
> *req)
>   continue;
>  
>   ctrl_test = v4l2_ctrl_request_hdl_ctrl_find(hdl,
> - cedrus_controls[i].id);
> + 
> cedrus_controls[i].id);
>   if (!ctrl_test) {
>   v4l2_info(>dev->v4l2_dev,
> -  "Missing required codec control\n");
> +   "Missing required codec control\n");
>   return -ENOENT;
>   }
>   }
> @@ -310,8 +310,8 @@ static int cedrus_probe(struct platform_device *pdev)
>   dev->mdev.ops = _m2m_media_ops;
>   dev->v4l2_dev.mdev = >mdev;
>  
> - ret = v4l2_m2m_register_media_controller(dev->m2m_dev,
> - vfd, MEDIA_ENT_F_PROC_VIDEO_DECODER);
> + ret = v4l2_m2m_register_media_controller(dev->m2m_dev, vfd,
> +  
> MEDIA_ENT_F_PROC_VIDEO_DECODER);
>   if (ret) {
>   v4l2_err(>v4l2_dev,
>"Failed to initialize V4L2 M2M media controller\n");
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h 
> b/drivers/staging/media/sunxi/cedrus/cedrus.h
> index 3262341e8c9a..8d171efecc37 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> @@ -44,7 +44,7 @@ struct cedrus_control {
>   u32 id;
>   u32 elem_size;
>   enum cedrus_codec   codec;
> - boolrequired;
> + unsigned char   required;

I would actually prefer to use something like:

unsigned char   required:1;

To make clear that it is a boolean value.

>  };
>  
>  struct cedrus_mpeg2_run {
> @@ -150,12 +150,14 @@ static inline dma_addr_t cedrus_dst_buf_addr(struct 
> cedrus_ctx *ctx,
>   return buf ? cedrus_buf_addr(buf, >dst_fmt, plane) : 0;
>  }
>  
> -static inline struct cedrus_buffer *vb2_v4l2_to_cedrus_buffer(const struct 
> vb2_v4l2_buffer *p)
> +static inline struct cedrus_buffer *
> +vb2_v4l2_to_cedrus_buffer(const struct vb2_v4l2_buffer *p)
>  {
>   return container_of(p, struct cedrus_buffer, m2m_buf.vb);
>  }
>  
> -static inline struct cedrus_buffer *vb2_to_cedrus_buffer(const struct 
> vb2_buffer *p)
> +static inline struct cedrus_buffer *
> +vb2_to_cedrus_buffer(const struct vb2_buffer *p)
>  {
>   return vb2_v4l2_to_cedrus_buffer(to_vb2_v4l2_buffer(p));
>  }
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> index e40180a33951..788811a1414e 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> @@ -43,10 +43,12 @@ void cedrus_device_run(void *priv)
>  
>   switch (ctx->src_fmt.pixelformat) {
>   case V4L2_PIX_FMT_MPEG2_SLICE:
> - run.mpeg2.slice_params = cedrus_find_control_data(ctx,
> - V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
> - run.mpeg2.quantization = cedrus_find_control_data(ctx,
> - V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
> + run.mpeg2.slice_params =
> + cedrus_find_control_data(ctx,
> +  
> V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
> + run.mpeg2.quantization =
> + cedrus_find_control_data(ctx,
> +  
> V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);

Nah, this an example where we should violate the 80-columns limit, in 

[PATCH 4/4] cec: remove cec-edid.c

[Hans Verkuil]

From: Hans Verkuil 

Move cec_get_edid_phys_addr() to cec-adap.c. It's not worth keeping
a separate source for this.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/Makefile   |  2 +-
 drivers/media/cec/cec-adap.c | 13 +
 drivers/media/cec/cec-edid.c | 24 
 3 files changed, 14 insertions(+), 25 deletions(-)
 delete mode 100644 drivers/media/cec/cec-edid.c

diff --git a/drivers/media/cec/Makefile b/drivers/media/cec/Makefile
index 29a2ab9e77c5..ad8677d8c896 100644
--- a/drivers/media/cec/Makefile
+++ b/drivers/media/cec/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
-cec-objs := cec-core.o cec-adap.o cec-api.o cec-edid.o
+cec-objs := cec-core.o cec-adap.o cec-api.o
 
 ifeq ($(CONFIG_CEC_NOTIFIER),y)
   cec-objs += cec-notifier.o
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 030b2602faf0..829878356e1e 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -62,6 +62,19 @@ static unsigned int cec_log_addr2dev(const struct 
cec_adapter *adap, u8 log_addr
return adap->log_addrs.primary_device_type[i < 0 ? 0 : i];
 }
 
+u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size,
+  unsigned int *offset)
+{
+   unsigned int loc = cec_get_edid_spa_location(edid, size);
+
+   if (offset)
+   *offset = loc;
+   if (loc == 0)
+   return CEC_PHYS_ADDR_INVALID;
+   return (edid[loc] << 8) | edid[loc + 1];
+}
+EXPORT_SYMBOL_GPL(cec_get_edid_phys_addr);
+
 /*
  * Queue a new event for this filehandle. If ts == 0, then set it
  * to the current time.
diff --git a/drivers/media/cec/cec-edid.c b/drivers/media/cec/cec-edid.c
deleted file mode 100644
index e2f54eec0829..
--- a/drivers/media/cec/cec-edid.c
+++ /dev/null
@@ -1,24 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * cec-edid - HDMI Consumer Electronics Control EDID & CEC helper functions
- *
- * Copyright 2016 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size,
-  unsigned int *offset)
-{
-   unsigned int loc = cec_get_edid_spa_location(edid, size);
-
-   if (offset)
-   *offset = loc;
-   if (loc == 0)
-   return CEC_PHYS_ADDR_INVALID;
-   return (edid[loc] << 8) | edid[loc + 1];
-}
-EXPORT_SYMBOL_GPL(cec_get_edid_phys_addr);
-- 
2.18.0

[PATCH 2/4] cec: integrate cec_validate_phys_addr() in cec-api.c

[Hans Verkuil]

From: Hans Verkuil 

The cec_phys_addr_validate() function will be moved to V4L2,
so use a simplified variant of that function in cec-api.c.
cec now no longer calls cec_phys_addr_validate() and it can
be safely moved to V4L2.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-api.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index 19170b1073fa..391b6fd483e1 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -101,6 +101,23 @@ static long cec_adap_g_phys_addr(struct cec_adapter *adap,
return 0;
 }
 
+static int cec_validate_phys_addr(u16 phys_addr)
+{
+   int i;
+
+   if (phys_addr == CEC_PHYS_ADDR_INVALID)
+   return 0;
+   for (i = 0; i < 16; i += 4)
+   if (phys_addr & (0xf << i))
+   break;
+   if (i == 16)
+   return 0;
+   for (i += 4; i < 16; i += 4)
+   if ((phys_addr & (0xf << i)) == 0)
+   return -EINVAL;
+   return 0;
+}
+
 static long cec_adap_s_phys_addr(struct cec_adapter *adap, struct cec_fh *fh,
 bool block, __u16 __user *parg)
 {
@@ -112,7 +129,7 @@ static long cec_adap_s_phys_addr(struct cec_adapter *adap, 
struct cec_fh *fh,
if (copy_from_user(_addr, parg, sizeof(phys_addr)))
return -EFAULT;
 
-   err = cec_phys_addr_validate(phys_addr, NULL, NULL);
+   err = cec_validate_phys_addr(phys_addr);
if (err)
return err;
mutex_lock(>lock);
-- 
2.18.0

[PATCH 1/4] cec: make cec_get_edid_spa_location() an inline function

[Hans Verkuil]

From: Hans Verkuil 

This function is needed by both V4L2 and CEC, so move this to
cec.h as a static inline since there are no obvious shared
modules between the two subsystems.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-edid.c | 60 ---
 include/media/cec.h  | 70 
 2 files changed, 70 insertions(+), 60 deletions(-)

diff --git a/drivers/media/cec/cec-edid.c b/drivers/media/cec/cec-edid.c
index ec72ac1c0b91..f587e8eaefd8 100644
--- a/drivers/media/cec/cec-edid.c
+++ b/drivers/media/cec/cec-edid.c
@@ -10,66 +10,6 @@
 #include 
 #include 
 
-/*
- * This EDID is expected to be a CEA-861 compliant, which means that there are
- * at least two blocks and one or more of the extensions blocks are CEA-861
- * blocks.
- *
- * The returned location is guaranteed to be < size - 1.
- */
-static unsigned int cec_get_edid_spa_location(const u8 *edid, unsigned int 
size)
-{
-   unsigned int blocks = size / 128;
-   unsigned int block;
-   u8 d;
-
-   /* Sanity check: at least 2 blocks and a multiple of the block size */
-   if (blocks < 2 || size % 128)
-   return 0;
-
-   /*
-* If there are fewer extension blocks than the size, then update
-* 'blocks'. It is allowed to have more extension blocks than the size,
-* since some hardware can only read e.g. 256 bytes of the EDID, even
-* though more blocks are present. The first CEA-861 extension block
-* should normally be in block 1 anyway.
-*/
-   if (edid[0x7e] + 1 < blocks)
-   blocks = edid[0x7e] + 1;
-
-   for (block = 1; block < blocks; block++) {
-   unsigned int offset = block * 128;
-
-   /* Skip any non-CEA-861 extension blocks */
-   if (edid[offset] != 0x02 || edid[offset + 1] != 0x03)
-   continue;
-
-   /* search Vendor Specific Data Block (tag 3) */
-   d = edid[offset + 2] & 0x7f;
-   /* Check if there are Data Blocks */
-   if (d <= 4)
-   continue;
-   if (d > 4) {
-   unsigned int i = offset + 4;
-   unsigned int end = offset + d;
-
-   /* Note: 'end' is always < 'size' */
-   do {
-   u8 tag = edid[i] >> 5;
-   u8 len = edid[i] & 0x1f;
-
-   if (tag == 3 && len >= 5 && i + len <= end &&
-   edid[i + 1] == 0x03 &&
-   edid[i + 2] == 0x0c &&
-   edid[i + 3] == 0x00)
-   return i + 4;
-   i += len + 1;
-   } while (i < end);
-   }
-   }
-   return 0;
-}
-
 u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size,
   unsigned int *offset)
 {
diff --git a/include/media/cec.h b/include/media/cec.h
index ff9847f7f99d..603f2fa08f62 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -461,4 +461,74 @@ static inline void cec_phys_addr_invalidate(struct 
cec_adapter *adap)
cec_s_phys_addr(adap, CEC_PHYS_ADDR_INVALID, false);
 }
 
+/**
+ * cec_get_edid_spa_location() - find location of the Source Physical Address
+ *
+ * @edid: the EDID
+ * @size: the size of the EDID
+ *
+ * This EDID is expected to be a CEA-861 compliant, which means that there are
+ * at least two blocks and one or more of the extensions blocks are CEA-861
+ * blocks.
+ *
+ * The returned location is guaranteed to be <= size-2.
+ *
+ * This is an inline function since it is used by both CEC and V4L2.
+ * Ideally this would go in a module shared by both, but it is overkill to do
+ * that for just a single function.
+ */
+static inline unsigned int cec_get_edid_spa_location(const u8 *edid,
+unsigned int size)
+{
+   unsigned int blocks = size / 128;
+   unsigned int block;
+   u8 d;
+
+   /* Sanity check: at least 2 blocks and a multiple of the block size */
+   if (blocks < 2 || size % 128)
+   return 0;
+
+   /*
+* If there are fewer extension blocks than the size, then update
+* 'blocks'. It is allowed to have more extension blocks than the size,
+* since some hardware can only read e.g. 256 bytes of the EDID, even
+* though more blocks are present. The first CEA-861 extension block
+* should normally be in block 1 anyway.
+*/
+   if (edid[0x7e] + 1 < blocks)
+   blocks = edid[0x7e] + 1;
+
+   for (block = 1; block < blocks; block++) {
+   unsigned int offset = block * 128;
+
+   /* Skip any non-CEA-861 extension blocks */
+   if (edid[offset] != 0x02 || edid[offset + 1] != 0x03)
+  

[PATCH 0/4] cec/v4l2: move v4l2-specific functions from cec to v4l2

[Hans Verkuil]

From: Hans Verkuil 

Several cec functions that deal with parsing EDIDs and handling physical
addresses where stubbed out if CEC_CORE was not configured. The problem
with that is that those functions are needed, regardless of CEC, by
receivers to validate the EDID.

This patch series moves those functions out of the cec subsystem into
the media subsystem: this only affects HDMI receivers, so the media
subsystem is a much better place.

This problem was reported by Lars-Peter Clausen.

Regards,

Hans

Hans Verkuil (4):
  cec: make cec_get_edid_spa_location() an inline function
  cec: integrate cec_validate_phys_addr() in cec-api.c
  cec/v4l2: move V4L2 specific CEC functions to V4L2
  cec: remove cec-edid.c

 drivers/media/cec/Makefile|   2 +-
 drivers/media/cec/cec-adap.c  |  13 ++
 drivers/media/cec/cec-api.c   |  19 ++-
 drivers/media/cec/cec-edid.c  | 155 --
 drivers/media/i2c/adv7604.c   |   4 +-
 drivers/media/i2c/adv7842.c   |   4 +-
 drivers/media/i2c/tc358743.c  |   2 +-
 drivers/media/platform/vivid/vivid-vid-cap.c  |   4 +-
 .../media/platform/vivid/vivid-vid-common.c   |   2 +-
 drivers/media/v4l2-core/v4l2-dv-timings.c | 151 +
 include/media/cec.h   | 150 -
 include/media/v4l2-dv-timings.h   |   6 +
 12 files changed, 267 insertions(+), 245 deletions(-)
 delete mode 100644 drivers/media/cec/cec-edid.c

-- 
2.18.0

[PATCH 3/4] cec/v4l2: move V4L2 specific CEC functions to V4L2

[Hans Verkuil]

From: Hans Verkuil 

Several CEC functions are actually specific for use with receivers,
i.e. they should be part of the V4L2 subsystem, not CEC.

These functions deal with validating and modifying EDIDs for (HDMI)
receivers, and they do not actually have anything to do with the CEC
subsystem and whether or not CEC is enabled. The problem was that if
the CEC_CORE config option was not set, then these functions would
become stubs, but that's not right: they should always be valid.

So replace the cec_ prefix by v4l2_ and move them to v4l2-dv-timings.c.
Update all drivers that call these accordingly.

Signed-off-by: Hans Verkuil 
Reported-by: Lars-Peter Clausen 
---
 drivers/media/cec/cec-edid.c  |  71 
 drivers/media/i2c/adv7604.c   |   4 +-
 drivers/media/i2c/adv7842.c   |   4 +-
 drivers/media/i2c/tc358743.c  |   2 +-
 drivers/media/platform/vivid/vivid-vid-cap.c  |   4 +-
 .../media/platform/vivid/vivid-vid-common.c   |   2 +-
 drivers/media/v4l2-core/v4l2-dv-timings.c | 151 ++
 include/media/cec.h   |  80 --
 include/media/v4l2-dv-timings.h   |   6 +
 9 files changed, 165 insertions(+), 159 deletions(-)

diff --git a/drivers/media/cec/cec-edid.c b/drivers/media/cec/cec-edid.c
index f587e8eaefd8..e2f54eec0829 100644
--- a/drivers/media/cec/cec-edid.c
+++ b/drivers/media/cec/cec-edid.c
@@ -22,74 +22,3 @@ u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size,
return (edid[loc] << 8) | edid[loc + 1];
 }
 EXPORT_SYMBOL_GPL(cec_get_edid_phys_addr);
-
-void cec_set_edid_phys_addr(u8 *edid, unsigned int size, u16 phys_addr)
-{
-   unsigned int loc = cec_get_edid_spa_location(edid, size);
-   u8 sum = 0;
-   unsigned int i;
-
-   if (loc == 0)
-   return;
-   edid[loc] = phys_addr >> 8;
-   edid[loc + 1] = phys_addr & 0xff;
-   loc &= ~0x7f;
-
-   /* update the checksum */
-   for (i = loc; i < loc + 127; i++)
-   sum += edid[i];
-   edid[i] = 256 - sum;
-}
-EXPORT_SYMBOL_GPL(cec_set_edid_phys_addr);
-
-u16 cec_phys_addr_for_input(u16 phys_addr, u8 input)
-{
-   /* Check if input is sane */
-   if (WARN_ON(input == 0 || input > 0xf))
-   return CEC_PHYS_ADDR_INVALID;
-
-   if (phys_addr == 0)
-   return input << 12;
-
-   if ((phys_addr & 0x0fff) == 0)
-   return phys_addr | (input << 8);
-
-   if ((phys_addr & 0x00ff) == 0)
-   return phys_addr | (input << 4);
-
-   if ((phys_addr & 0x000f) == 0)
-   return phys_addr | input;
-
-   /*
-* All nibbles are used so no valid physical addresses can be assigned
-* to the input.
-*/
-   return CEC_PHYS_ADDR_INVALID;
-}
-EXPORT_SYMBOL_GPL(cec_phys_addr_for_input);
-
-int cec_phys_addr_validate(u16 phys_addr, u16 *parent, u16 *port)
-{
-   int i;
-
-   if (parent)
-   *parent = phys_addr;
-   if (port)
-   *port = 0;
-   if (phys_addr == CEC_PHYS_ADDR_INVALID)
-   return 0;
-   for (i = 0; i < 16; i += 4)
-   if (phys_addr & (0xf << i))
-   break;
-   if (i == 16)
-   return 0;
-   if (parent)
-   *parent = phys_addr & (0xfff0 << i);
-   if (port)
-   *port = (phys_addr >> i) & 0xf;
-   for (i += 4; i < 16; i += 4)
-   if ((phys_addr & (0xf << i)) == 0)
-   return -EINVAL;
-   return 0;
-}
-EXPORT_SYMBOL_GPL(cec_phys_addr_validate);
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 668be2bca57a..c31673fcd5c1 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2295,8 +2295,8 @@ static int adv76xx_set_edid(struct v4l2_subdev *sd, 
struct v4l2_edid *edid)
edid->blocks = 2;
return -E2BIG;
}
-   pa = cec_get_edid_phys_addr(edid->edid, edid->blocks * 128, _loc);
-   err = cec_phys_addr_validate(pa, , NULL);
+   pa = v4l2_get_edid_phys_addr(edid->edid, edid->blocks * 128, _loc);
+   err = v4l2_phys_addr_validate(pa, , NULL);
if (err)
return err;
 
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index f1c168bfaaa4..cd63cc6564e9 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -789,8 +789,8 @@ static int edid_write_hdmi_segment(struct v4l2_subdev *sd, 
u8 port)
if (!state->hdmi_edid.present)
return 0;
 
-   pa = cec_get_edid_phys_addr(edid, 256, _loc);
-   err = cec_phys_addr_validate(pa, , NULL);
+   pa = v4l2_get_edid_phys_addr(edid, 256, _loc);
+   err = v4l2_phys_addr_validate(pa, , NULL);
if (err)
return err;
 
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index 44c41933415a..ef4dbac6bb58 100644
--- 

Re: [PATCH v5 5/6] media: Add controls for JPEG quantization tables

[Paul Kocialkowski]

Hi,

On Wed, 2018-09-05 at 19:00 -0300, Ezequiel Garcia wrote:
> From: Shunqian Zheng 
> 
> Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace
> configure the JPEG quantization tables.
> 
> Signed-off-by: Shunqian Zheng 
> Signed-off-by: Ezequiel Garcia 
> ---
>  .../media/uapi/v4l/extended-controls.rst  | 31 +++
>  .../media/videodev2.h.rst.exceptions  |  1 +
>  drivers/media/v4l2-core/v4l2-ctrls.c  | 10 ++
>  include/uapi/linux/v4l2-controls.h| 12 +++
>  include/uapi/linux/videodev2.h|  1 +
>  5 files changed, 55 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> b/Documentation/media/uapi/v4l/extended-controls.rst
> index 9f7312bf3365..1335d27d30f3 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -3354,7 +3354,38 @@ JPEG Control IDs
>  Specify which JPEG markers are included in compressed stream. This
>  control is valid only for encoders.
>  
> +.. _jpeg-quant-tables-control:

I just had a look at how the Allwinner VPU handles JPEG decoding and it
seems to require the following information (in addition to
quantization):

* Horizontal and vertical sampling factors for each Y/U/V component:

The number of components and sampling factors are coded separately in
the bitstream, but it's probably easier to use the already-existing
V4L2_CID_JPEG_CHROMA_SUBSAMPLING control for specifying that.

However, this is potentially very much related to the destination
format. If we decide that this format should match the format resulting
from decompression, we don't need to specify it through an external
control. On the other hand, it's possible that the VPU has format
conversion block integrated in its pipeline so it would also make sense
to consider the destination format as independent.

* Custom Huffman tables (DC and AC), both for luma and chroma

It seems that there is a default table when no Huffman table is provided
in the bitstream (I'm not too sure how standard that is, just started
learning about JPEG). We probably need a specific control for that.

* Reset interval

That's extracted from the bitstream as well and there's a
V4L2_CID_JPEG_RESTART_INTERVAL control already.

In addition to these points, I see that among all the JPEG profiles,
some have to do with arithmetic coding which will probably require a
specific control on its own (not sure how it should look at this point
though).

What do you think?

Cheers,

Paul

> +``V4L2_CID_JPEG_QUANTIZATION (struct)``
> +Specifies the luma and chroma quantization matrices for encoding
> +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The :ref:`itu-t81`
> +specification allows 8-bit quantization coefficients for
> +baseline profile images, and 8-bit or 16-bit for extended profile
> +images. Supporting or not 16-bit precision coefficients is 
> driver-specific.
> +Coefficients must be set in JPEG zigzag scan order.
> +
> +
> +.. c:type:: struct v4l2_ctrl_jpeg_quantization
> +
> +.. cssclass:: longtable
> +
> +.. flat-table:: struct v4l2_ctrl_jpeg_quantization
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 1 2
> +
> +* - __u8
> +  - ``precision``
> +  - Specifies the coefficient precision. User shall set 0
> +for 8-bit, and 1 for 16-bit.
> +
> +* - __u16
> +  - ``luma_quantization_matrix[64]``
> +  - Sets the luma quantization table.
> +
> +* - __u16
> +  - ``chroma_quantization_matrix[64]``
> +  - Sets the chroma quantization table.
>  
>  .. flat-table::
>  :header-rows:  0
> diff --git a/Documentation/media/videodev2.h.rst.exceptions 
> b/Documentation/media/videodev2.h.rst.exceptions
> index ca9f0edc579e..a0a38e92bf38 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -129,6 +129,7 @@ replace symbol V4L2_CTRL_TYPE_STRING 
> :c:type:`v4l2_ctrl_type`
>  replace symbol V4L2_CTRL_TYPE_U16 :c:type:`v4l2_ctrl_type`
>  replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type`
>  replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type`
> +replace symbol V4L2_CTRL_TYPE_JPEG_QUANTIZATION :c:type:`v4l2_ctrl_type`
>  
>  # V4L2 capability defines
>  replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 599c1cbff3b9..305bd7a9b7f1 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -999,6 +999,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>   case V4L2_CID_JPEG_RESTART_INTERVAL:return "Restart Interval";
>   case V4L2_CID_JPEG_COMPRESSION_QUALITY: return "Compression Quality";
>   case V4L2_CID_JPEG_ACTIVE_MARKER:   return "Active Markers";
> + case V4L2_CID_JPEG_QUANTIZATION:return "JPEG Quantization 
> Tables";

Re: Number of planes from fourcc code

[Oleksandr Andrushchenko]

On 09/13/2018 02:46 PM, Hans Verkuil wrote:

On 09/13/18 13:29, Oleksandr Andrushchenko wrote:

Hi, all!

Is there a way in V4L2 to get number of planes from fourcc code

or specifically I need number of planes for a given pixel format

expressed as V4L2_PIX_FMT_* value.

Sadly not. It's part of the documentation for the formats, but there
is no naming scheme through which you can deduce this or even helper
functions for it.

Ok, then I'll probably try to explain what I want to do:
I am implementing a Xen frontend driver which implements
a para-virtual camera protocol [1] which can support
multiple pixel formats. Thus, the driver will support
both single and multi plane formats. For that I need to implement
both single and multi plane format enumerators:
    .vidioc_enum_fmt_vid_cap
    .vidioc_enum_fmt_vid_cap_mplane

and for .vidioc_enum_fmt_vid_cap I have to filter out of supported
pixel formats those which are multi-planar. So, I hoped I can
use some helper (like DRM provides) to get number of planes for
a given pixel format.

So, it seems that I'll have to code similar table as DRM does
for various V4L2 encoded pixel formats to get num_planes...


I think the main reason why this never happened is that drivers tend to
have custom code for this anyway.

I have proposed in the past that some of this information is exposed
via VIDIOC_ENUM_FMT, but it never got traction.


I know that DRM has such a helper [1], but I am not quite sure

if I can call it with V4L2_PIX_FMT_* as argument to get what I need.

I am a bit confused here because there are different definitions

for DRM [2] and V4L2 [3].

I know. Each subsystem has traditionally been assigning fourccs independently.
In all fairness, this seems to be the case for fourccs throughout the whole
industry.

Regards,

Hans


Thank you,

Oleksandr

[1]
https://elixir.bootlin.com/linux/v4.19-rc3/source/drivers/gpu/drm/drm_fourcc.c#L199

[2]
https://elixir.bootlin.com/linux/v4.19-rc3/source/include/uapi/drm/drm_fourcc.h

[3]
https://elixir.bootlin.com/linux/v4.19-rc3/source/include/uapi/linux/videodev2.h


[1] https://patchwork.kernel.org/patch/10595259/

Re: Number of planes from fourcc code

[Hans Verkuil]

On 09/13/18 13:29, Oleksandr Andrushchenko wrote:
> Hi, all!
> 
> Is there a way in V4L2 to get number of planes from fourcc code
> 
> or specifically I need number of planes for a given pixel format
> 
> expressed as V4L2_PIX_FMT_* value.

Sadly not. It's part of the documentation for the formats, but there
is no naming scheme through which you can deduce this or even helper
functions for it.

I think the main reason why this never happened is that drivers tend to
have custom code for this anyway.

I have proposed in the past that some of this information is exposed
via VIDIOC_ENUM_FMT, but it never got traction.

> I know that DRM has such a helper [1], but I am not quite sure
> 
> if I can call it with V4L2_PIX_FMT_* as argument to get what I need.
> 
> I am a bit confused here because there are different definitions
> 
> for DRM [2] and V4L2 [3].

I know. Each subsystem has traditionally been assigning fourccs independently.
In all fairness, this seems to be the case for fourccs throughout the whole
industry.

Regards,

Hans

> 
> Thank you,
> 
> Oleksandr
> 
> [1] 
> https://elixir.bootlin.com/linux/v4.19-rc3/source/drivers/gpu/drm/drm_fourcc.c#L199
> 
> [2] 
> https://elixir.bootlin.com/linux/v4.19-rc3/source/include/uapi/drm/drm_fourcc.h
> 
> [3] 
> https://elixir.bootlin.com/linux/v4.19-rc3/source/include/uapi/linux/videodev2.h
> 

Re: [PATCH v1 2/2] v4l: Document Intel IPU3 meta data uAPI

[sakari.ai...@linux.intel.com]

Hi Raj,

My apologies for the delayed reply.

On Fri, Aug 31, 2018 at 11:39:54PM +, Mani, Rajmohan wrote:
...
> > > +struct ipu3_uapi_af_meta_data {
> > > + __u8 y_table[IPU3_UAPI_AF_Y_TABLE_MAX_SIZE] IPU3_ALIGN;
> > 
> > Here IPU3_ALIGN is put at the end...
> > 
> > > +} __packed;
> > > +
> > > +/**
> > > + * struct ipu3_uapi_af_raw_buffer - AF raw buffer
> > > + *
> > > + * @meta_data: raw buffer _uapi_af_meta_data for auto focus meta
> > data.
> > > + */
> > > +struct ipu3_uapi_af_raw_buffer {
> > > + IPU3_ALIGN struct ipu3_uapi_af_meta_data meta_data;
> > 
> > ... and here at the start. Is that due to the difference between an array 
> > and a
> > struct?
> > 
> 
> No.
> 
> When preparing uAPI kernelDoc using "make htmldocs",
> the kernel-doc encounters two type of error/warnings
> caused by IPU3_ALIGN.
> 
> case 1:
> struct IPU3_ALIGN ipu3_uapi_dummy {
>   ...
> } __packed;
> 
> "error: Cannot parse struct or union!"
> 
> case 2:
> struct ipu3_uapi_dummy {
>   struct ipu3_uapi_x x IPU3_ALIGN;
> } __packed;
> 
> "warning: Function parameter or member 'IPU3_ALIGN' not
> described in 'ipu3_uapi_dummy'"
> 
> Positioned the attribute syntax without altering the
> mem layout of the structs, while also making "make htmldocs" to
> compile fine.
> 
> Let us know if it's okay to ignore Sphinx warnings.

I looked a bit at different options for handling this in scripts/kernel-doc
but the difficulty in macro substitution comes in determining where to do
the substitution and where not to. That seems unaddressable in the kernel-doc
script; most of the time you want the definitions as-is while this is
likely the only case where something else might be appropriate. Making
IPU3_ALIGN a special case probably wouldn't really fly either.

In this particular case I'd just write open the alignment requirement so
kernel-doc can correctly parse it.

-- 
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Number of planes from fourcc code

[Oleksandr Andrushchenko]

Hi, all!

Is there a way in V4L2 to get number of planes from fourcc code

or specifically I need number of planes for a given pixel format

expressed as V4L2_PIX_FMT_* value.

I know that DRM has such a helper [1], but I am not quite sure

if I can call it with V4L2_PIX_FMT_* as argument to get what I need.

I am a bit confused here because there are different definitions

for DRM [2] and V4L2 [3].

Thank you,

Oleksandr

[1] 
https://elixir.bootlin.com/linux/v4.19-rc3/source/drivers/gpu/drm/drm_fourcc.c#L199


[2] 
https://elixir.bootlin.com/linux/v4.19-rc3/source/include/uapi/drm/drm_fourcc.h


[3] 
https://elixir.bootlin.com/linux/v4.19-rc3/source/include/uapi/linux/videodev2.h

Re: [PATCH 1/2] dt-bindings: dw9714, dw9807-vcm: Add files to MAINTAINERS, rename files

[Sakari Ailus]

On Thu, Aug 30, 2018 at 01:55:32PM +0300, Sakari Ailus wrote:
> Ping?

I will assume this patch is fine. :-)

> 
> On Mon, Jul 23, 2018 at 01:50:38PM +0300, Sakari Ailus wrote:
> > Add the DT binding documentation for dw9714 and dw9807-vcm to the
> > MAINTAINERS file. The dw9807-vcm binding documentation file is renamed to
> > match the dw9807's VCM bit's compatible string.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  .../bindings/media/i2c/{dongwoon,dw9807.txt => dongwoon,dw9807-vcm.txt} | 0
> >  MAINTAINERS | 
> > 2 ++
> >  2 files changed, 2 insertions(+)
> >  rename Documentation/devicetree/bindings/media/i2c/{dongwoon,dw9807.txt => 
> > dongwoon,dw9807-vcm.txt} (100%)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt 
> > b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807-vcm.txt
> > similarity index 100%
> > rename from Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> > rename to 
> > Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807-vcm.txt
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index bbd9b9b3d74f..44e917de2c8c 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4410,6 +4410,7 @@ L:linux-media@vger.kernel.org
> >  T: git git://linuxtv.org/media_tree.git
> >  S: Maintained
> >  F: drivers/media/i2c/dw9714.c
> > +F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt
> >  
> >  DONGWOON DW9807 LENS VOICE COIL DRIVER
> >  M: Sakari Ailus 
> > @@ -4417,6 +4418,7 @@ L:linux-media@vger.kernel.org
> >  T: git git://linuxtv.org/media_tree.git
> >  S: Maintained
> >  F: drivers/media/i2c/dw9807.c
> > +F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807-vcm.txt
> >  
> >  DOUBLETALK DRIVER
> >  M: "James R. Van Zandt" 

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

Re: [RFC 1/1] v4l: samsung, ov9650: Rely on V4L2-set sub-device names

[Sylwester Nawrocki]

Hi Sakari,

On Thu, 13 Sep 2018 at 11:21, Sakari Ailus  wrote:
[...]
> diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c 
> b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
> index ce196b60f917..64212551524e 100644
> --- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
> +++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
> @@ -1683,7 +1683,7 @@ static int s5c73m3_probe(struct i2c_client *client,
> v4l2_subdev_init(sd, _subdev_ops);
> sd->owner = client->dev.driver->owner;
> v4l2_set_subdevdata(sd, state);
> -   strlcpy(sd->name, "S5C73M3", sizeof(sd->name));
> +   v4l2_i2c_subdev_set_name(sd, client, NULL, NULL);
>
> sd->internal_ops = _internal_ops;
> sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> @@ -1698,7 +1698,7 @@ static int s5c73m3_probe(struct i2c_client *client,
> return ret;
>
> v4l2_i2c_subdev_init(oif_sd, client, _subdev_ops);
> -   strcpy(oif_sd->name, "S5C73M3-OIF");
> +   v4l2_i2c_subdev_set_name(sd, client, NULL, "-OIF");

I would suggest to change the "OIF-" prefix to lower case, to avoid
something like
"s5c73m3-OIF". IIRC client->name is derived from DT compatible string, which is
in lower case.
Otherwise looks OK to me.

--
Thanks,
Sylwester

[PATCH] staging: cedrus: Fix checkpatch issues

[Maxime Ripard]

Checkpatch, when used with --strict, reports a number of issues on the
cedrus driver.

Fix those warnings, except for a few, minor, lines too long warnings.

Signed-off-by: Maxime Ripard 
---
 drivers/staging/media/sunxi/cedrus/cedrus.c   | 10 +-
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  8 +---
 .../staging/media/sunxi/cedrus/cedrus_dec.c   | 10 ++
 .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 19 ++-
 .../staging/media/sunxi/cedrus/cedrus_regs.h  | 16 +---
 .../staging/media/sunxi/cedrus/cedrus_video.c |  6 ++
 6 files changed, 41 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 0a9363c7db06..d312dec5ab79 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -48,7 +48,7 @@ void *cedrus_find_control_data(struct cedrus_ctx *ctx, u32 id)
 {
unsigned int i;
 
-   for (i = 0; ctx->ctrls[i] != NULL; i++)
+   for (i = 0; ctx->ctrls[i]; i++)
if (ctx->ctrls[i]->id == id)
return ctx->ctrls[i]->p_cur.p;
 
@@ -147,10 +147,10 @@ static int cedrus_request_validate(struct media_request 
*req)
continue;
 
ctrl_test = v4l2_ctrl_request_hdl_ctrl_find(hdl,
-   cedrus_controls[i].id);
+   
cedrus_controls[i].id);
if (!ctrl_test) {
v4l2_info(>dev->v4l2_dev,
-"Missing required codec control\n");
+ "Missing required codec control\n");
return -ENOENT;
}
}
@@ -310,8 +310,8 @@ static int cedrus_probe(struct platform_device *pdev)
dev->mdev.ops = _m2m_media_ops;
dev->v4l2_dev.mdev = >mdev;
 
-   ret = v4l2_m2m_register_media_controller(dev->m2m_dev,
-   vfd, MEDIA_ENT_F_PROC_VIDEO_DECODER);
+   ret = v4l2_m2m_register_media_controller(dev->m2m_dev, vfd,
+
MEDIA_ENT_F_PROC_VIDEO_DECODER);
if (ret) {
v4l2_err(>v4l2_dev,
 "Failed to initialize V4L2 M2M media controller\n");
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h 
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 3262341e8c9a..8d171efecc37 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -44,7 +44,7 @@ struct cedrus_control {
u32 id;
u32 elem_size;
enum cedrus_codec   codec;
-   boolrequired;
+   unsigned char   required;
 };
 
 struct cedrus_mpeg2_run {
@@ -150,12 +150,14 @@ static inline dma_addr_t cedrus_dst_buf_addr(struct 
cedrus_ctx *ctx,
return buf ? cedrus_buf_addr(buf, >dst_fmt, plane) : 0;
 }
 
-static inline struct cedrus_buffer *vb2_v4l2_to_cedrus_buffer(const struct 
vb2_v4l2_buffer *p)
+static inline struct cedrus_buffer *
+vb2_v4l2_to_cedrus_buffer(const struct vb2_v4l2_buffer *p)
 {
return container_of(p, struct cedrus_buffer, m2m_buf.vb);
 }
 
-static inline struct cedrus_buffer *vb2_to_cedrus_buffer(const struct 
vb2_buffer *p)
+static inline struct cedrus_buffer *
+vb2_to_cedrus_buffer(const struct vb2_buffer *p)
 {
return vb2_v4l2_to_cedrus_buffer(to_vb2_v4l2_buffer(p));
 }
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..788811a1414e 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -43,10 +43,12 @@ void cedrus_device_run(void *priv)
 
switch (ctx->src_fmt.pixelformat) {
case V4L2_PIX_FMT_MPEG2_SLICE:
-   run.mpeg2.slice_params = cedrus_find_control_data(ctx,
-   V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
-   run.mpeg2.quantization = cedrus_find_control_data(ctx,
-   V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
+   run.mpeg2.slice_params =
+   cedrus_find_control_data(ctx,
+
V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
+   run.mpeg2.quantization =
+   cedrus_find_control_data(ctx,
+
V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
break;
 
default:
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
index 029eb1626bf4..9abd39cae38c 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
@@ -157,14 +157,22 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx, 
struct cedrus_run 

Re: [PATCH v1 2/2] v4l: Document Intel IPU3 meta data uAPI

[Sakari Ailus]

Hi Raj, Mauro,

On Fri, Aug 31, 2018 at 10:40:22PM +, Mani, Rajmohan wrote:
> Hi Sakari, Mauro,
> 
> > -Original Message-
> > From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com]
> > Sent: Tuesday, August 28, 2018 2:16 AM
> > To: Tomasz Figa 
> > Cc: Mauro Carvalho Chehab ; Hans Verkuil
> > ; Mani, Rajmohan ; Zhi,
> > Yong ; Linux Media Mailing List  > me...@vger.kernel.org>; Mauro Carvalho Chehab ;
> > Hans Verkuil ; Laurent Pinchart
> > ; Zheng, Jian Xu
> > ; Hu, Jerry W ; Li, Chao C
> > ; Qiu, Tian Shu 
> > Subject: Re: [PATCH v1 2/2] v4l: Document Intel IPU3 meta data uAPI
> > 
> > Hi Tomasz,
> > 
> > On Tue, Aug 28, 2018 at 05:56:37PM +0900, Tomasz Figa wrote:
> > > On Tue, Aug 14, 2018 at 5:50 AM Mauro Carvalho Chehab
> > >  wrote:
> > > >
> > > > Em Mon, 13 Aug 2018 15:42:34 +0200
> > > > Hans Verkuil  escreveu:
> > > >
> > > > > On 15/06/18 05:29, Yong Zhi wrote:
> > > > > > These meta formats are used on Intel IPU3 ImgU video queues to
> > > > > > carry 3A statistics and ISP pipeline parameters.
> > > > > >
> > > > > > V4L2_META_FMT_IPU3_3A
> > > > > > V4L2_META_FMT_IPU3_PARAMS
> > > > > >
> > > > > > Signed-off-by: Yong Zhi 
> > > > > > Signed-off-by: Chao C Li 
> > > > > > Signed-off-by: Rajmohan Mani 
> > > > > > ---
> > > > > >  Documentation/media/uapi/v4l/meta-formats.rst  |1 +
> > > > > >  .../media/uapi/v4l/pixfmt-meta-intel-ipu3.rst  |  174 ++
> > > > > >  include/uapi/linux/intel-ipu3.h| 2816
> > 
> > > > > >  3 files changed, 2991 insertions(+)  create mode 100644
> > > > > > Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> > > > > >  create mode 100644 include/uapi/linux/intel-ipu3.h
> > > > > >
> > > > > > diff --git a/Documentation/media/uapi/v4l/meta-formats.rst
> > > > > > b/Documentation/media/uapi/v4l/meta-formats.rst
> > > > > > index 0c4e1ec..b887fca 100644
> > > > > > --- a/Documentation/media/uapi/v4l/meta-formats.rst
> > > > > > +++ b/Documentation/media/uapi/v4l/meta-formats.rst
> > > > > > @@ -12,6 +12,7 @@ These formats are used for the :ref:`metadata`
> > interface only.
> > > > > >  .. toctree::
> > > > > >  :maxdepth: 1
> > > > > >
> > > > > > +pixfmt-meta-intel-ipu3
> > > > > >  pixfmt-meta-uvc
> > > > > >  pixfmt-meta-vsp1-hgo
> > > > > >  pixfmt-meta-vsp1-hgt
> > > > > > diff --git
> > > > > > a/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> > > > > > b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> > > > > > new file mode 100644
> > > > > > index 000..5c050e6
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> > > > > > @@ -0,0 +1,174 @@
> > > > > > +.. -*- coding: utf-8; mode: rst -*-
> > > > > > +
> > > > > > +.. _intel-ipu3:
> > > > > > +
> > > > > >
> > +***
> > > > > > +*** V4L2_META_FMT_IPU3_PARAMS ('ip3p'),
> > V4L2_META_FMT_IPU3_3A
> > > > > > +('ip3s')
> > > > > >
> > +***
> > > > > > +***
> > > > > > +
> > > > > > +.. c:type:: ipu3_uapi_stats_3a
> > > > > > +
> > > > > > +3A statistics
> > > > > > +=
> > > > > > +
> > > > > > +For IPU3 ImgU, the 3A statistics accelerators collect different
> > > > > > +statistics over an input bayer frame. Those statistics, defined
> > > > > > +in data struct :c:type:`ipu3_uapi_stats_3a`, are meta output 
> > > > > > obtained
> > from "ipu3-imgu 3a stat"
> > > > > > +video node, which are then passed to user space for statistics
> > > > > > +analysis using :c:type:`v4l2_meta_format` interface.
> > > > > > +
> > > > > > +The statistics collected are AWB (Auto-white balance) RGBS
> > > > > > +cells, AWB filter
> > > >
> > > > Just like you did with AWB, AF and AE, please place the full name in
> > > > parenthesis for RGBS and AWB.
> > > >
> > > > > > +response, AF (Auto-focus) filter response, and AE (Auto-exposure)
> > histogram.
> > > > > > +
> > > > > > +struct :c:type:`ipu3_uapi_4a_config` saves configurable parameters 
> > > > > > for
> > all above.
> > > > > > +
> > > > > > +
> > > > > > +.. code-block:: c
> > > > > > +
> > > > > > +
> > > > > > + struct ipu3_uapi_stats_3a {
> > > > > > +   IPU3_ALIGN struct ipu3_uapi_awb_raw_buffer awb_raw_buffer;
> > > > >
> > > > > IPU3_ALIGN? What's that?
> > > > >
> > > > > OK, after reading the header I see what it does, but I think you
> > > > > should drop it in the documentation since it doesn't help the reader.
> > > >
> > > > Yeah, that IPU3_ALIGN is confusing.
> > > >
> > > > Yet, instead of just dropping, I would replace it by a comment to
> > > > explain that the struct is 32-bytes aligned.
> > > >
> > > > On a separate (but related) comment, you're declaring it as:
> > > >
> > > > #define IPU3_ALIGN
> > __attribute__((aligned(IPU3_UAPI_ISP_WORD_BYTES)))
> > > >
> > > > This is a gcc-specific dialect. Better to use, instead, __aligned(x)
> > > > which is 

RFC: stop support for 2.6 kernel in the daily build

[Hans Verkuil]

SUSE Linux Enterprise Server 12 is on kernel 3.12, and version 11 SP2 or up
is on kernel 3.0.

Red Hat's RHEL 7 is on kernel 3.10.

I'm inclined to drop support for 2.6 altogether. If nothing else it
simplifies the kernel version handling in media_build.

Whether we should also drop support for 3.0-3.9 is another matter.
I wouldn't mind, 3.10 seems to be a reasonable minimum to me, but
I might be too optimistic here.

Comments?

Regards,

Hans