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:   Sun Apr 22 05:00:11 CEST 2018
media-tree git hash:1d338b86e17d87215cf57b1ad1d13b2afe582d33
media_build git hash:   4fb7a3cc8d0f56c7cddc3b5b29e35aa1159bc8d9
v4l-utils git hash: 9a4acdbe53884e5a433c1295eead61e45b0718e7
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: 0.5.2-RC1
smatch version: 0.5.1
host hardware:  x86_64
host os:4.15.0-2-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: WARNINGS: VIDEO_OMAP3 VIDEO_OMAP3_DEBUG
linux-2.6.36.4-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.101-i686: ERRORS
linux-3.0.101-x86_64: ERRORS
linux-3.1.10-i686: OK
linux-3.1.10-x86_64: OK
linux-3.2.101-i686: OK
linux-3.2.101-x86_64: OK
linux-3.3.8-i686: OK
linux-3.3.8-x86_64: OK
linux-3.4.113-i686: OK
linux-3.4.113-x86_64: OK
linux-3.5.7-i686: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-i686: OK
linux-3.6.11-x86_64: OK
linux-3.7.10-i686: OK
linux-3.7.10-x86_64: OK
linux-3.8.13-i686: OK
linux-3.8.13-x86_64: OK
linux-3.9.11-i686: OK
linux-3.9.11-x86_64: OK
linux-3.10.108-i686: WARNINGS
linux-3.10.108-x86_64: WARNINGS
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.56-i686: OK
linux-3.16.56-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.102-i686: OK
linux-3.18.102-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.51-i686: OK
linux-4.1.51-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.109-i686: OK
linux-4.4.109-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.91-i686: OK
linux-4.9.91-x86_64: OK
linux-4.14.31-i686: OK
linux-4.14.31-x86_64: OK
linux-4.15.14-i686: OK
linux-4.15.14-x86_64: OK
linux-4.16-i686: OK
linux-4.16-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH] media: imx: Skip every second frame in VDIC DIRECT mode

[Marek Vasut]

On 04/21/2018 11:29 PM, Steve Longerbeam wrote:
> 
> 
> On 04/12/2018 03:04 AM, Philipp Zabel wrote:
>> On Sat, 2018-04-07 at 15:04 +0200, Marek Vasut wrote:
>>> In VDIC direct mode, the VDIC applies combing filter during and
>>> doubles the framerate, that is, after the first two half-frames
>>> are received and the first frame is emitted by the VDIC, every
>>> subsequent half-frame is patched into the result and a full frame
>>> is produced. The half-frame order in the full frames is as follows
>>> 12 32 34 54 etc.
>> Is that true? We are only supporting full motion mode (VDI_MOT_SEL=2),
>> so I was under the impression that only data from the current field
>> makes it into the full frame. The missing lines should be purely
>> estimated from the available field using the di_vfilt 4-tap filter.
> 
> Yes, the reference manual states that the VDI_MOT_SEL field
> value 2 is "Full motion, only vertical filter is used". Which is
> clearly referring to the di_vfilt 4-tap filter.
> 
> There are still some questions about how full motion mode is
> supposed to work. For one thing, the di_vfilt only operates on four
> consecutive lines of a single field. It makes no sense that the VDIC
> can compensate for motion between fields when it is operating
> with only one field.
> 
> Marek, where did you get the information that full motion mode
> applies some kind of combing filter?

By observing how the HW behaves. The input from NXP forum was mostly
useless or actually outright wrong. I have to admit it's been a while
since I created the patch, but what I saw was basically the hardware
producing frames as a combination of halfframe 1-2 2-3 3-4 etc , thus
doubling the framerate. Setting the skip normalized the framerate
without any loss of image information.

> A combing filter would imply
> taking previous and/or future fields back into the result, which is
> exactly what the other motion modes do, but as I said the reference
> manual is clear that full motion mode uses only the (single field)
> vertical filter.
> 
> The manual also mentions regarding "real-time mode" which we are
> making use of (in which the VDIC FIFO1 receives field F(n-1) directly
> from the CSI rather than from DMA):
> 
> "In addition IDMAC read the field from FIFO1 and store in external memory.
> Then stored frames are used as F(n) and F(n+1).".
> 
> It is nowhere explicitly stated, but the assumption is that this is IDMAC
> channel 13 that stores the CSI field to memory. But many people have
> asked Freescale/NXP how this works in the past, and there has never
> been a satisfactory answer. And people have reported no success in
> getting this channel to work including myself.
> 
> So the approach this driver takes is to use real-time mode to receive
> F(n-1) directly from CSI, in concert with full motion mode, so that
> the VDIC operates on F(n-1) only. Thus no DMA is necessary.
> 
> Finally I have to say that the other modes are supported in this driver,
> but they require DMA transfer of all three fields, and there is no
> output device node written to make use of those modes yet. But
> from experience, the de-interlaced result is of much better quality
> than the real-time/full-motion output.
> 
> 
> Steve
> 
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH] media: imx: Skip every second frame in VDIC DIRECT mode

[Steve Longerbeam]

On 04/12/2018 03:04 AM, Philipp Zabel wrote:

On Sat, 2018-04-07 at 15:04 +0200, Marek Vasut wrote:

In VDIC direct mode, the VDIC applies combing filter during and
doubles the framerate, that is, after the first two half-frames
are received and the first frame is emitted by the VDIC, every
subsequent half-frame is patched into the result and a full frame
is produced. The half-frame order in the full frames is as follows
12 32 34 54 etc.

Is that true? We are only supporting full motion mode (VDI_MOT_SEL=2),
so I was under the impression that only data from the current field
makes it into the full frame. The missing lines should be purely
estimated from the available field using the di_vfilt 4-tap filter.


Yes, the reference manual states that the VDI_MOT_SEL field
value 2 is "Full motion, only vertical filter is used". Which is
clearly referring to the di_vfilt 4-tap filter.

There are still some questions about how full motion mode is
supposed to work. For one thing, the di_vfilt only operates on four
consecutive lines of a single field. It makes no sense that the VDIC
can compensate for motion between fields when it is operating
with only one field.

Marek, where did you get the information that full motion mode
applies some kind of combing filter? A combing filter would imply
taking previous and/or future fields back into the result, which is
exactly what the other motion modes do, but as I said the reference
manual is clear that full motion mode uses only the (single field)
vertical filter.

The manual also mentions regarding "real-time mode" which we are
making use of (in which the VDIC FIFO1 receives field F(n-1) directly
from the CSI rather than from DMA):

"In addition IDMAC read the field from FIFO1 and store in external memory.
Then stored frames are used as F(n) and F(n+1).".

It is nowhere explicitly stated, but the assumption is that this is IDMAC
channel 13 that stores the CSI field to memory. But many people have
asked Freescale/NXP how this works in the past, and there has never
been a satisfactory answer. And people have reported no success in
getting this channel to work including myself.

So the approach this driver takes is to use real-time mode to receive
F(n-1) directly from CSI, in concert with full motion mode, so that
the VDIC operates on F(n-1) only. Thus no DMA is necessary.

Finally I have to say that the other modes are supported in this driver,
but they require DMA transfer of all three fields, and there is no
output device node written to make use of those modes yet. But
from experience, the de-interlaced result is of much better quality
than the real-time/full-motion output.


Steve

Re: [PATCH 04/15] media: pxa_camera: remove the dmaengine compat need

[Robert Jarzmik]

Robert Jarzmik  writes:

> From: Robert Jarzmik 
>
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
>
> This patch simplifies the dma resource acquisition, using the more
> generic function dma_request_slave_channel().
>
> Signed-off-by: Robert Jarzmik 
> ---
>  drivers/media/platform/pxa_camera.c | 22 +++---
>  1 file changed, 3 insertions(+), 19 deletions(-)
Hans, could I have your ack please ?

Cheers.

--
Robert

PS: The submitted patch
>
> diff --git a/drivers/media/platform/pxa_camera.c 
> b/drivers/media/platform/pxa_camera.c
> index c71a00736541..4c82d1880753 100644
> --- a/drivers/media/platform/pxa_camera.c
> +++ b/drivers/media/platform/pxa_camera.c
> @@ -2357,8 +2357,6 @@ static int pxa_camera_probe(struct platform_device 
> *pdev)
>   .src_maxburst = 8,
>   .direction = DMA_DEV_TO_MEM,
>   };
> - dma_cap_mask_t mask;
> - struct pxad_param params;
>   char clk_name[V4L2_CLK_NAME_SIZE];
>   int irq;
>   int err = 0, i;
> @@ -2432,34 +2430,20 @@ static int pxa_camera_probe(struct platform_device 
> *pdev)
>   pcdev->base = base;
>  
>   /* request dma */
> - dma_cap_zero(mask);
> - dma_cap_set(DMA_SLAVE, mask);
> - dma_cap_set(DMA_PRIVATE, mask);
> -
> - params.prio = 0;
> - params.drcmr = 68;
> - pcdev->dma_chans[0] =
> - dma_request_slave_channel_compat(mask, pxad_filter_fn,
> -  , >dev, "CI_Y");
> + pcdev->dma_chans[0] = dma_request_slave_channel(>dev, "CI_Y");
>   if (!pcdev->dma_chans[0]) {
>   dev_err(>dev, "Can't request DMA for Y\n");
>   return -ENODEV;
>   }
>  
> - params.drcmr = 69;
> - pcdev->dma_chans[1] =
> - dma_request_slave_channel_compat(mask, pxad_filter_fn,
> -  , >dev, "CI_U");
> + pcdev->dma_chans[1] = dma_request_slave_channel(>dev, "CI_U");
>   if (!pcdev->dma_chans[1]) {
>   dev_err(>dev, "Can't request DMA for Y\n");
>   err = -ENODEV;
>   goto exit_free_dma_y;
>   }
>  
> - params.drcmr = 70;
> - pcdev->dma_chans[2] =
> - dma_request_slave_channel_compat(mask, pxad_filter_fn,
> -  , >dev, "CI_V");
> + pcdev->dma_chans[2] = dma_request_slave_channel(>dev, "CI_V");
>   if (!pcdev->dma_chans[2]) {
>   dev_err(>dev, "Can't request DMA for V\n");
>   err = -ENODEV;

Re: cx88 invalid video opcodes when VBI enabled

[Devin Heitmueller]

Hi Daniel,

My apologies for the delayed replies; been out of town for the last
couple of days.

On Fri, Apr 20, 2018 at 5:54 PM, Daniel Glöckner  wrote:
> for some reason I feel like buffer_queue in cx88-vbi.c should not be
> calling cx8800_start_vbi_dma as it is also called a few lines further
> down in start_streaming.
>
> Devin, can you check if it helps to remove that line and if VBI still
> works afterwards?

So I've commented out that line in buffer_queue, and so far haven't
been able to reproduce the issue, and it does look like VBI is working
as expected (captions are being rendered in VLC).  This doesn't
suggest I've done exhaustive testing by any means, but it's certainly
a good sign.

I've seen drivers in the past which start the main data pump when
buffer_queue() or buffer_prepare() is called (whether it be to start a
DMA engine in the case of PCI or start URB submission in the case of
USB devices).  However it's not clear that's required, in particular
with VB2 which will automatically call start_streaming() in the case
where read() is used.  If I had to guess, I suspect the origin of
starting DMA that early was probably oriented around users who wanted
to simply run "cat /dev/video0 > out.mpeg" without having to
explicitly issue a bunch of V4L ioctl() calls beforehand.

It's worth noting that we're also doing it in the buffer_queue()
routine for video and not just VBI.  Presumably we would want to drop
both cases.

Hans, you did the VB2 conversion and have obviously been through this
exercise with a number of other drivers.  Any thoughts on whether we
can drop the starting of DMA engine in buffer_queue()?

On a related note, a quick review of the start/stop logic for DMA in
that driver suggests the calls might not be properly balanced.  Looks
like portions of the core logic are also duplicated between
stop_streaming() and stop_video_dma() (which is only ever used if
CONFIG_PM is defined).  It feels like it could probably use some
review/cleanup, although I'm loathed to touch such a mature driver for
fear of breaking something subtle.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

[Matthias Reichl]

On Sat, Apr 21, 2018 at 03:18:52PM +0200, Matthias Reichl wrote:
> Hi Sean,
> 
> On Fri, Apr 20, 2018 at 12:17:23AM +0200, Matthias Reichl wrote:
> > One of the affected users reported back that the fix worked fine!
> > 
> > I'm keeping an eye on further reports but so far I'd say everything's
> > working really well.
> 
> Another bug report came in, button press results in multiple
> key down/up events
> https://forum.kodi.tv/showthread.php?tid=298461=2727837#pid2727837
> (and following posts).
> 
> ir-ctl -r output looks fine to me, but ir-keytable -t output suggests
> we'll need a margin between raw timeout and key up timeout:
> 
> https://pastebin.com/6RTSGXvp
> 2199.824106: event type EV_MSC(0x04): scancode = 0x800f0419
> 2199.824106: event type EV_KEY(0x01) key_down: KEY_STOP(0x0080)
> 2199.824106: event type EV_SYN(0x00).
> 2199.887081: event type EV_KEY(0x01) key_up: KEY_STOP(0x0080)
> 2199.887081: event type EV_MSC(0x04): scancode = 0x800f0422
> 2199.887081: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
> 2199.887081: event type EV_SYN(0x00).
> 2200.029804: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
> 2200.029804: event type EV_SYN(0x00).

Sorry, just noticed I snipped off the interesting part, here
is the rest:

2200.036070: event type EV_MSC(0x04): scancode = 0x800f0422
2200.036070: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
2200.036070: event type EV_SYN(0x00).
2200.143067: event type EV_MSC(0x04): scancode = 0x800f0422
2200.143067: event type EV_SYN(0x00).
2200.206061: event type EV_MSC(0x04): scancode = 0x800f0422
2200.206061: event type EV_SYN(0x00).
2200.346472: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
2200.346472: event type EV_SYN(0x00).

I looked at the log again, and now it doesn't make much sense
to me.

I'm not exactly sure what happened with the first KEY_OK
scancode, that seems to have been decoded ~60ms after the
KEY_STOP scancode (.887 vs .824).

The second KEY_OK scancode was decoded ~ 150ms after the first,
(and caused the problem), delay to third is 107ms, to fourth 63ms.

I'll ask the user to change batteries on the remote and check
if the reception is OK, could be that this was a false alarm.

Adding some margin (maybe 20-50ms) for keyup could still make
sense though, as currently we have basically just the timeout
as margin, which can be quite low and round to 1-2 jiffies.

so long,

Hias

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

[Matthias Reichl]

Hi Sean,

On Fri, Apr 20, 2018 at 12:17:23AM +0200, Matthias Reichl wrote:
> One of the affected users reported back that the fix worked fine!
> 
> I'm keeping an eye on further reports but so far I'd say everything's
> working really well.

Another bug report came in, button press results in multiple
key down/up events
https://forum.kodi.tv/showthread.php?tid=298461=2727837#pid2727837
(and following posts).

ir-ctl -r output looks fine to me, but ir-keytable -t output suggests
we'll need a margin between raw timeout and key up timeout:

https://pastebin.com/6RTSGXvp
2199.824106: event type EV_MSC(0x04): scancode = 0x800f0419
2199.824106: event type EV_KEY(0x01) key_down: KEY_STOP(0x0080)
2199.824106: event type EV_SYN(0x00).
2199.887081: event type EV_KEY(0x01) key_up: KEY_STOP(0x0080)
2199.887081: event type EV_MSC(0x04): scancode = 0x800f0422
2199.887081: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
2199.887081: event type EV_SYN(0x00).
2200.029804: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
2200.029804: event type EV_SYN(0x00).

so long,

Hias

[PATCH] media: i2c: adv748x: Fix pixel rate values

[Laurent Pinchart]

The pixel rate, as reported by the V4L2_CID_PIXEL_RATE control, must
include both horizontal and vertical blanking. Both the AFE and HDMI
receiver program it incorrectly:

- The HDMI receiver goes to the trouble of removing blanking to compute
the rate of active pixels. This is easy to fix by removing the
computation and returning the incoming pixel clock rate directly.

- The AFE performs similar calculation, while it should simply return
the fixed pixel rate for analog sources, mandated by the ADV748x to be
28.63636 MHz.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/i2c/adv748x/adv748x-afe.c  | 11 +--
 drivers/media/i2c/adv748x/adv748x-hdmi.c |  8 +---
 2 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c 
b/drivers/media/i2c/adv748x/adv748x-afe.c
index 61514bae7e5c..3e18d5ae813b 100644
--- a/drivers/media/i2c/adv748x/adv748x-afe.c
+++ b/drivers/media/i2c/adv748x/adv748x-afe.c
@@ -321,17 +321,16 @@ static const struct v4l2_subdev_video_ops 
adv748x_afe_video_ops = {
 static int adv748x_afe_propagate_pixelrate(struct adv748x_afe *afe)
 {
struct v4l2_subdev *tx;
-   unsigned int width, height, fps;
 
tx = adv748x_get_remote_sd(>pads[ADV748X_AFE_SOURCE]);
if (!tx)
return -ENOLINK;
 
-   width = 720;
-   height = afe->curr_norm & V4L2_STD_525_60 ? 480 : 576;
-   fps = afe->curr_norm & V4L2_STD_525_60 ? 30 : 25;
-
-   return adv748x_csi2_set_pixelrate(tx, width * height * fps);
+   /*
+* The ADV748x samples analog video signals using an externally supplied
+* clock whose frequency is required to be 28.63636 MHz.
+*/
+   return adv748x_csi2_set_pixelrate(tx, 28636360);
 }
 
 static int adv748x_afe_enum_mbus_code(struct v4l2_subdev *sd,
diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c 
b/drivers/media/i2c/adv748x/adv748x-hdmi.c
index 10d229a4f088..aecc2a84dfec 100644
--- a/drivers/media/i2c/adv748x/adv748x-hdmi.c
+++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
@@ -402,8 +402,6 @@ static int adv748x_hdmi_propagate_pixelrate(struct 
adv748x_hdmi *hdmi)
 {
struct v4l2_subdev *tx;
struct v4l2_dv_timings timings;
-   struct v4l2_bt_timings *bt = 
-   unsigned int fps;
 
tx = adv748x_get_remote_sd(>pads[ADV748X_HDMI_SOURCE]);
if (!tx)
@@ -411,11 +409,7 @@ static int adv748x_hdmi_propagate_pixelrate(struct 
adv748x_hdmi *hdmi)
 
adv748x_hdmi_query_dv_timings(>sd, );
 
-   fps = DIV_ROUND_CLOSEST_ULL(bt->pixelclock,
-   V4L2_DV_BT_FRAME_WIDTH(bt) *
-   V4L2_DV_BT_FRAME_HEIGHT(bt));
-
-   return adv748x_csi2_set_pixelrate(tx, bt->width * bt->height * fps);
+   return adv748x_csi2_set_pixelrate(tx, timings.bt.pixelclock);
 }
 
 static int adv748x_hdmi_enum_mbus_code(struct v4l2_subdev *sd,
-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/1] media: nec-decoder: remove trailer_space state

[Sean Young]

On Fri, Apr 20, 2018 at 11:51:39AM -0700, Vladislav Zhurba wrote:
> From: Daniel Fu 
> 
> Remove STATE_TRAILER_SPACE from state machine.
> Causing 2 issue:
> - can not decode the keycode, if it didn't following with
>   another keycode/repeat code
> - will generate one more code in current logic.
>   i.e. key_right + repeat code + key_left + repeat code.
>   expect: key_right, key_left.
>   Result: key_right, key_right, key_right.
>   Reason: when receive repeat code of key_right, state machine will
>   stay in STATE_TRAILER_SPACE state, then wait for a new interrupt,
>   if an interrupt came after keyup_timer, then will generate another
>   fake key.

This behaviour is symptomatic of rc driver which does not generate
ir timeouts. If an rc driver does not do this, then it won't be just the
nec protocol which is not parsed correctly. For example, rc-6 in mode 6a
can have 16, 24 or 32 bits and we rely on the ir timeout to demarcate the
end of the IR message -- else we are stuck with the behaviour as you
describe above.

> According to the NEC protocol, it don't need a trailer space. Remove it.

This isn't the right solution, so NAK I'm afraid. 

Please let us know what rc driver you are using, I'm happy to help fix it.


Sean

> 
> Signed-off-by: Daniel Fu 
> Signed-off-by: Vladislav Zhurba 
> ---
>  drivers/media/rc/ir-nec-decoder.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/drivers/media/rc/ir-nec-decoder.c 
> b/drivers/media/rc/ir-nec-decoder.c
> index 21647b809e6f..760b66affd1a 100644
> --- a/drivers/media/rc/ir-nec-decoder.c
> +++ b/drivers/media/rc/ir-nec-decoder.c
> @@ -128,16 +128,6 @@ static int ir_nec_decode(struct rc_dev *dev, struct 
> ir_raw_event ev)
>   if (!eq_margin(ev.duration, NEC_TRAILER_PULSE, NEC_UNIT / 2))
>   break;
>  
> - data->state = STATE_TRAILER_SPACE;
> - return 0;
> -
> - case STATE_TRAILER_SPACE:
> - if (ev.pulse)
> - break;
> -
> - if (!geq_margin(ev.duration, NEC_TRAILER_SPACE, NEC_UNIT / 2))
> - break;
> -
>   if (data->count == NEC_NBITS) {
>   address = bitrev8((data->bits >> 24) & 0xff);
>   not_address = bitrev8((data->bits >> 16) & 0xff);
> -- 
> 2.16.2

Re: Grant

[M. M. Fridman]

I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.

Check the link below for confirmation:

http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604

Reply as soon as possible with further directives.

Best Regards,
Mikhail Fridman.

[PATCH 2/2] media: rc: imon decoder: support the stick

[Sean Young]

The iMON PAD controller has a analog stick, which can be switched to
keyboard mode (cursor keys) or work as a crappy mouse.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-imon-decoder.c | 128 -
 drivers/media/rc/rc-core-priv.h|   3 +
 2 files changed, 128 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/ir-imon-decoder.c 
b/drivers/media/rc/ir-imon-decoder.c
index 52ea3b2fda74..c69906ba1a90 100644
--- a/drivers/media/rc/ir-imon-decoder.c
+++ b/drivers/media/rc/ir-imon-decoder.c
@@ -31,9 +31,62 @@ enum imon_state {
STATE_INACTIVE,
STATE_BIT_CHK,
STATE_BIT_START,
-   STATE_FINISHED
+   STATE_FINISHED,
+   STATE_ERROR,
 };
 
+static void ir_imon_decode_scancode(struct rc_dev *dev)
+{
+   struct imon_dec *imon = >raw->imon;
+
+   /* Keyboard/Mouse toggle */
+   if (imon->bits == 0x299115b7) {
+   imon->stick_keyboard = !imon->stick_keyboard;
+   return;
+   }
+
+   if ((imon->bits & 0xfcff) == 0x68b7) {
+   s8 rel_x, rel_y;
+   u8 buf;
+
+   buf = imon->bits >> 16;
+   rel_x = (buf & 0x08) | (buf & 0x10) >> 2 |
+   (buf & 0x20) >> 4 | (buf & 0x40) >> 6;
+   if (imon->bits & 0x0200)
+   rel_x |= ~0x0f;
+   buf = imon->bits >> 8;
+   rel_y = (buf & 0x08) | (buf & 0x10) >> 2 |
+   (buf & 0x20) >> 4 | (buf & 0x40) >> 6;
+   if (imon->bits & 0x0100)
+   rel_y |= ~0x0f;
+
+   if (rel_x && rel_y && imon->stick_keyboard) {
+   if (abs(rel_y) > abs(rel_x))
+   imon->bits = rel_y > 0 ? 0x289515b7 :
+0x2aa515b7;
+   else
+   imon->bits = rel_x > 0 ? 0x2ba515b7 :
+0x29a515b7;
+   }
+
+   if (!imon->stick_keyboard) {
+   input_event(imon->idev, EV_MSC, MSC_SCAN, imon->bits);
+
+   input_report_rel(imon->idev, REL_X, rel_x);
+   input_report_rel(imon->idev, REL_Y, rel_y);
+
+   input_report_key(imon->idev, BTN_LEFT,
+(imon->bits & 0x0001) != 0);
+   input_report_key(imon->idev, BTN_RIGHT,
+(imon->bits & 0x0004) != 0);
+   input_sync(imon->idev);
+   return;
+   }
+   }
+
+   rc_keydown(dev, RC_PROTO_IMON, imon->bits, 0);
+}
+
 /**
  * ir_imon_decode() - Decode one iMON pulse or space
  * @dev:   the struct rc_dev descriptor of the device
@@ -56,6 +109,22 @@ static int ir_imon_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
data->state, data->count, TO_US(ev.duration),
TO_STR(ev.pulse));
 
+   /*
+* Since iMON protocol is a series of bits, if at any point
+* we encounter an error, make sure that any remaining bits
+* aren't parsed as a scancode made up of less bits.
+*
+* Note that if the stick is held, then the remote repeats
+* the scancode with about 12ms between them. So, make sure
+* we have at least 10ms of space after an error. That way,
+* we're at a new scancode.
+*/
+   if (data->state == STATE_ERROR) {
+   if (!ev.pulse && ev.duration > MS_TO_NS(10))
+   data->state = STATE_INACTIVE;
+   return 0;
+   }
+
for (;;) {
if (!geq_margin(ev.duration, IMON_UNIT, IMON_UNIT / 2))
return 0;
@@ -95,7 +164,7 @@ static int ir_imon_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
case STATE_FINISHED:
if (ev.pulse)
goto err_out;
-   rc_keydown(dev, RC_PROTO_IMON, data->bits, 0);
+   ir_imon_decode_scancode(dev);
data->state = STATE_INACTIVE;
break;
}
@@ -107,7 +176,7 @@ static int ir_imon_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
data->state, data->count, TO_US(ev.duration),
TO_STR(ev.pulse));
 
-   data->state = STATE_INACTIVE;
+   data->state = STATE_ERROR;
 
return -EINVAL;
 }
@@ -165,11 +234,64 @@ static int ir_imon_encode(enum rc_proto protocol, u32 
scancode,
return e - events;
 }
 
+static int ir_imon_register(struct rc_dev *dev)
+{
+   struct input_dev *idev;
+   struct imon_dec *imon = >raw->imon;
+   int ret;
+
+   idev = input_allocate_device();
+   if (!idev)
+   return -ENOMEM;
+
+   snprintf(imon->name, sizeof(imon->name),
+  

[PATCH 1/2] media: rc: only register protocol for rc device if enabled

[Sean Young]

The raw_register function exists to create input devices associated with
that IR protocol.

If the mce_kbd module is loaded, then every rc device will have mce_kbd
input devices, even if the protocol is not enabled. Change this to call
the register function to when the protocol is enabled.

Signed-off-by: Sean Young 
---
 drivers/media/rc/rc-ir-raw.c | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index cac015df4b2f..26ec296263a7 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -236,6 +236,19 @@ static int change_protocol(struct rc_dev *dev, u64 
*rc_proto)
struct ir_raw_handler *handler;
u32 timeout = 0;
 
+   mutex_lock(_raw_handler_lock);
+   list_for_each_entry(handler, _raw_handler_list, list) {
+   if (!(dev->enabled_protocols & handler->protocols) &&
+   (*rc_proto & handler->protocols) && handler->raw_register)
+   handler->raw_register(dev);
+
+   if ((dev->enabled_protocols & handler->protocols) &&
+   !(*rc_proto & handler->protocols) &&
+   handler->raw_unregister)
+   handler->raw_unregister(dev);
+   }
+   mutex_unlock(_raw_handler_lock);
+
if (!dev->max_timeout)
return 0;
 
@@ -607,7 +620,6 @@ int ir_raw_event_prepare(struct rc_dev *dev)
 
 int ir_raw_event_register(struct rc_dev *dev)
 {
-   struct ir_raw_handler *handler;
struct task_struct *thread;
 
thread = kthread_run(ir_raw_event_thread, dev->raw, "rc%u", dev->minor);
@@ -618,9 +630,6 @@ int ir_raw_event_register(struct rc_dev *dev)
 
mutex_lock(_raw_handler_lock);
list_add_tail(>raw->list, _raw_client_list);
-   list_for_each_entry(handler, _raw_handler_list, list)
-   if (handler->raw_register)
-   handler->raw_register(dev);
mutex_unlock(_raw_handler_lock);
 
return 0;
@@ -648,7 +657,8 @@ void ir_raw_event_unregister(struct rc_dev *dev)
mutex_lock(_raw_handler_lock);
list_del(>raw->list);
list_for_each_entry(handler, _raw_handler_list, list)
-   if (handler->raw_unregister)
+   if (handler->raw_unregister &&
+   (handler->protocols & dev->enabled_protocols))
handler->raw_unregister(dev);
mutex_unlock(_raw_handler_lock);
 
@@ -661,13 +671,8 @@ void ir_raw_event_unregister(struct rc_dev *dev)
 
 int ir_raw_handler_register(struct ir_raw_handler *ir_raw_handler)
 {
-   struct ir_raw_event_ctrl *raw;
-
mutex_lock(_raw_handler_lock);
list_add_tail(_raw_handler->list, _raw_handler_list);
-   if (ir_raw_handler->raw_register)
-   list_for_each_entry(raw, _raw_client_list, list)
-   ir_raw_handler->raw_register(raw->dev);
atomic64_or(ir_raw_handler->protocols, _protocols);
mutex_unlock(_raw_handler_lock);
 
@@ -683,9 +688,10 @@ void ir_raw_handler_unregister(struct ir_raw_handler 
*ir_raw_handler)
mutex_lock(_raw_handler_lock);
list_del(_raw_handler->list);
list_for_each_entry(raw, _raw_client_list, list) {
-   ir_raw_disable_protocols(raw->dev, protocols);
-   if (ir_raw_handler->raw_unregister)
+   if (ir_raw_handler->raw_unregister &&
+   (raw->dev->enabled_protocols & protocols))
ir_raw_handler->raw_unregister(raw->dev);
+   ir_raw_disable_protocols(raw->dev, protocols);
}
atomic64_andnot(protocols, _protocols);
mutex_unlock(_raw_handler_lock);
-- 
2.14.3

[PATCH] media: staging: atomisp: Using module_pci_driver.

[YueHaibing]

Remove boilerplate code by using macro module_pci_driver.

Signed-off-by: YueHaibing 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 548e00e..f95a5d0 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1555,18 +1555,7 @@ static struct pci_driver atomisp_pci_driver = {
.remove = atomisp_pci_remove,
 };
 
-static int __init atomisp_init(void)
-{
-   return pci_register_driver(_pci_driver);
-}
-
-static void __exit atomisp_exit(void)
-{
-   pci_unregister_driver(_pci_driver);
-}
-
-module_init(atomisp_init);
-module_exit(atomisp_exit);
+module_pci_driver(atomisp_pci_driver);
 
 MODULE_AUTHOR("Wen Wang ");
 MODULE_AUTHOR("Xiaolin Zhang ");
-- 
2.7.0

Re: Grant

[M. M. Fridman]

I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.

Check the link below for confirmation:

http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604

Reply as soon as possible with further directives.

Best Regards,
Mikhail Fridman.

Re: [PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Friday, 20 April 2018 16:28:29 EEST Geert Uytterhoeven wrote:
> The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
> only.  Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
> ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
> than the legacy ARCH_SHMOBILE, hence use the former.
> 
> This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> future.
> 
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Laurent Pinchart 

How would you like to get this merged ?

> ---
>  drivers/media/platform/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index f9235e8f8e962d2e..7ad4725f9d1f9627 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -396,7 +396,7 @@ config VIDEO_SH_VEU
>  config VIDEO_RENESAS_FDP1
>   tristate "Renesas Fine Display Processor"
>   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> - depends on ARCH_SHMOBILE || COMPILE_TEST
> + depends on ARCH_RENESAS || COMPILE_TEST
>   depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_MEM2MEM_DEV

-- 
Regards,

Laurent Pinchart