cron job: media_tree daily build: ERRORS

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

Results of the daily build of media_tree:

date:   Fri Jan  5 05:00:16 CET 2018
media-tree git hash:6f0e5fd39143a59c22d60e7befc4f33f22aeed2f
media_build git hash:   46c9dc0a08499791cedfc7ee0df387e475f075a2
v4l-utils git hash: 8aa401d119afaeb1b4fe4d2994789cd3e9396554
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3911-g6f737e1f
smatch version: v0.5.0-3911-g6f737e1f
host hardware:  x86_64
host os:4.13.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: 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: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: 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: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9.26-i686: WARNINGS
linux-4.10.14-i686: WARNINGS
linux-4.11-i686: WARNINGS
linux-4.12.1-i686: WARNINGS
linux-4.13-i686: WARNINGS
linux-4.14-i686: WARNINGS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: 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: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: 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: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: WARNINGS
linux-4.14-x86_64: WARNINGS
apps: OK
spec-git: OK
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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


Re: [PATCH 7/9] lgdt3306a: Set fe ops.release to NULL if probed

2018-01-04 Thread Brad Love


On 2018-01-04 18:19, Michael Ira Krufky wrote:
> On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
>> If release is part of frontend ops then it is called in the
>> course of dvb_frontend_detach. The process also decrements
>> the module usage count. The problem is if the lgdt3306a
>> driver is reached via i2c_new_device, then when it is
>> eventually destroyed remove is called, which further
>> decrements the module usage count to negative. After this
>> occurs the driver is in a bad state and no longer works.
>> Also fixed by NULLing out the release callback is a double
>> kfree of state, which introduces arbitrary oopses/GPF.
>> This problem is only currently reachable via the em28xx driver.
>>
>> On disconnect of Hauppauge SoloHD before:
>>
>> lsmod | grep lgdt3306a
>> lgdt3306a  28672  -1
>> i2c_mux16384  1 lgdt3306a
>>
>> On disconnect of Hauppauge SoloHD after:
>>
>> lsmod | grep lgdt3306a
>> lgdt3306a  28672  0
>> i2c_mux16384  1 lgdt3306a
>>
>> Signed-off-by: Brad Love 
>> ---
>>  drivers/media/dvb-frontends/lgdt3306a.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
> Brad,
>
> We won't be able to apply this one.  The symptom that you're trying to
> fix is indicative of some other problem, probably in the em28xx
> driver.  NULL'ing the release callback is not the right thing to do.
>
> -Mike Krufky

Hey Mike,

Redacting this patch to deal with individually. I will separately send
to the list an example of another bridge driver which exhibits the same
issue, when using the lgdt3306a driver similarly. I don't think this is
solely an em28xx issue. I will also send a patch fixing only the double
free, as that seems to be most important.

Cheers,

Brad





>> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
>> b/drivers/media/dvb-frontends/lgdt3306a.c
>> index 6356815..d2477ed 100644
>> --- a/drivers/media/dvb-frontends/lgdt3306a.c
>> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
>> @@ -2177,6 +2177,7 @@ static int lgdt3306a_probe(struct i2c_client *client,
>>
>> i2c_set_clientdata(client, fe->demodulator_priv);
>> state = fe->demodulator_priv;
>> +   state->frontend.ops.release = NULL;
>>
>> /* create mux i2c adapter for tuner */
>> state->muxc = i2c_mux_alloc(client->adapter, >dev,
>> --
>> 2.7.4
>>




Re: [PATCH 8/9] lgdt3306a: QAM streaming improvement

2018-01-04 Thread Brad Love


On 2018-01-04 18:26, Michael Ira Krufky wrote:
> On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
>> Add some register updates required for stable viewing
>> on Cablevision in NY. Does not adversely affect other providers.
>>
>> Signed-off-by: Brad Love 
>> ---
>>  drivers/media/dvb-frontends/lgdt3306a.c | 22 ++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
>> b/drivers/media/dvb-frontends/lgdt3306a.c
>> index d2477ed..2f540f1 100644
>> --- a/drivers/media/dvb-frontends/lgdt3306a.c
>> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
>> @@ -598,6 +598,28 @@ static int lgdt3306a_set_qam(struct lgdt3306a_state 
>> *state, int modulation)
>> if (lg_chkerr(ret))
>> goto fail;
>>
>> +   /* 5.1 V0.36 SRDCHKALWAYS : For better QAM detection */
>> +   ret = lgdt3306a_read_reg(state, 0x000A, );
>> +   val &= 0xFD;
>> +   val |= 0x02;
>> +   ret = lgdt3306a_write_reg(state, 0x000A, val);
>> +   if (lg_chkerr(ret))
>> +   goto fail;
>> +
>> +   /* 5.2 V0.36 Control of "no signal" detector function */
>> +   ret = lgdt3306a_read_reg(state, 0x2849, );
>> +   val &= 0xDF;
>> +   ret = lgdt3306a_write_reg(state, 0x2849, val);
>> +   if (lg_chkerr(ret))
>> +   goto fail;
>> +
>> +   /* 5.3 Fix for Blonder Tongue HDE-2H-QAM and AQM modulators */
>> +   ret = lgdt3306a_read_reg(state, 0x302B, );
>> +   val &= 0x7F;  /* SELFSYNCFINDEN_CQS=0; disable auto reset */
>> +   ret = lgdt3306a_write_reg(state, 0x302B, val);
>> +   if (lg_chkerr(ret))
>> +   goto fail;
>> +
>> /* 6. Reset */
>> ret = lgdt3306a_soft_reset(state);
>> if (lg_chkerr(ret))
> Brad,
>
> The change looks good, but can you resubmit this using lowercase hex?
>
> Cheers,
>
> Michael Ira Krufky

Done, v2 submitted.



[PATCH v2 8/9] lgdt3306a: QAM streaming improvement

2018-01-04 Thread Brad Love
Add some register updates required for stable viewing
on Cablevision in NY. Does not adversely affect other providers.

Changes since v1:
- Change upper case hex to lower case.

Signed-off-by: Brad Love 
---
 drivers/media/dvb-frontends/lgdt3306a.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
b/drivers/media/dvb-frontends/lgdt3306a.c
index d2477ed..2f540f1 100644
--- a/drivers/media/dvb-frontends/lgdt3306a.c
+++ b/drivers/media/dvb-frontends/lgdt3306a.c
@@ -598,6 +598,28 @@ static int lgdt3306a_set_qam(struct lgdt3306a_state 
*state, int modulation)
if (lg_chkerr(ret))
goto fail;
 
+   /* 5.1 V0.36 SRDCHKALWAYS : For better QAM detection */
+   ret = lgdt3306a_read_reg(state, 0x000a, );
+   val &= 0xfd;
+   val |= 0x02;
+   ret = lgdt3306a_write_reg(state, 0x000a, val);
+   if (lg_chkerr(ret))
+   goto fail;
+
+   /* 5.2 V0.36 Control of "no signal" detector function */
+   ret = lgdt3306a_read_reg(state, 0x2849, );
+   val &= 0xdf;
+   ret = lgdt3306a_write_reg(state, 0x2849, val);
+   if (lg_chkerr(ret))
+   goto fail;
+
+   /* 5.3 Fix for Blonder Tongue HDE-2H-QAM and AQM modulators */
+   ret = lgdt3306a_read_reg(state, 0x302b, );
+   val &= 0x7f;  /* SELFSYNCFINDEN_CQS=0; disable auto reset */
+   ret = lgdt3306a_write_reg(state, 0x302b, val);
+   if (lg_chkerr(ret))
+   goto fail;
+
/* 6. Reset */
ret = lgdt3306a_soft_reset(state);
if (lg_chkerr(ret))
-- 
2.7.4



RE: [RESEND PATCH 0/2] dw9714 fixes, cleanups

2018-01-04 Thread Mani, Rajmohan
Hi Sakari,

Thanks for the patches.

> -Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com]
> Sent: Tuesday, January 02, 2018 3:12 AM
> To: linux-media@vger.kernel.org
> Cc: Mani, Rajmohan 
> Subject: [RESEND PATCH 0/2] dw9714 fixes, cleanups
> 
> Hi,
> 
> (Fixed Raj's e-mail.)
> 
> The two patches address a small bug in dw9714 driver and clean it up a little,
> too.
> 
> Raj: could you let me know if they work for you? Thanks.
> 

These patches work fine.

> 
> Sakari Ailus (2):
>   dw9714: Call pm_runtime_idle() at the end of probe()
>   dw9714: Remove client field in driver's struct
> 
>  drivers/media/i2c/dw9714.c | 20 ++--
>  1 file changed, 6 insertions(+), 14 deletions(-)
> 
> --
> 2.7.4



Re: [PATCH 9/9] lgdt3306a: Add QAM AUTO support

2018-01-04 Thread Michael Ira Krufky
On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
> As configured currently, modulation in the driver is set to auto detect,
> no matter what the user sets modulation to. This leads to both QAM64
> and QAM256 having the same effect. QAM AUTO is explicitly added here for
> compatibility with scanning software who can use AUTO instead of doing
> essentially the same scan twice.
> Also included is a module option to enforce a specific QAM modulation if
> desired. The true modulation is read before calculating the snr.
> Changes are backwards compatible with current behaviour.
>
> Signed-off-by: Brad Love 

:+1

Reviewed-by: Michael Ira Krufky 

> ---
>  drivers/media/dvb-frontends/lgdt3306a.c | 42 
> ++---
>  1 file changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
> b/drivers/media/dvb-frontends/lgdt3306a.c
> index 2f540f1..111efb0 100644
> --- a/drivers/media/dvb-frontends/lgdt3306a.c
> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
> @@ -30,6 +30,17 @@ static int debug;
>  module_param(debug, int, 0644);
>  MODULE_PARM_DESC(debug, "set debug level (info=1, reg=2 (or-able))");
>
> +/*
> + * Older drivers treated QAM64 and QAM256 the same; that is the HW always
> + * used "Auto" mode during detection.  Setting "forced_manual"=1 allows
> + * the user to treat these modes as separate.  For backwards compatibility,
> + * it's off by default.  QAM_AUTO can now be specified to achive that
> + * effect even if "forced_manual"=1
> + */
> +static int forced_manual;
> +module_param(forced_manual, int, 0644);
> +MODULE_PARM_DESC(forced_manual, "if set, QAM64 and QAM256 will only lock to 
> modulation specified");
> +
>  #define DBG_INFO 1
>  #define DBG_REG  2
>  #define DBG_DUMP 4 /* FGR - comment out to remove dump code */
> @@ -566,7 +577,12 @@ static int lgdt3306a_set_qam(struct lgdt3306a_state 
> *state, int modulation)
> /* 3. : 64QAM/256QAM detection(manual, auto) */
> ret = lgdt3306a_read_reg(state, 0x0009, );
> val &= 0xfc;
> -   val |= 0x02; /* STDOPDETCMODE[1:0]=1=Manual 2=Auto */
> +   /* Check for forced Manual modulation modes; otherwise always "auto" 
> */
> +   if(forced_manual && (modulation != QAM_AUTO)){
> +   val |= 0x01; /* STDOPDETCMODE[1:0]= 1=Manual */
> +   } else {
> +   val |= 0x02; /* STDOPDETCMODE[1:0]= 2=Auto */
> +   }
> ret = lgdt3306a_write_reg(state, 0x0009, val);
> if (lg_chkerr(ret))
> goto fail;
> @@ -642,10 +658,9 @@ static int lgdt3306a_set_modulation(struct 
> lgdt3306a_state *state,
> ret = lgdt3306a_set_vsb(state);
> break;
> case QAM_64:
> -   ret = lgdt3306a_set_qam(state, QAM_64);
> -   break;
> case QAM_256:
> -   ret = lgdt3306a_set_qam(state, QAM_256);
> +   case QAM_AUTO:
> +   ret = lgdt3306a_set_qam(state, p->modulation);
> break;
> default:
> return -EINVAL;
> @@ -672,6 +687,7 @@ static int lgdt3306a_agc_setup(struct lgdt3306a_state 
> *state,
> break;
> case QAM_64:
> case QAM_256:
> +   case QAM_AUTO:
> break;
> default:
> return -EINVAL;
> @@ -726,6 +742,7 @@ static int lgdt3306a_spectral_inversion(struct 
> lgdt3306a_state *state,
> break;
> case QAM_64:
> case QAM_256:
> +   case QAM_AUTO:
> /* Auto ok for QAM */
> ret = lgdt3306a_set_inversion_auto(state, 1);
> break;
> @@ -749,6 +766,7 @@ static int lgdt3306a_set_if(struct lgdt3306a_state *state,
> break;
> case QAM_64:
> case QAM_256:
> +   case QAM_AUTO:
> if_freq_khz = state->cfg->qam_if_khz;
> break;
> default:
> @@ -1607,6 +1625,7 @@ static int lgdt3306a_read_status(struct dvb_frontend 
> *fe,
> switch (state->current_modulation) {
> case QAM_256:
> case QAM_64:
> +   case QAM_AUTO:
> if (lgdt3306a_qam_lock_poll(state) == LG3306_LOCK) {
> *status |= FE_HAS_VITERBI;
> *status |= FE_HAS_SYNC;
> @@ -1650,6 +1669,7 @@ static int lgdt3306a_read_signal_strength(struct 
> dvb_frontend *fe,
>  * Calculate some sort of "strength" from SNR
>  */
> struct lgdt3306a_state *state = fe->demodulator_priv;
> +   u8 val;
> u16 snr; /* snr_x10 */
> int ret;
> u32 ref_snr; /* snr*100 */
> @@ -1662,11 +1682,15 @@ static int lgdt3306a_read_signal_strength(struct 
> dvb_frontend *fe,
>  ref_snr = 1600; /* 16dB */
>  break;
> case QAM_64:
> -ref_snr = 2200; /* 22dB */

Re: [PATCH 8/9] lgdt3306a: QAM streaming improvement

2018-01-04 Thread Michael Ira Krufky
On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
> Add some register updates required for stable viewing
> on Cablevision in NY. Does not adversely affect other providers.
>
> Signed-off-by: Brad Love 
> ---
>  drivers/media/dvb-frontends/lgdt3306a.c | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
> b/drivers/media/dvb-frontends/lgdt3306a.c
> index d2477ed..2f540f1 100644
> --- a/drivers/media/dvb-frontends/lgdt3306a.c
> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
> @@ -598,6 +598,28 @@ static int lgdt3306a_set_qam(struct lgdt3306a_state 
> *state, int modulation)
> if (lg_chkerr(ret))
> goto fail;
>
> +   /* 5.1 V0.36 SRDCHKALWAYS : For better QAM detection */
> +   ret = lgdt3306a_read_reg(state, 0x000A, );
> +   val &= 0xFD;
> +   val |= 0x02;
> +   ret = lgdt3306a_write_reg(state, 0x000A, val);
> +   if (lg_chkerr(ret))
> +   goto fail;
> +
> +   /* 5.2 V0.36 Control of "no signal" detector function */
> +   ret = lgdt3306a_read_reg(state, 0x2849, );
> +   val &= 0xDF;
> +   ret = lgdt3306a_write_reg(state, 0x2849, val);
> +   if (lg_chkerr(ret))
> +   goto fail;
> +
> +   /* 5.3 Fix for Blonder Tongue HDE-2H-QAM and AQM modulators */
> +   ret = lgdt3306a_read_reg(state, 0x302B, );
> +   val &= 0x7F;  /* SELFSYNCFINDEN_CQS=0; disable auto reset */
> +   ret = lgdt3306a_write_reg(state, 0x302B, val);
> +   if (lg_chkerr(ret))
> +   goto fail;
> +
> /* 6. Reset */
> ret = lgdt3306a_soft_reset(state);
> if (lg_chkerr(ret))

Brad,

The change looks good, but can you resubmit this using lowercase hex?

Cheers,

Michael Ira Krufky


Re: [PATCH 6/9] em28xx: Enable Hauppauge SoloHD rebranded 292e SE

2018-01-04 Thread Michael Ira Krufky
On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
> Add a missing device to the driver table.
>
> Signed-off-by: Brad Love 

:+1

Reviewed-by: Michael Ira Krufky 

> ---
>  drivers/media/usb/em28xx/em28xx-cards.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index 34c693a..66d4c3a 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -2619,6 +2619,8 @@ struct usb_device_id em28xx_id_table[] = {
> .driver_info = EM28178_BOARD_PCTV_461E },
> { USB_DEVICE(0x2013, 0x025f),
> .driver_info = EM28178_BOARD_PCTV_292E },
> +   { USB_DEVICE(0x2013, 0x0264), /* Hauppauge WinTV-soloHD 292e SE */
> +   .driver_info = EM28178_BOARD_PCTV_292E },
> { USB_DEVICE(0x2040, 0x0264), /* Hauppauge WinTV-soloHD Isoc */
> .driver_info = EM28178_BOARD_PCTV_292E },
> { USB_DEVICE(0x2040, 0x8264), /* Hauppauge OEM Generic WinTV-soloHD 
> Bulk */
> --
> 2.7.4
>


Re: [PATCH 5/9] em28xx: Add Hauppauge SoloHD/DualHD bulk models

2018-01-04 Thread Michael Ira Krufky
On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
> Add additional pids to driver list
>
> Signed-off-by: Brad Love 

:+1

Reviewed-by: Michael Ira Krufky 

> ---
>  drivers/media/usb/em28xx/em28xx-cards.c | 22 +-
>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index 7f5d0b28..34c693a 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -507,8 +507,10 @@ static struct em28xx_reg_seq plex_px_bcud[] = {
>  };
>
>  /*
> - * 2040:0265 Hauppauge WinTV-dualHD DVB
> - * 2040:026d Hauppauge WinTV-dualHD ATSC/QAM
> + * 2040:0265 Hauppauge WinTV-dualHD DVB Isoc
> + * 2040:8265 Hauppauge WinTV-dualHD DVB Bulk
> + * 2040:026d Hauppauge WinTV-dualHD ATSC/QAM Isoc
> + * 2040:826d Hauppauge WinTV-dualHD ATSC/QAM Bulk
>   * reg 0x80/0x84:
>   * GPIO_0: Yellow LED tuner 1, 0=on, 1=off
>   * GPIO_1: Green LED tuner 1, 0=on, 1=off
> @@ -2391,7 +2393,8 @@ struct em28xx_board em28xx_boards[] = {
> .has_dvb   = 1,
> },
> /*
> -* 2040:0265 Hauppauge WinTV-dualHD (DVB version).
> +* 2040:0265 Hauppauge WinTV-dualHD (DVB version) Isoc.
> +* 2040:8265 Hauppauge WinTV-dualHD (DVB version) Bulk.
>  * Empia EM28274, 2x Silicon Labs Si2168, 2x Silicon Labs Si2157
>  */
> [EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB] = {
> @@ -2407,7 +2410,8 @@ struct em28xx_board em28xx_boards[] = {
> .leds  = hauppauge_dualhd_leds,
> },
> /*
> -* 2040:026d Hauppauge WinTV-dualHD (model 01595 - ATSC/QAM).
> +* 2040:026d Hauppauge WinTV-dualHD (model 01595 - ATSC/QAM) Isoc.
> +* 2040:826d Hauppauge WinTV-dualHD (model 01595 - ATSC/QAM) Bulk.
>  * Empia EM28274, 2x LG LGDT3306A, 2x Silicon Labs Si2157
>  */
> [EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595] = {
> @@ -2549,8 +2553,12 @@ struct usb_device_id em28xx_id_table[] = {
> .driver_info = EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850 },
> { USB_DEVICE(0x2040, 0x0265),
> .driver_info = 
> EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB },
> +   { USB_DEVICE(0x2040, 0x8265),
> +   .driver_info = 
> EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB },
> { USB_DEVICE(0x2040, 0x026d),
> .driver_info = 
> EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 },
> +   { USB_DEVICE(0x2040, 0x826d),
> +   .driver_info = 
> EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 },
> { USB_DEVICE(0x0438, 0xb002),
> .driver_info = EM2880_BOARD_AMD_ATI_TV_WONDER_HD_600 
> },
> { USB_DEVICE(0x2001, 0xf112),
> @@ -2611,7 +2619,11 @@ struct usb_device_id em28xx_id_table[] = {
> .driver_info = EM28178_BOARD_PCTV_461E },
> { USB_DEVICE(0x2013, 0x025f),
> .driver_info = EM28178_BOARD_PCTV_292E },
> -   { USB_DEVICE(0x2040, 0x0264), /* Hauppauge WinTV-soloHD */
> +   { USB_DEVICE(0x2040, 0x0264), /* Hauppauge WinTV-soloHD Isoc */
> +   .driver_info = EM28178_BOARD_PCTV_292E },
> +   { USB_DEVICE(0x2040, 0x8264), /* Hauppauge OEM Generic WinTV-soloHD 
> Bulk */
> +   .driver_info = EM28178_BOARD_PCTV_292E },
> +   { USB_DEVICE(0x2040, 0x8268), /* Hauppauge Retail WinTV-soloHD Bulk */
> .driver_info = EM28178_BOARD_PCTV_292E },
> { USB_DEVICE(0x0413, 0x6f07),
> .driver_info = EM2861_BOARD_LEADTEK_VC100 },
> --
> 2.7.4
>


Re: [PATCH 4/9] em28xx: Increase max em28xx boards to max dvb adapters

2018-01-04 Thread Michael Ira Krufky
On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
> Maximum 4 em28xx boards is too low, this can be maxed out by two devices.
> This allows all the dvb adapters in the system to be em28xx if so desired.
>
> Signed-off-by: Brad Love 

:+1

Reviewed-by: Michael Ira Krufky 

> ---
>  drivers/media/usb/em28xx/em28xx.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx.h 
> b/drivers/media/usb/em28xx/em28xx.h
> index 7be8ac9..3dbcc9d 100644
> --- a/drivers/media/usb/em28xx/em28xx.h
> +++ b/drivers/media/usb/em28xx/em28xx.h
> @@ -166,7 +166,7 @@
>  #define EM28XX_STOP_AUDIO   0
>
>  /* maximum number of em28xx boards */
> -#define EM28XX_MAXBOARDS 4 /*FIXME: should be bigger */
> +#define EM28XX_MAXBOARDS DVB_MAX_ADAPTERS /* All adapters could be em28xx */
>
>  /* maximum number of frames that can be queued */
>  #define EM28XX_NUM_FRAMES 5
> --
> 2.7.4
>


Re: [PATCH 3/9] em28xx: USB bulk packet size fix

2018-01-04 Thread Michael Ira Krufky
On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
> Hauppauge em28xx bulk devices exhibit continuity errors and corrupted
> packets, when run in VMWare virtual machines. Unknown if other
> manufacturers bulk models exhibit the same issue. KVM/Qemu is unaffected.
>
> According to documentation the maximum packet multiplier for em28xx in bulk
> transfer mode is 256 * 188 bytes. This changes the size of bulk transfers
> to maximum supported value and have a bonus beneficial alignment.
>
> Before:
> # 512 * 384 = 196608
> ## 196608 % 188 != 0
>
> After:
> # 512 * 47 * 2 = 48128(188 * 128 * 2)
> ## 48128 % 188 = 0
>
> This sets up USB to expect just as many bytes as the em28xx is set to emit.
>
> Successful usage under load afterwards natively and in both VMWare
> and KVM/Qemu virtual machines.
>
> Signed-off-by: Brad Love 

:+1

Reviewed-by: Michael Ira Krufky 

> ---
>  drivers/media/usb/em28xx/em28xx.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx.h 
> b/drivers/media/usb/em28xx/em28xx.h
> index c85292c..7be8ac9 100644
> --- a/drivers/media/usb/em28xx/em28xx.h
> +++ b/drivers/media/usb/em28xx/em28xx.h
> @@ -191,7 +191,7 @@
> USB 2.0 spec says bulk packet size is always 512 bytes
>   */
>  #define EM28XX_BULK_PACKET_MULTIPLIER 384
> -#define EM28XX_DVB_BULK_PACKET_MULTIPLIER 384
> +#define EM28XX_DVB_BULK_PACKET_MULTIPLIER 94
>
>  #define EM28XX_INTERLACED_DEFAULT 1
>
> --
> 2.7.4
>


Re: [PATCH 2/9] em28xx: Bulk transfer implementation fix

2018-01-04 Thread Michael Ira Krufky
On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
> Set appropriate bulk/ISOC transfer multiplier on capture start.
> This sets ISOC transfer to 940 bytes (188 * 5)
> This sets bulk transfer to 48128 bytes (188 * 256)
>
> The above values are maximum allowed according to Empia.
>
> Signed-off-by: Brad Love 

:+1

Reviewed-by: Michael Ira Krufky 

> ---
>  drivers/media/usb/em28xx/em28xx-core.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-core.c 
> b/drivers/media/usb/em28xx/em28xx-core.c
> index ef38e56..67ed6a3 100644
> --- a/drivers/media/usb/em28xx/em28xx-core.c
> +++ b/drivers/media/usb/em28xx/em28xx-core.c
> @@ -638,6 +638,18 @@ int em28xx_capture_start(struct em28xx *dev, int start)
> dev->chip_id == CHIP_ID_EM28174 ||
> dev->chip_id == CHIP_ID_EM28178) {
> /* The Transport Stream Enable Register moved in em2874 */
> +   if (dev->dvb_xfer_bulk) {
> +   /* Max Tx Size = 188 * 256 = 48128 - LCM(188,512) * 2 
> */
> +   em28xx_write_reg(dev, (dev->ts == PRIMARY_TS) ?
> +   EM2874_R5D_TS1_PKT_SIZE :
> +   EM2874_R5E_TS2_PKT_SIZE,
> +   0xFF);
> +   } else {
> +   /* TS2 Maximum Transfer Size = 188 * 5 */
> +   em28xx_write_reg(dev, (dev->ts == PRIMARY_TS) ?
> +   EM2874_R5D_TS1_PKT_SIZE :
> +   EM2874_R5E_TS2_PKT_SIZE, 0x05);
> +   }
> if (dev->ts == PRIMARY_TS)
> rc = em28xx_write_reg_bits(dev,
> EM2874_R5F_TS_ENABLE,
> --
> 2.7.4
>


Re: [PATCH 1/9] em28xx: Hauppauge DualHD second tuner functionality

2018-01-04 Thread Michael Ira Krufky
On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
> Implement use of secondary TS port on em28xx.
> Adds has_dual_ts field, allows secondary demod/tuner to be
> added to a single em28xx device.
>
> Hauppauge DualHD models are configured to use this feature.
>
> Signed-off-by: Brad Love 

:+1

Reviewed-by: Michael Ira Krufky 

> ---
>  drivers/media/usb/em28xx/em28xx-cards.c | 126 
> +++-
>  drivers/media/usb/em28xx/em28xx-core.c  |  42 +--
>  drivers/media/usb/em28xx/em28xx-dvb.c   |  33 +++--
>  drivers/media/usb/em28xx/em28xx.h   |  12 +++
>  4 files changed, 196 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index 34e16f6a..7f5d0b28 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -2402,6 +2402,7 @@ struct em28xx_board em28xx_boards[] = {
> .tuner_type= TUNER_ABSENT,
> .tuner_gpio= hauppauge_dualhd_dvb,
> .has_dvb   = 1,
> +   .has_dual_ts   = 1,
> .ir_codes  = RC_MAP_HAUPPAUGE,
> .leds  = hauppauge_dualhd_leds,
> },
> @@ -2417,6 +2418,7 @@ struct em28xx_board em28xx_boards[] = {
> .tuner_type= TUNER_ABSENT,
> .tuner_gpio= hauppauge_dualhd_dvb,
> .has_dvb   = 1,
> +   .has_dual_ts   = 1,
> .ir_codes  = RC_MAP_HAUPPAUGE,
> .leds  = hauppauge_dualhd_leds,
> },
> @@ -3239,7 +3241,8 @@ static void em28xx_release_resources(struct em28xx *dev)
> em28xx_i2c_unregister(dev, 1);
> em28xx_i2c_unregister(dev, 0);
>
> -   usb_put_dev(udev);
> +   if (dev->ts == PRIMARY_TS)
> +   usb_put_dev(udev);
>
> /* Mark device as unused */
> clear_bit(dev->devno, em28xx_devused);
> @@ -3432,6 +3435,35 @@ static int em28xx_init_dev(struct em28xx *dev, struct 
> usb_device *udev,
> return 0;
>  }
>
> +int em28xx_duplicate_dev(struct em28xx *dev)
> +{
> +   int nr;
> +   struct em28xx *sec_dev = kzalloc(sizeof(*sec_dev), GFP_KERNEL);
> +
> +   if (sec_dev == NULL) {
> +   dev->dev_next = NULL;
> +   return -ENOMEM;
> +   }
> +   memcpy(sec_dev, dev, sizeof(sizeof(*sec_dev)));
> +   /* Check to see next free device and mark as used */
> +   do {
> +   nr = find_first_zero_bit(em28xx_devused, EM28XX_MAXBOARDS);
> +   if (nr >= EM28XX_MAXBOARDS) {
> +   /* No free device slots */
> +   dev_warn(>intf->dev, ": Supports only %i em28xx 
> boards.\n",
> +   EM28XX_MAXBOARDS);
> +   kfree(sec_dev);
> +   dev->dev_next = NULL;
> +   return -ENOMEM;
> +   }
> +   } while (test_and_set_bit(nr, em28xx_devused));
> +   sec_dev->devno = nr;
> +   snprintf(sec_dev->name, 28, "em28xx #%d", nr);
> +   sec_dev->dev_next = NULL;
> +   dev->dev_next = sec_dev;
> +   return 0;
> +}
> +
>  /* high bandwidth multiplier, as encoded in highspeed endpoint descriptors */
>  #define hb_mult(wMaxPacketSize) (1 + (((wMaxPacketSize) >> 11) & 0x03))
>
> @@ -3551,6 +3583,17 @@ static int em28xx_usb_probe(struct usb_interface 
> *interface,
> }
> }
> break;
> +   case 0x85:
> +   if (usb_endpoint_xfer_isoc(e)) {
> +   if (size > 
> dev->dvb_max_pkt_size_isoc_ts2) {
> +   dev->dvb_ep_isoc_ts2 
> = e->bEndpointAddress;
> +   
> dev->dvb_max_pkt_size_isoc_ts2 = size;
> +   dev->dvb_alt_isoc = i;
> +   }
> +   } else {
> +   dev->dvb_ep_bulk_ts2 = 
> e->bEndpointAddress;
> +   }
> +   break;
> }
> }
> /* NOTE:
> @@ -3565,6 +3608,8 @@ static int em28xx_usb_probe(struct usb_interface 
> *interface,
>  *  0x83isoc*   => audio
>  *  0x84isoc=> digital
>  *  0x84bulk=> analog or digital**
> +*  0x85isoc=> digital TS2
> + 

Re: [PATCH 7/9] lgdt3306a: Set fe ops.release to NULL if probed

2018-01-04 Thread Michael Ira Krufky
On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
> If release is part of frontend ops then it is called in the
> course of dvb_frontend_detach. The process also decrements
> the module usage count. The problem is if the lgdt3306a
> driver is reached via i2c_new_device, then when it is
> eventually destroyed remove is called, which further
> decrements the module usage count to negative. After this
> occurs the driver is in a bad state and no longer works.
> Also fixed by NULLing out the release callback is a double
> kfree of state, which introduces arbitrary oopses/GPF.
> This problem is only currently reachable via the em28xx driver.
>
> On disconnect of Hauppauge SoloHD before:
>
> lsmod | grep lgdt3306a
> lgdt3306a  28672  -1
> i2c_mux16384  1 lgdt3306a
>
> On disconnect of Hauppauge SoloHD after:
>
> lsmod | grep lgdt3306a
> lgdt3306a  28672  0
> i2c_mux16384  1 lgdt3306a
>
> Signed-off-by: Brad Love 
> ---
>  drivers/media/dvb-frontends/lgdt3306a.c | 1 +
>  1 file changed, 1 insertion(+)
>

Brad,

We won't be able to apply this one.  The symptom that you're trying to
fix is indicative of some other problem, probably in the em28xx
driver.  NULL'ing the release callback is not the right thing to do.

-Mike Krufky

> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
> b/drivers/media/dvb-frontends/lgdt3306a.c
> index 6356815..d2477ed 100644
> --- a/drivers/media/dvb-frontends/lgdt3306a.c
> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
> @@ -2177,6 +2177,7 @@ static int lgdt3306a_probe(struct i2c_client *client,
>
> i2c_set_clientdata(client, fe->demodulator_priv);
> state = fe->demodulator_priv;
> +   state->frontend.ops.release = NULL;
>
> /* create mux i2c adapter for tuner */
> state->muxc = i2c_mux_alloc(client->adapter, >dev,
> --
> 2.7.4
>


[PATCH 8/9] lgdt3306a: QAM streaming improvement

2018-01-04 Thread Brad Love
Add some register updates required for stable viewing
on Cablevision in NY. Does not adversely affect other providers.

Signed-off-by: Brad Love 
---
 drivers/media/dvb-frontends/lgdt3306a.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
b/drivers/media/dvb-frontends/lgdt3306a.c
index d2477ed..2f540f1 100644
--- a/drivers/media/dvb-frontends/lgdt3306a.c
+++ b/drivers/media/dvb-frontends/lgdt3306a.c
@@ -598,6 +598,28 @@ static int lgdt3306a_set_qam(struct lgdt3306a_state 
*state, int modulation)
if (lg_chkerr(ret))
goto fail;
 
+   /* 5.1 V0.36 SRDCHKALWAYS : For better QAM detection */
+   ret = lgdt3306a_read_reg(state, 0x000A, );
+   val &= 0xFD;
+   val |= 0x02;
+   ret = lgdt3306a_write_reg(state, 0x000A, val);
+   if (lg_chkerr(ret))
+   goto fail;
+
+   /* 5.2 V0.36 Control of "no signal" detector function */
+   ret = lgdt3306a_read_reg(state, 0x2849, );
+   val &= 0xDF;
+   ret = lgdt3306a_write_reg(state, 0x2849, val);
+   if (lg_chkerr(ret))
+   goto fail;
+
+   /* 5.3 Fix for Blonder Tongue HDE-2H-QAM and AQM modulators */
+   ret = lgdt3306a_read_reg(state, 0x302B, );
+   val &= 0x7F;  /* SELFSYNCFINDEN_CQS=0; disable auto reset */
+   ret = lgdt3306a_write_reg(state, 0x302B, val);
+   if (lg_chkerr(ret))
+   goto fail;
+
/* 6. Reset */
ret = lgdt3306a_soft_reset(state);
if (lg_chkerr(ret))
-- 
2.7.4



[PATCH 0/9] Hauppauge em28xx/lgdt3306a soloHD/DualHD support

2018-01-04 Thread Brad Love
Brief description of patches:
- Enable the second TS port on em28xx devices via board property
- Enables bulk transfer at max multiplier for em28xx TS1 and TS2
- Changes USB bulk transfer size to match em28xx bulk multiplier
- Increase em28xx arbitrary board limit to max dvb devices
- Add missing Hauppauge bulk model PID's
- Add missing Hauppauge SoloHD PID
- Fix i2c device related usb unplug frontend oops
- Add QAM_AUTO to frontend and an option to enforce a modulation
- Frontend streaming stability optimization

Brad Love (9):
  em28xx: Hauppauge DualHD second tuner functionality
  em28xx: Bulk transfer implementation fix
  em28xx: USB bulk packet size fix
  em28xx: Increase max em28xx boards to max dvb adapters
  em28xx: Add Hauppauge SoloHD/DualHD bulk models
  em28xx: Enable Hauppauge SoloHD rebranded 292e SE
  lgdt3306a: Set fe ops.release to NULL if probed
  lgdt3306a: QAM streaming improvement
  lgdt3306a: Add QAM AUTO support

 drivers/media/dvb-frontends/lgdt3306a.c |  65 --
 drivers/media/usb/em28xx/em28xx-cards.c | 150 ++--
 drivers/media/usb/em28xx/em28xx-core.c  |  54 ++--
 drivers/media/usb/em28xx/em28xx-dvb.c   |  33 +--
 drivers/media/usb/em28xx/em28xx.h   |  16 +++-
 5 files changed, 285 insertions(+), 33 deletions(-)

-- 
2.7.4



[PATCH 5/9] em28xx: Add Hauppauge SoloHD/DualHD bulk models

2018-01-04 Thread Brad Love
Add additional pids to driver list

Signed-off-by: Brad Love 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 7f5d0b28..34c693a 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -507,8 +507,10 @@ static struct em28xx_reg_seq plex_px_bcud[] = {
 };
 
 /*
- * 2040:0265 Hauppauge WinTV-dualHD DVB
- * 2040:026d Hauppauge WinTV-dualHD ATSC/QAM
+ * 2040:0265 Hauppauge WinTV-dualHD DVB Isoc
+ * 2040:8265 Hauppauge WinTV-dualHD DVB Bulk
+ * 2040:026d Hauppauge WinTV-dualHD ATSC/QAM Isoc
+ * 2040:826d Hauppauge WinTV-dualHD ATSC/QAM Bulk
  * reg 0x80/0x84:
  * GPIO_0: Yellow LED tuner 1, 0=on, 1=off
  * GPIO_1: Green LED tuner 1, 0=on, 1=off
@@ -2391,7 +2393,8 @@ struct em28xx_board em28xx_boards[] = {
.has_dvb   = 1,
},
/*
-* 2040:0265 Hauppauge WinTV-dualHD (DVB version).
+* 2040:0265 Hauppauge WinTV-dualHD (DVB version) Isoc.
+* 2040:8265 Hauppauge WinTV-dualHD (DVB version) Bulk.
 * Empia EM28274, 2x Silicon Labs Si2168, 2x Silicon Labs Si2157
 */
[EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB] = {
@@ -2407,7 +2410,8 @@ struct em28xx_board em28xx_boards[] = {
.leds  = hauppauge_dualhd_leds,
},
/*
-* 2040:026d Hauppauge WinTV-dualHD (model 01595 - ATSC/QAM).
+* 2040:026d Hauppauge WinTV-dualHD (model 01595 - ATSC/QAM) Isoc.
+* 2040:826d Hauppauge WinTV-dualHD (model 01595 - ATSC/QAM) Bulk.
 * Empia EM28274, 2x LG LGDT3306A, 2x Silicon Labs Si2157
 */
[EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595] = {
@@ -2549,8 +2553,12 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850 },
{ USB_DEVICE(0x2040, 0x0265),
.driver_info = EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB 
},
+   { USB_DEVICE(0x2040, 0x8265),
+   .driver_info = EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB 
},
{ USB_DEVICE(0x2040, 0x026d),
.driver_info = 
EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 },
+   { USB_DEVICE(0x2040, 0x826d),
+   .driver_info = 
EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 },
{ USB_DEVICE(0x0438, 0xb002),
.driver_info = EM2880_BOARD_AMD_ATI_TV_WONDER_HD_600 },
{ USB_DEVICE(0x2001, 0xf112),
@@ -2611,7 +2619,11 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM28178_BOARD_PCTV_461E },
{ USB_DEVICE(0x2013, 0x025f),
.driver_info = EM28178_BOARD_PCTV_292E },
-   { USB_DEVICE(0x2040, 0x0264), /* Hauppauge WinTV-soloHD */
+   { USB_DEVICE(0x2040, 0x0264), /* Hauppauge WinTV-soloHD Isoc */
+   .driver_info = EM28178_BOARD_PCTV_292E },
+   { USB_DEVICE(0x2040, 0x8264), /* Hauppauge OEM Generic WinTV-soloHD 
Bulk */
+   .driver_info = EM28178_BOARD_PCTV_292E },
+   { USB_DEVICE(0x2040, 0x8268), /* Hauppauge Retail WinTV-soloHD Bulk */
.driver_info = EM28178_BOARD_PCTV_292E },
{ USB_DEVICE(0x0413, 0x6f07),
.driver_info = EM2861_BOARD_LEADTEK_VC100 },
-- 
2.7.4



[PATCH 4/9] em28xx: Increase max em28xx boards to max dvb adapters

2018-01-04 Thread Brad Love
Maximum 4 em28xx boards is too low, this can be maxed out by two devices.
This allows all the dvb adapters in the system to be em28xx if so desired.

Signed-off-by: Brad Love 
---
 drivers/media/usb/em28xx/em28xx.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx.h 
b/drivers/media/usb/em28xx/em28xx.h
index 7be8ac9..3dbcc9d 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -166,7 +166,7 @@
 #define EM28XX_STOP_AUDIO   0
 
 /* maximum number of em28xx boards */
-#define EM28XX_MAXBOARDS 4 /*FIXME: should be bigger */
+#define EM28XX_MAXBOARDS DVB_MAX_ADAPTERS /* All adapters could be em28xx */
 
 /* maximum number of frames that can be queued */
 #define EM28XX_NUM_FRAMES 5
-- 
2.7.4



[PATCH 9/9] lgdt3306a: Add QAM AUTO support

2018-01-04 Thread Brad Love
As configured currently, modulation in the driver is set to auto detect,
no matter what the user sets modulation to. This leads to both QAM64
and QAM256 having the same effect. QAM AUTO is explicitly added here for
compatibility with scanning software who can use AUTO instead of doing
essentially the same scan twice.
Also included is a module option to enforce a specific QAM modulation if
desired. The true modulation is read before calculating the snr.
Changes are backwards compatible with current behaviour.

Signed-off-by: Brad Love 
---
 drivers/media/dvb-frontends/lgdt3306a.c | 42 ++---
 1 file changed, 33 insertions(+), 9 deletions(-)

diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
b/drivers/media/dvb-frontends/lgdt3306a.c
index 2f540f1..111efb0 100644
--- a/drivers/media/dvb-frontends/lgdt3306a.c
+++ b/drivers/media/dvb-frontends/lgdt3306a.c
@@ -30,6 +30,17 @@ static int debug;
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, "set debug level (info=1, reg=2 (or-able))");
 
+/*
+ * Older drivers treated QAM64 and QAM256 the same; that is the HW always
+ * used "Auto" mode during detection.  Setting "forced_manual"=1 allows
+ * the user to treat these modes as separate.  For backwards compatibility,
+ * it's off by default.  QAM_AUTO can now be specified to achive that
+ * effect even if "forced_manual"=1
+ */
+static int forced_manual;
+module_param(forced_manual, int, 0644);
+MODULE_PARM_DESC(forced_manual, "if set, QAM64 and QAM256 will only lock to 
modulation specified");
+
 #define DBG_INFO 1
 #define DBG_REG  2
 #define DBG_DUMP 4 /* FGR - comment out to remove dump code */
@@ -566,7 +577,12 @@ static int lgdt3306a_set_qam(struct lgdt3306a_state 
*state, int modulation)
/* 3. : 64QAM/256QAM detection(manual, auto) */
ret = lgdt3306a_read_reg(state, 0x0009, );
val &= 0xfc;
-   val |= 0x02; /* STDOPDETCMODE[1:0]=1=Manual 2=Auto */
+   /* Check for forced Manual modulation modes; otherwise always "auto" */
+   if(forced_manual && (modulation != QAM_AUTO)){
+   val |= 0x01; /* STDOPDETCMODE[1:0]= 1=Manual */
+   } else {
+   val |= 0x02; /* STDOPDETCMODE[1:0]= 2=Auto */
+   }
ret = lgdt3306a_write_reg(state, 0x0009, val);
if (lg_chkerr(ret))
goto fail;
@@ -642,10 +658,9 @@ static int lgdt3306a_set_modulation(struct lgdt3306a_state 
*state,
ret = lgdt3306a_set_vsb(state);
break;
case QAM_64:
-   ret = lgdt3306a_set_qam(state, QAM_64);
-   break;
case QAM_256:
-   ret = lgdt3306a_set_qam(state, QAM_256);
+   case QAM_AUTO:
+   ret = lgdt3306a_set_qam(state, p->modulation);
break;
default:
return -EINVAL;
@@ -672,6 +687,7 @@ static int lgdt3306a_agc_setup(struct lgdt3306a_state 
*state,
break;
case QAM_64:
case QAM_256:
+   case QAM_AUTO:
break;
default:
return -EINVAL;
@@ -726,6 +742,7 @@ static int lgdt3306a_spectral_inversion(struct 
lgdt3306a_state *state,
break;
case QAM_64:
case QAM_256:
+   case QAM_AUTO:
/* Auto ok for QAM */
ret = lgdt3306a_set_inversion_auto(state, 1);
break;
@@ -749,6 +766,7 @@ static int lgdt3306a_set_if(struct lgdt3306a_state *state,
break;
case QAM_64:
case QAM_256:
+   case QAM_AUTO:
if_freq_khz = state->cfg->qam_if_khz;
break;
default:
@@ -1607,6 +1625,7 @@ static int lgdt3306a_read_status(struct dvb_frontend *fe,
switch (state->current_modulation) {
case QAM_256:
case QAM_64:
+   case QAM_AUTO:
if (lgdt3306a_qam_lock_poll(state) == LG3306_LOCK) {
*status |= FE_HAS_VITERBI;
*status |= FE_HAS_SYNC;
@@ -1650,6 +1669,7 @@ static int lgdt3306a_read_signal_strength(struct 
dvb_frontend *fe,
 * Calculate some sort of "strength" from SNR
 */
struct lgdt3306a_state *state = fe->demodulator_priv;
+   u8 val;
u16 snr; /* snr_x10 */
int ret;
u32 ref_snr; /* snr*100 */
@@ -1662,11 +1682,15 @@ static int lgdt3306a_read_signal_strength(struct 
dvb_frontend *fe,
 ref_snr = 1600; /* 16dB */
 break;
case QAM_64:
-ref_snr = 2200; /* 22dB */
-break;
case QAM_256:
-ref_snr = 2800; /* 28dB */
-break;
+   case QAM_AUTO:
+   /* need to know actual modulation to set proper SNR baseline */
+   lgdt3306a_read_reg(state, 0x00a6, );
+   if(val & 0x04)
+   ref_snr = 2800; /* QAM-256 28dB */
+  

[PATCH 1/9] em28xx: Hauppauge DualHD second tuner functionality

2018-01-04 Thread Brad Love
Implement use of secondary TS port on em28xx.
Adds has_dual_ts field, allows secondary demod/tuner to be
added to a single em28xx device.

Hauppauge DualHD models are configured to use this feature.

Signed-off-by: Brad Love 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 126 +++-
 drivers/media/usb/em28xx/em28xx-core.c  |  42 +--
 drivers/media/usb/em28xx/em28xx-dvb.c   |  33 +++--
 drivers/media/usb/em28xx/em28xx.h   |  12 +++
 4 files changed, 196 insertions(+), 17 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 34e16f6a..7f5d0b28 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2402,6 +2402,7 @@ struct em28xx_board em28xx_boards[] = {
.tuner_type= TUNER_ABSENT,
.tuner_gpio= hauppauge_dualhd_dvb,
.has_dvb   = 1,
+   .has_dual_ts   = 1,
.ir_codes  = RC_MAP_HAUPPAUGE,
.leds  = hauppauge_dualhd_leds,
},
@@ -2417,6 +2418,7 @@ struct em28xx_board em28xx_boards[] = {
.tuner_type= TUNER_ABSENT,
.tuner_gpio= hauppauge_dualhd_dvb,
.has_dvb   = 1,
+   .has_dual_ts   = 1,
.ir_codes  = RC_MAP_HAUPPAUGE,
.leds  = hauppauge_dualhd_leds,
},
@@ -3239,7 +3241,8 @@ static void em28xx_release_resources(struct em28xx *dev)
em28xx_i2c_unregister(dev, 1);
em28xx_i2c_unregister(dev, 0);
 
-   usb_put_dev(udev);
+   if (dev->ts == PRIMARY_TS)
+   usb_put_dev(udev);
 
/* Mark device as unused */
clear_bit(dev->devno, em28xx_devused);
@@ -3432,6 +3435,35 @@ static int em28xx_init_dev(struct em28xx *dev, struct 
usb_device *udev,
return 0;
 }
 
+int em28xx_duplicate_dev(struct em28xx *dev)
+{
+   int nr;
+   struct em28xx *sec_dev = kzalloc(sizeof(*sec_dev), GFP_KERNEL);
+
+   if (sec_dev == NULL) {
+   dev->dev_next = NULL;
+   return -ENOMEM;
+   }
+   memcpy(sec_dev, dev, sizeof(sizeof(*sec_dev)));
+   /* Check to see next free device and mark as used */
+   do {
+   nr = find_first_zero_bit(em28xx_devused, EM28XX_MAXBOARDS);
+   if (nr >= EM28XX_MAXBOARDS) {
+   /* No free device slots */
+   dev_warn(>intf->dev, ": Supports only %i em28xx 
boards.\n",
+   EM28XX_MAXBOARDS);
+   kfree(sec_dev);
+   dev->dev_next = NULL;
+   return -ENOMEM;
+   }
+   } while (test_and_set_bit(nr, em28xx_devused));
+   sec_dev->devno = nr;
+   snprintf(sec_dev->name, 28, "em28xx #%d", nr);
+   sec_dev->dev_next = NULL;
+   dev->dev_next = sec_dev;
+   return 0;
+}
+
 /* high bandwidth multiplier, as encoded in highspeed endpoint descriptors */
 #define hb_mult(wMaxPacketSize) (1 + (((wMaxPacketSize) >> 11) & 0x03))
 
@@ -3551,6 +3583,17 @@ static int em28xx_usb_probe(struct usb_interface 
*interface,
}
}
break;
+   case 0x85:
+   if (usb_endpoint_xfer_isoc(e)) {
+   if (size > 
dev->dvb_max_pkt_size_isoc_ts2) {
+   dev->dvb_ep_isoc_ts2 = 
e->bEndpointAddress;
+   
dev->dvb_max_pkt_size_isoc_ts2 = size;
+   dev->dvb_alt_isoc = i;
+   }
+   } else {
+   dev->dvb_ep_bulk_ts2 = 
e->bEndpointAddress;
+   }
+   break;
}
}
/* NOTE:
@@ -3565,6 +3608,8 @@ static int em28xx_usb_probe(struct usb_interface 
*interface,
 *  0x83isoc*   => audio
 *  0x84isoc=> digital
 *  0x84bulk=> analog or digital**
+*  0x85isoc=> digital TS2
+*  0x85bulk=> digital TS2
 * (*: audio should always be isoc)
 * (**: analog, if ep 0x82 is isoc, otherwise digital)
 *
@@ -3632,6 +3677,10 @@ static int em28xx_usb_probe(struct usb_interface 
*interface,
dev->has_video = has_video;

[PATCH 2/9] em28xx: Bulk transfer implementation fix

2018-01-04 Thread Brad Love
Set appropriate bulk/ISOC transfer multiplier on capture start.
This sets ISOC transfer to 940 bytes (188 * 5)
This sets bulk transfer to 48128 bytes (188 * 256)

The above values are maximum allowed according to Empia.

Signed-off-by: Brad Love 
---
 drivers/media/usb/em28xx/em28xx-core.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/media/usb/em28xx/em28xx-core.c 
b/drivers/media/usb/em28xx/em28xx-core.c
index ef38e56..67ed6a3 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -638,6 +638,18 @@ int em28xx_capture_start(struct em28xx *dev, int start)
dev->chip_id == CHIP_ID_EM28174 ||
dev->chip_id == CHIP_ID_EM28178) {
/* The Transport Stream Enable Register moved in em2874 */
+   if (dev->dvb_xfer_bulk) {
+   /* Max Tx Size = 188 * 256 = 48128 - LCM(188,512) * 2 */
+   em28xx_write_reg(dev, (dev->ts == PRIMARY_TS) ?
+   EM2874_R5D_TS1_PKT_SIZE :
+   EM2874_R5E_TS2_PKT_SIZE,
+   0xFF);
+   } else {
+   /* TS2 Maximum Transfer Size = 188 * 5 */
+   em28xx_write_reg(dev, (dev->ts == PRIMARY_TS) ?
+   EM2874_R5D_TS1_PKT_SIZE :
+   EM2874_R5E_TS2_PKT_SIZE, 0x05);
+   }
if (dev->ts == PRIMARY_TS)
rc = em28xx_write_reg_bits(dev,
EM2874_R5F_TS_ENABLE,
-- 
2.7.4



[PATCH 7/9] lgdt3306a: Set fe ops.release to NULL if probed

2018-01-04 Thread Brad Love
If release is part of frontend ops then it is called in the
course of dvb_frontend_detach. The process also decrements
the module usage count. The problem is if the lgdt3306a
driver is reached via i2c_new_device, then when it is
eventually destroyed remove is called, which further
decrements the module usage count to negative. After this
occurs the driver is in a bad state and no longer works.
Also fixed by NULLing out the release callback is a double
kfree of state, which introduces arbitrary oopses/GPF.
This problem is only currently reachable via the em28xx driver.

On disconnect of Hauppauge SoloHD before:

lsmod | grep lgdt3306a
lgdt3306a  28672  -1
i2c_mux16384  1 lgdt3306a

On disconnect of Hauppauge SoloHD after:

lsmod | grep lgdt3306a
lgdt3306a  28672  0
i2c_mux16384  1 lgdt3306a

Signed-off-by: Brad Love 
---
 drivers/media/dvb-frontends/lgdt3306a.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
b/drivers/media/dvb-frontends/lgdt3306a.c
index 6356815..d2477ed 100644
--- a/drivers/media/dvb-frontends/lgdt3306a.c
+++ b/drivers/media/dvb-frontends/lgdt3306a.c
@@ -2177,6 +2177,7 @@ static int lgdt3306a_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, fe->demodulator_priv);
state = fe->demodulator_priv;
+   state->frontend.ops.release = NULL;
 
/* create mux i2c adapter for tuner */
state->muxc = i2c_mux_alloc(client->adapter, >dev,
-- 
2.7.4



[PATCH 3/9] em28xx: USB bulk packet size fix

2018-01-04 Thread Brad Love
Hauppauge em28xx bulk devices exhibit continuity errors and corrupted
packets, when run in VMWare virtual machines. Unknown if other
manufacturers bulk models exhibit the same issue. KVM/Qemu is unaffected.

According to documentation the maximum packet multiplier for em28xx in bulk
transfer mode is 256 * 188 bytes. This changes the size of bulk transfers
to maximum supported value and have a bonus beneficial alignment.

Before:
# 512 * 384 = 196608
## 196608 % 188 != 0

After:
# 512 * 47 * 2 = 48128(188 * 128 * 2)
## 48128 % 188 = 0

This sets up USB to expect just as many bytes as the em28xx is set to emit.

Successful usage under load afterwards natively and in both VMWare
and KVM/Qemu virtual machines.

Signed-off-by: Brad Love 
---
 drivers/media/usb/em28xx/em28xx.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx.h 
b/drivers/media/usb/em28xx/em28xx.h
index c85292c..7be8ac9 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -191,7 +191,7 @@
USB 2.0 spec says bulk packet size is always 512 bytes
  */
 #define EM28XX_BULK_PACKET_MULTIPLIER 384
-#define EM28XX_DVB_BULK_PACKET_MULTIPLIER 384
+#define EM28XX_DVB_BULK_PACKET_MULTIPLIER 94
 
 #define EM28XX_INTERLACED_DEFAULT 1
 
-- 
2.7.4



[PATCH 6/9] em28xx: Enable Hauppauge SoloHD rebranded 292e SE

2018-01-04 Thread Brad Love
Add a missing device to the driver table.

Signed-off-by: Brad Love 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 34c693a..66d4c3a 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2619,6 +2619,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM28178_BOARD_PCTV_461E },
{ USB_DEVICE(0x2013, 0x025f),
.driver_info = EM28178_BOARD_PCTV_292E },
+   { USB_DEVICE(0x2013, 0x0264), /* Hauppauge WinTV-soloHD 292e SE */
+   .driver_info = EM28178_BOARD_PCTV_292E },
{ USB_DEVICE(0x2040, 0x0264), /* Hauppauge WinTV-soloHD Isoc */
.driver_info = EM28178_BOARD_PCTV_292E },
{ USB_DEVICE(0x2040, 0x8264), /* Hauppauge OEM Generic WinTV-soloHD 
Bulk */
-- 
2.7.4



Re: IMX6 interlaced capture

2018-01-04 Thread Steve Longerbeam



On 01/04/2018 01:11 PM, Tim Harvey wrote:

On Thu, Jan 4, 2018 at 10:51 AM, Steve Longerbeam  wrote:


On 01/04/2018 09:57 AM, Tim Harvey wrote:

On Tue, Jan 2, 2018 at 6:00 PM, Steve Longerbeam 
wrote:

Hi Tim,

Happy New Year! And pardon the delay.


On 12/28/2017 01:56 PM, Tim Harvey wrote:

Steve/Hans,

I'm trying to get interlaced capture working with the TDA1997x driver
I've been working on which is connected to an IMX6 CSI.

The particular board I'm currently testing on is an IMX6Q which has
both a TDA19971 HDMI receiver as well as an ADV7180 analog video
decoder. The media-ctl topology for this board can be found at
http://dev.gateworks.com/docs/linux/media/imx6q-gw54xx-media.png.

For adv7180 everything appears to be working as expected:
- media-ctl --get-v4l2 '"adv7180 2-0020":0' shows:
[fmt:UYVY8_2X8/720x480 field:interlaced colorspace:smpte170m]
- he following captures/streams from the adv7180 using the vdic to
de-interlace:
media-ctl --link "adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]
media-ctl --link "ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]
media-ctl --link "ipu2_csi1":1 -> "ipu2_vdic":0[1]
media-ctl --link "ipu2_vdic":2 -> "ipu2_ic_prp":0[1]
media-ctl --link "ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]
media-ctl --link "ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]
media-ctl --set-v4l2 'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]
media-ctl --set-v4l2 'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480
field:interlaced]
media-ctl --set-v4l2 'ipu2_csi1':1 [fmt:UYVY2X8/720x480
field:interlaced]
media-ctl --set-v4l2 'ipu2_vdic':2 [fmt:UYVY2X8/720x480
field:interlaced]
media-ctl --set-v4l2 'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:none]
media-ctl --set-v4l2 'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]
v4l2-ctl -d /dev/video3
--set-fmt-video=width=720,height=480,pixelformat=UYVY
# capture 1 frame
v4l2-ctl -d /dev/video1 --stream-mmap --stream-skip=1
--stream-to=/tmp/x.raw --stream-count=1
# stream jpeg/rtp
gst-launch-1.0 v4l2src device=/dev/video3 !
 "video/x-raw,width=720,height=480,format=UYVY" !
  jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=5000"

For the tda1997x I'm trying to do something similar:
- media-ctl --get-v4l2 '"tda19971 2-0048":0' shows:
[fmt:UYVY8_1X16/1920x1080 field:alternate colorspace:srgb]
 still not sure V4L2_FIELD_ALTERNATE/SRGB returned from tda1997x
get_fmt is correct
- I setup the pipeline with:
media-ctl --link "tda19971 2-0048":0 -> "ipu1_csi0_mux":1[1]
media-ctl --link "ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]
media-ctl --link "ipu1_csi0":1 -> "ipu1_vdic":0[1]
media-ctl --link "ipu1_vdic":2 -> "ipu1_ic_prp":0[1]
media-ctl --link "ipu1_ic_prp":2 -> "ipu1_ic_prpvf":0[1]
media-ctl --link "ipu1_ic_prpvf":1 -> "ipu1_ic_prpvf capture":0[1]
media-ctl --set-v4l2 'tda19971 2-0048':0[fmt:UYVY8_1X16/1920x1080]
media-ctl --set-v4l2 'ipu1_csi0_mux':2[fmt:UYVY8_1X16/1920x1080
field:alternate]
media-ctl --set-v4l2 'ipu1_csi0':1[fmt:UYVY8_1X16/1920x1080
field:alternate]
media-ctl --set-v4l2 'ipu1_vdic':2[fmt:UYVY8_1X16/1920x1080
field:alternate]
media-ctl --set-v4l2 'ipu1_ic_prp':2[fmt:UYVY8_1X16/1920x1080
field:none]
media-ctl --set-v4l2 'ipu1_ic_prpvf':1[fmt:UYVY8_1X16/1920x1080
field:none]
v4l2-ctl -d /dev/video1
--set-fmt-video=width=1920,height=1080,pixelformat=UYVY
v4l2-ctl -d /dev/v4l-subdev1 --set-dv-bt-timings=query
v4l2-ctl -d /dev/video1 --stream-mmap --stream-skip=1
--stream-to=/tmp/x.raw --stream-count=1
ipu1_csi0: bayer/16-bit parallel buses must go to IDMAC pad
ipu1_ic_prpvf: pipeline start failed with -22
VIDIOC_STREAMON: failed: Invalid argument

Steve,

Thanks for the help.


Right, according to the i.MX6 reference manual, if the CSI muxes
are receiving from the parallel bus input with width >= 16 bits,
that data can't be passed to the IC. It never really made much sense
to me, and I can't remember if I ever tried it, maybe not, because
I don't have such hardware.

hmmm... that's not good. I may have to dig into what's being done in
my 3.14 kernel with the Freescale capture driver where I can capture
1080p60 fine with my tda1997x driver there.


Try this hack as an experiment: modify is_parallel_16bit_bus() in
imx-media-csi.c to simply return false, and see if the above pipeline
works.

I'm currently on 4.15-rc1 which doesn't have a
'is_parallel_16bit_bus()' but if I comment out the check we are
talking about in csi_link_validate as such:

--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -999,6 +999,7 @@ static int csi_link_validate(struct v4l2_subdev *sd,
  is_csi2 = (sensor_ep->bus_type == V4L2_MBUS_CSI2);
  incc = priv->cc[CSI_SINK_PAD];

+/*
  if (priv->dest != IPU_CSI_DEST_IDMAC &&
  (incc->bayer || (!is_csi2 &&
   sensor_ep->bus.parallel.bus_width >= 16))) {
@@ -1007,6 +1008,7 @@ static int csi_link_validate(struct v4l2_subdev *sd,
  ret = -EINVAL;
  goto out;
  }

[PATCH] media: uvcvideo: support multiple frame descriptors with the same dimensions

2018-01-04 Thread Philipp Zabel
The Microsoft HoloLens Sensors device has two separate frame descriptors
with the same dimensions, each with a single different frame interval:

  VideoStreaming Interface Descriptor:
bLength30
bDescriptorType36
bDescriptorSubtype  5 (FRAME_UNCOMPRESSED)
bFrameIndex 1
bmCapabilities   0x00
  Still image unsupported
wWidth   1280
wHeight   481
dwMinBitRate147763200
dwMaxBitRate147763200
dwMaxVideoFrameBufferSize  615680
dwDefaultFrameInterval 33
bFrameIntervalType  1
dwFrameInterval( 0)33
  VideoStreaming Interface Descriptor:
bLength30
bDescriptorType36
bDescriptorSubtype  5 (FRAME_UNCOMPRESSED)
bFrameIndex 2
bmCapabilities   0x00
  Still image unsupported
wWidth   1280
wHeight   481
dwMinBitRate443289600
dwMaxBitRate443289600
dwMaxVideoFrameBufferSize  615680
dwDefaultFrameInterval 11
bFrameIntervalType  1
dwFrameInterval( 0)11

Skip duplicate dimensions in enum_framesizes, let enum_frameintervals list
the intervals from both frame descriptors. Change set_streamparm to switch
to the correct frame index when changing the interval. This enables 90 fps
capture on a Lenovo Explorer Windows Mixed Reality headset.

Signed-off-by: Philipp Zabel 
---
Changes since v1 [1]:
- Break out of frame size loop if maxd == 0 in uvc_v4l2_set_streamparm.
- Moved d and tmp variables in uvc_v4l2_set_streamparm into loop,
  renamed tmp variable to tmp_ival.
- Changed i loop variables to unsigned int.
- Changed index variables to unsigned int.
- One line per variable declaration.

[1] https://patchwork.linuxtv.org/patch/46109/
---
 drivers/media/usb/uvc/uvc_v4l2.c | 71 +++-
 1 file changed, 55 insertions(+), 16 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index f5ab8164bca5..d9ee400bf47c 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -373,7 +373,10 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming 
*stream,
 {
struct uvc_streaming_control probe;
struct v4l2_fract timeperframe;
-   uint32_t interval;
+   struct uvc_format *format;
+   struct uvc_frame *frame;
+   __u32 interval, maxd;
+   unsigned int i;
int ret;
 
if (parm->type != stream->type)
@@ -396,9 +399,33 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming 
*stream,
return -EBUSY;
}
 
+   format = stream->cur_format;
+   frame = stream->cur_frame;
probe = stream->ctrl;
-   probe.dwFrameInterval =
-   uvc_try_frame_interval(stream->cur_frame, interval);
+   probe.dwFrameInterval = uvc_try_frame_interval(frame, interval);
+   maxd = abs((__s32)probe.dwFrameInterval - interval);
+
+   /* Try frames with matching size to find the best frame interval. */
+   for (i = 0; i < format->nframes && maxd != 0; i++) {
+   __u32 d, tmp_ival;
+
+   if (>frame[i] == stream->cur_frame)
+   continue;
+
+   if (format->frame[i].wWidth != stream->cur_frame->wWidth ||
+   format->frame[i].wHeight != stream->cur_frame->wHeight)
+   continue;
+
+   tmp_ival = uvc_try_frame_interval(>frame[i], interval);
+   d = abs((__s32)tmp_ival - interval);
+   if (d >= maxd)
+   continue;
+
+   frame = >frame[i];
+   probe.bFrameIndex = frame->bFrameIndex;
+   probe.dwFrameInterval = tmp_ival;
+   maxd = d;
+   }
 
/* Probe the device with the new settings. */
ret = uvc_probe_video(stream, );
@@ -408,6 +435,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming 
*stream,
}
 
stream->ctrl = probe;
+   stream->cur_frame = frame;
mutex_unlock(>mutex);
 
/* Return the actual frame period. */
@@ -1209,7 +1237,8 @@ static int uvc_ioctl_enum_framesizes(struct file *file, 
void *fh,
struct uvc_streaming *stream = handle->stream;
struct uvc_format *format = NULL;
struct uvc_frame *frame;
-   int i;
+   unsigned int index;
+   unsigned int i;
 
/* Look for the given pixel format */
for (i = 0; i < stream->nformats; i++) {
@@ -1221,10 +1250,20 

Re: [PATCH v3 1/9] dt-bindings: media: Add Renesas CEU bindings

2018-01-04 Thread Laurent Pinchart
Hi Jacopo,

Thank you for the patch.

On Thursday, 4 January 2018 18:03:09 EET Jacopo Mondi wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/media/renesas,ceu.txt  | 85 +++
>  1 file changed, 85 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt new file mode
> 100644
> index 000..a4f3c05
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,85 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found in the Renesas
> +SH Mobile and RZ SoCs.
> +
> +The interface supports a single parallel input with data bus width of 8 or
> 16
> +bits.
> +
> +Required properties:
> +- compatible: Must be one of the following.
> + - "renesas,r7s72100-ceu" for CEU units found in R7S72100 (RZ/A1) SoCs.
> + - "renesas,ceu" as a generic fallback.

As asked in my review of patch 3/9, what's your policy for compatible strings 
? As far as I understand there's no generic CEU, as the SH4 and RZ versions 
are not compatible. Should the "renesas,ceu" compatible string then be 
replaced by "renesas,rz-ceu" ?

> +   SH Mobile CPUs do not currently support OF, and they configure their
> + CEU interfaces using platform data. The "compatible" list will be
> + expanded once SH Mobile will be made OF-capable.

The first sentence is out of scope, or at least its second half. I'd drop this 
completely, or possibly capture it in the commit message.

> +- reg: Registers address base and size.
> +- interrupts: The interrupt specifier.
> +
> +The CEU supports a single parallel input and should contain a single 'port'
> +subnode with a single 'endpoint'. Connection to input devices are modeled
> +according to the video interfaces OF bindings specified in:
> +Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Optional endpoint properties applicable to parallel input bus described in
> +the above mentioned "video-interfaces.txt" file are supported by this
> driver:

I know it's hard to get rid of that habit, but drivers are out of scope for DT 
bindings so they should not be mentioned. You should of course document the 
properties, and explain whether they are mandatory and optional.

> +
> +- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH
> respectively.
> +- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH
> respectively.
> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and an
> +OV7670 image sensor connected to i2c1 interface.
> +
> +ceu: ceu@e821 {
> + reg = <0xe821 0x209c>;
> + compatible = "renesas,ceu";

Don't forget to update this example when you'll address my comment about 
compatible strings.

> + interrupts = ;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> +
> + port {
> + ceu_in: endpoint {
> + remote-endpoint = <_out>;
> +
> + hsync-active = <1>;
> + vsync-active = <0>;
> + };
> + };
> +};
> +
> +i2c1: i2c@fcfee400 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> +
> + clock-frequency = <10>;
> +
> + ov7670: camera@21 {
> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + ov7670_out: endpoint {
> + remote-endpoint = <_in>;
> +
> + hsync-active = <1>;
> + vsync-active = <0>;
> + };
> + };
> + };
> +};

-- 
Regards,

Laurent Pinchart



[PATCH] media: siano: Fix coherent memory allocation failure on some arch

2018-01-04 Thread Tomoki Sekiyama
On some architectures like arm64, coherent memory allocation for
USB devices fails by following error:

[  663.556135] usbcore: deregistering interface driver smsusb
[  683.624809] smsusb:smsusb_probe: board id=18, interface number 0
[  683.633530] smsusb:smsusb_init_device: smscore_register_device(...) failed, 
rc -12
[  683.641501] smsusb:smsusb_probe: Device initialized with return code -12
[  683.652978] smsusb: probe of 1-1:1.0 failed with error -12

This is caused by dma_alloc_coherent(NULL, ...) returning NULL in
smscoreapi.c.

To fix this error, usb_alloc_coherent() must be used for DMA
memory allocation for USB devices in such architectures.

Signed-off-by: Tomoki Sekiyama 
---
 drivers/media/common/siano/smscoreapi.c | 34 +++--
 drivers/media/common/siano/smscoreapi.h |  2 ++
 drivers/media/usb/siano/smsusb.c|  1 +
 3 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/media/common/siano/smscoreapi.c 
b/drivers/media/common/siano/smscoreapi.c
index c5c827e..8d0e7a6 100644
--- a/drivers/media/common/siano/smscoreapi.c
+++ b/drivers/media/common/siano/smscoreapi.c
@@ -690,17 +690,23 @@ int smscore_register_device(struct smsdevice_params_t 
*params,
 
/* alloc common buffer */
dev->common_buffer_size = params->buffer_size * params->num_buffers;
-   dev->common_buffer = dma_alloc_coherent(NULL, dev->common_buffer_size,
-   >common_buffer_phys,
-   GFP_KERNEL | GFP_DMA);
-   if (!dev->common_buffer) {
+   if (params->usb_device)
+   buffer = usb_alloc_coherent(params->usb_device,
+   dev->common_buffer_size,
+   GFP_KERNEL | GFP_DMA,
+   >common_buffer_phys);
+   else
+   buffer = dma_alloc_coherent(NULL, dev->common_buffer_size,
+   >common_buffer_phys,
+   GFP_KERNEL | GFP_DMA);
+   if (!buffer) {
smscore_unregister_device(dev);
return -ENOMEM;
}
+   dev->common_buffer = buffer;
 
/* prepare dma buffers */
-   for (buffer = dev->common_buffer;
-dev->num_buffers < params->num_buffers;
+   for (; dev->num_buffers < params->num_buffers;
 dev->num_buffers++, buffer += params->buffer_size) {
struct smscore_buffer_t *cb;
 
@@ -720,6 +726,7 @@ int smscore_register_device(struct smsdevice_params_t 
*params,
dev->board_id = SMS_BOARD_UNKNOWN;
dev->context = params->context;
dev->device = params->device;
+   dev->usb_device = params->usb_device;
dev->setmode_handler = params->setmode_handler;
dev->detectmode_handler = params->detectmode_handler;
dev->sendrequest_handler = params->sendrequest_handler;
@@ -1231,10 +1238,17 @@ void smscore_unregister_device(struct smscore_device_t 
*coredev)
 
pr_debug("freed %d buffers\n", num_buffers);
 
-   if (coredev->common_buffer)
-   dma_free_coherent(NULL, coredev->common_buffer_size,
-   coredev->common_buffer, coredev->common_buffer_phys);
-
+   if (coredev->common_buffer) {
+   if (coredev->usb_device)
+   usb_free_coherent(coredev->usb_device,
+ coredev->common_buffer_size,
+ coredev->common_buffer,
+ coredev->common_buffer_phys);
+   else
+   dma_free_coherent(NULL, coredev->common_buffer_size,
+ coredev->common_buffer,
+ coredev->common_buffer_phys);
+   }
kfree(coredev->fw_buf);
 
list_del(>entry);
diff --git a/drivers/media/common/siano/smscoreapi.h 
b/drivers/media/common/siano/smscoreapi.h
index 4cc39e4..134c69f 100644
--- a/drivers/media/common/siano/smscoreapi.h
+++ b/drivers/media/common/siano/smscoreapi.h
@@ -134,6 +134,7 @@ struct smscore_buffer_t {
 
 struct smsdevice_params_t {
struct device   *device;
+   struct usb_device   *usb_device;
 
int buffer_size;
int num_buffers;
@@ -176,6 +177,7 @@ struct smscore_device_t {
 
void *context;
struct device *device;
+   struct usb_device *usb_device;
 
char devpath[32];
unsigned long device_flags;
diff --git a/drivers/media/usb/siano/smsusb.c b/drivers/media/usb/siano/smsusb.c
index d07349c..7e8e803 100644
--- a/drivers/media/usb/siano/smsusb.c
+++ b/drivers/media/usb/siano/smsusb.c
@@ -446,6 +446,7 @@ static int smsusb_init_device(struct usb_interface *intf, 
int board_id)

Re: [PATCH v3 6/9] media: i2c: ov772x: Remove soc_camera dependencies

2018-01-04 Thread Laurent Pinchart
Hi Jacopo,

Thank you for the patch.

On Thursday, 4 January 2018 18:03:14 EET Jacopo Mondi wrote:
> Remove soc_camera framework dependencies from ov772x sensor driver.
> - Handle clock and gpios
> - Register async subdevice
> - Remove soc_camera specific g/s_mbus_config operations
> - Change image format colorspace from JPEG to SRGB as the two use the
>   same colorspace information but JPEG makes assumptions on color
>   components quantization that do not apply to the sensor
> - Remove sizes crop from get_selection as driver can't scale
> - Add kernel doc to driver interface header file
> - Adjust build system
> 
> This commit does not remove the original soc_camera based driver as long
> as other platforms depends on soc_camera-based CEU driver.
> 
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/i2c/Kconfig  |  11 +++
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/ov772x.c | 177 +++---
>  include/media/i2c/ov772x.h |   6 +-
>  4 files changed, 133 insertions(+), 62 deletions(-)

-- 
Regards,

Laurent Pinchart



Re: [PATCH] media: uvcvideo: support multiple frame descriptors with the same dimensions

2018-01-04 Thread Laurent Pinchart
Hi Philipp,

Thank you for the patch.

On Tuesday, 19 December 2017 10:17:35 EET Philipp Zabel wrote:
> The Microsoft HoloLens Sensors device has two separate frame descriptors
> with the same dimensions, each with a single different frame interval:

Why, oh why ? :-(

>   VideoStreaming Interface Descriptor:
> bLength30
> bDescriptorType36
> bDescriptorSubtype  5 (FRAME_UNCOMPRESSED)
> bFrameIndex 1
> bmCapabilities   0x00
>   Still image unsupported
> wWidth   1280
> wHeight   481
> dwMinBitRate147763200
> dwMaxBitRate147763200
> dwMaxVideoFrameBufferSize  615680
> dwDefaultFrameInterval 33
> bFrameIntervalType  1
> dwFrameInterval( 0)33
>   VideoStreaming Interface Descriptor:
> bLength30
> bDescriptorType36
> bDescriptorSubtype  5 (FRAME_UNCOMPRESSED)
> bFrameIndex 2
> bmCapabilities   0x00
>   Still image unsupported
> wWidth   1280
> wHeight   481
> dwMinBitRate443289600
> dwMaxBitRate443289600
> dwMaxVideoFrameBufferSize  615680
> dwDefaultFrameInterval 11
> bFrameIntervalType  1
> dwFrameInterval( 0)11
> 
> Skip duplicate dimensions in enum_framesizes, let enum_frameintervals list
> the intervals from both frame descriptors. Change set_streamparm to switch
> to the correct frame index when changing the interval. This enables 90 fps
> capture on a Lenovo Explorer Windows Mixed Reality headset.
>
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/media/usb/uvc/uvc_v4l2.c | 66 +++--
>  1 file changed, 50 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> b/drivers/media/usb/uvc/uvc_v4l2.c index 3e7e283a44a8..7d5bf8d56a99 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -373,8 +373,11 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming
> *stream, {
>   struct uvc_streaming_control probe;
>   struct v4l2_fract timeperframe;
> - uint32_t interval;
> + struct uvc_format *format;
> + struct uvc_frame *frame;
> + __u32 interval, tmp, d, maxd;

You can declare tmp and d inside the loop, it should simplify the code 
slightly. Please also avoid naming the variable tmp.

>   int ret;
> + int i;

i can be unsigned.

>   if (parm->type != stream->type)
>   return -EINVAL;
> @@ -396,9 +399,31 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming
> *stream, return -EBUSY;
>   }
> 
> + format = stream->cur_format;
> + frame = stream->cur_frame;
>   probe = stream->ctrl;
> - probe.dwFrameInterval =
> - uvc_try_frame_interval(stream->cur_frame, interval);
> + probe.dwFrameInterval = uvc_try_frame_interval(frame, interval);
> + maxd = abs((__s32)probe.dwFrameInterval - interval);
> +
> + /* Try frames with matching size to find the best frame interval. */
> + for (i = 0; i < format->nframes; i++) {

As a small optimization you can also stop when maxd == 0.

> + if (>frame[i] == stream->cur_frame)
> + continue;
> +
> + if (format->frame[i].wWidth != stream->cur_frame->wWidth ||
> + format->frame[i].wHeight != stream->cur_frame->wHeight)
> + continue;
> +
> + tmp = uvc_try_frame_interval(>frame[i], interval);
> + d = abs((__s32)tmp - interval);
> + if (d >= maxd)
> + continue;
> +
> + frame = >frame[i];
> + probe.bFrameIndex = frame->bFrameIndex;
> + probe.dwFrameInterval = tmp;
> + maxd = d;
> + }
> 
>   /* Probe the device with the new settings. */
>   ret = uvc_probe_video(stream, );
> @@ -408,6 +433,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming
> *stream, }
> 
>   stream->ctrl = probe;
> + stream->cur_frame = frame;
>   mutex_unlock(>mutex);
> 
>   /* Return the actual frame period. */
> @@ -1150,7 +1176,7 @@ static int uvc_ioctl_enum_framesizes(struct file
> *file, void *fh, struct uvc_streaming *stream = handle->stream;
>   struct uvc_format *format = NULL;
>   struct uvc_frame *frame;
> - int i;
> + int i, index;

Could you declare unrelated variables on separate lines ?

I think index can be unsigned (and it seems i can be as well for that matter).

> 

Re: IMX6 interlaced capture

2018-01-04 Thread Tim Harvey
On Thu, Jan 4, 2018 at 10:51 AM, Steve Longerbeam  wrote:
>
>
> On 01/04/2018 09:57 AM, Tim Harvey wrote:
>>
>> On Tue, Jan 2, 2018 at 6:00 PM, Steve Longerbeam 
>> wrote:
>>>
>>> Hi Tim,
>>>
>>> Happy New Year! And pardon the delay.
>>>
>>>
>>> On 12/28/2017 01:56 PM, Tim Harvey wrote:

 Steve/Hans,

 I'm trying to get interlaced capture working with the TDA1997x driver
 I've been working on which is connected to an IMX6 CSI.

 The particular board I'm currently testing on is an IMX6Q which has
 both a TDA19971 HDMI receiver as well as an ADV7180 analog video
 decoder. The media-ctl topology for this board can be found at
 http://dev.gateworks.com/docs/linux/media/imx6q-gw54xx-media.png.

 For adv7180 everything appears to be working as expected:
 - media-ctl --get-v4l2 '"adv7180 2-0020":0' shows:
 [fmt:UYVY8_2X8/720x480 field:interlaced colorspace:smpte170m]
 - he following captures/streams from the adv7180 using the vdic to
 de-interlace:
 media-ctl --link "adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]
 media-ctl --link "ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]
 media-ctl --link "ipu2_csi1":1 -> "ipu2_vdic":0[1]
 media-ctl --link "ipu2_vdic":2 -> "ipu2_ic_prp":0[1]
 media-ctl --link "ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]
 media-ctl --link "ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]
 media-ctl --set-v4l2 'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]
 media-ctl --set-v4l2 'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480
 field:interlaced]
 media-ctl --set-v4l2 'ipu2_csi1':1 [fmt:UYVY2X8/720x480
 field:interlaced]
 media-ctl --set-v4l2 'ipu2_vdic':2 [fmt:UYVY2X8/720x480
 field:interlaced]
 media-ctl --set-v4l2 'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:none]
 media-ctl --set-v4l2 'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]
 v4l2-ctl -d /dev/video3
 --set-fmt-video=width=720,height=480,pixelformat=UYVY
 # capture 1 frame
 v4l2-ctl -d /dev/video1 --stream-mmap --stream-skip=1
 --stream-to=/tmp/x.raw --stream-count=1
 # stream jpeg/rtp
 gst-launch-1.0 v4l2src device=/dev/video3 !
 "video/x-raw,width=720,height=480,format=UYVY" !
  jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=5000"

 For the tda1997x I'm trying to do something similar:
 - media-ctl --get-v4l2 '"tda19971 2-0048":0' shows:
 [fmt:UYVY8_1X16/1920x1080 field:alternate colorspace:srgb]
  still not sure V4L2_FIELD_ALTERNATE/SRGB returned from tda1997x
 get_fmt is correct
 - I setup the pipeline with:
 media-ctl --link "tda19971 2-0048":0 -> "ipu1_csi0_mux":1[1]
 media-ctl --link "ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]
 media-ctl --link "ipu1_csi0":1 -> "ipu1_vdic":0[1]
 media-ctl --link "ipu1_vdic":2 -> "ipu1_ic_prp":0[1]
 media-ctl --link "ipu1_ic_prp":2 -> "ipu1_ic_prpvf":0[1]
 media-ctl --link "ipu1_ic_prpvf":1 -> "ipu1_ic_prpvf capture":0[1]
 media-ctl --set-v4l2 'tda19971 2-0048':0[fmt:UYVY8_1X16/1920x1080]
 media-ctl --set-v4l2 'ipu1_csi0_mux':2[fmt:UYVY8_1X16/1920x1080
 field:alternate]
 media-ctl --set-v4l2 'ipu1_csi0':1[fmt:UYVY8_1X16/1920x1080
 field:alternate]
 media-ctl --set-v4l2 'ipu1_vdic':2[fmt:UYVY8_1X16/1920x1080
 field:alternate]
 media-ctl --set-v4l2 'ipu1_ic_prp':2[fmt:UYVY8_1X16/1920x1080
 field:none]
 media-ctl --set-v4l2 'ipu1_ic_prpvf':1[fmt:UYVY8_1X16/1920x1080
 field:none]
 v4l2-ctl -d /dev/video1
 --set-fmt-video=width=1920,height=1080,pixelformat=UYVY
 v4l2-ctl -d /dev/v4l-subdev1 --set-dv-bt-timings=query
 v4l2-ctl -d /dev/video1 --stream-mmap --stream-skip=1
 --stream-to=/tmp/x.raw --stream-count=1
 ipu1_csi0: bayer/16-bit parallel buses must go to IDMAC pad
 ipu1_ic_prpvf: pipeline start failed with -22
 VIDIOC_STREAMON: failed: Invalid argument
>>
>> Steve,
>>
>> Thanks for the help.
>>
>>> Right, according to the i.MX6 reference manual, if the CSI muxes
>>> are receiving from the parallel bus input with width >= 16 bits,
>>> that data can't be passed to the IC. It never really made much sense
>>> to me, and I can't remember if I ever tried it, maybe not, because
>>> I don't have such hardware.
>>
>> hmmm... that's not good. I may have to dig into what's being done in
>> my 3.14 kernel with the Freescale capture driver where I can capture
>> 1080p60 fine with my tda1997x driver there.
>>
>>> Try this hack as an experiment: modify is_parallel_16bit_bus() in
>>> imx-media-csi.c to simply return false, and see if the above pipeline
>>> works.
>>
>> I'm currently on 4.15-rc1 which doesn't have a
>> 'is_parallel_16bit_bus()' but if I comment out the check we are
>> talking about in csi_link_validate as such:
>>
>> --- a/drivers/staging/media/imx/imx-media-csi.c
>> +++ b/drivers/staging/media/imx/imx-media-csi.c
>> @@ -999,6 +999,7 @@ static int csi_link_validate(struct v4l2_subdev *sd,
>>  

Re: [PATCH v3 3/9] v4l: platform: Add Renesas CEU driver

2018-01-04 Thread Laurent Pinchart
Hi Jacopo,

Thank you for the patch.

On Thursday, 4 January 2018 18:03:11 EET Jacopo Mondi wrote:
> Add driver for Renesas Capture Engine Unit (CEU).
> 
> The CEU interface supports capturing 'data' (YUV422) and 'images'
> (NV[12|21|16|61]).
> 
> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
> 
> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> platform GR-Peach.
> 
> Tested with ov7725 camera sensor on SH4 platform Migo-R.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/Kconfig   |9 +
>  drivers/media/platform/Makefile  |1 +
>  drivers/media/platform/renesas-ceu.c | 1649 +++
>  3 files changed, 1659 insertions(+)
>  create mode 100644 drivers/media/platform/renesas-ceu.c

[snip]

> diff --git a/drivers/media/platform/renesas-ceu.c
> b/drivers/media/platform/renesas-ceu.c new file mode 100644
> index 000..a614859
> --- /dev/null
> +++ b/drivers/media/platform/renesas-ceu.c

[snip]

> +/*
> + * struct ceu_data - Platform specific CEU data
> + * @irq_mask: CETCR mask with all interrupt sources enabled. The mask
> differs
> + * between SH4 and RZ platforms.
> + */
> +struct ceu_data {
> + u32 irq_mask;
> +};
> +
> +const struct ceu_data ceu_data_rz = {
> + .irq_mask = CEU_CETCR_ALL_IRQS_RZ,
> +};
> +
> +const struct ceu_data ceu_data_sh4 = {
> + .irq_mask = CEU_CETCR_ALL_IRQS_SH4,
> +};

These two can be const.

> +#if IS_ENABLED(CONFIG_OF)
> +static const struct of_device_id ceu_of_match[] = {
> + { .compatible = "renesas,r7s72100-ceu", .data = _data_rz },
> + { .compatible = "renesas,ceu", .data = _data_rz },

Do you need both ? What's your policy for compatible strings ? As far as I 
understand there's no generic CEU, as the SH4 and RZ versions are not 
compatible. Should the "renesas,ceu" compatible string then be replaced by 
"renesas,rz-ceu" and the first entry dropped ?

> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ceu_of_match);
> +#endif
> +
> +static int ceu_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + const struct ceu_data *ceu_data;
> + struct ceu_device *ceudev;
> + struct resource *res;
> + unsigned int irq;
> + int num_subdevs;
> + int ret;
> +
> + ceudev = kzalloc(sizeof(*ceudev), GFP_KERNEL);
> + if (!ceudev)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, ceudev);
> + ceudev->dev = dev;
> +
> + INIT_LIST_HEAD(>capture);
> + spin_lock_init(>lock);
> + mutex_init(>mlock);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + ceudev->base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(ceudev->base))
> + goto error_free_ceudev;
> +
> + ret = platform_get_irq(pdev, 0);
> + if (ret < 0) {
> + dev_err(dev, "Failed to request irq: %d\n", ret);

s/request/get/ (it was correct in v2).

> + goto error_free_ceudev;
> + }
> + irq = ret;
> +
> + ret = devm_request_irq(dev, irq, ceu_irq,
> +0, dev_name(dev), ceudev);
> + if (ret) {
> + dev_err(>dev, "Unable to register CEU interrupt.\n");

s/register/request/ (this is the message that should have been changed).

> + return ret;

You're leaking ceudev here.

> + }
> +
> + pm_runtime_enable(dev);
> +
> + ret = v4l2_device_register(dev, >v4l2_dev);
> + if (ret)
> + goto error_pm_disable;
> +
> + if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> + ceu_data = of_match_device(ceu_of_match, dev)->data;
> + num_subdevs = ceu_parse_dt(ceudev);
> + } else if (dev->platform_data) {
> + /* Assume SH4 if booting with platform data. */
> + ceu_data = _data_sh4;
> + num_subdevs = ceu_parse_platform_data(ceudev,
> +   dev->platform_data);
> + } else {
> + num_subdevs = -EINVAL;
> + }
> +
> + if (num_subdevs < 0) {
> + ret = num_subdevs;
> + goto error_v4l2_unregister;
> + }
> + ceudev->irq_mask = ceu_data->irq_mask;
> +
> + ceudev->notifier.v4l2_dev   = >v4l2_dev;
> + ceudev->notifier.subdevs= ceudev->asds;
> + ceudev->notifier.num_subdevs= num_subdevs;
> + ceudev->notifier.ops= _notify_ops;
> + ret = v4l2_async_notifier_register(>v4l2_dev,
> +>notifier);
> + if (ret)
> + goto error_v4l2_unregister;
> +
> + dev_info(dev, "Renesas Capture Engine Unit %s\n", dev_name(dev));
> +
> + return 0;
> +
> +error_v4l2_unregister:
> + v4l2_device_unregister(>v4l2_dev);
> +error_pm_disable:
> + pm_runtime_disable(dev);
> +error_free_ceudev:
> + kfree(ceudev);
> +
> + return ret;
> +}

-- 
Regards,

Laurent Pinchart



Re: [PATCH v3 9/9] arch: sh: migor: Use new renesas-ceu camera driver

2018-01-04 Thread Laurent Pinchart
Hi Jacopo,

Thank you for the patch.

On Thursday, 4 January 2018 18:03:17 EET Jacopo Mondi wrote:
> Migo-R platform uses sh_mobile_ceu camera driver, which is now being
> replaced by a proper V4L2 camera driver named 'renesas-ceu'.
> 
> Move Migo-R platform to use the v4l2 renesas-ceu camera driver
> interface and get rid of soc_camera defined components used to register
> sensor drivers and of platform specific enable/disable routines.
> 
> Register clock source and GPIOs for sensor drivers, so they can use
> clock and gpio APIs.
> 
> Also, memory for CEU video buffers is now reserved with membocks APIs,
> and need to be declared as dma_coherent during machine initialization to
> remove that architecture specific part from CEU driver.
> 
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/sh/boards/mach-migor/setup.c  | 225 ++
>  arch/sh/kernel/cpu/sh4a/clock-sh7722.c |   2 +-
>  2 files changed, 101 insertions(+), 126 deletions(-)

-- 
Regards,

Laurent Pinchart



Re: IMX6 interlaced capture

2018-01-04 Thread Steve Longerbeam



On 01/04/2018 10:51 AM, Steve Longerbeam wrote:



On 01/04/2018 09:57 AM, Tim Harvey wrote:




Try this hack as an experiment: modify is_parallel_16bit_bus() in
imx-media-csi.c to simply return false, and see if the above pipeline
works.

I'm currently on 4.15-rc1 which doesn't have a
'is_parallel_16bit_bus()' but if I comment out the check we are
talking about in csi_link_validate as such:

--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -999,6 +999,7 @@ static int csi_link_validate(struct v4l2_subdev *sd,
 is_csi2 = (sensor_ep->bus_type == V4L2_MBUS_CSI2);
 incc = priv->cc[CSI_SINK_PAD];

+/*
 if (priv->dest != IPU_CSI_DEST_IDMAC &&
 (incc->bayer || (!is_csi2 &&
sensor_ep->bus.parallel.bus_width >= 16))) {
@@ -1007,6 +1008,7 @@ static int csi_link_validate(struct v4l2_subdev 
*sd,

 ret = -EINVAL;
 goto out;
 }
+*/

 if (is_csi2) {
 int vc_num = 0;

I get a pipeline start failure for ipu1_ic_prpvf:

root@ventana:~# v4l2-ctl -d /dev/video1 --stream-mmap --stream-skip=1
--stream-to=/tmp/x.raw --stream-count=1
[  909.993353] tda1997x 2-0048: tda1997x_get_pad_format
[  909.998342] tda1997x 2-0048: tda1997x_fill_format
 my tda1997x driver debug messages
[  910.004483] ipu1_ic_prpvf: pipeline start failed with -32
VIDIOC_STREAMON: failed: Broken pipe


The driver doesn't really support V4L2_FIELD_ALTERNATE, the CSI subdev
attempts to translate this to sequential-top-bottom or 
sequential-bottom-top
at the CSI output pads, since alternate holds no info about field 
order. I doubt
alternate is correct for the TDA19971 anyway, so that should be fixed 
in the
tda19971 driver. Until then, set to "seq-bt" downstream from the CSI, 
as in:


media-ctl --set-v4l2 'tda19971 2-0048':0[fmt:UYVY8_1X16/1920x1080]
media-ctl --set-v4l2 'ipu1_csi0_mux':2[fmt:UYVY8_1X16/1920x1080 
field:alternate]
media-ctl --set-v4l2 'ipu1_csi0':1[fmt:UYVY8_1X16/1920x1080 
field:alternate]

media-ctl --set-v4l2 'ipu1_vdic':2[fmt:UYVY8_1X16/1920x1080 field:seq-bt]
media-ctl --set-v4l2 'ipu1_ic_prp':2[fmt:UYVY8_1X16/1920x1080 field:none]
media-ctl --set-v4l2 'ipu1_ic_prpvf':1[fmt:UYVY8_1X16/1920x1080 
field:none]


Actually just noticed another problem with the original pipeline, the 
ipu1_vdic output
pad is always progressive/non-interlaced. The output pad enforces 
progressive, but

to be technically correct this should be:

media-ctl --set-v4l2 'tda19971 2-0048':0[fmt:UYVY8_1X16/1920x1080]
media-ctl --set-v4l2 'ipu1_csi0_mux':2[fmt:UYVY8_1X16/1920x1080 
field:alternate]
media-ctl --set-v4l2 'ipu1_csi0':1[fmt:UYVY8_1X16/1920x1080 
field:alternate]

media-ctl --set-v4l2 'ipu1_vdic':2[fmt:UYVY8_1X16/1920x1080 field:none]
media-ctl --set-v4l2 'ipu1_ic_prp':2[fmt:UYVY8_1X16/1920x1080 field:none]
media-ctl --set-v4l2 'ipu1_ic_prpvf':1[fmt:UYVY8_1X16/1920x1080 field:none]


But as said in my last email, if the tda19971 supports one of the 
sequential field
types that explicitly specifies field order, it would be better to start 
with that right

up front:

media-ctl --set-v4l2 'tda19971 2-0048':0[fmt:UYVY8_1X16/1920x1080 
field:seq-tb]
media-ctl --set-v4l2 'ipu1_csi0_mux':2[fmt:UYVY8_1X16/1920x1080 
field:seq-tb]

media-ctl --set-v4l2 'ipu1_csi0':1[fmt:AYUV32/1920x1080 field:seq-tb]
media-ctl --set-v4l2 'ipu1_vdic':2[fmt:AYUV32/1920x1080 field:none]
media-ctl --set-v4l2 'ipu1_ic_prp':2[fmt:AYUV32/1920x1080 field:none]
media-ctl --set-v4l2 'ipu1_ic_prpvf':1[fmt:UYVY8_1X16/1920x1080 field:none]

Note also the IPU-internal pixel formats should be AYUV32.

Steve




[PATCH 1/2] media: staging: use tabs instead of spaces at Kconfig and davinci

2018-01-04 Thread Mauro Carvalho Chehab
Even on text and Kconfigs, what we do on media is to use
tabs for indentation.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/Kconfig   | 14 +++---
 drivers/staging/media/davinci_vpfe/TODO | 10 +-
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index 227437f22acf..e68e1d343d53 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -1,19 +1,19 @@
 menuconfig STAGING_MEDIA
-bool "Media staging drivers"
-default n
----help---
-  This option allows you to select a number of media drivers that
+   bool "Media staging drivers"
+   default n
+   ---help---
+ This option allows you to select a number of media drivers that
  don't have the "normal" Linux kernel quality level.
  Most of them don't follow properly the V4L, DVB and/or RC API's,
  so, they won't likely work fine with the existing applications.
  That also means that, once fixed, their API's will change to match
  the existing ones.
 
-  If you wish to work on these drivers, to help improve them, or
-  to report problems you have with them, please use the
+ If you wish to work on these drivers, to help improve them, or
+ to report problems you have with them, please use the
  linux-media@vger.kernel.org mailing list.
 
-  If in doubt, say N here.
+ If in doubt, say N here.
 
 
 if STAGING_MEDIA && MEDIA_SUPPORT
diff --git a/drivers/staging/media/davinci_vpfe/TODO 
b/drivers/staging/media/davinci_vpfe/TODO
index 7015ab35ded5..3e5477e8cfa5 100644
--- a/drivers/staging/media/davinci_vpfe/TODO
+++ b/drivers/staging/media/davinci_vpfe/TODO
@@ -2,11 +2,11 @@ TODO (general):
 ==
 
 - User space interface refinement
-- Controls should be used when possible rather than private ioctl
-- No enums should be used
-- Use of MC and V4L2 subdev APIs when applicable
-- Single interface header might suffice
-- Current interface forces to configure everything at once
+   - Controls should be used when possible rather than private ioctl
+   - No enums should be used
+   - Use of MC and V4L2 subdev APIs when applicable
+   - Single interface header might suffice
+   - Current interface forces to configure everything at once
 - Get rid of the dm365_ipipe_hw.[ch] layer
 - Active external sub-devices defined by link configuration; no strcmp
   needed
-- 
2.14.3




Re: [RFC/RFT PATCH 6/6] uvcvideo: Move decode processing to process context

2018-01-04 Thread Guennadi Liakhovetski
On Wed, 3 Jan 2018, Kieran Bingham wrote:

> From: Kieran Bingham 
> 
> Newer high definition cameras, and cameras with multiple lenses such as
> the range of stereovision cameras now available have ever increasing
> data rates.
> 
> The inclusion of a variable length packet header in URB packets mean
> that we must memcpy the frame data out to our destination 'manually'.
> This can result in data rates of up to 2 gigabits per second being
> processed.
> 
> To improve efficiency, and maximise throughput, handle the URB decode
> processing through a work queue to move it from interrupt context, and
> allow multiple processors to work on URBs in parallel.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/media/usb/uvc/uvc_queue.c |  12 +++-
>  drivers/media/usb/uvc/uvc_video.c | 114 ++-
>  drivers/media/usb/uvc/uvcvideo.h  |  24 +++-
>  3 files changed, 132 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_queue.c 
> b/drivers/media/usb/uvc/uvc_queue.c
> index 204dd91a8526..07fcbfc132c9 100644
> --- a/drivers/media/usb/uvc/uvc_queue.c
> +++ b/drivers/media/usb/uvc/uvc_queue.c
> @@ -179,10 +179,22 @@ static void uvc_stop_streaming(struct vb2_queue *vq)
>   struct uvc_video_queue *queue = vb2_get_drv_priv(vq);
>   struct uvc_streaming *stream = uvc_queue_to_stream(queue);
>  
> + /* Prevent new buffers coming in. */
> + spin_lock_irq(>irqlock);
> + queue->flags |= UVC_QUEUE_STOPPING;
> + spin_unlock_irq(>irqlock);
> +
> + /*
> +  * All pending work should be completed before disabling the stream, as
> +  * all URBs will be free'd during uvc_video_enable(s, 0).
> +  */
> + flush_workqueue(stream->async_wq);
> +
>   uvc_video_enable(stream, 0);
>  
>   spin_lock_irq(>irqlock);
>   uvc_queue_return_buffers(queue, UVC_BUF_STATE_ERROR);
> + queue->flags &= ~UVC_QUEUE_STOPPING;
>   spin_unlock_irq(>irqlock);
>  }
>  
> diff --git a/drivers/media/usb/uvc/uvc_video.c 
> b/drivers/media/usb/uvc/uvc_video.c
> index 045ac655313c..b7b32a6bc2dc 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -1058,21 +1058,70 @@ static int uvc_video_decode_start(struct 
> uvc_streaming *stream,
>   return data[0];
>  }
>  
> -static void uvc_video_decode_data(struct uvc_streaming *stream,
> - struct uvc_buffer *buf, const __u8 *data, int len)
> +/*
> + * uvc_video_decode_data_work: Asynchronous memcpy processing
> + *
> + * Perform memcpy tasks in process context, with completion handlers
> + * to return the URB, and buffer handles.
> + *
> + * The work submitter must pre-determine that the work is safe
> + */
> +static void uvc_video_decode_data_work(struct work_struct *work)
>  {
> - unsigned int maxlen, nbytes;
> - void *mem;
> + struct uvc_urb *uvc_urb = container_of(work, struct uvc_urb, work);
> + struct uvc_streaming *stream = uvc_urb->stream;
> + struct uvc_video_queue *queue = >queue;
> + unsigned int i;
> + bool stopping;
> + int ret;
> +
> + for (i = 0; i < uvc_urb->packets; i++) {
> + struct uvc_decode_op *op = _urb->decodes[i];
> +
> + memcpy(op->dst, op->src, op->len);
> +
> + /* Release reference taken on this buffer */
> + uvc_queue_buffer_release(op->buf);
> + }
> +
> + /*
> +  * Prevent resubmitting URBs when shutting down to ensure that no new
> +  * work item will be scheduled after uvc_stop_streaming() flushes the
> +  * work queue.
> +  */
> + spin_lock_irq(>irqlock);
> + stopping = queue->flags & UVC_QUEUE_STOPPING;
> + spin_unlock_irq(>irqlock);

Are you sure this locking really helps? What if uvc_stop_streaming() runs 
here?

Thanks
Guennadi

> +
> + if (stopping)
> + return;
> +
> + ret = usb_submit_urb(uvc_urb->urb, GFP_ATOMIC);
> + if (ret < 0)
> + uvc_printk(KERN_ERR, "Failed to resubmit video URB (%d).\n",
> +ret);
> +}


Re: IMX6 interlaced capture

2018-01-04 Thread Steve Longerbeam



On 01/04/2018 09:57 AM, Tim Harvey wrote:

On Tue, Jan 2, 2018 at 6:00 PM, Steve Longerbeam  wrote:

Hi Tim,

Happy New Year! And pardon the delay.


On 12/28/2017 01:56 PM, Tim Harvey wrote:

Steve/Hans,

I'm trying to get interlaced capture working with the TDA1997x driver
I've been working on which is connected to an IMX6 CSI.

The particular board I'm currently testing on is an IMX6Q which has
both a TDA19971 HDMI receiver as well as an ADV7180 analog video
decoder. The media-ctl topology for this board can be found at
http://dev.gateworks.com/docs/linux/media/imx6q-gw54xx-media.png.

For adv7180 everything appears to be working as expected:
- media-ctl --get-v4l2 '"adv7180 2-0020":0' shows:
[fmt:UYVY8_2X8/720x480 field:interlaced colorspace:smpte170m]
- he following captures/streams from the adv7180 using the vdic to
de-interlace:
media-ctl --link "adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]
media-ctl --link "ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]
media-ctl --link "ipu2_csi1":1 -> "ipu2_vdic":0[1]
media-ctl --link "ipu2_vdic":2 -> "ipu2_ic_prp":0[1]
media-ctl --link "ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]
media-ctl --link "ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]
media-ctl --set-v4l2 'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]
media-ctl --set-v4l2 'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480
field:interlaced]
media-ctl --set-v4l2 'ipu2_csi1':1 [fmt:UYVY2X8/720x480 field:interlaced]
media-ctl --set-v4l2 'ipu2_vdic':2 [fmt:UYVY2X8/720x480 field:interlaced]
media-ctl --set-v4l2 'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:none]
media-ctl --set-v4l2 'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]
v4l2-ctl -d /dev/video3
--set-fmt-video=width=720,height=480,pixelformat=UYVY
# capture 1 frame
v4l2-ctl -d /dev/video1 --stream-mmap --stream-skip=1
--stream-to=/tmp/x.raw --stream-count=1
# stream jpeg/rtp
gst-launch-1.0 v4l2src device=/dev/video3 !
"video/x-raw,width=720,height=480,format=UYVY" !
 jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=5000"

For the tda1997x I'm trying to do something similar:
- media-ctl --get-v4l2 '"tda19971 2-0048":0' shows:
[fmt:UYVY8_1X16/1920x1080 field:alternate colorspace:srgb]
 still not sure V4L2_FIELD_ALTERNATE/SRGB returned from tda1997x
get_fmt is correct
- I setup the pipeline with:
media-ctl --link "tda19971 2-0048":0 -> "ipu1_csi0_mux":1[1]
media-ctl --link "ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]
media-ctl --link "ipu1_csi0":1 -> "ipu1_vdic":0[1]
media-ctl --link "ipu1_vdic":2 -> "ipu1_ic_prp":0[1]
media-ctl --link "ipu1_ic_prp":2 -> "ipu1_ic_prpvf":0[1]
media-ctl --link "ipu1_ic_prpvf":1 -> "ipu1_ic_prpvf capture":0[1]
media-ctl --set-v4l2 'tda19971 2-0048':0[fmt:UYVY8_1X16/1920x1080]
media-ctl --set-v4l2 'ipu1_csi0_mux':2[fmt:UYVY8_1X16/1920x1080
field:alternate]
media-ctl --set-v4l2 'ipu1_csi0':1[fmt:UYVY8_1X16/1920x1080
field:alternate]
media-ctl --set-v4l2 'ipu1_vdic':2[fmt:UYVY8_1X16/1920x1080
field:alternate]
media-ctl --set-v4l2 'ipu1_ic_prp':2[fmt:UYVY8_1X16/1920x1080 field:none]
media-ctl --set-v4l2 'ipu1_ic_prpvf':1[fmt:UYVY8_1X16/1920x1080
field:none]
v4l2-ctl -d /dev/video1
--set-fmt-video=width=1920,height=1080,pixelformat=UYVY
v4l2-ctl -d /dev/v4l-subdev1 --set-dv-bt-timings=query
v4l2-ctl -d /dev/video1 --stream-mmap --stream-skip=1
--stream-to=/tmp/x.raw --stream-count=1
ipu1_csi0: bayer/16-bit parallel buses must go to IDMAC pad
ipu1_ic_prpvf: pipeline start failed with -22
VIDIOC_STREAMON: failed: Invalid argument

Steve,

Thanks for the help.


Right, according to the i.MX6 reference manual, if the CSI muxes
are receiving from the parallel bus input with width >= 16 bits,
that data can't be passed to the IC. It never really made much sense
to me, and I can't remember if I ever tried it, maybe not, because
I don't have such hardware.

hmmm... that's not good. I may have to dig into what's being done in
my 3.14 kernel with the Freescale capture driver where I can capture
1080p60 fine with my tda1997x driver there.


Try this hack as an experiment: modify is_parallel_16bit_bus() in
imx-media-csi.c to simply return false, and see if the above pipeline
works.

I'm currently on 4.15-rc1 which doesn't have a
'is_parallel_16bit_bus()' but if I comment out the check we are
talking about in csi_link_validate as such:

--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -999,6 +999,7 @@ static int csi_link_validate(struct v4l2_subdev *sd,
 is_csi2 = (sensor_ep->bus_type == V4L2_MBUS_CSI2);
 incc = priv->cc[CSI_SINK_PAD];

+/*
 if (priv->dest != IPU_CSI_DEST_IDMAC &&
 (incc->bayer || (!is_csi2 &&
  sensor_ep->bus.parallel.bus_width >= 16))) {
@@ -1007,6 +1008,7 @@ static int csi_link_validate(struct v4l2_subdev *sd,
 ret = -EINVAL;
 goto out;
 }
+*/

 if (is_csi2) {
 int vc_num = 0;

I get a pipeline start failure for ipu1_ic_prpvf:

root@ventana:~# 

Re: [PATCH] media: don't use whitespaces for indentation

2018-01-04 Thread Mauro Carvalho Chehab
Em Thu, 4 Jan 2018 15:08:52 +0200
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Thu, Jan 04, 2018 at 07:27:48AM -0500, Mauro Carvalho Chehab wrote:
> > On several places, whitespaces are being used for indentation,
> > or even at the end of the line.
> > 
> > Fix them, by running a script that fix it inside drivers/media
> > and include/media.  
> 
> What kind of a script?

Just sent a patch series with the script, and addressing a bunch of
other places where we have bad spacing.

> Could you also add includ/uapi/media to this?

I added more places to it:

$ rmspaces.pl  $(find drivers/media -type f) $(find include/media -type f) 
include/uapi/linux/videodev2.h include/uapi/linux/v4l2-* 
include/uapi/linux/dvb/*

It is probably worth to run is also against staging/media. I'll do it in
separate.


Thanks,
Mauro


[PATCH 1/2] media: fix usage of whitespaces and on indentation

2018-01-04 Thread Mauro Carvalho Chehab
On several places, whitespaces are being used for indentation,
or even at the end of the line.

Fix them.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/Kconfig|  8 ++---
 drivers/media/dvb-core/Makefile  |  2 +-
 drivers/media/dvb-core/dvb_ca_en50221.c  |  2 +-
 drivers/media/dvb-frontends/cx24116.c|  2 +-
 drivers/media/dvb-frontends/drx39xyj/drxj.c  |  2 +-
 drivers/media/dvb-frontends/drxk.h   |  6 ++--
 drivers/media/dvb-frontends/mb86a20s.c   |  2 +-
 drivers/media/dvb-frontends/mn88473.c|  2 +-
 drivers/media/dvb-frontends/tda18271c2dd.h   |  4 +--
 drivers/media/i2c/Kconfig| 10 +++
 drivers/media/i2c/adv7343.c  |  2 +-
 drivers/media/i2c/adv7393.c  |  2 +-
 drivers/media/i2c/cx25840/cx25840-core.c |  6 ++--
 drivers/media/i2c/cx25840/cx25840-ir.c   |  4 +--
 drivers/media/i2c/smiapp/smiapp-core.c   |  2 +-
 drivers/media/i2c/tvp5150_reg.h  |  4 +--
 drivers/media/pci/cx18/cx18-fileops.c|  2 +-
 drivers/media/pci/cx18/cx18-streams.c|  2 +-
 drivers/media/pci/cx23885/cx23888-ir.c   |  4 +--
 drivers/media/pci/ivtv/ivtv-cards.c  |  2 +-
 drivers/media/pci/pluto2/pluto2.c|  2 +-
 drivers/media/pci/pt1/pt1.c  |  2 +-
 drivers/media/pci/pt1/va1j5jf8007s.c |  2 +-
 drivers/media/pci/pt1/va1j5jf8007s.h |  2 +-
 drivers/media/pci/pt1/va1j5jf8007t.c |  2 +-
 drivers/media/pci/pt1/va1j5jf8007t.h |  2 +-
 drivers/media/pci/saa7146/mxb.c  |  2 +-
 drivers/media/pci/tw5864/tw5864-video.c  |  2 +-
 drivers/media/platform/Kconfig   | 38 
 drivers/media/platform/arv.c |  4 +--
 drivers/media/platform/blackfin/ppi.c|  2 +-
 drivers/media/platform/davinci/dm355_ccdc.c  |  4 +--
 drivers/media/platform/davinci/dm644x_ccdc.c |  6 ++--
 drivers/media/platform/davinci/vpfe_capture.c|  6 ++--
 drivers/media/platform/exynos4-is/fimc-core.h|  2 +-
 drivers/media/platform/exynos4-is/fimc-lite.h|  4 +--
 drivers/media/platform/mtk-vcodec/vdec_vpu_if.h  |  2 +-
 drivers/media/platform/omap3isp/isp.c|  2 +-
 drivers/media/platform/sti/hva/hva.h |  2 +-
 drivers/media/platform/via-camera.h  |  2 +-
 drivers/media/radio/radio-maxiradio.c|  2 +-
 drivers/media/radio/radio-mr800.c| 24 +++
 drivers/media/radio/si470x/radio-si470x-common.c | 24 +++
 drivers/media/radio/wl128x/fmdrv_common.h| 10 +++
 drivers/media/rc/Kconfig |  8 ++---
 drivers/media/tuners/mt2063.c|  4 +--
 drivers/media/tuners/si2157.c|  2 +-
 drivers/media/tuners/tuner-i2c.h |  2 +-
 drivers/media/usb/as102/as10x_cmd_cfg.c  |  6 ++--
 drivers/media/usb/cx231xx/cx231xx-avcore.c   |  2 +-
 drivers/media/usb/em28xx/Kconfig | 14 -
 drivers/media/usb/gspca/autogain_functions.c | 12 
 drivers/media/usb/gspca/cpia1.c  |  2 +-
 drivers/media/usb/gspca/stv06xx/stv06xx.h|  2 +-
 drivers/media/usb/pvrusb2/pvrusb2-devattr.c  | 12 
 drivers/media/usb/tm6000/tm6000.h|  2 +-
 drivers/media/usb/usbtv/Kconfig  | 16 +-
 drivers/media/v4l2-core/Kconfig  |  4 +--
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c|  2 +-
 drivers/media/v4l2-core/v4l2-dv-timings.c|  2 +-
 include/media/dvb_frontend.h | 12 
 include/media/dvb_vb2.h  |  2 +-
 include/media/dvbdev.h   |  4 +--
 include/media/v4l2-async.h   |  8 ++---
 include/media/v4l2-common.h  |  4 +--
 include/media/v4l2-ctrls.h   |  2 +-
 include/media/v4l2-dev.h | 16 +-
 include/media/v4l2-event.h   |  2 +-
 include/media/v4l2-subdev.h  |  8 ++---
 69 files changed, 185 insertions(+), 185 deletions(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 3f69b948d102..145e12bfb819 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -80,11 +80,11 @@ config MEDIA_SDR_SUPPORT
 config MEDIA_CEC_SUPPORT
bool "HDMI CEC support"
---help---
- Enable support for HDMI CEC (Consumer Electronics Control),
- which is an optional HDMI feature.
+Enable support for HDMI CEC (Consumer Electronics Control),
+which is an optional HDMI feature.
 
- Say Y when you have an HDMI receiver, transmitter or a USB CEC
- adapter that supports HDMI CEC.
+

[PATCH 0/2] Cleanup bad whitespaces along media tree

2018-01-04 Thread Mauro Carvalho Chehab
>From time to time, bad whitespaces end by being merged at the tree.
Instead of taking lots of individual patches fixing them, it is a way better
to remove them at once. That's what this patch series does.

Both use the script below. The first patch was made using it at its
"standard" mode, with checks only for identations, whitespaces at the
end and comments like " *".

The second one was generated using "--spacetab" with looks specifically for
"" patterns.

This script has other modes, but they aren't used, as the goal here is not to
replace all spaces by tabs. Just to fix the ones that violate our coding style.

#!/usr/bin/perl
use Getopt::Long;
use strict;
use autodie;
use Text::Tabs;

my $hard;
my $harder;
my $notab;
my $help;
my $diffmode;
my $spacetab;

GetOptions(
"--hard" => \$hard,
"--harder" => \$harder,
"--spacetab" => \$spacetab,
"--notabremoval" => \$notab,
"--help" => \$help,
"--diff" => \$diffmode);

$help = 1 if ($#ARGV < 0);

print "Usage: $ARGV[0] [--help] [--hard] [--spacetab] [--notabremoval] [--diff] 
files\n" if ($help);
print "Hard algorithm for remove spaces. May unalign spaces.\n" if ($hard);
print "Working with diff files\n" if ($diffmode);

foreach my $argnum (0 .. $#ARGV) {
my $changed = 0;
my $file=$ARGV[$argnum];

my ($dev,$ino,$mode) = stat($file);

open IN, "<$file";
open OUT, ">$file.new";
while () {
if ($diffmode) {
if (!(/^[\+][^\+]/)) {
print OUT $_;
next;
}
s,^[\+],,;
}

my $prev = $_;
s/[ \t]+$//;
s<^ {8}> <\t> if (!$notab);
s<^ {1,7}\t> <\t> if (!$notab);
s<^ \* {1,4}\t> < *\t>; # Handle Kernel-doc comments

if ($spacetab) {
while (m/^(.*)( +\t)/g) {
my $t = expand($1);
my ($o, $s) = ($2, $2); 

my $pos = length($t) - 1;
my $p = 7 - ($pos % 8);
#printf STDERR "pos $pos, tabstop up to $p\n$_";
if (!$p) {
$s =~ s<^ {1,7}> <>;
} else {
my $p1 = $p - 1;
$s =~ s<\ {1,$p1}> <>;
$s =~ s<\ {$p,7}> <\t>;
}
$s =~ s/\t {8}/\t\t/g;
s/($o)/$s/;
#print STDERR $_;
}
}

s< {1,7}\t> <\t> if ($hard);
$_ = unexpand($_) if ($harder);

if (!$notab) {
while( s<\t {8}> <\t\t>g || s<\t {1,7}\t> <\t\t>g ) {}
}

$_ = "+$_" if ($diffmode);

print OUT $_;

$changed = 1 if ($prev ne $_);
}
close IN;
close OUT;
rename "$file.new", $file;

chmod $mode, $file;

print "whitespaces cleaned on $file\n" if ($changed);
}


Mauro Carvalho Chehab (2):
  media: fix usage of whitespaces and on indentation
  media: replace all  occurrences

 drivers/media/Kconfig  |   8 +-
 drivers/media/common/saa7146/saa7146_video.c   |   8 +-
 drivers/media/dvb-core/Makefile|   4 +-
 drivers/media/dvb-core/dvb_ca_en50221.c|   2 +-
 drivers/media/dvb-frontends/au8522_priv.h  | 218 -
 drivers/media/dvb-frontends/cx24116.c  |   2 +-
 drivers/media/dvb-frontends/drx39xyj/drx_driver.h  |   2 +-
 drivers/media/dvb-frontends/drx39xyj/drxj.c|   2 +-
 drivers/media/dvb-frontends/drxk.h |   6 +-
 drivers/media/dvb-frontends/mb86a20s.c |   2 +-
 drivers/media/dvb-frontends/mn88473.c  |   2 +-
 drivers/media/dvb-frontends/stb0899_drv.c  |  10 +-
 drivers/media/dvb-frontends/stb0899_drv.h  |   2 +-
 drivers/media/dvb-frontends/stb0899_priv.h |   2 +-
 drivers/media/dvb-frontends/stv0900_core.c |   2 +-
 drivers/media/dvb-frontends/stv0900_init.h |  34 +--
 drivers/media/dvb-frontends/stv0900_priv.h |   2 +-
 drivers/media/dvb-frontends/stv090x.c  |  12 +-
 drivers/media/dvb-frontends/stv090x_priv.h |   2 +-
 drivers/media/dvb-frontends/stv6110x.c |   2 +-
 drivers/media/dvb-frontends/stv6110x_priv.h|   6 +-
 drivers/media/dvb-frontends/tda10023.c |   2 +-
 drivers/media/dvb-frontends/tda18271c2dd.h |   4 +-
 drivers/media/firewire/firedtv-avc.c   |   4 +-
 

Re: [RFC/RFT PATCH 1/6] uvcvideo: Refactor URB descriptors

2018-01-04 Thread Guennadi Liakhovetski
Hi Kieran,

Just minor suggestions below:

On Wed, 3 Jan 2018, Kieran Bingham wrote:

> From: Kieran Bingham 
> 
> We currently store three separate arrays for each URB reference we hold.
> 
> Objectify the data needed to track URBs into a single uvc_urb structure,
> allowing better object management and tracking of the URB.
> 
> All accesses to the data pointers through stream, are converted to use a
> uvc_urb pointer for consistency.
> 
> Signed-off-by: Kieran Bingham 
> Reviewed-by: Laurent Pinchart 
> ---
>  drivers/media/usb/uvc/uvc_video.c | 46 
>  drivers/media/usb/uvc/uvcvideo.h  | 18 ++---
>  2 files changed, 44 insertions(+), 20 deletions(-)

[snip]

> diff --git a/drivers/media/usb/uvc/uvcvideo.h 
> b/drivers/media/usb/uvc/uvcvideo.h
> index 19e725e2bda5..4afa8ce13ea7 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -479,6 +479,20 @@ struct uvc_stats_stream {
>   unsigned int max_sof;   /* Maximum STC.SOF value */
>  };
>  
> +/**
> + * struct uvc_urb - URB context management structure
> + *
> + * @urb: described URB. Must be allocated with usb_alloc_urb()

Didn't you mean "describes?"

> + * @urb_buffer: memory storage for the URB
> + * @urb_dma: DMA coherent addressing for the urb_buffer

The whole struct describes URBs, so, I wouldn't repeat that in these two 
field names, I'd just call them "buffer" and "dma." OTOH, later you add 
more fields like "stream," which aren't per-URB, so, maybe you want to 
keep these prefixes.

Thanks
Guennadi

> + */
> +struct uvc_urb {
> + struct urb *urb;
> +
> + char *urb_buffer;
> + dma_addr_t urb_dma;
> +};
> +
>  struct uvc_streaming {
>   struct list_head list;
>   struct uvc_device *dev;
> @@ -521,9 +535,7 @@ struct uvc_streaming {
>   __u32 max_payload_size;
>   } bulk;
>  
> - struct urb *urb[UVC_URBS];
> - char *urb_buffer[UVC_URBS];
> - dma_addr_t urb_dma[UVC_URBS];
> + struct uvc_urb uvc_urb[UVC_URBS];
>   unsigned int urb_size;
>  
>   __u32 sequence;
> -- 
> git-series 0.9.1
> 


Re: [RFC/RFT PATCH 3/6] uvcvideo: Protect queue internals with helper

2018-01-04 Thread Guennadi Liakhovetski
Hi Kieran,

On Wed, 3 Jan 2018, Kieran Bingham wrote:

> From: Kieran Bingham 
> 
> The URB completion operation obtains the current buffer by reading
> directly into the queue internal interface.
> 
> Protect this queue abstraction by providing a helper
> uvc_queue_get_current_buffer() which can be used by both the decode
> task, and the uvc_queue_next_buffer() functions.
> 
> Signed-off-by: Kieran Bingham 
> Reviewed-by: Laurent Pinchart 
> ---
>  drivers/media/usb/uvc/uvc_queue.c | 34 +++-
>  drivers/media/usb/uvc/uvc_video.c |  7 +--
>  drivers/media/usb/uvc/uvcvideo.h  |  2 ++-
>  3 files changed, 32 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_queue.c 
> b/drivers/media/usb/uvc/uvc_queue.c
> index c8d78b2f3de4..0711e3d9ff76 100644
> --- a/drivers/media/usb/uvc/uvc_queue.c
> +++ b/drivers/media/usb/uvc/uvc_queue.c
> @@ -399,6 +399,34 @@ void uvc_queue_cancel(struct uvc_video_queue *queue, int 
> disconnect)
>   spin_unlock_irqrestore(>irqlock, flags);
>  }
>  
> +/*
> + * uvc_queue_get_current_buffer: Obtain the current working output buffer
> + *
> + * Buffers may span multiple packets, and even URBs, therefore the active 
> buffer
> + * remains on the queue until the EOF marker.
> + */
> +static struct uvc_buffer *
> +__uvc_queue_get_current_buffer(struct uvc_video_queue *queue)
> +{
> + if (!list_empty(>irqqueue))
> + return list_first_entry(>irqqueue, struct uvc_buffer,
> + queue);
> + else
> + return NULL;

I think the preferred style is not to use "else" in such cases. It might 
even be prettier to write

if (list_empty(...))
return NULL;

return list_first_entry(...);

Thanks
Guennadi


Re: [BUG] atomisp_ov2680 not initializing correctly

2018-01-04 Thread Andy Shevchenko
On Sat, 2017-12-30 at 20:57 +, Alan Cox wrote:
> On Tue, 19 Dec 2017 22:37:01 +0200
> Andy Shevchenko  wrote:
> > On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:

> > > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320
> > > > (Atom
> > > > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With
> > > > kernel
> > > > 4.14.4 and 4.15rc3 I see the following dmesg output:  
> > 
> > It seems I forgot to send the rest of the patches I did while ago
> > against AtomISP code.
> > 
> > It includes switch to normal DMI matching instead of the crap we
> > have
> > there right now.
> 
> The current code expects to be booted on an Android (or ex Android)
> tablet. In which case the various values are buried in the EFI as
> you'd
> expect.

Yes, the logic is left untouched, the code has been cleaned up and allow
to use more natural DMI matching table.

> > WRT to the messages below it seems we have no platform data for that
> > device. It needs to be added.
> 
> Or we need to learn how to parse the ACPI data - except that at least
> on
> some devices the ACPI data is at least half fictional so it's not
> clear
> what the Windows driver really does.

...if we have any specs inside how that ACPI table was being populated.


> > Version string: irci_stable_candrpv_0415_20150423_1753
> > SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6  shisp_2400b0_v21.bin
> 
> I'll send you a copy: (unfortunately for non Intel people I've not
> managed to get enough people to care about this to get permission to
> put
> the firmware in the public repository ... yet.)

I've tried firmware with a version that matches the driver, still same
result. I got only "statistics" IRQs (0x20 by value)

$ head -z -n1 shisp_2400b0_v21.bin
irci_stable_candrpv_0415_20150521_0458

$ sha1sum shisp_2400b0_v21.bin
358d7cd31b2e35b6f812c5bdfc0bc28cc23ce674 shisp_2400b0_v21.bin

-- 
Andy Shevchenko 
Intel Finland Oy


Re: IMX6 interlaced capture

2018-01-04 Thread Tim Harvey
On Tue, Jan 2, 2018 at 6:00 PM, Steve Longerbeam  wrote:
> Hi Tim,
>
> Happy New Year! And pardon the delay.
>
>
> On 12/28/2017 01:56 PM, Tim Harvey wrote:
>>
>> Steve/Hans,
>>
>> I'm trying to get interlaced capture working with the TDA1997x driver
>> I've been working on which is connected to an IMX6 CSI.
>>
>> The particular board I'm currently testing on is an IMX6Q which has
>> both a TDA19971 HDMI receiver as well as an ADV7180 analog video
>> decoder. The media-ctl topology for this board can be found at
>> http://dev.gateworks.com/docs/linux/media/imx6q-gw54xx-media.png.
>>
>> For adv7180 everything appears to be working as expected:
>> - media-ctl --get-v4l2 '"adv7180 2-0020":0' shows:
>> [fmt:UYVY8_2X8/720x480 field:interlaced colorspace:smpte170m]
>> - he following captures/streams from the adv7180 using the vdic to
>> de-interlace:
>> media-ctl --link "adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]
>> media-ctl --link "ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]
>> media-ctl --link "ipu2_csi1":1 -> "ipu2_vdic":0[1]
>> media-ctl --link "ipu2_vdic":2 -> "ipu2_ic_prp":0[1]
>> media-ctl --link "ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]
>> media-ctl --link "ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]
>> media-ctl --set-v4l2 'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]
>> media-ctl --set-v4l2 'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480
>> field:interlaced]
>> media-ctl --set-v4l2 'ipu2_csi1':1 [fmt:UYVY2X8/720x480 field:interlaced]
>> media-ctl --set-v4l2 'ipu2_vdic':2 [fmt:UYVY2X8/720x480 field:interlaced]
>> media-ctl --set-v4l2 'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:none]
>> media-ctl --set-v4l2 'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]
>> v4l2-ctl -d /dev/video3
>> --set-fmt-video=width=720,height=480,pixelformat=UYVY
>> # capture 1 frame
>> v4l2-ctl -d /dev/video1 --stream-mmap --stream-skip=1
>> --stream-to=/tmp/x.raw --stream-count=1
>> # stream jpeg/rtp
>> gst-launch-1.0 v4l2src device=/dev/video3 !
>>"video/x-raw,width=720,height=480,format=UYVY" !
>> jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=5000"
>>
>> For the tda1997x I'm trying to do something similar:
>> - media-ctl --get-v4l2 '"tda19971 2-0048":0' shows:
>> [fmt:UYVY8_1X16/1920x1080 field:alternate colorspace:srgb]
>>  still not sure V4L2_FIELD_ALTERNATE/SRGB returned from tda1997x
>> get_fmt is correct
>> - I setup the pipeline with:
>> media-ctl --link "tda19971 2-0048":0 -> "ipu1_csi0_mux":1[1]
>> media-ctl --link "ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]
>> media-ctl --link "ipu1_csi0":1 -> "ipu1_vdic":0[1]
>> media-ctl --link "ipu1_vdic":2 -> "ipu1_ic_prp":0[1]
>> media-ctl --link "ipu1_ic_prp":2 -> "ipu1_ic_prpvf":0[1]
>> media-ctl --link "ipu1_ic_prpvf":1 -> "ipu1_ic_prpvf capture":0[1]
>> media-ctl --set-v4l2 'tda19971 2-0048':0[fmt:UYVY8_1X16/1920x1080]
>> media-ctl --set-v4l2 'ipu1_csi0_mux':2[fmt:UYVY8_1X16/1920x1080
>> field:alternate]
>> media-ctl --set-v4l2 'ipu1_csi0':1[fmt:UYVY8_1X16/1920x1080
>> field:alternate]
>> media-ctl --set-v4l2 'ipu1_vdic':2[fmt:UYVY8_1X16/1920x1080
>> field:alternate]
>> media-ctl --set-v4l2 'ipu1_ic_prp':2[fmt:UYVY8_1X16/1920x1080 field:none]
>> media-ctl --set-v4l2 'ipu1_ic_prpvf':1[fmt:UYVY8_1X16/1920x1080
>> field:none]
>> v4l2-ctl -d /dev/video1
>> --set-fmt-video=width=1920,height=1080,pixelformat=UYVY
>> v4l2-ctl -d /dev/v4l-subdev1 --set-dv-bt-timings=query
>> v4l2-ctl -d /dev/video1 --stream-mmap --stream-skip=1
>> --stream-to=/tmp/x.raw --stream-count=1
>> ipu1_csi0: bayer/16-bit parallel buses must go to IDMAC pad
>> ipu1_ic_prpvf: pipeline start failed with -22
>> VIDIOC_STREAMON: failed: Invalid argument
>

Steve,

Thanks for the help.

>
> Right, according to the i.MX6 reference manual, if the CSI muxes
> are receiving from the parallel bus input with width >= 16 bits,
> that data can't be passed to the IC. It never really made much sense
> to me, and I can't remember if I ever tried it, maybe not, because
> I don't have such hardware.

hmmm... that's not good. I may have to dig into what's being done in
my 3.14 kernel with the Freescale capture driver where I can capture
1080p60 fine with my tda1997x driver there.

>
> Try this hack as an experiment: modify is_parallel_16bit_bus() in
> imx-media-csi.c to simply return false, and see if the above pipeline
> works.

I'm currently on 4.15-rc1 which doesn't have a
'is_parallel_16bit_bus()' but if I comment out the check we are
talking about in csi_link_validate as such:

--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -999,6 +999,7 @@ static int csi_link_validate(struct v4l2_subdev *sd,
is_csi2 = (sensor_ep->bus_type == V4L2_MBUS_CSI2);
incc = priv->cc[CSI_SINK_PAD];

+/*
if (priv->dest != IPU_CSI_DEST_IDMAC &&
(incc->bayer || (!is_csi2 &&
 sensor_ep->bus.parallel.bus_width >= 16))) {
@@ -1007,6 +1008,7 @@ static int csi_link_validate(struct v4l2_subdev *sd,
ret = 

Re: [BUG] atomisp_ov2680 not initializing correctly

2018-01-04 Thread Andy Shevchenko
On Sat, 2017-12-30 at 21:10 +, Alan Cox wrote:
> > AFAIR Alan has CHT hardware he is developing / testing on.
> 
> I have a loaned board from the company Vincent (who did the intial
> patches) works for. At the moment it's loading firmware, finding
> cameras
> doing power management but not transferring images.
> 
> Unfortunately because of the design of the driver and firmware at the
> moment we are reduced to analyzing all the structs by hand between
> multiple different driver releases, and playing games to try and find
> out
> why various things are not matching up (assuming the firmware we have
> will actually work with the Windows tablet in question in the first
> place).

Maybe we need start over, i.e. find a (presumable old) kernel with
driver _and_ corresponding firmware _and_ hardware it supports to start
with...

> It's nasty because there are complex structs shared between the
> firmware
> and the OS, and in at least one spot the supposedly 'pristine' CHT
> driver
> that was used for the merge we now know could never have worked
> because
> it mismatched its own firmware !

Argh!

> On BYT I can't currently do much as my latest Intel Android tablet has
> died and it's getting hard to find more because I guess the rest of
> those
> made have also died.

I have MRD7 with some BIOS on it I even don't know if there is any newer
still available inside.

-- 
Andy Shevchenko 
Intel Finland Oy


Re: [BUG] atomisp_ov2680 not initializing correctly

2018-01-04 Thread Andy Shevchenko
On Tue, 2018-01-02 at 18:31 +, Alan Cox wrote:
> > Patch 0003-atomisp_gmin_platform-tweak-to-drive-axp288.patch gives a
> > little confusion.
> > The PMIC driver should work via ACPI OpRegion macro (and should be
> > enabled in kernel configuration). That's how it supposed to work.
> > The patch seems redundant.
> 
> I am fairly sure it is meant to work that way - but it doesn't. At
> least
> not at the moment.

Hmm... At least I see writes to PMIC on my side through OpRegion driver.

(Assuming my ugly hack patches applied)

> > > I see your point, Still it feels, as if this could go somewhere.  
> > 
> > I hope so, though I didn't try CherryTrail and according to Alan
> > that
> > is what he had tried on.
> 
> It's what we are currently trying on. I can fire up the ISP and
> actually
> get interrupts from it, but not much more at this point.

Seems you are ahead of everyone who is trying AtomISP till now.

-- 
Andy Shevchenko 
Intel Finland Oy


Re: [PATCH v3 4/9] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

2018-01-04 Thread Simon Horman
On Thu, Jan 04, 2018 at 05:03:12PM +0100, Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Laurent Pinchart 

This looks good to me. Please ping me once the bindings, which I assume are
the only dependency, are Acked or accepted.


Business Possibility

2018-01-04 Thread Peter Deng
Hello there, My name is Peter Deng a South African citizen and a friend to Mrs 
Mugabe sister . I got your contact through Korean business online directory. I 
represent the interest of Mrs Mugabe who wishes to move a total amount of $19 
million  into a safe account owns by a trusted business man who is capable of 
accommodating such volume of funds with absolute trust & confidentiality.

We are willing to give 5-10 percent of the total money for this efforts . A non 
disclosure non circumvent agreement will be signed before the eventual transfer 
of funds. It is important for to know that the fund owner is going through a 
period of political turmoil and she is in a precarious position, so this 
transaction has to be highly secretive & very confidential.

Kindly respond back to me if this is what you can handle .

Regards,

Peter.


[PATCH v3 0/9] Renesas Capture Engine Unit (CEU) V4L2 driver

2018-01-04 Thread Jacopo Mondi
Hello everyone,
this is the third round for Renesas CEU unit.

Patch now based on v4.15-rc6, a base tag for testing is available at:
git://jmondi.org/linux tag:v4.15-rc6-ceu-v3-base for the interested ones.

Just closed review comments received from Laurent, Geert and Fabio on v2,
not a huge changelog in this iteration, compared to v1->v2 one.

Hopefully we're close to final version, I just would like to hear about
runtime_pm management, as I have noticed in Sakari's review of other patches
I may have been using runtime_pm a bit naively in this driver. Just want a
confirmation this is ok.

Tested on RZ with GR-Peach and ov7670 and SH4 with Migo-R platform with ov7725.

Thanks
   j

v2->v3:
- Improved DT bindings removing standard properties (pinctrl- ones and
  remote-endpoint) not specific to this driver and improved description of
  compatible strings
- Remove ov772x's xlkc_rate property and set clock rate in Migo-R board file
- Made 'xclk' clock private to ov772x driver in Migo-R board file
- Change 'rstb' GPIO active output level and changed ov772x and tw9910 drivers
  accordingly as suggested by Fabio
- Minor changes in CEU driver to address Laurent's comments
- Moved Migo-R setup patch to the end of the series to silence 0-day bot
- Renamed tw9910 clock to 'xti' as per video decoder manual
- Changed all SPDX identifiers to GPL-2.0 from previous GPL-2.0+

v1->v2:
 - DT
 -- Addressed Geert's comments and added clocks for CEU to mstp6 clock source
 -- Specified supported generic video iterfaces properties in dt-bindings and
simplified example

 - CEU driver
 -- Re-worked interrupt handler, interrupt management, reset(*) and capture
start operation
 -- Re-worked querycap/enum_input/enum_frameintervals to fix some
v4l2_compliance failures
 -- Removed soc_camera legacy operations g/s_mbus_format
 -- Update to new notifier implementation
 -- Fixed several comments from Hans, Laurent and Sakari

 - Migo-R
 -- Register clocks and gpios for sensor drivers in Migo-R setup
 -- Updated sensors (tw9910 and ov772x) drivers headers and drivers to close
remarks from Hans and Laurent:
 --- Removed platform callbacks and handle clocks and gpios from sensor drivers
 --- Remove g/s_mbus_config operations
Jacopo Mondi (9):
  dt-bindings: media: Add Renesas CEU bindings
  include: media: Add Renesas CEU driver interface
  v4l: platform: Add Renesas CEU driver
  ARM: dts: r7s72100: Add Capture Engine Unit (CEU)
  v4l: i2c: Copy ov772x soc_camera sensor driver
  media: i2c: ov772x: Remove soc_camera dependencies
  v4l: i2c: Copy tw9910 soc_camera sensor driver
  media: i2c: tw9910: Remove soc_camera dependencies
  arch: sh: migor: Use new renesas-ceu camera driver

 .../devicetree/bindings/media/renesas,ceu.txt  |   85 +
 arch/arm/boot/dts/r7s72100.dtsi|   15 +-
 arch/sh/boards/mach-migor/setup.c  |  225 ++-
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c |2 +-
 drivers/media/i2c/Kconfig  |   20 +
 drivers/media/i2c/Makefile |2 +
 drivers/media/i2c/ov772x.c | 1181 ++
 drivers/media/i2c/tw9910.c | 1039 
 drivers/media/platform/Kconfig |9 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/renesas-ceu.c   | 1649 
 include/media/drv-intf/renesas-ceu.h   |   26 +
 include/media/i2c/ov772x.h |6 +-
 include/media/i2c/tw9910.h |9 +
 14 files changed, 4138 insertions(+), 131 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
 create mode 100644 drivers/media/i2c/ov772x.c
 create mode 100644 drivers/media/i2c/tw9910.c
 create mode 100644 drivers/media/platform/renesas-ceu.c
 create mode 100644 include/media/drv-intf/renesas-ceu.h

--
2.7.4



[PATCH v3 2/9] include: media: Add Renesas CEU driver interface

2018-01-04 Thread Jacopo Mondi
Add renesas-ceu header file.

Do not remove the existing sh_mobile_ceu.h one as long as the original
driver does not go away.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
---
 include/media/drv-intf/renesas-ceu.h | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 include/media/drv-intf/renesas-ceu.h

diff --git a/include/media/drv-intf/renesas-ceu.h 
b/include/media/drv-intf/renesas-ceu.h
new file mode 100644
index 000..52841d1
--- /dev/null
+++ b/include/media/drv-intf/renesas-ceu.h
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * renesas-ceu.h - Renesas CEU driver interface
+ *
+ * Copyright 2017-2018 Jacopo Mondi 
+ */
+
+#ifndef __MEDIA_DRV_INTF_RENESAS_CEU_H__
+#define __MEDIA_DRV_INTF_RENESAS_CEU_H__
+
+#define CEU_MAX_SUBDEVS2
+
+struct ceu_async_subdev {
+   unsigned long flags;
+   unsigned char bus_width;
+   unsigned char bus_shift;
+   unsigned int i2c_adapter_id;
+   unsigned int i2c_address;
+};
+
+struct ceu_platform_data {
+   unsigned int num_subdevs;
+   struct ceu_async_subdev subdevs[CEU_MAX_SUBDEVS];
+};
+
+#endif /* ___MEDIA_DRV_INTF_RENESAS_CEU_H__ */
-- 
2.7.4



[PATCH v3 3/9] v4l: platform: Add Renesas CEU driver

2018-01-04 Thread Jacopo Mondi
Add driver for Renesas Capture Engine Unit (CEU).

The CEU interface supports capturing 'data' (YUV422) and 'images'
(NV[12|21|16|61]).

This driver aims to replace the soc_camera-based sh_mobile_ceu one.

Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
platform GR-Peach.

Tested with ov7725 camera sensor on SH4 platform Migo-R.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/platform/Kconfig   |9 +
 drivers/media/platform/Makefile  |1 +
 drivers/media/platform/renesas-ceu.c | 1649 ++
 3 files changed, 1659 insertions(+)
 create mode 100644 drivers/media/platform/renesas-ceu.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index fd0c998..fe7bd26 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
  To compile this driver as a module, choose M here: the module
  will be called stm32-dcmi.
 
+config VIDEO_RENESAS_CEU
+   tristate "Renesas Capture Engine Unit (CEU) driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_FWNODE
+   ---help---
+ This is a v4l2 driver for the Renesas CEU Interface
+
 source "drivers/media/platform/soc_camera/Kconfig"
 source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 003b0bb..6580a6b 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)+= sh_vou.o
 obj-$(CONFIG_SOC_CAMERA)   += soc_camera/
 
 obj-$(CONFIG_VIDEO_RCAR_DRIF)  += rcar_drif.o
+obj-$(CONFIG_VIDEO_RENESAS_CEU)+= renesas-ceu.o
 obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o
 obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
diff --git a/drivers/media/platform/renesas-ceu.c 
b/drivers/media/platform/renesas-ceu.c
new file mode 100644
index 000..a614859
--- /dev/null
+++ b/drivers/media/platform/renesas-ceu.c
@@ -0,0 +1,1649 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
+ * Copyright (C) 2017-2018 Jacopo Mondi 
+ *
+ * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
+ * Copyright (C) 2008 Magnus Damm
+ *
+ * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
+ * Copyright (C) 2006, Sascha Hauer, Pengutronix
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME"renesas-ceu"
+
+/* CEU registers offsets and masks. */
+#define CEU_CAPSR  0x00 /* Capture start register  */
+#define CEU_CAPCR  0x04 /* Capture control register*/
+#define CEU_CAMCR  0x08 /* Capture interface control register  */
+#define CEU_CAMOR  0x10 /* Capture interface offset register   */
+#define CEU_CAPWR  0x14 /* Capture interface width register*/
+#define CEU_CAIFR  0x18 /* Capture interface input format register */
+#define CEU_CRCNTR 0x28 /* CEU register control register   */
+#define CEU_CRCMPR 0x2c /* CEU register forcible control register  */
+#define CEU_CFLCR  0x30 /* Capture filter control register */
+#define CEU_CFSZR  0x34 /* Capture filter size clip register   */
+#define CEU_CDWDR  0x38 /* Capture destination width register  */
+#define CEU_CDAYR  0x3c /* Capture data address Y register */
+#define CEU_CDACR  0x40 /* Capture data address C register */
+#define CEU_CFWCR  0x5c /* Firewall operation control register */
+#define CEU_CDOCR  0x64 /* Capture data output control register*/
+#define CEU_CEIER  0x70 /* Capture event interrupt enable register */
+#define CEU_CETCR  0x74 /* Capture event flag clear register   */
+#define CEU_CSTSR  0x7c /* Capture status register */
+#define CEU_CSRTR  0x80 /* Capture software reset register */
+
+/* Data synchronous fetch mode. */
+#define CEU_CAMCR_JPEG BIT(4)
+
+/* Input components ordering: CEU_CAMCR.DTARY field. */
+#define CEU_CAMCR_DTARY_8_UYVY (0x00 << 8)
+#define CEU_CAMCR_DTARY_8_VYUY (0x01 << 8)
+#define CEU_CAMCR_DTARY_8_YUYV (0x02 << 8)
+#define CEU_CAMCR_DTARY_8_YVYU (0x03 << 8)
+/* TODO: input 

[PATCH v3 4/9] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

2018-01-04 Thread Jacopo Mondi
Add Capture Engine Unit (CEU) node to device tree.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r7s72100.dtsi | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index ab9645a..5fe62f9 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -135,9 +135,9 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", 
"renesas,cpg-mstp-clocks";
reg = <0xfcfe042c 4>;
-   clocks = <_clk>;
-   clock-indices = ;
-   clock-output-names = "rtc";
+   clocks = <_clk>, <_clk>;
+   clock-indices = ;
+   clock-output-names = "ceu", "rtc";
};
 
mstp7_clks: mstp7_clks@fcfe0430 {
@@ -667,4 +667,13 @@
power-domains = <_clocks>;
status = "disabled";
};
+
+   ceu: ceu@e821 {
+   reg = <0xe821 0x3000>;
+   compatible = "renesas,r7s72100-ceu";
+   interrupts = ;
+   clocks = <_clks R7S72100_CLK_CEU>;
+   power-domains = <_clocks>;
+   status = "disabled";
+   };
 };
-- 
2.7.4



[PATCH v3 5/9] v4l: i2c: Copy ov772x soc_camera sensor driver

2018-01-04 Thread Jacopo Mondi
Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.
No modification to KConfig and Makefile as soc_camera framework
dependencies need to be removed first in next commit.

Signed-off-by: Jacopo Mondi 
Acked-by: Laurent Pinchart 
---
 drivers/media/i2c/ov772x.c | 1124 
 1 file changed, 1124 insertions(+)
 create mode 100644 drivers/media/i2c/ov772x.c

diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
new file mode 100644
index 000..8063835
--- /dev/null
+++ b/drivers/media/i2c/ov772x.c
@@ -0,0 +1,1124 @@
+/*
+ * ov772x Camera Driver
+ *
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov7670 and soc_camera_platform driver,
+ *
+ * Copyright 2006-7 Jonathan Corbet 
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * register offset
+ */
+#define GAIN0x00 /* AGC - Gain control gain setting */
+#define BLUE0x01 /* AWB - Blue channel gain setting */
+#define RED 0x02 /* AWB - Red   channel gain setting */
+#define GREEN   0x03 /* AWB - Green channel gain setting */
+#define COM10x04 /* Common control 1 */
+#define BAVG0x05 /* U/B Average Level */
+#define GAVG0x06 /* Y/Gb Average Level */
+#define RAVG0x07 /* V/R Average Level */
+#define AECH0x08 /* Exposure Value - AEC MSBs */
+#define COM20x09 /* Common control 2 */
+#define PID 0x0A /* Product ID Number MSB */
+#define VER 0x0B /* Product ID Number LSB */
+#define COM30x0C /* Common control 3 */
+#define COM40x0D /* Common control 4 */
+#define COM50x0E /* Common control 5 */
+#define COM60x0F /* Common control 6 */
+#define AEC 0x10 /* Exposure Value */
+#define CLKRC   0x11 /* Internal clock */
+#define COM70x12 /* Common control 7 */
+#define COM80x13 /* Common control 8 */
+#define COM90x14 /* Common control 9 */
+#define COM10   0x15 /* Common control 10 */
+#define REG16   0x16 /* Register 16 */
+#define HSTART  0x17 /* Horizontal sensor size */
+#define HSIZE   0x18 /* Horizontal frame (HREF column) end high 8-bit */
+#define VSTART  0x19 /* Vertical frame (row) start high 8-bit */
+#define VSIZE   0x1A /* Vertical sensor size */
+#define PSHFT   0x1B /* Data format - pixel delay select */
+#define MIDH0x1C /* Manufacturer ID byte - high */
+#define MIDL0x1D /* Manufacturer ID byte - low  */
+#define LAEC0x1F /* Fine AEC value */
+#define COM11   0x20 /* Common control 11 */
+#define BDBASE  0x22 /* Banding filter Minimum AEC value */
+#define DBSTEP  0x23 /* Banding filter Maximum Setp */
+#define AEW 0x24 /* AGC/AEC - Stable operating region (upper limit) */
+#define AEB 0x25 /* AGC/AEC - Stable operating region (lower limit) */
+#define VPT 0x26 /* AGC/AEC Fast mode operating region */
+#define REG28   0x28 /* Register 28 */
+#define HOUTSIZE0x29 /* Horizontal data output size MSBs */
+#define EXHCH   0x2A /* Dummy pixel insert MSB */
+#define EXHCL   0x2B /* Dummy pixel insert LSB */
+#define VOUTSIZE0x2C /* Vertical data output size MSBs */
+#define ADVFL   0x2D /* LSB of insert dummy lines in Vertical direction */
+#define ADVFH   0x2E /* MSG of insert dummy lines in Vertical direction */
+#define YAVE0x2F /* Y/G Channel Average value */
+#define LUMHTH  0x30 /* Histogram AEC/AGC Luminance high level threshold */
+#define LUMLTH  0x31 /* Histogram AEC/AGC Luminance low  level threshold */
+#define HREF0x32 /* Image start and size control */
+#define DM_LNL  0x33 /* Dummy line low  8 bits */
+#define DM_LNH  0x34 /* Dummy line high 8 bits */
+#define ADOFF_B 0x35 /* AD offset compensation value for B  channel */
+#define ADOFF_R 0x36 /* AD offset compensation value for R  channel */
+#define ADOFF_GB0x37 /* AD offset compensation value for Gb channel */
+#define ADOFF_GR0x38 /* AD offset compensation value for Gr channel */
+#define OFF_B   0x39 /* Analog process B  channel offset value */
+#define OFF_R   0x3A /* Analog process R  channel offset value */
+#define OFF_GB  0x3B /* Analog process Gb channel offset value */
+#define OFF_GR  0x3C /* Analog process Gr channel offset value */
+#define COM12   0x3D 

[PATCH v3 6/9] media: i2c: ov772x: Remove soc_camera dependencies

2018-01-04 Thread Jacopo Mondi
Remove soc_camera framework dependencies from ov772x sensor driver.
- Handle clock and gpios
- Register async subdevice
- Remove soc_camera specific g/s_mbus_config operations
- Change image format colorspace from JPEG to SRGB as the two use the
  same colorspace information but JPEG makes assumptions on color
  components quantization that do not apply to the sensor
- Remove sizes crop from get_selection as driver can't scale
- Add kernel doc to driver interface header file
- Adjust build system

This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera-based CEU driver.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/Kconfig  |  11 +++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/ov772x.c | 177 ++---
 include/media/i2c/ov772x.h |   6 +-
 4 files changed, 133 insertions(+), 62 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff..a61d7f4 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -645,6 +645,17 @@ config VIDEO_OV5670
  To compile this driver as a module, choose M here: the
  module will be called ov5670.

+config VIDEO_OV772X
+   tristate "OmniVision OV772x sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV772x camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov772x.
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..fb99293 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
+obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 8063835..df2516c 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * ov772x Camera Driver
  *
+ * Copyright (C) 2017 Jacopo Mondi 
+ *
  * Copyright (C) 2008 Renesas Solutions Corp.
  * Kuninori Morimoto 
  *
@@ -9,27 +12,25 @@
  * Copyright 2006-7 Jonathan Corbet 
  * Copyright (C) 2008 Magnus Damm
  * Copyright (C) 2008, Guennadi Liakhovetski 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */

+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 

 #include 
-#include 
-#include 
+
 #include 
-#include 
+#include 
 #include 
+#include 

 /*
  * register offset
@@ -393,8 +394,10 @@ struct ov772x_win_size {
 struct ov772x_priv {
struct v4l2_subdevsubdev;
struct v4l2_ctrl_handler  hdl;
-   struct v4l2_clk  *clk;
+   struct clk   *clk;
struct ov772x_camera_info*info;
+   struct gpio_desc *pwdn_gpio;
+   struct gpio_desc *rstb_gpio;
const struct ov772x_color_format *cfmt;
const struct ov772x_win_size *win;
unsigned shortflag_vflip:1;
@@ -409,7 +412,7 @@ struct ov772x_priv {
 static const struct ov772x_color_format ov772x_cfmts[] = {
{
.code   = MEDIA_BUS_FMT_YUYV8_2X8,
-   .colorspace = V4L2_COLORSPACE_JPEG,
+   .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3   = 0x0,
.dsp4   = DSP_OFMT_YUV,
.com3   = SWAP_YUV,
@@ -417,7 +420,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
},
{
.code   = MEDIA_BUS_FMT_YVYU8_2X8,
-   .colorspace = V4L2_COLORSPACE_JPEG,
+   .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3   = UV_ON,
.dsp4   = DSP_OFMT_YUV,
.com3   = SWAP_YUV,
@@ -425,7 +428,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
},
{
.code   = MEDIA_BUS_FMT_UYVY8_2X8,
-   .colorspace = V4L2_COLORSPACE_JPEG,
+   .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3   = 0x0,
.dsp4 

[PATCH v3 8/9] media: i2c: tw9910: Remove soc_camera dependencies

2018-01-04 Thread Jacopo Mondi
Remove soc_camera framework dependencies from tw9910 sensor driver.
- Handle clock and gpios
- Register async subdevice
- Remove soc_camera specific g/s_mbus_config operations
- Add kernel doc to driver interface header file
- Adjust build system

This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera-based CEU driver.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/i2c/Kconfig  |   9 +++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/tw9910.c | 162 -
 include/media/i2c/tw9910.h |   9 +++
 4 files changed, 120 insertions(+), 61 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index a61d7f4..804a1bf 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -423,6 +423,15 @@ config VIDEO_TW9906
  To compile this driver as a module, choose M here: the
  module will be called tw9906.
 
+config VIDEO_TW9910
+   tristate "Techwell TW9910 video decoder"
+   depends on VIDEO_V4L2 && I2C
+   ---help---
+ Support for Techwell TW9910 NTSC/PAL/SECAM video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9910.
+
 config VIDEO_VPX3220
tristate "vpx3220a, vpx3216b & vpx3214c video decoders"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index fb99293..e26544f 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
 obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
 obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
 obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
+obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
 obj-$(CONFIG_VIDEO_CS3308) += cs3308.o
 obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
 obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
index bdb5e0a..96792df 100644
--- a/drivers/media/i2c/tw9910.c
+++ b/drivers/media/i2c/tw9910.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * tw9910 Video Driver
  *
+ * Copyright (C) 2017 Jacopo Mondi 
+ *
  * Copyright (C) 2008 Renesas Solutions Corp.
  * Kuninori Morimoto 
  *
@@ -10,12 +13,10 @@
  * Copyright 2006-7 Jonathan Corbet 
  * Copyright (C) 2008 Magnus Damm
  * Copyright (C) 2008, Guennadi Liakhovetski 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -25,9 +26,7 @@
 #include 
 #include 
 
-#include 
 #include 
-#include 
 #include 
 
 #define GET_ID(val)  ((val & 0xF8) >> 3)
@@ -228,8 +227,10 @@ struct tw9910_scale_ctrl {
 
 struct tw9910_priv {
struct v4l2_subdev  subdev;
-   struct v4l2_clk *clk;
+   struct clk  *clk;
struct tw9910_video_info*info;
+   struct gpio_desc*pdn_gpio;
+   struct gpio_desc*rstb_gpio;
const struct tw9910_scale_ctrl  *scale;
v4l2_std_id norm;
u32 revision;
@@ -582,13 +583,66 @@ static int tw9910_s_register(struct v4l2_subdev *sd,
 }
 #endif
 
+static int tw9910_power_on(struct tw9910_priv *priv)
+{
+   struct i2c_client *client = v4l2_get_subdevdata(>subdev);
+   int ret;
+
+   if (priv->clk) {
+   ret = clk_prepare_enable(priv->clk);
+   if (ret)
+   return ret;
+   }
+
+   if (priv->pdn_gpio) {
+   gpiod_set_value(priv->pdn_gpio, 0);
+   usleep_range(500, 1000);
+   }
+
+   /*
+* FIXME: The reset signal is connected to a shared GPIO on some
+* platforms (namely the SuperH Migo-R). Until a framework becomes
+* available to handle this cleanly, request the GPIO temporarily
+* to avoid conflicts.
+*/
+   priv->rstb_gpio = gpiod_get_optional(>dev, "rstb",
+GPIOD_OUT_LOW);
+   if (IS_ERR(priv->rstb_gpio)) {
+   dev_info(>dev, "Unable to get GPIO \"rstb\"");
+   return PTR_ERR(priv->rstb_gpio);
+   }
+
+   if (priv->rstb_gpio) {
+   gpiod_set_value(priv->rstb_gpio, 1);
+   usleep_range(500, 1000);
+   gpiod_set_value(priv->rstb_gpio, 0);
+   usleep_range(500, 1000);
+
+   gpiod_put(priv->rstb_gpio);
+   }
+
+   return 0;
+}
+
+static int tw9910_power_off(struct tw9910_priv *priv)
+{
+   clk_disable_unprepare(priv->clk);
+
+   if (priv->pdn_gpio) {
+ 

[PATCH v3 7/9] v4l: i2c: Copy tw9910 soc_camera sensor driver

2018-01-04 Thread Jacopo Mondi
Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.
No modification to KConfig and Makefile as soc_camera framework
dependencies need to be removed first in next commit.

Signed-off-by: Jacopo Mondi 
Acked-by: Laurent Pinchart 
---
 drivers/media/i2c/tw9910.c | 999 +
 1 file changed, 999 insertions(+)
 create mode 100644 drivers/media/i2c/tw9910.c

diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
new file mode 100644
index 000..bdb5e0a
--- /dev/null
+++ b/drivers/media/i2c/tw9910.c
@@ -0,0 +1,999 @@
+/*
+ * tw9910 Video Driver
+ *
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov772x driver,
+ *
+ * Copyright (C) 2008 Kuninori Morimoto 
+ * Copyright 2006-7 Jonathan Corbet 
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define GET_ID(val)  ((val & 0xF8) >> 3)
+#define GET_REV(val) (val & 0x07)
+
+/*
+ * register offset
+ */
+#define ID 0x00 /* Product ID Code Register */
+#define STATUS10x01 /* Chip Status Register I */
+#define INFORM 0x02 /* Input Format */
+#define OPFORM 0x03 /* Output Format Control Register */
+#define DLYCTR 0x04 /* Hysteresis and HSYNC Delay Control */
+#define OUTCTR10x05 /* Output Control I */
+#define ACNTL1 0x06 /* Analog Control Register 1 */
+#define CROP_HI0x07 /* Cropping Register, High */
+#define VDELAY_LO  0x08 /* Vertical Delay Register, Low */
+#define VACTIVE_LO 0x09 /* Vertical Active Register, Low */
+#define HDELAY_LO  0x0A /* Horizontal Delay Register, Low */
+#define HACTIVE_LO 0x0B /* Horizontal Active Register, Low */
+#define CNTRL1 0x0C /* Control Register I */
+#define VSCALE_LO  0x0D /* Vertical Scaling Register, Low */
+#define SCALE_HI   0x0E /* Scaling Register, High */
+#define HSCALE_LO  0x0F /* Horizontal Scaling Register, Low */
+#define BRIGHT 0x10 /* BRIGHTNESS Control Register */
+#define CONTRAST   0x11 /* CONTRAST Control Register */
+#define SHARPNESS  0x12 /* SHARPNESS Control Register I */
+#define SAT_U  0x13 /* Chroma (U) Gain Register */
+#define SAT_V  0x14 /* Chroma (V) Gain Register */
+#define HUE0x15 /* Hue Control Register */
+#define CORING10x17
+#define CORING20x18 /* Coring and IF compensation */
+#define VBICNTL0x19 /* VBI Control Register */
+#define ACNTL2 0x1A /* Analog Control 2 */
+#define OUTCTR20x1B /* Output Control 2 */
+#define SDT0x1C /* Standard Selection */
+#define SDTR   0x1D /* Standard Recognition */
+#define TEST   0x1F /* Test Control Register */
+#define CLMPG  0x20 /* Clamping Gain */
+#define IAGC   0x21 /* Individual AGC Gain */
+#define AGCGAIN0x22 /* AGC Gain */
+#define PEAKWT 0x23 /* White Peak Threshold */
+#define CLMPL  0x24 /* Clamp level */
+#define SYNCT  0x25 /* Sync Amplitude */
+#define MISSCNT0x26 /* Sync Miss Count Register */
+#define PCLAMP 0x27 /* Clamp Position Register */
+#define VCNTL1 0x28 /* Vertical Control I */
+#define VCNTL2 0x29 /* Vertical Control II */
+#define CKILL  0x2A /* Color Killer Level Control */
+#define COMB   0x2B /* Comb Filter Control */
+#define LDLY   0x2C /* Luma Delay and H Filter Control */
+#define MISC1  0x2D /* Miscellaneous Control I */
+#define LOOP   0x2E /* LOOP Control Register */
+#define MISC2  0x2F /* Miscellaneous Control II */
+#define MVSN   0x30 /* Macrovision Detection */
+#define STATUS20x31 /* Chip STATUS II */
+#define HFREF  0x32 /* H monitor */
+#define CLMD   0x33 /* CLAMP MODE */
+#define IDCNTL 0x34 /* ID Detection Control */
+#define CLCNTL10x35 /* Clamp Control I */
+#define ANAPLLCTL  0x4C
+#define VBIMIN 0x4D
+#define HSLOWCTL   0x4E
+#define WSS3   0x4F
+#define FILLDATA   0x50
+#define SDID   0x51
+#define DID0x52
+#define WSS1   0x53
+#define WSS2   0x54
+#define VVBI   0x55
+#define LCTL6  0x56
+#define LCTL7  0x57
+#define LCTL8  0x58
+#define LCTL9   

[PATCH v3 9/9] arch: sh: migor: Use new renesas-ceu camera driver

2018-01-04 Thread Jacopo Mondi
Migo-R platform uses sh_mobile_ceu camera driver, which is now being
replaced by a proper V4L2 camera driver named 'renesas-ceu'.

Move Migo-R platform to use the v4l2 renesas-ceu camera driver
interface and get rid of soc_camera defined components used to register
sensor drivers and of platform specific enable/disable routines.

Register clock source and GPIOs for sensor drivers, so they can use
clock and gpio APIs.

Also, memory for CEU video buffers is now reserved with membocks APIs,
and need to be declared as dma_coherent during machine initialization to
remove that architecture specific part from CEU driver.

Signed-off-by: Jacopo Mondi 
---
 arch/sh/boards/mach-migor/setup.c  | 225 +++--
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c |   2 +-
 2 files changed, 101 insertions(+), 126 deletions(-)

diff --git a/arch/sh/boards/mach-migor/setup.c 
b/arch/sh/boards/mach-migor/setup.c
index 0bcbe58..2dd9fb9 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -1,17 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Renesas System Solutions Asia Pte. Ltd - Migo-R
  *
  * Copyright (C) 2008 Magnus Damm
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,10 +22,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -45,6 +45,9 @@
  * 0x1800   8GB8   NAND Flash (K9K8G08U0A)
  */

+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu_dma_membase;
+
 static struct smc91x_platdata smc91x_info = {
.flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
 };
@@ -301,65 +304,24 @@ static struct platform_device migor_lcdc_device = {
},
 };

-static struct clk *camera_clk;
-static DEFINE_MUTEX(camera_lock);
-
-static void camera_power_on(int is_tw)
-{
-   mutex_lock(_lock);
-
-   /* Use 10 MHz VIO_CKO instead of 24 MHz to work
-* around signal quality issues on Panel Board V2.1.
-*/
-   camera_clk = clk_get(NULL, "video_clk");
-   clk_set_rate(camera_clk, 1000);
-   clk_enable(camera_clk); /* start VIO_CKO */
-
-   /* use VIO_RST to take camera out of reset */
-   mdelay(10);
-   if (is_tw) {
-   gpio_set_value(GPIO_PTT2, 0);
-   gpio_set_value(GPIO_PTT0, 0);
-   } else {
-   gpio_set_value(GPIO_PTT0, 1);
-   }
-   gpio_set_value(GPIO_PTT3, 0);
-   mdelay(10);
-   gpio_set_value(GPIO_PTT3, 1);
-   mdelay(10); /* wait to let chip come out of reset */
-}
-
-static void camera_power_off(void)
-{
-   clk_disable(camera_clk); /* stop VIO_CKO */
-   clk_put(camera_clk);
-
-   gpio_set_value(GPIO_PTT3, 0);
-   mutex_unlock(_lock);
-}
-
-static int ov7725_power(struct device *dev, int mode)
-{
-   if (mode)
-   camera_power_on(0);
-   else
-   camera_power_off();
-
-   return 0;
-}
-
-static int tw9910_power(struct device *dev, int mode)
-{
-   if (mode)
-   camera_power_on(1);
-   else
-   camera_power_off();
-
-   return 0;
-}
-
-static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
-   .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static const struct ceu_platform_data ceu_pdata = {
+   .num_subdevs= 2,
+   .subdevs = {
+   { /* [0] = ov772x */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x21,
+   },
+   { /* [1] = tw9910 */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x45,
+   },
+   },
 };

 static struct resource migor_ceu_resources[] = {
@@ -373,18 +335,32 @@ static struct resource migor_ceu_resources[] = {
.start  = evt2irq(0x880),
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   /* place holder for contiguous memory */
-   },
 };

 static struct platform_device migor_ceu_device = {
-   .name   = "sh_mobile_ceu",
-   .id = 0, /* "ceu0" clock */
+   .name   = "renesas-ceu",
+   .id = 0, /* ceu.0 */
.num_resources  = ARRAY_SIZE(migor_ceu_resources),
.resource   = migor_ceu_resources,
.dev= {
-   .platform_data  = _mobile_ceu_info,
+   .platform_data  = _pdata,
+   },
+};
+
+/* 

[PATCH v3 1/9] dt-bindings: media: Add Renesas CEU bindings

2018-01-04 Thread Jacopo Mondi
Add bindings documentation for Renesas Capture Engine Unit (CEU).

Signed-off-by: Jacopo Mondi 
---
 .../devicetree/bindings/media/renesas,ceu.txt  | 85 ++
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt

diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
b/Documentation/devicetree/bindings/media/renesas,ceu.txt
new file mode 100644
index 000..a4f3c05
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
@@ -0,0 +1,85 @@
+Renesas Capture Engine Unit (CEU)
+--
+
+The Capture Engine Unit is the image capture interface found in the Renesas
+SH Mobile and RZ SoCs.
+
+The interface supports a single parallel input with data bus width of 8 or 16
+bits.
+
+Required properties:
+- compatible: Must be one of the following.
+   - "renesas,r7s72100-ceu" for CEU units found in R7S72100 (RZ/A1) SoCs.
+   - "renesas,ceu" as a generic fallback.
+
+   SH Mobile CPUs do not currently support OF, and they configure their
+   CEU interfaces using platform data. The "compatible" list will be
+   expanded once SH Mobile will be made OF-capable.
+
+- reg: Registers address base and size.
+- interrupts: The interrupt specifier.
+
+The CEU supports a single parallel input and should contain a single 'port'
+subnode with a single 'endpoint'. Connection to input devices are modeled
+according to the video interfaces OF bindings specified in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Optional endpoint properties applicable to parallel input bus described in
+the above mentioned "video-interfaces.txt" file are supported by this driver:
+
+- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH 
respectively.
+- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH 
respectively.
+
+Example:
+
+The example describes the connection between the Capture Engine Unit and an
+OV7670 image sensor connected to i2c1 interface.
+
+ceu: ceu@e821 {
+   reg = <0xe821 0x209c>;
+   compatible = "renesas,ceu";
+   interrupts = ;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+
+   port {
+   ceu_in: endpoint {
+   remote-endpoint = <_out>;
+
+   hsync-active = <1>;
+   vsync-active = <0>;
+   };
+   };
+};
+
+i2c1: i2c@fcfee400 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+
+   clock-frequency = <10>;
+
+   ov7670: camera@21 {
+   compatible = "ovti,ov7670";
+   reg = <0x21>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   reset-gpios = < 11 GPIO_ACTIVE_LOW>;
+   powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
+
+   port {
+   ov7670_out: endpoint {
+   remote-endpoint = <_in>;
+
+   hsync-active = <1>;
+   vsync-active = <0>;
+   };
+   };
+   };
+};
--
2.7.4



[PATCH] media: coda: bump maximum number of internal framebuffers to 19

2018-01-04 Thread Philipp Zabel
While the h.264 standard only allows up to 16 reference frames, the CODA
firmware needs two more buffers: one to hold the currently decoded frame
and one for the display frame. Adding the framebuffer needed by the
driver for VDOA operation brings the total to a maximum of 19 internal
framebuffers.
Lift the current maximum of 17 internal framebuffers to allow playback
of high profile streams that require more than 14 reference frames.

Signed-off-by: Philipp Zabel 
---
 drivers/media/platform/coda/coda.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda.h 
b/drivers/media/platform/coda/coda.h
index c5f504d8cf67f..ea8a4e23540d0 100644
--- a/drivers/media/platform/coda/coda.h
+++ b/drivers/media/platform/coda/coda.h
@@ -28,7 +28,7 @@
 
 #include "coda_regs.h"
 
-#define CODA_MAX_FRAMEBUFFERS  17
+#define CODA_MAX_FRAMEBUFFERS  19
 #define FMO_SLICE_SAVE_BUF_SIZE(32)
 
 enum {
-- 
2.11.0



Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support

2018-01-04 Thread Ondřej Jirman
On Thu, Jan 04, 2018 at 03:06:25PM +0100, Maxime Ripard wrote:
> On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ondřej Jirman wrote:
> > Hello,
> > 
> > On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > > Hi,
> > > 
> > > On Fri, 22 Dec 2017 14:46:48 +0100
> > > Ondřej Jirman  wrote:
> > > 
> > > > Hello,
> > > > 
> > > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > > > 
> > > > > Test input 0:
> > > > > 
> > > > > Control ioctls:
> > > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not 
> > > > > Supported)
> > > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not 
> > > > > Supported)
> > > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > > Standard Controls: 0 Private Controls: 0
> > > > 
> > > > I'm not sure if your driver passes control queries to the subdev. It
> > > > did not originally, and I'm not sure you picked up the change from my
> > > > version of the driver. "Not supported" here seems to indicate that it
> > > > does not.
> > > > 
> > > > I'd be interested what's the recommended practice here. It sure helps
> > > > with some apps that expect to be able to modify various input controls
> > > > directly on the /dev/video# device. These are then supported out of the
> > > > box.
> > > > 
> > > > It's a one-line change. See:
> > > > 
> > > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > > heriting-controls
> > > 
> > > I think this is a feature and not affect the driver's main function.
> > > I just focused on making the CSI main function to work properly in 
> > > the initial version. Is this feature mandatory or most commonly used?
> > 
> > I grepped the platform/ code and it seems, that inheriting controls
> > from subdevs is pretty common for input drivers. (there are varying
> > approaches though, some inherit by hand in the link function, some
> > just register and empty ctrl_handler on the v4l2_dev and leave the
> > rest to the core).
> > 
> > Practically, I haven't found a common app that would allow me to enter
> > both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> > themselves, but it would be better if current controls were available
> > at the /dev/video0 device automatically.
> > 
> > It's much simpler for the userspace apps than the alternative, which
> > is trying to identify the correct subdev that is currently
> > associated with the CSI driver at runtime, which is not exactly
> > straightforward and requires much more code, than a few lines in
> > the kernel, that are required to inherit controls:
> 
> And it becomes much more complicated once you have the same controls
> on the v4l2 device and subdevice, which is not that uncommon.

Hi Maxime,

I don't think you understand the issue. In your hypothetical situation, if the
CSI device will have any controls in the future, the merging of controls from
subdev will be done automatically anyway, it's not some optional feature.

Also userspace will not get any more complicated than without my proposed change
to the driver. It will be at most the same as without the change if any subdev
controls are masked by the CSI device controls.

This CSI driver has no controls anyway. All my change does is create an empty
handler for future controls of the CSI driver, so that apps can depend on this
merging behavior right now, and not wait until someone adds the first control
to the CSI driver.

regards,
  o.j.

> 
> Maxime
> 
> 
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com




Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support

2018-01-04 Thread Maxime Ripard
On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ondřej Jirman wrote:
> Hello,
> 
> On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > Hi,
> > 
> > On Fri, 22 Dec 2017 14:46:48 +0100
> > Ondřej Jirman  wrote:
> > 
> > > Hello,
> > > 
> > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > > 
> > > > Test input 0:
> > > > 
> > > > Control ioctls:
> > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not 
> > > > Supported)
> > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > Standard Controls: 0 Private Controls: 0
> > > 
> > > I'm not sure if your driver passes control queries to the subdev. It
> > > did not originally, and I'm not sure you picked up the change from my
> > > version of the driver. "Not supported" here seems to indicate that it
> > > does not.
> > > 
> > > I'd be interested what's the recommended practice here. It sure helps
> > > with some apps that expect to be able to modify various input controls
> > > directly on the /dev/video# device. These are then supported out of the
> > > box.
> > > 
> > > It's a one-line change. See:
> > > 
> > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > heriting-controls
> > 
> > I think this is a feature and not affect the driver's main function.
> > I just focused on making the CSI main function to work properly in 
> > the initial version. Is this feature mandatory or most commonly used?
> 
> I grepped the platform/ code and it seems, that inheriting controls
> from subdevs is pretty common for input drivers. (there are varying
> approaches though, some inherit by hand in the link function, some
> just register and empty ctrl_handler on the v4l2_dev and leave the
> rest to the core).
> 
> Practically, I haven't found a common app that would allow me to enter
> both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> themselves, but it would be better if current controls were available
> at the /dev/video0 device automatically.
> 
> It's much simpler for the userspace apps than the alternative, which
> is trying to identify the correct subdev that is currently
> associated with the CSI driver at runtime, which is not exactly
> straightforward and requires much more code, than a few lines in
> the kernel, that are required to inherit controls:

And it becomes much more complicated once you have the same controls
on the v4l2 device and subdevice, which is not that uncommon.

Maxime



-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature


Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support

2018-01-04 Thread Maxime Ripard
On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> Hi,
> 
> On Fri, 22 Dec 2017 14:46:48 +0100
> Ondřej Jirman  wrote:
> 
> > Hello,
> > 
> > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > This patchset add initial support for Allwinner V3s CSI.
> > > 
> > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > and CSI1 is used for parallel interface. This is not documented in
> > > datasheet but by testing and guess.
> > > 
> > > This patchset implement a v4l2 framework driver and add a binding 
> > > documentation for it. 
> > > 
> > > Currently, the driver only support the parallel interface. And has been
> > > tested with a BT1120 signal which generating from FPGA. The following
> > > fetures are not support with this patchset:
> > >   - ISP 
> > >   - MIPI-CSI2
> > >   - Master clock for camera sensor
> > >   - Power regulator for the front end IC
> > > 
> > > Thanks for Ondřej Jirman's help.
> > > 
> > > Changes in v4:
> > >   * Deal with the CSI 'INNER QUEUE'.
> > > CSI will lookup the next dma buffer for next frame before the
> > > the current frame done IRQ triggered. This is not documented
> > > but reported by Ondřej Jirman.
> > > The BSP code has workaround for this too. It skip to mark the
> > > first buffer as frame done for VB2 and pass the second buffer
> > > to CSI in the first frame done ISR call. Then in second frame
> > > done ISR call, it mark the first buffer as frame done for VB2
> > > and pass the third buffer to CSI. And so on. The bad thing is
> > > that the first buffer will be written twice and the first frame
> > > is dropped even the queued buffer is sufficient.
> > > So, I make some improvement here. Pass the next buffer to CSI
> > > just follow starting the CSI. In this case, the first frame
> > > will be stored in first buffer, second frame in second buffer.
> > > This mothed is used to avoid dropping the first frame, it
> > > would also drop frame when lacking of queued buffer.
> > >   * Fix: using a wrong mbus_code when getting the supported formats
> > >   * Change all fourcc to pixformat
> > >   * Change some function names
> > > 
> > > Changes in v3:
> > >   * Get rid of struct sun6i_csi_ops
> > >   * Move sun6i-csi to new directory drivers/media/platform/sunxi
> > >   * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
> > >   * Use generic fwnode endpoints parser
> > >   * Only support a single subdev to make things simple
> > >   * Many complaintion fix
> > > 
> > > Changes in v2: 
> > >   * Change sunxi-csi to sun6i-csi
> > >   * Rebase to media_tree master branch 
> > > 
> > > Following is the 'v4l2-compliance -s -f' output, I have test this
> > > with both interlaced and progressive signal:
> > > 
> > > # ./v4l2-compliance -s -f
> > > v4l2-compliance SHA   : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
> > > 
> > > Driver Info:
> > > Driver name   : sun6i-video
> > > Card type : sun6i-csi
> > > Bus info  : platform:csi
> > > Driver version: 4.15.0
> > > Capabilities  : 0x8421
> > > Video Capture
> > > Streaming
> > > Extended Pix Format
> > > Device Capabilities
> > > Device Caps   : 0x0421
> > > Video Capture
> > > Streaming
> > > Extended Pix Format
> > > 
> > > Compliance test for device /dev/video0 (not using libv4l2):
> > > 
> > > Required ioctls:
> > > test VIDIOC_QUERYCAP: OK
> > > 
> > > Allow for multiple opens:
> > > test second video open: OK
> > > test VIDIOC_QUERYCAP: OK
> > > test VIDIOC_G/S_PRIORITY: OK
> > > test for unlimited opens: OK
> > > 
> > > Debug ioctls:
> > > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> > > test VIDIOC_LOG_STATUS: OK (Not Supported)
> > > 
> > > Input ioctls:
> > > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> > > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> > > test VIDIOC_ENUMAUDIO: OK (Not Supported)
> > > test VIDIOC_G/S/ENUMINPUT: OK
> > > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > > Inputs: 1 Audio Inputs: 0 Tuners: 0
> > > 
> > > Output ioctls:
> > > test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> > > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > > test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> > > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> > > test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> > > Outputs: 0 Audio Outputs: 0 Modulators: 0
> > > 
> > > Input/Output configuration ioctls:
> > > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> > > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> > > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> > >  

[PATCH] [v2] media: au0828: fix VIDEO_V4L2 dependency

2018-01-04 Thread Arnd Bergmann
After the move of videobuf2 into the common directory, selecting the
au0828 driver with CONFIG_V4L2 disabled started causing a link failure,
as we now attempt to build videobuf2 but it still requires v4l2:

ERROR: "v4l2_event_pending" [drivers/media/common/videobuf/videobuf2-v4l2.ko] 
undefined!
ERROR: "v4l2_fh_release" [drivers/media/common/videobuf/videobuf2-v4l2.ko] 
undefined!
ERROR: "video_devdata" [drivers/media/common/videobuf/videobuf2-v4l2.ko] 
undefined!
ERROR: "__tracepoint_vb2_buf_done" 
[drivers/media/common/videobuf/videobuf2-core.ko] undefined!
ERROR: "__tracepoint_vb2_dqbuf" 
[drivers/media/common/videobuf/videobuf2-core.ko] undefined!
ERROR: "v4l_vb2q_enable_media_source" 
[drivers/media/common/videobuf/videobuf2-core.ko] undefined!

We want to be able to build the core au0828 support without V4L2,
so this makes the 'select' conditional on V4L2, and refines the
dependencies in VIDEO_AU0828_V4L2 so it can only be enabled in
the exact conditions that have VIDEOBUF2_VMALLOC reachable.

Fixes: 03fbdb2fc2b8 ("media: move videobuf2 to drivers/media/common")
Fixes: 05439b1a3693 ("[media] media: au0828 - convert to use videobuf2")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/au0828/Kconfig | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/au0828/Kconfig b/drivers/media/usb/au0828/Kconfig
index 70521e0b4c53..18630b033d5b 100644
--- a/drivers/media/usb/au0828/Kconfig
+++ b/drivers/media/usb/au0828/Kconfig
@@ -4,7 +4,7 @@ config VIDEO_AU0828
depends on I2C && INPUT && DVB_CORE && USB
select I2C_ALGOBIT
select VIDEO_TVEEPROM
-   select VIDEOBUF2_VMALLOC
+   select VIDEOBUF2_VMALLOC if VIDEO_V4L2
select DVB_AU8522_DTV if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC5000 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT
@@ -18,7 +18,8 @@ config VIDEO_AU0828
 
 config VIDEO_AU0828_V4L2
bool "Auvitek AU0828 v4l2 analog video support"
-   depends on VIDEO_AU0828 && VIDEO_V4L2
+   depends on VIDEO_AU0828
+   depends on VIDEO_V4L2=y || VIDEO_V4L2=VIDEO_AU0828
select DVB_AU8522_V4L if MEDIA_SUBDRV_AUTOSELECT
select VIDEO_TUNER
default y
-- 
2.9.0



Re: [PATCH] media: don't use whitespaces for indentation

2018-01-04 Thread Sakari Ailus
Hi Mauro,

On Thu, Jan 04, 2018 at 07:27:48AM -0500, Mauro Carvalho Chehab wrote:
> On several places, whitespaces are being used for indentation,
> or even at the end of the line.
> 
> Fix them, by running a script that fix it inside drivers/media
> and include/media.

What kind of a script?

Could you also add includ/uapi/media to this?

Thanks.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi


hey

2018-01-04 Thread Lindsey
Hey,i am Lindsey ,How's everything with you,I have interest on you
after going through your profile I really want to have a good
friendship with you


[PATCH] media: don't use whitespaces for indentation

2018-01-04 Thread Mauro Carvalho Chehab
On several places, whitespaces are being used for indentation,
or even at the end of the line.

Fix them, by running a script that fix it inside drivers/media
and include/media.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/Kconfig   |  8 +++---
 drivers/media/dvb-core/Makefile |  2 +-
 drivers/media/dvb-frontends/cx24116.c   |  2 +-
 drivers/media/dvb-frontends/drxk.h  |  4 +--
 drivers/media/dvb-frontends/mb86a20s.c  |  2 +-
 drivers/media/dvb-frontends/mn88473.c   |  2 +-
 drivers/media/dvb-frontends/tda18271c2dd.h  |  4 +--
 drivers/media/i2c/Kconfig   | 10 +++
 drivers/media/i2c/cx25840/cx25840-core.c|  6 ++--
 drivers/media/i2c/smiapp/smiapp-core.c  |  2 +-
 drivers/media/i2c/tvp5150_reg.h |  4 +--
 drivers/media/pci/cx18/cx18-fileops.c   |  2 +-
 drivers/media/pci/cx18/cx18-streams.c   |  2 +-
 drivers/media/pci/ivtv/ivtv-cards.c |  2 +-
 drivers/media/pci/saa7146/mxb.c |  2 +-
 drivers/media/pci/tw5864/tw5864-video.c |  2 +-
 drivers/media/platform/Kconfig  | 38 -
 drivers/media/platform/blackfin/ppi.c   |  2 +-
 drivers/media/platform/mtk-vcodec/vdec_vpu_if.h |  2 +-
 drivers/media/platform/sti/hva/hva.h|  2 +-
 drivers/media/platform/via-camera.h |  2 +-
 drivers/media/radio/radio-maxiradio.c   |  2 +-
 drivers/media/radio/wl128x/fmdrv_common.h   | 10 +++
 drivers/media/rc/Kconfig|  8 +++---
 drivers/media/tuners/mt2063.c   |  2 +-
 drivers/media/tuners/si2157.c   |  2 +-
 drivers/media/usb/as102/as10x_cmd_cfg.c |  6 ++--
 drivers/media/usb/em28xx/Kconfig| 14 -
 drivers/media/usb/gspca/autogain_functions.c| 12 
 drivers/media/usb/gspca/cpia1.c |  2 +-
 drivers/media/usb/gspca/stv06xx/stv06xx.h   |  2 +-
 drivers/media/usb/pvrusb2/pvrusb2-devattr.c | 12 
 drivers/media/usb/tm6000/tm6000.h   |  2 +-
 drivers/media/usb/usbtv/Kconfig | 16 +--
 drivers/media/v4l2-core/Kconfig |  4 +--
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c   |  2 +-
 include/media/dvb_frontend.h| 12 
 include/media/dvb_vb2.h |  2 +-
 include/media/dvbdev.h  |  4 +--
 include/media/v4l2-async.h  |  8 +++---
 include/media/v4l2-common.h |  4 +--
 include/media/v4l2-ctrls.h  |  2 +-
 include/media/v4l2-dev.h| 16 +--
 include/media/v4l2-event.h  |  2 +-
 include/media/v4l2-subdev.h |  8 +++---
 45 files changed, 128 insertions(+), 128 deletions(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 3f69b948d102..145e12bfb819 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -80,11 +80,11 @@ config MEDIA_SDR_SUPPORT
 config MEDIA_CEC_SUPPORT
bool "HDMI CEC support"
---help---
- Enable support for HDMI CEC (Consumer Electronics Control),
- which is an optional HDMI feature.
+Enable support for HDMI CEC (Consumer Electronics Control),
+which is an optional HDMI feature.
 
- Say Y when you have an HDMI receiver, transmitter or a USB CEC
- adapter that supports HDMI CEC.
+Say Y when you have an HDMI receiver, transmitter or a USB CEC
+adapter that supports HDMI CEC.
 
 source "drivers/media/cec/Kconfig"
 
diff --git a/drivers/media/dvb-core/Makefile b/drivers/media/dvb-core/Makefile
index 3756ccf83384..05827ee2a406 100644
--- a/drivers/media/dvb-core/Makefile
+++ b/drivers/media/dvb-core/Makefile
@@ -6,7 +6,7 @@
 dvb-net-$(CONFIG_DVB_NET) := dvb_net.o
 dvb-vb2-$(CONFIG_DVB_MMSP) := dvb_vb2.o
 
-dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o \
+dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o \
 dvb_ca_en50221.o dvb_frontend.o\
 $(dvb-net-y) dvb_ringbuffer.o $(dvb-vb2-y) dvb_math.o
 
diff --git a/drivers/media/dvb-frontends/cx24116.c 
b/drivers/media/dvb-frontends/cx24116.c
index 0ef5f8614b58..786c56a4ef76 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -963,7 +963,7 @@ static int cx24116_send_diseqc_msg(struct dvb_frontend *fe,
 
/* Validate length */
if (d->msg_len > sizeof(d->msg))
-return -EINVAL;
+   return -EINVAL;
 
/* Dump DiSEqC message */
if (debug) {
diff --git a/drivers/media/dvb-frontends/drxk.h 
b/drivers/media/dvb-frontends/drxk.h
index b16fedbb53a3..d9c1a4319f90 100644
--- a/drivers/media/dvb-frontends/drxk.h
+++ 

Re: [PATCH 3/3] media: au0828: add VIDEO_V4L2 dependency

2018-01-04 Thread Arnd Bergmann
On Thu, Jan 4, 2018 at 11:31 AM, Arnd Bergmann  wrote:
> After the move of videobuf2 into the common directory, selecting the
> au0828 driver with CONFIG_V4L2 disabled started causing a link failure,
> as we now attempt to build videobuf2 but it still requires v4l2:
>
> ERROR: "v4l2_event_pending" [drivers/media/common/videobuf/videobuf2-v4l2.ko] 
> undefined!
> ERROR: "v4l2_fh_release" [drivers/media/common/videobuf/videobuf2-v4l2.ko] 
> undefined!
> ERROR: "video_devdata" [drivers/media/common/videobuf/videobuf2-v4l2.ko] 
> undefined!
> ERROR: "__tracepoint_vb2_buf_done" 
> [drivers/media/common/videobuf/videobuf2-core.ko] undefined!
> ERROR: "__tracepoint_vb2_dqbuf" 
> [drivers/media/common/videobuf/videobuf2-core.ko] undefined!
> ERROR: "v4l_vb2q_enable_media_source" 
> [drivers/media/common/videobuf/videobuf2-core.ko] undefined!
>
> This adds the same dependency in au0828 that the other users of videobuf2
> have.
>
> Fixes: 03fbdb2fc2b8 ("media: move videobuf2 to drivers/media/common")
> Fixes: 05439b1a3693 ("[media] media: au0828 - convert to use videobuf2")
> Signed-off-by: Arnd Bergmann 

On a further look, this prevents us from building the RC driver without the V4L2
driver, which was the reason this driver is split. I'll send a v2, but
it needs more
randconfig testing than this version.

Arnd


[PATCH 2/3] media: dvb: fix DVB_MMAP dependency

2018-01-04 Thread Arnd Bergmann
Enabling CONFIG_DVB_MMAP without CONFIG_VIDEOBUF2_VMALLOC results
in a link error:

drivers/media/dvb-core/dvb_vb2.o: In function `_stop_streaming':
dvb_vb2.c:(.text+0x894): undefined reference to `vb2_buffer_done'
drivers/media/dvb-core/dvb_vb2.o: In function `dvb_vb2_init':
dvb_vb2.c:(.text+0xbec): undefined reference to `vb2_vmalloc_memops'
dvb_vb2.c:(.text+0xc4c): undefined reference to `vb2_core_queue_init'
drivers/media/dvb-core/dvb_vb2.o: In function `dvb_vb2_release':
dvb_vb2.c:(.text+0xe14): undefined reference to `vb2_core_queue_release'
drivers/media/dvb-core/dvb_vb2.o: In function `dvb_vb2_stream_on':
dvb_vb2.c:(.text+0xeb8): undefined reference to `vb2_core_streamon'
drivers/media/dvb-core/dvb_vb2.o: In function `dvb_vb2_stream_off':
dvb_vb2.c:(.text+0xfe8): undefined reference to `vb2_core_streamoff'
drivers/media/dvb-core/dvb_vb2.o: In function `dvb_vb2_fill_buffer':
dvb_vb2.c:(.text+0x13ec): undefined reference to `vb2_plane_vaddr'
dvb_vb2.c:(.text+0x149c): undefined reference to `vb2_buffer_done'

This adds a 'select' statement for it, plus a dependency that
ensures that videobuf2 in turn works, as it in turn depends on
VIDEO_V4L2 to link, and that must not be a module if videobuf2
is built-in.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 3f69b948d102..d1be86ebfd9a 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -147,6 +147,8 @@ config DVB_CORE
 config DVB_MMAP
bool "Enable DVB memory-mapped API (EXPERIMENTAL)"
depends on DVB_CORE
+   depends on VIDEO_V4L2=y || VIDEO_V4L2=DVB_CORE
+   select VIDEOBUF2_VMALLOC
default n
help
  This option enables DVB experimental memory-mapped API, with
-- 
2.9.0



[PATCH 3/3] media: au0828: add VIDEO_V4L2 dependency

2018-01-04 Thread Arnd Bergmann
After the move of videobuf2 into the common directory, selecting the
au0828 driver with CONFIG_V4L2 disabled started causing a link failure,
as we now attempt to build videobuf2 but it still requires v4l2:

ERROR: "v4l2_event_pending" [drivers/media/common/videobuf/videobuf2-v4l2.ko] 
undefined!
ERROR: "v4l2_fh_release" [drivers/media/common/videobuf/videobuf2-v4l2.ko] 
undefined!
ERROR: "video_devdata" [drivers/media/common/videobuf/videobuf2-v4l2.ko] 
undefined!
ERROR: "__tracepoint_vb2_buf_done" 
[drivers/media/common/videobuf/videobuf2-core.ko] undefined!
ERROR: "__tracepoint_vb2_dqbuf" 
[drivers/media/common/videobuf/videobuf2-core.ko] undefined!
ERROR: "v4l_vb2q_enable_media_source" 
[drivers/media/common/videobuf/videobuf2-core.ko] undefined!

This adds the same dependency in au0828 that the other users of videobuf2
have.

Fixes: 03fbdb2fc2b8 ("media: move videobuf2 to drivers/media/common")
Fixes: 05439b1a3693 ("[media] media: au0828 - convert to use videobuf2")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/au0828/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/au0828/Kconfig b/drivers/media/usb/au0828/Kconfig
index 70521e0b4c53..bfaa806633df 100644
--- a/drivers/media/usb/au0828/Kconfig
+++ b/drivers/media/usb/au0828/Kconfig
@@ -1,7 +1,7 @@
 
 config VIDEO_AU0828
tristate "Auvitek AU0828 support"
-   depends on I2C && INPUT && DVB_CORE && USB
+   depends on I2C && INPUT && DVB_CORE && USB && VIDEO_V4L2
select I2C_ALGOBIT
select VIDEO_TVEEPROM
select VIDEOBUF2_VMALLOC
-- 
2.9.0



[PATCH 1/3] media: dvb: fix DVB_MMAP symbol name

2018-01-04 Thread Arnd Bergmann
CONFIG_DVB_MMAP was misspelled either as CONFIG_DVB_MMSP
or DVB_MMAP, so it had no effect at all. This fixes that,
to make it possible to build it again.

Fixes: 4021053ed52d ("media: dvb-core: make DVB mmap API optional")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/dvb-core/Makefile |  2 +-
 drivers/media/dvb-core/dmxdev.c | 30 +++---
 include/media/dvb_vb2.h |  2 +-
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/media/dvb-core/Makefile b/drivers/media/dvb-core/Makefile
index 3756ccf83384..045e2392c668 100644
--- a/drivers/media/dvb-core/Makefile
+++ b/drivers/media/dvb-core/Makefile
@@ -4,7 +4,7 @@
 #
 
 dvb-net-$(CONFIG_DVB_NET) := dvb_net.o
-dvb-vb2-$(CONFIG_DVB_MMSP) := dvb_vb2.o
+dvb-vb2-$(CONFIG_DVB_MMAP) := dvb_vb2.o
 
 dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o \
 dvb_ca_en50221.o dvb_frontend.o\
diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
index bc198f84b9cd..41e0259fc1c7 100644
--- a/drivers/media/dvb-core/dmxdev.c
+++ b/drivers/media/dvb-core/dmxdev.c
@@ -128,7 +128,7 @@ static int dvb_dvr_open(struct inode *inode, struct file 
*file)
struct dvb_device *dvbdev = file->private_data;
struct dmxdev *dmxdev = dvbdev->priv;
struct dmx_frontend *front;
-#ifndef DVB_MMAP
+#ifndef CONFIG_DVB_MMAP
bool need_ringbuffer = false;
 #else
const bool need_ringbuffer = true;
@@ -144,7 +144,7 @@ static int dvb_dvr_open(struct inode *inode, struct file 
*file)
return -ENODEV;
}
 
-#ifndef DVB_MMAP
+#ifndef CONFIG_DVB_MMAP
if ((file->f_flags & O_ACCMODE) == O_RDONLY)
need_ringbuffer = true;
 #else
@@ -200,7 +200,7 @@ static int dvb_dvr_release(struct inode *inode, struct file 
*file)
 {
struct dvb_device *dvbdev = file->private_data;
struct dmxdev *dmxdev = dvbdev->priv;
-#ifndef DVB_MMAP
+#ifndef CONFIG_DVB_MMAP
bool need_ringbuffer = false;
 #else
const bool need_ringbuffer = true;
@@ -213,7 +213,7 @@ static int dvb_dvr_release(struct inode *inode, struct file 
*file)
dmxdev->demux->connect_frontend(dmxdev->demux,
dmxdev->dvr_orig_fe);
}
-#ifndef DVB_MMAP
+#ifndef CONFIG_DVB_MMAP
if ((file->f_flags & O_ACCMODE) == O_RDONLY)
need_ringbuffer = true;
 #endif
@@ -426,7 +426,7 @@ static int dvb_dmxdev_ts_callback(const u8 *buffer1, size_t 
buffer1_len,
 {
struct dmxdev_filter *dmxdevfilter = feed->priv;
struct dvb_ringbuffer *buffer;
-#ifdef DVB_MMAP
+#ifdef CONFIG_DVB_MMAP
struct dvb_vb2_ctx *ctx;
 #endif
int ret;
@@ -440,12 +440,12 @@ static int dvb_dmxdev_ts_callback(const u8 *buffer1, 
size_t buffer1_len,
if (dmxdevfilter->params.pes.output == DMX_OUT_TAP ||
dmxdevfilter->params.pes.output == DMX_OUT_TSDEMUX_TAP) {
buffer = >buffer;
-#ifdef DVB_MMAP
+#ifdef CONFIG_DVB_MMAP
ctx = >vb2_ctx;
 #endif
} else {
buffer = >dev->dvr_buffer;
-#ifdef DVB_MMAP
+#ifdef CONFIG_DVB_MMAP
ctx = >dev->dvr_vb2_ctx;
 #endif
}
@@ -,7 +,7 @@ static int dvb_demux_do_ioctl(struct file *file,
mutex_unlock(>mutex);
break;
 
-#ifdef DVB_MMAP
+#ifdef CONFIG_DVB_MMAP
case DMX_REQBUFS:
if (mutex_lock_interruptible(>mutex)) {
mutex_unlock(>mutex);
@@ -1199,7 +1199,7 @@ static __poll_t dvb_demux_poll(struct file *file, 
poll_table *wait)
return mask;
 }
 
-#ifdef DVB_MMAP
+#ifdef CONFIG_DVB_MMAP
 static int dvb_demux_mmap(struct file *file, struct vm_area_struct *vma)
 {
struct dmxdev_filter *dmxdevfilter = file->private_data;
@@ -1249,7 +1249,7 @@ static const struct file_operations dvb_demux_fops = {
.release = dvb_demux_release,
.poll = dvb_demux_poll,
.llseek = default_llseek,
-#ifdef DVB_MMAP
+#ifdef CONFIG_DVB_MMAP
.mmap = dvb_demux_mmap,
 #endif
 };
@@ -1280,7 +1280,7 @@ static int dvb_dvr_do_ioctl(struct file *file,
ret = dvb_dvr_set_buffer_size(dmxdev, arg);
break;
 
-#ifdef DVB_MMAP
+#ifdef CONFIG_DVB_MMAP
case DMX_REQBUFS:
ret = dvb_vb2_reqbufs(>dvr_vb2_ctx, parg);
break;
@@ -1322,7 +1322,7 @@ static __poll_t dvb_dvr_poll(struct file *file, 
poll_table *wait)
struct dvb_device *dvbdev = file->private_data;
struct dmxdev *dmxdev = dvbdev->priv;
__poll_t mask = 0;
-#ifndef DVB_MMAP
+#ifndef CONFIG_DVB_MMAP
bool need_ringbuffer = false;
 #else
const bool need_ringbuffer = true;
@@ -1337,7 +1337,7 @@ static __poll_t dvb_dvr_poll(struct file *file, 
poll_table *wait)
 
poll_wait(file, >dvr_buffer.queue, wait);
 
-#ifndef DVB_MMAP
+#ifndef CONFIG_DVB_MMAP
if ((file->f_flags & 

Re: [RFC/RFT PATCH 0/6] Asynchronous UVC

2018-01-04 Thread Kieran Bingham
Hi Troy,

On 03/01/18 21:13, Troy Kisky wrote:
> On 1/3/2018 12:32 PM, Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> The Linux UVC driver has long provided adequate performance capabilities for
>> web-cams and low data rate video devices in Linux while resolutions were low.
>>
>> Modern USB cameras are now capable of high data rates thanks to USB3 with
>> 1080p, and even 4k capture resolutions supported.
>>
>> Cameras such as the Stereolabs ZED or the Logitech Brio can generate more 
>> data
>> than an embedded ARM core is able to process on a single core, resulting in
>> frame loss.
>>
>> A large part of this performance impact is from the requirement to
>> ‘memcpy’ frames out from URB packets to destination frames. This unfortunate
>> requirement is due to the UVC protocol allowing a variable length header, and
>> thus it is not possible to provide the target frame buffers directly.
> 
> I have a rather large patch that does provide frame buffers directly for bulk
> cameras. It cannot be used with ISOC cameras.  But it is currently for 4.1.
> I'll be porting it to 4.9 in a few days if you'd like to see it.

That does indeed sound interesting!

Having direct frame buffers for bulk would certainly be a benefit.
This series could then only be relevant to the ISOC cameras.

Let me know if there's anything I can do to help with porting to mainline, (as
opposed to 4.9) and feel free to send me patches to test and review.

If you're able to test these patches along side yours then that could also be
useful, although I suspect there may be a lot of cross-over - so it will likely
be more effort than just applying the patches :)

--
Regards

Kieran



> BR
> Troy
> 
> 
>>
>> Extra throughput is possible by moving the actual memcpy actions to a work
>> queue, and moving the memcpy out of interrupt context and allowing work tasks
>> to be scheduled across multiple cores.
>>
>> This series has been tested on both the ZED and Brio cameras on arm64
>> platforms, however due to the intrinsic changes in the driver I would like to
>> see it tested with other devices and other platforms, so I'd appreciate if
>> anyone can test this on a range of USB cameras.
>>
>> Kieran Bingham (6):
>>   uvcvideo: Refactor URB descriptors
>>   uvcvideo: Convert decode functions to use new context structure
>>   uvcvideo: Protect queue internals with helper
>>   uvcvideo: queue: Simplify spin-lock usage
>>   uvcvideo: queue: Support asynchronous buffer handling
>>   uvcvideo: Move decode processing to process context
>>
>>  drivers/media/usb/uvc/uvc_isight.c |   4 +-
>>  drivers/media/usb/uvc/uvc_queue.c  | 115 ++
>>  drivers/media/usb/uvc/uvc_video.c  | 191 ++
>>  drivers/media/usb/uvc/uvcvideo.h   |  56 +++--
>>  4 files changed, 289 insertions(+), 77 deletions(-)
>>
>> base-commit: 6f0e5fd39143a59c22d60e7befc4f33f22aeed2f
>>
> 


[GIT PULL for 4.16] More sensor driver patches

2018-01-04 Thread Sakari Ailus
Hi Mauro,

Here's the regular stash of sensor driver patches.

Please pull.


The following changes since commit d0c8f6ad8b381dd572576ac50b9696d4d31142bb:

  media: imx: fix breakages when compiling for arm (2017-12-29 14:55:41 -0500)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git for-4.16-2

for you to fetch changes up to 218f72b841c3fa3f08f99a55f246acef75ab2b43:

  media: ov5640: add support of RGB565 and YUYV formats (2018-01-03 22:19:17 
+0200)


Akinobu Mita (4):
  media: mt9m111: create subdevice device node
  media: mt9m111: add media controller support
  media: mt9m111: document missing required clocks property
  media: mt9m111: add V4L2_CID_TEST_PATTERN control

Dan Carpenter (1):
  media: imx274: Silence uninitialized variable warning

Hugues Fruchet (5):
  media: ov5640: switch to gpiod_set_value_cansleep()
  media: ov5640: check chip id
  media: dt-bindings: ov5640: refine CSI-2 and add parallel interface
  media: ov5640: add support of DVP parallel interface
  media: ov5640: add support of RGB565 and YUYV formats

Wenyou Yang (2):
  media: ov7740: Document device tree bindings
  media: i2c: Add the ov7740 image sensor driver

 .../devicetree/bindings/media/i2c/mt9m111.txt  |4 +
 .../devicetree/bindings/media/i2c/ov5640.txt   |   46 +-
 .../devicetree/bindings/media/i2c/ov7740.txt   |   47 +
 MAINTAINERS|8 +
 drivers/media/i2c/Kconfig  |8 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/imx274.c |2 +-
 drivers/media/i2c/mt9m111.c|   51 +-
 drivers/media/i2c/ov5640.c |  325 +-
 drivers/media/i2c/ov7740.c | 1216 
 10 files changed, 1658 insertions(+), 50 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt
 create mode 100644 drivers/media/i2c/ov7740.c

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi


[GIT PULL for 4.16] Intel IPU3 CIO2 fixes, cleanup

2018-01-04 Thread Sakari Ailus
Hi Mauro,

Here are a bunch of fixes for the Intel IPU3 CIO2 driver, as well as the
cleanup I wrote earlier.

Please pull.


The following changes since commit d0c8f6ad8b381dd572576ac50b9696d4d31142bb:

  media: imx: fix breakages when compiling for arm (2017-12-29 14:55:41 -0500)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git ipu3

for you to fetch changes up to ec9d117f472d27289bf0e845b325e5852d5799dd:

  media: intel-ipu3: cio2: fix for wrong vb2buf state warnings (2018-01-04 
12:14:28 +0200)


Arnd Bergmann (2):
  media: intel-ipu3: cio2: mark PM functions as __maybe_unused
  media: intel-ipu3: cio2: fix building with large PAGE_SIZE

Sakari Ailus (1):
  intel-ipu3: Rename arr_size macro, use min

Yong Zhi (2):
  media: intel-ipu3: cio2: fix a crash with out-of-bounds access
  media: intel-ipu3: cio2: fix for wrong vb2buf state warnings

 drivers/media/pci/intel/ipu3/ipu3-cio2.c | 31 ---
 drivers/media/pci/intel/ipu3/ipu3-cio2.h |  2 +-
 2 files changed, 17 insertions(+), 16 deletions(-)

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi


Re: [Yavta Patches v1 0/2] Add support for intel ipu3 specific formats

2018-01-04 Thread Sakari Ailus
Hi Tian Shu,

On Thu, Jan 04, 2018 at 11:48:11AM +0800, tian.shu@intel.com wrote:
> From: Tianshu Qiu 
> 
> This patch set adds new pixel formats specific for intel 3rd generation
> ipu driver.

Thanks for the patches. For both:

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com


[PATCH v2 0/2] media: ov7670: Implement mbus configuration

2018-01-04 Thread Jacopo Mondi
Hello,
   this series adds mbus configuration properties to ov7670 sensor driver.

I have sent v1 a few days ago and forgot to cc device tree people. Doing it
now with bindings description and implementation split in 2 separate patches.

I have fixed Sakari's comment on v1, and I'm sending v2 out with support for
"pll-bypass" custom property as it was in v1. If we decide it is not worth
to make an OF property out of it, I will drop it in v3. Technically it is not
even an mbus configuration option, so I'm fine dropping it eventually.

Thanks
  j

v1->v2:
- Split bindings description and implementation
- Addressed Sakari's comments on v1
- Check for return values of register writes in set_fmt()
- TODO: decide if "pll-bypass" should be an OF property.

Jacopo Mondi (2):
  v4l2: i2c: ov7670: Implement OF mbus configuration
  media: dt-bindings: Add OF properties to ov7670

 .../devicetree/bindings/media/i2c/ov7670.txt   |  14 +++
 drivers/media/i2c/ov7670.c | 124 ++---
 2 files changed, 124 insertions(+), 14 deletions(-)

--
2.7.4



[PATCH v2 2/2] media: dt-bindings: Add OF properties to ov7670

2018-01-04 Thread Jacopo Mondi
Describe newly introduced OF properties for ov7670 image sensor.
The driver supports two standard properties to configure synchronism
signals polarities and two custom properties already supported as
platform data options by the driver.
---
 Documentation/devicetree/bindings/media/i2c/ov7670.txt | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/i2c/ov7670.txt 
b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
index 826b656..57ded18 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov7670.txt
+++ b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
@@ -9,11 +9,22 @@ Required Properties:
 - clocks: reference to the xclk input clock.
 - clock-names: should be "xclk".
 
+The following properties, as defined by video interfaces OF bindings
+"Documentation/devicetree/bindings/media/video-interfaces.txt" are supported:
+
+- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH 
respectively.
+- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH 
respectively.
+
+Default is high active state for both vsync and hsync signals.
+
 Optional Properties:
 - reset-gpios: reference to the GPIO connected to the resetb pin, if any.
   Active is low.
 - powerdown-gpios: reference to the GPIO connected to the pwdn pin, if any.
   Active is high.
+- ov7670,pll-bypass: set to 1 to bypass PLL for pixel clock generation.
+- ov7670,pclk-hb-disable: set to 1 to suppress pixel clock output signal during
+  horizontal blankings.
 
 The device node must contain one 'port' child node for its digital output
 video port, in accordance with the video interface bindings defined in
@@ -34,6 +45,9 @@ Example:
assigned-clocks = <>;
assigned-clock-rates = <2500>;
 
+   vsync-active = <0>;
+   ov7670,pclk-hb-disable = <1>;
+
port {
ov7670_0: endpoint {
remote-endpoint = <_0>;
-- 
2.7.4



[PATCH v2 1/2] v4l2: i2c: ov7670: Implement OF mbus configuration

2018-01-04 Thread Jacopo Mondi
ov7670 driver supports two optional properties supplied through platform
data, but currently does not support any standard video interface
property.

Add support through OF parsing for 2 generic properties (vsync and hsync
polarities) and for two custom properties already supported by platform
data.

While at there, check return value of register writes in set_fmt
function and rationalize spacings.

Signal polarities and pixel clock blanking verified through scope and
image capture.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/ov7670.c | 124 -
 1 file changed, 110 insertions(+), 14 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 950a0ac..d40a601 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -237,6 +238,7 @@ struct ov7670_info {
struct clk *clk;
struct gpio_desc *resetb_gpio;
struct gpio_desc *pwdn_gpio;
+   unsigned int mbus_config;   /* Media bus configuration flags */
int min_width;  /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -995,7 +997,7 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
 #ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
struct v4l2_mbus_framefmt *mbus_fmt;
 #endif
-   unsigned char com7;
+   unsigned char com7, com10 = 0;
int ret;
 
if (format->pad)
@@ -1015,7 +1017,6 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
}
 
ret = ov7670_try_fmt_internal(sd, >format, , );
-
if (ret)
return ret;
/*
@@ -1026,16 +1027,41 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
 */
com7 = ovfmt->regs[0].value;
com7 |= wsize->com7_bit;
-   ov7670_write(sd, REG_COM7, com7);
+   ret = ov7670_write(sd, REG_COM7, com7);
+   if (ret)
+   return ret;
+
+   /*
+* Configure the media bus through COM10 register
+*/
+   if (info->mbus_config & V4L2_MBUS_VSYNC_ACTIVE_LOW)
+   com10 |= COM10_VS_NEG;
+   if (info->mbus_config & V4L2_MBUS_HSYNC_ACTIVE_LOW)
+   com10 |= COM10_HREF_REV;
+   if (info->pclk_hb_disable)
+   com10 |= COM10_PCLK_HB;
+   ret = ov7670_write(sd, REG_COM10, com10);
+   if (ret)
+   return ret;
+
/*
 * Now write the rest of the array.  Also store start/stops
 */
-   ov7670_write_array(sd, ovfmt->regs + 1);
-   ov7670_set_hw(sd, wsize->hstart, wsize->hstop, wsize->vstart,
-   wsize->vstop);
-   ret = 0;
-   if (wsize->regs)
+   ret = ov7670_write_array(sd, ovfmt->regs + 1);
+   if (ret)
+   return ret;
+
+   ret = ov7670_set_hw(sd, wsize->hstart, wsize->hstop, wsize->vstart,
+   wsize->vstop);
+   if (ret)
+   return ret;
+
+   if (wsize->regs) {
ret = ov7670_write_array(sd, wsize->regs);
+   if (ret)
+   return ret;
+   }
+
info->fmt = ovfmt;
 
/*
@@ -1048,8 +1074,10 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
 * to write it unconditionally, and that will make the frame
 * rate persistent too.
 */
-   if (ret == 0)
-   ret = ov7670_write(sd, REG_CLKRC, info->clkrc);
+   ret = ov7670_write(sd, REG_CLKRC, info->clkrc);
+   if (ret)
+   return ret;
+
return 0;
 }
 
@@ -1658,6 +1686,71 @@ static int ov7670_init_gpio(struct i2c_client *client, 
struct ov7670_info *info)
return 0;
 }
 
+/*
+ * ov7670_parse_dt() - Parse device tree to collect mbus configuration
+ * properties
+ */
+static int ov7670_parse_dt(struct device *dev,
+  struct ov7670_info *info)
+{
+   struct fwnode_handle *fwnode = dev_fwnode(dev);
+   struct v4l2_fwnode_endpoint bus_cfg;
+   struct fwnode_handle *ep;
+   u32 propval;
+   int ret;
+
+   if (!fwnode)
+   return -EINVAL;
+
+   ep = fwnode_graph_get_next_endpoint(fwnode, NULL);
+   if (!ep)
+   return -EINVAL;
+
+   ret = v4l2_fwnode_endpoint_parse(ep, _cfg);
+   if (ret) {
+   fwnode_handle_put(fwnode);
+   return ret;
+   }
+
+   /* Any CSI-2 property set? */
+   if (bus_cfg.bus_type != V4L2_MBUS_PARALLEL) {
+   fwnode_handle_put(fwnode);
+   return -EINVAL;
+   }
+   info->mbus_config = bus_cfg.bus.parallel.flags;
+   fwnode_handle_put(fwnode);
+
+   /* Parse custom OF properties. */
+   info->pclk_hb_disable = false;
+   info->pll_bypass = false;
+
+   ret = 

Re: [PATCH v3 00/27] kill devm_ioremap_nocache

2018-01-04 Thread Christophe LEROY



Le 25/12/2017 à 02:34, Yisheng Xie a écrit :



On 2017/12/24 17:05, christophe leroy wrote:



Le 23/12/2017 à 14:48, Greg KH a écrit :

On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:

Hi all,

When I tried to use devm_ioremap function and review related code, I found
devm_ioremap and devm_ioremap_nocache is almost the same with each other,
except one use ioremap while the other use ioremap_nocache.


For all arches?  Really?  Look at MIPS, and x86, they have different
functions.


While ioremap's
default function is ioremap_nocache, so devm_ioremap_nocache also have the
same function with devm_ioremap, which can just be killed to reduce the size
of devres.o(from 20304 bytes to 18992 bytes in my compile environment).

I have posted two versions, which use macro instead of function for
devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
devm_ioremap_nocache for no need to keep a macro around for the duplicate
thing. So here comes v3 and please help to review.


I don't think this can be done, what am I missing?  These functions are
not identical, sorry for missing that before.


devm_ioremap() and devm_ioremap_nocache() are quite similar, both use 
devm_ioremap_release() for the release, why not just defining:

static void __iomem *__devm_ioremap(struct device *dev, resource_size_t offset,
resource_size_t size, bool nocache)
{
[...]
 if (nocache)
 addr = ioremap_nocache(offset, size);
 else
 addr = ioremap(offset, size);
[...]
}

then in include/linux/io.h

static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t 
offset,
resource_size_t size)
{return __devm_ioremap(dev, offset, size, false);}

static inline void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
resource_size_t size);
{return __devm_ioremap(dev, offset, size, true);}


Yeah, this seems good to me, right now we have devm_ioremap, devm_ioremap_wc, 
devm_ioremap_nocache
May be we can use an enum like:
typedef enum {
DEVM_IOREMAP = 0,
DEVM_IOREMAP_NOCACHE,
DEVM_IOREMAP_WC,
} devm_ioremap_type;

static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t 
offset,
 resource_size_t size)
  {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP);}

  static inline void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
 resource_size_t size);
  {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_NOCACHE);}

  static inline void __iomem *devm_ioremap_wc(struct device *dev, 
resource_size_t offset,
 resource_size_t size);
  {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_WC);}

  static void __iomem *__devm_ioremap(struct device *dev, resource_size_t 
offset,
 resource_size_t size, devm_ioremap_type type)
  {
  void __iomem **ptr, *addr = NULL;
  [...]
  switch (type){
  case DEVM_IOREMAP:
  addr = ioremap(offset, size);
  break;
  case DEVM_IOREMAP_NOCACHE:
  addr = ioremap_nocache(offset, size);
  break;
  case DEVM_IOREMAP_WC:
  addr = ioremap_wc(offset, size);
  break;
  }
  [...]
  }



That looks good to me, will you submit a v4 ?

Christophe



Thanks
Yisheng



Christophe



thanks,

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



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


.