cron job: media_tree daily build: ERRORS
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
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
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 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, > - ¶ms, &pdev->dev, "CI_Y"); > + pcdev->dma_chans[0] = dma_request_slave_channel(&pdev->dev, "CI_Y"); > if (!pcdev->dma_chans[0]) { > dev_err(&pdev->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, > - ¶ms, &pdev->dev, "CI_U"); > + pcdev->dma_chans[1] = dma_request_slave_channel(&pdev->dev, "CI_U"); > if (!pcdev->dma_chans[1]) { > dev_err(&pdev->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, > - ¶ms, &pdev->dev, "CI_V"); > + pcdev->dma_chans[2] = dma_request_slave_channel(&pdev->dev, "CI_V"); > if (!pcdev->dma_chans[2]) { > dev_err(&pdev->dev, "Can't request DMA for V\n"); > err = -ENODEV;
Re: cx88 invalid video opcodes when VBI enabled
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
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&pid=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
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&pid=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
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(&afe->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 = &timings.bt; - unsigned int fps; tx = adv748x_get_remote_sd(&hdmi->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(&hdmi->sd, &timings); - 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
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
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
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 = &dev->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 = &dev->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
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(&ir_raw_handler_lock); + list_for_each_entry(handler, &ir_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(&ir_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(&ir_raw_handler_lock); list_add_tail(&dev->raw->list, &ir_raw_client_list); - list_for_each_entry(handler, &ir_raw_handler_list, list) - if (handler->raw_register) - handler->raw_register(dev); mutex_unlock(&ir_raw_handler_lock); return 0; @@ -648,7 +657,8 @@ void ir_raw_event_unregister(struct rc_dev *dev) mutex_lock(&ir_raw_handler_lock); list_del(&dev->raw->list); list_for_each_entry(handler, &ir_raw_handler_list, list) - if (handler->raw_unregister) + if (handler->raw_unregister && + (handler->protocols & dev->enabled_protocols)) handler->raw_unregister(dev); mutex_unlock(&ir_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(&ir_raw_handler_lock); list_add_tail(&ir_raw_handler->list, &ir_raw_handler_list); - if (ir_raw_handler->raw_register) - list_for_each_entry(raw, &ir_raw_client_list, list) - ir_raw_handler->raw_register(raw->dev); atomic64_or(ir_raw_handler->protocols, &available_protocols); mutex_unlock(&ir_raw_handler_lock); @@ -683,9 +688,10 @@ void ir_raw_handler_unregister(struct ir_raw_handler *ir_raw_handler) mutex_lock(&ir_raw_handler_lock); list_del(&ir_raw_handler->list); list_for_each_entry(raw, &ir_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, &available_protocols); mutex_unlock(&ir_raw_handler_lock); -- 2.14.3
[PATCH] media: staging: atomisp: Using module_pci_driver.
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(&atomisp_pci_driver); -} - -static void __exit atomisp_exit(void) -{ - pci_unregister_driver(&atomisp_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
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
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