cron job: media_tree daily build: ERRORS

2017-03-15 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 16 05:00:15 CET 2017
media-tree git hash:700ea5e0e0dd70420a04e703ff264cc133834cba
media_build git hash:   bc4c2a205c087c8deff3cd14ed663c4767dd2016
v4l-utils git hash: ca6a0c099399cc51ecfacff7ef938be6ef73b8b3
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: [PATCH v3 4/7] macintosh: Only descend into directory when CONFIG_MACINTOSH_DRIVERS is set

2017-03-15 Thread Michael Ellerman 
"Andrew F. Davis"  writes:

> When CONFIG_MACINTOSH_DRIVERS is not set make will still descend into the
> macintosh directory but nothing will be built. This produces unneeded
> build artifacts and messages in addition to slowing the build.
> Fix this here.
>
> Signed-off-by: Andrew F. Davis 
> ---
>  drivers/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM.

Acked-by: Michael Ellerman 

cheersj

Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

2017-03-15 Thread Michael Zoran 
On Wed, 2017-03-15 at 22:08 -0300, Mauro Carvalho Chehab wrote:

> No, I didn't. Thanks! Applied it but, unfortunately, didn't work.
> Perhaps I'm missing some other patch. I'm compiling it from
> the Greg's staging tree (branch staging-next):
>   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.
> git/log/?h=staging-next
> 
> Btw, as I'm running Raspbian, and didn't want to use compat32 bits, 
> I'm compiling the Kernel as an arm32 bits Kernel.
> 
> I did a small trick to build the DTB on arm32:
> 
>   ln -sf ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
> arch/arm/boot/dts/bcm2837-rpi-3-b.dts
>   ln -sf ../../../arm64/boot/dts/broadcom/bcm2837.dtsi
> arch/arm/boot/dts/bcm2837.dtsi
>   git checkout arch/arm/boot/dts/Makefile
>   sed "s,bcm2835-rpi-zero.dtb,bcm2835-rpi-zero.dtb bcm2837-rpi-3-
> b.dtb," a && mv a arch/arm/boot/dts/Makefile
> 

Two other hacks are currently needed to get the camera to work:

1. Add this to config.txt(This required to get the firmware to detect
the camera)

start_x=1
gpu_mem=128

2. VC4 is incompatible with the firmware at this time, so you need 
to presently munge the build configuration. What you do is leave
simplefb in the build config(I'm assuming you already have that), but
you will need to remove VC4 from the config.

The firmware currently adds a node for a simplefb for debugging
purposes to show the boot log.  Surprisingly, this is still good enough
for basic usage and testing.  

The only remaining issue is that since simplefb is intented for
debugging, you wan't be able to use many of the RPI specific
applications.  

I've been using cheese and ffmpeg to test the camera which are not RPI
specific.

Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

2017-03-15 Thread Mauro Carvalho Chehab 
Em Wed, 15 Mar 2017 15:01:29 -0700
Eric Anholt  escreveu:

> Mauro Carvalho Chehab  writes:
> 
> > Em Fri, 27 Jan 2017 13:54:57 -0800
> > Eric Anholt  escreveu:
> >  
> >> Here's my first pass at importing the camera driver.  There's a bunch
> >> of TODO left to it, most of which is documented, and the rest being
> >> standard checkpatch fare.
> >> 
> >> Unfortunately, when I try modprobing it on my pi3, the USB network
> >> device dies, consistently.  I'm not sure what's going on here yet, but
> >> I'm going to keep working on some debug of it.  I've unfortunately
> >> changed a lot of variables (pi3 vs pi2, upstream vs downstream, vchi's
> >> updates while in staging, 4.9 vs 4.4), so I probably won't figure it
> >> out today.
> >> 
> >> Note that the "Update the driver to the current VCHI API" patch will
> >> conflict with the outstanding "Add vchi_queue_kernel_message and
> >> vchi_queue_user_message" series, but the fix should be pretty obvious
> >> when that lands.
> >> 
> >> I built this against 4.10-rc1, but a merge with staging-next was clean
> >> and still built fine.  
> >
> > I'm trying it, building from the linux-next branch of the staging
> > tree. No joy.
> >
> > That's what happens when I modprobe it:
> >
> > [  991.841549] bcm2835_v4l2: module is from the staging directory, the 
> > quality is unknown, you have been warned.
> > [  991.842931] vchiq_get_state: g_state.remote == NULL
> > [  991.843437] vchiq_get_state: g_state.remote == NULL
> > [  991.843940] vchiq_get_state: g_state.remote == NULL
> > [  991.84] vchiq_get_state: g_state.remote == NULL
> > [  991.844947] vchiq_get_state: g_state.remote == NULL
> > [  991.845451] vchiq_get_state: g_state.remote == NULL
> > [  991.845954] vchiq_get_state: g_state.remote == NULL
> > [  991.846457] vchiq_get_state: g_state.remote == NULL
> > [  991.846961] vchiq_get_state: g_state.remote == NULL
> > [  991.847464] vchiq_get_state: g_state.remote == NULL
> > [  991.847969] vchiq: vchiq_initialise: videocore not initialized
> >
> > [  991.847973] mmal_vchiq: Failed to initialise VCHI instance (status=-1)  
> 
> Yeah, this failure mode sucks.  I'm guessing you don't have a VCHI node
> in the DT?  Patch attached.

No, I didn't. Thanks! Applied it but, unfortunately, didn't work.
Perhaps I'm missing some other patch. I'm compiling it from
the Greg's staging tree (branch staging-next):

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/log/?h=staging-next

Btw, as I'm running Raspbian, and didn't want to use compat32 bits, 
I'm compiling the Kernel as an arm32 bits Kernel.

I did a small trick to build the DTB on arm32:

ln -sf ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts 
arch/arm/boot/dts/bcm2837-rpi-3-b.dts
ln -sf ../../../arm64/boot/dts/broadcom/bcm2837.dtsi 
arch/arm/boot/dts/bcm2837.dtsi
git checkout arch/arm/boot/dts/Makefile
sed "s,bcm2835-rpi-zero.dtb,bcm2835-rpi-zero.dtb bcm2837-rpi-3-b.dtb," 
a && mv a arch/arm/boot/dts/Makefile

> I haven't followed up on getting the DT documented so that it can be
> merged, and it sounds like Michael has some plans for changing how VCHI
> and VCHI's consumers get attached to each other so that it's not
> DT-based anyway.

I see.

> 
> From 9488974b836b1fba7d32af34d612151872f9ce0d Mon Sep 17 00:00:00 2001
> From: Eric Anholt 
> Date: Mon, 3 Oct 2016 11:23:34 -0700
> Subject: [PATCH] ARM: bcm2835: Add VCHIQ to the DT.
> 
> Signed-off-by: Eric Anholt 
> ---
>  arch/arm/boot/dts/bcm2835-rpi.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
> b/arch/arm/boot/dts/bcm2835-rpi.dtsi
> index caf2707680c1..f5fb5c5aa07a 100644
> --- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
> +++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
> @@ -26,6 +26,14 @@
>   firmware = <>;
>   #power-domain-cells = <1>;
>   };
> +
> + vchiq {
> + compatible = "brcm,bcm2835-vchiq";
> + reg = <0x7e00b840 0xf>;
> + interrupts = <0 2>;
> + cache-line-size = <32>;
> + firmware = <>;
> + };
>   };
>  };
>  



Thanks,
Mauro


pgpeW9mILB_ph.pgp
Description: Assinatura digital OpenPGP

[PATCH 3/3] [media] af9035: add Logilink vg0022a to device id table

2017-03-15 Thread Andreas Kemnade 
Ths adds the logilink VG00022a dvb-t dongle to the device table.
The dongle contains (checked by removing the case)
IT9303
SI2168
  214730

Signed-off-by: Andreas Kemnade 
---
 drivers/media/usb/dvb-usb-v2/af9035.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c 
b/drivers/media/usb/dvb-usb-v2/af9035.c
index a95f4b2..db93e59 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -2165,6 +2165,8 @@ static const struct usb_device_id af9035_id_table[] = {
/* IT930x devices */
{ DVB_USB_DEVICE(USB_VID_ITETECH, USB_PID_ITETECH_IT9303,
_props, "ITE 9303 Generic", NULL) },
+   { DVB_USB_DEVICE(USB_VID_DEXATEK, 0x0100,
+   _props, "Logilink VG0022A", NULL) },
{ }
 };
 MODULE_DEVICE_TABLE(usb, af9035_id_table);
-- 
2.1.4

[PATCH 1/3] [media] si2157: get chip id during probing

2017-03-15 Thread Andreas Kemnade 
If the si2157 is behind a e.g. si2168, the si2157 will
at least in some situations not be readable after the si268
got the command 0101. It still accepts commands but the answer
is just ff. So read the chip id before that so the
information is not lost.

The following line in kernel output is a symptome
of that problem:
si2157 7-0063: unknown chip version Si21255-\x\x\x

Signed-off-by: Andreas Kemnade 
---
 drivers/media/tuners/si2157.c  | 54 ++
 drivers/media/tuners/si2157_priv.h |  7 +
 2 files changed, 39 insertions(+), 22 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 57b2508..0da7a33 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -84,7 +84,7 @@ static int si2157_init(struct dvb_frontend *fe)
struct si2157_cmd cmd;
const struct firmware *fw;
const char *fw_name;
-   unsigned int uitmp, chip_id;
+   unsigned int uitmp;
 
dev_dbg(>dev, "\n");
 
@@ -115,24 +115,7 @@ static int si2157_init(struct dvb_frontend *fe)
if (ret)
goto err;
 
-   /* query chip revision */
-   memcpy(cmd.args, "\x02", 1);
-   cmd.wlen = 1;
-   cmd.rlen = 13;
-   ret = si2157_cmd_execute(client, );
-   if (ret)
-   goto err;
-
-   chip_id = cmd.args[1] << 24 | cmd.args[2] << 16 | cmd.args[3] << 8 |
-   cmd.args[4] << 0;
-
-   #define SI2158_A20 ('A' << 24 | 58 << 16 | '2' << 8 | '0' << 0)
-   #define SI2148_A20 ('A' << 24 | 48 << 16 | '2' << 8 | '0' << 0)
-   #define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
-   #define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
-   #define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
-
-   switch (chip_id) {
+   switch (dev->chip_id) {
case SI2158_A20:
case SI2148_A20:
fw_name = SI2158_A20_FIRMWARE;
@@ -150,9 +133,6 @@ static int si2157_init(struct dvb_frontend *fe)
goto err;
}
 
-   dev_info(>dev, "found a 'Silicon Labs Si21%d-%c%c%c'\n",
-   cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
-
if (fw_name == NULL)
goto skip_fw_download;
 
@@ -444,6 +424,36 @@ static int si2157_probe(struct i2c_client *client,
 
memcpy(>ops.tuner_ops, _ops, sizeof(struct dvb_tuner_ops));
fe->tuner_priv = client;
+   /* power up */
+   if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
+   memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
+   cmd.wlen = 9;
+   } else {
+   memcpy(cmd.args,
+   "\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01",
+   15);
+   cmd.wlen = 15;
+   }
+   cmd.rlen = 1;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+   /* query chip revision */
+   /* hack: do it here because after the si2168 gets 0101, commands will
+* still be executed here but no result
+*/
+   memcpy(cmd.args, "\x02", 1);
+   cmd.wlen = 1;
+   cmd.rlen = 13;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err_kfree;
+   dev->chip_id = cmd.args[1] << 24 |
+   cmd.args[2] << 16 |
+   cmd.args[3] << 8 |
+   cmd.args[4] << 0;
+   dev_info(>dev, "found a 'Silicon Labs Si21%d-%c%c%c'\n",
+   cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
 
 #ifdef CONFIG_MEDIA_CONTROLLER
if (cfg->mdev) {
diff --git a/drivers/media/tuners/si2157_priv.h 
b/drivers/media/tuners/si2157_priv.h
index d6b2c7b..54c1a856 100644
--- a/drivers/media/tuners/si2157_priv.h
+++ b/drivers/media/tuners/si2157_priv.h
@@ -30,6 +30,7 @@ struct si2157_dev {
u8 chiptype;
u8 if_port;
u32 if_frequency;
+   u32 chip_id;
struct delayed_work stat_work;
 
 #if defined(CONFIG_MEDIA_CONTROLLER)
@@ -43,6 +44,12 @@ struct si2157_dev {
 #define SI2157_CHIPTYPE_SI2157 0
 #define SI2157_CHIPTYPE_SI2146 1
 
+#define SI2158_A20 ('A' << 24 | 58 << 16 | '2' << 8 | '0' << 0)
+#define SI2148_A20 ('A' << 24 | 48 << 16 | '2' << 8 | '0' << 0)
+#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
+#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
+#define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
+
 /* firmware command struct */
 #define SI2157_ARGLEN  30
 struct si2157_cmd {
-- 
2.1.4

[PATCH 0/3] support for Logilink VG0022a DVB-T2 stick

2017-03-15 Thread Andreas Kemnade 
Hi all,
here are some patches needed for supporting the
Logilink VG0022A DVB-T2 stick.
As the combination of chips in that stick is not
uncommon, the first two patches might also fix problems
for similar hardware.

Andreas Kemnade (3):
  [media] si2157: get chip id during probing
  [media] af9035: init i2c already in it930x_frontend_attach
  [media] af9035: add Logilink vg0022a to device id table

 drivers/media/tuners/si2157.c | 54 +--
 drivers/media/tuners/si2157_priv.h|  7 +
 drivers/media/usb/dvb-usb-v2/af9035.c | 45 -
 3 files changed, 83 insertions(+), 23 deletions(-)

-- 
2.1.4

[PATCH 2/3] [media] af9035: init i2c already in it930x_frontend_attach

2017-03-15 Thread Andreas Kemnade 
i2c bus is already needed when the frontend is probed,
so init it already in it930x_frontend_attach
That prevents errors like
 si2168: probe of 6-0067 failed with error -5

Signed-off-by: Andreas Kemnade 
---
 drivers/media/usb/dvb-usb-v2/af9035.c | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c 
b/drivers/media/usb/dvb-usb-v2/af9035.c
index 4df9486..a95f4b2 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -1214,8 +1214,49 @@ static int it930x_frontend_attach(struct dvb_usb_adapter 
*adap)
struct si2168_config si2168_config;
struct i2c_adapter *adapter;
 
-   dev_dbg(>dev, "adap->id=%d\n", adap->id);
+   dev_dbg(>dev, "%s  adap->id=%d\n", __func__, adap->id);
+
+   /* I2C master bus 2 clock speed 300k */
+   ret = af9035_wr_reg(d, 0x00f6a7, 0x07);
+   if (ret < 0)
+   goto err;
+
+   /* I2C master bus 1,3 clock speed 300k */
+   ret = af9035_wr_reg(d, 0x00f103, 0x07);
+   if (ret < 0)
+   goto err;
+
+   /* set gpio11 low */
+   ret = af9035_wr_reg_mask(d, 0xd8d4, 0x01, 0x01);
+   if (ret < 0)
+   goto err;
+
+   ret = af9035_wr_reg_mask(d, 0xd8d5, 0x01, 0x01);
+   if (ret < 0)
+   goto err;
+
+   ret = af9035_wr_reg_mask(d, 0xd8d3, 0x01, 0x01);
+   if (ret < 0)
+   goto err;
 
+   /* Tuner enable using gpiot2_en, gpiot2_on and gpiot2_o (reset) */
+   ret = af9035_wr_reg_mask(d, 0xd8b8, 0x01, 0x01);
+   if (ret < 0)
+   goto err;
+
+   ret = af9035_wr_reg_mask(d, 0xd8b9, 0x01, 0x01);
+   if (ret < 0)
+   goto err;
+
+   ret = af9035_wr_reg_mask(d, 0xd8b7, 0x00, 0x01);
+   if (ret < 0)
+   goto err;
+
+   msleep(200);
+
+   ret = af9035_wr_reg_mask(d, 0xd8b7, 0x01, 0x01);
+   if (ret < 0)
+   goto err;
memset(_config, 0, sizeof(si2168_config));
si2168_config.i2c_adapter = 
si2168_config.fe = >fe[0];
-- 
2.1.4

Re: [PATCH v10 2/2] media: i2c: Add support for OV5647 sensor.

2017-03-15 Thread Sakari Ailus 
Hi Ramiro,

On Wed, Mar 15, 2017 at 04:45:16PM +, Ramiro Oliveira wrote:
> Hi Sakari
> 
> On 3/7/2017 10:45 AM, Sakari Ailus wrote:
> > Hi Ramiro,
> > 
> > On Mon, Mar 06, 2017 at 11:16:34AM +, Ramiro Oliveira wrote:
> > ...
> >> +static int __sensor_init(struct v4l2_subdev *sd)
> >> +{
> >> +  int ret;
> >> +  u8 resetval, rdval;
> >> +  struct i2c_client *client = v4l2_get_subdevdata(sd);
> >> +
> >> +  dev_dbg(>dev, "sensor init\n");
> > 
> > This looks like a debugging time leftover. Please remove.
> > 
> 
> Should I send a v11 with this change?

Please do; you can add my ack on that one.

> 
> > With that,
> > 
> > Acked-by: Sakari Ailus 
> > 
> > ...
> > 

-- 
Regards,

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

Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

2017-03-15 Thread Eric Anholt 
Mauro Carvalho Chehab  writes:

> Em Fri, 27 Jan 2017 13:54:57 -0800
> Eric Anholt  escreveu:
>
>> Here's my first pass at importing the camera driver.  There's a bunch
>> of TODO left to it, most of which is documented, and the rest being
>> standard checkpatch fare.
>> 
>> Unfortunately, when I try modprobing it on my pi3, the USB network
>> device dies, consistently.  I'm not sure what's going on here yet, but
>> I'm going to keep working on some debug of it.  I've unfortunately
>> changed a lot of variables (pi3 vs pi2, upstream vs downstream, vchi's
>> updates while in staging, 4.9 vs 4.4), so I probably won't figure it
>> out today.
>> 
>> Note that the "Update the driver to the current VCHI API" patch will
>> conflict with the outstanding "Add vchi_queue_kernel_message and
>> vchi_queue_user_message" series, but the fix should be pretty obvious
>> when that lands.
>> 
>> I built this against 4.10-rc1, but a merge with staging-next was clean
>> and still built fine.
>
> I'm trying it, building from the linux-next branch of the staging
> tree. No joy.
>
> That's what happens when I modprobe it:
>
> [  991.841549] bcm2835_v4l2: module is from the staging directory, the 
> quality is unknown, you have been warned.
> [  991.842931] vchiq_get_state: g_state.remote == NULL
> [  991.843437] vchiq_get_state: g_state.remote == NULL
> [  991.843940] vchiq_get_state: g_state.remote == NULL
> [  991.84] vchiq_get_state: g_state.remote == NULL
> [  991.844947] vchiq_get_state: g_state.remote == NULL
> [  991.845451] vchiq_get_state: g_state.remote == NULL
> [  991.845954] vchiq_get_state: g_state.remote == NULL
> [  991.846457] vchiq_get_state: g_state.remote == NULL
> [  991.846961] vchiq_get_state: g_state.remote == NULL
> [  991.847464] vchiq_get_state: g_state.remote == NULL
> [  991.847969] vchiq: vchiq_initialise: videocore not initialized
>
> [  991.847973] mmal_vchiq: Failed to initialise VCHI instance (status=-1)

Yeah, this failure mode sucks.  I'm guessing you don't have a VCHI node
in the DT?  Patch attached.

I haven't followed up on getting the DT documented so that it can be
merged, and it sounds like Michael has some plans for changing how VCHI
and VCHI's consumers get attached to each other so that it's not
DT-based anyway.

From 9488974b836b1fba7d32af34d612151872f9ce0d Mon Sep 17 00:00:00 2001
From: Eric Anholt 
Date: Mon, 3 Oct 2016 11:23:34 -0700
Subject: [PATCH] ARM: bcm2835: Add VCHIQ to the DT.

Signed-off-by: Eric Anholt 
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index caf2707680c1..f5fb5c5aa07a 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -26,6 +26,14 @@
firmware = <>;
#power-domain-cells = <1>;
};
+
+   vchiq {
+   compatible = "brcm,bcm2835-vchiq";
+   reg = <0x7e00b840 0xf>;
+   interrupts = <0 2>;
+   cache-line-size = <32>;
+   firmware = <>;
+   };
};
 };
 
-- 
2.11.0



signature.asc
Description: PGP signature

Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

2017-03-15 Thread Stefan Wahren 
Hi Mauro,

> Mauro Carvalho Chehab  hat am 15. März 2017 um 
> 15:01 geschrieben:
> 
> 
> Em Fri, 27 Jan 2017 13:54:57 -0800
> Eric Anholt  escreveu:
> 
> > Here's my first pass at importing the camera driver.  There's a bunch
> > of TODO left to it, most of which is documented, and the rest being
> > standard checkpatch fare.
> > 
> > Unfortunately, when I try modprobing it on my pi3, the USB network
> > device dies, consistently.  I'm not sure what's going on here yet, but
> > I'm going to keep working on some debug of it.  I've unfortunately
> > changed a lot of variables (pi3 vs pi2, upstream vs downstream, vchi's
> > updates while in staging, 4.9 vs 4.4), so I probably won't figure it
> > out today.
> > 
> > Note that the "Update the driver to the current VCHI API" patch will
> > conflict with the outstanding "Add vchi_queue_kernel_message and
> > vchi_queue_user_message" series, but the fix should be pretty obvious
> > when that lands.
> > 
> > I built this against 4.10-rc1, but a merge with staging-next was clean
> > and still built fine.
> 
> I'm trying it, building from the linux-next branch of the staging
> tree. No joy.
> 
> That's what happens when I modprobe it:
> 
> [  991.841549] bcm2835_v4l2: module is from the staging directory, the 
> quality is unknown, you have been warned.
> [  991.842931] vchiq_get_state: g_state.remote == NULL
> [  991.843437] vchiq_get_state: g_state.remote == NULL
> [  991.843940] vchiq_get_state: g_state.remote == NULL
> [  991.84] vchiq_get_state: g_state.remote == NULL
> [  991.844947] vchiq_get_state: g_state.remote == NULL
> [  991.845451] vchiq_get_state: g_state.remote == NULL
> [  991.845954] vchiq_get_state: g_state.remote == NULL
> [  991.846457] vchiq_get_state: g_state.remote == NULL
> [  991.846961] vchiq_get_state: g_state.remote == NULL
> [  991.847464] vchiq_get_state: g_state.remote == NULL
> [  991.847969] vchiq: vchiq_initialise: videocore not initialized
> 
> [  991.847973] mmal_vchiq: Failed to initialise VCHI instance (status=-1)
> 

only a guess, but did you add the vchiq node to the device tree?

vchiq: vchiq@7e00b840 {
compatible = "brcm,bcm2835-vchiq";
reg = <0x7e00b840 0xf>;
interrupts = <0 2>;
cache-line-size = <32>;
firmware = <>;
};

For a Raspberry Pi 3 you will need cache-line-size to be 64.

Regards
Stefan

> 
> Thanks,
> Mauro
> 
> ___
> linux-rpi-kernel mailing list
> linux-rpi-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel

Re: [PATCH v3 0/7] Remove unneeded build directory traversals

2017-03-15 Thread Arnd Bergmann 
On Wed, Mar 15, 2017 at 10:15 PM, Andrew F. Davis  wrote:
> On 03/15/2017 04:03 PM, Arnd Bergmann wrote:
>> On Wed, Mar 15, 2017 at 5:37 PM, Andrew F. Davis  wrote:
>>> Hello all,
>>>
>>> I was building a kernel for x86 and noticed Make still descended into
>>> directories like drivers/gpu/drm/hisilicon, this seems kind of odd given
>>> nothing will be built here. It looks to be due to some directories being
>>> included in obj-y unconditionally instead of only when the relevant
>>> CONFIG_ is set.
>>>
>>> These patches are split by subsystem in-case, for some reason, a file in
>>> a directory does need to be built, I believe I have checked for all
>>> instances of this, but a quick review from some maintainers would be nice.
>>
>> I didn't see anything wrong with the patches, and made sure that there
>> are no tristate symbols controlling the subdirectory for anything that
>> requires a built-in driver (which would cause a link failure).
>>
>> I'm not sure about drivers/lguest, which has some special magic
>> in its Makefile, it's possible that this now fails with CONFIG_LGUEST=m.
>>
>
> lguest and mmc are the strange ones, so I put them last in the series in
> case they did need to be dropped.
>
> lguest was supposed to have been taken from v1:
> https://lkml.org/lkml/2016/6/20/1086
> but it looks like it didn't so I re-introduced it for v3.
>
> mmc caught some 0-day build warnings but I never got to the bottom of them.

Ah, I see now what happened to mmc:

obj-$(subst m,y,$(CONFIG_MMC))  += host/
tmio_mmc_core-$(subst m,y,$(CONFIG_MMC_SDHI))   += tmio_mmc_dma.o
obj-$(subst m,y,$(CONFIG_MMC_SDHCI_PCI))+= sdhci-pci-data.o

with CONFIG_MMC=m, this will fail to build the built-in files in
drivers/mmc/host. I suppose this could be expressed in a different
way these days, but dropping the patch would be easier.

 Arnd

Re: [PATCH v3 0/7] Remove unneeded build directory traversals

2017-03-15 Thread Andrew F. Davis 
On 03/15/2017 04:03 PM, Arnd Bergmann wrote:
> On Wed, Mar 15, 2017 at 5:37 PM, Andrew F. Davis  wrote:
>> Hello all,
>>
>> I was building a kernel for x86 and noticed Make still descended into
>> directories like drivers/gpu/drm/hisilicon, this seems kind of odd given
>> nothing will be built here. It looks to be due to some directories being
>> included in obj-y unconditionally instead of only when the relevant
>> CONFIG_ is set.
>>
>> These patches are split by subsystem in-case, for some reason, a file in
>> a directory does need to be built, I believe I have checked for all
>> instances of this, but a quick review from some maintainers would be nice.
> 
> I didn't see anything wrong with the patches, and made sure that there
> are no tristate symbols controlling the subdirectory for anything that
> requires a built-in driver (which would cause a link failure).
> 
> I'm not sure about drivers/lguest, which has some special magic
> in its Makefile, it's possible that this now fails with CONFIG_LGUEST=m.
> 

lguest and mmc are the strange ones, so I put them last in the series in
case they did need to be dropped.

lguest was supposed to have been taken from v1:
https://lkml.org/lkml/2016/6/20/1086
but it looks like it didn't so I re-introduced it for v3.

mmc caught some 0-day build warnings but I never got to the bottom of them.

Anyway, I have no problem with these two being held back until the magic
in their Makefile is sorted out.

Thanks,
Andrew

>   Arnd
>

Re: [PATCH v3 0/7] Remove unneeded build directory traversals

2017-03-15 Thread Arnd Bergmann 
On Wed, Mar 15, 2017 at 5:37 PM, Andrew F. Davis  wrote:
> Hello all,
>
> I was building a kernel for x86 and noticed Make still descended into
> directories like drivers/gpu/drm/hisilicon, this seems kind of odd given
> nothing will be built here. It looks to be due to some directories being
> included in obj-y unconditionally instead of only when the relevant
> CONFIG_ is set.
>
> These patches are split by subsystem in-case, for some reason, a file in
> a directory does need to be built, I believe I have checked for all
> instances of this, but a quick review from some maintainers would be nice.

I didn't see anything wrong with the patches, and made sure that there
are no tristate symbols controlling the subdirectory for anything that
requires a built-in driver (which would cause a link failure).

I'm not sure about drivers/lguest, which has some special magic
in its Makefile, it's possible that this now fails with CONFIG_LGUEST=m.

  Arnd

Re: media / v4l2-mc: wishlist for complex cameras (was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline)

2017-03-15 Thread Mauro Carvalho Chehab 
Em Wed, 15 Mar 2017 19:04:21 +0100
Pavel Machek  escreveu:

> Hi!
> 
> > > Well, I believe first question is: what applications would we want to
> > > run on complex devices? Will sending control from video to subdevs
> > > actually help?  
> > 
> > I would say: camorama, xawtv3, zbar, google talk, skype. If it runs
> > with those, it will likely run with any other application.  
> 
> I'll take a look when I'm at better internet access.

Ok.

> > > mplayer is useful for testing... but that one already works (after you
> > > setup the pipeline, and configure exposure/gain).
> > > 
> > > But thats useful for testing, not really for production. Image will be
> > > out of focus and with wrong white balance.
> > > 
> > > What I would really like is an application to get still photos. For
> > > taking pictures with manual settings we need
> > > 
> > > a) units for controls: user wants to focus on 1m, and take picture
> > > with ISO200, 1/125 sec. We should also tell him that lens is f/5.6 and
> > > focal length is 20mm with 5mm chip.
> > > 
> > > But... autofocus/autogain would really be good to have. Thus we need:
> > > 
> > > b) for each frame, we need exposure settings and focus position at
> > > time frame was taken. Otherwise autofocus/autogain will be too
> > > slow. At least focus position is going to be tricky -- either kernel
> > > would have to compute focus position for us (not trivial) or we'd need
> > > enough information to compute it in userspace.
> > > 
> > > There are more problems: hardware-accelerated preview is not trivial
> > > to set up (and I'm unsure if it can be done in generic way). Still
> > > photos application needs to switch resolutions between preview and
> > > photo capture. Probably hardware-accelerated histograms are needed for
> > > white balance, auto gain and auto focus, 
> > > 
> > > It seems like there's a _lot_ of stuff to be done before we have
> > > useful support for complex cameras...  
> > 
> > Taking still pictures using a hardware-accelerated preview is
> > a sophisticated use case. I don't know any userspace application
> > that does that. Ok, several allow taking snapshots, by simply
> > storing the image of the current frame.  
> 
> Well, there are applications that take still pictures. Android has
> one. Maemo has another. Then there's fcam-dev. Its open source; with
> modified kernel it is fully usable. I have version that runs on recent
> nearly-mainline on N900. 

Hmm... it seems that FCam is specific for N900:
http://fcam.garage.maemo.org/

If so, then we have here just the opposite problem, if want it to be
used as a generic application, as very likely it requires OMAP3-specific
graph/subdevs.

> So yes, I'd like solution for problems a) and b).
> 
> > > (And I'm not sure... when application such as skype is running, is
> > > there some way to run autogain/autofocus/autowhitebalance? Is that
> > > something we want to support?)  
> > 
> > Autofocus no. Autogain/Autowhite can be done via libv4l, provided that
> > it can access the device's controls via /dev/video devnode. Other
> > applications may be using some other similar algorithms.
> > 
> > Ok, they don't use histograms provided by the SoC. So, they do it in
> > software, with is slower. Still, it works fine when the light
> > conditions don't change too fast.  
> 
> I guess it is going to work well enough with higher CPU
> usage.

Yes.

> Question is if camera without autofocus is usable. I'd say "not
> really".qv4l2

That actually depends on the sensor and how focus is adjusted.

I'm testing right now this camera module for RPi:
   https://www.raspberrypi.org/products/camera-module-v2/

I might be wrong, but this sensor doesn't seem to have auto-focus.
Instead, it seems to use a wide-angle lens. So, except when the
object is too close, the focus look OK.

> > > I believe other question is: will not having same control on main
> > > video device and subdevs be confusing? Does it actually help userspace
> > > in any way? Yes, we can make controls accessible to old application,
> > > but does it make them more useful?   
> > 
> > Yes. As I said, libv4l (and some apps) have logic inside to adjust
> > the image via bright, contrast and white balance controls, using the
> > video devnode. They don't talk subdev API. So, if those controls
> > aren't exported, they won't be able to provide a good quality image.  
> 
> Next question is if the libv4l will do the right thing if we just put
> all controls to one node. For example on N900 you have exposure/gain
> and brightness. But the brightness is applied at preview phase, so it
> is "basically useless". You really need to adjust the image using the
> exposure/gain.

I've no idea, but I suspect it shouldn't be hard to teach libv4l to
prefer use an exposure/gain instead of brightness when available.

> > > > > In addition, I suspect end-users of these complex devices don't 
> > > > > really care
> > > > > about a plugin: they want

Re: mainline build: 208 builds: 0 failed, 208 passed, 422 warnings (v4.11-rc2-164-gdefc7d752265)

2017-03-15 Thread Arnd Bergmann 
On Wed, Mar 15, 2017 at 6:53 PM, kernelci.org bot  wrote:
>
> mainline build: 208 builds: 0 failed, 208 passed, 422 warnings 
> (v4.11-rc2-164-gdefc7d752265)

The last build failure in mainline is gone now, though I don't know
what fixed it.
Let's hope this doesn't come back as the cause was apparently a race condition
in Kbuild that might have stopped triggering.

> Warnings summary:
> 409 :1325:2: warning: #warning syscall statx not implemented [-Wcpp]

The warning triggers for arm, arm64 and mips on every build. I saw a patch
was posted for asm-generic, which takes care of arm64.

Catalin and Will: can you take this through the arm64 tree? I don't have
anything else for asm-generic at the moment.

Russell and Ralf, do you already have patches for ARM and MIPS to
add the syscalls, or would you like me to send you patches for it?
I assume all arch maintainers will get to it eventually, but I'd like to
see this gone from the kernelci reporting.

Once the syscall number has been assigned for arch/arm, we will
also need to update the compat syscall table for arm64 of course.

> 2 include/linux/device.h:1479:15: warning: passing argument 1 of 
> 'platform_driver_unregister' discards 'const' qualifier from pointer target 
> type [-Wdiscarded-qualifiers]
> 2 include/linux/device.h:1474:20: warning: passing argument 1 of 
> '__platform_driver_register' discards 'const' qualifier from pointer target 
> type [-Wdiscarded-qualifiers]

Mauro has applied the fix in linux-next, I assume this is going to hit mainline
before v4.11-rc3.

> 1 net/wireless/nl80211.c:5743:1: warning: the frame size of 2064 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> 1 drivers/tty/vt/keyboard.c:1472:1: warning: the frame size of 2344 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]

I still have this one on my list, should be able to post an updated version
in a few days after I'm through with my backlog of older patches.

  Arnd

Re: [Patch v2 02/11] s5p-mfc: Adding initial support for MFC v10.10

2017-03-15 Thread Rob Herring 
On Fri, Mar 03, 2017 at 02:37:07PM +0530, Smitha T Murthy wrote:
> Adding the support for MFC v10.10, with new register file and
> necessary hw control, decoder, encoder and structural changes.
> 
> Signed-off-by: Smitha T Murthy 
> CC: Rob Herring 
> CC: devicet...@vger.kernel.org
> ---
>  .../devicetree/bindings/media/s5p-mfc.txt  |1 +

Acked-by: Rob Herring 

>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h  |   36 
>  drivers/media/platform/s5p-mfc/s5p_mfc.c   |   30 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h|4 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |4 ++
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |   44 
> +++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   |   21 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c|9 +++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|2 +
>  9 files changed, 118 insertions(+), 33 deletions(-)
>  create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h

Re: media / v4l2-mc: wishlist for complex cameras (was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline)

2017-03-15 Thread Nicolas Dufresne 
Le mercredi 15 mars 2017 à 11:50 +0100, Philippe De Muyter a écrit :
> > I would say: camorama, xawtv3, zbar, google talk, skype. If it runs
> > with those, it will likely run with any other application.
> > 
> 
> I would like to add the 'v4l2src' plugin of gstreamer, and on the
> imx6 its

While it would be nice if somehow you would get v4l2src to work (in
some legacy/emulation mode through libv4l2), the longer plan is to
implement smart bin that handle several v4l2src, that can do the
required interactions so we can expose similar level of controls as
found in Android Camera HAL3, and maybe even further assuming userspace
can change the media tree at run-time. We might be a long way from
there, specially that some of the features depends on how much the
hardware can do. Just being able to figure-out how to build the MC tree
dynamically seems really hard when thinking of generic mechanism. Also,
Request API will be needed.

I think for this one, we'll need some userspace driver that enable the
features (not hide them), and that's what I'd be looking for from
libv4l2 in this regard.

> imx-specific counterpart 'imxv4l2videosrc' from the gstreamer-imx
> package
> at https://github.com/Freescale/gstreamer-imx, and 'v4l2-ctl'.

This one is specific to IMX hardware using vendor driver. You can
probably ignore that.

Nicolas

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround

2017-03-15 Thread Steve Longerbeam 



On 03/10/2017 11:17 AM, Fabio Estevam wrote:

On Fri, Mar 10, 2017 at 3:59 PM, Troy Kisky
 wrote:

On 3/9/2017 8:52 PM, Steve Longerbeam wrote:

There is a pin conflict with GPIO_6. This pin functions as a power
input pin to the OV5642 camera sensor, but ENET uses it as the h/w
workaround for erratum ERR006687, to wake-up the ARM cores on normal
RX and TX packet done events. So we need to remove the h/w workaround
to support the OV5642. The result is that the CPUidle driver will no
longer allow entering the deep idle states on the sabrelite.

This is a partial revert of

commit 6261c4c8f13e ("ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC
  interrupt.")
commit a28eeb43ee57 ("ARM: dts: imx6: tag boards that have the HW workaround
  for ERR006687")

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 8413179..89dce27 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -270,9 +270,6 @@
  txd1-skew-ps = <0>;
  txd2-skew-ps = <0>;
  txd3-skew-ps = <0>;


How about

+#if !IS_ENABLED(CONFIG_VIDEO_OV5642)


Or maybe just create a new device tree for using the camera, like
imx6q-sabrelite-camera.dts.

This way we can keep the FEC erratum for the existing sabrelite dtb's.


Is it really necessary to keep the erratum in sabrelite dts? Because the
sabrelite is a _reference_ platform, vendors use this dts as a working
example of how to configure their imx6-based hardware. So as a working
example, it should contain as much example hardware config as possible
as a guide. If a vendor does not require OV5642 support and requires
the lower power consumption that the erratum workaround provides, they
can refer to other example imx6 dts files which still implement the
erratum, or look at the git log of this file.

Steve

Re: [PATCH 3/4] Documentation: dt: Add bindings documentation for CSI-2 Host Video Platform

2017-03-15 Thread Rob Herring 
On Tue, Mar 07, 2017 at 02:37:50PM +, Ramiro Oliveira wrote:
> Create device tree bindings documentation for the CSI-2 Host Video
>  platform.
> 
> Signed-off-by: Ramiro Oliveira 
> ---
>  .../devicetree/bindings/media/snps,plat-csi2.txt   | 77 
> ++
>  1 file changed, 77 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/snps,plat-csi2.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/snps,plat-csi2.txt 
> b/Documentation/devicetree/bindings/media/snps,plat-csi2.txt
> new file mode 100644
> index ..f559257a0a44
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,plat-csi2.txt
> @@ -0,0 +1,77 @@
> +Synopsys DesignWare CSI-2 Host Video Platform
> +
> +The Synopsys DesignWare CSI-2 Host Video Device subsystem comprises of 
> multiple
> +sub-devices represented by separate device tree nodes. Currently this 
> includes:
> +plat-csi2, video-device, and dw-mipi-csi.
> +
> +The sub-subdevices are defined as child nodes of the common 'camera'.
> +
> +Common 'camera' node
> +
> +
> +Required properties:
> +
> +- compatible: must be "snps,plat-csi2", "simple-bus"
> +
> +The 'camera' node must include at least one 'video-device' and one 
> 'dw-mipi-csi'
> +child node.
> +
> +'video-device' device nodes
> +---
> +
> +Required properties:
> +
> +- compatible: "snps,video-device"
> +- dmas, dma-names: List of one DMA specifier and identifier string (as 
> defined
> +  in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port
> +  requires a DMA channel with the identifier string set to "vdma" followed by
> +  the port index.
> +
> +Image sensor nodes
> +--
> +
> +The sensor device nodes should be added to their control bus controller (e.g.
> +I2C0) nodes and linked to a port node in the dw-mipi-csi,using the common 
> video
> +interfaces bindings, defined in video-interfaces.txt.
> +
> +Example:
> +
> +
> + camera {
> + compatible = "snps,plat-csi2", "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + video_device: video-device@0x1 {

Drop the '0x' and any leading 0s on unit addresses.

> + compatible = "snps,video-device";
> + dmas = <_vdma_0 0>;
> + dma-names = "vdma0";
> + };

If video-device is not a real device, then you shouldn't need a DT node. 
I need a better explanation or diagram of what the h/w blocks and 
connections look like here.

>From the looks of this, you can just move dmas to the csi2 node. But I 
don't think that is right, because you can't generally just use an 
external DMA controller with camera data (maybe for validation, but it's 
not something you see in SoCs).

> +
> + csi2:   csi2@0x03000 {
> + compatible = "snps,dw-mipi-csi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = < 0x03000 0x7FF>;
> + interrupts = <2>;
> + phys = <_phy_ctrl1 0>;
> + resets = <_rst 1>;
> +
> + output-type = <2>;
> + ipi-mode = <0>;
> + ipi-color-mode = <0>;
> + ipi-auto-flush = <1>;
> + virtual-channel = <0>;
> +
> + port@1 {
> + reg = <1>;
> + csi1_ep1: endpoint {
> + remote-endpoint = <>;
> + data-lanes = <1 2>;
> + };
> + };
> + };
> + };
> + };
> +
> +The dw-mipi-csi device binding is defined in snps,dw-mipi-csi.txt.
> -- 
> 2.11.0
> 
>

Re: [PATCH 1/4] Documentation: dt: Add bindings documentation for DW MIPI CSI-2 Host

2017-03-15 Thread Rob Herring 
On Tue, Mar 07, 2017 at 02:37:48PM +, Ramiro Oliveira wrote:
> Create device tree bindings documentation for the Synopsys DW MIPI CSI-2
>  Host.
> 
> Signed-off-by: Ramiro Oliveira 
> ---
>  .../devicetree/bindings/media/snps,dw-mipi-csi.txt | 37 
> ++
>  1 file changed, 37 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt 
> b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> new file mode 100644
> index ..5b24eb43d760
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> @@ -0,0 +1,37 @@
> +Synopsys DesignWare CSI-2 Host controller
> +
> +Description
> +---
> +
> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
> +camera.
> +
> +Required properties:
> +- compatible: shall be "snps,dw-mipi-csi"

... "and an SoC specific compatible string"

> +- reg: physical base address and size of the device memory 
> mapped
> +  registers;
> +- interrupts : CSI-2 Host interrupt
> +- output-type   : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2) These
> +  values choose which of the Core outputs will be used, it can be Image Data
> +  Interface or Image Pixel Interface.
> +- phys: List of one PHY specifier (as defined in
> +  Documentation/devicetree/bindings/phy/phy-bindings.txt). This PHY is a MIPI
> +  DPHY working in RX mode.
> +- resets: Reference to a reset controller (optional)
> +
> +Optional properties(if in IPI mode):
> +- ipi-mode   : Mode to be used when in IPI(Camera -> 0 or Controller -> 1)
> +  This property defines if the controller will use the video timings 
> available
> +  in the video stream or if it will use pre-defined ones.

This could be boolean instead. I'd expect the former to be the typical 
mode, so name the property for the latter.

> +- ipi-color-mode: Bus depth to be used in IPI (48 bits -> 0 or 16 bits -> 1)
> +  This property defines the width of the IPI bus.

Are these the only 2 modes that any h/w would ever have (not just your 
controller)? Perhaps using the actual bits for the value would be 
better. Also, if this is the bus width, then the property should be 
named that as bus widths and pixel formats or color modes are not 
necessarily the same.

> +- ipi-auto-flush: Data auto-flush (1 -> Yes or 0 -> No). This property 
> defines
> +  if the data is automatically flushed in each vsync or if this process is 
> done
> +  manually

This could be boolean.

> +- virtual-channel: Virtual channel where data is present when in IPI mode. 
> This
> +  property chooses the virtual channel which IPI will use to retrieve the 
> video
> +  stream.

Again, some of these should probably be common properties (and therefore 
documented in a common location). I'm looking for some feedback from 
video/camera maintainers on this. I know I've seen some other similar 
bindings for camera interfaces recently.

Rob

Re: media / v4l2-mc: wishlist for complex cameras (was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline)

2017-03-15 Thread Pavel Machek 
Hi!

> > Well, I believe first question is: what applications would we want to
> > run on complex devices? Will sending control from video to subdevs
> > actually help?
> 
> I would say: camorama, xawtv3, zbar, google talk, skype. If it runs
> with those, it will likely run with any other application.

I'll take a look when I'm at better internet access.

> > mplayer is useful for testing... but that one already works (after you
> > setup the pipeline, and configure exposure/gain).
> > 
> > But thats useful for testing, not really for production. Image will be
> > out of focus and with wrong white balance.
> > 
> > What I would really like is an application to get still photos. For
> > taking pictures with manual settings we need
> > 
> > a) units for controls: user wants to focus on 1m, and take picture
> > with ISO200, 1/125 sec. We should also tell him that lens is f/5.6 and
> > focal length is 20mm with 5mm chip.
> > 
> > But... autofocus/autogain would really be good to have. Thus we need:
> > 
> > b) for each frame, we need exposure settings and focus position at
> > time frame was taken. Otherwise autofocus/autogain will be too
> > slow. At least focus position is going to be tricky -- either kernel
> > would have to compute focus position for us (not trivial) or we'd need
> > enough information to compute it in userspace.
> > 
> > There are more problems: hardware-accelerated preview is not trivial
> > to set up (and I'm unsure if it can be done in generic way). Still
> > photos application needs to switch resolutions between preview and
> > photo capture. Probably hardware-accelerated histograms are needed for
> > white balance, auto gain and auto focus, 
> > 
> > It seems like there's a _lot_ of stuff to be done before we have
> > useful support for complex cameras...
> 
> Taking still pictures using a hardware-accelerated preview is
> a sophisticated use case. I don't know any userspace application
> that does that. Ok, several allow taking snapshots, by simply
> storing the image of the current frame.

Well, there are applications that take still pictures. Android has
one. Maemo has another. Then there's fcam-dev. Its open source; with
modified kernel it is fully usable. I have version that runs on recent
nearly-mainline on N900. 

So yes, I'd like solution for problems a) and b).

> > (And I'm not sure... when application such as skype is running, is
> > there some way to run autogain/autofocus/autowhitebalance? Is that
> > something we want to support?)
> 
> Autofocus no. Autogain/Autowhite can be done via libv4l, provided that
> it can access the device's controls via /dev/video devnode. Other
> applications may be using some other similar algorithms.
> 
> Ok, they don't use histograms provided by the SoC. So, they do it in
> software, with is slower. Still, it works fine when the light
> conditions don't change too fast.

I guess it is going to work well enough with higher CPU
usage. Question is if camera without autofocus is usable. I'd say "not
really".

> > I believe other question is: will not having same control on main
> > video device and subdevs be confusing? Does it actually help userspace
> > in any way? Yes, we can make controls accessible to old application,
> > but does it make them more useful? 
> 
> Yes. As I said, libv4l (and some apps) have logic inside to adjust
> the image via bright, contrast and white balance controls, using the
> video devnode. They don't talk subdev API. So, if those controls
> aren't exported, they won't be able to provide a good quality image.

Next question is if the libv4l will do the right thing if we just put
all controls to one node. For example on N900 you have exposure/gain
and brightness. But the brightness is applied at preview phase, so it
is "basically useless". You really need to adjust the image using the
exposure/gain.

> > > > In addition, I suspect end-users of these complex devices don't really 
> > > > care
> > > > about a plugin: they want full control and won't typically use generic
> > > > applications. If they would need support for that, we'd have seen much 
> > > > more
> > > > interest. The main reason for having a plugin is to simplify testing and
> > > > if this is going to be used on cheap hobbyist devkits.  
> > > 
> > > What are the needs for a cheap hobbyist devkit owner? Do we currently
> > > satisfy those needs? I'd say that having a functional driver when
> > > compiled without the subdev API, that implements the ioctl's/controls  
> > 
> > Having different interface based on config options... is just
> > weird. What about poor people (like me) trying to develop complex
> > applications?
> 
> Well, that could be done using other mechanisms, like a modprobe
> parameter or by switching the behaviour if a subdev interface is
> opened. I don't see much trouble on allowing accessing a control via
> both interfaces.

If we really want to go that way (is not modifying library to access
the right files quite easy?), I

Re: [PATCH v3] [media] adv7604: Add support for hardware reset

2017-03-15 Thread Jean-Michel Hautbois 
Hi,

2016-06-22 13:30 GMT+02:00 Dragos Bogdan :
> The part can be reset by a low pulse on the RESET pin (i.e. a hardware
> reset) with a minimum width of 5 ms. It is recommended to wait 5 ms
> after the low pulse before an I2C write is performed to the part.
> For safety reasons, the delays will be between 5 and 10 ms.
>
> The RESET pin can be tied high, so the GPIO is optional.
>
> Signed-off-by: Dragos Bogdan 
> Reviewed-by: Lars-Peter Clausen 
> Acked-by: Laurent Pinchart 
> ---
> Changes since v2:
>  - adv76xx_reset() is now a void function (it always returned 0).
>
> Changes since v1:
>  - Replace mdelay() with usleep_range();
>  - Limit the comments to 75 characters per line.
>
>  drivers/media/i2c/adv7604.c | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 41a1bfc..ab4f933 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -164,6 +164,7 @@ struct adv76xx_state {
> struct adv76xx_platform_data pdata;
>
> struct gpio_desc *hpd_gpio[4];
> +   struct gpio_desc *reset_gpio;
>
> struct v4l2_subdev sd;
> struct media_pad pads[ADV76XX_PAD_MAX];
> @@ -2996,6 +2997,19 @@ static int configure_regmaps(struct adv76xx_state 
> *state)
> return 0;
>  }
>
> +static void adv76xx_reset(struct adv76xx_state *state)
> +{
> +   if (state->reset_gpio) {
> +   /* ADV76XX can be reset by a low reset pulse of minimum 5 ms. 
> */
> +   gpiod_set_value_cansleep(state->reset_gpio, 0);
> +   usleep_range(5000, 1);
> +   gpiod_set_value_cansleep(state->reset_gpio, 1);
> +   /* It is recommended to wait 5 ms after the low pulse before 
> */
> +   /* an I2C write is performed to the ADV76XX. */
> +   usleep_range(5000, 1);
> +   }
> +}
> +
>  static int adv76xx_probe(struct i2c_client *client,
>  const struct i2c_device_id *id)
>  {
> @@ -3059,6 +3073,12 @@ static int adv76xx_probe(struct i2c_client *client,
> if (state->hpd_gpio[i])
> v4l_info(client, "Handling HPD %u GPIO\n", i);
> }
> +   state->reset_gpio = devm_gpiod_get_optional(>dev, "reset",
> +   
> GPIOD_OUT_HIGH);
> +   if (IS_ERR(state->reset_gpio))
> +   return PTR_ERR(state->reset_gpio);
> +
> +   adv76xx_reset(state);
>
> state->timings = cea640x480;
> state->format = adv76xx_format_info(state, MEDIA_BUS_FMT_YUYV8_2X8);
> --
> 2.1.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

I now have this patch in my tree and I can get into a point where
status is V4L2_IN_ST_NO_SYNC and stays there...
If I set a resolution (say, 1920x1080@60), and then use another one
without unplugging the cable, I can get into this state.
If I don't have the reset call, there is not such problem.

Any idea why ?
I tried (without a high conviction) to add i call to adv76xx_reset
inside g_input_status when there is no sync, it is better, but not
perfect (I still can get a status = 0x10003 for example).

Thanks,
JM

Re: [RFC PATCH 1/5] Document: Add document file for Sony CXD2880 DVB-T2/T tuner + demodulator

2017-03-15 Thread Rob Herring 
On Tue, Mar 07, 2017 at 10:07:45AM +0900, yasunari.takigu...@sony.com wrote:
> From: Yasunari Takiguchi 
> 
> This is the driver for Sony CXD2880 DVB-T2/T tuner + demodulator.

Looks like a binding, not a driver to me.

For subject, use: dt-bindings: media: ...

> 
> Regarding this third Beta Release, the status is:

"third Beta Release" is not really meaningful to upstream kernel.

> - Tested on Raspberry Pi 3.
> - The DVB-API operates under dvbv5 tools.
> 
> Signed-off-by: Yasunari Takiguchi 
> Signed-off-by: Masayuki Yamamoto 
> Signed-off-by: Hideki Nozawa 
> Signed-off-by: Kota Yonezawa 
> Signed-off-by: Toshihiko Matsumoto 
> Signed-off-by: Satoshi Watanabe 
> ---
>  .../devicetree/bindings/media/spi/sony-cxd2880.txt |   16 
>  1 file changed, 16 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt 
> b/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt
> new file mode 100644
> index 000..bdbb047
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt
> @@ -0,0 +1,16 @@
> +Sony CXD2880 DVB-T2/T tuner + demodulator driver SPI adapter
> +
> +Required properties:
> +- compatible: Should be "sony,cxd2880".
> +- reg: SPI chip select number for the device.
> +- spi-max-frequency: Maximum bus speed, should be set to <5500> (55MHz).
> +- status: Should be "okay"
> +
> +Example:
> +
> +cxd2880@0 {
> + compatible = "sony,cxd2880";
> + reg = <0>; /* CE0 */
> + spi-max-frequency = <5500>; /* 55MHz */
> + status = "okay";

Don't show status in examples.

> +};
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 1/2] Documentation: DT: Add OV5647 bindings

2017-03-15 Thread Rob Herring 
On Wed, Mar 15, 2017 at 11:51 AM, Ramiro Oliveira
 wrote:
> Hi Rob
>
> On 3/15/2017 4:42 PM, Rob Herring wrote:
>> On Mon, Mar 06, 2017 at 11:16:33AM +, Ramiro Oliveira wrote:
>>> Create device tree bindings documentation.
>>>
>>> Signed-off-by: Ramiro Oliveira 
>>> ---
>>>  .../devicetree/bindings/media/i2c/ov5647.txt   | 35 
>>> ++
>>>  1 file changed, 35 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>
>> There's no changelog here, so I can't tell if anything is changed, but I
>> acked v7. Please add acks when sending new versions.
>>
>
> The changelog is in the cover letter, although I didn't specify which changes
> where made in the driver and which were made in the Documentation.
>
> The only change was removing the clock name since there was only one clock 
> used.
>
> Should I keep your ack?

Yes.

Rob

Re: [PATCH v10 1/2] Documentation: DT: Add OV5647 bindings

2017-03-15 Thread Ramiro Oliveira 
Hi Rob

On 3/15/2017 4:42 PM, Rob Herring wrote:
> On Mon, Mar 06, 2017 at 11:16:33AM +, Ramiro Oliveira wrote:
>> Create device tree bindings documentation.
>>
>> Signed-off-by: Ramiro Oliveira 
>> ---
>>  .../devicetree/bindings/media/i2c/ov5647.txt   | 35 
>> ++
>>  1 file changed, 35 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> 
> There's no changelog here, so I can't tell if anything is changed, but I 
> acked v7. Please add acks when sending new versions.
> 

The changelog is in the cover letter, although I didn't specify which changes
where made in the driver and which were made in the Documentation.

The only change was removing the clock name since there was only one clock used.

Should I keep your ack?

-- 
Best Regards

Ramiro Oliveira
ramiro.olive...@synopsys.com

Re: [PATCH v10 2/2] media: i2c: Add support for OV5647 sensor.

2017-03-15 Thread Ramiro Oliveira 
Hi Sakari

On 3/7/2017 10:45 AM, Sakari Ailus wrote:
> Hi Ramiro,
> 
> On Mon, Mar 06, 2017 at 11:16:34AM +, Ramiro Oliveira wrote:
> ...
>> +static int __sensor_init(struct v4l2_subdev *sd)
>> +{
>> +int ret;
>> +u8 resetval, rdval;
>> +struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +dev_dbg(>dev, "sensor init\n");
> 
> This looks like a debugging time leftover. Please remove.
> 

Should I send a v11 with this change?

> With that,
> 
> Acked-by: Sakari Ailus 
> 
> ...
> 
>> +static int ov5647_parse_dt(struct device_node *np)
>> +{
>> +struct v4l2_of_endpoint bus_cfg;
>> +struct device_node *ep;
>> +
>> +int ret;
>> +
>> +ep = of_graph_get_next_endpoint(np, NULL);
>> +if (!ep)
>> +return -EINVAL;
>> +
>> +ret = v4l2_of_parse_endpoint(ep, _cfg);
>> +
>> +of_node_put(ep);
>> +return ret;
>> +}
> 
> This will conflict with my fwnode patchset. Let's see in which order the
> patches will be merged, one of the sets has to be changed. The work is
> trivial though.
> 

-- 
Best Regards

Ramiro Oliveira
ramiro.olive...@synopsys.com

Re: [PATCH v10 1/2] Documentation: DT: Add OV5647 bindings

2017-03-15 Thread Rob Herring 
On Mon, Mar 06, 2017 at 11:16:33AM +, Ramiro Oliveira wrote:
> Create device tree bindings documentation.
> 
> Signed-off-by: Ramiro Oliveira 
> ---
>  .../devicetree/bindings/media/i2c/ov5647.txt   | 35 
> ++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt

There's no changelog here, so I can't tell if anything is changed, but I 
acked v7. Please add acks when sending new versions.

Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

2017-03-15 Thread Mauro Carvalho Chehab 
Em Fri, 27 Jan 2017 13:54:57 -0800
Eric Anholt  escreveu:

> Here's my first pass at importing the camera driver.  There's a bunch
> of TODO left to it, most of which is documented, and the rest being
> standard checkpatch fare.
> 
> Unfortunately, when I try modprobing it on my pi3, the USB network
> device dies, consistently.  I'm not sure what's going on here yet, but
> I'm going to keep working on some debug of it.  I've unfortunately
> changed a lot of variables (pi3 vs pi2, upstream vs downstream, vchi's
> updates while in staging, 4.9 vs 4.4), so I probably won't figure it
> out today.
> 
> Note that the "Update the driver to the current VCHI API" patch will
> conflict with the outstanding "Add vchi_queue_kernel_message and
> vchi_queue_user_message" series, but the fix should be pretty obvious
> when that lands.
> 
> I built this against 4.10-rc1, but a merge with staging-next was clean
> and still built fine.

I'm trying it, building from the linux-next branch of the staging
tree. No joy.

That's what happens when I modprobe it:

[  991.841549] bcm2835_v4l2: module is from the staging directory, the quality 
is unknown, you have been warned.
[  991.842931] vchiq_get_state: g_state.remote == NULL
[  991.843437] vchiq_get_state: g_state.remote == NULL
[  991.843940] vchiq_get_state: g_state.remote == NULL
[  991.84] vchiq_get_state: g_state.remote == NULL
[  991.844947] vchiq_get_state: g_state.remote == NULL
[  991.845451] vchiq_get_state: g_state.remote == NULL
[  991.845954] vchiq_get_state: g_state.remote == NULL
[  991.846457] vchiq_get_state: g_state.remote == NULL
[  991.846961] vchiq_get_state: g_state.remote == NULL
[  991.847464] vchiq_get_state: g_state.remote == NULL
[  991.847969] vchiq: vchiq_initialise: videocore not initialized

[  991.847973] mmal_vchiq: Failed to initialise VCHI instance (status=-1)


Thanks,
Mauro

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

2017-03-15 Thread Javier Martinez Canillas 
Hello Marian,

On Wed, Mar 15, 2017 at 9:00 AM, Marian Mihailescu
 wrote:
> Thanks for the quick reply.
>
> Decoding works without issues for me too.
> I did not change the CMA size or used s5p_mfc.mem parameter. However, 
> according to the Marek, the default 8M should be enough for 3 instances of 
> H264 encoders/decoders. My test was encoding a 30 seconds 720p clip, so I 
> thought memory should not be a big issue; also it’s working w/o these patches 
> applied, so I think CMA size is enough.
> Nevertheless, I will try setting them, but I would feel better if someone 
> else would try encoding too.
>

Ok, I thought it may be that because Shuah and I needed to increase
the CMA size in order to decode a H.264 1080p video.

But if decoding is working correctly for you and only fails on
encoding, then I'm afraid that I won't be able to help you since as
mentioned I didn't test that.

> Cheers,
> Marian
>

Best regards,
Javier

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

2017-03-15 Thread Marian Mihailescu 
Thanks for the quick reply.

Decoding works without issues for me too.
I did not change the CMA size or used s5p_mfc.mem parameter. However, according 
to the Marek, the default 8M should be enough for 3 instances of H264 
encoders/decoders. My test was encoding a 30 seconds 720p clip, so I thought 
memory should not be a big issue; also it’s working w/o these patches applied, 
so I think CMA size is enough.
Nevertheless, I will try setting them, but I would feel better if someone else 
would try encoding too.

Cheers,
Marian

> On 15 Mar. 2017, at 10:19 pm, Javier Martinez Canillas  
> wrote:
> 
> Hello Marian,
> 
> On Wed, Mar 15, 2017 at 8:36 AM, Marian Mihailescu
>  wrote:
>> Hi,
>> 
>> After testing these patches, encoding using MFC fails when requesting
>> buffers for capture (it works for output) with ENOMEM (it complains it
>> cannot allocate memory on bank1).
>> Did anyone else test encoding?
>> 
> 
> I've not tested encoding, but I did test decoding and it works for me
> with Shuah's patch to increase the CMA memory [0]. Did you test with
> that one as well?
> 
> Also you could try using the 5p_mfc.mem kernel param as explained in
> the commit message of "media: s5p-mfc: Add support for probe-time
> preallocated block based allocator".
> 
> [0]: https://patchwork.kernel.org/patch/9596737/
> 
>> Thanks,
>> Marian
>> 
> 
> Best regards,
> Javier

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

2017-03-15 Thread Javier Martinez Canillas 
Hello Marian,

On Wed, Mar 15, 2017 at 8:36 AM, Marian Mihailescu
 wrote:
> Hi,
>
> After testing these patches, encoding using MFC fails when requesting
> buffers for capture (it works for output) with ENOMEM (it complains it
> cannot allocate memory on bank1).
> Did anyone else test encoding?
>

I've not tested encoding, but I did test decoding and it works for me
with Shuah's patch to increase the CMA memory [0]. Did you test with
that one as well?

Also you could try using the 5p_mfc.mem kernel param as explained in
the commit message of "media: s5p-mfc: Add support for probe-time
preallocated block based allocator".

[0]: https://patchwork.kernel.org/patch/9596737/

> Thanks,
> Marian
>

Best regards,
Javier

[PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

2017-03-15 Thread Marian Mihailescu 
Hi,

After testing these patches, encoding using MFC fails when requesting
buffers for capture (it works for output) with ENOMEM (it complains it
cannot allocate memory on bank1).
Did anyone else test encoding?

Thanks,
Marian

Either I've been missing something or nothing has been going on. (K. E. Gordon)

[PATCH v2 03/14] [media] coda: simplify optional reset handling

2017-03-15 Thread Philipp Zabel 
As of commit bb475230b8e5 ("reset: make optional functions really
optional"), the reset framework API calls use NULL pointers to
describe optional, non-present reset controls.

This allows to return errors from devm_reset_control_get_optional
without special cases and to call reset_control_reset unconditionally.

Signed-off-by: Philipp Zabel 
---
 drivers/media/platform/coda/coda-common.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index eb6548f46cbac..0cf667ab44bfb 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1982,8 +1982,7 @@ static int coda_hw_init(struct coda_dev *dev)
if (ret)
goto err_clk_ahb;
 
-   if (dev->rstc)
-   reset_control_reset(dev->rstc);
+   reset_control_reset(dev->rstc);
 
/*
 * Copy the first CODA_ISRAM_SIZE in the internal SRAM.
@@ -2362,13 +2361,8 @@ static int coda_probe(struct platform_device *pdev)
dev->rstc = devm_reset_control_get_optional(>dev, NULL);
if (IS_ERR(dev->rstc)) {
ret = PTR_ERR(dev->rstc);
-   if (ret == -ENOENT || ret == -ENOTSUPP) {
-   dev->rstc = NULL;
-   } else {
-   dev_err(>dev, "failed get reset control: %d\n",
-   ret);
-   return ret;
-   }
+   dev_err(>dev, "failed get reset control: %d\n", ret);
+   return ret;
}
 
/* Get IRAM pool from device tree or platform data */
-- 
2.11.0

[PATCH v2 04/14] [media] st_rc: simplify optional reset handling

2017-03-15 Thread Philipp Zabel 
As of commit bb475230b8e5 ("reset: make optional functions really
optional"), the reset framework API calls use NULL pointers to describe
optional, non-present reset controls.

This allows to return errors from reset_control_get_optional and to call
reset_control_(de)assert unconditionally.

Signed-off-by: Philipp Zabel 
Acked-by: Patrice Chotard 
---
 drivers/media/rc/st_rc.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index f0d7190e39195..0ac1879f75069 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -165,8 +165,7 @@ static void st_rc_hardware_init(struct st_rc_device *dev)
unsigned int rx_sampling_freq_div;
 
/* Enable the IP */
-   if (dev->rstc)
-   reset_control_deassert(dev->rstc);
+   reset_control_deassert(dev->rstc);
 
clk_prepare_enable(dev->sys_clock);
baseclock = clk_get_rate(dev->sys_clock);
@@ -281,10 +280,11 @@ static int st_rc_probe(struct platform_device *pdev)
else
rc_dev->rx_base = rc_dev->base;
 
-
rc_dev->rstc = reset_control_get_optional(dev, NULL);
-   if (IS_ERR(rc_dev->rstc))
-   rc_dev->rstc = NULL;
+   if (IS_ERR(rc_dev->rstc)) {
+   ret = PTR_ERR(rc_dev->rstc);
+   goto err;
+   }
 
rc_dev->dev = dev;
platform_set_drvdata(pdev, rc_dev);
@@ -352,8 +352,7 @@ static int st_rc_suspend(struct device *dev)
writel(0x00, rc_dev->rx_base + IRB_RX_EN);
writel(0x00, rc_dev->rx_base + IRB_RX_INT_EN);
clk_disable_unprepare(rc_dev->sys_clock);
-   if (rc_dev->rstc)
-   reset_control_assert(rc_dev->rstc);
+   reset_control_assert(rc_dev->rstc);
}
 
return 0;
-- 
2.11.0

[PATCH v2 05/14] [media] rc: sunxi-cir: simplify optional reset handling

2017-03-15 Thread Philipp Zabel 
As of commit bb475230b8e5 ("reset: make optional functions really
optional"), the reset framework API calls use NULL pointers to describe
optional, non-present reset controls.

This allows to return errors from devm_reset_control_get_optional and to
call reset_control_(de)assert unconditionally.

Signed-off-by: Philipp Zabel 
---
 drivers/media/rc/sunxi-cir.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 25b0061678102..4b785dd775c11 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -174,16 +174,11 @@ static int sunxi_ir_probe(struct platform_device *pdev)
 
/* Reset (optional) */
ir->rst = devm_reset_control_get_optional(dev, NULL);
-   if (IS_ERR(ir->rst)) {
-   ret = PTR_ERR(ir->rst);
-   if (ret == -EPROBE_DEFER)
-   return ret;
-   ir->rst = NULL;
-   } else {
-   ret = reset_control_deassert(ir->rst);
-   if (ret)
-   return ret;
-   }
+   if (IS_ERR(ir->rst))
+   return PTR_ERR(ir->rst);
+   ret = reset_control_deassert(ir->rst);
+   if (ret)
+   return ret;
 
ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
if (ret) {
@@ -291,8 +286,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
 exit_clkdisable_apb_clk:
clk_disable_unprepare(ir->apb_clk);
 exit_reset_assert:
-   if (ir->rst)
-   reset_control_assert(ir->rst);
+   reset_control_assert(ir->rst);
 
return ret;
 }
@@ -304,8 +298,7 @@ static int sunxi_ir_remove(struct platform_device *pdev)
 
clk_disable_unprepare(ir->clk);
clk_disable_unprepare(ir->apb_clk);
-   if (ir->rst)
-   reset_control_assert(ir->rst);
+   reset_control_assert(ir->rst);
 
spin_lock_irqsave(>ir_lock, flags);
/* disable IR IRQ */
-- 
2.11.0

Re: media / v4l2-mc: wishlist for complex cameras (was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline)

2017-03-15 Thread Philippe De Muyter 
On Tue, Mar 14, 2017 at 09:54:31PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 14 Mar 2017 23:32:54 +0100
> Pavel Machek  escreveu:
> 
> > 
> > Well, I believe first question is: what applications would we want to
> > run on complex devices? Will sending control from video to subdevs
> > actually help?
> 
> I would say: camorama, xawtv3, zbar, google talk, skype. If it runs
> with those, it will likely run with any other application.
> 

I would like to add the 'v4l2src' plugin of gstreamer, and on the imx6 its
imx-specific counterpart 'imxv4l2videosrc' from the gstreamer-imx package
at https://github.com/Freescale/gstreamer-imx, and 'v4l2-ctl'.

Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles

[PATCH] [media] doc: kapi: fix typo

2017-03-15 Thread Baruch Siach 
Signed-off-by: Baruch Siach 
---
 Documentation/media/kapi/v4l2-core.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/media/kapi/v4l2-core.rst 
b/Documentation/media/kapi/v4l2-core.rst
index e9677150ed99..d8f6c46d26d5 100644
--- a/Documentation/media/kapi/v4l2-core.rst
+++ b/Documentation/media/kapi/v4l2-core.rst
@@ -1,4 +1,4 @@
-Video2Linux devices
+Video4Linux devices
 ---
 
 .. toctree::
-- 
2.11.0

Re: [RFC][PATCH] dma-buf: Introduce dma-buf test module

2017-03-15 Thread Daniel Vetter 
On Tue, Mar 14, 2017 at 01:30:30PM -0700, Laura Abbott wrote:
> On 03/14/2017 01:13 PM, Daniel Vetter wrote:
> > On Tue, Mar 14, 2017 at 01:04:19PM -0700, Laura Abbott wrote:
> >>
> >> dma-buf is designed to share buffers. Sharing means that there needs to
> >> be another subsystem to accept those buffers. Introduce a simple test
> >> module to act as a dummy system to accept dma_bufs from elsewhere. The
> >> goal is to provide a very simple interface to validate exported buffers
> >> do something reasonable. This is based on ion_test.c that existed for
> >> the Ion framework.
> >>
> >> Signed-off-by: Laura Abbott 
> >> ---
> >> This is basically a drop in of what was available as
> >> drivers/staging/android/ion/ion_test.c. Given it has no Ion specific
> >> parts it might be useful as a more general test module. RFC mostly
> >> to see if this is generally useful or not.
> > 
> > We already have a test dma-buf driver, which also handles reservation
> > objects and can create fences to provoke signalling races an all kinds of
> > other fun. It's drivers/gpu/drm/vgem.
> > 
> > If there's anything missing in there, patches very much welcome.
> > -Daniel
> > 
> 
> Thanks for that pointer. It certainly looks more complete vs. allocating
> a platform_device. I'll look and see if there's anything that needs
> extension. Plus this means I can probably delete more code from Ion (woo)

\o/ for less code!

btw for the tests, I think we should really hard to either get them into
kselftests or igt.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3 06/27] rcar-vin: move max width and height information to chip information

2017-03-15 Thread Sergei Shtylyov 

On 3/14/2017 10:02 PM, Niklas Söderlund wrote:


On Gen3 the max supported width and height will be different from Gen2.
Move the limits to the struct chip_info to prepare for Gen3 support.


   Maybe rvin_info?


Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 6 ++
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 6 ++
 drivers/media/platform/rcar-vin/rcar-vin.h  | 6 ++
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index ec1eb723d401fda2..998617711f1ad045 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -257,14 +257,20 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)

 static const struct rvin_info rcar_info_h1 = {
.chip = RCAR_H1,
+   .max_width = 2048,
+   .max_height = 2048,
 };

 static const struct rvin_info rcar_info_m1 = {
.chip = RCAR_M1,
+   .max_width = 2048,
+   .max_height = 2048,
 };

 static const struct rvin_info rcar_info_gen2 = {
.chip = RCAR_GEN2,
+   .max_width = 2048,
+   .max_height = 2048,
 };

 static const struct of_device_id rvin_of_id_table[] = {

[...]

MBR, Sergei

Re: [PATCH 03/16] rcar-vin: fix how pads are handled for v4l2 subdevice operations

2017-03-15 Thread Niklas Söderlund 
Hi Sergei,

Thanks for your feedback.

On 2017-03-15 12:12:21 +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 3/14/2017 9:59 PM, Niklas Söderlund wrote:
> 
> > The rcar-vin driver only uses one pad, pad number 0.
> > 
> > - All v4l2 operations that did not check that the requested operation
> >   was for pad 0 have been updated with a check to enforce this.
> > 
> > - All v4l2 operations that stored (and later restore) the requested pad
> 
>Restored?

Will update for v2.

> 
> >   before substituting it for the subdevice pad number have been updated
> >   to not store the incoming pad and simply restore it to 0 after the
> >   subdevice operation is complete.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  drivers/media/platform/rcar-vin/rcar-v4l2.c | 26 ++
> >  1 file changed, 14 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> > b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > index 7ca27599b9982ffc..610f59e2a9142622 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > @@ -550,14 +550,16 @@ static int rvin_enum_dv_timings(struct file *file, 
> > void *priv_fh,
> >  {
> > struct rvin_dev *vin = video_drvdata(file);
> > struct v4l2_subdev *sd = vin_to_source(vin);
> > -   int pad, ret;
> > +   int ret;
> > +
> > +   if (timings->pad)
> > +   return -EINVAL;
> > 
> > -   pad = timings->pad;
> > timings->pad = vin->sink_pad_idx;
> > 
> > ret = v4l2_subdev_call(sd, pad, enum_dv_timings, timings);
> 
>Does this still compile after you removed 'pad'?

Yes, the pad in v4l2_subdev_call() do not refer to the pad variable but 
the pad operations of the subdevice ops struct, the macro is defined as:

#define v4l2_subdev_call(sd, o, f, args...) \
(!(sd) ? -ENODEV : (((sd)->ops->o && (sd)->ops->o->f) ? \
(sd)->ops->o->f((sd), ##args) : -ENOIOCTLCMD))

So if you expand the macro it looks like:

sd->ops->pad->enum_dv_timings(timings);

I agree it's confusing and I had the same thought the first times I 
looked at it too :-)

> 
> > 
> > -   timings->pad = pad;
> > +   timings->pad = 0;
> > 
> > return ret;
> >  }
> > @@ -600,14 +602,16 @@ static int rvin_dv_timings_cap(struct file *file, 
> > void *priv_fh,
> >  {
> > struct rvin_dev *vin = video_drvdata(file);
> > struct v4l2_subdev *sd = vin_to_source(vin);
> > -   int pad, ret;
> > +   int ret;
> > +
> > +   if (cap->pad)
> > +   return -EINVAL;
> > 
> > -   pad = cap->pad;
> > cap->pad = vin->sink_pad_idx;
> > 
> > ret = v4l2_subdev_call(sd, pad, dv_timings_cap, cap);
> 
>And this?
> 
> > 
> > -   cap->pad = pad;
> > +   cap->pad = 0;
> > 
> > return ret;
> >  }
> [...]
> 
> MBR, Sergei
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH 03/16] rcar-vin: fix how pads are handled for v4l2 subdevice operations

2017-03-15 Thread Sergei Shtylyov 

Hello!

On 3/14/2017 9:59 PM, Niklas Söderlund wrote:


The rcar-vin driver only uses one pad, pad number 0.

- All v4l2 operations that did not check that the requested operation
  was for pad 0 have been updated with a check to enforce this.

- All v4l2 operations that stored (and later restore) the requested pad


   Restored?


  before substituting it for the subdevice pad number have been updated
  to not store the incoming pad and simply restore it to 0 after the
  subdevice operation is complete.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 7ca27599b9982ffc..610f59e2a9142622 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -550,14 +550,16 @@ static int rvin_enum_dv_timings(struct file *file, void 
*priv_fh,
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int pad, ret;
+   int ret;
+
+   if (timings->pad)
+   return -EINVAL;

-   pad = timings->pad;
timings->pad = vin->sink_pad_idx;

ret = v4l2_subdev_call(sd, pad, enum_dv_timings, timings);


   Does this still compile after you removed 'pad'?



-   timings->pad = pad;
+   timings->pad = 0;

return ret;
 }
@@ -600,14 +602,16 @@ static int rvin_dv_timings_cap(struct file *file, void 
*priv_fh,
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int pad, ret;
+   int ret;
+
+   if (cap->pad)
+   return -EINVAL;

-   pad = cap->pad;
cap->pad = vin->sink_pad_idx;

ret = v4l2_subdev_call(sd, pad, dv_timings_cap, cap);


   And this?



-   cap->pad = pad;
+   cap->pad = 0;

return ret;
 }

[...]

MBR, Sergei

Re: [PATCH 01/16] rcar-vin: reset bytesperline and sizeimage when resetting format

2017-03-15 Thread Sergei Shtylyov 

Hello!

On 3/14/2017 9:59 PM, Niklas Söderlund wrote:


These two where forgotten when refactoring the format reset code. If


   s/where/were/?


they are not also reset at the same time as width and height the format
returned from G_FMT will not match reality.

Signed-off-by: Niklas Söderlund 

[...]

MBR, Sergei

Re: [PATCH] [media] v4l2-dv-timings: Introduce v4l2_calc_fps()

2017-03-15 Thread Hans Verkuil 
On 03/14/2017 08:14 PM, Jose Abreu wrote:
> Hi Hans,
> 
> 
> On 14-03-2017 07:24, Hans Verkuil wrote:
>>> Right, I was forgetting about this ...
>>>
>>> So:
>>> 1) Most of HDMI receivers do not have the expected precision in
>>> measuring pixel clock value;
>> s/Most/Some/
>>
>> Newer HDMI receivers tend to have better precision.
>>
>> However, the 1000/1001 factor is within the error of margin that the HDMI
>> spec has for the pixelclock, so even if it is 59.94 you still (theoretically)
>> do not know if that is because it really has that fps or if the source just 
>> has
>> a bad clock.
> 
> Hmm. But if source has a bad clock then it won't send at the
> expected frame rate, so if we are able to measure pixel clock
> value we will get the approximated frame rate for that source,
> right? Unless the source also doesn't have standard h/v timings,
> but as long as receiver detects this correctly then we can calculate.

s/bad clock/slightly different clock/

The problem is that the HDMI spec has an error of margin for the pixelclock of
(I think) 0.25%. The difference in pixelclock between 60 and 59.94 Hz is about
0.1%. In addition the source clock and the sink clock will run at slightly 
different
speeds. So all this makes it hard to reliably measure.

Now, we never tested this and in reality the difference between 60 an 59.94 
might
be as clear as day and night (for receivers with sufficient timer resolution).

So that's why more information is needed.

> 
>>
>> It's a bit theoretical, in practice you can assume the source really is 
>> sending
>> at 59.94 AFAIK.
>>
>>> 2) Most (I would guess all of them?) have access to AVI infoframe
>>> contents;
>> All will have that.
>>
>>> 3) The FPS value is generally used by applications to calculate
>>> expected frame rate and number of frames dropped (right?);
>> Not really. Most HDMI drivers do not implement g_parm, instead they fill in
>> the detected pixelclock in QUERY_DV_TIMINGS, leaving it up to the application
>> to calculate the fps from that.
>>
>>> 4) The factor in FPS value can be adjusted by 1000/1001;
>>>
>>> From these points I would propose in just using the vic and drop
>>> the resolution in fps a little bit, do you agree?
>> The reality is that how to detect the 1000/1001 reduced fps is fuzzy. Part of
>> the reason for that is that most of the HDMI receivers we have in the kernel
>> were developed by Cisco/Tandberg (i.e. mostly me) for our video conferencing
>> systems, and those all run at 60 Hz. So we never had the need to detect 
>> 59.94 vs
>> 60 Hz. In addition, some of the older Analog Devices devices didn't have the
>> resolution to detect the difference.
>>
>> So I always held off a bit with defining exactly how to do this since I had
>> no experience with it.
>>
>> My question to you is: can you reliably detect the difference between 60 and 
>> 59.94
>> Hz and between 24 and 23.976 Hz by just the measured pixelclock?
>>
>> You need to test this with different sources, not just signal generators. You
>> probably get a range of pixelclock values for the same framerate for 
>> different
>> sources, since each source has their own clock.
> 
> I will have to conduct more tests to confirm but the expected
> resolution is more than enough to detect 1000/1001 changes.
> 
>>
>> My preference would be to extend query_dv_timings a bit for this:
>>
>> 
>> Add a flag V4L2_DV_FL_CAN_DETECT_REDUCED_FPS. If set, then the hw can detect 
>> the
>> difference between regular fps and 1000/1001 fps. Note: this is only valid 
>> for
>> timings of VIC codes with the V4L2_DV_FL_CAN_REDUCE_FPS flag set.
> 
> Where should we set the flag? In v4l2_dv_timings_cap?

I was thinking v4l2_bt_timings, but a capability in v4l2_bt_timings_cap is not
a bad idea. Although that's global while having it in v4l2_bt_timings makes it
specific to the detected timings. Just in case the hardware can detect it for
some pixelclock frequencies, but not for others. But I'm not sure if that can
happen.

> 
>>
>> Allow V4L2_DV_FL_REDUCED_FPS to be used for receivers if 
>> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS
>> is set.
>>
>> For standard VIC codes the pixelclock returned by query_dv_timings is that 
>> of the
>> corresponding VIC timing, not what is measured. This will ensure fixed fps 
>> values
>>
>> g_parm should calculate the fps based on the v4l2_bt_timings struct, looking 
>> at the
>> REDUCES_FPS flags.
>>
>> For those receivers that cannot detect the difference, the fps will be 
>> 24/30/60 Hz,
>> for those that can detect the difference g_parm can check if both 
>> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS
>> and V4L2_DV_FL_REDUCED_FPS are set and reduce the fps by 1000/1001.
>> 
>>
>> If your hw can reliably detect the difference, then now is a good time to 
>> close
>> this gap in the DV_TIMINGS API.
> 
> Sounds nice :) Let me conduct more tests first and I will try to
> make the patch.

Nice!

Regards,

Hans

> 
> Best regards,
> Jose Miguel Abreu
> 
>>
>> Regards,
>>
>>

[PATCH 4/4] staging: atomisp: fix "alignment should match open parenthesis"

2017-03-15 Thread Daeseok Youn 
Fix checkpatch.pl issues in atomisp_cmd.c
 : "CHECK: Alignment should match open parenthesis"

Signed-off-by: Daeseok Youn 
---
 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   | 179 +++--
 1 file changed, 90 insertions(+), 89 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 82e7382..d97a8df 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -158,7 +158,7 @@ static unsigned short atomisp_get_sensor_fps(struct 
atomisp_sub_device *asd)
unsigned short fps;
 
if (v4l2_subdev_call(isp->inputs[asd->input_curr].camera,
-   video, g_frame_interval, _interval)) {
+   video, g_frame_interval, _interval)) {
fps = 0;
} else {
if (frame_interval.interval.numerator)
@@ -481,7 +481,7 @@ static void atomisp_3a_stats_ready_event(struct 
atomisp_sub_device *asd, uint8_t
 }
 
 static void atomisp_metadata_ready_event(struct atomisp_sub_device *asd,
-   enum atomisp_metadata_type 
md_type)
+enum atomisp_metadata_type md_type)
 {
struct v4l2_event event = {0};
 
@@ -622,14 +622,14 @@ irqreturn_t atomisp_isr(int irq, void *dev)
}
if (irq_infos & CSS_IRQ_INFO_EVENTS_READY)
atomic_set(>sequence,
-   atomic_read(>sequence_temp));
+  atomic_read(>sequence_temp));
}
 
if (irq_infos & CSS_IRQ_INFO_CSS_RECEIVER_SOF)
irq_infos &= ~CSS_IRQ_INFO_CSS_RECEIVER_SOF;
 
if ((irq_infos & CSS_IRQ_INFO_INPUT_SYSTEM_ERROR) ||
-   (irq_infos & CSS_IRQ_INFO_IF_ERROR)) {
+   (irq_infos & CSS_IRQ_INFO_IF_ERROR)) {
/* handle mipi receiver error */
u32 rx_infos;
enum ia_css_csi2_port port;
@@ -684,7 +684,7 @@ void atomisp_clear_css_buffer_counters(struct 
atomisp_sub_device *asd)
memset(asd->s3a_bufs_in_css, 0, sizeof(asd->s3a_bufs_in_css));
for (i = 0; i < ATOMISP_INPUT_STREAM_NUM; i++)
memset(asd->metadata_bufs_in_css[i], 0,
-   sizeof(asd->metadata_bufs_in_css[i]));
+  sizeof(asd->metadata_bufs_in_css[i]));
asd->dis_bufs_in_css = 0;
asd->video_out_capture.buffers_in_css = 0;
asd->video_out_vf.buffers_in_css = 0;
@@ -804,7 +804,7 @@ void atomisp_flush_params_queue(struct atomisp_video_pipe 
*pipe)
 
while (!list_empty(>per_frame_params)) {
param = list_entry(pipe->per_frame_params.next,
-   struct atomisp_css_params_with_list, list);
+  struct atomisp_css_params_with_list, list);
list_del(>list);
atomisp_free_css_parameters(>params);
atomisp_kernel_free(param);
@@ -983,7 +983,7 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, int 
error,
memset(, 0, sizeof(struct atomisp_css_buffer));
buffer.css_buffer.type = buf_type;
err = atomisp_css_dequeue_buffer(asd, stream_id, css_pipe_id,
-   buf_type, );
+buf_type, );
if (err) {
dev_err(isp->dev,
"atomisp_css_dequeue_buffer failed: 0x%x\n", err);
@@ -1000,12 +1000,12 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, 
int error,
switch (buf_type) {
case CSS_BUFFER_TYPE_3A_STATISTICS:
list_for_each_entry_safe(s3a_buf, _s3a_buf_tmp,
-   >s3a_stats_in_css, list) {
+>s3a_stats_in_css, list) {
if (s3a_buf->s3a_data ==
buffer.css_buffer.data.stats_3a) {
list_del_init(_buf->list);
list_add_tail(_buf->list,
-   >s3a_stats_ready);
+ >s3a_stats_ready);
break;
}
}
@@ -1021,12 +1021,12 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, 
int error,
 
md_type = atomisp_get_metadata_type(asd, css_pipe_id);
list_for_each_entry_safe(md_buf, _md_buf_tmp,
-   >metadata_in_css[md_type], list) {
+>metadata_in_css[md_type], list) {
if (md_buf->metadata ==
buffer.css_buffer.data.metadata) {
list_del_init(_buf->list);

[PATCH 3/4] staging: atomisp: remove useless #ifdef ISP2401 on top of atomisp_cmd.c

2017-03-15 Thread Daeseok Youn 
There is no reason to have "#ifdef ISP2401" condition
on top of atomisp_cmd.c file

Signed-off-by: Daeseok Youn 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 6160119..82e7382 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -1,6 +1,3 @@
-#ifdef ISP2401
-
-#endif
 /*
  * Support for Medifield PNW Camera Imaging ISP subsystem.
  *
-- 
1.9.1

[PATCH 2/4] staging: atomisp: fix inconsistent indenting

2017-03-15 Thread Daeseok Youn 
Fix warnings from the smatch tool

atomisp_cmd.c:5698
   atomisp_set_fmt_to_snr() warn: inconsistent indenting
atomisp_cmd.c:5714
   atomisp_set_fmt_to_snr() warn: inconsistent indenting

Signed-off-by: Daeseok Youn 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 9c3ba11..6160119 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -5693,7 +5693,7 @@ static int atomisp_set_fmt_to_snr(struct video_device 
*vdev,
/* Disable dvs if resolution can't be supported by sensor */
if (asd->params.video_dis_en &&
source_pad == ATOMISP_SUBDEV_PAD_SOURCE_VIDEO) {
-   vformat.which = V4L2_SUBDEV_FORMAT_TRY;
+   vformat.which = V4L2_SUBDEV_FORMAT_TRY;
ret = v4l2_subdev_call(isp->inputs[asd->input_curr].camera,
pad, set_fmt, _cfg, );
if (ret)
@@ -5710,7 +5710,7 @@ static int atomisp_set_fmt_to_snr(struct video_device 
*vdev,
}
dev_dbg(isp->dev, "sensor width: %d, height: %d\n",
ffmt->width, ffmt->height);
-vformat.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+   vformat.which = V4L2_SUBDEV_FORMAT_ACTIVE;
ret = v4l2_subdev_call(isp->inputs[asd->input_curr].camera, pad,
   set_fmt, NULL, );
if (ret)
-- 
1.9.1