date:20161031

cron job: media_tree daily build: ERRORS

2016-10-31 Thread 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:   Tue Nov  1 05:00:15 CET 2016
media-tree git hash:bd676c0c04ec94bd830b9192e2c33f2c4532278d
media_build git hash:   dac8db4dd7fa3cc87715cb19ace554e080690b39
v4l-utils git hash: 4ad7174b908a36c4f315e3fe2efa7e2f8a6f375a
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.7.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: ERRORS
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: ERRORS
linux-git-i686: ERRORS
linux-git-m32r: WARNINGS
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: ERRORS
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.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: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: WARNINGS
linux-4.9-rc1-i686: WARNINGS
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.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: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
smatch: ERRORS
ABI WARNING: change for arm-davinci
ABI WARNING: change for arm-multi
ABI WARNING: change for blackfin-bf561
ABI WARNING: change for mips
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Notes on V4L2 async discussion

2016-10-31 Thread Sakari Ailus

Hi folks,

Here are my notes on the V4L2 async development discussion we had a couple
of days ago.

Philipp Zabel, Niklas Söderlund, Laurent Pinchart and myself were present.


Background
--

The V4L2 async framework provides all-important support for delaying the
registration of the external sub-devices until all the necessary information
is available in order to finish the device registration.

New use cases have surfaced since the original V4L2 async framework. While
the original framework dealt with attaching single sub-devices to the ISP
(or bridge) device which also was the owner of the media device, we now have
an entire graph of devices described in DT. This is demonstrated by e.g. the
ADV7482 analogue / HDMI -> CSI-2 converter [1] and the iMX6 IPU [2].


New use cases
-

In order to support graphs, there are two approaches that can be taken in
extending the V4L2 async framework:

1. Take the next logical step in extending the V4L2 async framework and add
   support for a different kind of a notifier and a callback for sub-devices
   to register other sub-devices or
2. Implement a generic OF graph parser which parses the entire graph,
   possibly initiated by the Media device owner driver.

In the first option, the use of callbacks to driver functions to call other
callbacks suggests that the framework is getting perhaps a little bit more
complicated than it would need to be. Graph parsing is generic, independent
of hardware. There is also a significant risk of getting things wrong in
drivers, and on the other hand the framework could do more of the driver's job.

The V4L2 async framework would require changes beyond (1) also because there
will be other than 1:1 relations between sub-devices and async slaves (now
called async sub-devices).

Thus, from debugging, maintenance and niceness point of view the second
option is preferred.


Changes required


- A generic graph parsing function is needed. The function is called on a
  device node of the Media device driver's device.

- Endpoints may refer to non-V4L2 devices as well. The drivers must
  thus be consulted before parsing the OF links from a device_node,
  in order to tell whether or not one or more ports should be
  ignored. A callback is added for this purpose.

- Driver's probe must be run first.

- Probably default to parsing all.

- There may be other than 1:1 relations between device nodes and
  sub-devices (for device node which is related to a sub-device). In ADV7482
  case the driver could well instantiate several sub-devices for a single
  device node.

- Instead of registering sub-devices with the async framework, async
  slave concept should be used to replace async sub-devices.

- An async slave is registered for each device's device
  node by the driver in its probe() function.

- Matching can be done using either the device or port node.

- Using the port node does have the benefit of making it
  possible to have a single list of nodes to match against.

- Sub-device registration to the media device can be postponed until the full
  graph is parsed. There may be other benefits from this. Once all
  sub-devices have been registered, the media device is finally registered.

- The sub-devices can be registered to the media device only when
  the media device itself is registered.

As there will be V4L2 async API changes to the existing API, this should be
tried first with one driver before converting more drivers.


References
--

[1] http://www.retiisi.org.uk/v4l2/tmp/adv7482.txt

[2] http://www.retiisi.org.uk/v4l2/tmp/imx6.txt

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-10-31 Thread Sakari Ailus

Hi Pavel,

(Cc Laurent.)

On Sun, Oct 23, 2016 at 10:40:01PM +0200, Pavel Machek wrote:
> Hi!
> 
> > Thanks, this answered half of my questions already. ;-)
> > 
> > Do all the modes work for you currently btw.?
> 
> Aha, went through my notes. This is what it does in 5MP mode, even on
> v4.9:
> 
> pavel@n900:/my/fcam-dev$ ./camera.py
> ['-r']
> ['-l', '"et8ek8 3-003e":0 -> "video-bus-switch":1 [1]']
> ['-l', '"video-bus-switch":0 -> "OMAP3 ISP CCP2":0 [1]']
> ['-l', '"OMAP3 ISP CCP2":1 -> "OMAP3 ISP CCDC":0 [1]']
> ['-l', '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]']
> ['-V', '"et8ek8 3-003e":0 [SGRBG10 2592x1968]']
> ['-V', '"OMAP3 ISP CCP2":0 [SGRBG10 2592x1968]']
> ['-V', '"OMAP3 ISP CCP2":1 [SGRBG10 2592x1968]']
> ['-V', '"OMAP3 ISP CCDC":1 [SGRBG10 2592x1968]']
> ['-V', '"OMAP3 ISP CCDC":2 [SGRBG10 2592x1968]']
> Device /dev/video2 opened.
> Device `OMAP3 ISP CCDC output' on `media' is a video capture (without
> mplanes) device.
> Video format set: SGRBG10 (30314142) 2592x1968 (stride 5184) field
> none buffer size 10202112
> Video format: SGRBG10 (30314142) 2592x1968 (stride 5184) field none
> buffer size 10202112
> 4 buffers requested.
> length: 10202112 offset: 0 timestamp type/source: mono/EoF
> Buffer 0/0 mapped at address 0xb63a.
> length: 10202112 offset: 10203136 timestamp type/source: mono/EoF
> Buffer 1/0 mapped at address 0xb59e5000.
> length: 10202112 offset: 20406272 timestamp type/source: mono/EoF
> Buffer 2/0 mapped at address 0xb502a000.
> length: 10202112 offset: 30609408 timestamp type/source: mono/EoF
> Buffer 3/0 mapped at address 0xb466f000.
> 0 (0) [E] any 0 10202112 B 0.00 2792.366987 0.001 fps ts mono/EoF
> Unable to queue buffer: Input/output error (5).
> Unable to requeue buffer: Input/output error (5).
> Unable to release buffers: Device or resource busy (16).
> pavel@n900:/my/fcam-dev$
> 
> (gitlab.com fcam-dev branch good)
> 
> Kernel will say
> 
> [ 2689.598358] stream on success
> [ 2702.426635] Streamon
> [ 2702.426727] check_format checking px 808534338 808534338, h 984
> 984, w 1296 1296, bpline 2592 2592, size 2550528 2550528 field 1 1
> [ 2702.426818] configuring for 1296(2592)x984
> [ 2702.434722] stream on success
> [ 2792.276184] Streamon
> [ 2792.276306] check_format checking px 808534338 808534338, h 1968
> 1968, w 2592 2592, bpline 5184 5184, size 10202112 10202112 field 1 1
> [ 2792.276367] configuring for 2592(5184)x1968
> [ 2792.284240] stream on success
> [ 2792.368164] omap3isp 480bc000.isp: CCDC won't become idle!

This is Bad(tm).

It means that the driver waited for the CCDC to become idle to reprogram it,
but it didn't happen. This could be a problem in the number of lines
configured, or some polarity settings between the CCP2 receiver and the
CCDC. I suspect the latter, but I could be totally wrong here as well since
it was more than five years I worked on these things. :-I

> [ 2793.901550] omap3isp 480bc000.isp: Unable to stop OMAP3 ISP CCDC

And this is probably directly caused by the same problem. :-(

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

2016-10-31 Thread Sakari Ailus

Hi Pavel,

On Sun, Oct 23, 2016 at 10:33:15PM +0200, Pavel Machek wrote:
> Hi!
> 
> > Thanks, this answered half of my questions already. ;-)
> 
> :-).
> 
> I'll have to go through the patches, et8ek8 driver is probably not
> enough to get useful video. platform/video-bus-switch.c is needed for
> camera switching, then some omap3isp patches to bind flash and
> autofocus into the subdevice.
> 
> Then, device tree support on n900 can be added.

I briefly discussed with with Sebastian.

Do you think the elusive support for the secondary camera is worth keeping
out the main camera from the DT in mainline? As long as there's a reasonable
way to get it working, I'd just merge that. If someone ever gets the
secondary camera working properly and nicely with the video bus switch,
that's cool, we'll somehow deal with the problem then. But frankly I don't
think it's very useful even if we get there: the quality is really bad.

> > Do all the modes work for you currently btw.?
> 
> I don't think I got 5MP mode to work. Even 2.5MP mode is tricky (needs
> a lot of continuous memory).

The OMAP 3 ISP has got an MMU, getting some contiguous memory is not really
a problem when you have a 4 GiB empty space to use.

> Anyway, I have to start somewhere, and I believe this is a good
> starting place; I'd like to get the code cleaned up and merged, then
> move to the next parts.

I wonder if something else could be the problem. I think the data rate is
higher in the 5 MP mode, and that might be the reason. I don't remember how
similar is the clock tree in the 3430 to the 3630. Could it be that the ISP
clock is lower than it should be for some reason, for instance?

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] media: et8ek8: add device tree binding documentation

2016-10-31 Thread Sakari Ailus

Hi Rob and Pavel,

On Sun, Oct 30, 2016 at 03:41:34PM -0500, Rob Herring wrote:
> On Sun, Oct 23, 2016 at 09:17:06PM +0200, Pavel Machek wrote:
> > 
> > Add device tree binding documentation for toshiba et8ek8 sensor.
> > 
> > Signed-off-by: Ivaylo Dimitrov 
> > Signed-off-by: Pavel Machek 
> > 
> > ---
> > 
> > diff from v3: explain what clock-frequency means
> > 
> > 
> > diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt 
> > b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
> > new file mode 100644
> > index 000..54863cf
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
> > @@ -0,0 +1,51 @@
> > +Toshiba et8ek8 5MP sensor
> > +
> > +Toshiba et8ek8 5MP sensor is an image sensor found in Nokia N900 device
> > +
> > +More detailed documentation can be found in
> > +Documentation/devicetree/bindings/media/video-interfaces.txt .
> > +
> > +
> > +Mandatory properties
> > +
> > +
> > +- compatible: "toshiba,et8ek8"
> > +- reg: I2C address (0x3e, or an alternative address)
> > +- vana-supply: Analogue voltage supply (VANA), 2.8 volts
> > +- clocks: External clock to the sensor
> > +- clock-frequency: Frequency of the external clock to the sensor. Camera
> > +  driver will set this frequency on the external clock.
> 
> This is fine if the frequency is fixed (e.g. an oscillator), but you 
> should use the clock binding if clocks are programable.

We've discussed the matter here (v3):





Pavel, could you add to the desciption e.g.:

"The clock frequency is a pre-determined frequency known to be suitable to
the board."

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/9] [media] redrat3: enable carrier reports using wideband receiver

2016-10-31 Thread Sean Young

The wideband receiver is a little awkward on the redrat3. Data arrives
on a different endpoint, and the learning command must be reissued
every time data is learned.

Signed-off-by: Sean Young 
---
 drivers/media/rc/redrat3.c | 186 ++---
 1 file changed, 140 insertions(+), 46 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index eaf374d..1882712 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -81,6 +81,8 @@
 #define RR3_RC_DET_ENABLE  0xbb
 /* Stop capture with the RC receiver */
 #define RR3_RC_DET_DISABLE 0xbc
+/* Start capture with the wideband receiver */
+#define RR3_MODSIG_CAPTURE 0xb2
 /* Return the status of RC detector capture */
 #define RR3_RC_DET_STATUS  0xbd
 /* Reset redrat */
@@ -105,8 +107,10 @@
 #define RR3_CLK_PER_COUNT  12
 /* (RR3_CLK / RR3_CLK_PER_COUNT) */
 #define RR3_CLK_CONV_FACTOR200
-/* USB bulk-in IR data endpoint address */
-#define RR3_BULK_IN_EP_ADDR0x82
+/* USB bulk-in wideband IR data endpoint address */
+#define RR3_WIDE_IN_EP_ADDR0x81
+/* USB bulk-in narrowband IR data endpoint address */
+#define RR3_NARROW_IN_EP_ADDR  0x82
 
 /* Size of the fixed-length portion of the signal */
 #define RR3_DRIVER_MAXLENS 128
@@ -207,15 +211,22 @@ struct redrat3_dev {
struct urb *flash_urb;
u8 flash_in_buf;
 
+   /* learning */
+   bool wideband;
+   struct usb_ctrlrequest learn_control;
+   struct urb *learn_urb;
+   u8 learn_buf;
+
/* save off the usb device pointer */
struct usb_device *udev;
 
/* the receive endpoint */
-   struct usb_endpoint_descriptor *ep_in;
+   struct usb_endpoint_descriptor *ep_narrow;
/* the buffer to receive data */
void *bulk_in_buf;
/* urb used to read ir data */
-   struct urb *read_urb;
+   struct urb *narrow_urb;
+   struct urb *wide_urb;
 
/* the send endpoint */
struct usb_endpoint_descriptor *ep_out;
@@ -236,23 +247,6 @@ struct redrat3_dev {
char phys[64];
 };
 
-/*
- * redrat3_issue_async
- *
- *  Issues an async read to the ir data in port..
- *  sets the callback to be redrat3_handle_async
- */
-static void redrat3_issue_async(struct redrat3_dev *rr3)
-{
-   int res;
-
-   res = usb_submit_urb(rr3->read_urb, GFP_ATOMIC);
-   if (res)
-   dev_dbg(rr3->dev,
-   "%s: receive request FAILED! (res %d, len %d)\n",
-   __func__, res, rr3->read_urb->transfer_buffer_length);
-}
-
 static void redrat3_dump_fw_error(struct redrat3_dev *rr3, int code)
 {
if (!rr3->transmitting && (code != 0x40))
@@ -367,6 +361,14 @@ static void redrat3_process_ir_data(struct redrat3_dev 
*rr3)
 
mod_freq = redrat3_val_to_mod_freq(>irdata);
dev_dbg(dev, "Got mod_freq of %u\n", mod_freq);
+   if (mod_freq && rr3->wideband) {
+   DEFINE_IR_RAW_EVENT(ev);
+
+   ev.carrier_report = 1;
+   ev.carrier = mod_freq;
+
+   ir_raw_event_store(rr3->rc, );
+   }
 
/* process each rr3 encoded byte into an int */
sig_size = be16_to_cpu(rr3->irdata.sig_size);
@@ -449,19 +451,31 @@ static int redrat3_enable_detector(struct redrat3_dev 
*rr3)
return -EIO;
}
 
-   redrat3_issue_async(rr3);
+   ret = usb_submit_urb(rr3->narrow_urb, GFP_KERNEL);
+   if (ret) {
+   dev_err(rr3->dev, "narrow band urb failed: %d", ret);
+   return ret;
+   }
 
-   return 0;
+   ret = usb_submit_urb(rr3->wide_urb, GFP_KERNEL);
+   if (ret)
+   dev_err(rr3->dev, "wide band urb failed: %d", ret);
+
+   return ret;
 }
 
 static inline void redrat3_delete(struct redrat3_dev *rr3,
  struct usb_device *udev)
 {
-   usb_kill_urb(rr3->read_urb);
+   usb_kill_urb(rr3->narrow_urb);
+   usb_kill_urb(rr3->wide_urb);
usb_kill_urb(rr3->flash_urb);
-   usb_free_urb(rr3->read_urb);
+   usb_kill_urb(rr3->learn_urb);
+   usb_free_urb(rr3->narrow_urb);
+   usb_free_urb(rr3->wide_urb);
usb_free_urb(rr3->flash_urb);
-   usb_free_coherent(udev, le16_to_cpu(rr3->ep_in->wMaxPacketSize),
+   usb_free_urb(rr3->learn_urb);
+   usb_free_coherent(udev, le16_to_cpu(rr3->ep_narrow->wMaxPacketSize),
  rr3->bulk_in_buf, rr3->dma_in);
 
kfree(rr3);
@@ -694,9 +708,19 @@ static void redrat3_handle_async(struct urb *urb)
switch (urb->status) {
case 0:
ret = redrat3_get_ir_data(rr3, urb->actual_length);
+   if (!ret && rr3->wideband && !rr3->learn_urb->hcpriv) {
+   ret = usb_submit_urb(rr3->learn_urb, GFP_ATOMIC);
+   if (ret)
+   dev_err(rr3->dev, "Failed to submit learning 
urb: %d",
+

Re: [PATCH 14/82] media: usb: uvc: make use of new usb_endpoint_maxp_mult()

2016-10-31 Thread Laurent Pinchart

Hi Felipe,

Thank you for the patch.

On Monday 31 Oct 2016 12:48:06 Felipe Balbi wrote:
> We have introduced a helper to calculate multiplier
> value from wMaxPacketSize. Start using it.
> 
> Cc: Laurent Pinchart 
> Cc: Mauro Carvalho Chehab 
> Cc: 
> Signed-off-by: Felipe Balbi 

Acked-by: Laurent Pinchart 

> ---
>  drivers/media/usb/uvc/uvc_video.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c index b5589d5f5da4..11e0e5f4e1c2 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -1467,6 +1467,7 @@ static unsigned int uvc_endpoint_max_bpi(struct
> usb_device *dev, struct usb_host_endpoint *ep)
>  {
>   u16 psize;
> + u16 mult;
> 
>   switch (dev->speed) {
>   case USB_SPEED_SUPER:
> @@ -1474,7 +1475,8 @@ static unsigned int uvc_endpoint_max_bpi(struct
> usb_device *dev, return le16_to_cpu(ep->ss_ep_comp.wBytesPerInterval);
>   case USB_SPEED_HIGH:
>   psize = usb_endpoint_maxp(>desc);
> - return (psize & 0x07ff) * (1 + ((psize >> 11) & 3));
> + mult = usb_endpoint_maxp_mult(>desc);
> + return (psize & 0x07ff) * mult;
>   case USB_SPEED_WIRELESS:
>   psize = usb_endpoint_maxp(>desc);
>   return psize;

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 2/2] mm: remove get_user_pages_locked()

2016-10-31 Thread Lorenzo Stoakes

On Mon, Oct 31, 2016 at 06:55:33PM +0100, Paolo Bonzini wrote:
> > 2. There is currently only one caller of get_user_pages_locked() in
> >mm/frame_vector.c which seems to suggest this function isn't widely
> >used/known.
>
> Or not widely necessary. :)

Well, quite :)
>
> > 3. This change results in all slow-path get_user_pages*() functions having 
> > the
> >ability to use VM_FAULT_RETRY logic rather than 'defaulting' to using
> >get_user_pages() that doesn't let you do this even if you wanted to.
>
> This is only true if someone does the work though.  From a quick look
> at your series, the following files can be trivially changed to use
> get_user_pages_unlocked:
>
> - drivers/gpu/drm/via/via_dmablit.c
> - drivers/platform/goldfish/goldfish_pipe.c
> - drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> - drivers/rapidio/devices/rio_mport_cdev.c
> - drivers/virt/fsl_hypervisor.c
>

Ah indeed, I rather glossed through the callers and noticed that at least some
held locks long enough or were called with a lock held sufficient that I wasn't
sure it could be released.

> Also, videobuf_dma_init_user could be changed to use retry by adding a
> *locked argument to videobuf_dma_init_user_locked, prototype patch
> after my signature.
>

Very nice!

> Everything else is probably best kept using get_user_pages.
>
> > 4. It's somewhat confusing/redundant having both get_user_pages_locked() and
> >get_user_pages() functions which both require mmap_sem to be held (i.e. 
> > both
> >are 'locked' versions.)
> >
> >> If all callers were changed, then sure removing the _locked suffix would
> >> be a good idea.
> >
> > It seems many callers cannot release mmap_sem so VM_FAULT_RETRY logic 
> > couldn't
> > happen anyway in this cases and in these cases we couldn't change the 
> > caller.
>
> But then get_user_pages_locked remains a less-common case, so perhaps
> it's a good thing to give it a longer name!

My (somewhat minor) concern was that there would be confusion due to the
existence of the triumvirate of g_u_p()/g_u_p_unlocked()/g_u_p_locked(), however
the comments do a decent enough job of explaining the situation.

>
> > Overall, an alternative here might be to remove get_user_pages() and update
> > get_user_pages_locked() to add a 'vmas' parameter, however doing this 
> > renders
> > get_user_pages_unlocked() asymmetric as it would lack an vmas parameter 
> > (adding
> > one there would make no sense as VM_FAULT_RETRY logic invalidates VMAs) 
> > though
> > perhaps not such a big issue as it makes sense as to why this is the case.
>
> Adding the 'vmas' parameter to get_user_pages_locked would make little
> sense.  Since VM_FAULT_RETRY invalidates it and g_u_p_locked can and
> does retry, it would generally not be useful.

I meant only in the case where we'd remove get_user_pages() and instead be left
with get_user_pages_[un]locked() only, meaning we'd have to add some means of
retrieving vmas if locked was set NULL, of course in cases where locked is not
NULL it makes no sense to add it.

>
> So I think we have the right API now:
>
> - do not have lock?  Use get_user_pages_unlocked, get retry for free,
> no need to handle  mmap_sem and the locked argument; cannot get back vmas.
>
> - have and cannot drop lock?  User get_user_pages, no need to pass NULL
> for the locked argument; can get back vmas.
>
> - have but can drop lock (rare case)?  Use get_user_pages_locked,
> cannot get back vams.

Yeah I think this is sane as it is actually, this patch set was a lot less
convincing of a cleanup than prior ones and overall it seems we are better off
with the existing API.

I wonder whether a better patch series to come out of this would be to find
cases where the lock could be dropped (i.e. the ones you mention above) and to
switch to using get_user_pages_[un]locked() where it makes sense to.

I am happy to look into these cases (though of course I must leave your
suggested patch here to you :)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/9] [media] redrat3: enable carrier reports using wideband receiver

2016-10-31 Thread kbuild test robot

Hi Sean,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on next-20161028]
[cannot apply to v4.9-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Sean-Young/Various-IR-fixes/20161101-023658
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-x014-201644 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/media/rc/redrat3.c: In function 'redrat3_learn_complete':
>> drivers/media/rc/redrat3.c:903:6: warning: unused variable 'ret' 
>> [-Wunused-variable]
 int ret;
 ^~~

vim +/ret +903 drivers/media/rc/redrat3.c

   887  
   888  rr3->wideband = enable != 0;
   889  
   890  if (enable) {
   891  ret = usb_submit_urb(rr3->learn_urb, GFP_KERNEL);
   892  if (ret)
   893  dev_err(rr3->dev, "Failed to submit learning 
urb: %d",
   894  
ret);
   895  }
   896  
   897  return ret;
   898  }
   899  
   900  static void redrat3_learn_complete(struct urb *urb)
   901  {
   902  struct redrat3_dev *rr3 = urb->context;
 > 903  int ret;
   904  
   905  switch (urb->status) {
   906  case 0:
   907  break;
   908  case -ECONNRESET:
   909  case -ENOENT:
   910  case -ESHUTDOWN:
   911  usb_unlink_urb(urb);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/2] mm: remove get_user_pages_locked()

2016-10-31 Thread Paolo Bonzini



On 31/10/2016 14:48, Lorenzo Stoakes wrote:
> On Mon, Oct 31, 2016 at 12:45:36PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 31/10/2016 11:02, Lorenzo Stoakes wrote:
>>> - *
>>> - * get_user_pages should be phased out in favor of
>>> - * get_user_pages_locked|unlocked or get_user_pages_fast. Nothing
>>> - * should use get_user_pages because it cannot pass
>>> - * FAULT_FLAG_ALLOW_RETRY to handle_mm_fault.
>>
>> This comment should be preserved in some way.  In addition, removing
> 
> Could you clarify what you think should be retained?
> 
> The comment seems to me to be largely rendered redundant by this change -
> get_user_pages() now offers identical behaviour, and of course the latter part
> of the comment ('because it cannot pass FAULT_FLAG_ALLOW_RETRY') is rendered
> incorrect by this change.
> 
> It could be replaced with a recommendation to make use of VM_FAULT_RETRY logic
> if possible.

Yes, exactly.  locked == NULL should be avoided whenever mmap_sem can 
be dropped, and the comment indirectly said so.  Now most of those cases
actually are those where you can just call get_user_pages_unlocked.

>> get_user_pages_locked() makes it harder (compared to a simple "git grep
>> -w") to identify callers that lack allow-retry functionality).  So I'm
>> not sure about the benefits of these patches.
> 
> That's a fair point, and certainly this cleanup series is less obviously 
> helpful
> than previous ones.
> 
> However, there are a few points in its favour:
> 
> 1. get_user_pages_remote() was the mirror of get_user_pages() prior to adding 
> an
>int *locked parameter to the former (necessary to allow for the unexport of
>__get_user_pages_unlocked()), differing only in task/mm being specified and
>FOLL_REMOTE being set. This patch series keeps these functions 
> 'synchronised'
>in this respect.
> 
> 2. There is currently only one caller of get_user_pages_locked() in
>mm/frame_vector.c which seems to suggest this function isn't widely
>used/known.

Or not widely necessary. :)

> 3. This change results in all slow-path get_user_pages*() functions having the
>ability to use VM_FAULT_RETRY logic rather than 'defaulting' to using
>get_user_pages() that doesn't let you do this even if you wanted to.

This is only true if someone does the work though.  From a quick look 
at your series, the following files can be trivially changed to use 
get_user_pages_unlocked:

- drivers/gpu/drm/via/via_dmablit.c
- drivers/platform/goldfish/goldfish_pipe.c
- drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
- drivers/rapidio/devices/rio_mport_cdev.c
- drivers/virt/fsl_hypervisor.c

Also, videobuf_dma_init_user could be changed to use retry by adding a 
*locked argument to videobuf_dma_init_user_locked, prototype patch 
after my signature.

Everything else is probably best kept using get_user_pages.

> 4. It's somewhat confusing/redundant having both get_user_pages_locked() and
>get_user_pages() functions which both require mmap_sem to be held (i.e. 
> both
>are 'locked' versions.)
> 
>> If all callers were changed, then sure removing the _locked suffix would
>> be a good idea.
> 
> It seems many callers cannot release mmap_sem so VM_FAULT_RETRY logic couldn't
> happen anyway in this cases and in these cases we couldn't change the caller.

But then get_user_pages_locked remains a less-common case, so perhaps 
it's a good thing to give it a longer name!

> Overall, an alternative here might be to remove get_user_pages() and update
> get_user_pages_locked() to add a 'vmas' parameter, however doing this renders
> get_user_pages_unlocked() asymmetric as it would lack an vmas parameter 
> (adding
> one there would make no sense as VM_FAULT_RETRY logic invalidates VMAs) though
> perhaps not such a big issue as it makes sense as to why this is the case.

Adding the 'vmas' parameter to get_user_pages_locked would make little 
sense.  Since VM_FAULT_RETRY invalidates it and g_u_p_locked can and 
does retry, it would generally not be useful.

So I think we have the right API now:

- do not have lock?  Use get_user_pages_unlocked, get retry for free,
no need to handle  mmap_sem and the locked argument; cannot get back vmas.

- have and cannot drop lock?  User get_user_pages, no need to pass NULL 
for the locked argument; can get back vmas.

- have but can drop lock (rare case)?  Use get_user_pages_locked, 
cannot get back vams.

Paolo

> get_user_pages_unlocked() definitely seems to be a useful helper and therefore
> makes sense to retain.

> Of course another alternative is to leave things be :)
> 

diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c 
b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 1db0af6c7f94..dae4eb8e9d5b 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -152,7 +152,8 @@ static void videobuf_dma_init(struct videobuf_dmabuf *dma)
 }
 
 static int videobuf_dma_init_user_locked(struct videobuf_dmabuf *dma,
-

[PATCH 5/9] [media] redrat3: enable carrier reports using wideband receiver

2016-10-31 Thread Sean Young

The wideband receiver is a little awkward on the redrat3. Data arrives
on a different endpoint, and the learning command must be reissued
every time data is learned.

Signed-off-by: Sean Young 
---
 drivers/media/rc/redrat3.c | 184 ++---
 1 file changed, 140 insertions(+), 44 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index eaf374d..4370d21 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -81,6 +81,8 @@
 #define RR3_RC_DET_ENABLE  0xbb
 /* Stop capture with the RC receiver */
 #define RR3_RC_DET_DISABLE 0xbc
+/* Start capture with the wideband receiver */
+#define RR3_MODSIG_CAPTURE 0xb2
 /* Return the status of RC detector capture */
 #define RR3_RC_DET_STATUS  0xbd
 /* Reset redrat */
@@ -105,8 +107,10 @@
 #define RR3_CLK_PER_COUNT  12
 /* (RR3_CLK / RR3_CLK_PER_COUNT) */
 #define RR3_CLK_CONV_FACTOR200
-/* USB bulk-in IR data endpoint address */
-#define RR3_BULK_IN_EP_ADDR0x82
+/* USB bulk-in wideband IR data endpoint address */
+#define RR3_WIDE_IN_EP_ADDR0x81
+/* USB bulk-in narrowband IR data endpoint address */
+#define RR3_NARROW_IN_EP_ADDR  0x82
 
 /* Size of the fixed-length portion of the signal */
 #define RR3_DRIVER_MAXLENS 128
@@ -207,15 +211,22 @@ struct redrat3_dev {
struct urb *flash_urb;
u8 flash_in_buf;
 
+   /* learning */
+   bool wideband;
+   struct usb_ctrlrequest learn_control;
+   struct urb *learn_urb;
+   u8 learn_buf;
+
/* save off the usb device pointer */
struct usb_device *udev;
 
/* the receive endpoint */
-   struct usb_endpoint_descriptor *ep_in;
+   struct usb_endpoint_descriptor *ep_narrow;
/* the buffer to receive data */
void *bulk_in_buf;
/* urb used to read ir data */
-   struct urb *read_urb;
+   struct urb *narrow_urb;
+   struct urb *wide_urb;
 
/* the send endpoint */
struct usb_endpoint_descriptor *ep_out;
@@ -236,23 +247,6 @@ struct redrat3_dev {
char phys[64];
 };
 
-/*
- * redrat3_issue_async
- *
- *  Issues an async read to the ir data in port..
- *  sets the callback to be redrat3_handle_async
- */
-static void redrat3_issue_async(struct redrat3_dev *rr3)
-{
-   int res;
-
-   res = usb_submit_urb(rr3->read_urb, GFP_ATOMIC);
-   if (res)
-   dev_dbg(rr3->dev,
-   "%s: receive request FAILED! (res %d, len %d)\n",
-   __func__, res, rr3->read_urb->transfer_buffer_length);
-}
-
 static void redrat3_dump_fw_error(struct redrat3_dev *rr3, int code)
 {
if (!rr3->transmitting && (code != 0x40))
@@ -367,6 +361,14 @@ static void redrat3_process_ir_data(struct redrat3_dev 
*rr3)
 
mod_freq = redrat3_val_to_mod_freq(>irdata);
dev_dbg(dev, "Got mod_freq of %u\n", mod_freq);
+   if (mod_freq && rr3->wideband) {
+   DEFINE_IR_RAW_EVENT(ev);
+
+   ev.carrier_report = 1;
+   ev.carrier = mod_freq;
+
+   ir_raw_event_store(rr3->rc, );
+   }
 
/* process each rr3 encoded byte into an int */
sig_size = be16_to_cpu(rr3->irdata.sig_size);
@@ -449,19 +451,31 @@ static int redrat3_enable_detector(struct redrat3_dev 
*rr3)
return -EIO;
}
 
-   redrat3_issue_async(rr3);
+   ret = usb_submit_urb(rr3->narrow_urb, GFP_KERNEL);
+   if (ret) {
+   dev_err(rr3->dev, "narrow band urb failed: %d", ret);
+   return ret;
+   }
 
-   return 0;
+   ret = usb_submit_urb(rr3->wide_urb, GFP_KERNEL);
+   if (ret)
+   dev_err(rr3->dev, "wide band urb failed: %d", ret);
+
+   return ret;
 }
 
 static inline void redrat3_delete(struct redrat3_dev *rr3,
  struct usb_device *udev)
 {
-   usb_kill_urb(rr3->read_urb);
+   usb_kill_urb(rr3->narrow_urb);
+   usb_kill_urb(rr3->wide_urb);
usb_kill_urb(rr3->flash_urb);
-   usb_free_urb(rr3->read_urb);
+   usb_kill_urb(rr3->learn_urb);
+   usb_free_urb(rr3->narrow_urb);
+   usb_free_urb(rr3->wide_urb);
usb_free_urb(rr3->flash_urb);
-   usb_free_coherent(udev, le16_to_cpu(rr3->ep_in->wMaxPacketSize),
+   usb_free_urb(rr3->learn_urb);
+   usb_free_coherent(udev, le16_to_cpu(rr3->ep_narrow->wMaxPacketSize),
  rr3->bulk_in_buf, rr3->dma_in);
 
kfree(rr3);
@@ -694,9 +708,19 @@ static void redrat3_handle_async(struct urb *urb)
switch (urb->status) {
case 0:
ret = redrat3_get_ir_data(rr3, urb->actual_length);
+   if (!ret && rr3->wideband && !rr3->learn_urb->hcpriv) {
+   ret = usb_submit_urb(rr3->learn_urb, GFP_ATOMIC);
+   if (ret)
+   dev_err(rr3->dev, "Failed to submit learning 
urb: %d",
+

[PATCH 9/9] [media] lirc: use-after free while reading from device and unplugging

2016-10-31 Thread Sean Young

Many lirc drivers have their own receive buffers which are freed on
unplug (e.g. ir_lirc_unregister). This means that ir->buf->wait_poll
will be freed directly after unplug so do not remove yourself from the
wait queue.

Signed-off-by: Sean Young 
---
 drivers/media/rc/lirc_dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 60fd106..b0c79a5 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -718,7 +718,7 @@ ssize_t lirc_dev_fop_read(struct file *file,
 
if (!ir->attached) {
ret = -ENODEV;
-   break;
+   goto out_locked;
}
} else {
lirc_buffer_read(ir->buf, buf);
-- 
2.7.4

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

[PATCH 4/9] [media] redrat3: fix error paths in probe

2016-10-31 Thread Sean Young

If redrat3_delete() is called, ensure ep_in and udev members are set
up so we don't dereference null in the error path. Also ensure that
rc dev device exists before we enable the receiver and that the
led urb exists before we create the led device.

Signed-off-by: Sean Young 
---
 drivers/media/rc/redrat3.c | 49 ++
 1 file changed, 23 insertions(+), 26 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 23180ec..eaf374d 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -982,17 +982,19 @@ static int redrat3_dev_probe(struct usb_interface *intf,
goto no_endpoints;
 
rr3->dev = >dev;
+   rr3->ep_in = ep_in;
+   rr3->ep_out = ep_out;
+   rr3->udev = udev;
 
/* set up bulk-in endpoint */
rr3->read_urb = usb_alloc_urb(0, GFP_KERNEL);
if (!rr3->read_urb)
-   goto error;
+   goto redrat_free;
 
-   rr3->ep_in = ep_in;
rr3->bulk_in_buf = usb_alloc_coherent(udev,
le16_to_cpu(ep_in->wMaxPacketSize), GFP_KERNEL, >dma_in);
if (!rr3->bulk_in_buf)
-   goto error;
+   goto redrat_free;
 
pipe = usb_rcvbulkpipe(udev, ep_in->bEndpointAddress);
usb_fill_bulk_urb(rr3->read_urb, udev, pipe, rr3->bulk_in_buf,
@@ -1000,34 +1002,16 @@ static int redrat3_dev_probe(struct usb_interface *intf,
rr3->read_urb->transfer_dma = rr3->dma_in;
rr3->read_urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
 
-   rr3->ep_out = ep_out;
-   rr3->udev = udev;
-
redrat3_reset(rr3);
redrat3_get_firmware_rev(rr3);
 
-   /* might be all we need to do? */
-   retval = redrat3_enable_detector(rr3);
-   if (retval < 0)
-   goto error;
-
/* default.. will get overridden by any sends with a freq defined */
rr3->carrier = 38000;
 
-   /* led control */
-   rr3->led.name = "redrat3:red:feedback";
-   rr3->led.default_trigger = "rc-feedback";
-   rr3->led.brightness_set = redrat3_brightness_set;
-   retval = led_classdev_register(>dev, >led);
-   if (retval)
-   goto error;
-
atomic_set(>flash, 0);
rr3->flash_urb = usb_alloc_urb(0, GFP_KERNEL);
-   if (!rr3->flash_urb) {
-   retval = -ENOMEM;
-   goto led_free_error;
-   }
+   if (!rr3->flash_urb)
+   goto redrat_free;
 
/* setup packet is 'c0 b9   0001' */
rr3->flash_control.bRequestType = 0xc0;
@@ -1039,20 +1023,33 @@ static int redrat3_dev_probe(struct usb_interface *intf,
>flash_in_buf, sizeof(rr3->flash_in_buf),
redrat3_led_complete, rr3);
 
+   /* led control */
+   rr3->led.name = "redrat3:red:feedback";
+   rr3->led.default_trigger = "rc-feedback";
+   rr3->led.brightness_set = redrat3_brightness_set;
+   retval = led_classdev_register(>dev, >led);
+   if (retval)
+   goto redrat_free;
+
rr3->rc = redrat3_init_rc_dev(rr3);
if (!rr3->rc) {
retval = -ENOMEM;
-   goto led_free_error;
+   goto led_free;
}
 
+   /* might be all we need to do? */
+   retval = redrat3_enable_detector(rr3);
+   if (retval < 0)
+   goto led_free;
+
/* we can register the device now, as it is ready */
usb_set_intfdata(intf, rr3);
 
return 0;
 
-led_free_error:
+led_free:
led_classdev_unregister(>led);
-error:
+redrat_free:
redrat3_delete(rr3, rr3->udev);
 
 no_endpoints:
-- 
2.7.4

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

[PATCH 3/9] [media] redrat3: remove dead code and pointless messages

2016-10-31 Thread Sean Young

No need to log kmalloc failures.

Signed-off-by: Sean Young 
---
 drivers/media/rc/redrat3.c | 42 ++
 1 file changed, 6 insertions(+), 36 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index de40e58..23180ec 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -363,11 +363,6 @@ static void redrat3_process_ir_data(struct redrat3_dev 
*rr3)
unsigned int i, sig_size, single_len, offset, val;
u32 mod_freq;
 
-   if (!rr3) {
-   pr_err("%s called with no context!\n", __func__);
-   return;
-   }
-
dev = rr3->dev;
 
mod_freq = redrat3_val_to_mod_freq(>irdata);
@@ -480,10 +475,8 @@ static u32 redrat3_get_timeout(struct redrat3_dev *rr3)
 
len = sizeof(*tmp);
tmp = kzalloc(len, GFP_KERNEL);
-   if (!tmp) {
-   dev_warn(rr3->dev, "Memory allocation faillure\n");
+   if (!tmp)
return timeout;
-   }
 
pipe = usb_rcvctrlpipe(rr3->udev, 0);
ret = usb_control_msg(rr3->udev, pipe, RR3_GET_IR_PARAM,
@@ -544,10 +537,8 @@ static void redrat3_reset(struct redrat3_dev *rr3)
txpipe = usb_sndctrlpipe(udev, 0);
 
val = kmalloc(len, GFP_KERNEL);
-   if (!val) {
-   dev_err(dev, "Memory allocation failure\n");
+   if (!val)
return;
-   }
 
*val = 0x01;
rc = usb_control_msg(udev, rxpipe, RR3_RESET,
@@ -589,10 +580,8 @@ static void redrat3_get_firmware_rev(struct redrat3_dev 
*rr3)
char *buffer;
 
buffer = kzalloc(sizeof(char) * (RR3_FW_VERSION_LEN + 1), GFP_KERNEL);
-   if (!buffer) {
-   dev_err(rr3->dev, "Memory allocation failure\n");
+   if (!buffer)
return;
-   }
 
rc = usb_control_msg(rr3->udev, usb_rcvctrlpipe(rr3->udev, 0),
 RR3_FW_VERSION,
@@ -699,19 +688,9 @@ static int redrat3_get_ir_data(struct redrat3_dev *rr3, 
unsigned len)
 /* callback function from USB when async USB request has completed */
 static void redrat3_handle_async(struct urb *urb)
 {
-   struct redrat3_dev *rr3;
+   struct redrat3_dev *rr3 = urb->context;
int ret;
 
-   if (!urb)
-   return;
-
-   rr3 = urb->context;
-   if (!rr3) {
-   pr_err("%s called with invalid context!\n", __func__);
-   usb_unlink_urb(urb);
-   return;
-   }
-
switch (urb->status) {
case 0:
ret = redrat3_get_ir_data(rr3, urb->actual_length);
@@ -999,10 +978,8 @@ static int redrat3_dev_probe(struct usb_interface *intf,
 
/* allocate memory for our device state and initialize it */
rr3 = kzalloc(sizeof(*rr3), GFP_KERNEL);
-   if (rr3 == NULL) {
-   dev_err(dev, "Memory allocation failure\n");
+   if (rr3 == NULL)
goto no_endpoints;
-   }
 
rr3->dev = >dev;
 
@@ -1014,10 +991,8 @@ static int redrat3_dev_probe(struct usb_interface *intf,
rr3->ep_in = ep_in;
rr3->bulk_in_buf = usb_alloc_coherent(udev,
le16_to_cpu(ep_in->wMaxPacketSize), GFP_KERNEL, >dma_in);
-   if (!rr3->bulk_in_buf) {
-   dev_err(dev, "Read buffer allocation failure\n");
+   if (!rr3->bulk_in_buf)
goto error;
-   }
 
pipe = usb_rcvbulkpipe(udev, ep_in->bEndpointAddress);
usb_fill_bulk_urb(rr3->read_urb, udev, pipe, rr3->bulk_in_buf,
@@ -1081,8 +1056,6 @@ static int redrat3_dev_probe(struct usb_interface *intf,
redrat3_delete(rr3, rr3->udev);
 
 no_endpoints:
-   dev_err(dev, "%s: retval = %x", __func__, retval);
-
return retval;
 }
 
@@ -1091,9 +1064,6 @@ static void redrat3_dev_disconnect(struct usb_interface 
*intf)
struct usb_device *udev = interface_to_usbdev(intf);
struct redrat3_dev *rr3 = usb_get_intfdata(intf);
 
-   if (!rr3)
-   return;
-
usb_set_intfdata(intf, NULL);
rc_unregister_device(rr3->rc);
led_classdev_unregister(>led);
-- 
2.7.4

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

[PATCH 1/9] [media] winbond-cir: use name without space for pnp driver

2016-10-31 Thread Sean Young

Rename the pnp driver in sysfs from /sys/bus/pnp/drivers/Winbond CIR
to /sys/bus/pnp/drivers/winbond-cir

Signed-off-by: Sean Young 
---
 drivers/media/rc/winbond-cir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index cdcd6e3..1ccb6bb 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1185,7 +1185,7 @@ static const struct pnp_device_id wbcir_ids[] = {
 MODULE_DEVICE_TABLE(pnp, wbcir_ids);
 
 static struct pnp_driver wbcir_driver = {
-   .name = WBCIR_NAME,
+   .name = DRVNAME,
.id_table = wbcir_ids,
.probe= wbcir_probe,
.remove   = wbcir_remove,
-- 
2.7.4

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

[PATCH 6/9] [media] redrat3: increase set size for lengths to maximum

2016-10-31 Thread Sean Young

In learning mode, you can get much longer messages which can run out
of lengths. The usb message will slightly larger.

Signed-off-by: Sean Young 
---
 drivers/media/rc/redrat3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 4370d21..12e299f 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -113,7 +113,7 @@
 #define RR3_NARROW_IN_EP_ADDR  0x82
 
 /* Size of the fixed-length portion of the signal */
-#define RR3_DRIVER_MAXLENS 128
+#define RR3_DRIVER_MAXLENS 255
 #define RR3_MAX_SIG_SIZE   512
 #define RR3_TIME_UNIT  50
 #define RR3_END_OF_SIGNAL  0x7f
-- 
2.7.4

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

[PATCH 7/9] [media] lirc: might sleep error in lirc_dev_fop_read

2016-10-31 Thread Sean Young

[  101.457944] [ cut here ]
[  101.457954] WARNING: CPU: 3 PID: 1819 at kernel/sched/core.c:7708 
__might_sleep+0x7e/0x80
[  101.457960] do not call blocking ops when !TASK_RUNNING; state=1 set at 
[] lirc_dev_fop_read+0x292/0x4e0 [lirc_dev]

Signed-off-by: Sean Young 
---
 drivers/media/rc/lirc_dev.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 91f9bb8..bf4309f 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -684,7 +684,6 @@ ssize_t lirc_dev_fop_read(struct file *file,
 * between while condition checking and scheduling)
 */
add_wait_queue(>buf->wait_poll, );
-   set_current_state(TASK_INTERRUPTIBLE);
 
/*
 * while we didn't provide 'length' bytes, device is opened in blocking
@@ -709,13 +708,13 @@ ssize_t lirc_dev_fop_read(struct file *file,
}
 
mutex_unlock(>irctl_lock);
-   schedule();
set_current_state(TASK_INTERRUPTIBLE);
+   schedule();
+   set_current_state(TASK_RUNNING);
 
if (mutex_lock_interruptible(>irctl_lock)) {
ret = -ERESTARTSYS;
remove_wait_queue(>buf->wait_poll, );
-   set_current_state(TASK_RUNNING);
goto out_unlocked;
}
 
@@ -735,7 +734,6 @@ ssize_t lirc_dev_fop_read(struct file *file,
}
 
remove_wait_queue(>buf->wait_poll, );
-   set_current_state(TASK_RUNNING);
 
 out_locked:
mutex_unlock(>irctl_lock);
-- 
2.7.4

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

[PATCH 8/9] [media] lirc: prevent use-after free

2016-10-31 Thread Sean Young

If you unplug an lirc device while reading from it, you will get an
use after free as the cdev is freed while still in use.

Signed-off-by: Sean Young 
---
 drivers/media/rc/lirc_dev.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index bf4309f..60fd106 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -164,15 +164,15 @@ static int lirc_cdev_add(struct irctl *ir)
struct lirc_driver *d = >d;
struct cdev *cdev;
 
-   cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
+   cdev = cdev_alloc();
if (!cdev)
goto err_out;
 
if (d->fops) {
-   cdev_init(cdev, d->fops);
+   cdev->ops = d->fops;
cdev->owner = d->owner;
} else {
-   cdev_init(cdev, _dev_fops);
+   cdev->ops = _dev_fops;
cdev->owner = THIS_MODULE;
}
retval = kobject_set_name(>kobj, "lirc%d", d->minor);
@@ -190,7 +190,7 @@ static int lirc_cdev_add(struct irctl *ir)
return 0;
 
 err_out:
-   kfree(cdev);
+   cdev_del(cdev);
return retval;
 }
 
@@ -420,7 +420,6 @@ int lirc_unregister_driver(int minor)
} else {
lirc_irctl_cleanup(ir);
cdev_del(cdev);
-   kfree(cdev);
kfree(ir);
irctls[minor] = NULL;
}
@@ -521,7 +520,6 @@ int lirc_dev_fop_close(struct inode *inode, struct file 
*file)
lirc_irctl_cleanup(ir);
cdev_del(cdev);
irctls[ir->d.minor] = NULL;
-   kfree(cdev);
kfree(ir);
}
 
-- 
2.7.4

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

[PATCH 0/9] Various IR fixes

2016-10-31 Thread Sean Young

Teach the redrat3 driver how to use the wideband receiver, also fix
some very nasty crashes if you disconnect a lirc device while
reading from it.

Sean Young (9):
  [media] winbond-cir: use name without space for pnp driver
  [media] redrat3: don't include vendor/product id in name
  [media] redrat3: remove dead code and pointless messages
  [media] redrat3: fix error paths in probe
  [media] redrat3: enable carrier reports using wideband receiver
  [media] redrat3: increase set size for lengths to maximum
  [media] lirc: might sleep error in lirc_dev_fop_read
  [media] lirc: prevent use-after free
  [media] lirc: use-after free while reading from device and unplugging

 drivers/media/rc/lirc_dev.c|  18 +--
 drivers/media/rc/redrat3.c | 283 +
 drivers/media/rc/winbond-cir.c |   2 +-
 3 files changed, 181 insertions(+), 122 deletions(-)

-- 
2.7.4

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

[PATCH 2/9] [media] redrat3: don't include vendor/product id in name

2016-10-31 Thread Sean Young

No need to duplicate these in the rc name.

Signed-off-by: Sean Young 
---
 drivers/media/rc/redrat3.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 3b0ed1c..de40e58 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -912,9 +912,9 @@ static struct rc_dev *redrat3_init_rc_dev(struct 
redrat3_dev *rr3)
goto out;
}
 
-   snprintf(rr3->name, sizeof(rr3->name), "RedRat3%s Infrared Remote 
Transceiver (%04x:%04x)",
-prod == USB_RR3IIUSB_PRODUCT_ID ? "-II" : "",
-le16_to_cpu(rr3->udev->descriptor.idVendor), prod);
+   snprintf(rr3->name, sizeof(rr3->name),
+"RedRat3%s Infrared Remote Transceiver",
+prod == USB_RR3IIUSB_PRODUCT_ID ? "-II" : "");
 
usb_make_path(rr3->udev, rr3->phys, sizeof(rr3->phys));
 
-- 
2.7.4

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

Re: [PATCH v2 5/7] [media] ir-lirc-codec: don't wait any transmitting time for tx only devices

2016-10-31 Thread Sean Young

Hi David, Andi,

On Mon, Oct 31, 2016 at 02:31:52PM +, David Härdeman wrote:
> October 27, 2016 4:36 PM, "Sean Young"  wrote:
> > Since we have to be able to switch between waiting and not waiting,
> > we need some sort of ABI for this. I think this warrants a new ioctl;
> > I'm not sure how else it can be done. I'll be sending out a patch
> > shortly.
> 
> Hi Sean,
> 
> have you considered using a module param for the LIRC bridge module instead? 
> As far as I understand it, this is an issue which is entirely internal to 
> LIRC, and it's also not something which really needs to be changed on a 
> per-device level (either you have a modern LIRC daemon or you don't, and all 
> drivers should behave the same, no?).

I still don't see how any of this would change anything for the ir-spi case:
since it uses sync spi transfer, it's going to block anyway.

> Another advantage is that the parameter would then go away if and when the 
> lirc bridge ever goes away (yes, I can still dream, can't I?).

The suggested ioctl is unique to lirc too and would disappear if the
lirc ABI goes away. With a module parameter you would change the lirc ABI
into an incompatible one. Not sure that is what module parameters should
be used for.

Andi, it would be good to know what the use-case for the original change is.


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

Re: [PATCH v2 5/7] [media] ir-lirc-codec: don't wait any transmitting time for tx only devices

2016-10-31 Thread David Härdeman

October 27, 2016 4:36 PM, "Sean Young"  wrote:
> Since we have to be able to switch between waiting and not waiting,
> we need some sort of ABI for this. I think this warrants a new ioctl;
> I'm not sure how else it can be done. I'll be sending out a patch
> shortly.

Hi Sean,

have you considered using a module param for the LIRC bridge module instead? As 
far as I understand it, this is an issue which is entirely internal to LIRC, 
and it's also not something which really needs to be changed on a per-device 
level (either you have a modern LIRC daemon or you don't, and all drivers 
should behave the same, no?).

Another advantage is that the parameter would then go away if and when the lirc 
bridge ever goes away (yes, I can still dream, can't I?).

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

Re: [PATCH 2/2] mm: remove get_user_pages_locked()

2016-10-31 Thread Lorenzo Stoakes

On Mon, Oct 31, 2016 at 12:45:36PM +0100, Paolo Bonzini wrote:
>
>
> On 31/10/2016 11:02, Lorenzo Stoakes wrote:
> > - *
> > - * get_user_pages should be phased out in favor of
> > - * get_user_pages_locked|unlocked or get_user_pages_fast. Nothing
> > - * should use get_user_pages because it cannot pass
> > - * FAULT_FLAG_ALLOW_RETRY to handle_mm_fault.
>
> This comment should be preserved in some way.  In addition, removing

Could you clarify what you think should be retained?

The comment seems to me to be largely rendered redundant by this change -
get_user_pages() now offers identical behaviour, and of course the latter part
of the comment ('because it cannot pass FAULT_FLAG_ALLOW_RETRY') is rendered
incorrect by this change.

It could be replaced with a recommendation to make use of VM_FAULT_RETRY logic
if possible. Note that the line above retains the reference to
'get_user_pages_fast()' - 'See also get_user_pages_fast, for performance
critical applications.'

One important thing to note here is this is a comment on get_user_pages_remote()
for which it was already incorrect syntactically (I'm guessing once
get_user_pages_remote() was added it 'stole' get_user_pages()'s comment :)

> get_user_pages_locked() makes it harder (compared to a simple "git grep
> -w") to identify callers that lack allow-retry functionality).  So I'm
> not sure about the benefits of these patches.
>

That's a fair point, and certainly this cleanup series is less obviously helpful
than previous ones.

However, there are a few points in its favour:

1. get_user_pages_remote() was the mirror of get_user_pages() prior to adding an
   int *locked parameter to the former (necessary to allow for the unexport of
   __get_user_pages_unlocked()), differing only in task/mm being specified and
   FOLL_REMOTE being set. This patch series keeps these functions 'synchronised'
   in this respect.

2. There is currently only one caller of get_user_pages_locked() in
   mm/frame_vector.c which seems to suggest this function isn't widely
   used/known.

3. This change results in all slow-path get_user_pages*() functions having the
   ability to use VM_FAULT_RETRY logic rather than 'defaulting' to using
   get_user_pages() that doesn't let you do this even if you wanted to.

4. It's somewhat confusing/redundant having both get_user_pages_locked() and
   get_user_pages() functions which both require mmap_sem to be held (i.e. both
   are 'locked' versions.)

> If all callers were changed, then sure removing the _locked suffix would
> be a good idea.

It seems many callers cannot release mmap_sem so VM_FAULT_RETRY logic couldn't
happen anyway in this cases and in these cases we couldn't change the caller.

Overall, an alternative here might be to remove get_user_pages() and update
get_user_pages_locked() to add a 'vmas' parameter, however doing this renders
get_user_pages_unlocked() asymmetric as it would lack an vmas parameter (adding
one there would make no sense as VM_FAULT_RETRY logic invalidates VMAs) though
perhaps not such a big issue as it makes sense as to why this is the case.

get_user_pages_unlocked() definitely seems to be a useful helper and therefore
makes sense to retain.

Of course another alternative is to leave things be :)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Problem with uvcvideo timestamps

2016-10-31 Thread Niels Möller

Hi,

I'm tracking down a problem in Chrome, where video streams captured
from a Logitech c930e camera get bogus timestamps. Chrome started
using camera timestamps on linux a few months ago. I've noted commit

  
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5d0fd3c806b9e932010931ae67dbb482020e0882

  "[media] uvcvideo: Disable hardware timestamps by default"

but I'm running with a kernel which doesn't have that change.

First, let me say that for our purposes, the hairy syncing to the
"SOF" clock done by uvc_video_clock_update is not that useful.
Ideally, I would prefer if the v4l2_buffer of a captured frame
included both

  * untranslated pts timestamp from the camera device (if I've
understood this correctly, and there is a pts sent over the wire),
and

  * the value of system monotonic clock at the point when the frame
was received by the kernel.

Is there any reasonable way to get this information out from the
driver? We could then do estimation of the camera's epoch and clock
drift in the application. The raw pts is the most important piece of
information.

Second, I'd like to try to provide some logs to help track down the
bug. To reproduce, I'm using the example program at
https://gist.github.com/maxlapshin/1253534, modified to print out
camera timestamp and gettimeofday for each frame. Log attached as
time-2.log.

I also enabled tracing of the clock translation logic using

  echo 4096 > /sys/module/uvcvideo/parameters/trace

The corresponding kernel log messages are attached as trace-2.log.

In time-2.log (i.e., the application log), I see that camera
timestamps move backwards in time,

  TIMESTAMP_MONOTONIC
 cam: 2321521.085372
 sys: 1477913910.983620
  TIMESTAMP_MONOTONIC
 cam: 2321520.879272
 sys: 1477913911.051628

In trace-2.log (i.e., kernel log messages) I see

  uvcvideo: Logitech Webcam C930e: PTS 219483992 y 4084.798004 SOF
4084.798004 (x1 2064310082 x2 2148397132 y1 218759168 y2 268238848 SOF
offset 170)
  uvcvideo: Logitech Webcam C930e: SOF 4084.798004 y 3105900702 ts
2321520.879272 buf ts 2321521.153372 (x1 218759168/1546/1290 x2
274071552/1878/2045 y1 10 y2 3380001263)
  uvcvideo: Logitech Webcam C930e: PTS 221480532 y 4156.709564 SOF
4156.709564 (x1 2079524156 x2 2148397450 y1 256376832 y2 272629760 SOF
offset 170)
  uvcvideo: Logitech Webcam C930e: SOF 4156.709564 y 2453257742 ts
2321520.378627 buf ts 2321521.217373 (x1 262275072/1698/1864 x2
278265856/1942/64 y1 10 y2 3292003672)
  uvcvideo: Logitech Webcam C930e: PTS 223477044 y 4223.428085 SOF
4223.428085 (x1 2081269216 x2 2148397122 y1 264568832 y2 276955136 SOF
offset 170)
  uvcvideo: Logitech Webcam C930e: SOF 2175.428085 y 2158773894 ts
2321520.208143 buf ts 2321521.285373 (x1 136183808/1822/1989 x2
148504576/2010/130 y1 10 y2 3236003012)

I don't know the details of the usb protocol, but it looks like the
"SOF" value is usually increasing. But close to the bogus output
timestamp of 2321520.879272, it goes through some kind of wraparound,
with the sequence of values

  4156.709564
  4223.428085
  2175.428085# 2048 less than previous value
  2243.169921

I hope the attached logs provide enough information to analyze where
uvc_video_clock_update gets this wrong.

Best regards,
/Niels Möller
TIMESTAMP_MONOTONIC
   cam: 2321518.773372
   sys: 1477913908.671607
TIMESTAMP_MONOTONIC
   cam: 2321518.925369
   sys: 1477913908.823594
TIMESTAMP_MONOTONIC
   cam: 2321519.049369
   sys: 1477913908.947600
TIMESTAMP_MONOTONIC
   cam: 2321519.173370
   sys: 1477913909.071610
TIMESTAMP_MONOTONIC
   cam: 2321519.297369
   sys: 1477913909.195603
TIMESTAMP_MONOTONIC
   cam: 2321519.421370
   sys: 1477913909.319607
TIMESTAMP_MONOTONIC
   cam: 2321519.489369
   sys: 1477913909.387594
TIMESTAMP_MONOTONIC
   cam: 2321519.553370
   sys: 1477913909.455586
TIMESTAMP_MONOTONIC
   cam: 2321519.621369
   sys: 1477913909.519601
TIMESTAMP_MONOTONIC
   cam: 2321519.689369
   sys: 1477913909.587594
TIMESTAMP_MONOTONIC
   cam: 2321519.753370
   sys: 1477913909.655587
TIMESTAMP_MONOTONIC
   cam: 2321519.821370
   sys: 1477913909.719600
TIMESTAMP_MONOTONIC
   cam: 2321519.889370
   sys: 1477913909.787594
TIMESTAMP_MONOTONIC
   cam: 2321519.953371
   sys: 1477913909.855585
TIMESTAMP_MONOTONIC
   cam: 2321520.021370
   sys: 1477913909.919602
TIMESTAMP_MONOTONIC
   cam: 2321520.089370
   sys: 1477913909.987594
TIMESTAMP_MONOTONIC
   cam: 2321520.153370
   sys: 1477913910.051609
TIMESTAMP_MONOTONIC
   cam: 2321520.221371
   sys: 1477913910.119597
TIMESTAMP_MONOTONIC
   cam: 2321520.289371
   sys: 1477913910.187599
TIMESTAMP_MONOTONIC
   cam: 2321520.353371
   sys: 1477913910.251609
TIMESTAMP_MONOTONIC
   cam: 2321520.421371
   sys: 1477913910.319597
TIMESTAMP_MONOTONIC
   cam: 2321520.485372
   sys: 1477913910.387588
TIMESTAMP_MONOTONIC
   cam: 2321520.553371
   sys: 1477913910.451604
TIMESTAMP_MONOTONIC
   cam: 2321520.621371
   sys: 1477913910.519595
TIMESTAMP_MONOTONIC

Re: [PATCH 2/2] mm: remove get_user_pages_locked()

2016-10-31 Thread Paolo Bonzini



On 31/10/2016 11:02, Lorenzo Stoakes wrote:
> - *
> - * get_user_pages should be phased out in favor of
> - * get_user_pages_locked|unlocked or get_user_pages_fast. Nothing
> - * should use get_user_pages because it cannot pass
> - * FAULT_FLAG_ALLOW_RETRY to handle_mm_fault.

This comment should be preserved in some way.  In addition, removing
get_user_pages_locked() makes it harder (compared to a simple "git grep
-w") to identify callers that lack allow-retry functionality).  So I'm
not sure about the benefits of these patches.

If all callers were changed, then sure removing the _locked suffix would
be a good idea.

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

[PATCH 14/82] media: usb: uvc: make use of new usb_endpoint_maxp_mult()

2016-10-31 Thread Felipe Balbi

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.

Cc: Laurent Pinchart 
Cc: Mauro Carvalho Chehab 
Cc: 
Signed-off-by: Felipe Balbi 
---
 drivers/media/usb/uvc/uvc_video.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index b5589d5f5da4..11e0e5f4e1c2 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1467,6 +1467,7 @@ static unsigned int uvc_endpoint_max_bpi(struct 
usb_device *dev,
 struct usb_host_endpoint *ep)
 {
u16 psize;
+   u16 mult;
 
switch (dev->speed) {
case USB_SPEED_SUPER:
@@ -1474,7 +1475,8 @@ static unsigned int uvc_endpoint_max_bpi(struct 
usb_device *dev,
return le16_to_cpu(ep->ss_ep_comp.wBytesPerInterval);
case USB_SPEED_HIGH:
psize = usb_endpoint_maxp(>desc);
-   return (psize & 0x07ff) * (1 + ((psize >> 11) & 3));
+   mult = usb_endpoint_maxp_mult(>desc);
+   return (psize & 0x07ff) * mult;
case USB_SPEED_WIRELESS:
psize = usb_endpoint_maxp(>desc);
return psize;
-- 
2.10.1

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

[PATCH 13/82] media: usbtv: core: make use of new usb_endpoint_maxp_mult()

2016-10-31 Thread Felipe Balbi

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.

Cc: Mauro Carvalho Chehab 
Cc: 
Signed-off-by: Felipe Balbi 
---
 drivers/media/usb/usbtv/usbtv-core.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/usbtv/usbtv-core.c 
b/drivers/media/usb/usbtv/usbtv-core.c
index dc76fd41e00f..ceb953be0770 100644
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -71,6 +71,7 @@ static int usbtv_probe(struct usb_interface *intf,
int size;
struct device *dev = >dev;
struct usbtv *usbtv;
+   struct usb_host_endpoint *ep;
 
/* Checks that the device is what we think it is. */
if (intf->num_altsetting != 2)
@@ -78,10 +79,12 @@ static int usbtv_probe(struct usb_interface *intf,
if (intf->altsetting[1].desc.bNumEndpoints != 4)
return -ENODEV;
 
+   ep = >altsetting[1].endpoint[0];
+
/* Packet size is split into 11 bits of base size and count of
 * extra multiplies of it.*/
-   size = usb_endpoint_maxp(>altsetting[1].endpoint[0].desc);
-   size = (size & 0x07ff) * (((size & 0x1800) >> 11) + 1);
+   size = usb_endpoint_maxp(>desc);
+   size = (size & 0x07ff) * usb_endpoint_maxp_mult(>desc);
 
/* Device structure */
usbtv = kzalloc(sizeof(struct usbtv), GFP_KERNEL);
-- 
2.10.1

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

[PATCH 30/82] media: usb: uvc: remove unnecessary & operation

2016-10-31 Thread Felipe Balbi

Now that usb_endpoint_maxp() only returns the lowest
11 bits from wMaxPacketSize, we can remove the &
operation from this driver.

Cc: Laurent Pinchart 
Cc: Mauro Carvalho Chehab 
Cc: 
Acked-by: Laurent Pinchart 
Signed-off-by: Felipe Balbi 
---
 drivers/media/usb/uvc/uvc_video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index 11e0e5f4e1c2..f3c1c852e401 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1553,7 +1553,7 @@ static int uvc_init_video_bulk(struct uvc_streaming 
*stream,
u16 psize;
u32 size;
 
-   psize = usb_endpoint_maxp(>desc) & 0x7ff;
+   psize = usb_endpoint_maxp(>desc);
size = stream->ctrl.dwMaxPayloadTransferSize;
stream->bulk.max_payload_size = size;
 
-- 
2.10.1

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

Lower exposure times than 100 us?

2016-10-31 Thread Michael Haardt

Hello,

V4L2_CID_EXPOSURE_ABSOLUTE uses a 100 us resolution.  Quite a few
sensors offer lower exposures and more fine resolutions than that.
Can the resolution be switched to e.g. 1 us, similar to how the tuner
frequency may be specified in smaller steps if the driver implements
the V4L2_TUNER_CAP_* values?

Regards,

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

StarTech SVID2USB2 suport

2016-10-31 Thread Jean-Grégoire Foulon


Hello,

I bought a usb2 video capture card which is not supported yet :

https://www.startech.com/AV/Converters/Video/USB-S-Video-and-Composite-Video-Capture-Device-Cable-with-Audio~SVID2USB2

I posted the pictures here :

https://linuxtv.org/wiki/index.php/File:Startech_svid2usb2_board_back.jpg

https://linuxtv.org/wiki/index.php/File:Startech_svid2usb2_open.jpg

Here is the result of dmesg :

[11662.666571] em28xx: New device  USB 2821 Device @ 480 Mbps 
(eb1a:2821, interface 0, class 0)

[11662.666576] em28xx: Video interface 0 found: bulk isoc
[11662.98] em28xx: chip ID is em2710/2820
[11662.790996] em2710/2820 #0: EEPROM ID = 1a eb 67 95, EEPROM hash = 
0x26da7a8a

[11662.791007] em2710/2820 #0: EEPROM info:
[11662.791009] em2710/2820 #0: AC97 audio (5 sample rates)
[11662.791010] em2710/2820 #0: 500mA max power
[11662.791012] em2710/2820 #0: Table at offset 0x04, strings=0x226a, 
0x, 0x

[11662.849346] em2710/2820 #0: No sensor detected
[11662.866090] em2710/2820 #0: found i2c device @ 0x4a on bus 0 [saa7113h]
[11662.883297] em2710/2820 #0: found i2c device @ 0xa0 on bus 0 [eeprom]
[11662.902797] em2710/2820 #0: Your board has no unique USB ID and thus 
need a hint to be detected.
[11662.902800] em2710/2820 #0: You may try to use card= insmod option 
to workaround that.

[11662.902802] em2710/2820 #0: Please send an email with this log to:
[11662.902803] em2710/2820 #0: V4L Mailing List 


[11662.902813] em2710/2820 #0: Board eeprom hash is 0x26da7a8a
[11662.902814] em2710/2820 #0: Board i2c devicelist hash is 0x6ba50080
[11662.902816] em2710/2820 #0: Here is a list of valid choices for the 
card= insmod option:

[11662.902818] em2710/2820 #0: card=0 -> Unknown EM2800 video grabber
[11662.902819] em2710/2820 #0: card=1 -> Unknown EM2750/28xx video 
grabber

[11662.902821] em2710/2820 #0: card=2 -> Terratec Cinergy 250 USB
[11662.902823] em2710/2820 #0: card=3 -> Pinnacle PCTV USB 2
[11662.902824] em2710/2820 #0: card=4 -> Hauppauge WinTV USB 2
[11662.902826] em2710/2820 #0: card=5 -> MSI VOX USB 2.0
[11662.902827] em2710/2820 #0: card=6 -> Terratec Cinergy 200 USB
[11662.902829] em2710/2820 #0: card=7 -> Leadtek Winfast USB II
[11662.902831] em2710/2820 #0: card=8 -> Kworld USB2800
[11662.902832] em2710/2820 #0: card=9 -> Pinnacle Dazzle DVC 
90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 / 
Plextor ConvertX PX-AV100U

[11662.902834] em2710/2820 #0: card=10 -> Hauppauge WinTV HVR 900
[11662.902836] em2710/2820 #0: card=11 -> Terratec Hybrid XS
[11662.902837] em2710/2820 #0: card=12 -> Kworld PVR TV 2800 RF
[11662.902839] em2710/2820 #0: card=13 -> Terratec Prodigy XS
[11662.902840] em2710/2820 #0: card=14 -> SIIG AVTuner-PVR / 
Pixelview Prolink PlayTV USB 2.0

[11662.902842] em2710/2820 #0: card=15 -> V-Gear PocketTV
[11662.902844] em2710/2820 #0: card=16 -> Hauppauge WinTV HVR 950
[11662.902845] em2710/2820 #0: card=17 -> Pinnacle PCTV HD Pro Stick
[11662.902847] em2710/2820 #0: card=18 -> Hauppauge WinTV HVR 900 (R2)
[11662.902848] em2710/2820 #0: card=19 -> EM2860/SAA711X Reference 
Design

[11662.902850] em2710/2820 #0: card=20 -> AMD ATI TV Wonder HD 600
[11662.902852] em2710/2820 #0: card=21 -> eMPIA Technology, Inc. 
GrabBeeX+ Video Encoder
[11662.902853] em2710/2820 #0: card=22 -> EM2710/EM2750/EM2751 
webcam grabber

[11662.902855] em2710/2820 #0: card=23 -> Huaqi DLCW-130
[11662.902856] em2710/2820 #0: card=24 -> D-Link DUB-T210 TV Tuner
[11662.902858] em2710/2820 #0: card=25 -> Gadmei UTV310
[11662.902860] em2710/2820 #0: card=26 -> Hercules Smart TV USB 2.0
[11662.902861] em2710/2820 #0: card=27 -> Pinnacle PCTV USB 2 
(Philips FM1216ME)

[11662.902863] em2710/2820 #0: card=28 -> Leadtek Winfast USB II Deluxe
[11662.902864] em2710/2820 #0: card=29 -> EM2860/TVP5150 Reference 
Design

[11662.902866] em2710/2820 #0: card=30 -> Videology 20K14XUSB USB2.0
[11662.902867] em2710/2820 #0: card=31 -> Usbgear VD204v9
[11662.902869] em2710/2820 #0: card=32 -> Supercomp USB 2.0 TV
[11662.902871] em2710/2820 #0: card=33 -> Elgato Video Capture
[11662.902872] em2710/2820 #0: card=34 -> Terratec Cinergy A Hybrid XS
[11662.902874] em2710/2820 #0: card=35 -> Typhoon DVD Maker
[11662.902875] em2710/2820 #0: card=36 -> NetGMBH Cam
[11662.902877] em2710/2820 #0: card=37 -> Gadmei UTV330
[11662.902878] em2710/2820 #0: card=38 -> Yakumo MovieMixer
[11662.902880] em2710/2820 #0: card=39 -> KWorld PVRTV 300U
[11662.902881] em2710/2820 #0: card=40 -> Plextor ConvertX PX-TV100U
[11662.902883] em2710/2820 #0: card=41 -> Kworld 350 U DVB-T
[11662.902884] em2710/2820 #0: card=42 -> Kworld 355 U DVB-T
[11662.902886] em2710/2820 #0: card=43 -> Terratec Cinergy T XS
[11662.902887] em2710/2820 #0: card=44 -> Terratec Cinergy T XS (MT2060)
[11662.902889]

[PATCH 2/2] mm: remove get_user_pages_locked()

2016-10-31 Thread Lorenzo Stoakes

get_user_pages() now has an int *locked parameter which renders
get_user_pages_locked() redundant, so remove it.

This patch should not introduce any functional changes.

Signed-off-by: Lorenzo Stoakes 
---
 include/linux/mm.h |  2 --
 mm/frame_vector.c  |  4 ++--
 mm/gup.c   | 56 +++---
 mm/nommu.c |  8 
 4 files changed, 22 insertions(+), 48 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 396984e..4db3147 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1278,8 +1278,6 @@ long get_user_pages_remote(struct task_struct *tsk, 
struct mm_struct *mm,
 long get_user_pages(unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
struct vm_area_struct **vmas, int *locked);
-long get_user_pages_locked(unsigned long start, unsigned long nr_pages,
-   unsigned int gup_flags, struct page **pages, int *locked);
 long __get_user_pages_unlocked(struct task_struct *tsk, struct mm_struct *mm,
   unsigned long start, unsigned long nr_pages,
   struct page **pages, unsigned int gup_flags);
diff --git a/mm/frame_vector.c b/mm/frame_vector.c
index db77dcb..c5ce1b1 100644
--- a/mm/frame_vector.c
+++ b/mm/frame_vector.c
@@ -55,8 +55,8 @@ int get_vaddr_frames(unsigned long start, unsigned int 
nr_frames,
if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
vec->got_ref = true;
vec->is_pfns = false;
-   ret = get_user_pages_locked(start, nr_frames,
-   gup_flags, (struct page **)(vec->ptrs), );
+   ret = get_user_pages(start, nr_frames,
+   gup_flags, (struct page **)(vec->ptrs), NULL, );
goto out;
}
 
diff --git a/mm/gup.c b/mm/gup.c
index 6b5539e..6cec693 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -826,37 +826,6 @@ static __always_inline long __get_user_pages_locked(struct 
task_struct *tsk,
 }
 
 /*
- * We can leverage the VM_FAULT_RETRY functionality in the page fault
- * paths better by using either get_user_pages_locked() or
- * get_user_pages_unlocked().
- *
- * get_user_pages_locked() is suitable to replace the form:
- *
- *  down_read(>mmap_sem);
- *  do_something()
- *  get_user_pages(tsk, mm, ..., pages, NULL, NULL);
- *  up_read(>mmap_sem);
- *
- *  to:
- *
- *  int locked = 1;
- *  down_read(>mmap_sem);
- *  do_something()
- *  get_user_pages_locked(tsk, mm, ..., pages, );
- *  if (locked)
- *  up_read(>mmap_sem);
- */
-long get_user_pages_locked(unsigned long start, unsigned long nr_pages,
-  unsigned int gup_flags, struct page **pages,
-  int *locked)
-{
-   return __get_user_pages_locked(current, current->mm, start, nr_pages,
-  pages, NULL, locked, true,
-  gup_flags | FOLL_TOUCH);
-}
-EXPORT_SYMBOL(get_user_pages_locked);
-
-/*
  * Same as get_user_pages_unlocked(, FOLL_TOUCH) but it allows to
  * pass additional gup_flags as last parameter (like FOLL_HWPOISON).
  *
@@ -954,11 +923,6 @@ EXPORT_SYMBOL(get_user_pages_unlocked);
  * use the correct cache flushing APIs.
  *
  * See also get_user_pages_fast, for performance critical applications.
- *
- * get_user_pages should be phased out in favor of
- * get_user_pages_locked|unlocked or get_user_pages_fast. Nothing
- * should use get_user_pages because it cannot pass
- * FAULT_FLAG_ALLOW_RETRY to handle_mm_fault.
  */
 long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
unsigned long start, unsigned long nr_pages,
@@ -976,6 +940,26 @@ EXPORT_SYMBOL(get_user_pages_remote);
  * less-flexible calling convention where we assume that the task
  * and mm being operated on are the current task's.  We also
  * obviously don't pass FOLL_REMOTE in here.
+ *
+ * We can leverage the VM_FAULT_RETRY functionality in the page fault
+ * paths better by using either get_user_pages()'s locked parameter or
+ * get_user_pages_unlocked().
+ *
+ * get_user_pages()'s locked parameter is suitable to replace the form:
+ *
+ *  down_read(>mmap_sem);
+ *  do_something()
+ *  get_user_pages(tsk, mm, ..., pages, NULL, NULL);
+ *  up_read(>mmap_sem);
+ *
+ *  to:
+ *
+ *  int locked = 1;
+ *  down_read(>mmap_sem);
+ *  do_something()
+ *  get_user_pages(tsk, mm, ..., pages, NULL, );
+ *  if (locked)
+ *  up_read(>mmap_sem);
  */
 long get_user_pages(unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
diff --git a/mm/nommu.c b/mm/nommu.c
index 82aaa33..3d38d40 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -168,14 +168,6 @@ long get_user_pages(unsigned long start, unsigned long 
nr_pages,
 }

[PATCH 0/2] mm: remove get_user_pages_locked()

2016-10-31 Thread Lorenzo Stoakes

by adding an int *locked parameter to get_user_pages() callers to this function
can now utilise VM_FAULT_RETRY functionality.

Taken in conjunction with the patch series adding the same parameter to
get_user_pages_remote() this means all slow-path get_user_pages*() functions
will now have the ability to utilise VM_FAULT_RETRY.

Additionally get_user_pages() and get_user_pages_remote() previously mirrored
one another in functionality differing only in the ability to specify task/mm,
this patch series reinstates this relationship.

This patch series should not introduce any functional changes.

Lorenzo Stoakes (2):
  mm: add locked parameter to get_user_pages()
  mm: remove get_user_pages_locked()

 arch/cris/arch-v32/drivers/cryptocop.c |  2 +
 arch/ia64/kernel/err_inject.c  |  2 +-
 arch/x86/mm/mpx.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c|  2 +-
 drivers/gpu/drm/via/via_dmablit.c  |  2 +-
 drivers/infiniband/core/umem.c |  2 +-
 drivers/infiniband/hw/mthca/mthca_memfree.c|  3 +-
 drivers/infiniband/hw/qib/qib_user_pages.c |  2 +-
 drivers/infiniband/hw/usnic/usnic_uiom.c   |  2 +-
 drivers/media/v4l2-core/videobuf-dma-sg.c  |  2 +-
 drivers/misc/mic/scif/scif_rma.c   |  1 +
 drivers/misc/sgi-gru/grufault.c|  3 +-
 drivers/platform/goldfish/goldfish_pipe.c  |  2 +-
 drivers/rapidio/devices/rio_mport_cdev.c   |  2 +-
 .../interface/vchiq_arm/vchiq_2835_arm.c   |  3 +-
 .../vc04_services/interface/vchiq_arm/vchiq_arm.c  |  3 +-
 drivers/virt/fsl_hypervisor.c  |  2 +-
 include/linux/mm.h |  4 +-
 mm/frame_vector.c  |  4 +-
 mm/gup.c   | 62 --
 mm/ksm.c   |  3 +-
 mm/mempolicy.c |  2 +-
 mm/nommu.c | 10 +---
 virt/kvm/kvm_main.c|  4 +-
 25 files changed, 55 insertions(+), 73 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] mm: add locked parameter to get_user_pages()

2016-10-31 Thread Lorenzo Stoakes

This patch adds an int *locked parameter to get_user_pages() to allow
VM_FAULT_RETRY faulting behaviour similar to get_user_pages_[un]locked().

It additionally clears the way for get_user_pages_locked() to be removed as its
sole remaining useful characteristic was to allow for VM_FAULT_RETRY behaviour
when faulting in pages.

It should not introduce any functional changes, however it does allow for
subsequent changes to get_user_pages() callers to take advantage of
VM_FAULT_RETRY.

Signed-off-by: Lorenzo Stoakes 
---
 arch/cris/arch-v32/drivers/cryptocop.c| 2 ++
 arch/ia64/kernel/err_inject.c | 2 +-
 arch/x86/mm/mpx.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c   | 2 +-
 drivers/gpu/drm/via/via_dmablit.c | 2 +-
 drivers/infiniband/core/umem.c| 2 +-
 drivers/infiniband/hw/mthca/mthca_memfree.c   | 3 ++-
 drivers/infiniband/hw/qib/qib_user_pages.c| 2 +-
 drivers/infiniband/hw/usnic/usnic_uiom.c  | 2 +-
 drivers/media/v4l2-core/videobuf-dma-sg.c | 2 +-
 drivers/misc/mic/scif/scif_rma.c  | 1 +
 drivers/misc/sgi-gru/grufault.c   | 3 ++-
 drivers/platform/goldfish/goldfish_pipe.c | 2 +-
 drivers/rapidio/devices/rio_mport_cdev.c  | 2 +-
 .../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c| 3 ++-
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 3 ++-
 drivers/virt/fsl_hypervisor.c | 2 +-
 include/linux/mm.h| 2 +-
 mm/gup.c  | 8 
 mm/ksm.c  | 3 ++-
 mm/mempolicy.c| 2 +-
 mm/nommu.c| 4 ++--
 virt/kvm/kvm_main.c   | 4 ++--
 24 files changed, 35 insertions(+), 27 deletions(-)

diff --git a/arch/cris/arch-v32/drivers/cryptocop.c 
b/arch/cris/arch-v32/drivers/cryptocop.c
index 0068fd4..7444b45 100644
--- a/arch/cris/arch-v32/drivers/cryptocop.c
+++ b/arch/cris/arch-v32/drivers/cryptocop.c
@@ -2723,6 +2723,7 @@ static int cryptocop_ioctl_process(struct inode *inode, 
struct file *filp, unsig
 noinpages,
 0,  /* read access only for in data */
 inpages,
+NULL,
 NULL);
 
if (err < 0) {
@@ -2737,6 +2738,7 @@ static int cryptocop_ioctl_process(struct inode *inode, 
struct file *filp, unsig
 nooutpages,
 FOLL_WRITE, /* write access for out data */
 outpages,
+NULL,
 NULL);
up_read(>mm->mmap_sem);
if (err < 0) {
diff --git a/arch/ia64/kernel/err_inject.c b/arch/ia64/kernel/err_inject.c
index 5ed0ea9..99f3fa2 100644
--- a/arch/ia64/kernel/err_inject.c
+++ b/arch/ia64/kernel/err_inject.c
@@ -142,7 +142,7 @@ store_virtual_to_phys(struct device *dev, struct 
device_attribute *attr,
u64 virt_addr=simple_strtoull(buf, NULL, 16);
int ret;
 
-   ret = get_user_pages(virt_addr, 1, FOLL_WRITE, NULL, NULL);
+   ret = get_user_pages(virt_addr, 1, FOLL_WRITE, NULL, NULL, NULL);
if (ret<=0) {
 #ifdef ERR_INJ_DEBUG
printk("Virtual address %lx is not existing.\n",virt_addr);
diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index e4f8009..b74a7b2 100644
--- a/arch/x86/mm/mpx.c
+++ b/arch/x86/mm/mpx.c
@@ -546,7 +546,7 @@ static int mpx_resolve_fault(long __user *addr, int write)
int nr_pages = 1;
 
gup_ret = get_user_pages((unsigned long)addr, nr_pages,
-   write ? FOLL_WRITE : 0, NULL, NULL);
+   write ? FOLL_WRITE : 0, NULL, NULL, NULL);
/*
 * get_user_pages() returns number of pages gotten.
 * 0 means we failed to fault in and get anything,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index dcaf691..3d9a195 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -584,7 +584,7 @@ int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct 
page **pages)
list_add(, >guptasks);
spin_unlock(>guptasklock);
 
-   r = get_user_pages(userptr,

[PATCH v2 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

2016-10-31 Thread Rick Chang

Add a DT binding documentation for Mediatek JPEG Decoder of
MT2701 SoC.

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
 .../bindings/media/mediatek-jpeg-codec.txt | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt 
b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
new file mode 100644
index 000..514e656
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
@@ -0,0 +1,35 @@
+* Mediatek JPEG Codec
+
+Mediatek JPEG Codec device driver is a v4l2 driver which can decode
+JPEG-encoded video frames.
+
+Required properties:
+  - compatible : "mediatek,mt2701-jpgdec"
+  - reg : Physical base address of the jpeg codec registers and length of
+memory mapped region.
+  - interrupts : interrupt number to the cpu.
+  - clocks : clock name from clock manager
+  - clock-names: the clocks of the jpeg codec H/W
+  - power-domains : a phandle to the power domain.
+  - larb : must contain the larbes of current platform
+  - iommus : Mediatek IOMMU H/W has designed the fixed associations with
+the multimedia H/W. and there is only one multimedia iommu domain.
+"iommus = < portid>" the "portid" is from
+dt-bindings\iommu\mt2701-iommu-port.h, it means that this portid will
+enable iommu. The portid default is disable iommu if "< portid>"
+don't be added.
+
+Example:
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,mt2701-jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
-- 
1.9.1

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

[PATCH v2 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

2016-10-31 Thread Rick Chang

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
This patch depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/
---
 arch/arm/boot/dts/mt2701.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 8f13c70..4dd5048 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -298,6 +298,20 @@
power-domains = < MT2701_POWER_DOMAIN_ISP>;
};
 
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,mt2701-jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
-- 
1.9.1

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

[PATCH v2 2/3] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

2016-10-31 Thread Rick Chang

Add v4l2 driver for Mediatek JPEG Decoder

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/Kconfig   |   15 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/mtk-jpeg/Makefile |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c  | 1271 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h  |  141 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c|  417 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h|   91 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c |  160 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h |   25 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h   |   58 +
 10 files changed, 2182 insertions(+)
 create mode 100644 drivers/media/platform/mtk-jpeg/Makefile
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..96c9887 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,21 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_MEDIATEK_JPEG
+   tristate "Mediatek JPEG Codec driver"
+   depends on MTK_IOMMU_V1 || COMPILE_TEST
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on HAS_DMA
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ Mediatek jpeg codec driver provides HW capability to decode
+ JPEG format
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-jpeg
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index f842933..cf701e3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU)  += mtk-vpu/
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
diff --git a/drivers/media/platform/mtk-jpeg/Makefile 
b/drivers/media/platform/mtk-jpeg/Makefile
new file mode 100644
index 000..b2e6069
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -0,0 +1,2 @@
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
new file mode 100644
index 000..64a2044
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -0,0 +1,1271 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Ming Hsiu Tsai 
+ * Rick Chang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_core.h"
+#include "mtk_jpeg_parse.h"
+
+static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
+   {
+   .name   = "JPEG JFIF",
+   .fourcc = V4L2_PIX_FMT_JPEG,
+   .colplanes  = 1,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
+   },
+   {
+   .name   = "YUV 4:2:0 non-contiguous 3-planar, Y/Cb/Cr",
+   .fourcc = V4L2_PIX_FMT_YUV420M,
+   .h_sample   = {4, 2, 2},
+   .v_sample   = {4, 2, 2},
+   .colplanes  = 3,
+   .h_align= 5,
+   .v_align= 4,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+   },
+   {
+   .name   = "YUV 4:2:2 non-contiguous 3-planar,

[PATCH v2 0/3] Add Mediatek JPEG Decoder

2016-10-31 Thread Rick Chang

This series of patches provide a v4l2 driver to control Mediatek JPEG hw
for decoding JPEG image and Motion JPEG bitstream.

changes since v1:
- Rebase for v4.9-rc1.
- Update Compliance test version and result
- Remove redundant path in Makefile
- Fix potential build error without CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP
- Fix warnings from patch check and smatch check

* Dependency
The patch "arm: dts: mt2701: Add node for JPEG decoder" depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/

* Compliance test
v4l2-compliance SHA   : 4ad7174b908a36c4f315e3fe2efa7e2f8a6f375a

Driver Info:
Driver name   : mtk-jpeg decode
Card type : mtk-jpeg decoder
Bus info  : platform:15004000.jpegdec
Driver version: 4.9.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/video3 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK
test Scaling: OK

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:


Total: 43, Succeeded: 43, Failed: 0, Warnings: 0

Rick Chang (3):
  dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder
  vcodec: mediatek: Add Mediatek JPEG Decoder Driver
  arm: dts: mt2701: Add node for Mediatek JPEG Decoder

 .../bindings/media/mediatek-jpeg-codec.txt |   35 +
 arch/arm/boot/dts/mt2701.dtsi  |   14 +
 drivers/media/platform/Kconfig |   15 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/mtk-jpeg/Makefile   |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c| 1271 
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h|  141 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c  |  417 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h  |   91 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c   |  160 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h   |   25 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h

Re: [PATCH] [media] lirc: introduce LIRC_SET_TRANSMITTER_WAIT ioctl

2016-10-31 Thread Andi Shyti

Hi Sean.

> > >   ret *= sizeof(unsigned int);
> > >  
> > > - /*
> > > -  * The lircd gap calculation expects the write function to
> > > -  * wait for the actual IR signal to be transmitted before
> > > -  * returning.
> > > -  */
> > > - towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
> > > - if (towait > 0) {
> > > - set_current_state(TASK_INTERRUPTIBLE);
> > > - schedule_timeout(usecs_to_jiffies(towait));
> > > + if (!lirc->tx_no_wait) {
> > > + /*
> > > +  * The lircd gap calculation expects the write function to
> > > +  * wait for the actual IR signal to be transmitted before
> > > +  * returning.
> > > +  */
> > > + towait = ktime_us_delta(ktime_add_us(start, duration),
> > > + ktime_get());
> > > + if (towait > 0) {
> > > + set_current_state(TASK_INTERRUPTIBLE);
> > > + schedule_timeout(usecs_to_jiffies(towait));
> > > + }
> > >   }
> > > -
> > 
> > this doesn't fix my problem, though.
> > 
> > This approach gives the userspace the possibility to choose to
> > either sync or not. In my case the sync happens, but in a
> > different level and it's not up to the userspace to make the
> > decision.
> 
> What problem are you trying to solve?
> 
> I wrote this patch as a response to this patch:
> 
> https://lkml.org/lkml/2016/9/1/653

Actually no big problem here but what I wrote below.

If the user sets LIRC_SET_TRANSMITTER_WAIT to 0 and the driver
waits anyway, this patch wouldn't be of any use and it would
do exactly what it whas doing before.

> In the spi case, the driver already waits for the IR to complete so the 
> wait in ir_lirc_transmit_ir() is unnecessary. However it does not end up
> waiting. There are other drivers like yours that wait for the IR to 
> complete (ene_ir, ite-cir). Since towait in ir_lirc_transmit_ir is the 
> delta between before and after the driver transmits, it will be 0 and 
> will never goto into schedule_timeout(), barring some very minor rounding 
> differences.
> 
> > Besides, I see here a security issue: what happens if userspace
> > does something like
> > 
> >  fd = open("/dev/lirc0", O_RDWR);
> > 
> >  ioctl(fd, LIRC_SET_TRANSMITTER_WAIT, 0);
> > 
> >  while(1)
> > write(fd, buffer, ENORMOUS_BUFFER_SIZE);
> 
> I don't understand what problem this would introduce.
> 
> You can't write more than 512 pulse/spaces and each write cannot
> have more than 500ms in IR (so adding up the pulses and spaces). The driver
> should only send once the previous send completed.

OK.

> > > + case LIRC_SET_TRANSMITTER_WAIT:
> > > + if (!dev->tx_ir)
> > > + return -ENOTTY;
> > > +
> > > + lirc->tx_no_wait = !val;
> > > + break;
> > > +
> > 
> > Here I see an innocuous bug. Depending on the hardware (for
> > example ir-spi) it might happen that the device waits in any
> > case (in ir-spi the sync is done by the spi). This means that if
> > userspace sets 'tx_no_wait = true', the device/driver doesn't
> > care and waits anyway, doing the opposite from what is described
> > in the ABI.
> > 
> > Here we could call a dev->tx_set_transmitter_wait(...) function
> > that sets the value or returns error in case the wait is not
> > feasable, something like:
> > 
> > case LIRC_SET_TRANSMITTER_WAIT:
> > if (!dev->tx_ir)
> > return -ENOTTY;
> > 
> > if (dev->tx_set_transmitter_wait)
> > return dev->tx_set_transmitter_wait(lirc, val);
> > 
> > lirc->tx_no_wait = !val;
> > break;
> 
> That is true. Do you want the ir-spi driver to be able to send without
> waiting?

I think there should be some meccanism to keep it coherent with
the ABI, mine was a suggestion.

> > > --- a/drivers/media/rc/rc-core-priv.h
> > > +++ b/drivers/media/rc/rc-core-priv.h
> > > @@ -112,7 +112,7 @@ struct ir_raw_event_ctrl {
> > >   u64 gap_duration;
> > >   bool gap;
> > >   bool send_timeout_reports;
> > > -
> > > + bool tx_no_wait;
> > >   } lirc;
> > 
> > this to me looks confusing, it has a negative meaning in kernel
> > space and a positive meaning in userspace. Can't we call it
> > lirc->tx_wait instead of lirc->tx_no_wait, so that we keep the
> > same meaning and we don't need to negate val?
> 
> This was just done to avoid having to initialise to true (non-zero).

OK, this was just a nitpick anyway :)

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

38 matches

Mail list logo