[PATCH] drivers/staging/media: atomisp: Removing redundant information from dev_err

2017-03-23 Thread Pushkar Jambhlekar 
Removing hardcoded function name as code is already using __func__

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
index d1a609d2..a51a27b 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
@@ -64,7 +64,7 @@ struct hmm_buffer_object *__bo_alloc(struct kmem_cache 
*bo_cache)
 
bo = kmem_cache_alloc(bo_cache, GFP_KERNEL);
if (!bo)
-   dev_err(atomisp_dev, "%s: __bo_alloc failed!\n", __func__);
+   dev_err(atomisp_dev, "%s: failed!\n", __func__);
 
return bo;
 }
-- 
2.7.4

cron job: media_tree daily build: ERRORS

2017-03-23 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:   Fri Mar 24 05:00:19 CET 2017
media-tree git hash:8bc4793bd083158bd266157e85ea4762577a5be6
media_build git hash:   bc4c2a205c087c8deff3cd14ed663c4767dd2016
v4l-utils git hash: 5fe0692261996876dceedbd47f254691371d4c78
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.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: 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: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
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: OK
linux-4.9-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
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-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH v2] media: platform: rcar_imr: add IMR-LSX3 support

2017-03-23 Thread Rob Herring 
On Thu, Mar 16, 2017 at 09:59:50PM +0300, Sergei Shtylyov wrote:
> Add support for the image renderer light SRAM extended 3 (IMR-LSX3) found
> only in the R-Car V2H (R8A7792) SoC.  It differs  from IMR-LX4 in that it
> supports only planar video formats but can use the video capture data for
> the textures.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> This patch  is against the 'media_tree.git' repo's 'master' branch plus the
> latest version of  the Renesas IMR driver...
> 
> Changes in version 2:
> - renamed *enum* 'imr_gen' to 'imr_type' and the *struct* field of this type
>   from 'gen' to 'type';
> - rename *struct* 'imr_type' to 'imr_info' and the fields/variables of this 
> type
>   from 'type' to 'info';
> - added comments to IMR-LX4 only CMRCR2 bits;
> - added IMR type check to the WTS instruction writing to CMRCCR2.
> 
>  Documentation/devicetree/bindings/media/rcar_imr.txt |   11 +

Acked-by: Rob Herring 

>  drivers/media/platform/rcar_imr.c|  106 
> +++
>  2 files changed, 97 insertions(+), 20 deletions(-)

JVC camera and Hauppauge PVR-150 framegrabber.

2017-03-23 Thread peter 
With a manual setting of the device path and ID, the V4L2 Test Bench 
produced this image from a JVC TK-1070U camera on a microscope.  
http://easthope.ca/JVCtoPVR150screen.jpg

Setting the device in the Test Bench each time it is opened becomes 
tedious and no /etc/*v4l* exists.  Can the default configuration be 
adjusted permanently without recompiling?  How?

Although too dark, the image from the microscope slide is faintly 
visible. The upper half of the image is on the bottom of the screen 
and the lower half is at the top.  On a VCR I might try adjusting 
vertical sync.  Is there an equivalent in the Test Bench?

Thanks,   ... Peter E. 
-- 

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202  Pender Is.: +1 250 629 3757
http://easthope.ca/Peter.html  Bcc: peter at easthope. ca

[PATCH] [media] vb2: Fix queue_setup() callback description

2017-03-23 Thread Anton Leontiev 
Correct meaning of the last sensence by swapping it with previous.
Fix two small typos.

Signed-off-by: Anton Leontiev 
---
 include/media/videobuf2-core.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index ac5898a55fd9..cb97c224be73 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -305,16 +305,16 @@ struct vb2_buffer {
  * buffer in \*num_planes, the size of each plane should be
  * set in the sizes\[\] array and optional per-plane
  * allocator specific device in the alloc_devs\[\] array.
- * When called from VIDIOC_REQBUFS,() \*num_planes == 0,
+ * When called from VIDIOC_REQBUFS(), \*num_planes == 0,
  * the driver has to use the currently configured format to
  * determine the plane sizes and \*num_buffers is the total
  * number of buffers that are being allocated. When called
- * from VIDIOC_CREATE_BUFS,() \*num_planes != 0 and it
+ * from VIDIOC_CREATE_BUFS(), \*num_planes != 0 and it
  * describes the requested number of planes and sizes\[\]
- * contains the requested plane sizes. If either
- * \*num_planes or the requested sizes are invalid callback
- * must return %-EINVAL. In this case \*num_buffers are
- * being allocated additionally to q->num_buffers.
+ * contains the requested plane sizes. In this case
+ * \*num_buffers are being allocated additionally to
+ * q->num_buffers. If either \*num_planes or the requested
+ * sizes are invalid callback must return %-EINVAL.
  * @wait_prepare:  release any locks taken while calling vb2 functions;
  * it is called before an ioctl needs to wait for a new
  * buffer to arrive; required to avoid a deadlock in
-- 
2.12.0

Re: [PATCH 2/2] em28xx: simplify ID-reading from Micron sensors

2017-03-23 Thread Frank Schäfer 



Am 23.03.2017 um 13:56 schrieb Mauro Carvalho Chehab:

Em Thu, 23 Mar 2017 13:01:32 +0100
Frank Schäfer  escreveu:


Am 22.03.2017 um 15:46 schrieb Mauro Carvalho Chehab:

Em Sun, 19 Feb 2017 19:29:18 +0100
Frank Schäfer  escreveu:
  

Use i2c_smbus_read_word_data() instead of i2c_master_send() and
i2c_master_recv() for reading the ID of Micorn sensors.
Bytes need to be swapped afterwards, because i2c_smbus_read_word_data()
assumes that the received bytes are little-endian byte order (as specified
by smbus), while Micron sensors with 16 bit register width use big endian
byte order.

Signed-off-by: Frank Schäfer 
---
   drivers/media/usb/em28xx/em28xx-camera.c | 28 
   1 file changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
b/drivers/media/usb/em28xx/em28xx-camera.c
index 7b4129ab1cf9..4839479624e7 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -106,8 +106,6 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
   {
int ret, i;
char *name;
-   u8 reg;
-   __be16 id_be;
u16 id;
   
   	struct i2c_client *client = >i2c_client[dev->def_i2c_bus];

@@ -115,10 +113,8 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
dev->em28xx_sensor = EM28XX_NOSENSOR;
for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END; i++) {
client->addr = micron_sensor_addrs[i];
-   /* NOTE: i2c_smbus_read_word_data() doesn't work with BE data */
/* Read chip ID from register 0x00 */
-   reg = 0x00;
-   ret = i2c_master_send(client, , 1);
+   ret = i2c_smbus_read_word_data(client, 0x00); /* assumes LE */
if (ret < 0) {
if (ret != -ENXIO)
dev_err(>intf->dev,
@@ -126,24 +122,9 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
   client->addr << 1, ret);
continue;
}
-   ret = i2c_master_recv(client, (u8 *)_be, 2);
-   if (ret < 0) {
-   dev_err(>intf->dev,
-   "couldn't read from i2c device 0x%02x: error 
%i\n",
-   client->addr << 1, ret);
-   continue;
-   }
-   id = be16_to_cpu(id_be);
+   id = swab16(ret); /* LE -> BE */

That's wrong! You can't assume that CPU is BE, as some archs use LE.

You should, instead, call le16_to_cpu(), to be sure that it will be
doing the right thing.

Something like:

id = le16_to_cpu((__le16)ret);

SMBus read/write word transfers are always LE (see SMBus spec section
6.5.5),
which is also what i2c_smbus_xfer_emulated() assumes:
http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L3485

I got that part, but, if the CPU is also LE, doing swab16() is
wrong. It should swap it *only* if the CPU is BE.
No, it should always be swapped, because the bytes are always transfered 
in the wrong order.

The cpu endianess doesn't matter, (0x12 << 8) | 0x34 is always 0x1234.

Regards,
Frank




le16_to_cpu() should do the right thing, e. g. swap for BE
CPUs or not swap otherwise.

Thanks,
Mauro

Re: [PATCH] staging: media: atomisp: fix build error

2017-03-23 Thread Alan Cox 
On Thu, 2017-03-23 at 21:12 +0800, Geliang Tang wrote:
> Fix the following build error:
> 
>   CC  drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o
> drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2:
>  error: excess elements in array initializer [-Werror]
>   "i", /* ion */
>   ^~~

NAK

I've sent a patch to sort this out properly we shouldn't be using
string arrays for single char values to start with...

Alan

Re: [PATCH] staging: media: atomisp: use kvmalloc and kvfree

2017-03-23 Thread Greg Kroah-Hartman 
On Thu, Mar 23, 2017 at 09:12:39PM +0800, Geliang Tang wrote:
> Use kvmalloc() and kvfree() instead of open-coding.

These functions are not in Linus's tree, so I can't apply this patch
without breaking things :(

thanks,

greg k-h

Re: [PATCH v2] staging: radio-bcm2048: fixed bare use of unsigned int

2017-03-23 Thread Greg Kroah-Hartman 
On Wed, Mar 22, 2017 at 01:33:39PM +1100, Eddie Youseph wrote:
> Fixed checkpatch WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> 
> Signed-off-by: Eddie Youseph 
> ---
> Changes in v2:
>   - Added changelog

Did you actually build this change?

Please do so...

thanks,

greg k-h

Re: Updates, autofocus, 5Mpix mode on N900? Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

2017-03-23 Thread Pavel Machek 
Hi!

> > Plus I have played with v4l-utils, and managed to implement autofocus
> > and autoexposure -- it was easier than expected. I believe you
> > mentioned you had some patches to automatically initialize the
> > pipeline. Do you and can I have them?
> 
> It was an early prototype and it wasn't really functional yet.
> 
> Given a video node, it can find possible pipelines to the image sources with
> common formats. I.e. the ccdc -> rsz path is not available for raw
> cameras.

> C (especially without helper libraries) wasn't particularly suitable for the
> task, the data structures I had didn't end up too nice. What would also be
> necessary is to associate library or application specific data to entities,
> this could be as simple as key-value pairs with both key and value being
> pointers.

Could I get a copy, anyway? Need not be perfect, but starting point
would be welcome.

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] staging: media: atomisp: use kvmalloc and kvfree

2017-03-23 Thread Geliang Tang 
Use kvmalloc() and kvfree() instead of open-coding.

Signed-off-by: Geliang Tang 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 94bc793..c7b9320 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -90,10 +90,7 @@ union host {
 void *atomisp_kernel_malloc(size_t bytes)
 {
/* vmalloc() is preferable if allocating more than 1 page */
-   if (bytes > PAGE_SIZE)
-   return vmalloc(bytes);
-
-   return kmalloc(bytes, GFP_KERNEL);
+   return kvmalloc(bytes, GFP_KERNEL);
 }
 
 /*
@@ -118,10 +115,7 @@ void *atomisp_kernel_zalloc(size_t bytes, bool zero_mem)
 void atomisp_kernel_free(void *ptr)
 {
/* Verify if buffer was allocated by vmalloc() or kmalloc() */
-   if (is_vmalloc_addr(ptr))
-   vfree(ptr);
-   else
-   kfree(ptr);
+   kvfree(ptr);
 }
 
 /*
-- 
2.9.3

[PATCH] staging: media: atomisp: fix build error

2017-03-23 Thread Geliang Tang 
Fix the following build error:

  CC  drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2:
 error: excess elements in array initializer [-Werror]
  "i", /* ion */
  ^~~
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2:
 note: (near initialization for ‘hmm_bo_type_strings’)
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target
'drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o' failed

Signed-off-by: Geliang Tang 
---
 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index a362b49..e78f02f 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -49,7 +49,9 @@ const char *hmm_bo_type_strings[HMM_BO_LAST] = {
"p", /* private */
"s", /* shared */
"u", /* user */
+#ifdef CONFIG_ION
"i", /* ion */
+#endif
 };
 
 static ssize_t bo_show(struct device *dev, struct device_attribute *attr,
-- 
2.9.3

Re: [PATCH 2/2] em28xx: simplify ID-reading from Micron sensors

2017-03-23 Thread Mauro Carvalho Chehab 
Em Thu, 23 Mar 2017 13:01:32 +0100
Frank Schäfer  escreveu:

> Am 22.03.2017 um 15:46 schrieb Mauro Carvalho Chehab:
> > Em Sun, 19 Feb 2017 19:29:18 +0100
> > Frank Schäfer  escreveu:
> >  
> >> Use i2c_smbus_read_word_data() instead of i2c_master_send() and
> >> i2c_master_recv() for reading the ID of Micorn sensors.
> >> Bytes need to be swapped afterwards, because i2c_smbus_read_word_data()
> >> assumes that the received bytes are little-endian byte order (as specified
> >> by smbus), while Micron sensors with 16 bit register width use big endian
> >> byte order.
> >>
> >> Signed-off-by: Frank Schäfer 
> >> ---
> >>   drivers/media/usb/em28xx/em28xx-camera.c | 28 
> >> 
> >>   1 file changed, 4 insertions(+), 24 deletions(-)
> >>
> >> diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
> >> b/drivers/media/usb/em28xx/em28xx-camera.c
> >> index 7b4129ab1cf9..4839479624e7 100644
> >> --- a/drivers/media/usb/em28xx/em28xx-camera.c
> >> +++ b/drivers/media/usb/em28xx/em28xx-camera.c
> >> @@ -106,8 +106,6 @@ static int em28xx_probe_sensor_micron(struct em28xx 
> >> *dev)
> >>   {
> >>int ret, i;
> >>char *name;
> >> -  u8 reg;
> >> -  __be16 id_be;
> >>u16 id;
> >>   
> >>struct i2c_client *client = >i2c_client[dev->def_i2c_bus];
> >> @@ -115,10 +113,8 @@ static int em28xx_probe_sensor_micron(struct em28xx 
> >> *dev)
> >>dev->em28xx_sensor = EM28XX_NOSENSOR;
> >>for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END; i++) {
> >>client->addr = micron_sensor_addrs[i];
> >> -  /* NOTE: i2c_smbus_read_word_data() doesn't work with BE data */
> >>/* Read chip ID from register 0x00 */
> >> -  reg = 0x00;
> >> -  ret = i2c_master_send(client, , 1);
> >> +  ret = i2c_smbus_read_word_data(client, 0x00); /* assumes LE */
> >>if (ret < 0) {
> >>if (ret != -ENXIO)
> >>dev_err(>intf->dev,
> >> @@ -126,24 +122,9 @@ static int em28xx_probe_sensor_micron(struct em28xx 
> >> *dev)
> >>   client->addr << 1, ret);
> >>continue;
> >>}
> >> -  ret = i2c_master_recv(client, (u8 *)_be, 2);
> >> -  if (ret < 0) {
> >> -  dev_err(>intf->dev,
> >> -  "couldn't read from i2c device 0x%02x: error 
> >> %i\n",
> >> -  client->addr << 1, ret);
> >> -  continue;
> >> -  }
> >> -  id = be16_to_cpu(id_be);
> >> +  id = swab16(ret); /* LE -> BE */  
> > That's wrong! You can't assume that CPU is BE, as some archs use LE.
> >
> > You should, instead, call le16_to_cpu(), to be sure that it will be
> > doing the right thing.
> >
> > Something like:
> >
> > id = le16_to_cpu((__le16)ret);  
> 
> SMBus read/write word transfers are always LE (see SMBus spec section 
> 6.5.5),
> which is also what i2c_smbus_xfer_emulated() assumes:
> http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L3485

I got that part, but, if the CPU is also LE, doing swab16() is
wrong. It should swap it *only* if the CPU is BE.

le16_to_cpu() should do the right thing, e. g. swap for BE
CPUs or not swap otherwise.

Thanks,
Mauro

Re: [PATCH 2/2] em28xx: simplify ID-reading from Micron sensors

2017-03-23 Thread Frank Schäfer 



Am 22.03.2017 um 15:46 schrieb Mauro Carvalho Chehab:

Em Sun, 19 Feb 2017 19:29:18 +0100
Frank Schäfer  escreveu:


Use i2c_smbus_read_word_data() instead of i2c_master_send() and
i2c_master_recv() for reading the ID of Micorn sensors.
Bytes need to be swapped afterwards, because i2c_smbus_read_word_data()
assumes that the received bytes are little-endian byte order (as specified
by smbus), while Micron sensors with 16 bit register width use big endian
byte order.

Signed-off-by: Frank Schäfer 
---
  drivers/media/usb/em28xx/em28xx-camera.c | 28 
  1 file changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
b/drivers/media/usb/em28xx/em28xx-camera.c
index 7b4129ab1cf9..4839479624e7 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -106,8 +106,6 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
  {
int ret, i;
char *name;
-   u8 reg;
-   __be16 id_be;
u16 id;
  
  	struct i2c_client *client = >i2c_client[dev->def_i2c_bus];

@@ -115,10 +113,8 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
dev->em28xx_sensor = EM28XX_NOSENSOR;
for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END; i++) {
client->addr = micron_sensor_addrs[i];
-   /* NOTE: i2c_smbus_read_word_data() doesn't work with BE data */
/* Read chip ID from register 0x00 */
-   reg = 0x00;
-   ret = i2c_master_send(client, , 1);
+   ret = i2c_smbus_read_word_data(client, 0x00); /* assumes LE */
if (ret < 0) {
if (ret != -ENXIO)
dev_err(>intf->dev,
@@ -126,24 +122,9 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
   client->addr << 1, ret);
continue;
}
-   ret = i2c_master_recv(client, (u8 *)_be, 2);
-   if (ret < 0) {
-   dev_err(>intf->dev,
-   "couldn't read from i2c device 0x%02x: error 
%i\n",
-   client->addr << 1, ret);
-   continue;
-   }
-   id = be16_to_cpu(id_be);
+   id = swab16(ret); /* LE -> BE */

That's wrong! You can't assume that CPU is BE, as some archs use LE.

You should, instead, call le16_to_cpu(), to be sure that it will be
doing the right thing.

Something like:

id = le16_to_cpu((__le16)ret);


SMBus read/write word transfers are always LE (see SMBus spec section 
6.5.5),

which is also what i2c_smbus_xfer_emulated() assumes:
http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L3485

Regards,
Frank



Regards,

Thanks,
Mauro

[PATCH] [media] coda: remove redundant call to v4l2_m2m_get_vq

2017-03-23 Thread Colin King 
From: Colin Ian King 

The call to v4ls_m2m_get_vq is only used to get the return value
which is not being used, so it appears to be redundant and can
be removed.

Detected with CoverityScan, CID#1420674 ("Useless call")

Signed-off-by: Colin Ian King 
---
 drivers/media/platform/coda/coda-common.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 800d2477f1a0..95e4648f18e6 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -817,8 +817,6 @@ static int coda_qbuf(struct file *file, void *priv,
 static bool coda_buf_is_end_of_stream(struct coda_ctx *ctx,
  struct vb2_v4l2_buffer *buf)
 {
-   v4l2_m2m_get_vq(ctx->fh.m2m_ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
-
return ((ctx->bit_stream_param & CODA_BIT_STREAM_END_FLAG) &&
(buf->sequence == (ctx->qsequence - 1)));
 }
-- 
2.11.0

Re: [PATCH 0/3] staging: media: Replace a bit shift.

2017-03-23 Thread Chris Moore 

Hi,

Le 22/03/2017 à 05:26, Arushi Singhal a écrit :

Replace a bit shift by a use of BIT in media driver.

Arushi Singhal (3):
   staging: media: Replace a bit shift by a use of BIT.
   staging: media: davinci_vpfe: Replace a bit shift by a use of BIT.
   staging: media: omap4iss: Replace a bit shift by a use of BIT.

  .../media/atomisp/pci/atomisp2/atomisp_cmd.c   | 12 +-
  .../atomisp/pci/atomisp2/atomisp_compat_css20.c|  6 ++---
  .../media/atomisp/pci/atomisp2/atomisp_drvfs.c |  6 ++---
  .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  | 18 +++
  .../media/atomisp/pci/atomisp2/hmm/hmm_bo.c|  2 +-
  drivers/staging/media/davinci_vpfe/dm365_ipipe.c   |  2 +-
  drivers/staging/media/davinci_vpfe/dm365_ipipeif.c |  2 +-
  drivers/staging/media/davinci_vpfe/dm365_isif.c| 26 +++---
  drivers/staging/media/davinci_vpfe/dm365_resizer.c |  6 ++---
  drivers/staging/media/omap4iss/iss_csi2.c  |  2 +-
  drivers/staging/media/omap4iss/iss_ipipe.c |  2 +-
  drivers/staging/media/omap4iss/iss_ipipeif.c   |  2 +-
  drivers/staging/media/omap4iss/iss_resizer.c   |  2 +-
  13 files changed, 44 insertions(+), 44 deletions(-)



Most of these replacements add redundant parentheses around the BIT macro.
IMHO this makes the code less readable.
So I suggest (BIT(c)) -> BIT(c).

Cheers,
Chris

cron job: media_tree daily build: ERRORS

2017-03-23 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:   Thu Mar 23 05:00:15 CET 2017
media-tree git hash:db0f4691d9749d5dd758b8636290cec8fd88aa26
media_build git hash:   bc4c2a205c087c8deff3cd14ed663c4767dd2016
v4l-utils git hash: 5fe0692261996876dceedbd47f254691371d4c78
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.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: 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: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
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: OK
linux-4.9-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
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-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: Updates, autofocus, 5Mpix mode on N900? Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

2017-03-23 Thread Sakari Ailus 
Hi Pavel,

On Thu, Mar 23, 2017 at 12:46:51AM +0100, Pavel Machek wrote:
> On Tue 2017-02-28 16:16:21, Sakari Ailus wrote:
> > On Tue, Feb 28, 2017 at 03:09:21PM +0100, Pavel Machek wrote:
> > > Can I get you to apply this one? :-).
> > 
> > Let me try to understand again what does that change actually do. I'll find
> > the time during the rest of this week.
> > 
> > I'm starting to think we need a test suite for the PLL calculator...
> 
> Any update here or on the other patch? We are quite close to working
> camera now...

I've been working on PLL test cases. The PLL calculator really requires that
to be able to test any changes made to it.

> 
> Plus I have played with v4l-utils, and managed to implement autofocus
> and autoexposure -- it was easier than expected. I believe you
> mentioned you had some patches to automatically initialize the
> pipeline. Do you and can I have them?

It was an early prototype and it wasn't really functional yet.

Given a video node, it can find possible pipelines to the image sources with
common formats. I.e. the ccdc -> rsz path is not available for raw cameras.

C (especially without helper libraries) wasn't particularly suitable for the
task, the data structures I had didn't end up too nice. What would also be
necessary is to associate library or application specific data to entities,
this could be as simple as key-value pairs with both key and value being
pointers.

> 
> Last thing.. Is someone able to compute new modes for et8ek8? I
> believe smaller than 640x480 mode would be useful for video streaming,
> and I still can't get 5MPix mode to work; understanding what goes on
> there would be useful.

Unfortunately the et8ek8 does not conform to a standard such as SMIA. :-(
I'm not sure the datasheet provides enough information to come up with new
mode definitions. Perhaps with some experimentation it could be possible.
There are a few additional embedded documents in it, those are worth
checking out. LibreOffice can open them AFAIR.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk