Re: [PATCH] media: sh_mobile_ceu_camera, rcar_vin: Use ARCH_RENESAS

2016-03-06 Thread Geert Uytterhoeven 
Hi Simon,

Oops, seems I dropped all CCs in my earlier reply. Fixing up...

On Mon, Mar 7, 2016 at 2:28 AM, Simon Horman  wrote:
> On Thu, Mar 03, 2016 at 09:40:07AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Mar 3, 2016 at 2:52 AM, Simon Horman  
>> wrote:
>> > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
>> >
>> > This is part of an ongoing process to migrate from ARCH_SHMOBILE to
>> > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
>> > appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
>> >
>> > Signed-off-by: Simon Horman 
>>
>> > --- a/drivers/media/platform/soc_camera/Kconfig
>> > +++ b/drivers/media/platform/soc_camera/Kconfig
>> > @@ -36,7 +36,7 @@ config VIDEO_PXA27x
>> >  config VIDEO_RCAR_VIN
>> > tristate "R-Car Video Input (VIN) support"
>> > depends on VIDEO_DEV && SOC_CAMERA
>> > -   depends on ARCH_SHMOBILE || COMPILE_TEST
>> > +   depends on ARCH_RENESAS || COMPILE_TEST
>>
>> OK
>>
>> >>  config VIDEO_SH_MOBILE_CEU
>> > tristate "SuperH Mobile CEU Interface driver"
>> > depends on VIDEO_DEV && SOC_CAMERA && HAS_DMA && HAVE_CLK
>> > -   depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST
>> > +   depends on ARCH_RENESAS || SUPERH || COMPILE_TEST
>>
>> I think dropping the SUPERH dependency is the right approach here, as all
>> SuperH platforms using this driver select ARCH_SHMOBILE.
>>
>> "sh_mobile_ceu" is used on SH_AP325RXA, SH_ECOVEC, SH_KFR2R09, SH_MIGOR,
>> and SH_7724_SOLUTION_ENGINE, which depend on either CPU_SUBTYPE_SH7722,
>>  CPU_SUBTYPE_SH7723, or
>> CPU_SUBTYPE_SH7724, and all three select ARCH_SHMOBILE.
>
> Dropping SUPERH seems fine to me. But in that case I think the following
> would be best as I would like to stop selecting ARCH_SHMOBILE for
> the ARM SoCs.
>
> depends on ARCH_RENESAS || ARCH_SHMOBILE || COMPILE_TEST

Do we need this driver with ARCH_RENESAS? It does not support DT.

R8a7740 has the sh_mobile_ceu hardware, but support for it was dropped with
r8a7740/armadillo legacy removal.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: tw686x driver

2016-03-06 Thread Krzysztof Hałasa 
Hans Verkuil  writes:

> Sorry, I meant V4L2_FIELD_INTERLACED support. Very few applications support
> FIELD_TOP/BOTTOM, let alone SEQ_BT.

Well, that's doable, though not in SG mode. It still doesn't require
memcpy() of uncompressed video.

> I don't get it. Getting your driver in staging is much better for you since
> your code is in there and can be compiled for those who want to. I'm not
> going to add your driver and then replace it with Ezequiel's version.

Then simply add my driver and don't replace it.
Face it: Ezequiel's driver adds the audio support, and I guess he can
add this audio code without breaking the existing driver.
I also have (old) audio code for this driver, but it has only been
tested without an actual audio input, so it's not ready for deployment.
I simply don't use audio at the moment.

Otherwise, "his driver" is a regression - it removes critical
functionality, in exchange giving only the V4L2_FIELD_INTERLACED, which
can be easily implemented without breaking the rest.

> Heck, if you prefer your driver can be added to staging first, then Ezequiel's
> driver commit can directly refer to the staging driver as being
> derived from it.

Well, I will have to think about it. Though I wonder - if you do that,
perhaps my next request should be to swap them.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
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

cron job: media_tree daily build: OK

2016-03-06 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:   Mon Mar  7 04:00:18 CET 2016
git branch: test
git hash:   de08b5a8be0df1eb7c796b0fe6b30cf1d03d14a6
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-51-ga53cea2
smatch version: v0.5.0-3228-g5cf65ab
host hardware:  x86_64
host os:4.4.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.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

Re: Kernel docs: muddying the waters a bit

2016-03-06 Thread Jonathan Corbet 
On Thu, 03 Mar 2016 16:03:14 +0200
Jani Nikula  wrote:

> This stalled a bit, but the waters are still muddy...

So I've been messing with this a bit; wanted to do a proper patch posting
but I'm fried and mostly out of time for the moment.

The results I'm getting now can be seen at:

http://static.lwn.net/kerneldoc/

I've pulled in a few templates (including gpu.tmpl), converted them, and
built them into some reasonable-looking HTML, modulo a fair number of
glitches. There's lots of details to deal with, but the broad shape of it
is there.  If you look, you'll see that things like cross-file
cross-references, a feature we've never had before, work nicely.

I can also get good EPUB and PDF output - except that rst2pdf is
currently crashing on me, which is a little discouraging.  Man page
output will take more work.

What I have so far can be pulled from:

git://git.lwn.net/linux.git doc/sphinx

It's still based on using docproc because that was easiest (for me).  The
kernel-doc part is Jani's asciidoc stuff, hacked up and made uglier.  I'm
not sure that any of it is worth more than a demonstration of what can be
done; I'm not particularly proud of (or tied to) any of it.  But it's a
start.

I've not looked at the table situation at all; soon.

jon
--
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: Kernel docs: muddying the waters a bit

2016-03-06 Thread Johannes Stezenbach 
On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote:
> 
> I converted one of the big tables to CSV. At least now it recognized
> it as a table. Yet, the table was very badly formated:
>   
> https://mchehab.fedorapeople.org/media-kabi-docs-test/rst_tests/packed-rgb.html
> 
> This is how this table should look like:
>   https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html
> 
> Also, as this table has merged cells at the legend. I've no idea how
> to tell sphinx to do that on csv format.
> 
> The RST files are on this git tree:
>   https://git.linuxtv.org/mchehab/v4l2-docs-poc.git/

Yeah, seems it can't do merged cells in csv.  Attached patch converts it
back to grid table format and fixes the table definition.
The html output looks usable, but clearly it is no fun to
work with tables in Sphinx.

Sphinx' latex writer can't handle nested tables, though.
Python's docutils rst2latex can, but that doesn't help here.
rst2pdf also supports it.  But I have doubts such a large
table would render OK in pdf without using landscape orientation.
I have not tried because I used python3-sphinx but rst2pdf
is only availble for Python2 in Debian so it does not integrate
with Sphinx.


Johannes
>From 61674b398e778bd5ff644ffd493d5ff1cfaca0ef Mon Sep 17 00:00:00 2001
From: Johannes Stezenbach 
Date: Sun, 6 Mar 2016 23:55:19 +0100
Subject: [PATCH] some progress for html output

---
 _static/borderless.css |  3 --
 _static/v4l2tables.css |  9 +
 _templates/layout.html |  9 +
 packed-rgb.rst | 88 +-
 pixfmt-yuyv.rst|  2 +-
 v4l-table-within-table.rst | 72 +++--
 6 files changed, 105 insertions(+), 78 deletions(-)
 delete mode 100644 _static/borderless.css
 create mode 100644 _static/v4l2tables.css

diff --git a/_static/borderless.css b/_static/borderless.css
deleted file mode 100644
index bfd4b01..000
--- a/_static/borderless.css
+++ /dev/null
@@ -1,3 +0,0 @@
-table#table-borderless {
-border: 1px solid black;
-}
diff --git a/_static/v4l2tables.css b/_static/v4l2tables.css
new file mode 100644
index 000..c045e45
--- /dev/null
+++ b/_static/v4l2tables.css
@@ -0,0 +1,9 @@
+table.noborder {
+border: 1px solid black;
+background: white;
+white-space: nowrap;
+}
+
+table.noborder td, table.noborder th {
+padding: 0px;
+}
diff --git a/_templates/layout.html b/_templates/layout.html
index b6bf12b..637332d 100644
--- a/_templates/layout.html
+++ b/_templates/layout.html
@@ -1,9 +1,2 @@
 {% extends "!layout.html" %}
-{% block tables %}
-
-table#table-borderless {
-border: 1px solid black;
-}
-
-{{ super() }}
-{% endblock %}
+{% set css_files = css_files + ["_static/v4l2tables.css"] %}
diff --git a/packed-rgb.rst b/packed-rgb.rst
index 352b91c..b4fcf3e 100644
--- a/packed-rgb.rst
+++ b/packed-rgb.rst
@@ -9,25 +9,46 @@ graphics frame buffers. They occupy 8, 16, 24 or 32 bits per pixel.
 These are all packed-pixel formats, meaning all the data for a pixel lie
 next to each other in memory.
 
-.. csv-table:: Table: Packed RGB Image Formats
-  :header: Identifier,Code, ,Byte 0 in memory,Byte 1,Byte 2,Byte 3
+.. table:: Packed RGB Image Formats
+   :class: noborder
 
-  ``V4L2_PIX_FMT_RGB332``,'RGB1',,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`1`,b\ :sub:`0`
-  ``V4L2_PIX_FMT_ARGB444``,'AR12',,g\ :sub:`3`,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,a\ :sub:`3`,a\ :sub:`2`,a\ :sub:`1`,a\ :sub:`0`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`
-  ``V4L2_PIX_FMT_XRGB444``,'XR12',,g\ :sub:`3`,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,-,-,-,-,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`
-  ``V4L2_PIX_FMT_ARGB555``,'AR15',,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,a,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`
-  ``V4L2_PIX_FMT_XRGB555``,'XR15',,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,-,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`
-  ``V4L2_PIX_FMT_RGB565``,'RGBP',,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`5`,g\ :sub:`4`,g\ :sub:`3`
-  ``V4L2_PIX_FMT_ARGB555X``,'AR15' | (1<<31),,a,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`,,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`
-  ``V4L2_PIX_FMT_XRGB555X``,'XR15' | (1<<31),,-,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`,,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`
-

dib0700_devices.c:undefined reference to `dibx000_i2c_set_speed'

2016-03-06 Thread kbuild test robot 
Hi Mauro,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   67944024c1cdd897e49a09b0d6af3ea38d1388ca
commit: fa8cb6444c3236d2bad7460bdfdb2685f82b7ee4 [media] ov2659: Don't depend 
on subdev API
date:   9 months ago
config: i386-randconfig-h0-03070225 (attached as .config)
reproduce:
git checkout fa8cb6444c3236d2bad7460bdfdb2685f82b7ee4
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `dib01x0_pmu_update.constprop.9':
>> dib0700_devices.c:(.text.unlikely+0x9029): undefined reference to 
>> `dibx000_i2c_set_speed'

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


.config.gz
Description: Binary data

[PATCH 2/2] [media] gspca_kinect: enable both video and depth streams

2016-03-06 Thread Ulrik de Muelenaere 
The Kinect produces both a video stream and a depth stream. Call
gspca_dev_probe() twice to create a video device node for each.

Remove the depth_mode parameter which had to be set at probe time in
order to select either the video or depth stream.

Signed-off-by: Ulrik de Muelenaere 
---
 drivers/media/usb/gspca/kinect.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/media/usb/gspca/kinect.c b/drivers/media/usb/gspca/kinect.c
index 3cb30a3..4bc5b7d 100644
--- a/drivers/media/usb/gspca/kinect.c
+++ b/drivers/media/usb/gspca/kinect.c
@@ -36,8 +36,6 @@ MODULE_AUTHOR("Antonio Ospite ");
 MODULE_DESCRIPTION("GSPCA/Kinect Sensor Device USB Camera Driver");
 MODULE_LICENSE("GPL");
 
-static bool depth_mode;
-
 struct pkt_hdr {
uint8_t magic[2];
uint8_t pad;
@@ -424,7 +422,7 @@ static void sd_pkt_scan(struct gspca_dev *gspca_dev, u8 
*__data, int len)
 
 /* sub-driver description */
 static const struct sd_desc sd_desc_video = {
-   .name  = MODULE_NAME,
+   .name  = MODULE_NAME "_video",
.config= sd_config_video,
.init  = sd_init,
.start = sd_start_video,
@@ -436,7 +434,7 @@ static const struct sd_desc sd_desc_video = {
*/
 };
 static const struct sd_desc sd_desc_depth = {
-   .name  = MODULE_NAME,
+   .name  = MODULE_NAME "_depth",
.config= sd_config_depth,
.init  = sd_init,
.start = sd_start_depth,
@@ -460,12 +458,19 @@ MODULE_DEVICE_TABLE(usb, device_table);
 /* -- device connect -- */
 static int sd_probe(struct usb_interface *intf, const struct usb_device_id *id)
 {
-   if (depth_mode)
-   return gspca_dev_probe(intf, id, _desc_depth,
-  sizeof(struct sd), THIS_MODULE);
-   else
-   return gspca_dev_probe(intf, id, _desc_video,
-  sizeof(struct sd), THIS_MODULE);
+   int res;
+
+   res = gspca_dev_probe(intf, id, _desc_video, sizeof(struct sd),
+ THIS_MODULE);
+   if (res < 0)
+   return res;
+
+   res = gspca_dev_probe(intf, id, _desc_depth, sizeof(struct sd),
+ THIS_MODULE);
+   if (res < 0)
+   gspca_disconnect(intf);
+
+   return res;
 }
 
 static struct usb_driver sd_driver = {
@@ -481,6 +486,3 @@ static struct usb_driver sd_driver = {
 };
 
 module_usb_driver(sd_driver);
-
-module_param(depth_mode, bool, 0644);
-MODULE_PARM_DESC(depth_mode, "0=video 1=depth");
-- 
2.7.0

--
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] [media] gspca: allow multiple probes per USB interface

2016-03-06 Thread Ulrik de Muelenaere 
Allow gspca_dev_probe() to be called multiple times per USB interface,
resulting in multiple video device nodes.

A pointer to the created gspca_dev is stored as the interface's private
data. Store other devices linked to the same interface as a linked list,
allowing all devices to be disconnected, suspended or resumed when given
the interface.

This is useful for subdrivers such as gspca_kinect, where a single USB
interface produces both video and depth streams.

Signed-off-by: Ulrik de Muelenaere 
---
 drivers/media/usb/gspca/gspca.c | 129 +++-
 drivers/media/usb/gspca/gspca.h |   1 +
 2 files changed, 76 insertions(+), 54 deletions(-)

diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index af5cd82..d002b8b 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -2004,8 +2004,9 @@ static const struct video_device gspca_template = {
 /*
  * probe and create a new gspca device
  *
- * This function must be called by the sub-driver when it is
- * called for probing a new device.
+ * This function must be called by the sub-driver when it is called for probing
+ * a new device. It may be called multiple times per USB interface, resulting 
in
+ * multiple video device nodes.
  */
 int gspca_dev_probe2(struct usb_interface *intf,
const struct usb_device_id *id,
@@ -2037,6 +2038,7 @@ int gspca_dev_probe2(struct usb_interface *intf,
gspca_dev->dev = dev;
gspca_dev->iface = intf->cur_altsetting->desc.bInterfaceNumber;
gspca_dev->xfer_ep = -1;
+   gspca_dev->next_dev = usb_get_intfdata(intf);
 
/* check if any audio device */
if (dev->actconfig->desc.bNumInterfaces != 1) {
@@ -2169,41 +2171,50 @@ EXPORT_SYMBOL(gspca_dev_probe);
  */
 void gspca_disconnect(struct usb_interface *intf)
 {
-   struct gspca_dev *gspca_dev = usb_get_intfdata(intf);
+   struct gspca_dev *gspca_dev = usb_get_intfdata(intf), *next_dev;
 #if IS_ENABLED(CONFIG_INPUT)
struct input_dev *input_dev;
 #endif
 
-   PDEBUG(D_PROBE, "%s disconnect",
-   video_device_node_name(_dev->vdev));
+   while (gspca_dev) {
+   PDEBUG(D_PROBE, "%s disconnect",
+   video_device_node_name(_dev->vdev));
 
-   mutex_lock(_dev->usb_lock);
+   mutex_lock(_dev->usb_lock);
 
-   gspca_dev->present = 0;
-   destroy_urbs(gspca_dev);
+   gspca_dev->present = 0;
+   destroy_urbs(gspca_dev);
 
 #if IS_ENABLED(CONFIG_INPUT)
-   gspca_input_destroy_urb(gspca_dev);
-   input_dev = gspca_dev->input_dev;
-   if (input_dev) {
-   gspca_dev->input_dev = NULL;
-   input_unregister_device(input_dev);
-   }
+   gspca_input_destroy_urb(gspca_dev);
+   input_dev = gspca_dev->input_dev;
+   if (input_dev) {
+   gspca_dev->input_dev = NULL;
+   input_unregister_device(input_dev);
+   }
 #endif
-   /* Free subdriver's streaming resources / stop sd workqueue(s) */
-   if (gspca_dev->sd_desc->stop0 && gspca_dev->streaming)
-   gspca_dev->sd_desc->stop0(gspca_dev);
-   gspca_dev->streaming = 0;
-   gspca_dev->dev = NULL;
-   wake_up_interruptible(_dev->wq);
+   /* Free subdriver's streaming resources / stop sd
+* workqueue(s)
+*/
+   if (gspca_dev->sd_desc->stop0 && gspca_dev->streaming)
+   gspca_dev->sd_desc->stop0(gspca_dev);
+   gspca_dev->streaming = 0;
+   gspca_dev->dev = NULL;
+   wake_up_interruptible(_dev->wq);
 
-   v4l2_device_disconnect(_dev->v4l2_dev);
-   video_unregister_device(_dev->vdev);
+   v4l2_device_disconnect(_dev->v4l2_dev);
+   video_unregister_device(_dev->vdev);
 
-   mutex_unlock(_dev->usb_lock);
+   mutex_unlock(_dev->usb_lock);
 
-   /* (this will call gspca_release() immediately or on last close) */
-   v4l2_device_put(_dev->v4l2_dev);
+   next_dev = gspca_dev->next_dev;
+   /* (this will call gspca_release() immediately or on last
+* close)
+*/
+   v4l2_device_put(_dev->v4l2_dev);
+
+   gspca_dev = next_dev;
+   }
 }
 EXPORT_SYMBOL(gspca_disconnect);
 
@@ -2212,21 +2223,27 @@ int gspca_suspend(struct usb_interface *intf, 
pm_message_t message)
 {
struct gspca_dev *gspca_dev = usb_get_intfdata(intf);
 
-   gspca_input_destroy_urb(gspca_dev);
+   while (gspca_dev) {
+   gspca_input_destroy_urb(gspca_dev);
 
-   if (!gspca_dev->streaming)
-   return 0;
+   if (!gspca_dev->streaming) {
+   gspca_dev = gspca_dev->next_dev;
+   continue;
+   }
 
-

[PATCH 0/2] [media] gspca_kinect: enable both video and depth streams

2016-03-06 Thread Ulrik de Muelenaere 
Hello,

The Kinect produces both a video and depth stream, but the current 
implementation of the
gspca_kinect subdriver requires a depth_mode parameter at probe time to select 
one of
the streams which will be exposed as a v4l device. This patchset allows both 
streams to
be accessed as separate video nodes.

A possible solution which has been discussed in the past is to call 
gspca_dev_probe()
multiple times in order to create multiple video nodes. See the following mails:

http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/26194/focus=26213
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/76715/focus=78344

In the second mail linked above, it was mentioned that gspca_dev_probe() cannot 
be
called multiple times for the same USB interface, since gspca_dev_probe2() 
stores a
pointer to the new gspca_dev as the interface's private data. This is required 
for
gspca_disconnect(), gspca_suspend() and gspca_resume(). As far as I can tell, 
this is
the only reason gspca_dev_probe() cannot be called multiple times.

The first patch fixes this by storing other devices linked to the same 
interface as a
linked list. The second patch then calls gspca_dev_probe() twice in the 
gspca_kinect
subdriver, to create a video node for each stream.

Some notes on error handling, which I think should be reviewed:

* I could not test the gspca_suspend() and gspca_resume() functions. From my 
evaluation
  of the code, it seems that the only effect of returning an error code from
  gspca_resume() is that a message is logged. Therefore I decided to attempt to 
resume
  each gspca_dev when the interface is resumed, even if one fails. Bitwise OR 
seems
  like the best way to combine potentially multiple error codes.

* In the gspca_kinect subdriver, if the second call to gspca_dev_probe() fails, 
the
  first video node will still be available. I handle this case by calling
  gspca_disconnect(), which worked when I was testing, but I am not sure if 
this is the
  correct way to handle it.

Regards,
Ulrik

Ulrik de Muelenaere (2):
  [media] gspca: allow multiple probes per USB interface
  [media] gspca_kinect: enable both video and depth streams

 drivers/media/usb/gspca/gspca.c  | 129 +++
 drivers/media/usb/gspca/gspca.h  |   1 +
 drivers/media/usb/gspca/kinect.c |  28 +
 3 files changed, 91 insertions(+), 67 deletions(-)

-- 
2.7.0

--
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 5/6] [media] touptek: don't DMA at the stack

2016-03-06 Thread Mauro Carvalho Chehab 
As warned by smatch:
drivers/media/usb/gspca/touptek.c:220 reg_w() error: doing dma on the 
stack (buff)
drivers/media/usb/gspca/touptek.c:458 configure() error: doing dma on 
the stack (buff)

This can fail, as the stack may not be in a memory that would
allod DMA. So, use the usb_buf instead.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/gspca/touptek.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/gspca/touptek.c 
b/drivers/media/usb/gspca/touptek.c
index 7bac6bc96063..8063b8e45ee5 100644
--- a/drivers/media/usb/gspca/touptek.c
+++ b/drivers/media/usb/gspca/touptek.c
@@ -211,7 +211,7 @@ static int val_reply(struct gspca_dev *gspca_dev, const 
char *reply, int rc)
 
 static void reg_w(struct gspca_dev *gspca_dev, u16 value, u16 index)
 {
-   char buff[1];
+   char *buff = gspca_dev->usb_buf;
int rc;
 
PDEBUG(D_USBO,
@@ -438,7 +438,7 @@ static void configure_encrypted(struct gspca_dev *gspca_dev)
 static int configure(struct gspca_dev *gspca_dev)
 {
int rc;
-   uint8_t buff[4];
+   char *buff = gspca_dev->usb_buf;
 
PDEBUG(D_STREAM, "configure()\n");
 
-- 
2.5.0

--
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/6] [media] ddcore: avoid endless loop if readl() fails

2016-03-06 Thread Mauro Carvalho Chehab 
As warned by smatch:
drivers/media/pci/ddbridge/ddbridge-core.c:1351 flashio() warn: this 
loop depends on readl() succeeding
drivers/media/pci/ddbridge/ddbridge-core.c:1371 flashio() warn: this 
loop depends on readl() succeeding

Let the loop be interrupted too if something really bad happens
and readl() fails.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 6e995ef8c37e..4b85dd0cac3f 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -1339,6 +1339,7 @@ static irqreturn_t irq_handler(int irq, void *dev_id)
 static int flashio(struct ddb *dev, u8 *wbuf, u32 wlen, u8 *rbuf, u32 rlen)
 {
u32 data, shift;
+   int val;
 
if (wlen > 4)
ddbwritel(1, SPI_CONTROL);
@@ -1348,8 +1349,9 @@ static int flashio(struct ddb *dev, u8 *wbuf, u32 wlen, 
u8 *rbuf, u32 rlen)
wbuf += 4;
wlen -= 4;
ddbwritel(data, SPI_DATA);
-   while (ddbreadl(SPI_CONTROL) & 0x0004)
-   ;
+   do {
+   val = ddbreadl(SPI_CONTROL);
+   } while (val >= 0 && val & 0x0004);
}
 
if (rlen)
@@ -1368,8 +1370,9 @@ static int flashio(struct ddb *dev, u8 *wbuf, u32 wlen, 
u8 *rbuf, u32 rlen)
if (shift)
data <<= shift;
ddbwritel(data, SPI_DATA);
-   while (ddbreadl(SPI_CONTROL) & 0x0004)
-   ;
+   do {
+   val = ddbreadl(SPI_CONTROL);
+   } while (val >= 0 && val & 0x0004);
 
if (!rlen) {
ddbwritel(0, SPI_CONTROL);
@@ -1380,8 +1383,9 @@ static int flashio(struct ddb *dev, u8 *wbuf, u32 wlen, 
u8 *rbuf, u32 rlen)
 
while (rlen > 4) {
ddbwritel(0x, SPI_DATA);
-   while (ddbreadl(SPI_CONTROL) & 0x0004)
-   ;
+   do {
+   val = ddbreadl(SPI_CONTROL);
+   } while (val >= 0 && val & 0x0004);
data = ddbreadl(SPI_DATA);
*(u32 *) rbuf = swab32(data);
rbuf += 4;
@@ -1389,8 +1393,9 @@ static int flashio(struct ddb *dev, u8 *wbuf, u32 wlen, 
u8 *rbuf, u32 rlen)
}
ddbwritel(0x0003 | ((rlen << (8 + 3)) & 0x1F00), SPI_CONTROL);
ddbwritel(0x, SPI_DATA);
-   while (ddbreadl(SPI_CONTROL) & 0x0004)
-   ;
+   do {
+   val = ddbreadl(SPI_CONTROL);
+   } while (val >= 0 && val & 0x0004);
 
data = ddbreadl(SPI_DATA);
ddbwritel(0, SPI_CONTROL);
-- 
2.5.0

--
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/6] [media] mantis: check for errors on readl inside loop

2016-03-06 Thread Mauro Carvalho Chehab 
As warned by smatch:
drivers/media/pci/mantis/mantis_uart.c:105 mantis_uart_work() warn: 
this loop depends on readl() succeeding

If readl() fails, this could lead into an endless loop. Avoid that.
We might instead add some timeout logic, but it readl() is
failing, then something really wrong is happening.

While here, remove two defines that are only used once.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/mantis/mantis_common.h | 7 ++-
 drivers/media/pci/mantis/mantis_uart.c   | 4 ++--
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/media/pci/mantis/mantis_common.h 
b/drivers/media/pci/mantis/mantis_common.h
index d48778a366a9..8348c5de3d18 100644
--- a/drivers/media/pci/mantis/mantis_common.h
+++ b/drivers/media/pci/mantis/mantis_common.h
@@ -54,11 +54,8 @@
}   
\
 } while(0)
 
-#define mwrite(dat, addr)  writel((dat), addr)
-#define mread(addr)readl(addr)
-
-#define mmwrite(dat, addr) mwrite((dat), (mantis->mmio + (addr)))
-#define mmread(addr)   mread(mantis->mmio + (addr))
+#define mmwrite(dat, addr) writel((dat), (mantis->mmio + (addr)))
+#define mmread(addr)   readl(mantis->mmio + (addr))
 
 #define MANTIS_TS_188  0
 #define MANTIS_TS_204  1
diff --git a/drivers/media/pci/mantis/mantis_uart.c 
b/drivers/media/pci/mantis/mantis_uart.c
index f1c96aec8c7b..95ccc34be9fd 100644
--- a/drivers/media/pci/mantis/mantis_uart.c
+++ b/drivers/media/pci/mantis/mantis_uart.c
@@ -91,7 +91,7 @@ static void mantis_uart_read(struct mantis_pci *mantis)
 static void mantis_uart_work(struct work_struct *work)
 {
struct mantis_pci *mantis = container_of(work, struct mantis_pci, 
uart_work);
-   u32 stat;
+   int stat;
 
stat = mmread(MANTIS_UART_STAT);
 
@@ -102,7 +102,7 @@ static void mantis_uart_work(struct work_struct *work)
 * MANTIS_UART_RXFIFO_DATA is only set if at least
 * config->bytes + 1 bytes are in the FIFO.
 */
-   while (stat & MANTIS_UART_RXFIFO_DATA) {
+   while ((stat >= 0) && (stat & MANTIS_UART_RXFIFO_DATA)) {
mantis_uart_read(mantis);
stat = mmread(MANTIS_UART_STAT);
}
-- 
2.5.0

--
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/6] [media] mceusb: use %*ph for small buffer dumps

2016-03-06 Thread Mauro Carvalho Chehab 
It makes the printk cleaner. As a side efect, it also fixes those smatch
warnings:
drivers/media/rc/mceusb.c:590 mceusb_dev_printdata() warn: argument 6 
to %02x specifier has type 'char'
drivers/media/rc/mceusb.c:590 mceusb_dev_printdata() warn: argument 7 
to %02x specifier has type 'char'

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/rc/mceusb.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 2cdb740cde48..35155ae500c7 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -587,9 +587,8 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir, 
char *buf,
if (len == 2)
dev_dbg(dev, "Get hw/sw rev?");
else
-   dev_dbg(dev, "hw/sw rev 0x%02x 0x%02x 0x%02x 
0x%02x",
-data1, data2,
-buf[start + 4], buf[start + 5]);
+   dev_dbg(dev, "hw/sw rev %*ph",
+   4, [start + 2]);
break;
case MCE_CMD_RESUME:
dev_dbg(dev, "Device resume requested");
-- 
2.5.0

--
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/6] [media] touptek: cast char types on %x printk

2016-03-06 Thread Mauro Carvalho Chehab 
This fixes those two smatch warnings:
drivers/media/usb/gspca/touptek.c:206 val_reply() warn: argument 3 to 
%02x specifier has type 'char'
drivers/media/usb/gspca/touptek.c:222 reg_w() warn: argument 4 to %02x 
specifier has type 'char'

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/gspca/touptek.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/gspca/touptek.c 
b/drivers/media/usb/gspca/touptek.c
index 8063b8e45ee5..b8af4370d27c 100644
--- a/drivers/media/usb/gspca/touptek.c
+++ b/drivers/media/usb/gspca/touptek.c
@@ -203,7 +203,7 @@ static int val_reply(struct gspca_dev *gspca_dev, const 
char *reply, int rc)
return -EIO;
}
if (reply[0] != 0x08) {
-   PERR("Bad reply 0x%02X", reply[0]);
+   PERR("Bad reply 0x%02x", (int)reply[0]);
return -EIO;
}
return 0;
@@ -219,7 +219,7 @@ static void reg_w(struct gspca_dev *gspca_dev, u16 value, 
u16 index)
value, index);
rc = usb_control_msg(gspca_dev->dev, usb_rcvctrlpipe(gspca_dev->dev, 0),
0x0B, 0xC0, value, index, buff, 1, 500);
-   PDEBUG(D_USBO, "rc=%d, ret={0x%02X}", rc, buff[0]);
+   PDEBUG(D_USBO, "rc=%d, ret={0x%02x}", rc, (int)buff[0]);
if (rc < 0) {
PERR("Failed reg_w(0x0B, 0xC0, 0x%04X, 0x%04X) w/ rc %d\n",
value, index, rc);
-- 
2.5.0

--
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