Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

Ping!

I really like to get this in for 4.16 so I can move forward with hooking
this up for nouveau/amd.

Regards,

Hans

On 11/20/2017 12:42 PM, Hans Verkuil wrote:
> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature. This patch series is based on the 4.14 mainline release but applies
> as well to drm-next.
> 
> This patch series has been tested with my NUC7i5BNK, a Samsung USB-C to 
> HDMI adapter and a Club 3D DisplayPort MST Hub + modified UpTab DP-to-HDMI
> adapter (where the CEC pin is wired up).
> 
> Please note this comment at the start of drm_dp_cec.c:
> 
> --
> Unfortunately it turns out that we have a chicken-and-egg situation
> here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
> have a converter chip that supports CEC-Tunneling-over-AUX (usually the
> Parade PS176 or MegaChips MCDP2900), but they do not wire up the CEC pin,
> thus making CEC useless.
> 
> Sadly there is no way for this driver to know this. What happens is
> that a /dev/cecX device is created that is isolated and unable to see
> any of the other CEC devices. Quite literally the CEC wire is cut
> (or in this case, never connected in the first place).
> 
> I suspect that the reason so few adapters support this is that this
> tunneling protocol was never supported by any OS. So there was no
> easy way of testing it, and no incentive to correctly wire up the
> CEC pin.
> 
> Hopefully by creating this driver it will be easier for vendors to
> finally fix their adapters and test the CEC functionality.
> 
> I keep a list of known working adapters here:
> 
> https://hverkuil.home.xs4all.nl/cec-status.txt
> 
> Please mail me (hverk...@xs4all.nl) if you find an adapter that works
> and is not yet listed there.
> 
> Note that the current implementation does not support CEC over an MST hub.
> As far as I can see there is no mechanism defined in the DisplayPort
> standard to transport CEC interrupts over an MST device. It might be
> possible to do this through polling, but I have not been able to get that
> to work.
> --
> 
> I really hope that this work will provide an incentive for vendors to
> finally connect the CEC pin. It's a shame that there are so few adapters
> that work (I found only two USB-C to HDMI adapters that work, and no
> (mini-)DP to HDMI adapters at all).
> 
> Hopefully if this gets merged there will be an incentive for vendors
> to make adapters where this actually works. It is a very nice feature
> for HTPC boxes.
> 
> The main reason why this v5 is delayed by 2 months is due to the fact
> that I needed some dedicated time to investigate what happens when an
> MST hub is in use. It turns out that this is not working. There is no
> mechanism defined in the DisplayPort standard to transport the CEC
> interrupt back up the MST chain. I was actually able to send a CEC
> message but the interrupt that tells when the transmit finished is
> unavailable.
> 
> I attempted to implement this via polling, but I got weird errors
> and was not able to read the DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1
> register. I decided to give up on this for now and just disable CEC
> for DP-to-HDMI adapters after an MST hub. I plan to revisit this
> later since it would be neat to make this work as well. Although it
> might not be possible at all.
> 
> If anyone is interested, work-in-progress for this is here:
> 
> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=dp-cec-mst
> 
> Note that I removed the Tested-by tag from Carlos Santa due to the
> almost complete rework of the third patch. Carlos, can you test this again?
> 
> Regards,
> 
> Hans
> 
> Changes since v4:
> 
> - Updated comment at the start of drm_dp_cec.c
> - Add edid pointer to drm_dp_cec_configure_adapter
> - Reworked the last patch (adding CEC to i915) based on Ville's comments
>   and my MST testing:
>   - register/unregister CEC in intel_dp_connector_register/unregister
>   - add comment and check if connector is registered in long_pulse
>   - unregister CEC if an MST 'connector' is detected.
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

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 Dec  1 05:00:17 CET 2017
media-tree git hash:781b045baefdabf7e0bc9f33672ca830d3db9f27
media_build git hash:   320b9b80ebbf318a67a9479c18a0e4be244c8409
v4l-utils git hash: 26eca33b62f988ecbc4df8134ebdef20f9f75c97
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: 0.5.1 (Debian: 0.5.1-2)
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.13.0-164

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-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9.26-i686: ERRORS
linux-4.10.14-i686: ERRORS
linux-4.11-i686: ERRORS
linux-4.12.1-i686: ERRORS
linux-4.13-i686: ERRORS
linux-4.14-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9.26-x86_64: ERRORS
linux-4.10.14-x86_64: ERRORS
linux-4.11-x86_64: ERRORS
linux-4.12.1-x86_64: ERRORS
linux-4.13-x86_64: ERRORS
linux-4.14-x86_64: ERRORS
apps: OK
spec-git: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH v8 28/28] rcar-vin: enable support for r8a77970

[Rob Herring]

On Wed, Nov 29, 2017 at 08:43:42PM +0100, Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a77970.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  .../devicetree/bindings/media/rcar_vin.txt |  1 +

Acked-by: Rob Herring 

>  drivers/media/platform/rcar-vin/rcar-core.c| 40 
> ++
>  2 files changed, 41 insertions(+)

Re: [PATCH v8 27/28] rcar-vin: enable support for r8a7796

[Rob Herring]

On Wed, Nov 29, 2017 at 08:43:41PM +0100, Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a7796.
> 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 
> ---
>  .../devicetree/bindings/media/rcar_vin.txt |  1 +

Acked-by: Rob Herring 

>  drivers/media/platform/rcar-vin/rcar-core.c| 64 
> ++
>  2 files changed, 65 insertions(+)

[PATCH 1/1] media: uvcvideo: Add quirk to support light switch on Dino-Lite cameras

[Alexandre Macabies]

The Dino-Lite cameras are equipped with LED lights that can be switched
on and off by setting a proprietary control. For this control, the
camera reports a length of 1 byte, but actually the value set by the
original Windows driver is 3 byte long. This makes it impossible to
toggle the camera lights from uvcvideo, as the length from GET_LEN is
trusted as being the right one.

This is to make GET_LEN indicate a length of 3 instead of 1 for this
specific device.

Signed-off-by: Alexandre Macabies 
---
 drivers/media/usb/uvc/uvc_driver.c |  9 +
 drivers/media/usb/uvc/uvc_video.c  | 10 ++
 drivers/media/usb/uvc/uvcvideo.h   |  1 +
 3 files changed, 20 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_driver.c 
b/drivers/media/usb/uvc/uvc_driver.c
index 28b91b7d7..17689a242 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2734,6 +2734,15 @@ static const struct usb_device_id uvc_ids[] = {
  .bInterfaceSubClass   = 1,
  .bInterfaceProtocol   = 0,
  .driver_info  = UVC_QUIRK_FORCE_Y8 },
+   /* Dino-Lite Premier AM4111T */
+   { .match_flags  = USB_DEVICE_ID_MATCH_DEVICE
+   | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0xa168,
+ .idProduct= 0x0870,
+ .bInterfaceClass  = USB_CLASS_VIDEO,
+ .bInterfaceSubClass   = 1,
+ .bInterfaceProtocol   = 0,
+ .driver_info  = UVC_QUIRK_LIGHT_CTRL_LEN },
/* Generic USB Video Class */
{ USB_INTERFACE_INFO(USB_CLASS_VIDEO, 1, UVC_PC_PROTOCOL_UNDEFINED) },
{ USB_INTERFACE_INFO(USB_CLASS_VIDEO, 1, UVC_PC_PROTOCOL_15) },
diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index fb86d6af3..702bf03c7 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -83,6 +83,16 @@ int uvc_query_ctrl(struct uvc_device *dev, __u8 query, __u8 
unit,
return -EIO;
}
 
+   /* The Dino-Lite Premier camera lies about a specific query length:
+* control 3 unit 4 (LED light on/off) expects a 3 byte payload but
+* the camera reports only 1 byte when queried for GET_LEN.
+*/
+   if ((dev->quirks & UVC_QUIRK_LIGHT_CTRL_LEN) && query == UVC_GET_LEN
+   && cs == 3 && unit == 4 && size == 2) {
+   put_unaligned_le16(3, data);
+   return 0;
+   }
+
return 0;
 }
 
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 05398784d..bb6a74920 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -186,6 +186,7 @@
 #define UVC_QUIRK_RESTRICT_FRAME_RATE  0x0200
 #define UVC_QUIRK_RESTORE_CTRLS_ON_INIT0x0400
 #define UVC_QUIRK_FORCE_Y8 0x0800
+#define UVC_QUIRK_LIGHT_CTRL_LEN   0x1000
 
 /* Format flags */
 #define UVC_FMT_FLAG_COMPRESSED0x0001
-- 
2.15.1

[PATCH 0/1] Add quirk to support light switch on some cameras

[Alexandre Macabies]

The Dino-Lite cameras are equipped with LED lights that can be switched
on and off by setting a proprietary control. For this control, the
camera reports a length of 1 byte, but actually the value set by the
original Windows driver is 3 byte long. This makes it impossible to
toggle the camera lights from uvcvideo, as the length from GET_LEN is
trusted as being the right one.

This patch makes GET_LEN indicate a length of 3 instead of 1 for this
specific device and control cs/unit.

This patch is a follow-up of a previous patch [1] sent in June, that
went unnoticed but addresses the same issue. It uses a table of local
fixups instead of a module quirk. If you prefer this approach, please
tell me, so I can rework it a bit and submit it in place of this one.

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

Alexandre Macabies (1):
  media: uvcvideo: Add quirk to support light switch on Dino-Lite
cameras

 drivers/media/usb/uvc/uvc_driver.c |  9 +
 drivers/media/usb/uvc/uvc_video.c  | 10 ++
 drivers/media/usb/uvc/uvcvideo.h   |  1 +
 3 files changed, 20 insertions(+)

-- 
2.15.1

[PATCH 2/4] dma-buf: make reservation_object_copy_fences rcu save

[Lyude Paul]

From: Christian König 

Stop requiring that the src reservation object is locked for this operation.

commit 39e16ba16c147e662bf9fbcee9a99d70d420382f upstream

Acked-by: Chunming Zhou 
Signed-off-by: Christian König 
Signed-off-by: Alex Deucher 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1504551766-5093-1-git-send-email-deathsim...@vodafone.de
Signed-off-by: Lyude Paul 
---
 drivers/dma-buf/reservation.c | 56 ---
 1 file changed, 42 insertions(+), 14 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a815455d..b44d9d7db347 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -266,8 +266,7 @@ EXPORT_SYMBOL(reservation_object_add_excl_fence);
 * @dst: the destination reservation object
 * @src: the source reservation object
 *
-* Copy all fences from src to dst. Both src->lock as well as dst-lock must be
-* held.
+* Copy all fences from src to dst. dst-lock must be held.
 */
 int reservation_object_copy_fences(struct reservation_object *dst,
   struct reservation_object *src)
@@ -277,33 +276,62 @@ int reservation_object_copy_fences(struct 
reservation_object *dst,
size_t size;
unsigned i;
 
-   src_list = reservation_object_get_list(src);
+   rcu_read_lock();
+   src_list = rcu_dereference(src->fence);
 
+retry:
if (src_list) {
-   size = offsetof(typeof(*src_list),
-   shared[src_list->shared_count]);
+   unsigned shared_count = src_list->shared_count;
+
+   size = offsetof(typeof(*src_list), shared[shared_count]);
+   rcu_read_unlock();
+
dst_list = kmalloc(size, GFP_KERNEL);
if (!dst_list)
return -ENOMEM;
 
-   dst_list->shared_count = src_list->shared_count;
-   dst_list->shared_max = src_list->shared_count;
-   for (i = 0; i < src_list->shared_count; ++i)
-   dst_list->shared[i] =
-   dma_fence_get(src_list->shared[i]);
+   rcu_read_lock();
+   src_list = rcu_dereference(src->fence);
+   if (!src_list || src_list->shared_count > shared_count) {
+   kfree(dst_list);
+   goto retry;
+   }
+
+   dst_list->shared_count = 0;
+   dst_list->shared_max = shared_count;
+   for (i = 0; i < src_list->shared_count; ++i) {
+   struct dma_fence *fence;
+
+   fence = rcu_dereference(src_list->shared[i]);
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+>flags))
+   continue;
+
+   if (!dma_fence_get_rcu(fence)) {
+   kfree(dst_list);
+   src_list = rcu_dereference(src->fence);
+   goto retry;
+   }
+
+   if (dma_fence_is_signaled(fence)) {
+   dma_fence_put(fence);
+   continue;
+   }
+
+   dst_list->shared[dst_list->shared_count++] = fence;
+   }
} else {
dst_list = NULL;
}
 
+   new = dma_fence_get_rcu_safe(>fence_excl);
+   rcu_read_unlock();
+
kfree(dst->staged);
dst->staged = NULL;
 
src_list = reservation_object_get_list(dst);
-
old = reservation_object_get_excl(dst);
-   new = reservation_object_get_excl(src);
-
-   dma_fence_get(new);
 
preempt_disable();
write_seqcount_begin(>seq);
-- 
2.14.3

[PATCH 0/4] Backported amdgpu ttm deadlock fixes for 4.14

[Lyude Paul]

I haven't gone to see where it started, but as of late a good number of
pretty nasty deadlock issues have appeared with the kernel. Easy
reproduction recipe on a laptop with i915/amdgpu prime with lockdep enabled:

DRI_PRIME=1 glxinfo

Additionally, some more race conditions exist that I've managed to
trigger with piglit and lockdep enabled after applying these patches:

=
WARNING: suspicious RCU usage
4.14.3Lyude-Test+ #2 Not tainted
-
./include/linux/reservation.h:216 suspicious rcu_dereference_protected() 
usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
1 lock held by ext_image_dma_b/27451:
 #0:  (reservation_ww_class_mutex){+.+.}, at: [] 
ttm_bo_unref+0x9f/0x3c0 [ttm]

stack backtrace:
CPU: 0 PID: 27451 Comm: ext_image_dma_b Not tainted 4.14.3Lyude-Test+ #2
Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.02 06/09/2017
Call Trace:
 dump_stack+0x8e/0xce
 lockdep_rcu_suspicious+0xc5/0x100
 reservation_object_copy_fences+0x292/0x2b0
 ? ttm_bo_unref+0x9f/0x3c0 [ttm]
 ttm_bo_unref+0xbd/0x3c0 [ttm]
 amdgpu_bo_unref+0x2a/0x50 [amdgpu]
 amdgpu_gem_object_free+0x4b/0x50 [amdgpu]
 drm_gem_object_free+0x1f/0x40 [drm]
 drm_gem_object_put_unlocked+0x40/0xb0 [drm]
 drm_gem_object_handle_put_unlocked+0x6c/0xb0 [drm]
 drm_gem_object_release_handle+0x51/0x90 [drm]
 drm_gem_handle_delete+0x5e/0x90 [drm]
 ? drm_gem_handle_create+0x40/0x40 [drm]
 drm_gem_close_ioctl+0x20/0x30 [drm]
 drm_ioctl_kernel+0x5d/0xb0 [drm]
 drm_ioctl+0x2f7/0x3b0 [drm]
 ? drm_gem_handle_create+0x40/0x40 [drm]
 ? trace_hardirqs_on_caller+0xf4/0x190
 ? trace_hardirqs_on+0xd/0x10
 amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
 do_vfs_ioctl+0x93/0x670
 ? __fget+0x108/0x1f0
 SyS_ioctl+0x79/0x90
 entry_SYSCALL_64_fastpath+0x23/0xc2

I've also added the relevant fixes for the issue mentioned above.

Christian König (3):
  drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more
  dma-buf: make reservation_object_copy_fences rcu save
  drm/amdgpu: reserve root PD while releasing it

Michel Dänzer (1):
  drm/ttm: Always and only destroy bo->ttm_resv in ttm_bo_release_list

 drivers/dma-buf/reservation.c  | 56 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 13 ++--
 drivers/gpu/drm/ttm/ttm_bo.c   | 43 +-
 3 files changed, 74 insertions(+), 38 deletions(-)

--
2.14.3

Re: [BUG] ir-ctl: error sending file with multiple scancodes

[Sean Young]

Hi Matthias,

On Thu, Nov 30, 2017 at 04:34:33PM +0100, Matthias Reichl wrote:
> Hi Sean,
> 
> On Wed, Nov 29, 2017 at 08:05:21PM +, Sean Young wrote:
> > On Wed, Nov 29, 2017 at 03:44:00PM +0100, Matthias Reichl wrote:
> > > The goal I'm trying to achieve is to send a repeated signal with ir-ctl
> > > (a user reported his sony receiver needs this to actually power up).
> > 
> > That's interesting.
> 
> I'm not sure how common that is. I've got a Panasonic TV here
> that needs a 0.5-1sec button press to power up from standby,
> but it could well be that this is a rather nieche issue.
> 
> I had a look at what it would take to add proper repeat handling
> to ir-ctl (similar to the --count  option in lirc's irsend)
> but that looks like a larger endeavour: implement automatic
> variable length gaps to get fixed repeat times, handle toggle
> bits in some protocols, send special repeat codes eg in NEC etc.

Yes, I've thought about that too. I'm not sure what the user inferface
should look like (and how useful it is).

> As I'm not sure if all of this is even needed I think it's best
> to leave it for maybe some time later. For now the current
> functionality in ir-ctl looks sufficient.

If you have any suggestions. :-)

> > > Using the -S option multiple times comes rather close, but the 125ms
> > > delay between signals is a bit long for the sony protocol - would be
> > > nice if that would be adjustable :)
> > 
> > Yes, that would be a useful feature.
> > 
> > I've got some patches for this, I'll send them as a reply to this. Please
> > let me know what you think.
> 
> [PATCH 1/2] ir-ctl: fix multiple scancodes in one file 
> 01-multiple-scancodes.patch
> [PATCH 2/2] ir-ctl: specify the gap between scancodes or files
> 
> Tested-by: Matthias Reichl 
> 
> Thanks, the patches look and tested fine!
> 
> I've tested multiple scancodes in a file with and without explicit
> space in between and the gap option with multiple -S scancodes on
> the command line. I also tested rc5 protocol in addition to sony12.
> 
> So I'd like to say a big thank you for fixing the issue so quickly!

Thanks for making ir-ctl a better tool :)


Sean

[PATCH 1/3] media: atomisp: convert default struct values to use compound-literals with designated initializers.

[Jeremy Sowden]

The CSS API uses a lot of nested anonymous structs defined in object
macros to assign default values to its data-structures.  These have been
changed to use compound-literals and designated initializers to make
them more comprehensible and less fragile.

The compound-literals can also be used in assignment, which means we can
get rid of some temporary variables whose only purpose is to be
initialized by one of these anonymous structs and then serve as the
rvalue in an assignment expression.

Signed-off-by: Jeremy Sowden 
---
 .../hive_isp_css_common/input_formatter_global.h   |  25 ++--
 .../pci/atomisp2/css2400/ia_css_frame_public.h |  46 ---
 .../atomisp/pci/atomisp2/css2400/ia_css_pipe.h | 145 +++--
 .../pci/atomisp2/css2400/ia_css_pipe_public.h  | 136 +--
 .../atomisp/pci/atomisp2/css2400/ia_css_types.h|  78 +--
 .../isp/kernels/s3a/s3a_1.0/ia_css_s3a_types.h | 130 +-
 .../kernels/sdis/common/ia_css_sdis_common_types.h |  85 +---
 .../isp/kernels/sdis/sdis_1.0/ia_css_sdis.host.c   |   3 +-
 .../runtime/binary/interface/ia_css_binary.h   | 140 ++--
 .../atomisp2/css2400/runtime/binary/src/binary.c   |   3 +-
 .../isp_param/interface/ia_css_isp_param_types.h   |  19 ++-
 .../runtime/pipeline/interface/ia_css_pipeline.h   |  30 ++---
 .../css2400/runtime/pipeline/src/pipeline.c|   7 +-
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c|  22 +---
 .../atomisp/pci/atomisp2/css2400/sh_css_legacy.h   |  16 +--
 .../atomisp/pci/atomisp2/css2400/sh_css_metrics.h  |  26 ++--
 16 files changed, 514 insertions(+), 397 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
index 5654d911db65..d5a586b08955 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
@@ -108,19 +108,20 @@ struct input_formatter_cfg_s {
 };
 
 #define DEFAULT_IF_CONFIG \
+(struct input_formatter_cfg_s) \
 { \
-   0,  /* start_line */\
-   0,  /* start_column */\
-   0,  /* left_padding */\
-   0,  /* cropped_height */\
-   0,  /* cropped_width */\
-   0,  /* deinterleaving */\
-   0,  /*.buf_vecs */\
-   0,  /* buf_start_index */\
-   0,  /* buf_increment */\
-   0,  /* buf_eol_offset */\
-   false,  /* is_yuv420_format */\
-   false   /* block_no_reqs */\
+   .start_line = 0, \
+   .start_column   = 0, \
+   .left_padding   = 0, \
+   .cropped_height = 0, \
+   .cropped_width  = 0, \
+   .deinterleaving = 0, \
+   .buf_vecs   = 0, \
+   .buf_start_index= 0, \
+   .buf_increment  = 0, \
+   .buf_eol_offset = 0, \
+   .is_yuv420_format   = false, \
+   .block_no_reqs  = false \
 }
 
 extern const hrt_address HIVE_IF_SRST_ADDRESS[N_INPUT_FORMATTER_ID];
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h
index 92f2389176b2..786585037af9 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h
@@ -121,15 +121,19 @@ struct ia_css_frame_info {
 };
 
 #define IA_CSS_BINARY_DEFAULT_FRAME_INFO \
-{ \
-   {0,  /* width */ \
-0}, /* height */ \
-   0,   /* padded_width */ \
-   IA_CSS_FRAME_FORMAT_NUM, /* format */ \
-   0,   /* raw_bit_depth */ \
-   IA_CSS_BAYER_ORDER_NUM,  /* raw_bayer_order */ \
-   {0,   /*start col */ \
-0},   /*start line */ \
+(struct ia_css_frame_info) { \
+   .res= (struct ia_css_resolution) { \
+   .width = 0, \
+   .height = 0 \
+   }, \
+   .padded_width   = 0, \
+   .format = IA_CSS_FRAME_FORMAT_NUM,  \
+   .raw_bit_depth  = 0, \
+   .raw_bayer_order= IA_CSS_BAYER_ORDER_NUM, \
+   .crop_info  = (struct ia_css_crop_info) { \
+   .start_column   = 0, \
+   .start_line = 0 \
+   }, \
 }
 
 /**
@@ -190,18 +194,18 @@ struct ia_css_frame {
 };
 
 #define DEFAULT_FRAME \
-{ \
-   IA_CSS_BINARY_DEFAULT_FRAME_INFO,   /* 

[PATCH 0/3] Clean up of data-structure initialization in the CSS API

[Jeremy Sowden]

The CSS API uses a lot of nested anonymous structs defined in object
macros to assign default values to its data-structures.  These have been
changed to use compound-literals and designated initializers to make
them more comprehensible and less fragile.

The compound-literals can also be used in assignment, which made it
possible get rid of some temporary variables whose only purpose is to be
initialized by one of these anonymous structs and then serve as the
rvalue in an assignment expression.

The designated initializers also allow the removal of lots of
struct-members initialized to zero values.

I made the changes in three stages: firstly, I converted the default
values to compound-literals and designated initializers and removed the
temporary variables; secondly, I removed the zero-valued struct-members;
finally, I removed some structs which had become empty.

Jeremy Sowden (3):
  media: atomisp: convert default struct values to use compound-literals
with designated initializers.
  media: atomisp: delete zero-valued struct members.
  media: atomisp: delete empty default struct values.

 .../hive_isp_css_common/input_formatter_global.h   |  16 ---
 .../pci/atomisp2/css2400/ia_css_frame_public.h |  29 ++
 .../atomisp/pci/atomisp2/css2400/ia_css_pipe.h | 110 +++--
 .../pci/atomisp2/css2400/ia_css_pipe_public.h  | 108 +++-
 .../atomisp/pci/atomisp2/css2400/ia_css_types.h|  64 +++-
 .../isp/kernels/s3a/s3a_1.0/ia_css_s3a_types.h |  50 +-
 .../kernels/sdis/common/ia_css_sdis_common_types.h |  31 ++
 .../isp/kernels/sdis/sdis_1.0/ia_css_sdis.host.c   |   3 +-
 .../runtime/binary/interface/ia_css_binary.h   |  88 ++---
 .../atomisp2/css2400/runtime/binary/src/binary.c   |   3 +-
 .../isp_param/interface/ia_css_isp_param_types.h   |  10 --
 .../runtime/pipeline/interface/ia_css_pipeline.h   |  24 ++---
 .../css2400/runtime/pipeline/src/pipeline.c|   7 +-
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c|  31 ++
 .../atomisp/pci/atomisp2/css2400/sh_css_legacy.h   |  11 ---
 .../atomisp/pci/atomisp2/css2400/sh_css_metrics.h  |  21 
 16 files changed, 114 insertions(+), 492 deletions(-)


base-commit: 37cb8e1f8e10c6e9bd2a1b95cdda0620a21b0551
-- 
2.15.0

[PATCH 3/3] media: atomisp: delete empty default struct values.

[Jeremy Sowden]

Removing zero-valued struct-members left a number of the default
struct-values empty.  These values have now been removed.

Signed-off-by: Jeremy Sowden 
---
 .../atomisp/pci/atomisp2/css2400/ia_css_pipe.h |  1 -
 .../atomisp/pci/atomisp2/css2400/ia_css_types.h|  1 -
 .../isp/kernels/s3a/s3a_1.0/ia_css_s3a_types.h |  3 --
 .../kernels/sdis/common/ia_css_sdis_common_types.h | 34 +-
 .../isp/kernels/sdis/sdis_1.0/ia_css_sdis.host.c   |  2 +-
 .../runtime/binary/interface/ia_css_binary.h   |  6 
 .../isp_param/interface/ia_css_isp_param_types.h   |  9 --
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c|  9 +++---
 .../atomisp/pci/atomisp2/css2400/sh_css_legacy.h   |  2 --
 .../atomisp/pci/atomisp2/css2400/sh_css_metrics.h  |  8 -
 10 files changed, 12 insertions(+), 63 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_pipe.h 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_pipe.h
index a8f89866876d..9c6efaa66c93 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_pipe.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_pipe.h
@@ -164,7 +164,6 @@ struct ia_css_pipe {
 #define IA_CSS_DEFAULT_PIPE \
 (struct ia_css_pipe) { \
.config = DEFAULT_PIPE_CONFIG, \
-   .extra_config   = DEFAULT_PIPE_EXTRA_CONFIG, \
.info   = DEFAULT_PIPE_INFO, \
.mode   = IA_CSS_PIPE_ID_ACC, /* (pipe_id) */ \
.pipeline   = DEFAULT_PIPELINE, \
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_types.h 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_types.h
index 0ae60a3d0643..e49fe5bc98b8 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_types.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_types.h
@@ -407,7 +407,6 @@ struct ia_css_grid_info {
 /** defaults for ia_css_grid_info structs */
 #define DEFAULT_GRID_INFO \
 (struct ia_css_grid_info) { \
-   .s3a_grid   = DEFAULT_3A_GRID_INFO, \
.dvs_grid   = DEFAULT_DVS_GRID_INFO, \
.vamem_type = IA_CSS_VAMEM_TYPE_1 \
 }
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/s3a/s3a_1.0/ia_css_s3a_types.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/s3a/s3a_1.0/ia_css_s3a_types.h
index 1309b06747d0..4297c3addcb2 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/s3a/s3a_1.0/ia_css_s3a_types.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/s3a/s3a_1.0/ia_css_s3a_types.h
@@ -98,9 +98,6 @@ struct ia_css_3a_grid_info {
 };
 
 
-#define DEFAULT_3A_GRID_INFO (struct ia_css_3a_grid_info) { }
-
-
 /* This struct should be split into 3, for AE, AWB and AF.
  * However, that will require driver/ 3A lib modifications.
  */
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/common/ia_css_sdis_common_types.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/common/ia_css_sdis_common_types.h
index a969384430aa..4cfd31bd3e5f 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/common/ia_css_sdis_common_types.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/sdis/common/ia_css_sdis_common_types.h
@@ -41,8 +41,6 @@ struct ia_css_sdis_info {
uint32_t deci_factor_log2;
 };
 
-#define IA_CSS_DEFAULT_SDIS_INFO (struct ia_css_sdis_info) { }
-
 /** DVS statistics grid
  *
  *  ISP block: SDVS1 (DIS/DVS Support for DIS/DVS ver.1 (2-axes))
@@ -197,33 +195,15 @@ struct ia_css_dvs_stat_grid_info {
 
 /** DVS statistics generated by accelerator default grid info
  */
-#define DEFAULT_DVS_STAT_PUBLIC_DVS_GLOBAL_CFG \
-(struct dvs_stat_public_dvs_global_cfg) { }
-
-#define DEFAULT_DVS_STAT_PUBLIC_DVS_GRD_CFG \
-(struct dvs_stat_public_dvs_grd_cfg) { }
-
-#define DEFAULT_DVS_STAT_PUBLIC_DVS_LEVEL_FE_ROI_CFG(X_START) \
-   (struct dvs_stat_public_dvs_level_fe_roi_cfg) { .x_start = X_START, }
-
-#define DEFAULT_DVS_STAT_GRID_INFO \
-(struct ia_css_dvs_stat_grid_info) { \
-   .dvs_gbl_cfg = DEFAULT_DVS_STAT_PUBLIC_DVS_GLOBAL_CFG, \
-   .grd_cfg = { \
-   DEFAULT_DVS_STAT_PUBLIC_DVS_GRD_CFG, \
-   DEFAULT_DVS_STAT_PUBLIC_DVS_GRD_CFG, \
-   DEFAULT_DVS_STAT_PUBLIC_DVS_GRD_CFG \
-   }, \
-   .fe_roi_cfg = { \
-   DEFAULT_DVS_STAT_PUBLIC_DVS_LEVEL_FE_ROI_CFG(0), \
-   DEFAULT_DVS_STAT_PUBLIC_DVS_LEVEL_FE_ROI_CFG(4), \
-   DEFAULT_DVS_STAT_PUBLIC_DVS_LEVEL_FE_ROI_CFG(0), \
-   } \
-}
-
 #define DEFAULT_DVS_GRID_INFO \
 (union ia_css_dvs_grid_u) { \
-   .dvs_stat_grid_info = DEFAULT_DVS_STAT_GRID_INFO, \
+   .dvs_stat_grid_info = (struct ia_css_dvs_stat_grid_info) { \
+   .fe_roi_cfg = { \
+   [1] = (struct dvs_stat_public_dvs_level_fe_roi_cfg) 

[PATCH 2/3] media: atomisp: delete zero-valued struct members.

[Jeremy Sowden]

A lot of the members of the default struct values used by the CSS API
were explicitly initialized to zero values.  Designated initializers
have allowed these members to be removed.

Signed-off-by: Jeremy Sowden 
---
 .../hive_isp_css_common/input_formatter_global.h   |  17 
 .../pci/atomisp2/css2400/ia_css_frame_public.h |  17 
 .../atomisp/pci/atomisp2/css2400/ia_css_pipe.h |  42 +---
 .../pci/atomisp2/css2400/ia_css_pipe_public.h  |  82 ---
 .../atomisp/pci/atomisp2/css2400/ia_css_types.h|  47 +
 .../isp/kernels/s3a/s3a_1.0/ia_css_s3a_types.h | 113 +
 .../kernels/sdis/common/ia_css_sdis_common_types.h |  48 +
 .../runtime/binary/interface/ia_css_binary.h   |  90 ++--
 .../isp_param/interface/ia_css_isp_param_types.h   |  18 +---
 .../runtime/pipeline/interface/ia_css_pipeline.h   |   6 --
 .../atomisp/pci/atomisp2/css2400/sh_css_legacy.h   |  11 +-
 .../atomisp/pci/atomisp2/css2400/sh_css_metrics.h  |  11 +-
 12 files changed, 29 insertions(+), 473 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
index d5a586b08955..7558f4964313 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
@@ -107,23 +107,6 @@ struct input_formatter_cfg_s {
uint32_tblock_no_reqs;
 };
 
-#define DEFAULT_IF_CONFIG \
-(struct input_formatter_cfg_s) \
-{ \
-   .start_line = 0, \
-   .start_column   = 0, \
-   .left_padding   = 0, \
-   .cropped_height = 0, \
-   .cropped_width  = 0, \
-   .deinterleaving = 0, \
-   .buf_vecs   = 0, \
-   .buf_start_index= 0, \
-   .buf_increment  = 0, \
-   .buf_eol_offset = 0, \
-   .is_yuv420_format   = false, \
-   .block_no_reqs  = false \
-}
-
 extern const hrt_address HIVE_IF_SRST_ADDRESS[N_INPUT_FORMATTER_ID];
 extern const hrt_data HIVE_IF_SRST_MASK[N_INPUT_FORMATTER_ID];
 extern const uint8_t HIVE_IF_SWITCH_CODE[N_INPUT_FORMATTER_ID];
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h
index 786585037af9..b0872f93b3fa 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h
@@ -122,18 +122,8 @@ struct ia_css_frame_info {
 
 #define IA_CSS_BINARY_DEFAULT_FRAME_INFO \
 (struct ia_css_frame_info) { \
-   .res= (struct ia_css_resolution) { \
-   .width = 0, \
-   .height = 0 \
-   }, \
-   .padded_width   = 0, \
.format = IA_CSS_FRAME_FORMAT_NUM,  \
-   .raw_bit_depth  = 0, \
.raw_bayer_order= IA_CSS_BAYER_ORDER_NUM, \
-   .crop_info  = (struct ia_css_crop_info) { \
-   .start_column   = 0, \
-   .start_line = 0 \
-   }, \
 }
 
 /**
@@ -196,16 +186,9 @@ struct ia_css_frame {
 #define DEFAULT_FRAME \
 (struct ia_css_frame) { \
.info   = IA_CSS_BINARY_DEFAULT_FRAME_INFO, \
-   .data   = 0, \
-   .data_bytes = 0, \
.dynamic_queue_id   = SH_CSS_INVALID_QUEUE_ID, \
.buf_type   = IA_CSS_BUFFER_TYPE_INVALID, \
.flash_state= IA_CSS_FRAME_FLASH_STATE_NONE, \
-   .exp_id = 0, \
-   .isp_config_id  = 0, \
-   .valid  = false, \
-   .contiguous = false, \
-   .planes = { 0 } \
 }
 
 /** @brief Fill a frame with zeros
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_pipe.h 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_pipe.h
index 5d307679768e..a8f89866876d 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_pipe.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_pipe.h
@@ -44,11 +44,6 @@ struct ia_css_preview_settings {
.copy_binary= IA_CSS_BINARY_DEFAULT_SETTINGS, \
.preview_binary = IA_CSS_BINARY_DEFAULT_SETTINGS, \
.vf_pp_binary   = IA_CSS_BINARY_DEFAULT_SETTINGS, \
-   .delay_frames   = { NULL }, \
-   .tnr_frames = { NULL }, \
-   .copy_pipe  = NULL, \
-   .capture_pipe   = NULL, \
-   .acc_pipe   = NULL, \
 }
 
 struct ia_css_capture_settings {
@@ -73,17 

Re: DVB-S2 and S2X API extensions

[Αθανάσιος Οικονόμου]

2017-11-30 20:26 GMT+02:00 Mauro Carvalho Chehab :
> Em Mon, 20 Nov 2017 02:05:35 +0100
> Ralph Metzler  escreveu:
>
>> Hi,
>
> (C/C Athanasios, as he also rised concerns about S2X).
>>
>> Mauro Carvalho Chehab writes:
>>  > Em Thu, 9 Nov 2017 16:28:18 +0100
>>  > Ralph Metzler  escreveu:
>>  >
>>  > > Hi,
>>  > >
>>  > > I have a few RFCs regarding new needed enums and
>>  > > properties for DVB-S2 and DVB-S2X:
>>  > >
>>  > > - DVB-S2/X physical layer scrambling
>>  > >
>>  > > I currently use the inofficial DTV_PLS for setting the scrambling
>>  > > sequence index (cf. ETSI EN 300 468 table 41) of
>>  > > the physical layer scrambling in DVB-S2 and DVB-S2X.
>>  > > Some drivers already misuse bits 8-27 of the DTV_STREAM_ID
>>  > > for setting this. They also differentiate between gold, root
>>  > > and combo codes.
>>  > > The gold code is the actual scrambling sequence index.
>>  > > The root code is just an intermediate calculation
>>  > > accepted by some chips, but derived from the gold code.
>>  > > It can be easily mapped one-to-one to the gold code.
>>  > > (see https://github.com/DigitalDevices/dddvb/blob/master/apps/pls.c,
>>  > > A more optimized version of this could be added to dvb-math.c)
>>  > > The combo code does not really exist but is a by-product
>>  > > of the buggy usage of a gold to root code conversion in ST chips.
>>  > >
>>  > > So, I would propose to officially introduce a property
>>  > > for the scrambling sequence index (=gold code).
>>  > > Should it be called DTV_PLS (which I already used in the dddvb package)
>>  > > or rather DTV_SSI?
>>  > > I realized PLS can be confused with physical layer signalling which
>>  > > uses the acronym PLS in the DVB-S2 specs.
>>  >
>>  > Yes, it makes sense to have a DTV property for the PLS gold code.
>>  >
>>  > I would prefer to use a clearer name, like DTV_PLS_GOLD_CODE,
>>  > to make easier to identify what it means.
>>  >
>>  > At documentation, we should point to EN 302 307 section 5.5.4 and
>>  > to EN 300 468 table 41, with a good enough description to make
>>  > clear that it is the gold code, and not the root code (or
>>  > a chipset-specific "combo" code).
>>
>> If we use a long descriptive name, DTV_SCRAMBLING_SEQUENCE_INDEX might
>> be better because it is the actual name used for it in the documentation
>> and SI fields.
>
> I'm OK with that.
>
>> And, to make it absolutely clear, the combo code is not just a
>> chipset-specific code, it is utter BS!
>> Here is why (sorry for the lengthy explanation):
>>
>> The STV090X/0910 chips have 3 8-bit registers for setting the
>> root code called PLROOT0, PLROOT1 and PLROOT2.
>> The code has 18 bits. So PLROOT0, PLROOT1 and the lower 2 bits
>> (bits 0 and 1) of PLROOT2 are the root code.
>> Bits 2 and 3 of PLROOT2 determine a mode with the following
>> 3 possible values:
>> 0 = the 18 bits are the root code
>> 1 = the 18 bits are the gold code
>> 2 = if you write the gold code to the 18 bits, they will
>> be converted to the root code and you can then
>> read them back, mode will be changed to 0 after
>> conversion
>>
>> This mode 2 is what somebody called "combo code".
>> But why is it seen as a different code? It should
>> behave just identical to writing a gold code!
>> Because some Linux drivers, probably also some
>> Windows drivers, first write PLROOT2, then PLROOT1 and
>> PLROOT0, also in the case of mode 2.
>> Writing the 2 in the mode bits actually triggers the
>> gold->root conversion and this conversion takes some time!
>>
>> So, the conversion is triggered by the write to PLROOT2
>> even though PLROOT1 and PLROOT0 have not yet been written.
>> Depending on many factors like I2C write speed, the
>> computer speed, other tasks running, etc. and especially also
>> the previous values of PLROOT1 and PLROOT2, you will get
>> varying results after the conversion.
>> The length of the conversion also depends on the size of
>> the gold code.
>> For small gold codes the conversion is so fast that
>> it is finished before PLROOT1 and PLROOT2 are written.
>> The lower 16 bits of the conversion results will actually be overwritten
>> again! For larger gold codes only the lower 8 bits, etc.
>>
>> Think about all the race conditions and wrong initial values in this
>> process and everybody please forget about "combo code"!
>
> Yeah, it sounds messy ;-)
>
>>  > > DVB-S2X also defines 7 preferred scrambling code sequences
>>  > > (EN 302 307-2 5.5.4) which should be checked during tuning.
>>  > > If the demod does not do this, should the DVB kernel layer or
>>  > > application do this?
>>  >
>>  > IMHO, it should be up to the kernel to check if the received
>>  > gold code is one of those 7 codes from EM 302 307 part 2 spec,
>>  > if the delivery system is DVB_S2X (btw, we likely need to add it
>>  > to the list of delivery systems). Not sure what would be the
>>  > best way to implement it. Perhaps via 

Re: [PATCH 4/7] media: davinci: fix kernel-doc warnings

[Lad, Prabhakar]

HI Mauro,

Thanks for the patch.

On Wed, Nov 29, 2017 at 12:08 PM, Mauro Carvalho Chehab
 wrote:
> There are several of kernel-doc warnings:
>
> drivers/media/platform/davinci/vpif_display.c:114: warning: No 
> description found for parameter 'sizes'
> drivers/media/platform/davinci/vpif_display.c:165: warning: No 
> description found for parameter 'vq'
> drivers/media/platform/davinci/vpif_display.c:165: warning: Excess 
> function parameter 'vb' description in 'vpif_start_streaming'
> drivers/media/platform/davinci/vpif_display.c:780: warning: No 
> description found for parameter 'vpif_cfg'
> drivers/media/platform/davinci/vpif_display.c:780: warning: No 
> description found for parameter 'chan_cfg'
> drivers/media/platform/davinci/vpif_display.c:780: warning: No 
> description found for parameter 'index'
> drivers/media/platform/davinci/vpif_display.c:813: warning: No 
> description found for parameter 'vpif_cfg'
> drivers/media/platform/davinci/vpif_display.c:813: warning: No 
> description found for parameter 'ch'
> drivers/media/platform/davinci/vpif_display.c:813: warning: No 
> description found for parameter 'index'
> drivers/media/platform/davinci/vpif_capture.c:121: warning: No 
> description found for parameter 'sizes'
> drivers/media/platform/davinci/vpif_capture.c:174: warning: No 
> description found for parameter 'vq'
> drivers/media/platform/davinci/vpif_capture.c:174: warning: Excess 
> function parameter 'vb' description in 'vpif_start_streaming'
> drivers/media/platform/davinci/vpif_capture.c:636: warning: No 
> description found for parameter 'iface'
> drivers/media/platform/davinci/vpif_capture.c:647: warning: No 
> description found for parameter 'ch'
> drivers/media/platform/davinci/vpif_capture.c:647: warning: No 
> description found for parameter 'muxmode'
> drivers/media/platform/davinci/vpif_capture.c:676: warning: No 
> description found for parameter 'vpif_cfg'
> drivers/media/platform/davinci/vpif_capture.c:676: warning: No 
> description found for parameter 'chan_cfg'
> drivers/media/platform/davinci/vpif_capture.c:676: warning: No 
> description found for parameter 'input_index'
> drivers/media/platform/davinci/vpif_capture.c:712: warning: No 
> description found for parameter 'vpif_cfg'
> drivers/media/platform/davinci/vpif_capture.c:712: warning: No 
> description found for parameter 'ch'
> drivers/media/platform/davinci/vpif_capture.c:712: warning: No 
> description found for parameter 'index'
> drivers/media/platform/davinci/vpif_capture.c:798: warning: No 
> description found for parameter 'std'
> drivers/media/platform/davinci/vpif_capture.c:798: warning: Excess 
> function parameter 'std_id' description in 'vpif_g_std'
> drivers/media/platform/davinci/vpif_capture.c:940: warning: No 
> description found for parameter 'fmt'
> drivers/media/platform/davinci/vpif_capture.c:940: warning: Excess 
> function parameter 'index' description in 'vpif_enum_fmt_vid_cap'
> drivers/media/platform/davinci/vpif_capture.c:1750: warning: No 
> description found for parameter 'dev'
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/platform/davinci/vpif_capture.c | 27 
> ++-
>  drivers/media/platform/davinci/vpif_display.c | 16 
>  2 files changed, 22 insertions(+), 21 deletions(-)
>

Acked-by: Lad, Prabhakar 

Regards,
--Prabhakar Lad

Re: [PATCH 06/12] media: vpif: don't generate a kernel-doc warning on a constant

[Lad, Prabhakar]

On Wed, Nov 29, 2017 at 10:46 AM, Mauro Carvalho Chehab
 wrote:
> Constants documentation is not supported by kernel-doc markups.
> So, change the comment label to avoid this warning:
> drivers/media/platform/davinci/vpif.c:54: warning: cannot understand 
> function prototype: 'const struct vpif_channel_config_params vpif_ch_params[] 
> = '
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/platform/davinci/vpif.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

Acked-by: Lad, Prabhakar 

Regards,
--Prabhakar Lad

Unknown symbol errors with latest RH7 kernel using meda_build

[Werner, Zachary]

I'm new to mailing lists, so I'm sorry if this message is poorly formatted.

I have been compiling v4l on RH7 using very minor changes (made it
into an rpm, have to remove 'v3.16_wait_on_bit.patch' from the
backports) for a while now. I had been using an older set of firmware
and git hash from the media_build repo for several kernels, but the
latest kernel release had an issue loading the modules. I've tried
some of the latest kernel releases, 3.10.0-693.el7.x86_64 and
3.10.0-693.5.2.el7.x86_64. They build with a few compiler warnings,
but still build successfully. After installing the new kernel, updated
rpm, and rebooting, I get the following in dmesg:

videobuf2_v4l2: Unknown symbol vb2_buffer_in_use (err 0)
videobuf2_v4l2: Unknown symbol vb2_core_queue_init (err 0)
videobuf2_v4l2: Unknown symbol vb2_verify_memory_type (err 0)
videobuf2_v4l2: Unknown symbol vb2_core_reqbufs (err 0)
videobuf2_v4l2: Unknown symbol vb2_core_expbuf (err 0)
videobuf2_v4l2: Unknown symbol vb2_core_create_bufs (err 0)
videobuf2_v4l2: disagrees about version of symbol vb2_write
videobuf2_v4l2: Unknown symbol vb2_write (err -22)
videobuf2_v4l2: Unknown symbol vb2_core_queue_release (err 0)
videobuf2_v4l2: Unknown symbol vb2_core_prepare_buf (err 0)
videobuf2_v4l2: disagrees about version of symbol vb2_read
videobuf2_v4l2: Unknown symbol vb2_read (err -22)
videobuf2_v4l2: Unknown symbol vb2_core_poll (err 0)
videobuf2_v4l2: Unknown symbol vb2_core_streamon (err 0)
videobuf2_v4l2: Unknown symbol vb2_core_querybuf (err 0)
videobuf2_v4l2: Unknown symbol vb2_core_qbuf (err 0)
videobuf2_v4l2: disagrees about version of symbol vb2_mmap
videobuf2_v4l2: Unknown symbol vb2_mmap (err -22)
videobuf2_v4l2: Unknown symbol vb2_core_dqbuf (err 0)
videobuf2_v4l2: Unknown symbol vb2_core_streamoff (err 0)

Since the videobuf2-core module loaded, I'm not sure why the symbols
are missing. If I compile and install using the latest git versions
using the rpm and locally on the box (using './build' and 'make
install'), I get the same results. I've tried looking into issues with
the symbols not being exported, but the code seems to have them there,
and considering this used to work, I'm a at a loss.

Some of the warnings on build include various files that report:

WARNING: /root/rpmbuild/BUILD/v4l/media_build/v4l/dvb-core.o
(.discard.unreachable): unexpected non-allocatable section.
Did you forget to use "ax"/"aw" in a .S file?
Note that for example  contains
section definitions for use in .S files.

After which this block comes up:

WARNING: "frame_vector_to_pages"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-vmalloc.ko]
undefined!
WARNING: "frame_vector_to_pfns"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-vmalloc.ko]
undefined!
WARNING: "dma_buf_export_named"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-vmalloc.ko]
undefined!
WARNING: "frame_vector_create"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-memops.ko]
undefined!
WARNING: "frame_vector_destroy"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-memops.ko]
undefined!
WARNING: "get_vaddr_frames"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-memops.ko]
undefined!
WARNING: "put_vaddr_frames"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-memops.ko]
undefined!
WARNING: "frame_vector_to_pages"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-dma-sg.ko]
undefined!
WARNING: "dma_buf_export_named"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-dma-sg.ko]
undefined!
WARNING: "frame_vector_to_pages"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-dma-contig.ko]
undefined!
WARNING: "frame_vector_to_pfns"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-dma-contig.ko]
undefined!
WARNING: "dma_buf_export_named"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-dma-contig.ko]
undefined!
WARNING: "v4l_vb2q_enable_media_source"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/videobuf2-core.ko]
undefined!
WARNING: "v4l2_mc_create_media_graph"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/saa7134.ko] undefined!
WARNING: "syscon_regmap_lookup_by_phandle"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/ir-hix5hd2.ko] undefined!
WARNING: "v4l2_mc_create_media_graph"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/em28xx-v4l.ko] undefined!
WARNING: "__v4l2_ctrl_s_ctrl"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/cx8800.ko] undefined!
WARNING: "__v4l2_ctrl_s_ctrl"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/cx88-alsa.ko] undefined!
WARNING: "__v4l2_ctrl_s_ctrl"
[/root/rpmbuild/BUILD/v4l/media_build/v4l/cx23885.ko] undefined!

I don't recall these errors in earlier builds, and I'm not sure if
they are perhaps related to the issues I'm getting on module load.

Any help is appreciated.

Zach

Re: [PATCH 07/22] media: s5k6aa: describe some function parameters

[Nicholas Mc Guire]

On Wed, Nov 29, 2017 at 02:08:25PM -0500, Mauro Carvalho Chehab wrote:
> as warned:
>   drivers/media/i2c/s5k6aa.c:429: warning: No description found for parameter 
> 's5k6aa'
>   drivers/media/i2c/s5k6aa.c:679: warning: No description found for parameter 
> 's5k6aa'
>   drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 
> 's5k6aa'
>   drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 
> 'preset'
>   drivers/media/i2c/s5k6aa.c:787: warning: No description found for parameter 
> 'sd'
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/i2c/s5k6aa.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/media/i2c/s5k6aa.c b/drivers/media/i2c/s5k6aa.c
> index 9fd254a8e20d..13c10b5e2b45 100644
> --- a/drivers/media/i2c/s5k6aa.c
> +++ b/drivers/media/i2c/s5k6aa.c
> @@ -421,6 +421,7 @@ static int s5k6aa_set_ahb_address(struct i2c_client 
> *client)
>  
>  /**
>   * s5k6aa_configure_pixel_clock - apply ISP main clock/PLL configuration
> + * @s5k6aa: pointer to  s5k6aa describing the device
>   *
>   * Configure the internal ISP PLL for the required output frequency.
>   * Locking: called with s5k6aa.lock mutex held.
> @@ -669,6 +670,7 @@ static int s5k6aa_set_input_params(struct s5k6aa *s5k6aa)
>  
>  /**
>   * s5k6aa_configure_video_bus - configure the video output interface
> + * @s5k6aa: pointer to  s5k6aa describing the device
>   * @bus_type: video bus type: parallel or MIPI-CSI
>   * @nlanes: number of MIPI lanes to be used (MIPI-CSI only)
>   *
> @@ -724,6 +726,8 @@ static int s5k6aa_new_config_sync(struct i2c_client 
> *client, int timeout,
>  
>  /**
>   * s5k6aa_set_prev_config - write user preview register set
> + * @s5k6aa: pointer to  s5k6aa describing the device
> + * @preset: s5kaa preset to be applied

that looks like a minor typo  s5kaa  should be  s5k6aa  

also it might be more meaningful to describe its content e.g.

   * @preset: s5k6aa preset pixel format and resolution to be applied

>   *
>   * Configure output resolution and color fromat, pixel clock
>   * frequency range, device frame rate type and frame period range.
> @@ -777,6 +781,7 @@ static int s5k6aa_set_prev_config(struct s5k6aa *s5k6aa,
>  
>  /**
>   * s5k6aa_initialize_isp - basic ISP MCU initialization
> + * @sd: pointer to V4L2 sub-device descriptor
>   *
>   * Configure AHB addresses for registers read/write; configure PLLs for
>   * required output pixel clock. The ISP power supply needs to be already
> -- 
> 2.14.3
>

thx!
hofrat 

Re: [PATCH v2 3/4] media: ov5640: add support of DVP parallel interface

[Fabio Estevam]

Hi Hugues,

On Wed, Nov 29, 2017 at 3:11 PM, Hugues Fruchet  wrote:
> Add support of DVP parallel mode in addition of
> existing MIPI CSI mode. The choice between two modes
> and configuration is made through device tree.

What about explaining how to select between the two modes in
Documentation/devicetree/bindings/media/i2c/ov5640.txt ?

Thanks

Re: [PATCH v2 2/4] media: ov5640: check chip id

[Fabio Estevam]

Hi Hugues,

On Wed, Nov 29, 2017 at 3:11 PM, Hugues Fruchet  wrote:

>  /* read exposure, in number of line periods */
>  static int ov5640_get_exposure(struct ov5640_dev *sensor)
>  {
> @@ -1562,6 +1586,10 @@ static int ov5640_set_power(struct ov5640_dev *sensor, 
> bool on)
> ov5640_reset(sensor);
> ov5640_power(sensor, true);
>
> +   ret = ov5640_check_chip_id(sensor);
> +   if (ret)
> +   goto power_off;

Wouldn't it make more sense to add this check in ov5640_probe()
function instead?

Re: [RFC v5 00/11] V4L2 Explicit Synchronization

[Gustavo Padovan]

Hi Smitha,

2017-11-20 Smitha T Murthy :

> Hi Gustavo,
> 
> I am currently referring to your implementation for explicit
> synchronisation. For the same I needed your testapp, but I am unable
> to download the same at the link provided
> “https://gitlab.collabora.com/padovan/v4l2-fences-test”
> 
> Could you please help me out with the same.

Sorry about that, our gitlab instance creates the repos as internal by
default. I just changed it to Public.

Gustavo

Re: DVB-S2 and S2X API extensions

[Mauro Carvalho Chehab]

Em Mon, 20 Nov 2017 02:05:35 +0100
Ralph Metzler  escreveu:

> Hi,

(C/C Athanasios, as he also rised concerns about S2X).
> 
> Mauro Carvalho Chehab writes:
>  > Em Thu, 9 Nov 2017 16:28:18 +0100
>  > Ralph Metzler  escreveu:
>  >   
>  > > Hi,
>  > > 
>  > > I have a few RFCs regarding new needed enums and
>  > > properties for DVB-S2 and DVB-S2X:
>  > > 
>  > > - DVB-S2/X physical layer scrambling
>  > > 
>  > > I currently use the inofficial DTV_PLS for setting the scrambling
>  > > sequence index (cf. ETSI EN 300 468 table 41) of
>  > > the physical layer scrambling in DVB-S2 and DVB-S2X.
>  > > Some drivers already misuse bits 8-27 of the DTV_STREAM_ID
>  > > for setting this. They also differentiate between gold, root
>  > > and combo codes.
>  > > The gold code is the actual scrambling sequence index.
>  > > The root code is just an intermediate calculation
>  > > accepted by some chips, but derived from the gold code.
>  > > It can be easily mapped one-to-one to the gold code.
>  > > (see https://github.com/DigitalDevices/dddvb/blob/master/apps/pls.c,
>  > > A more optimized version of this could be added to dvb-math.c)
>  > > The combo code does not really exist but is a by-product
>  > > of the buggy usage of a gold to root code conversion in ST chips.
>  > > 
>  > > So, I would propose to officially introduce a property
>  > > for the scrambling sequence index (=gold code).
>  > > Should it be called DTV_PLS (which I already used in the dddvb package)
>  > > or rather DTV_SSI?
>  > > I realized PLS can be confused with physical layer signalling which
>  > > uses the acronym PLS in the DVB-S2 specs.  
>  > 
>  > Yes, it makes sense to have a DTV property for the PLS gold code.
>  > 
>  > I would prefer to use a clearer name, like DTV_PLS_GOLD_CODE,
>  > to make easier to identify what it means.
>  > 
>  > At documentation, we should point to EN 302 307 section 5.5.4 and
>  > to EN 300 468 table 41, with a good enough description to make
>  > clear that it is the gold code, and not the root code (or
>  > a chipset-specific "combo" code).  
> 
> If we use a long descriptive name, DTV_SCRAMBLING_SEQUENCE_INDEX might
> be better because it is the actual name used for it in the documentation
> and SI fields.

I'm OK with that.

> And, to make it absolutely clear, the combo code is not just a
> chipset-specific code, it is utter BS!
> Here is why (sorry for the lengthy explanation):
> 
> The STV090X/0910 chips have 3 8-bit registers for setting the
> root code called PLROOT0, PLROOT1 and PLROOT2.
> The code has 18 bits. So PLROOT0, PLROOT1 and the lower 2 bits
> (bits 0 and 1) of PLROOT2 are the root code.
> Bits 2 and 3 of PLROOT2 determine a mode with the following
> 3 possible values:
> 0 = the 18 bits are the root code
> 1 = the 18 bits are the gold code
> 2 = if you write the gold code to the 18 bits, they will
> be converted to the root code and you can then
> read them back, mode will be changed to 0 after
> conversion
> 
> This mode 2 is what somebody called "combo code".
> But why is it seen as a different code? It should
> behave just identical to writing a gold code!
> Because some Linux drivers, probably also some
> Windows drivers, first write PLROOT2, then PLROOT1 and
> PLROOT0, also in the case of mode 2.
> Writing the 2 in the mode bits actually triggers the
> gold->root conversion and this conversion takes some time!
> 
> So, the conversion is triggered by the write to PLROOT2
> even though PLROOT1 and PLROOT0 have not yet been written.
> Depending on many factors like I2C write speed, the
> computer speed, other tasks running, etc. and especially also
> the previous values of PLROOT1 and PLROOT2, you will get
> varying results after the conversion.
> The length of the conversion also depends on the size of
> the gold code.
> For small gold codes the conversion is so fast that
> it is finished before PLROOT1 and PLROOT2 are written.
> The lower 16 bits of the conversion results will actually be overwritten
> again! For larger gold codes only the lower 8 bits, etc.
> 
> Think about all the race conditions and wrong initial values in this
> process and everybody please forget about "combo code"!

Yeah, it sounds messy ;-)

>  > > DVB-S2X also defines 7 preferred scrambling code sequences
>  > > (EN 302 307-2 5.5.4) which should be checked during tuning.
>  > > If the demod does not do this, should the DVB kernel layer or
>  > > application do this?  
>  > 
>  > IMHO, it should be up to the kernel to check if the received
>  > gold code is one of those 7 codes from EM 302 307 part 2 spec,
>  > if the delivery system is DVB_S2X (btw, we likely need to add it
>  > to the list of delivery systems). Not sure what would be the
>  > best way to implement it. Perhaps via some ancillary routine
>  > that the demods would be using.
>  >   
>  > > - slices
>  > > 
>  > > DVB-S2 and DVB-C2, additionally to ISI/PLP, also can have
>  > > slicing. 

Re: DVB-S2X - S2 Extensions Support

[Mauro Carvalho Chehab]

Em Thu, 30 Nov 2017 15:24:47 +0200
Αθανάσιος Οικονόμου  escreveu:

> Hi All,
> 
> I am not aware if there was a discussion regarding S2X before, so I
> would like to hear what are your plans regarding S2X.

Ralph started a discussion about that sometime ago.

> There are already several manufacturers with S2X capable receivers and
> soon more will follow.
> 
> The S2 extensions will bring more code rates and modulations, so I
> guess adding those to fe_code_rate and fe_modulation is mandatory.
> 
> Something like the following with proper documentation of course.
> 
> @@ -313,6 +313,24 @@ enum fe_code_rate {
> FEC_3_5,
> FEC_9_10,
> FEC_2_5,
> +   FEC_13_45,
> +   FEC_9_20,
> +   FEC_11_20,
> +   FEC_23_36,
> +   FEC_25_36,
> +   FEC_13_18,
> +   FEC_26_45,
> +   FEC_28_45,
> +   FEC_7_9,
> +   FEC_77_90,
> +   FEC_32_45,
> +   FEC_11_15,
> +   FEC_1_2_L,
> +   FEC_8_15_L,
> +   FEC_3_5_L,
> +   FEC_2_3_L,
> +   FEC_5_9_L,
> +   FEC_26_45_L
>  };
> 
> @@ -350,6 +368,10 @@ enum fe_modulation {
> APSK_32,
> DQPSK,
> QAM_4_NR,
> +   APSK_8,
> +   APSK_64,
> +   APSK_128,
> +   ASPK_256
>  };

That's the easiest part :-)

> Adding new values, means that we should bump the DVB API as well to
> 5.12 in order usespace applications to be aware of the changes.

Yes.

> That is let's say the easy part, the hard part is how are we going to
> query frontend capabilities?
> 
> Are we going to introduce a new delsys (SYS_DVBS2X)? Or are we going
> to introduce Supports "3nd generation" modulation"
> (FE_CAN_3G_MODULATION) ?
> 
> Or since the new APSK modulations are optional, we need to add
> FE_CAN_APSK_8/64/128/256 to capabilities.
> 

We have only 2 bits (maybe a few more bits, if we reuse some
unused ones). Anyway, that's not enough for FE_CAN_foo flags.
So, we'll need to extend the API somehow. I'm answering the other
thread with some raw ideas for discussion.

> Thanks for your suggestions.
> 
> Best Regards,
> Athanasios
> 
> PS. Here you can read about S2X:
> https://www.dvb.org/standards/dvb-s2x
> http://www.dvb.org/resources/public/standards/a83-2_dvb-s2x_den302307-2.pdf



Thanks,
Mauro

Re: [PATCH v8 28/28] rcar-vin: enable support for r8a77970

[Kieran Bingham]

Hi Niklas,

On 29/11/17 19:43, Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a77970.
> 
> Signed-off-by: Niklas Söderlund 

Not going through the details on this one, as I don't know where to start yet
other than the cursory chip, width, and height all look correct ... but as this
has helped me capture video this evening this patch can at least have:

Tested-by: Kieran Bingham 

> ---
>  .../devicetree/bindings/media/rcar_vin.txt |  1 +
>  drivers/media/platform/rcar-vin/rcar-core.c| 40 
> ++
>  2 files changed, 41 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 314743532bbb4523..6b98f8a3398fa493 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -21,6 +21,7 @@ on Gen3 to a CSI-2 receiver.
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7796" for the R8A7796 device
> +   - "renesas,vin-r8a77970" for the R8A77970 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
>   device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 62eb89b36fbb2ee1..bbdf36b5c3c8178d 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1145,6 +1145,42 @@ static const struct rvin_info rcar_info_r8a7796 = {
>   },
>  };
>  
> +static const struct rvin_info rcar_info_r8a77970 = {
> + .chip = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> +
> + .num_chsels = 5,
> + .chsels = {
> + {
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + }, {
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 1 },
> + { .csi = RVIN_NC, .chan = 0 },
> + }, {
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 2 },
> + { .csi = RVIN_NC, .chan = 0 },
> + }, {
> + { .csi = RVIN_CSI40, .chan = 1 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 3 },
> + { .csi = RVIN_NC, .chan = 0 },
> + },
> + },
> +};
> +
>  static const struct of_device_id rvin_of_id_table[] = {
>   {
>   .compatible = "renesas,vin-r8a7778",
> @@ -1182,6 +1218,10 @@ static const struct of_device_id rvin_of_id_table[] = {
>   .compatible = "renesas,vin-r8a7796",
>   .data = _info_r8a7796,
>   },
> + {
> + .compatible = "renesas,vin-r8a77970",
> + .data = _info_r8a77970,
> + },
>   { },
>  };
>  MODULE_DEVICE_TABLE(of, rvin_of_id_table);
> 

Re: [PATCH v8 03/28] rcar-vin: unregister video device on driver removal

[Kieran Bingham]

Hi Niklas,

Thankyou for the patch.

Only the grammar police here again :)

On 29/11/17 19:43, Niklas Söderlund wrote:
> If the video device was registered by the complete() callback it should
> be unregistered when the driver is removed. Protect from printing a

/printing a/printing an/

> uninitialized video device node name by adding a checking in

/checking/check/

> rvin_v4l2_unregister() by checking that the video device is registered.

/by checking/to identify/

> Signed-off-by: Niklas Söderlund 

Reviewed-by: Kieran Bingham 



> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 2 ++
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index f7a4c21909da6923..6d99542ec74b49a7 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -272,6 +272,8 @@ static int rcar_vin_remove(struct platform_device *pdev)
>  
>   pm_runtime_disable(>dev);
>  
> + rvin_v4l2_unregister(vin);
> +
>   v4l2_async_notifier_unregister(>notifier);
>   v4l2_async_notifier_cleanup(>notifier);
>  
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 178aecc94962abe2..32a658214f48fa49 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -841,6 +841,9 @@ static const struct v4l2_file_operations rvin_fops = {
>  
>  void rvin_v4l2_unregister(struct rvin_dev *vin)
>  {
> + if (!video_is_registered(>vdev))
> + return;
> +
>   v4l2_info(>v4l2_dev, "Removing %s\n",
> video_device_node_name(>vdev));
>  
> 

Re: [PATCH v8 02/28] rcar-vin: rename poorly named initialize and cleanup functions

[Kieran Bingham]

Hi Niklas,

If relevant I believe you could have a Tested-by: tag from me on this series now
that I have capture working on the Eagle-V3M. I'll let you decide on that 
though.

On 29/11/17 19:43, Niklas Söderlund wrote:
> The functions to initialize and cleanup the hardware and video device
> where poorly named from the start. Rename them to better describe there

s/describe there/describe their/

> intended function.
> 
> Signed-off-by: Niklas Söderlund 

Other than the spelling above, the rename looks good to me.

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 10 +-
>  drivers/media/platform/rcar-vin/rcar-dma.c  |  6 +++---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c |  4 ++--
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  8 
>  4 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 108d776f32651b27..f7a4c21909da6923 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -93,7 +93,7 @@ static int rvin_digital_notify_complete(struct 
> v4l2_async_notifier *notifier)
>   return ret;
>   }
>  
> - return rvin_v4l2_probe(vin);
> + return rvin_v4l2_register(vin);
>  }
>  
>  static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
> @@ -103,7 +103,7 @@ static void rvin_digital_notify_unbind(struct 
> v4l2_async_notifier *notifier,
>   struct rvin_dev *vin = notifier_to_vin(notifier);
>  
>   vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
> - rvin_v4l2_remove(vin);
> + rvin_v4l2_unregister(vin);
>   vin->digital->subdev = NULL;
>  }
>  
> @@ -245,7 +245,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
>   if (irq < 0)
>   return irq;
>  
> - ret = rvin_dma_probe(vin, irq);
> + ret = rvin_dma_register(vin, irq);
>   if (ret)
>   return ret;
>  
> @@ -260,7 +260,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
>  
>   return 0;
>  error:
> - rvin_dma_remove(vin);
> + rvin_dma_unregister(vin);
>   v4l2_async_notifier_cleanup(>notifier);
>  
>   return ret;
> @@ -275,7 +275,7 @@ static int rcar_vin_remove(struct platform_device *pdev)
>   v4l2_async_notifier_unregister(>notifier);
>   v4l2_async_notifier_cleanup(>notifier);
>  
> - rvin_dma_remove(vin);
> + rvin_dma_unregister(vin);
>  
>   return 0;
>  }
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 23fdff7a7370842e..d701b52d198243b5 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1153,14 +1153,14 @@ static const struct vb2_ops rvin_qops = {
>   .wait_finish= vb2_ops_wait_finish,
>  };
>  
> -void rvin_dma_remove(struct rvin_dev *vin)
> +void rvin_dma_unregister(struct rvin_dev *vin)
>  {
>   mutex_destroy(>lock);
>  
>   v4l2_device_unregister(>v4l2_dev);
>  }
>  
> -int rvin_dma_probe(struct rvin_dev *vin, int irq)
> +int rvin_dma_register(struct rvin_dev *vin, int irq)
>  {
>   struct vb2_queue *q = >queue;
>   int i, ret;
> @@ -1208,7 +1208,7 @@ int rvin_dma_probe(struct rvin_dev *vin, int irq)
>  
>   return 0;
>  error:
> - rvin_dma_remove(vin);
> + rvin_dma_unregister(vin);
>  
>   return ret;
>  }
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index b479b882da12f62d..178aecc94962abe2 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -839,7 +839,7 @@ static const struct v4l2_file_operations rvin_fops = {
>   .read   = vb2_fop_read,
>  };
>  
> -void rvin_v4l2_remove(struct rvin_dev *vin)
> +void rvin_v4l2_unregister(struct rvin_dev *vin)
>  {
>   v4l2_info(>v4l2_dev, "Removing %s\n",
> video_device_node_name(>vdev));
> @@ -866,7 +866,7 @@ static void rvin_notify(struct v4l2_subdev *sd,
>   }
>  }
>  
> -int rvin_v4l2_probe(struct rvin_dev *vin)
> +int rvin_v4l2_register(struct rvin_dev *vin)
>  {
>   struct video_device *vdev = >vdev;
>   struct v4l2_subdev *sd = vin_to_source(vin);
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index 5382078143fb3869..85cb7ec53d2b08b5 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -153,11 +153,11 @@ struct rvin_dev {
>  #define vin_warn(d, fmt, arg...) dev_warn(d->dev, fmt, ##arg)
>  #define vin_err(d, fmt, arg...)  dev_err(d->dev, fmt, ##arg)
>  
> -int rvin_dma_probe(struct rvin_dev *vin, int irq);
> -void rvin_dma_remove(struct rvin_dev 

[PATCH v2] dvb-frontends: fix i2c access helpers for KASAN

[Arnd Bergmann]

A typical code fragment was copied across many dvb-frontend drivers and
causes large stack frames when built with with CONFIG_KASAN on gcc-5/6/7:

drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

gcc-8 now solves this by consolidating the stack slots for the argument
variables, but on older compilers we can get the same behavior by taking
the pointer of a local variable rather than the inline function argument.

Cc: sta...@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann 
---
v2: add a comment for each instance of the problem, linking
to the gcc bugzilla (I left out the http:// so it would fit
in one line)
---
 drivers/media/dvb-frontends/ascot2e.c | 4 +++-
 drivers/media/dvb-frontends/cxd2841er.c   | 4 +++-
 drivers/media/dvb-frontends/helene.c  | 4 +++-
 drivers/media/dvb-frontends/horus3a.c | 4 +++-
 drivers/media/dvb-frontends/itd1000.c | 5 +++--
 drivers/media/dvb-frontends/mt312.c   | 5 -
 drivers/media/dvb-frontends/stb0899_drv.c | 3 ++-
 drivers/media/dvb-frontends/stb6100.c | 6 --
 drivers/media/dvb-frontends/stv0367.c | 4 +++-
 drivers/media/dvb-frontends/stv090x.c | 4 +++-
 drivers/media/dvb-frontends/stv6110x.c| 4 +++-
 drivers/media/dvb-frontends/zl10039.c | 4 +++-
 12 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/drivers/media/dvb-frontends/ascot2e.c 
b/drivers/media/dvb-frontends/ascot2e.c
index 0ee0df53b91b..79d5d89bc95e 100644
--- a/drivers/media/dvb-frontends/ascot2e.c
+++ b/drivers/media/dvb-frontends/ascot2e.c
@@ -155,7 +155,9 @@ static int ascot2e_write_regs(struct ascot2e_priv *priv,
 
 static int ascot2e_write_reg(struct ascot2e_priv *priv, u8 reg, u8 val)
 {
-   return ascot2e_write_regs(priv, reg, , 1);
+   u8 tmp = val; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
+
+   return ascot2e_write_regs(priv, reg, , 1);
 }
 
 static int ascot2e_read_regs(struct ascot2e_priv *priv,
diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 48ee9bc00c06..ccbd84fd6428 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -257,7 +257,9 @@ static int cxd2841er_write_regs(struct cxd2841er_priv *priv,
 static int cxd2841er_write_reg(struct cxd2841er_priv *priv,
   u8 addr, u8 reg, u8 val)
 {
-   return cxd2841er_write_regs(priv, addr, reg, , 1);
+   u8 tmp = val; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
+
+   return cxd2841er_write_regs(priv, addr, reg, , 1);
 }
 
 static int cxd2841er_read_regs(struct cxd2841er_priv *priv,
diff --git a/drivers/media/dvb-frontends/helene.c 
b/drivers/media/dvb-frontends/helene.c
index 4bf5a551ba40..2ab8d83e5576 100644
--- a/drivers/media/dvb-frontends/helene.c
+++ b/drivers/media/dvb-frontends/helene.c
@@ -331,7 +331,9 @@ static int helene_write_regs(struct helene_priv *priv,
 
 static int helene_write_reg(struct helene_priv *priv, u8 reg, u8 val)
 {
-   return helene_write_regs(priv, reg, , 1);
+   u8 tmp = val; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
+
+   return helene_write_regs(priv, reg, , 1);
 }
 
 static int helene_read_regs(struct helene_priv *priv,
diff --git a/drivers/media/dvb-frontends/horus3a.c 
b/drivers/media/dvb-frontends/horus3a.c
index 68d759c4c52e..5c8b405f2ddc 100644
--- a/drivers/media/dvb-frontends/horus3a.c
+++ b/drivers/media/dvb-frontends/horus3a.c
@@ -89,7 +89,9 @@ static int horus3a_write_regs(struct horus3a_priv *priv,
 
 static int horus3a_write_reg(struct horus3a_priv *priv, u8 reg, u8 val)
 {
-   return horus3a_write_regs(priv, reg, , 1);
+   u8 tmp = val; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
+
+   return horus3a_write_regs(priv, reg, , 1);
 }
 
 static int horus3a_enter_power_save(struct horus3a_priv *priv)
diff --git a/drivers/media/dvb-frontends/itd1000.c 
b/drivers/media/dvb-frontends/itd1000.c
index 5bb1e73a10b4..ce7c443d3eac 100644
--- a/drivers/media/dvb-frontends/itd1000.c
+++ b/drivers/media/dvb-frontends/itd1000.c
@@ -95,8 +95,9 @@ static int itd1000_read_reg(struct itd1000_state *state, u8 
reg)
 
 static inline int itd1000_write_reg(struct itd1000_state *state, u8 r, u8 v)
 {
-   int ret = itd1000_write_regs(state, r, , 1);
-   

Re: [PATCH v8 23/28] rcar-vin: parse Gen3 OF and setup media graph

[Niklas Söderlund]

Hi,

There is one error in this patch. A left over from moving the video 
device registration from probe() to the async callbacks, see bellow. I 
will await further feedback before resending but will include this fix 
in the next version.

On 2017-11-29 20:43:37 +0100, Niklas Söderlund wrote:
> Parse the VIN Gen3 OF graph and register all CSI-2 devices in the VIN
> group common media device. Once all CSI-2 subdevices are added to the
> common media device create links between them.
> 
> The parsing and registering CSI-2 subdevices with the v4l2 async
> framework is a collaborative effort shared between the VIN instances
> which are part of the group. The first rcar-vin instance parses OF and
> finds all other VIN and CSI-2 nodes which are part of the graph. It
> stores a bit mask of all VIN instances found and handles to all CSI-2
> nodes.
> 
> The bit mask is used to figure out when all VIN instances have been
> probed. Once the last VIN instance is probed this is detected and this
> instance registers all CSI-2 subdevices in its private async notifier.
> Once the .complete() callback of this notifier is called it register all
> video devices and creates the media controller links between all
> entities.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 322 
> +++-
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  10 +-
>  2 files changed, 327 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index a6713fd61dd87a88..2081637e493e1941 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -86,6 +86,7 @@ static struct rvin_group *__rvin_group_allocate(struct 
> rvin_dev *vin)
>   return NULL;
>  
>   kref_init(>refcount);
> + group->notifier = NULL;
>   rvin_group_data = group;
>  
>   vin_dbg(vin, "%s: alloc group=%p\n", __func__, group);
> @@ -392,10 +393,281 @@ static int rvin_digital_graph_init(struct rvin_dev 
> *vin)
>   * Group async notifier
>   */
>  
> -static int rvin_group_init(struct rvin_dev *vin)
> +/* group lock should be held when calling this function */
> +static int rvin_group_add_link(struct rvin_dev *vin,
> +struct media_entity *source,
> +unsigned int source_idx,
> +struct media_entity *sink,
> +unsigned int sink_idx,
> +u32 flags)
> +{
> + struct media_pad *source_pad, *sink_pad;
> + int ret = 0;
> +
> + source_pad = >pads[source_idx];
> + sink_pad = >pads[sink_idx];
> +
> + if (!media_entity_find_link(source_pad, sink_pad))
> + ret = media_create_pad_link(source, source_idx,
> + sink, sink_idx, flags);
> +
> + if (ret)
> + vin_err(vin, "Error adding link from %s to %s\n",
> + source->name, sink->name);
> +
> + return ret;
> +}
> +
> +static int rvin_group_update_links(struct rvin_dev *vin)
> +{
> + struct media_entity *source, *sink;
> + struct rvin_dev *master;
> + unsigned int i, n, idx, csi;
> + int ret = 0;
> +
> + mutex_lock(>group->lock);
> +
> + for (n = 0; n < RCAR_VIN_NUM; n++) {
> +
> + /* Check that VIN is part of the group */
> + if (!vin->group->vin[n])
> + continue;
> +
> + /* Check that subgroup master is part of the group */
> + master = vin->group->vin[n < 4 ? 0 : 4];
> + if (!master)
> + continue;
> +
> + for (i = 0; i < vin->info->num_chsels; i++) {
> + csi = vin->info->chsels[n][i].csi;
> +
> + /* If the CSI-2 is out of bounds it's a noop, skip */
> + if (csi >= RVIN_CSI_MAX)
> + continue;
> +
> + /* Check that CSI-2 are part of the group */
> + if (!vin->group->csi[csi].subdev)
> + continue;
> +
> + source = >group->csi[csi].subdev->entity;
> + sink = >group->vin[n]->vdev.entity;
> + idx = vin->info->chsels[n][i].chan + 1;
> +
> + ret = rvin_group_add_link(vin, source, idx, sink, 0,
> +   0);
> + if (ret)
> + goto out;
> + }
> + }
> +out:
> + mutex_unlock(>group->lock);
> +
> + return ret;
> +}
> +
> +static int rvin_group_notify_complete(struct v4l2_async_notifier *notifier)
>  {
> + struct rvin_dev *vin = notifier_to_vin(notifier);
> + unsigned int i;
>   int ret;
>  
> + ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
> + if 

Re: [BUG] ir-ctl: error sending file with multiple scancodes

[Matthias Reichl]

Hi Sean,

On Wed, Nov 29, 2017 at 08:05:21PM +, Sean Young wrote:
> On Wed, Nov 29, 2017 at 03:44:00PM +0100, Matthias Reichl wrote:
> > The goal I'm trying to achieve is to send a repeated signal with ir-ctl
> > (a user reported his sony receiver needs this to actually power up).
> 
> That's interesting.

I'm not sure how common that is. I've got a Panasonic TV here
that needs a 0.5-1sec button press to power up from standby,
but it could well be that this is a rather nieche issue.

I had a look at what it would take to add proper repeat handling
to ir-ctl (similar to the --count  option in lirc's irsend)
but that looks like a larger endeavour: implement automatic
variable length gaps to get fixed repeat times, handle toggle
bits in some protocols, send special repeat codes eg in NEC etc.

As I'm not sure if all of this is even needed I think it's best
to leave it for maybe some time later. For now the current
functionality in ir-ctl looks sufficient.

> > Using the -S option multiple times comes rather close, but the 125ms
> > delay between signals is a bit long for the sony protocol - would be
> > nice if that would be adjustable :)
> 
> Yes, that would be a useful feature.
> 
> I've got some patches for this, I'll send them as a reply to this. Please
> let me know what you think.

[PATCH 1/2] ir-ctl: fix multiple scancodes in one file 
01-multiple-scancodes.patch
[PATCH 2/2] ir-ctl: specify the gap between scancodes or files

Tested-by: Matthias Reichl 

Thanks, the patches look and tested fine!

I've tested multiple scancodes in a file with and without explicit
space in between and the gap option with multiple -S scancodes on
the command line. I also tested rc5 protocol in addition to sony12.

So I'd like to say a big thank you for fixing the issue so quickly!

so long,

Hias

Re: [linux-sunxi] Cedrus driver

[Maxime Ripard]

Hi Thomas,

On Wed, Nov 29, 2017 at 04:36:01PM +0100, Thomas van Kleef wrote:
> > C) I'm not sure what you tried to do with the application of the
> >request API patches (such as e1ca861c168f) but we want to have the
> >whole commits in there, and not a patch adding all of them. This
> >will make the work so much easier to rebase to a later version when
> >some patches wouldn't have been merged and some would have.
> > 
> > D) Rebase :)
>
> Thank you. Giulio asked before if I could add a repo and commit the 
> patches so that is what I did. I will push a different code where the
> full history is present in commits.
> 
> So, I got it setup. As I did test it before on the slightly newer branch,
> I did not verify, again, if the video-decoder worked on this specific 
> state of the linux kernel, 4.14. But it should x:
> If you rather wait for me to tell if it work let me know, but we could do
> a pull request then again anyway.

Yeah, I'd rather wait for at least small test that the general case is
working.

> So here is the new pull-request
> The following changes since commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4:
> 
>   Linux 4.14 (2017-11-12 10:46:13 -0800)
> 
> are available in the git repository at:
> 
>   https://github.com/thomas-vitsch/linux-a20-cedrus.git linux-sunxi-cedrus
> 
> for you to fetch changes up to 26701eca67a07ab002c7fd18038fa299b9589939:
> 
>   Fix the sun5i and sun8i dts files (2017-11-29 15:18:05 +0100)
> 
> 
> Bob Ham (1):
>   sunxi-cedrus: Fix compilation errors from bad types under GCC 6.2
> 
> Florent Revest (8):
>   Both mainline and cedrus had added their own formats with both are 
> added.
>   v4l: Add MPEG2 low-level decoder API control
>   v4l: Add MPEG4 low-level decoder API control
>   media: platform: Add Sunxi Cedrus decoder driver
>   sunxi-cedrus: Add a MPEG 2 codec
>   sunxi-cedrus: Add a MPEG 4 codec
>   sunxi-cedrus: Add device tree binding document
>   ARM: dts: sun5i: Use video-engine node
> 
> Hans Verkuil (15):
>   videodev2.h: add max_reqs to struct v4l2_query_ext_ctrl
>   videodev2.h: add request to v4l2_ext_controls
>   videodev2.h: add request field to v4l2_buffer.
>   vb2: add allow_requests flag
>   v4l2-ctrls: add request support
>   v4l2-ctrls: add function to apply a request.
>   v4l2-ctrls: implement delete request(s)
>   v4l2-ctrls: add VIDIOC_REQUEST_CMD
>   v4l2: add initial V4L2_REQ_CMD_QUEUE support
>   vb2: add helper function to queue request-specific buffer.
>   v4l2-device: keep track of registered video_devices
>   v4l2-device: add v4l2_device_req_queue
>   vivid: add request support for video capture.
>   v4l2-ctrls: add REQ_KEEP flag
>   Documentation: add v4l2-requests.txt
> 
> Icenowy Zheng (2):
>   sunxi-cedrus: add syscon support
>   ARM: dts: sun8i: add video engine support for A33
> 
> Thomas van Kleef (4):
>   Merged requests2 into linux 4.14
>   Fix merge error
>   Remove reject file from merge
>   Fix the sun5i and sun8i dts files

There's still two minor issues with your patches here.

Your SoB should contain your name only, so you should drop the Vitsch
Electronics part. And the patches that are fixing compilation issues
should be squashed in the patches that introduced the breakage in the
first place. So a01b8665802145f1180680b67e5e1d04f2050fe3 should be
merged with 1c735c83c68d54616503481b2796005f02930b85 for example.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 2/2] media: rc-core.rst: add the lirc_dev.h header

[Mauro Carvalho Chehab]

Em Thu, 30 Nov 2017 08:20:56 -0500
Mauro Carvalho Chehab  escreveu:

> There is a kAPI declaration there. Add it to the documentation.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Please ignore this one. Was sent by mistake.

Thanks,
Mauro

Re: [PATCH, RESEND 1/2] dvb-frontends: fix i2c access helpers for KASAN

[Mauro Carvalho Chehab]

Em Thu, 30 Nov 2017 15:06:15 +0100
Arnd Bergmann  escreveu:

> On Thu, Nov 30, 2017 at 1:49 PM, Mauro Carvalho Chehab
>  wrote:
> >> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
> >> Signed-off-by: Arnd Bergmann 
> >> ---
> >> I'm undecided here whether there should be a comment pointing
> >> to PR81715 for each file that the bogus local variable workaround
> >> to prevent it from being cleaned up again. It's probably not
> >> necessary since anything that causes actual problems would also
> >> trigger a build warning.  
> 
> >
> > This kind of sucks, and it is completely unexpected... why val is
> > so special that it would require this kind of hack?  
> 
> It's explained in the gcc bug report: basically gcc always skipped
> one optimization on inline function arguments that it does on
> normal variables. Without KASAN and asan-stack, we didn't
> notice because the impact was fairly small, but I ended up finally
> getting to the bottom of it in September, and it finally got fixed.
> 
> I had an older version of the patch that was much more invasive
> before we understood what exactly is happening, see
> https://lkml.org/lkml/2017/3/2/484

Yeah, I saw the old versions and I'm following this thread.

> > Also, there's always a risk of someone see it and decide to
> > simplify the code, returning it to the previous state.
> >
> > So, if we're willing to do something like that, IMHO, we should have
> > some macro that would document it, and fall back to the direct
> > code if the compiler is not gcc 5, 6 or 7.  
> 
> Older compilers are also affected and will produce better code
> with my change, the difference is just smaller without asan-stack
> (added ion gcc-5) is disabled, since that increases the stack
> space used by each variable to (IIRC) 32 bytes.
> 
> The fixed gcc-8 produces identical code with and without my
> change.
> 
> I don't think that a macro would help here at all, but if you
> prefer, I could add a link to that gcc bug in each function that
> has the problem.

My main concern here is to avoid someone to undo the changes.
Adding a quick note on each of those changes is helpful, in
order to warn people and refrain undoing.

So, adding a quick comment works for me.

Regards,
Mauro

Re: [PATCH, RESEND 1/2] dvb-frontends: fix i2c access helpers for KASAN

[Arnd Bergmann]

On Thu, Nov 30, 2017 at 1:49 PM, Mauro Carvalho Chehab
 wrote:
>> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
>> Signed-off-by: Arnd Bergmann 
>> ---
>> I'm undecided here whether there should be a comment pointing
>> to PR81715 for each file that the bogus local variable workaround
>> to prevent it from being cleaned up again. It's probably not
>> necessary since anything that causes actual problems would also
>> trigger a build warning.

>
> This kind of sucks, and it is completely unexpected... why val is
> so special that it would require this kind of hack?

It's explained in the gcc bug report: basically gcc always skipped
one optimization on inline function arguments that it does on
normal variables. Without KASAN and asan-stack, we didn't
notice because the impact was fairly small, but I ended up finally
getting to the bottom of it in September, and it finally got fixed.

I had an older version of the patch that was much more invasive
before we understood what exactly is happening, see
https://lkml.org/lkml/2017/3/2/484

> Also, there's always a risk of someone see it and decide to
> simplify the code, returning it to the previous state.
>
> So, if we're willing to do something like that, IMHO, we should have
> some macro that would document it, and fall back to the direct
> code if the compiler is not gcc 5, 6 or 7.

Older compilers are also affected and will produce better code
with my change, the difference is just smaller without asan-stack
(added ion gcc-5) is disabled, since that increases the stack
space used by each variable to (IIRC) 32 bytes.

The fixed gcc-8 produces identical code with and without my
change.

I don't think that a macro would help here at all, but if you
prefer, I could add a link to that gcc bug in each function that
has the problem.

 Arnd

[PATCH] kernel-doc: parse DECLARE_KFIFO_PTR()

[Mauro Carvalho Chehab]

On media, we now have an struct declared with:

struct lirc_fh {
struct list_head list;
struct rc_dev *rc;
int carrier_low;
boolsend_timeout_reports;
DECLARE_KFIFO_PTR(rawir, unsigned int);
DECLARE_KFIFO_PTR(scancodes, struct lirc_scancode);
wait_queue_head_t   wait_poll;
u8  send_mode;
u8  rec_mode;
};

Currently, it produces the following error:

./include/media/rc-core.h:96: warning: No description found for 
parameter 'int'
./include/media/rc-core.h:96: warning: No description found for 
parameter 'lirc_scancode'
./include/media/rc-core.h:96: warning: Excess struct member 'rawir' 
description in 'lirc_fh'
./include/media/rc-core.h:96: warning: Excess struct member 'scancodes' 
description in 'lirc_fh'

So, teach kernel-doc how to parse a DECLARE_KFIFO_PTR();

While here, relax at the past DECLARE_foo() macros,
accepting a random number of spaces after comma.

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kernel-doc | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index bd29a92b4b48..5c12208f8c89 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -2208,10 +2208,11 @@ sub dump_struct($$) {
$members =~ s/__aligned\s*\([^;]*\)//gos;
$members =~ s/\s*CRYPTO_MINALIGN_ATTR//gos;
# replace DECLARE_BITMAP
-   $members =~ s/DECLARE_BITMAP\s*\(([^,)]+), ([^,)]+)\)/unsigned long 
$1\[BITS_TO_LONGS($2)\]/gos;
+   $members =~ s/DECLARE_BITMAP\s*\(([^,)]+),\s*([^,)]+)\)/unsigned long 
$1\[BITS_TO_LONGS($2)\]/gos;
# replace DECLARE_HASHTABLE
-   $members =~ s/DECLARE_HASHTABLE\s*\(([^,)]+), ([^,)]+)\)/unsigned long 
$1\[1 << (($2) - 1)\]/gos;
-
+   $members =~ s/DECLARE_HASHTABLE\s*\(([^,)]+),\s*([^,)]+)\)/unsigned 
long $1\[1 << (($2) - 1)\]/gos;
+   # replace DECLARE_KFIFO_PTR(fifo, type)
+   $members =~ s/DECLARE_KFIFO_PTR\s*\(([^,)]+),\s*([^,)]+)\)/$2 \*$1/gos;
create_parameterlist($members, ';', $file);
check_sections($file, $declaration_name, $decl_type, $sectcheck, 
$struct_actual, $nested);
 
-- 
2.14.3

DVB-S2X - S2 Extensions Support

[Αθανάσιος Οικονόμου]

Hi All,

I am not aware if there was a discussion regarding S2X before, so I
would like to hear what are your plans regarding S2X.

There are already several manufacturers with S2X capable receivers and
soon more will follow.

The S2 extensions will bring more code rates and modulations, so I
guess adding those to fe_code_rate and fe_modulation is mandatory.

Something like the following with proper documentation of course.

@@ -313,6 +313,24 @@ enum fe_code_rate {
FEC_3_5,
FEC_9_10,
FEC_2_5,
+   FEC_13_45,
+   FEC_9_20,
+   FEC_11_20,
+   FEC_23_36,
+   FEC_25_36,
+   FEC_13_18,
+   FEC_26_45,
+   FEC_28_45,
+   FEC_7_9,
+   FEC_77_90,
+   FEC_32_45,
+   FEC_11_15,
+   FEC_1_2_L,
+   FEC_8_15_L,
+   FEC_3_5_L,
+   FEC_2_3_L,
+   FEC_5_9_L,
+   FEC_26_45_L
 };

@@ -350,6 +368,10 @@ enum fe_modulation {
APSK_32,
DQPSK,
QAM_4_NR,
+   APSK_8,
+   APSK_64,
+   APSK_128,
+   ASPK_256
 };

Adding new values, means that we should bump the DVB API as well to
5.12 in order usespace applications to be aware of the changes.

That is let's say the easy part, the hard part is how are we going to
query frontend capabilities?

Are we going to introduce a new delsys (SYS_DVBS2X)? Or are we going
to introduce Supports "3nd generation" modulation"
(FE_CAN_3G_MODULATION) ?

Or since the new APSK modulations are optional, we need to add
FE_CAN_APSK_8/64/128/256 to capabilities.

Thanks for your suggestions.

Best Regards,
Athanasios

PS. Here you can read about S2X:
https://www.dvb.org/standards/dvb-s2x
http://www.dvb.org/resources/public/standards/a83-2_dvb-s2x_den302307-2.pdf

[PATCH 1/2] media: RC docs: add enum rc_proto description at the docs

[Mauro Carvalho Chehab]

This is part of the uAPI. Add it to the documentation again,
and fix cross-references.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/rc/lirc-dev-intro.rst | 19 +--
 Documentation/media/uapi/rc/lirc-read.rst  |  2 +-
 Documentation/media/uapi/rc/lirc-write.rst |  4 ++--
 3 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst 
b/Documentation/media/uapi/rc/lirc-dev-intro.rst
index 47c6c218e72a..3a74fec66d69 100644
--- a/Documentation/media/uapi/rc/lirc-dev-intro.rst
+++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst
@@ -46,13 +46,13 @@ on the following table.
 This mode is for both sending and receiving IR.
 
 For transmitting (aka sending), create a ``struct lirc_scancode`` with
-the desired scancode set in the ``scancode`` member, ``rc_proto`` set
-the IR protocol, and all other members set to 0. Write this struct to
+the desired scancode set in the ``scancode`` member, :c:type:`rc_proto`
+set the IR protocol, and all other members set to 0. Write this struct to
 the lirc device.
 
 For receiving, you read ``struct lirc_scancode`` from the lirc device,
 with ``scancode`` set to the received scancode and the IR protocol
-``rc_proto``. If the scancode maps to a valid key code, this is set
+:c:type:`rc_proto`. If the scancode maps to a valid key code, this is set
 in the ``keycode`` field, else it is set to ``KEY_RESERVED``.
 
 The ``flags`` can have ``LIRC_SCANCODE_FLAG_TOGGLE`` set if the toggle
@@ -74,9 +74,6 @@ on the following table.
 The ``timestamp`` field is filled with the time nanoseconds
 (in ``CLOCK_MONOTONIC``) when the scancode was decoded.
 
-An ``enum rc_proto`` in the :ref:`lirc_header` lists all the supported
-IR protocols.
-
 .. _lirc-mode-mode2:
 
 ``LIRC_MODE_MODE2``
@@ -125,3 +122,13 @@ on the following table.
 of entries.
 
 This mode is used only for IR send.
+
+
+**
+Remote Controller protocol
+**
+
+An enum :c:type:`rc_proto` in the :ref:`lirc_header` lists all the
+supported IR protocols:
+
+.. kernel-doc:: include/uapi/linux/lirc.h
diff --git a/Documentation/media/uapi/rc/lirc-read.rst 
b/Documentation/media/uapi/rc/lirc-read.rst
index 51d37ed10194..c024aaffb8ad 100644
--- a/Documentation/media/uapi/rc/lirc-read.rst
+++ b/Documentation/media/uapi/rc/lirc-read.rst
@@ -54,7 +54,7 @@ read from the chardev.
 
 Alternatively, :ref:`LIRC_MODE_SCANCODE ` can be available,
 in this mode scancodes which are either decoded by software decoders, or
-by hardware decoders. The ``rc_proto`` member is set to the
+by hardware decoders. The :c:type:`rc_proto` member is set to the
 protocol used for transmission, and ``scancode`` to the decoded scancode,
 and the ``keycode`` set to the keycode or ``KEY_RESERVED``.
 
diff --git a/Documentation/media/uapi/rc/lirc-write.rst 
b/Documentation/media/uapi/rc/lirc-write.rst
index 3d7541bad8b9..dd3d1fe807a6 100644
--- a/Documentation/media/uapi/rc/lirc-write.rst
+++ b/Documentation/media/uapi/rc/lirc-write.rst
@@ -57,8 +57,8 @@ driver returns ``EINVAL``.
 When in :ref:`LIRC_MODE_SCANCODE ` mode, one
 ``struct lirc_scancode`` must be written to the chardev at a time, else
 ``EINVAL`` is returned. Set the desired scancode in the ``scancode`` member,
-and the protocol in the ``rc_proto`` member. All other members must be set
-to 0, else ``EINVAL`` is returned. If there is no protocol encoder
+and the protocol in the :c:type:`rc_proto`: member. All other members must be
+set to 0, else ``EINVAL`` is returned. If there is no protocol encoder
 for the protocol or the scancode is not valid for the specified protocol,
 ``EINVAL`` is returned. The write function may not wait until the scancode
 is transmitted.
-- 
2.14.3

[PATCH 2/2] media: rc-core.rst: add the lirc_dev.h header

[Mauro Carvalho Chehab]

There is a kAPI declaration there. Add it to the documentation.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/kapi/rc-core.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/media/kapi/rc-core.rst 
b/Documentation/media/kapi/rc-core.rst
index 41c2256dbf6a..dd2482c58cdb 100644
--- a/Documentation/media/kapi/rc-core.rst
+++ b/Documentation/media/kapi/rc-core.rst
@@ -7,3 +7,5 @@ Remote Controller core
 .. kernel-doc:: include/media/rc-core.h
 
 .. kernel-doc:: include/media/rc-map.h
+
+.. kernel-doc:: include/media/lirc_dev.h
-- 
2.14.3

Re: [PATCH v3 26/26] kfifo: DECLARE_KIFO_PTR(fifo, u64) does not work on arm 32 bit

[Stefani Seibold]

On Thu, 2017-11-30 at 10:29 -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 10 Oct 2017 09:59:42 +0200
> Sean Young  escreveu:
> 
> > If you try to store u64 in a kfifo (or a struct with u64 members),
> > then the buf member of __STRUCT_KFIFO_PTR will cause 4 bytes
> > padding due to alignment (note that struct __kfifo is 20 bytes
> > on 32 bit).
> > 
> > That in turn causes the __is_kfifo_ptr() to fail, which is caught
> > by kfifo_alloc(), which now returns EINVAL.
> > 
> > So, ensure that __is_kfifo_ptr() compares to the right structure.
> > 
> > Signed-off-by: Sean Young 
> > Acked-by: Stefani Seibold 
> 
> Hi Stefani/Andrew,
> 
> As this patch is required for the LIRC rework, would be ok if I would
> merge it via the media tree?
> 

It is okay by me. But the question remains why this patch wasn't
already merged?

Andrew: Any objections against this patch?


> > 
> > ---
> >  include/linux/kfifo.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
> > index 41eb6fdf87a8..86b5fb08e96c 100644
> > --- a/include/linux/kfifo.h
> > +++ b/include/linux/kfifo.h
> > @@ -113,7 +113,8 @@ struct kfifo_rec_ptr_2
> > __STRUCT_KFIFO_PTR(unsigned char, 2, void);
> >   * array is a part of the structure and the fifo type where the
> > array is
> >   * outside of the fifo structure.
> >   */
> > -#define__is_kfifo_ptr(fifo)(sizeof(*fifo) ==
> > sizeof(struct __kfifo))
> > +#define__is_kfifo_ptr(fifo) \
> > +   (sizeof(*fifo) == sizeof(STRUCT_KFIFO_PTR(typeof(*(fifo)-
> > >type
> >  
> >  /**
> >   * DECLARE_KFIFO_PTR - macro to declare a fifo pointer object
> 
> 
> 
> Thanks,
> Mauro

Re: [PATCH, RESEND 1/2] dvb-frontends: fix i2c access helpers for KASAN

[Mauro Carvalho Chehab]

Hi Arnd,

Em Thu, 30 Nov 2017 12:08:04 +0100
Arnd Bergmann  escreveu:

> A typical code fragment was copied across many dvb-frontend drivers and
> causes large stack frames when built with with CONFIG_KASAN on gcc-5/6/7:
> 
> drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 
> bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
> drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 
> bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
> drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 
> bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
> drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
> bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
> drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 
> bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
> 
> gcc-8 now solves this by consolidating the stack slots for the argument
> variables, but on older compilers we can get the same behavior by taking
> the pointer of a local variable rather than the inline function argument.
> 
> Cc: sta...@vger.kernel.org
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
> Signed-off-by: Arnd Bergmann 
> ---
> I'm undecided here whether there should be a comment pointing
> to PR81715 for each file that the bogus local variable workaround
> to prevent it from being cleaned up again. It's probably not
> necessary since anything that causes actual problems would also
> trigger a build warning.
> ---
>  drivers/media/dvb-frontends/ascot2e.c | 4 +++-
>  drivers/media/dvb-frontends/cxd2841er.c   | 4 +++-
>  drivers/media/dvb-frontends/helene.c  | 4 +++-
>  drivers/media/dvb-frontends/horus3a.c | 4 +++-
>  drivers/media/dvb-frontends/itd1000.c | 5 +++--
>  drivers/media/dvb-frontends/mt312.c   | 4 +++-
>  drivers/media/dvb-frontends/stb0899_drv.c | 3 ++-
>  drivers/media/dvb-frontends/stb6100.c | 6 --
>  drivers/media/dvb-frontends/stv0367.c | 4 +++-
>  drivers/media/dvb-frontends/stv090x.c | 4 +++-
>  drivers/media/dvb-frontends/stv6110x.c| 4 +++-
>  drivers/media/dvb-frontends/zl10039.c | 4 +++-
>  12 files changed, 36 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/media/dvb-frontends/ascot2e.c 
> b/drivers/media/dvb-frontends/ascot2e.c
> index 0ee0df53b91b..1219272ca3f0 100644
> --- a/drivers/media/dvb-frontends/ascot2e.c
> +++ b/drivers/media/dvb-frontends/ascot2e.c
> @@ -155,7 +155,9 @@ static int ascot2e_write_regs(struct ascot2e_priv *priv,
>  
>  static int ascot2e_write_reg(struct ascot2e_priv *priv, u8 reg, u8 val)
>  {
> - return ascot2e_write_regs(priv, reg, , 1);
> + u8 tmp = val;
> +
> + return ascot2e_write_regs(priv, reg, , 1);
>  }
>  
>  static int ascot2e_read_regs(struct ascot2e_priv *priv,
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 48ee9bc00c06..b7574deff5c6 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -257,7 +257,9 @@ static int cxd2841er_write_regs(struct cxd2841er_priv 
> *priv,
>  static int cxd2841er_write_reg(struct cxd2841er_priv *priv,
>  u8 addr, u8 reg, u8 val)
>  {
> - return cxd2841er_write_regs(priv, addr, reg, , 1);
> + u8 tmp = val;
> +
> + return cxd2841er_write_regs(priv, addr, reg, , 1);
>  }


This kind of sucks, and it is completely unexpected... why val is
so special that it would require this kind of hack?

Also, there's always a risk of someone see it and decide to 
simplify the code, returning it to the previous state.

So, if we're willing to do something like that, IMHO, we should have
some macro that would document it, and fall back to the direct
code if the compiler is not gcc 5, 6 or 7.

Regards,
Mauro

[GIT PULL for 4.16] Sensor driver patches, et8ek8 lens binding

[Sakari Ailus]

Hi Mauro,

Here are sensor driver patches, including error handling fixes, and DT
binding documentation and DTS changes for Nokia N900.

Please pull.


The following changes since commit be9b53c83792e3898755dce90f8c632d40e7c83e:

  media: dvb-frontends: complete kernel-doc markups (2017-11-30 04:19:05 -0500)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git for-4.16-1

for you to fetch changes up to 5e1372893debd1d0e74546072424ee912c9625fd:

  v4l: mt9v032: Disable clock on error paths (2017-11-30 14:26:42 +0200)


Akinobu Mita (2):
  media: ov7670: use v4l2_async_unregister_subdev()
  media: ov7670: add V4L2_CID_TEST_PATTERN control

Alexey Khoroshilov (1):
  v4l: mt9v032: Disable clock on error paths

Pavel Machek (2):
  dt-bindings: et8ek8: Document support for flash and lens devices
  ARM: dts: nokia n900: enable autofocus

Sakari Ailus (1):
  imx274: Fix error handling, add MAINTAINERS entry

 .../bindings/media/i2c/toshiba,et8ek8.txt  |  7 
 MAINTAINERS|  8 
 arch/arm/boot/dts/omap3-n900.dts   |  2 +
 drivers/media/i2c/imx274.c |  5 +--
 drivers/media/i2c/mt9v032.c| 21 +++---
 drivers/media/i2c/ov7670.c | 48 +-
 6 files changed, 80 insertions(+), 11 deletions(-)

-- 
Kind regards,

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

Re: [PATCH v3 26/26] kfifo: DECLARE_KIFO_PTR(fifo, u64) does not work on arm 32 bit

[Mauro Carvalho Chehab]

Em Tue, 10 Oct 2017 09:59:42 +0200
Sean Young  escreveu:

> If you try to store u64 in a kfifo (or a struct with u64 members),
> then the buf member of __STRUCT_KFIFO_PTR will cause 4 bytes
> padding due to alignment (note that struct __kfifo is 20 bytes
> on 32 bit).
> 
> That in turn causes the __is_kfifo_ptr() to fail, which is caught
> by kfifo_alloc(), which now returns EINVAL.
> 
> So, ensure that __is_kfifo_ptr() compares to the right structure.
> 
> Signed-off-by: Sean Young 
> Acked-by: Stefani Seibold 

Hi Stefani/Andrew,

As this patch is required for the LIRC rework, would be ok if I would
merge it via the media tree?

Thanks!
Mauro


> 
> ---
>  include/linux/kfifo.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
> index 41eb6fdf87a8..86b5fb08e96c 100644
> --- a/include/linux/kfifo.h
> +++ b/include/linux/kfifo.h
> @@ -113,7 +113,8 @@ struct kfifo_rec_ptr_2 __STRUCT_KFIFO_PTR(unsigned char, 
> 2, void);
>   * array is a part of the structure and the fifo type where the array is
>   * outside of the fifo structure.
>   */
> -#define  __is_kfifo_ptr(fifo)(sizeof(*fifo) == sizeof(struct 
> __kfifo))
> +#define  __is_kfifo_ptr(fifo) \
> + (sizeof(*fifo) == sizeof(STRUCT_KFIFO_PTR(typeof(*(fifo)->type
>  
>  /**
>   * DECLARE_KFIFO_PTR - macro to declare a fifo pointer object



Thanks,
Mauro

[GIT PULL for 4.16] Intel IPU3 CIO2 CSI-2 receiver driver

[Sakari Ailus]

Hi Mauro,

Here's the Intel IPU3 CIO2 CSI-2 receiver driver, with the accompanying
format definitions.

Please pull.


The following changes since commit be9b53c83792e3898755dce90f8c632d40e7c83e:

  media: dvb-frontends: complete kernel-doc markups (2017-11-30 04:19:05 -0500)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git ipu3

for you to fetch changes up to f178207daa68e817ab6fd702d81ed7c8637ab72c:

  intel-ipu3: cio2: add new MIPI-CSI2 driver (2017-11-30 14:19:47 +0200)


Yong Zhi (3):
  videodev2.h, v4l2-ioctl: add IPU3 raw10 color format
  doc-rst: add IPU3 raw10 bayer pixel format definitions
  intel-ipu3: cio2: add new MIPI-CSI2 driver

 Documentation/media/uapi/v4l/pixfmt-rgb.rst|1 +
 .../media/uapi/v4l/pixfmt-srggb10-ipu3.rst |  335 
 MAINTAINERS|8 +
 drivers/media/pci/Kconfig  |2 +
 drivers/media/pci/Makefile |3 +-
 drivers/media/pci/intel/Makefile   |5 +
 drivers/media/pci/intel/ipu3/Kconfig   |   19 +
 drivers/media/pci/intel/ipu3/Makefile  |1 +
 drivers/media/pci/intel/ipu3/ipu3-cio2.c   | 2052 
 drivers/media/pci/intel/ipu3/ipu3-cio2.h   |  449 +
 drivers/media/v4l2-core/v4l2-ioctl.c   |4 +
 include/uapi/linux/videodev2.h |6 +
 12 files changed, 2884 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst
 create mode 100644 drivers/media/pci/intel/Makefile
 create mode 100644 drivers/media/pci/intel/ipu3/Kconfig
 create mode 100644 drivers/media/pci/intel/ipu3/Makefile
 create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.c
 create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.h

-- 
Kind regards,

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

[PATCH, RESEND 1/2] dvb-frontends: fix i2c access helpers for KASAN

[Arnd Bergmann]

A typical code fragment was copied across many dvb-frontend drivers and
causes large stack frames when built with with CONFIG_KASAN on gcc-5/6/7:

drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

gcc-8 now solves this by consolidating the stack slots for the argument
variables, but on older compilers we can get the same behavior by taking
the pointer of a local variable rather than the inline function argument.

Cc: sta...@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann 
---
I'm undecided here whether there should be a comment pointing
to PR81715 for each file that the bogus local variable workaround
to prevent it from being cleaned up again. It's probably not
necessary since anything that causes actual problems would also
trigger a build warning.
---
 drivers/media/dvb-frontends/ascot2e.c | 4 +++-
 drivers/media/dvb-frontends/cxd2841er.c   | 4 +++-
 drivers/media/dvb-frontends/helene.c  | 4 +++-
 drivers/media/dvb-frontends/horus3a.c | 4 +++-
 drivers/media/dvb-frontends/itd1000.c | 5 +++--
 drivers/media/dvb-frontends/mt312.c   | 4 +++-
 drivers/media/dvb-frontends/stb0899_drv.c | 3 ++-
 drivers/media/dvb-frontends/stb6100.c | 6 --
 drivers/media/dvb-frontends/stv0367.c | 4 +++-
 drivers/media/dvb-frontends/stv090x.c | 4 +++-
 drivers/media/dvb-frontends/stv6110x.c| 4 +++-
 drivers/media/dvb-frontends/zl10039.c | 4 +++-
 12 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/drivers/media/dvb-frontends/ascot2e.c 
b/drivers/media/dvb-frontends/ascot2e.c
index 0ee0df53b91b..1219272ca3f0 100644
--- a/drivers/media/dvb-frontends/ascot2e.c
+++ b/drivers/media/dvb-frontends/ascot2e.c
@@ -155,7 +155,9 @@ static int ascot2e_write_regs(struct ascot2e_priv *priv,
 
 static int ascot2e_write_reg(struct ascot2e_priv *priv, u8 reg, u8 val)
 {
-   return ascot2e_write_regs(priv, reg, , 1);
+   u8 tmp = val;
+
+   return ascot2e_write_regs(priv, reg, , 1);
 }
 
 static int ascot2e_read_regs(struct ascot2e_priv *priv,
diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 48ee9bc00c06..b7574deff5c6 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -257,7 +257,9 @@ static int cxd2841er_write_regs(struct cxd2841er_priv *priv,
 static int cxd2841er_write_reg(struct cxd2841er_priv *priv,
   u8 addr, u8 reg, u8 val)
 {
-   return cxd2841er_write_regs(priv, addr, reg, , 1);
+   u8 tmp = val;
+
+   return cxd2841er_write_regs(priv, addr, reg, , 1);
 }
 
 static int cxd2841er_read_regs(struct cxd2841er_priv *priv,
diff --git a/drivers/media/dvb-frontends/helene.c 
b/drivers/media/dvb-frontends/helene.c
index 4bf5a551ba40..6e93f2d1575b 100644
--- a/drivers/media/dvb-frontends/helene.c
+++ b/drivers/media/dvb-frontends/helene.c
@@ -331,7 +331,9 @@ static int helene_write_regs(struct helene_priv *priv,
 
 static int helene_write_reg(struct helene_priv *priv, u8 reg, u8 val)
 {
-   return helene_write_regs(priv, reg, , 1);
+   u8 tmp = val;
+
+   return helene_write_regs(priv, reg, , 1);
 }
 
 static int helene_read_regs(struct helene_priv *priv,
diff --git a/drivers/media/dvb-frontends/horus3a.c 
b/drivers/media/dvb-frontends/horus3a.c
index 68d759c4c52e..fa9e2d373073 100644
--- a/drivers/media/dvb-frontends/horus3a.c
+++ b/drivers/media/dvb-frontends/horus3a.c
@@ -89,7 +89,9 @@ static int horus3a_write_regs(struct horus3a_priv *priv,
 
 static int horus3a_write_reg(struct horus3a_priv *priv, u8 reg, u8 val)
 {
-   return horus3a_write_regs(priv, reg, , 1);
+   u8 tmp = val;
+
+   return horus3a_write_regs(priv, reg, , 1);
 }
 
 static int horus3a_enter_power_save(struct horus3a_priv *priv)
diff --git a/drivers/media/dvb-frontends/itd1000.c 
b/drivers/media/dvb-frontends/itd1000.c
index 5bb1e73a10b4..1ac5177162f6 100644
--- a/drivers/media/dvb-frontends/itd1000.c
+++ b/drivers/media/dvb-frontends/itd1000.c
@@ -95,8 +95,9 @@ static int itd1000_read_reg(struct itd1000_state *state, u8 
reg)
 
 static inline int itd1000_write_reg(struct itd1000_state *state, u8 r, u8 v)
 {
-   int ret = itd1000_write_regs(state, r, , 1);
-   state->shadow[r] = v;
+   u8 tmp = v;
+   int ret = 

[PATCH, RESEND 2/2] r820t: fix r820t_write_reg for KASAN

[Arnd Bergmann]

With CONFIG_KASAN, we get an overly long stack frame due to inlining
the register access functions:

drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is 
larger than 2048 bytes [-Werror=frame-larger-than=]

This is caused by a gcc bug that has now been fixed in gcc-8.
To work around the problem, we can pass the register data
through a local variable that older gcc versions can optimize
out as well.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann 
---
 drivers/media/tuners/r820t.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c
index ba80376a3b86..d097eb04a0e9 100644
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -396,9 +396,11 @@ static int r820t_write(struct r820t_priv *priv, u8 reg, 
const u8 *val,
return 0;
 }
 
-static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
+static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
 {
-   return r820t_write(priv, reg, , 1);
+   u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */
+
+   return r820t_write(priv, reg, , 1);
 }
 
 static int r820t_read_cache_reg(struct r820t_priv *priv, int reg)
@@ -411,17 +413,18 @@ static int r820t_read_cache_reg(struct r820t_priv *priv, 
int reg)
return -EINVAL;
 }
 
-static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
+static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
u8 bit_mask)
 {
+   u8 tmp = val;
int rc = r820t_read_cache_reg(priv, reg);
 
if (rc < 0)
return rc;
 
-   val = (rc & ~bit_mask) | (val & bit_mask);
+   tmp = (rc & ~bit_mask) | (tmp & bit_mask);
 
-   return r820t_write(priv, reg, , 1);
+   return r820t_write(priv, reg, , 1);
 }
 
 static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len)
-- 
2.9.0

Re: [bug report] media: dvb_frontend: cleanup ioctl handling logic

[Menion]

Hello
Is anyone working on adding compact_ioctl?
So far it is impossible to use linux-media from 32bit userland on 64bit kernels
Bye

2017-11-30 10:58 GMT+01:00 Dan Carpenter :
> Hello Mauro Carvalho Chehab,
>
> The patch d73dcf0cdb95: "media: dvb_frontend: cleanup ioctl handling
> logic" from Sep 18, 2017, leads to the following static checker
> warning:
>
> drivers/media/dvb-core/dvb_frontend.c:2469 dvb_frontend_handle_ioctl()
> error: uninitialized symbol 'err'.
>
> drivers/media/dvb-core/dvb_frontend.c
>   2427  case FE_READ_UNCORRECTED_BLOCKS:
>   2428  if (fe->ops.read_ucblocks) {
>   2429  if (fepriv->thread)
>   2430  err = fe->ops.read_ucblocks(fe, parg);
>   2431  else
>   2432  err = -EAGAIN;
>   2433  }
>
> "err" isn't initialized if ->ops.read_ucblocks is NULL.
>
>   2434  break;
>   2435
>   2436  /* DEPRECATED DVBv3 ioctls */
>   2437
>   2438  case FE_SET_FRONTEND:
>   2439  err = dvbv3_set_delivery_system(fe);
>   2440  if (err)
>   2441  break;
>   2442
>   2443  err = dtv_property_cache_sync(fe, c, parg);
>   2444  if (err)
>   2445  break;
>   2446  err = dtv_set_frontend(fe);
>   2447  break;
>   2448  case FE_GET_EVENT:
>   2449  err = dvb_frontend_get_event (fe, parg, 
> file->f_flags);
>   2450  break;
>   2451
>   2452  case FE_GET_FRONTEND: {
>   2453  struct dtv_frontend_properties getp = 
> fe->dtv_property_cache;
>   2454
>   2455  /*
>   2456   * Let's use our own copy of property cache, in order 
> to
>   2457   * avoid mangling with DTV zigzag logic, as drivers 
> might
>   2458   * return crap, if they don't check if the data is 
> available
>   2459   * before updating the properties cache.
>   2460   */
>   2461  err = dtv_get_frontend(fe, , parg);
>   2462  break;
>   2463  }
>   2464
>   2465  default:
>   2466  return -ENOTSUPP;
>   2467  } /* switch */
>   2468
>   2469  return err;
> ^^
>   2470  }
>
> regards,
> dan carpenter

Re: [PATCH 12/22] media: s3c-camif: add missing description at s3c_camif_find_format()

[Sylwester Nawrocki]

On 11/29/2017 08:08 PM, Mauro Carvalho Chehab wrote:
> Fix this warning:
>   drivers/media/platform/s3c-camif/camif-core.c:112: warning: No 
> description found for parameter 'vp'
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Sylwester Nawrocki 

[bug report] media: dvb_frontend: cleanup ioctl handling logic

[Dan Carpenter]

Hello Mauro Carvalho Chehab,

The patch d73dcf0cdb95: "media: dvb_frontend: cleanup ioctl handling
logic" from Sep 18, 2017, leads to the following static checker
warning:

drivers/media/dvb-core/dvb_frontend.c:2469 dvb_frontend_handle_ioctl()
error: uninitialized symbol 'err'.

drivers/media/dvb-core/dvb_frontend.c
  2427  case FE_READ_UNCORRECTED_BLOCKS:
  2428  if (fe->ops.read_ucblocks) {
  2429  if (fepriv->thread)
  2430  err = fe->ops.read_ucblocks(fe, parg);
  2431  else
  2432  err = -EAGAIN;
  2433  }

"err" isn't initialized if ->ops.read_ucblocks is NULL.

  2434  break;
  2435  
  2436  /* DEPRECATED DVBv3 ioctls */
  2437  
  2438  case FE_SET_FRONTEND:
  2439  err = dvbv3_set_delivery_system(fe);
  2440  if (err)
  2441  break;
  2442  
  2443  err = dtv_property_cache_sync(fe, c, parg);
  2444  if (err)
  2445  break;
  2446  err = dtv_set_frontend(fe);
  2447  break;
  2448  case FE_GET_EVENT:
  2449  err = dvb_frontend_get_event (fe, parg, file->f_flags);
  2450  break;
  2451  
  2452  case FE_GET_FRONTEND: {
  2453  struct dtv_frontend_properties getp = 
fe->dtv_property_cache;
  2454  
  2455  /*
  2456   * Let's use our own copy of property cache, in order to
  2457   * avoid mangling with DTV zigzag logic, as drivers 
might
  2458   * return crap, if they don't check if the data is 
available
  2459   * before updating the properties cache.
  2460   */
  2461  err = dtv_get_frontend(fe, , parg);
  2462  break;
  2463  }
  2464  
  2465  default:
  2466  return -ENOTSUPP;
  2467  } /* switch */
  2468  
  2469  return err;
^^
  2470  }

regards,
dan carpenter

Re: [PATCH 16/22] media: vsp1: add a missing kernel-doc parameter

[Kieran Bingham]

Hi Mauro,

Thanks for the patch.

On 29/11/17 19:08, Mauro Carvalho Chehab wrote:
> Fix this warning:
>   drivers/media/platform/vsp1/vsp1_dl.c:87: warning: No description found 
> for parameter 'has_chain'
> 
> Signed-off-by: Mauro Carvalho Chehab 

Ah yes, I missed that... Thanks for fixing.

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/vsp1/vsp1_dl.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
> b/drivers/media/platform/vsp1/vsp1_dl.c
> index 8b5cbb6b7a70..4257451f1bd8 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -70,6 +70,7 @@ struct vsp1_dl_body {
>   * @dma: DMA address for the header
>   * @body0: first display list body
>   * @fragments: list of extra display list bodies
> + * @has_chain: if true, indicates that there's a partition chain
>   * @chain: entry in the display list partition chain
>   */
>  struct vsp1_dl_list {
> 

Re: [PATCH 19/22] media: drivers: remove "/**" from non-kernel-doc comments

[Kieran Bingham]

Hi Mauro,

Thanks for the patch.

On 29/11/17 19:08, Mauro Carvalho Chehab wrote:
> Several comments are wrongly tagged as kernel-doc, causing
> those warnings:
> 
>   drivers/media/rc/st_rc.c:98: warning: No description found for parameter 
> 'irq'
>   drivers/media/rc/st_rc.c:98: warning: No description found for parameter 
> 'data'
>   drivers/media/pci/solo6x10/solo6x10-enc.c:183: warning: No description 
> found for parameter 'solo_dev'
>   drivers/media/pci/solo6x10/solo6x10-enc.c:183: warning: No description 
> found for parameter 'ch'
>   drivers/media/pci/solo6x10/solo6x10-enc.c:183: warning: No description 
> found for parameter 'qp'
>   drivers/media/usb/pwc/pwc-dec23.c:652: warning: Cannot understand  *
>on line 652 - I thought it was a doc line
>   drivers/media/usb/dvb-usb/cinergyT2-fe.c:40: warning: No description found 
> for parameter 'op'
>   drivers/media/usb/dvb-usb/friio-fe.c:301: warning: Cannot understand  * 
> (reg, val) commad list to initialize this module.
>on line 301 - I thought it was a doc line
>   drivers/media/rc/streamzap.c:201: warning: No description found for 
> parameter 'urb'
>   drivers/media/rc/streamzap.c:333: warning: No description found for 
> parameter 'intf'
>   drivers/media/rc/streamzap.c:333: warning: No description found for 
> parameter 'id'
>   drivers/media/rc/streamzap.c:464: warning: No description found for 
> parameter 'interface'
>   drivers/media/i2c/ov5647.c:432: warning: Cannot understand  * @short Subdev 
> core operations registration
>on line 432 - I thought it was a doc line
>   drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
> parameter 'd'
>   drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
> parameter 'addr'
>   drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
> parameter 'wbuf'
>   drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
> parameter 'wlen'
>   drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
> parameter 'rbuf'
>   drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
> parameter 'rlen'
>   drivers/media/platform/vim2m.c:350: warning: No description found for 
> parameter 'priv'
>   drivers/media/dvb-frontends/tua6100.c:34: warning: cannot understand 
> function prototype: 'struct tua6100_priv '
>   drivers/media/platform/sti/hva/hva-h264.c:140: warning: cannot understand 
> function prototype: 'struct hva_h264_stereo_video_sei '
>   drivers/media/platform/sti/hva/hva-h264.c:150: warning: Cannot understand  
> * @frame_width: width in pixels of the buffer containing the input frame
>on line 150 - I thought it was a doc line
>   drivers/media/platform/sti/hva/hva-h264.c:356: warning: Cannot understand  
> * @ slice_size: slice size
>on line 356 - I thought it was a doc line
>   drivers/media/platform/sti/hva/hva-h264.c:369: warning: Cannot understand  
> * @ bitstream_size: bitstream size
>on line 369 - I thought it was a doc line
>   drivers/media/platform/sti/hva/hva-h264.c:395: warning: Cannot understand  
> * @seq_info:  sequence information buffer
>on line 395 - I thought it was a doc line
>   drivers/media/dvb-frontends/sp887x.c:137: warning: No description found for 
> parameter 'fe'
>   drivers/media/dvb-frontends/sp887x.c:137: warning: No description found for 
> parameter 'fw'
>   drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for 
> parameter 'n'
>   drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for 
> parameter 'd'
>   drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for 
> parameter 'quotient_i'
>   drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for 
> parameter 'quotient_f'
>   drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:83: warning: cannot 
> understand function prototype: 'struct ttusb '
>   drivers/media/platform/sh_veu.c:277: warning: No description found for 
> parameter 'priv'
>   drivers/media/dvb-frontends/zl10036.c:33: warning: cannot understand 
> function prototype: 'int zl10036_debug; '
>   drivers/media/dvb-frontends/zl10036.c:179: warning: No description found 
> for parameter 'state'
>   drivers/media/dvb-frontends/zl10036.c:179: warning: No description found 
> for parameter 'frequency'
>   drivers/media/platform/rcar_fdp1.c:1139: warning: No description found for 
> parameter 'priv'
>   drivers/media/platform/ti-vpe/vpe.c:933: warning: No description found for 
> parameter 'priv'
>   drivers/media/usb/gspca/ov519.c:36: warning: No description found for 
> parameter 'fmt'
>   drivers/media/usb/dvb-usb/dib0700_devices.c:3367: warning: No description 
> found for parameter 'adap'
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Kieran Bingham 

For FDP1 at least :)

> ---
>  drivers/media/dvb-frontends/sp887x.c  |  6 +++---
>