Re: [PATCH 2/2] [media] cx231xx: Fix I2C on Internal Master 3 Bus

2017-02-12 Thread Oleh Kravchenko 


On 13.02.17 06:58, Antti Palosaari wrote:
> On 02/07/2017 09:35 PM, Oleh Kravchenko wrote:
>> Internal Master 3 Bus can send and receive only 4 bytes per time.
>>
>> Signed-off-by: Oleh Kravchenko 
>> ---
>>  drivers/media/usb/cx231xx/cx231xx-core.c | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/usb/cx231xx/cx231xx-core.c 
>> b/drivers/media/usb/cx231xx/cx231xx-core.c
>> index 550ec93..46646ec 100644
>> --- a/drivers/media/usb/cx231xx/cx231xx-core.c
>> +++ b/drivers/media/usb/cx231xx/cx231xx-core.c
>> @@ -355,7 +355,12 @@ int cx231xx_send_vendor_cmd(struct cx231xx *dev,
>>   */
>>  if ((ven_req->wLength > 4) && ((ven_req->bRequest == 0x4) ||
>>  (ven_req->bRequest == 0x5) ||
>> -(ven_req->bRequest == 0x6))) {
>> +(ven_req->bRequest == 0x6) ||
>> +
>> +/* Internal Master 3 Bus can send
>> + * and receive only 4 bytes per time
>> + */
>> +(ven_req->bRequest == 0x2))) {
>>  unsend_size = 0;
>>  pdata = ven_req->pBuff;
>>
>>
> 
> Good that you finally got i2c fixed properly and get rid of that ugly device 
> specific hack.
> 
> That new comment still does not open for me, why you call i2c bus tuner sits 
> as internal?
 
Because Sri Deevi called it:
/* Internal Master 3 Bus */
dev->i2c_bus[2].nr = 2;
dev->i2c_bus[2].dev = dev;
dev->i2c_bus[2].i2c_period = I2C_SPEED_100K;/* 100kHz */
dev->i2c_bus[2].i2c_nostop = 0;
dev->i2c_bus[2].i2c_reserve = 0;

> There is now commands 2, 4, 5, and 6 that should be split to 4 byte long, is 
> there any vendor command that could be longer? Maybe you could just add 
> single comment which states what all those 4 commands are.

Those commands is I2C bus numbers, plus read flag:
0 - write to I2C_0  0+4 - read from I2C_0
1 - write to I2C_1  1+4 - read from I2C_1
2 - write to I2C_2  2+4 - read from I2C_2
So I think my comment is good enough.
 
> Your patches are still on wrong order - you should first fix i2c and after 
> that add device support.

Looks like I can't change this, it already merged into linux-next :)

> regards
> Antti

-- 
Best regards,
Oleh Kravchenko

Re: [PATCH 2/3] si2157: Si2141/2151 tuner support.

2017-02-12 Thread Antti Palosaari 

Hello
You still didn't addressed the issues I pointed. For example that 
repeating loop looks simply wrong and you don't even care to add comment 
why this kind of ugly looking hack is there.


Stefan sent yesterday new set of patches for this device and those looks 
correct. There is not even that kind of strange reset loop.


regards
Antti


On 02/07/2017 11:35 PM, CrazyCat wrote:

Support for new tuner version.

Signed-off-by: Evgeny Plehov 
---
 drivers/media/tuners/si2157.c  | 70 ++
 drivers/media/tuners/si2157_priv.h |  2 ++
 2 files changed, 66 insertions(+), 6 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 57b2508..b46b149 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -1,5 +1,5 @@
 /*
- * Silicon Labs Si2146/2147/2148/2157/2158 silicon tuner driver
+ * Silicon Labs Si2141/2146/2147/2148/2151/2157/2158 silicon tuner driver
  *
  * Copyright (C) 2014 Antti Palosaari 
  *
@@ -75,6 +75,7 @@ static int si2157_cmd_execute(struct i2c_client *client, 
struct si2157_cmd *cmd)
return ret;
 }

+#define MAX_RESET_ATTEMPTS 10
 static int si2157_init(struct dvb_frontend *fe)
 {
struct i2c_client *client = fe->tuner_priv;
@@ -84,7 +85,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, chip_id, i;

dev_dbg(>dev, "\n");

@@ -102,14 +103,44 @@ static int si2157_init(struct dvb_frontend *fe)
if (uitmp == dev->if_frequency / 1000)
goto warm;

+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   for (i = 0; i < MAX_RESET_ATTEMPTS; i++)  {
+   /* reset */
+   memcpy(cmd.args, "\xc0\x05\x00\x00", 4);
+   cmd.wlen = 4;
+   cmd.rlen = 1;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+
+   memcpy(cmd.args, 
"\xc0\x00\x0d\x0e\x00\x01\x01\x01\x01\x03", 10);
+   cmd.wlen = 10;
+   cmd.rlen = 1;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+   if (cmd.args[0] != 0xfe)
+   break;
+   }
+   if (i >= MAX_RESET_ATTEMPTS)
+   goto err;
+   }
+
/* power up */
-   if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
+   switch (dev->chiptype) {
+   case SI2157_CHIPTYPE_SI2146:
memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
cmd.wlen = 9;
-   } else {
+   break;
+   case SI2157_CHIPTYPE_SI2141:
+   memcpy(cmd.args, "\xc0\x08\x01\x02\x00\x08\x01", 7);
+   cmd.wlen = 7;
+   break;
+   default:
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)
@@ -131,6 +162,8 @@ static int si2157_init(struct dvb_frontend *fe)
#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)
+   #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
+   #define SI2151_A10 ('A' << 24 | 51 << 16 | '1' << 8 | '0' << 0)

switch (chip_id) {
case SI2158_A20:
@@ -142,6 +175,10 @@ static int si2157_init(struct dvb_frontend *fe)
case SI2146_A10:
fw_name = NULL;
break;
+   case SI2141_A10:
+   case SI2151_A10:
+   fw_name = SI2141_A10_FIRMWARE;
+   break;
default:
dev_err(>dev, "unknown chip version Si21%d-%c%c%c\n",
cmd.args[2], cmd.args[1],
@@ -214,6 +251,23 @@ static int si2157_init(struct dvb_frontend *fe)

dev_info(>dev, "firmware version: %c.%c.%d\n",
cmd.args[6], cmd.args[7], cmd.args[8]);
+
+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   /* set clock */
+   memcpy(cmd.args, "\xc0\x00\x0d", 3);
+   cmd.wlen = 3;
+   cmd.rlen = 1;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+   /* setup PIN */
+   memcpy(cmd.args, "\x12\x80\x80\x85\x00\x81\x00", 7);
+   cmd.wlen = 7;
+   cmd.rlen = 7;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+

Re: [PATCH 10/11] [media] v4l2: Add v4l2 control IDs for HEVC encoder

2017-02-12 Thread Smitha T Murthy 
On Mon, 2017-02-06 at 15:54 +0100, Andrzej Hajda wrote:
> Hi Smitha,
> 
> I have no big experience with HEVC, so it is hard to review it
> appropriately but I will try do my best.
> As these control names goes to user space you should be very careful
> about it.
> I guess it could be good to compare these controls with other HEVC
> encoders including software ones (ffmpeg, intel, ...) to find some
> similarities, common naming convention.
> 
Thank you so much for the review :)
I will compare it with the software HEVC encoders for the naming
convention. Basically I was following the convention used for other
codecs in the same file.
> 
> On 18.01.2017 11:02, Smitha T Murthy wrote:
> > Add v4l2 controls for HEVC encoder
> >
> > CC: Hans Verkuil 
> > CC: Wu-Cheng Li 
> > CC: Kieran Bingham 
> > CC: Vladimir Zapolskiy 
> > CC: Laurent Pinchart 
> > Signed-off-by: Smitha T Murthy 
> > ---
> >  drivers/media/v4l2-core/v4l2-ctrls.c |   51 
> >  include/uapi/linux/v4l2-controls.h   |  109 
> > ++
> >  2 files changed, 160 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index 47001e2..387439d 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -775,6 +775,57 @@ static bool is_new_manual(const struct v4l2_ctrl 
> > *master)
> > case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX 
> > P-Frame QP Value";
> > case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:   return "VPX 
> > Profile";
> >  
> > +   /* HEVC controls */
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:   return "HEVC 
> > Frame QP value";
> 
> Should be "HEVC I-Frame", it looks like the convention is to upper-case
> first letter of all words,
> and the convention is I-Frame, B-Frame, P-Frame, here and in the next
> controls.
> I would drop also the word "value", but it is already used in other
> controls so I do not know :)
> 
The I,P,B frame naming convention for other codecs is like
"V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP" and
"V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP"
so I followed the same for HEVC codec too.

Yes they use the word "value" for other codecs too.

> > +   case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP:   return "HEVC P 
> > frame QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP:   return "HEVC B 
> > frame QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP:   return "HEVC 
> > Minimum QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP:   return "HEVC 
> > Maximum QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_DARK: return "HEVC 
> > dark region adaptive";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_SMOOTH:   return "HEVC 
> > smooth region adaptive";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_STATIC:   return "HEVC 
> > static region adaptive";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_ACTIVITY: return "HEVC 
> > activity adaptive";
> 
> Shouldn't it be "... Region Adaptive RC", or "... Region Adaptive Rate
> Control" ?
> 
I will correct it to Region Adaptive Rate Control.

> > +   case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:  return "HEVC 
> > Profile";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:return "HEVC 
> > level";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:return "HEVC 
> > tier_flag default is Main";
> 
> I guess 0 - means main tier, 1 means high tier, am I right? In such case
> it should be named "HEVC high tier" or sth similar.
> 
Yes 0 is for Main tier and 1 is for High tier. Since the flag by default
is main tier and it can be used for both the tiers I just kept the name
as "TIER_FLAG"

> > +   case V4L2_CID_MPEG_VIDEO_HEVC_RC_FRAME_RATE:return "HEVC 
> > Frame rate";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH:  return "HEVC 
> > Maximum coding unit depth";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_REF_NUMBER_FOR_PFRAMES:   return "HEVC 
> > Number of reference picture";
> 
> What is purpose of this control? Macro name suggest sth different than
> string.
> 
Sorry the description should have been "Number of reference frames for
P-Frame". P-frame can use 1 or 2 frames for reference.

> > +   case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE: return "HEVC 
> > refresh type";
> 
> Could you enumerate these refresh types, in patch 9 and documentation,
> maybe it would be worth to make it menu.
> 
There are 3 refresh types : None, CRA, IDR. I will add more details in
the Documentation patch and in the menu on this.

> > +   case V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED_ENABLE:  return "HEVC 
> > constant intra prediction enabled";
> > +   case

cron job: media_tree daily build: WARNINGS

2017-02-12 Thread Hans Verkuil 
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Mon Feb 13 05:00:15 CET 2017
media-tree git hash:9eeb0ed0f30938f31a3d9135a88b9502192c18dd
media_build git hash:   785cdf7f0798964681b33aad44fc2ff4d734733d
v4l-utils git hash: beb8f75b18b9014b49e0efaee7d6a6bff9cdec8c
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.8.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: WARNINGS
linux-3.12.67-i686: WARNINGS
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-rc3-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: WARNINGS
linux-3.12.67-x86_64: WARNINGS
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: OK
linux-4.9-x86_64: OK
linux-4.10-rc3-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH 0/3] Add support for MyGica T230C DVB-T2 stick

2017-02-12 Thread Antti Palosaari 

On 02/12/2017 05:26 PM, Stefan Brüns wrote:

The required command sequence for the new tuner (Si2141) was traced from the
current Windows driver and verified with a small python script/libusb.
The changes to the Si2168 and cxusb driver are mostly addition of the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] cxusb: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 -
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb/cxusb.c | 80 +--
 6 files changed, 106 insertions(+), 6 deletions(-)



Patch set looks pretty correct, but remote controller is something I 
hope you could fix. Old T230 did it wrong and defined 
rc_map_d680_dmb_table whilst proper map is 
RC_MAP_TOTAL_MEDIA_IN_HAND_02. Secondly it should be converted to 
rc-core. Even those are wrong for old revision, for new devices those 
should be done correct.


regards
Antti
--
http://palosaari.fi/

Re: [PATCH 2/2] [media] cx231xx: Fix I2C on Internal Master 3 Bus

2017-02-12 Thread Antti Palosaari 

On 02/07/2017 09:35 PM, Oleh Kravchenko wrote:

Internal Master 3 Bus can send and receive only 4 bytes per time.

Signed-off-by: Oleh Kravchenko 
---
 drivers/media/usb/cx231xx/cx231xx-core.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-core.c 
b/drivers/media/usb/cx231xx/cx231xx-core.c
index 550ec93..46646ec 100644
--- a/drivers/media/usb/cx231xx/cx231xx-core.c
+++ b/drivers/media/usb/cx231xx/cx231xx-core.c
@@ -355,7 +355,12 @@ int cx231xx_send_vendor_cmd(struct cx231xx *dev,
 */
if ((ven_req->wLength > 4) && ((ven_req->bRequest == 0x4) ||
(ven_req->bRequest == 0x5) ||
-   (ven_req->bRequest == 0x6))) {
+   (ven_req->bRequest == 0x6) ||
+
+   /* Internal Master 3 Bus can send
+* and receive only 4 bytes per time
+*/
+   (ven_req->bRequest == 0x2))) {
unsend_size = 0;
pdata = ven_req->pBuff;




Good that you finally got i2c fixed properly and get rid of that ugly 
device specific hack.


That new comment still does not open for me, why you call i2c bus tuner 
sits as internal?


There is now commands 2, 4, 5, and 6 that should be split to 4 byte 
long, is there any vendor command that could be longer? Maybe you could 
just add single comment which states what all those 4 commands are.


Your patches are still on wrong order - you should first fix i2c and 
after that add device support.


regards
Antti
--
http://palosaari.fi/

[PATCH] v4l: vsp1: Fix WPF U/V order in 3-planar formats on Gen3

2017-02-12 Thread Laurent Pinchart 
The WPF U/V order bit has no effect for 3-planar formats on Gen3
hardware. Swap the U and V planes manually instead in that case.

Fixes: b915bd24a034 ("[media] v4l: vsp1: Add tri-planar memory formats support")
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_wpf.c | 9 +
 1 file changed, 9 insertions(+)

This makes the vsp-unit-test-0002.sh test pass on both H2 and H3.

diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
b/drivers/media/platform/vsp1/vsp1_wpf.c
index 7c48f81cd5c1..052a83e2d489 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -216,6 +216,7 @@ static void wpf_configure(struct vsp1_entity *entity,
 
if (params == VSP1_ENTITY_PARAMS_PARTITION) {
const struct v4l2_pix_format_mplane *format = >format;
+   const struct vsp1_format_info *fmtinfo = wpf->fmtinfo;
struct vsp1_rwpf_memory mem = wpf->mem;
unsigned int flip = wpf->flip.active;
unsigned int width = source_format->width;
@@ -281,6 +282,14 @@ static void wpf_configure(struct vsp1_entity *entity,
}
}
 
+   /*
+* On Gen3 hardware the SPUVS bit has no effect on 3-planar
+* formats. Swap the U and V planes manually in that case.
+*/
+   if (vsp1->info->gen == 3 && format->num_planes == 3 &&
+   fmtinfo->swap_uv)
+   swap(mem.addr[1], mem.addr[2]);
+
vsp1_wpf_write(wpf, dl, VI6_WPF_DSTM_ADDR_Y, mem.addr[0]);
vsp1_wpf_write(wpf, dl, VI6_WPF_DSTM_ADDR_C0, mem.addr[1]);
vsp1_wpf_write(wpf, dl, VI6_WPF_DSTM_ADDR_C1, mem.addr[2]);
-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver

2017-02-12 Thread Steve Longerbeam 

(resending text only)


On 02/02/2017 02:36 AM, Laurent Pinchart wrote:

Hi Steve,

Thank you for the patch. Many of the comments below apply to the ov5642 driver
too, please take them into account when reworking patch 23/24.

On Friday 06 Jan 2017 18:11:40 Steve Longerbeam wrote:

This driver is based on ov5640_mipi.c from Freescale imx_3.10.17_1.0.0_beta
branch, modified heavily to bring forward to latest interfaces and code
cleanup.

Signed-off-by: Steve Longerbeam
---
  drivers/staging/media/imx/Kconfig   |8 +
  drivers/staging/media/imx/Makefile  |2 +
  drivers/staging/media/imx/ov5640-mipi.c | 2348 

You're missing DT bindings.


Done, created Documentation/devicetree/bindings/media/i2c/ov5640.txt.


The driver should go to drivers/media/i2c/ as it should not be specific to the
i.MX6, and you can just call it ov5640.c.


Done.


diff --git a/drivers/staging/media/imx/Kconfig
b/drivers/staging/media/imx/Kconfig index ce2d2c8..09f373d 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -17,5 +17,13 @@ config VIDEO_IMX_CAMERA
---help---
  A video4linux camera capture driver for i.MX5/6.

+config IMX_OV5640_MIPI
+   tristate "OmniVision OV5640 MIPI CSI-2 camera support"
+   depends on GPIOLIB && VIDEO_IMX_CAMERA

The sensor driver is generic, it shouldn't depend on IMX. It should however
depend on at least I2C and OF by the look of it.


Done.




+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

Pet peeve of mine, please sort the headers alphabetically. It makes it easier
to locate duplicated.


Fixed.


+
+#define OV5640_CHIP_ID  0x300A
+#define OV5640_SLAVE_ID 0x3100
+#define OV5640_DEFAULT_SLAVE_ID 0x3c

You're mixing lower-case and upper-case hex constants. Let's pick one. Kernel
code usually favours lower-case.


Fixed.


Please define macros for all the other numerical constants you use in the
driver (register addresses and values). The large registers tables can be an
exception if you don't have access to the information, but for registers
written manually, hardcoding numerical values isn't good.


Done.


+
+#define OV5640_MAX_CONTROLS 64
+
+enum ov5640_mode {
+   ov5640_mode_MIN = 0,
+   ov5640_mode_QCIF_176_144 = 0,
+   ov5640_mode_QVGA_320_240,
+   ov5640_mode_VGA_640_480,
+   ov5640_mode_NTSC_720_480,
+   ov5640_mode_PAL_720_576,
+   ov5640_mode_XGA_1024_768,
+   ov5640_mode_720P_1280_720,
+   ov5640_mode_1080P_1920_1080,
+   ov5640_mode_QSXGA_2592_1944,
+   ov5640_num_modes,
+   ov5640_mode_INIT = 0xff, /*only for sensor init*/

Please add spaces after /* and before */.

Enumerated values should be all upper-case.


Fixed (and ov5640_mode_INIT is removed).

+
+/* image size under 1280 * 960 are SUBSAMPLING
+ * image size upper 1280 * 960 are SCALING
+ */

The kernel multi-line comment style is

/*
  * text
  * text
  */


Fixed.


+
+struct ov5640_dev {
+   struct i2c_client *i2c_client;
+   struct device *dev;
+   struct v4l2_subdev sd;
+   struct media_pad pad;
+   struct v4l2_ctrl_handler ctrl_hdl;
+   struct v4l2_of_endpoint ep; /* the parsed DT endpoint info */
+   struct v4l2_mbus_framefmt fmt;
+   struct v4l2_captureparm streamcap;
+   struct clk *xclk; /* system clock to OV5640 */
+   int xclk_freq;/* requested xclk freq from devicetree */
+
+   enum ov5640_mode current_mode;

Store a (const) pointer to the corresponding ov5640_mode_info instead, it will
simplify the code and allow you to get rid of the ov5640_mode enum.


Done.


+
+   int prev_sysclk, prev_hts;
+   int ae_low, ae_high, ae_target;

Can't these be unsigned int ?


yep, an old left-over Freescale-ism, fixed.


+
+static void ov5640_power(struct ov5640_dev *sensor, bool enable);
+static void ov5640_reset(struct ov5640_dev *sensor);
+static int ov5640_restore_ctrls(struct ov5640_dev *sensor);
+static int ov5640_set_agc(struct ov5640_dev *sensor, int value);
+static int ov5640_set_exposure(struct ov5640_dev *sensor, int value);
+static int ov5640_get_exposure(struct ov5640_dev *sensor);
+static int ov5640_set_gain(struct ov5640_dev *sensor, int value);
+static int ov5640_get_gain(struct ov5640_dev *sensor);

No forward declarations please. You should reorder functions as needed (and of
course still group related functions together).


Fixed.


+static struct reg_value ov5640_init_setting_30fps_VGA[] = {
+

+   {0x3a1f, 0x14, 0, 0}, {0x3008, 0x02, 0, 0}, {0x3c00, 0x04, 0, 300},
+};

You only use the delay feature of the registers tables twice, once after
writing the first two registers (to select the clock source and perform a
software reset) and once at the very end.


There is a delay in other places as well. There is a

Re: [PATCH 4/4] media-ctl: add colorimetry support

2017-02-12 Thread Sakari Ailus 
On Tue, Feb 07, 2017 at 05:08:50PM +0100, Philipp Zabel wrote:
> media-ctl can be used to propagate v4l2 subdevice pad formats from
> source pads of one subdevice to another one's sink pads. These formats
> include colorimetry information, so media-ctl should be able to print
> or change it using the --set/get-v4l2 option.
> 
> Signed-off-by: Philipp Zabel 

Acked-by: Sakari Ailus 

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

Re: [PATCH 3/4] media-ctl: propagate frame interval

2017-02-12 Thread Sakari Ailus 
Hi Philipp,

On Tue, Feb 07, 2017 at 05:08:49PM +0100, Philipp Zabel wrote:
> Same as the media bus format, the frame interval should be propagated
> from output pads to connected entities' input pads.
> 
> Signed-off-by: Philipp Zabel 

Acked-by: Sakari Ailus 

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

Re: [PATCH 2/4] media-ctl: print the configured frame interval

2017-02-12 Thread Sakari Ailus 
On Tue, Feb 07, 2017 at 05:08:48PM +0100, Philipp Zabel wrote:
> After the pad format, also print the frame interval, if already configured.
> 
> Signed-off-by: Philipp Zabel 

Acked-by: Sakari Ailus 

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

Re: [PATCH 1/4] media-ctl: add pad support to set/get_frame_interval

2017-02-12 Thread Sakari Ailus 
Hi Philipp,

On Tue, Feb 07, 2017 at 05:08:47PM +0100, Philipp Zabel wrote:
> This allows to set and get the frame interval on pads other than pad 0.
> 
> Signed-off-by: Philipp Zabel 
> ---
>  utils/media-ctl/libv4l2subdev.c | 24 ++--
>  utils/media-ctl/v4l2subdev.h|  4 ++--
>  2 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
> index 3dcf943c..eadfc875 100644
> --- a/utils/media-ctl/libv4l2subdev.c
> +++ b/utils/media-ctl/libv4l2subdev.c
> @@ -262,7 +262,8 @@ int v4l2_subdev_set_dv_timings(struct media_entity 
> *entity,
>  }
>  
>  int v4l2_subdev_get_frame_interval(struct media_entity *entity,
> -struct v4l2_fract *interval)
> +struct v4l2_fract *interval,
> +unsigned int pad)
>  {
>   struct v4l2_subdev_frame_interval ival;
>   int ret;
> @@ -272,6 +273,7 @@ int v4l2_subdev_get_frame_interval(struct media_entity 
> *entity,
>   return ret;
>  
>   memset(, 0, sizeof(ival));
> + ival.pad = pad;
>  
>   ret = ioctl(entity->fd, VIDIOC_SUBDEV_G_FRAME_INTERVAL, );
>   if (ret < 0)
> @@ -282,7 +284,8 @@ int v4l2_subdev_get_frame_interval(struct media_entity 
> *entity,
>  }
>  
>  int v4l2_subdev_set_frame_interval(struct media_entity *entity,
> -struct v4l2_fract *interval)
> +struct v4l2_fract *interval,
> +unsigned int pad)
>  {
>   struct v4l2_subdev_frame_interval ival;
>   int ret;
> @@ -292,6 +295,7 @@ int v4l2_subdev_set_frame_interval(struct media_entity 
> *entity,
>   return ret;
>  
>   memset(, 0, sizeof(ival));
> + ival.pad = pad;
>   ival.interval = *interval;
>  
>   ret = ioctl(entity->fd, VIDIOC_SUBDEV_S_FRAME_INTERVAL, );
> @@ -617,7 +621,7 @@ static int set_selection(struct media_pad *pad, unsigned 
> int target,
>   return 0;
>  }
>  
> -static int set_frame_interval(struct media_entity *entity,
> +static int set_frame_interval(struct media_pad *pad,
> struct v4l2_fract *interval)
>  {
>   int ret;
> @@ -625,20 +629,20 @@ static int set_frame_interval(struct media_entity 
> *entity,
>   if (interval->numerator == 0)
>   return 0;
>  
> - media_dbg(entity->media,
> -   "Setting up frame interval %u/%u on entity %s\n",
> + media_dbg(pad->entity->media,
> +   "Setting up frame interval %u/%u on entity %s pad %u\n",

The usual notation for specifying the pad in debug messages has been
"%s/%u", entity, pad. Although the syntax appears to use %s:%u. So please
use %s/%u for now.

Acked-by: Sakari Ailus 

> interval->numerator, interval->denominator,
> -   entity->info.name);
> +   pad->entity->info.name, pad->index);
>  
> - ret = v4l2_subdev_set_frame_interval(entity, interval);
> + ret = v4l2_subdev_set_frame_interval(pad->entity, interval, pad->index);
>   if (ret < 0) {
> - media_dbg(entity->media,
> + media_dbg(pad->entity->media,
> "Unable to set frame interval: %s (%d)",
> strerror(-ret), ret);
>   return ret;
>   }
>  
> - media_dbg(entity->media, "Frame interval set: %u/%u\n",
> + media_dbg(pad->entity->media, "Frame interval set: %u/%u\n",
> interval->numerator, interval->denominator);
>  
>   return 0;
> @@ -685,7 +689,7 @@ static int v4l2_subdev_parse_setup_format(struct 
> media_device *media,
>   return ret;
>   }
>  
> - ret = set_frame_interval(pad->entity, );
> + ret = set_frame_interval(pad, );
>   if (ret < 0)
>   return ret;
>  
> diff --git a/utils/media-ctl/v4l2subdev.h b/utils/media-ctl/v4l2subdev.h
> index 9c8fee89..413094d5 100644
> --- a/utils/media-ctl/v4l2subdev.h
> +++ b/utils/media-ctl/v4l2subdev.h
> @@ -200,7 +200,7 @@ int v4l2_subdev_set_dv_timings(struct media_entity 
> *entity,
>   */
>  
>  int v4l2_subdev_get_frame_interval(struct media_entity *entity,
> - struct v4l2_fract *interval);
> + struct v4l2_fract *interval, unsigned int pad);
>  
>  /**
>   * @brief Set the frame interval on a sub-device.
> @@ -217,7 +217,7 @@ int v4l2_subdev_get_frame_interval(struct media_entity 
> *entity,
>   * @return 0 on success, or a negative error code on failure.
>   */
>  int v4l2_subdev_set_frame_interval(struct media_entity *entity,
> - struct v4l2_fract *interval);
> + struct v4l2_fract *interval, unsigned int pad);
>  
>  /**
>   * @brief Parse a string and apply format, crop and frame interval settings.
> -- 
> 2.11.0
> 

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

Re: Device Tree formatting for multiple virtual channels in ti-vpe/cal driver?

2017-02-12 Thread Sakari Ailus 
Hi Thomas,

On Fri, Feb 10, 2017 at 09:34:46AM +, Thomas Axelsson wrote:
> Hi,
> 
> I have a TI AM571x CPU, and I'm trying to add support for multiple MIPI
> CSI-2 virtual channels per PHY (port) to the ti-vpe/cal.c driver
> (CAMSS/CAL peripheral, ch. 8 in Datasheet [1]). This CPU can have more
> contexts (virtual channels) per PHY than what it has DMA handlers. Each
> PHY may have up to 8 contexts, and there are 2 PHYs, but there are only 8
> DMA channels in total. It is not required to use DMA to receive data from
> the context.

Is there a use case for receiving more than eight streams concurrently? I
have to admit that this does appear quite exotic if 8 would not suffice. How
does the data end up to the system memory if there's no DMA? PIO...?

What are the limitations otherwise --- how many PHYs can be used
simultaneously? Are the 8 DMAs shared among all?

>  
> Since it will be very useful to specify which contexts will use DMA and which 
> will 
> not, the proper place to do this seems to be the device tree.
>  
> This becomes rather messy though, since it needs to be specified in the 
> device tree 
> node pointed to by the remote-endpoint field - yet, it's decided by the 
> capabilities 
> of the master component (in this case the CAL), so the remote-endpoint is a 
> weird 
> place to put it.
>  
> I have made an example [2] using the Device Tree example in 
> Documentation/devicetree/bindings/media/ti-cal.txt (my own comments).
> In the ar0330_1 endpoint, I have:
> * Put multiple virtual channels in "reg", as in 
>   Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt,
> * Added "dma-write" for specifying which virtual channels should get written 
>   directly to memory through DMA,
> * Added "vip" just to show that a Virtual Channel can go somewhere else than 
>   through DMA write.
> * Added "pix-proc" to show that pixel processing might be applied to some of 
> the 
>   Virtual Channels.
>  
> What is your advice on how to properly move forward with adding support like 
> this?
> 
> Thank you in advance.
> 
> Best regards,
> Thomas Axelsson
>  
> 
> [1] http://www.ti.com/lit/gpn/am5716
>  
> [2]
> --
> cal: cal@4845b000 {
> compatible = "ti,dra72-cal";
> ti,hwmods = "cal";
>  
> /* snip */
>  
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> csi2_0: port@0 {
> reg = <0>; /* PHY index, must match port 
> index */
> status = "okay";   /* Enable */
> endpoint {
> slave-mode;
> remote-endpoint = <_1>;
> };
> };
> csi2_1: port@1 {
> reg = <1>; /* PHY Index */
> };
> };
> };
>  
> i2c5: i2c@4807c000 {
> ar0330@10 {
> compatible = "ti,ar0330";
> reg = <0x10>;
> port {
> #address-cells = <1>;
> #size-cells = <0>;
> ar0330_1: endpoint {
> reg = <0 1 2>; /* Virtual Channels */
> dma-write = <0 2>; /* Virtual Channels that will 
> use 
>   Write DMA */
> vip = <1>; /* Virtual Channel to send on 
> to 
>   Video Input Port */
> pix-proc = <2>;/* Virtual channels to apply 
> pixel
>   processing on */
> clock-lanes = <1>; /* Clock lane indices */
> data-lanes = <0 2 3 4>;/* Data lane indices */
> remote-endpoint = <_0>;
> };
> };
> };
> };

-- 
Kind regards,

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

Re: [PATCH] smiapp: add CCP2 support

2017-02-12 Thread Sakari 
Hi Pavel,

On Sun, Feb 12, 2017 at 12:22:58AM +0100, Pavel Machek wrote:
> Hi!
> 
> > Besides this patch, what else is needed? The CSI-2 / CCP2 support is
> > missing in V4L2 OF at least. It'd be better to have this all in the same
> > set.
> 
> Quite a lot of is needed.
> 
> > I pushed the two DT patches here:
> > 
> > 
> 
> Thanks for a branch. If you could the two patches that look ok there,
> it would mean less work for me, I could just mark those two as applied
> here.

I think a verb could be missing from the sentence. :-) I'll send a pull
request for the entire set, containing more than just the DT changes. Feel
free to base yours on top of this.

A word of warning: I have patches to replace the V4L2 OF framework by V4L2
fwnode. The preliminary set (which is still missing V4L2 OF removal) is
here, I'll post a refresh soon:



Let's see what the order ends up to be in the end. If the fwnode set is
applicable first, then I'd like to rebase the lane parsing changes on top of
that rather than the other way around --- it's easier that way.

> 
> Core changes for CSI2 support are needed.

CCP2? We could get these and the smiapp and possibly also the omap3isp
patches in first, to avoid having to manage a large patchset. What do you
think?

The rest could come later.

> 
> There are core changes in notifier locking, and subdev support.
> 
> I need video-bus-switch, at least for testing.
> 
> I need subdev support for omap3isp, so that we can attach flash and
> focus devices.
> 
> Finally dts support on N900 can be enabled.

Yes! 8-)

I don't know if any euros were saved by using that video bus switch but it
sure has caused a lot of hassle (and perhaps some gray hair) for software
engineers. X-)

-- 
Kind regards,

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

[PATCH] Staging: media: bcm2048: Fixed coding style issue.

2017-02-12 Thread Ran Algawi 
Fixed a coding style issue, where an octal value was needed insted of decimal.

Signed-off-by: Ran Algawi 
---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 37bd439..d605c41 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -300,7 +300,7 @@ struct bcm2048_device {
 };
 
 static int radio_nr = -1;  /* radio device minor (-1 ==> auto assign) */
-module_param(radio_nr, int, 0);
+module_param(radio_nr, int, );
 MODULE_PARM_DESC(radio_nr,
 "Minor number for radio device (-1 ==> auto assign)");
 
-- 
2.7.4

Re: [PATCH] Staging: media: bcm2048: Fixed an error

2017-02-12 Thread Greg Kroah-Hartman 
On Sun, Feb 12, 2017 at 11:12:42PM +0200, Ran Algawi wrote:
> Hello Greg,
> First, I appreciate you taking the time to educate me. I used the checkpatch
> script on the file I fixed and he reported the line as an error. Do you
> consider all checkpatch warnings/error/checks as coding style fixes?

The ones that refer to coding style issues, yes, that is what they are.
Sometimes the script points out other things that should be changed,
like octal values which is not an error in this case, but rather a
clarification.

And please turn html off in your email client, it gets rejected by the
mailing lists :)

thanks,

greg k-h

Re: [PATCH] Staging: media: bcm2048: Fixed an error

2017-02-12 Thread Ran Algawi 
Hello Greg,
I apperaciate you taking the time to educate me.
Do you consider all checkpatch errors/warnnings/checks as code style
fixes?
With regards,
Ran A.

[PATCH] media: rc: nuvoton: fix deadlock in nvt_write_wakeup_codes

2017-02-12 Thread Heiner Kallweit 
nvt_write_wakeup_codes acquires the same lock as the ISR but doesn't
disable interrupts on the local CPU. This caused the following
deadlock. Fix this by using spin_lock_irqsave.

[  432.362008] 
[  432.362074] WARNING: inconsistent lock state
[  432.362144] 4.10.0-rc7-next-20170210 #1 Not tainted
[  432.362219] 
[  432.362286] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[  432.362379] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[  432.362457]  (&(>lock)->rlock){?.+...}, at: [] 
nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[  432.362611] {HARDIRQ-ON-W} state was registered at:
[  432.362686]
[  432.362698] [] __lock_acquire+0x5dc/0x1260
[  432.362812]
[  432.362817] [] lock_acquire+0xe9/0x1d0
[  432.362927]
[  432.362934] [] _raw_spin_lock+0x33/0x50
[  432.363045]
[  432.363051] [] nvt_write_wakeup_codes.isra.12+0x22/0xe0 
[nuvoton_cir]
[  432.363193]
[  432.363199] [] wakeup_data_store+0xdf/0xf0 [nuvoton_cir]
[  432.363327]
[  432.36] [] dev_attr_store+0x13/0x20
[  432.363441]
[  432.363449] [] sysfs_kf_write+0x40/0x50
[  432.363558]
[  432.363564] [] kernfs_fop_write+0x150/0x1e0
[  432.363676]
[  432.363685] [] __vfs_write+0x23/0x120
[  432.363791]
[  432.363798] [] vfs_write+0xc3/0x1e0
[  432.363902]
[  432.363909] [] SyS_write+0x44/0xa0
[  432.364012]
[  432.364021] [] do_syscall_64+0x57/0x140
[  432.364129]
[  432.364135] [] return_from_SYSCALL_64+0x0/0x7a
[  432.364252] irq event stamp: 415118
[  432.364313] hardirqs last  enabled at (415115): [] 
cpuidle_enter_state+0x11b/0x370
[  432.364445] hardirqs last disabled at (415116): [] 
common_interrupt+0x8b/0x90
[  432.364573] softirqs last  enabled at (415118): [] 
_local_bh_enable+0x1c/0x50
[  432.364699] softirqs last disabled at (415117): [] 
irq_enter+0x43/0x60
[  432.364814]
   other info that might help us debug this:
[  432.364909]  Possible unsafe locking scenario:

[  432.367821]CPU0
[  432.370645]
[  432.373432]   lock(&(>lock)->rlock);
[  432.376228]   
[  432.378982] lock(&(>lock)->rlock);
[  432.381757]
*** DEADLOCK ***

[  432.389888] no locks held by swapper/0/0.
[  432.392574]
   stack backtrace:
[  432.397774] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.10.0-rc7-next-20170210 #1
[  432.400375] Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS 
B246P105 06/01/2015
[  432.403023] Call Trace:
[  432.405636]  
[  432.408208]  dump_stack+0x68/0x93
[  432.410775]  print_usage_bug+0x1dd/0x1f0
[  432.413334]  mark_lock+0x559/0x5c0
[  432.415871]  ? print_shortest_lock_dependencies+0x1a0/0x1a0
[  432.418431]  __lock_acquire+0x6b1/0x1260
[  432.420941]  lock_acquire+0xe9/0x1d0
[  432.423396]  ? nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[  432.425844]  _raw_spin_lock+0x33/0x50
[  432.428252]  ? nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[  432.430670]  nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[  432.433085]  __handle_irq_event_percpu+0x43/0x330
[  432.435493]  handle_irq_event_percpu+0x1e/0x50
[  432.437884]  handle_irq_event+0x34/0x60
[  432.440236]  handle_edge_irq+0x6a/0x150
[  432.442561]  handle_irq+0x15/0x20
[  432.444854]  do_IRQ+0x57/0x110
[  432.447115]  common_interrupt+0x90/0x90
[  432.449380] RIP: 0010:cpuidle_enter_state+0x120/0x370
[  432.451653] RSP: 0018:81c03dd8 EFLAGS: 0206 ORIG_RAX: 
ffcc
[  432.453994] RAX: 81c14500 RBX: 0008 RCX: 0064aac6f2d2
[  432.456349] RDX:  RSI: 0001 RDI: 81c14500
[  432.458704] RBP: 81c03e18 R08: cccd R09: 0018
[  432.461072] R10:  R11:  R12: 880100a21260
[  432.463450] R13: 81c7e6f8 R14: 0008 R15: 81c7e6e0
[  432.465819]  
[  432.468104]  ? cpuidle_enter_state+0x11b/0x370
[  432.470413]  cpuidle_enter+0x12/0x20
[  432.472698]  call_cpuidle+0x1e/0x40
[  432.474967]  do_idle+0xe3/0x1c0
[  432.477172]  cpu_startup_entry+0x18/0x20
[  432.479376]  rest_init+0x130/0x140
[  432.481565]  start_kernel+0x3cc/0x3d9
[  432.483750]  x86_64_start_reservations+0x2a/0x2c
[  432.485980]  x86_64_start_kernel+0x178/0x18b
[  432.488222]  start_cpu+0x14/0x14
[  432.490453]  ? start_cpu+0x14/0x14

Fixes: 97c129747af5 "[media] rc: nuvoton-cir: Add support wakeup via sysfs 
filter callback"
Signed-off-by: Heiner Kallweit 
---
 drivers/media/rc/nuvoton-cir.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index b109f824..ec4b25bd 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -176,12 +176,13 @@ static void nvt_write_wakeup_codes(struct rc_dev *dev,
 {
u8 tolerance, config;
struct nvt_dev *nvt = dev->priv;
+   unsigned long flags;
int i;
 
/* hardcode the tolerance to 10% */
tolerance = DIV_ROUND_UP(count, 10);
 
-   spin_lock(>lock);

Re: [PATCH RESEND 1/1] media: platform: Renesas IMR driver

2017-02-12 Thread Laurent Pinchart 
Hi Sergei,

(CC'ing the dri-evel mailing list)

Thank you for the patch.

On Saturday 11 Feb 2017 23:02:01 Sergei Shtylyov wrote:
> From: Konstantin Kozhevnikov 
> 
> The image renderer light extended 4 (IMR-LX4) or the distortion correction
> engine is a drawing processor with a simple  instruction system capable of
> referencing data on an external memory as 2D texture data and performing
> texture mapping and drawing with respect to any shape that is split into
> triangular objects.
> 
> This V4L2 memory-to-memory device driver only supports image renderer found
> in the R-Car gen3 SoCs; the R-Car gen2 support  can be added later...

Let's start with the main question : given that this is a rendering engine, it 
looks like it should use the DRM subsystem.

> [Sergei: merged 2 original patches, added the patch description, removed
> unrelated parts,  added the binding document, ported the driver to the
> modern kernel, renamed the UAPI header file and the guard  macros to match
> the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
> help, made use of the BIT()/GENMASK() macros, sorted #include's, removed
> leading  dots and fixed grammar in the comments, fixed up indentation to
> use tabs where possible, renamed IMR_DLSR to IMR_DLPR to match the manual,
> separated the register offset/bit #define's, removed *inline* from .c file,
> fixed lines over 80 columns, removed useless parens, operators, casts,
> braces, variables, #include's, (commented out) statements, and even
> function, inserted empty line after desclaration, removed extra empty
> lines, reordered some local variable desclarations, removed calls to
> 4l2_err() on kmalloc() failure, fixed the error returned by imr_default(),
> avoided code duplication in the IRQ handler, used '__packed' for the UAPI
> structures, enclosed the macro parameters in parens, exchanged the values
> of IMR_MAP_AUTO[SD]G macros.]
> 
> Signed-off-by: Konstantin Kozhevnikov
>  Signed-off-by: Sergei Shtylyov
> 
> 
> ---
> This patch is against the 'media_tree.git' repo's 'master' branch.
> 
>  Documentation/devicetree/bindings/media/rcar_imr.txt |   23
>  drivers/media/platform/Kconfig   |   13
>  drivers/media/platform/Makefile  |1
>  drivers/media/platform/rcar_imr.c| 1923 +++
>  include/uapi/linux/rcar_imr.h|   94
>  5 files changed, 2054 insertions(+)

-- 
Regards,

Laurent Pinchart

[PATCH 3/3] [media] cxusb: MyGica T230C support

2017-02-12 Thread Stefan Brüns 
Mygica T230 DVB-T/T2/C USB stick support. It uses the same FX2/Si2168
bridge/demodulator combo as the T230, but uses the Si2141 tuner.
Factor out the common code and pass the tuner type and if port as
parameter, to avoid duplicating the initialization code.

Signed-off-by: Stefan Brüns 
---
 drivers/media/dvb-core/dvb-usb-ids.h |  1 +
 drivers/media/usb/dvb-usb/cxusb.c| 80 ++--
 2 files changed, 77 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index a7a4674ccc40..ce4a3d574dd7 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -380,6 +380,7 @@
 #define USB_PID_SONY_PLAYTV0x0003
 #define USB_PID_MYGICA_D6890xd811
 #define USB_PID_MYGICA_T2300xc688
+#define USB_PID_MYGICA_T230C   0xc689
 #define USB_PID_ELGATO_EYETV_DIVERSITY 0x0011
 #define USB_PID_ELGATO_EYETV_DTT   0x0021
 #define USB_PID_ELGATO_EYETV_DTT_2 0x003f
diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index 9fd43a37154c..967f4f74309c 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1305,7 +1305,9 @@ static int cxusb_mygica_d689_frontend_attach(struct 
dvb_usb_adapter *adap)
return 0;
 }
 
-static int cxusb_mygica_t230_frontend_attach(struct dvb_usb_adapter *adap)
+static int cxusb_mygica_t230_common_frontend_attach(struct dvb_usb_adapter 
*adap,
+   const char *tuner_name,
+   u8 tuner_if_port)
 {
struct dvb_usb_device *d = adap->dev;
struct cxusb_state *st = d->priv;
@@ -1352,12 +1354,12 @@ static int cxusb_mygica_t230_frontend_attach(struct 
dvb_usb_adapter *adap)
/* attach tuner */
memset(_config, 0, sizeof(si2157_config));
si2157_config.fe = adap->fe_adap[0].fe;
-   si2157_config.if_port = 1;
+   si2157_config.if_port = tuner_if_port;
memset(, 0, sizeof(struct i2c_board_info));
-   strlcpy(info.type, "si2157", I2C_NAME_SIZE);
+   strlcpy(info.type, tuner_name, I2C_NAME_SIZE);
info.addr = 0x60;
info.platform_data = _config;
-   request_module(info.type);
+   request_module("si2157");
client_tuner = i2c_new_device(adapter, );
if (client_tuner == NULL || client_tuner->dev.driver == NULL) {
module_put(client_demod->dev.driver->owner);
@@ -1376,6 +1378,16 @@ static int cxusb_mygica_t230_frontend_attach(struct 
dvb_usb_adapter *adap)
return 0;
 }
 
+static int cxusb_mygica_t230_frontend_attach(struct dvb_usb_adapter *adap)
+{
+   return cxusb_mygica_t230_common_frontend_attach(adap, "si2157", 1);
+}
+
+static int cxusb_mygica_t230c_frontend_attach(struct dvb_usb_adapter *adap)
+{
+   return cxusb_mygica_t230_common_frontend_attach(adap, "si2141", 0);
+}
+
 /*
  * DViCO has shipped two devices with the same USB ID, but only one of them
  * needs a firmware download.  Check the device class details to see if they
@@ -1458,6 +1470,7 @@ static struct dvb_usb_device_properties 
cxusb_aver_a868r_properties;
 static struct dvb_usb_device_properties cxusb_d680_dmb_properties;
 static struct dvb_usb_device_properties cxusb_mygica_d689_properties;
 static struct dvb_usb_device_properties cxusb_mygica_t230_properties;
+static struct dvb_usb_device_properties cxusb_mygica_t230c_properties;
 
 static int cxusb_probe(struct usb_interface *intf,
   const struct usb_device_id *id)
@@ -1490,6 +1503,8 @@ static int cxusb_probe(struct usb_interface *intf,
 THIS_MODULE, NULL, adapter_nr) ||
0 == dvb_usb_device_init(intf, _mygica_t230_properties,
 THIS_MODULE, NULL, adapter_nr) ||
+   0 == dvb_usb_device_init(intf, _mygica_t230c_properties,
+THIS_MODULE, NULL, adapter_nr) ||
0)
return 0;
 
@@ -1541,6 +1556,7 @@ enum cxusb_table_index {
CONEXANT_D680_DMB,
MYGICA_D689,
MYGICA_T230,
+   MYGICA_T230C,
NR__cxusb_table_index
 };
 
@@ -1608,6 +1624,9 @@ static struct usb_device_id 
cxusb_table[NR__cxusb_table_index + 1] = {
[MYGICA_T230] = {
USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230)
},
+   [MYGICA_T230C] = {
+   USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230C)
+   },
{}  /* Terminating entry */
 };
 MODULE_DEVICE_TABLE (usb, cxusb_table);
@@ -2307,6 +2326,59 @@ static struct dvb_usb_device_properties 
cxusb_mygica_t230_properties = {
}
 };
 
+static struct dvb_usb_device_properties cxusb_mygica_t230c_properties = {
+

[PATCH 0/3] Add support for MyGica T230C DVB-T2 stick

2017-02-12 Thread Stefan Brüns 
The required command sequence for the new tuner (Si2141) was traced from the
current Windows driver and verified with a small python script/libusb.
The changes to the Si2168 and cxusb driver are mostly addition of the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] cxusb: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 -
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb/cxusb.c | 80 +--
 6 files changed, 106 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCH 1/3] [media] si2157: Add support for Si2141-A10

2017-02-12 Thread Stefan Brüns 
The Si2141 needs two distinct commands for powerup/reset, otherwise it
will not respond to chip revision requests. It also needs a firmware
to run properly.

Signed-off-by: Stefan Brüns 
---
 drivers/media/tuners/si2157.c  | 23 +--
 drivers/media/tuners/si2157_priv.h |  2 ++
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 57b250847cd3..e35b1faf0ddc 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -106,6 +106,9 @@ static int si2157_init(struct dvb_frontend *fe)
if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
cmd.wlen = 9;
+   } else if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x00\x0d\x0e\x00\x01\x01\x01\x01\x03", 
10);
+   cmd.wlen = 10;
} else {
memcpy(cmd.args, 
"\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01", 15);
cmd.wlen = 15;
@@ -115,6 +118,15 @@ static int si2157_init(struct dvb_frontend *fe)
if (ret)
goto err;
 
+   /* Si2141 needs a second command before it answers the revision query */
+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x08\x01\x02\x00\x00\x01", 7);
+   cmd.wlen = 7;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+   }
+
/* query chip revision */
memcpy(cmd.args, "\x02", 1);
cmd.wlen = 1;
@@ -131,12 +143,16 @@ static int si2157_init(struct dvb_frontend *fe)
#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)
+   #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
 
switch (chip_id) {
case SI2158_A20:
case SI2148_A20:
fw_name = SI2158_A20_FIRMWARE;
break;
+   case SI2141_A10:
+   fw_name = SI2141_A10_FIRMWARE;
+   break;
case SI2157_A30:
case SI2147_A30:
case SI2146_A10:
@@ -371,7 +387,7 @@ static int si2157_get_if_frequency(struct dvb_frontend *fe, 
u32 *frequency)
 
 static const struct dvb_tuner_ops si2157_ops = {
.info = {
-   .name   = "Silicon Labs Si2146/2147/2148/2157/2158",
+   .name   = "Silicon Labs 
Si2141/Si2146/2147/2148/2157/2158",
.frequency_min  = 4200,
.frequency_max  = 87000,
},
@@ -471,6 +487,7 @@ static int si2157_probe(struct i2c_client *client,
 #endif
 
dev_info(>dev, "Silicon Labs %s successfully attached\n",
+   dev->chiptype == SI2157_CHIPTYPE_SI2141 ?  "Si2141" :
dev->chiptype == SI2157_CHIPTYPE_SI2146 ?
"Si2146" : "Si2147/2148/2157/2158");
 
@@ -508,6 +525,7 @@ static int si2157_remove(struct i2c_client *client)
 static const struct i2c_device_id si2157_id_table[] = {
{"si2157", SI2157_CHIPTYPE_SI2157},
{"si2146", SI2157_CHIPTYPE_SI2146},
+   {"si2141", SI2157_CHIPTYPE_SI2141},
{}
 };
 MODULE_DEVICE_TABLE(i2c, si2157_id_table);
@@ -524,7 +542,8 @@ static struct i2c_driver si2157_driver = {
 
 module_i2c_driver(si2157_driver);
 
-MODULE_DESCRIPTION("Silicon Labs Si2146/2147/2148/2157/2158 silicon tuner 
driver");
+MODULE_DESCRIPTION("Silicon Labs Si2141/Si2146/2147/2148/2157/2158 silicon 
tuner driver");
 MODULE_AUTHOR("Antti Palosaari ");
 MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2158_A20_FIRMWARE);
+MODULE_FIRMWARE(SI2141_A10_FIRMWARE);
diff --git a/drivers/media/tuners/si2157_priv.h 
b/drivers/media/tuners/si2157_priv.h
index d6b2c7b44053..e6436f74abaa 100644
--- a/drivers/media/tuners/si2157_priv.h
+++ b/drivers/media/tuners/si2157_priv.h
@@ -42,6 +42,7 @@ struct si2157_dev {
 
 #define SI2157_CHIPTYPE_SI2157 0
 #define SI2157_CHIPTYPE_SI2146 1
+#define SI2157_CHIPTYPE_SI2141 2
 
 /* firmware command struct */
 #define SI2157_ARGLEN  30
@@ -52,5 +53,6 @@ struct si2157_cmd {
 };
 
 #define SI2158_A20_FIRMWARE "dvb-tuner-si2158-a20-01.fw"
+#define SI2141_A10_FIRMWARE "dvb-tuner-si2141-a10-01.fw"
 
 #endif
-- 
2.11.0

[PATCH 2/3] [media] si2168: add support for Si2168-D60

2017-02-12 Thread Stefan Brüns 
Add handling for new revision, requiring new firmware.

Signed-off-by: Stefan Brüns 
---
 drivers/media/dvb-frontends/si2168.c  | 4 
 drivers/media/dvb-frontends/si2168_priv.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 20b4a659e2e4..28f3bbe0af25 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -674,6 +674,9 @@ static int si2168_probe(struct i2c_client *client,
case SI2168_CHIP_ID_B40:
dev->firmware_name = SI2168_B40_FIRMWARE;
break;
+   case SI2168_CHIP_ID_D60:
+   dev->firmware_name = SI2168_D60_FIRMWARE;
+   break;
default:
dev_dbg(>dev, "unknown chip version Si21%d-%c%c%c\n",
cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
@@ -761,3 +764,4 @@ MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2168_A20_FIRMWARE);
 MODULE_FIRMWARE(SI2168_A30_FIRMWARE);
 MODULE_FIRMWARE(SI2168_B40_FIRMWARE);
+MODULE_FIRMWARE(SI2168_D60_FIRMWARE);
diff --git a/drivers/media/dvb-frontends/si2168_priv.h 
b/drivers/media/dvb-frontends/si2168_priv.h
index 7843ccb448a0..4baa95b7d648 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -25,6 +25,7 @@
 #define SI2168_A20_FIRMWARE "dvb-demod-si2168-a20-01.fw"
 #define SI2168_A30_FIRMWARE "dvb-demod-si2168-a30-01.fw"
 #define SI2168_B40_FIRMWARE "dvb-demod-si2168-b40-01.fw"
+#define SI2168_D60_FIRMWARE "dvb-demod-si2168-d60-01.fw"
 #define SI2168_B40_FIRMWARE_FALLBACK "dvb-demod-si2168-02.fw"
 
 /* state struct */
@@ -37,6 +38,7 @@ struct si2168_dev {
#define SI2168_CHIP_ID_A20 ('A' << 24 | 68 << 16 | '2' << 8 | '0' << 0)
#define SI2168_CHIP_ID_A30 ('A' << 24 | 68 << 16 | '3' << 8 | '0' << 0)
#define SI2168_CHIP_ID_B40 ('B' << 24 | 68 << 16 | '4' << 8 | '0' << 0)
+   #define SI2168_CHIP_ID_D60 ('D' << 24 | 68 << 16 | '6' << 8 | '0' << 0)
unsigned int chip_id;
unsigned int version;
const char *firmware_name;
-- 
2.11.0

[PATCH v2] [media] dvb-usb-firmware: don't do DMA on stack

2017-02-12 Thread Stefan Brüns 
The buffer allocation for the firmware data was changed in
commit 43fab9793c1f ("dvb-usb: don't use stack for firmware load"),
but the same applies for the reset value.

Signed-off-by: Stefan Brüns 
---
This patch replaces the earlier submission conflicting with commit
43fab9793c1f, which was a subset of the submitted patch.

 drivers/media/usb/dvb-usb/dvb-usb-firmware.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c 
b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
index 3271b3fee1f4..1f008f354282 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
@@ -36,16 +36,19 @@ static int usb_cypress_writemem(struct usb_device *udev,u16 
addr,u8 *data, u8 le
 int usb_cypress_load_firmware(struct usb_device *udev, const struct firmware 
*fw, int type)
 {
struct hexline *hx;
-   u8 reset;
+   u8 *buf;
+   u8 *reset;
int ret,pos=0;
+   u16 cpu_cs_register = cypress[type].cpu_cs_register;
 
-   hx = kmalloc(sizeof(*hx), GFP_KERNEL);
-   if (!hx)
+   buf = kmalloc(sizeof(*hx), GFP_KERNEL);
+   if (!buf)
return -ENOMEM;
+   hx = (struct hexline *)buf;
 
/* stop the CPU */
-   reset = 1;
-   if ((ret = 
usb_cypress_writemem(udev,cypress[type].cpu_cs_register,,1)) != 1)
+   buf[0] = 1;
+   if (usb_cypress_writemem(udev, cpu_cs_register, buf, 1) != 1)
err("could not stop the USB controller CPU.");
 
while ((ret = dvb_usb_get_hexline(fw, hx, )) > 0) {
@@ -61,21 +64,21 @@ int usb_cypress_load_firmware(struct usb_device *udev, 
const struct firmware *fw
}
if (ret < 0) {
err("firmware download failed at %d with %d",pos,ret);
-   kfree(hx);
+   kfree(buf);
return ret;
}
 
if (ret == 0) {
/* restart the CPU */
-   reset = 0;
-   if (ret || 
usb_cypress_writemem(udev,cypress[type].cpu_cs_register,,1) != 1) {
+   buf[0] = 0;
+   if (usb_cypress_writemem(udev, cpu_cs_register, buf, 1) != 1) {
err("could not restart the USB controller CPU.");
ret = -EINVAL;
}
} else
ret = -EIO;
 
-   kfree(hx);
+   kfree(buf);
 
return ret;
 }
-- 
2.11.0

Re: [PATCH] smiapp: add CCP2 support

2017-02-12 Thread kbuild test robot 
Hi Pavel,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.10-rc7 next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pavel-Machek/smiapp-add-CCP2-support/20170208-214729
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-it0-02122030 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/i2c/smiapp/smiapp-core.c: In function 'smiapp_get_hwconfig':
   drivers/media/i2c/smiapp/smiapp-core.c:2812:7: error: 'V4L2_MBUS_CCP2' 
undeclared (first use in this function)
 case V4L2_MBUS_CCP2:
  ^
   drivers/media/i2c/smiapp/smiapp-core.c:2812:7: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/media/i2c/smiapp/smiapp-core.c:2813:45: error: 'union ' 
>> has no member named 'mipi_csi1'
  hwcfg->csi_signalling_mode = (bus_cfg->bus.mipi_csi1.strobe) ?
^

vim +2813 drivers/media/i2c/smiapp/smiapp-core.c

  2806  
  2807  switch (bus_cfg->bus_type) {
  2808  case V4L2_MBUS_CSI2:
  2809  hwcfg->csi_signalling_mode = 
SMIAPP_CSI_SIGNALLING_MODE_CSI2;
  2810  hwcfg->lanes = bus_cfg->bus.mipi_csi2.num_data_lanes;
  2811  break;
> 2812  case V4L2_MBUS_CCP2:
> 2813  hwcfg->csi_signalling_mode = 
> (bus_cfg->bus.mipi_csi1.strobe) ?
  2814  SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_STROBE :
  2815  SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_CLOCK;
  2816  hwcfg->lanes = 1;

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


.config.gz
Description: application/gzip

Re: [PATCHv2] v4l: split lane parsing code

2017-02-12 Thread Pavel Machek 
Hi!

> The patch looks good to me. Could you post a patchset containing all the
> needed patches, maybe on top of the DT patches in the ccp2 branch, please?
> It'd be easier to handle this that way.

Ok, will do.

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


signature.asc
Description: Digital signature

Re: [PATCH] Staging: media: bcm2048: Fixed an error

2017-02-12 Thread Greg KH 
On Sat, Feb 11, 2017 at 12:41:29AM +0200, Ran Algawi wrote:
> Fixed an error where the system was given a code in the form of decimal
> instead of octal.

It's not really an "error", right?  Please be more descriptive of
exactly what is going on here (hint, it's a coding style warning...)

thanks,

greg k-h