cron job: media_tree daily build: ERRORS

[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:   Sat Jul 16 04:00:13 CEST 2016
git branch: test
git hash:   eca2d34b9d2ce70165a50510659838e28ca22742
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: ERRORS
linux-git-blackfin-bf561: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
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: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.23-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: ERRORS
linux-4.0-i686: ERRORS
linux-4.1.1-i686: ERRORS
linux-4.2-i686: ERRORS
linux-4.3-i686: ERRORS
linux-4.4-i686: ERRORS
linux-4.5-i686: ERRORS
linux-4.6-i686: ERRORS
linux-4.7-rc1-i686: ERRORS
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: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.23-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: ERRORS
linux-4.0-x86_64: ERRORS
linux-4.1.1-x86_64: ERRORS
linux-4.2-x86_64: ERRORS
linux-4.3-x86_64: ERRORS
linux-4.4-x86_64: ERRORS
linux-4.5-x86_64: ERRORS
linux-4.6-x86_64: ERRORS
linux-4.7-rc1-x86_64: ERRORS
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Javier Martinez Canillas]

Hello Shuah,

On 07/15/2016 03:42 PM, Shuah Khan wrote:
> On 07/15/2016 10:26 AM, Javier Martinez Canillas wrote:
>> The buffer planes' dma-buf are currently mapped when buffers are queued
>> from userspace but it's more appropriate to do the mapping when buffers
>> are queued in the driver since that's when the actual DMA operation are
>> going to happen.
>>
>> Suggested-by: Nicolas Dufresne 
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>> Hello,
>>
>> A side effect of this change is that if the dmabuf map fails for some
>> reasons (i.e: a driver using the DMA contig memory allocator but CMA
>> not being enabled), the fail will no longer happen on VIDIOC_QBUF but
>> later (i.e: in VIDIOC_STREAMON).
>>
>> I don't know if that's an issue though but I think is worth mentioning.
> 
> How does this change impact the user applications.? This changes

One thing that Nicolas mentioned is that for example GStreamer uses QBUF
to detect if a dma-buf is compatible, and fallbacks to a slow path if
that's not the case. For example if VIDIOC_QBUF fails, gst can attempt
to do another VIDIOC_REQBUFS with a different streaming I/O method as a
fallback.

If now QBUF doesn't fail, then gst will believe that it's OK and drop the
buffer so won't be able to recover from an error later and do a fallback.

Now, I don't know if that is the correct thing to expect since the v4l2
doc for VIDIOC_QBUF doesn't say that the ioctl should be used for this.

The question is if validating that the exported dma-buf can be imported
is something that could be done without attempting to do the mapping.

> the behavior and user applications now get dmabuf map error at a
> later stage in the call sequence.
>
> The change itself looks consistent with the change described.
> 
> -- Shuah
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] subsystem:linux-media CVE-2016-5400

[Linus Torvalds]

On Fri, 15 Jul 2016, James Patrick-Evans wrote:
>
> The memory leak is caused by the probe function of the airspy driver
> mishandeling errors and not freeing the corresponding control structures when
> an error occours registering the device to v4l2 core.

The patch causes a warning about the now unused label.

I fixed that and cleaned up the commit message, and applied the end 
result.

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

Re: [PATCH 3/3] [media] cxd2841er: Reading SNR for DVB-C added

[Abylay Ospan]

Hi Mauro,

This is patches for cxd2841er for reading UCB, SNR and BER for DVB-C.
Please, apply this patches.
But first need to apply all of your previous patches (i'v picked it
from your emails):

commit f38faf6f4ff49b549c4b7d4ff7ae93945ed7255c
Author: Mauro Carvalho Chehab 
Date:   Fri Jul 1 15:41:38 2016 -0300

cxd2841er: fix signal strength scale for ISDB-T

commit 73116c317e4ec018d302e8a990b2379cb3a7
Author: Mauro Carvalho Chehab 
Date:   Fri Jul 1 11:03:16 2016 -0300

cxd2841er: adjust the dB scale for DVB-C

commit a994179e7cca5f5fb4dbc1e26489cc644be99cef
Author: Mauro Carvalho Chehab 
Date:   Fri Jul 1 11:03:14 2016 -0300

cxd2841er: provide signal strength for DVB-C

commit aed60dc2282486104009b6d3eb996a475a834fec
Author: Mauro Carvalho Chehab 
Date:   Fri Jul 1 11:03:15 2016 -0300

cxd2841er: fix BER report via DVBv5 stats API

I have made repository with all required patches here:
https://github.com/aospan/media_tree

(it's based on git://linuxtv.org/media_tree.git)

Please pull all of this patches.

thanks !

2016-07-15 16:21 GMT-04:00 Abylay Ospan :
> now driver returns correct values for DVB-C:
>  SNR (in dB)
>
> Signed-off-by: Abylay Ospan 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 89 
> ++---
>  1 file changed, 81 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 623b04f3..99baccf 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -1570,7 +1570,8 @@ static int cxd2841er_read_ber_t(struct cxd2841er_priv 
> *priv,
> return 0;
>  }
>
> -static u32 cxd2841er_dvbs_read_snr(struct cxd2841er_priv *priv, u8 delsys)
> +static u32 cxd2841er_dvbs_read_snr(struct cxd2841er_priv *priv,
> +   u8 delsys, u32 *snr)
>  {
> u8 data[3];
> u32 res = 0, value;
> @@ -1628,9 +1629,71 @@ static u32 cxd2841er_dvbs_read_snr(struct 
> cxd2841er_priv *priv, u8 delsys)
> } else {
> dev_dbg(>i2c->dev,
> "%s(): no data available\n", __func__);
> +   return -EINVAL;
> }
>  done:
> -   return res;
> +   *snr = res;
> +   return 0;
> +}
> +
> +uint32_t sony_log(uint32_t x)
> +{
> +   return (((1>>8)*(intlog2(x)>>16) + LOG2_E_100X/2)/LOG2_E_100X);
> +}
> +
> +static int cxd2841er_read_snr_c(struct cxd2841er_priv *priv, u32 *snr)
> +{
> +   u32 reg;
> +   u8 data[2];
> +   enum sony_dvbc_constellation_t qam = SONY_DVBC_CONSTELLATION_16QAM;
> +
> +   *snr = 0;
> +   if (priv->state != STATE_ACTIVE_TC) {
> +   dev_dbg(>i2c->dev,
> +   "%s(): invalid state %d\n",
> +   __func__, priv->state);
> +   return -EINVAL;
> +   }
> +
> +   /*
> +* Freeze registers: ensure multiple separate register reads
> +* are from the same snapshot
> +*/
> +   cxd2841er_write_reg(priv, I2C_SLVT, 0x01, 0x01);
> +
> +   cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x40);
> +   cxd2841er_read_regs(priv, I2C_SLVT, 0x19, data, 1);
> +   qam = (enum sony_dvbc_constellation_t) (data[0] & 0x07);
> +   cxd2841er_read_regs(priv, I2C_SLVT, 0x4C, data, 2);
> +
> +   reg = ((u32)(data[0]&0x1f) << 8) | (u32)data[1];
> +   if (reg == 0) {
> +   dev_dbg(>i2c->dev,
> +   "%s(): reg value out of range\n", __func__);
> +   return 0;
> +   }
> +
> +   switch (qam) {
> +   case SONY_DVBC_CONSTELLATION_16QAM:
> +   case SONY_DVBC_CONSTELLATION_64QAM:
> +   case SONY_DVBC_CONSTELLATION_256QAM:
> +   /* SNR(dB) = -9.50 * ln(IREG_SNR_ESTIMATE / (24320)) */
> +   if (reg < 126)
> +   reg = 126;
> +   *snr = -95 * (int32_t)sony_log(reg) + 95941;
> +   break;
> +   case SONY_DVBC_CONSTELLATION_32QAM:
> +   case SONY_DVBC_CONSTELLATION_128QAM:
> +   /* SNR(dB) = -8.75 * ln(IREG_SNR_ESTIMATE / (20800)) */
> +   if (reg < 69)
> +   reg = 69;
> +   *snr = -88 * (int32_t)sony_log(reg) + 86999;
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   return 0;
>  }
>
>  static int cxd2841er_read_snr_t(struct cxd2841er_priv *priv, u32 *snr)
> @@ -1871,23 +1934,29 @@ static void cxd2841er_read_signal_strength(struct 
> dvb_frontend *fe)
>  static void cxd2841er_read_snr(struct dvb_frontend *fe)
>  {
> u32 tmp = 0;
> +   int ret = 0;
> struct dtv_frontend_properties *p = >dtv_property_cache;
> struct cxd2841er_priv *priv = fe->demodulator_priv;
>
> dev_dbg(>i2c->dev, "%s()\n", __func__);
> 

[PATCH 3/3] [media] cxd2841er: Reading SNR for DVB-C added

[Abylay Ospan]

now driver returns correct values for DVB-C:
 SNR (in dB)

Signed-off-by: Abylay Ospan 
---
 drivers/media/dvb-frontends/cxd2841er.c | 89 ++---
 1 file changed, 81 insertions(+), 8 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 623b04f3..99baccf 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -1570,7 +1570,8 @@ static int cxd2841er_read_ber_t(struct cxd2841er_priv 
*priv,
return 0;
 }
 
-static u32 cxd2841er_dvbs_read_snr(struct cxd2841er_priv *priv, u8 delsys)
+static u32 cxd2841er_dvbs_read_snr(struct cxd2841er_priv *priv,
+   u8 delsys, u32 *snr)
 {
u8 data[3];
u32 res = 0, value;
@@ -1628,9 +1629,71 @@ static u32 cxd2841er_dvbs_read_snr(struct cxd2841er_priv 
*priv, u8 delsys)
} else {
dev_dbg(>i2c->dev,
"%s(): no data available\n", __func__);
+   return -EINVAL;
}
 done:
-   return res;
+   *snr = res;
+   return 0;
+}
+
+uint32_t sony_log(uint32_t x)
+{
+   return (((1>>8)*(intlog2(x)>>16) + LOG2_E_100X/2)/LOG2_E_100X);
+}
+
+static int cxd2841er_read_snr_c(struct cxd2841er_priv *priv, u32 *snr)
+{
+   u32 reg;
+   u8 data[2];
+   enum sony_dvbc_constellation_t qam = SONY_DVBC_CONSTELLATION_16QAM;
+
+   *snr = 0;
+   if (priv->state != STATE_ACTIVE_TC) {
+   dev_dbg(>i2c->dev,
+   "%s(): invalid state %d\n",
+   __func__, priv->state);
+   return -EINVAL;
+   }
+
+   /*
+* Freeze registers: ensure multiple separate register reads
+* are from the same snapshot
+*/
+   cxd2841er_write_reg(priv, I2C_SLVT, 0x01, 0x01);
+
+   cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x40);
+   cxd2841er_read_regs(priv, I2C_SLVT, 0x19, data, 1);
+   qam = (enum sony_dvbc_constellation_t) (data[0] & 0x07);
+   cxd2841er_read_regs(priv, I2C_SLVT, 0x4C, data, 2);
+
+   reg = ((u32)(data[0]&0x1f) << 8) | (u32)data[1];
+   if (reg == 0) {
+   dev_dbg(>i2c->dev,
+   "%s(): reg value out of range\n", __func__);
+   return 0;
+   }
+
+   switch (qam) {
+   case SONY_DVBC_CONSTELLATION_16QAM:
+   case SONY_DVBC_CONSTELLATION_64QAM:
+   case SONY_DVBC_CONSTELLATION_256QAM:
+   /* SNR(dB) = -9.50 * ln(IREG_SNR_ESTIMATE / (24320)) */
+   if (reg < 126)
+   reg = 126;
+   *snr = -95 * (int32_t)sony_log(reg) + 95941;
+   break;
+   case SONY_DVBC_CONSTELLATION_32QAM:
+   case SONY_DVBC_CONSTELLATION_128QAM:
+   /* SNR(dB) = -8.75 * ln(IREG_SNR_ESTIMATE / (20800)) */
+   if (reg < 69)
+   reg = 69;
+   *snr = -88 * (int32_t)sony_log(reg) + 86999;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
 }
 
 static int cxd2841er_read_snr_t(struct cxd2841er_priv *priv, u32 *snr)
@@ -1871,23 +1934,29 @@ static void cxd2841er_read_signal_strength(struct 
dvb_frontend *fe)
 static void cxd2841er_read_snr(struct dvb_frontend *fe)
 {
u32 tmp = 0;
+   int ret = 0;
struct dtv_frontend_properties *p = >dtv_property_cache;
struct cxd2841er_priv *priv = fe->demodulator_priv;
 
dev_dbg(>i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
+   case SYS_DVBC_ANNEX_A:
+   case SYS_DVBC_ANNEX_B:
+   case SYS_DVBC_ANNEX_C:
+   ret = cxd2841er_read_snr_c(priv, );
+   break;
case SYS_DVBT:
-   cxd2841er_read_snr_t(priv, );
+   ret = cxd2841er_read_snr_t(priv, );
break;
case SYS_DVBT2:
-   cxd2841er_read_snr_t2(priv, );
+   ret = cxd2841er_read_snr_t2(priv, );
break;
case SYS_ISDBT:
-   cxd2841er_read_snr_i(priv, );
+   ret = cxd2841er_read_snr_i(priv, );
break;
case SYS_DVBS:
case SYS_DVBS2:
-   tmp = cxd2841er_dvbs_read_snr(priv, p->delivery_system);
+   ret = cxd2841er_dvbs_read_snr(priv, p->delivery_system, );
break;
default:
dev_dbg(>i2c->dev, "%s(): unknown delivery system %d\n",
@@ -1896,8 +1965,12 @@ static void cxd2841er_read_snr(struct dvb_frontend *fe)
return;
}
 
-   p->cnr.stat[0].scale = FE_SCALE_DECIBEL;
-   p->cnr.stat[0].svalue = tmp;
+   if (!ret) {
+   p->cnr.stat[0].scale = FE_SCALE_DECIBEL;
+   p->cnr.stat[0].svalue = tmp;
+   } else {
+   p->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   }
 }
 
 static void cxd2841er_read_ucblocks(struct dvb_frontend *fe)
-- 

[PATCH 2/3] [media] cxd2841er: Reading BER and UCB for DVB-C added

[Abylay Ospan]

now driver returns correct values for DVB-C:
 BER (post_bit_count and post_bit_error values)
 UCB (count of uncorrected errors)
also, some code cleanup was done - checkpatch.pl now is happy

Signed-off-by: Abylay Ospan 
---
 drivers/media/dvb-frontends/cxd2841er.c | 87 +++--
 1 file changed, 84 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index b2bfbaa..623b04f3 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -36,6 +36,16 @@
 #include "cxd2841er_priv.h"
 
 #define MAX_WRITE_REGSIZE  16
+#define LOG2_E_100X 144
+
+/* DVB-C constellation */
+enum sony_dvbc_constellation_t {
+   SONY_DVBC_CONSTELLATION_16QAM,
+   SONY_DVBC_CONSTELLATION_32QAM,
+   SONY_DVBC_CONSTELLATION_64QAM,
+   SONY_DVBC_CONSTELLATION_128QAM,
+   SONY_DVBC_CONSTELLATION_256QAM
+};
 
 enum cxd2841er_state {
STATE_SHUTDOWN = 0,
@@ -1262,6 +1272,24 @@ static int cxd2841er_get_carrier_offset_c(struct 
cxd2841er_priv *priv,
return 0;
 }
 
+static int cxd2841er_read_packet_errors_c(
+   struct cxd2841er_priv *priv, u32 *penum)
+{
+   u8 data[3];
+
+   *penum = 0;
+   if (priv->state != STATE_ACTIVE_TC) {
+   dev_dbg(>i2c->dev, "%s(): invalid state %d\n",
+   __func__, priv->state);
+   return -EINVAL;
+   }
+   cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x40);
+   cxd2841er_read_regs(priv, I2C_SLVT, 0xea, data, sizeof(data));
+   if (data[2] & 0x01)
+   *penum = ((u32)data[0] << 8) | (u32)data[1];
+   return 0;
+}
+
 static int cxd2841er_read_packet_errors_t(
struct cxd2841er_priv *priv, u32 *penum)
 {
@@ -1330,6 +1358,49 @@ static int cxd2841er_read_packet_errors_i(
return 0;
 }
 
+static int cxd2841er_read_ber_c(struct cxd2841er_priv *priv,
+   u32 *bit_error, u32 *bit_count)
+{
+   u8 data[3];
+   u32 bit_err, period_exp;
+
+   dev_dbg(>i2c->dev, "%s()\n", __func__);
+   if (priv->state != STATE_ACTIVE_TC) {
+   dev_dbg(>i2c->dev, "%s(): invalid state %d\n",
+   __func__, priv->state);
+   return -EINVAL;
+   }
+   cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x40);
+   cxd2841er_read_regs(priv, I2C_SLVT, 0x62, data, sizeof(data));
+   if (!(data[0] & 0x80)) {
+   dev_dbg(>i2c->dev,
+   "%s(): no valid BER data\n", __func__);
+   return -EINVAL;
+   }
+   bit_err = ((u32)(data[0] & 0x3f) << 16) |
+   ((u32)data[1] << 8) |
+   (u32)data[2];
+   cxd2841er_read_reg(priv, I2C_SLVT, 0x60, data);
+   period_exp = data[0] & 0x1f;
+
+   if ((period_exp <= 11) && (bit_err > (1 << period_exp) * 204 * 8)) {
+   dev_dbg(>i2c->dev,
+   "%s(): period_exp(%u) or bit_err(%u)  not in 
range. no valid BER data\n",
+   __func__, period_exp, bit_err);
+   return -EINVAL;
+   }
+
+   dev_dbg(>i2c->dev,
+   "%s(): period_exp(%u) or bit_err(%u) count=%d\n",
+   __func__, period_exp, bit_err,
+   ((1 << period_exp) * 204 * 8));
+
+   *bit_error = bit_err;
+   *bit_count = ((1 << period_exp) * 204 * 8);
+
+   return 0;
+}
+
 static int cxd2841er_mon_read_ber_s(struct cxd2841er_priv *priv,
u32 *bit_error, u32 *bit_count)
 {
@@ -1461,7 +1532,7 @@ static int cxd2841er_read_ber_t2(struct cxd2841er_priv 
*priv,
*bit_error *= 3125ULL;
} else {
*bit_count = (1U << period_exp) * (n_ldpc / 200);
-   *bit_error *= 5ULL;;
+   *bit_error *= 5ULL;
}
return 0;
 }
@@ -1713,6 +1784,11 @@ static void cxd2841er_read_ber(struct dvb_frontend *fe)
 
dev_dbg(>i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
+   case SYS_DVBC_ANNEX_A:
+   case SYS_DVBC_ANNEX_B:
+   case SYS_DVBC_ANNEX_C:
+   ret = cxd2841er_read_ber_c(priv, _error, _count);
+   break;
case SYS_DVBS:
ret = cxd2841er_mon_read_ber_s(priv, _error, _count);
break;
@@ -1733,9 +1809,9 @@ static void cxd2841er_read_ber(struct dvb_frontend *fe)
 
if (!ret) {
p->post_bit_error.stat[0].scale = FE_SCALE_COUNTER;
-   p->post_bit_error.stat[0].uvalue = bit_error;
+   p->post_bit_error.stat[0].uvalue += bit_error;
p->post_bit_count.stat[0].scale = FE_SCALE_COUNTER;
-   p->post_bit_count.stat[0].uvalue = bit_count;
+   p->post_bit_count.stat[0].uvalue += bit_count;
} else {
p->post_bit_error.stat[0].scale = 

[PATCH 1/3] [media] cxd2841er: fix switch-case for DVB-C

[Abylay Ospan]

compilation was failed with complains about duplicate case.
now fixed

Signed-off-by: Abylay Ospan 
---
 drivers/media/dvb-frontends/cxd2841er.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 41349c2..b2bfbaa 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -1750,14 +1750,6 @@ static void cxd2841er_read_signal_strength(struct 
dvb_frontend *fe)
 
dev_dbg(>i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
-   case SYS_DVBC_ANNEX_A:
-   case SYS_DVBC_ANNEX_B:
-   case SYS_DVBC_ANNEX_C:
-   strength = 65535 - cxd2841er_read_agc_gain_c(
-   priv, p->delivery_system);
-   p->strength.stat[0].scale = FE_SCALE_RELATIVE;
-   p->strength.stat[0].uvalue = strength;
-   break;
case SYS_DVBT:
case SYS_DVBT2:
strength = cxd2841er_read_agc_gain_t_t2(priv,
@@ -1767,7 +1759,9 @@ static void cxd2841er_read_signal_strength(struct 
dvb_frontend *fe)
p->strength.stat[0].uvalue = strength * 366 / 100 - 89520;
break;  /* Code moved out of the function */
case SYS_DVBC_ANNEX_A:
-   strength = cxd2841er_read_agc_gain_t_t2(priv,
+   case SYS_DVBC_ANNEX_B:
+   case SYS_DVBC_ANNEX_C:
+   strength = cxd2841er_read_agc_gain_c(priv,
p->delivery_system);
p->strength.stat[0].scale = FE_SCALE_DECIBEL;
/*
-- 
2.7.4

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

Re: next build: 143 builds: 3 failed, 140 passed, 4 errors, 131 warnings (next-20160715)

[Arnd Bergmann]

On Friday, July 15, 2016 5:37:02 AM CEST kernelci. org bot wrote:
> 
>   1  pm-rcar-gen2.c:(.init.text+0x740): undefined reference to 
> `platform_can_secondary_boot'

I sent a patch for it, Geert added an Ack, but it's still waiting to come
back through the renesas tree.

Note that the actual error is in arch/arm/mach-shmobile/platsmp.c,
not in pm-rcar-gen2.c

>   1  fs/fat/dir.c:758:424: internal compiler error: Segmentation fault

I reported the gcc but when it broke in 4.9, but it was only fixed in 6.1,
so this will have to wait for the kernelci infrastructure to do something
about it by updating their toolchain or blacklisting the config.

>   1  drivers/pinctrl/bcm/pinctrl-nsp-mux.c:356:20: error: 
> 'pinconf_generic_dt_node_to_map_group' undeclared here (not in a function)
>   1  drivers/pinctrl/bcm/pinctrl-cygnus-mux.c:739:20: error: 
> 'pinconf_generic_dt_node_to_map_group' undeclared here (not in a function)

I though I sent a patch for it but con't find it now. We basically need
this:

Subject: [PATCH] pinctrl: bcm: add OF dependencies

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/pinctrl/bcm/Kconfig b/drivers/pinctrl/bcm/Kconfig
index 7967c6723676..63246770bd74 100644
--- a/drivers/pinctrl/bcm/Kconfig
+++ b/drivers/pinctrl/bcm/Kconfig
@@ -60,6 +60,7 @@ config PINCTRL_IPROC_GPIO
 config PINCTRL_CYGNUS_MUX
bool "Broadcom Cygnus IOMUX driver"
depends on (ARCH_BCM_CYGNUS || COMPILE_TEST)
+   depends on OF
select PINMUX
select GENERIC_PINCONF
default ARCH_BCM_CYGNUS
@@ -103,6 +104,7 @@ config PINCTRL_NS2_MUX
 config PINCTRL_NSP_MUX
bool "Broadcom NSP IOMUX driver"
depends on (ARCH_BCM_NSP || COMPILE_TEST)
+   depends on OF
select PINMUX
select GENERIC_PINCONF
default ARCH_BCM_NSP


> Warnings summary:
> 
>  43  drivers/video/fbdev/core/fbmon.c:1497:67: warning: parameter 'specs' 
> set but not used [-Wunused-but-set-parameter]

I sent a patch on June 16 when this warning was only for "make W=1", but
never got a reply from the fbdev maintainers (which is not uncommon
for that subsystem). Now Andrew merged a patch to have the warning at the
default level, I'll send him my oneline patch so he can apply it as well:

--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -1496,7 +1496,6 @@ int fb_parse_edid(unsigned char *edid, struct 
fb_var_screeninfo *var)
 }
 void fb_edid_to_monspecs(unsigned char *edid, struct fb_monspecs *specs)
 {
-   specs = NULL;
 }
 void fb_edid_add_monspecs(unsigned char *edid, struct fb_monspecs *specs)
 {


>  14  drivers/i2c/i2c-core.c:269:20: warning: 'i2c_acpi_add_device' 
> defined but not used [-Wunused-function]

This was the result of an incomplete merge conflict resolution in linux-next,
hopefully to be resolved soon.

>   6  arch/arm64/configs/defconfig:352:warning: override: reassigning to 
> symbol PWM

I have to look into this.

>   4  WARNING: modpost: missing MODULE_LICENSE() in 
> drivers/dma/xilinx/zynqmp_dma.o

I have not seen this one before, but it should be obvious, Kedareswara rao 
Appana
just submitted the new driver recently and can probably send a fix.

>   3  drivers/misc/lkdtm_core.c:97:22: warning: 'jp_shrink_inactive_list' 
> defined but not used [-Wunused-function]
>   3  drivers/misc/lkdtm_core.c:89:13: warning: 'jp_ll_rw_block' defined 
> but not used [-Wunused-function]
>   3  drivers/misc/lkdtm_core.c:83:13: warning: 'jp_tasklet_action' 
> defined but not used [-Wunused-function]
>   3  drivers/misc/lkdtm_core.c:75:20: warning: 'jp_handle_irq_event' 
> defined but not used [-Wunused-function]
>   3  drivers/misc/lkdtm_core.c:68:21: warning: 'jp_do_irq' defined but 
> not used [-Wunused-function]
>   3  drivers/misc/lkdtm_core.c:340:16: warning: 'lkdtm_debugfs_entry' 
> defined but not used [-Wunused-function]
>   3  drivers/misc/lkdtm_core.c:114:12: warning: 'jp_scsi_dispatch_cmd' 
> defined but not used [-Wunused-function]
>   3  drivers/misc/lkdtm_core.c:106:12: warning: 'jp_hrtimer_start' 
> defined but not used [-Wunused-function]

This showed up today, and I sent a patch.

>   2  net/bluetooth/6lowpan.c:608:570: warning: 'addr_type' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]

I assume this is the result of using an older compiler, I haven't looked at the
details. Olof's build bot doesn't have it.

>   2  lib/test_hash.c:234:7: warning: "HAVE_ARCH_HASH_64" is not defined 
> [-Wundef]
>   2  lib/test_hash.c:229:7: warning: "HAVE_ARCH_HASH_32" is not defined 
> [-Wundef]
>   2  lib/test_hash.c:224:7: warning: "HAVE_ARCH__HASH_32" is not defined 
> [-Wundef]
>   2  lib/test_hash.c:146:2: warning: missing braces around initializer 
> [-Wmissing-braces]
>   2  lib/test_hash.c:146:2: warning: (near initialization for 
> 'hash_or[0]') [-Wmissing-braces]

These are definitely coming from an 

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Shuah Khan]

On 07/15/2016 10:26 AM, Javier Martinez Canillas wrote:
> The buffer planes' dma-buf are currently mapped when buffers are queued
> from userspace but it's more appropriate to do the mapping when buffers
> are queued in the driver since that's when the actual DMA operation are
> going to happen.
> 
> Suggested-by: Nicolas Dufresne 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> Hello,
> 
> A side effect of this change is that if the dmabuf map fails for some
> reasons (i.e: a driver using the DMA contig memory allocator but CMA
> not being enabled), the fail will no longer happen on VIDIOC_QBUF but
> later (i.e: in VIDIOC_STREAMON).
> 
> I don't know if that's an issue though but I think is worth mentioning.

How does this change impact the user applications.? This changes
the behavior and user applications now get dmabuf map error at a
later stage in the call sequence.

The change itself looks consistent with the change described.

-- Shuah

> 
> Best regards,
> Javier
> 
>  drivers/media/v4l2-core/videobuf2-core.c | 88 
> 
>  1 file changed, 54 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index ca8ffeb56d72..3fdf882bf279 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -186,7 +186,7 @@ module_param(debug, int, 0644);
>  })
>  
>  static void __vb2_queue_cancel(struct vb2_queue *q);
> -static void __enqueue_in_driver(struct vb2_buffer *vb);
> +static int __enqueue_in_driver(struct vb2_buffer *vb);
>  
>  /**
>   * __vb2_buf_mem_alloc() - allocate video memory for the given buffer
> @@ -1271,20 +1271,6 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
> void *pb)
>   vb->planes[plane].mem_priv = mem_priv;
>   }
>  
> - /* TODO: This pins the buffer(s) with  dma_buf_map_attachment()).. but
> -  * really we want to do this just before the DMA, not while queueing
> -  * the buffer(s)..
> -  */
> - for (plane = 0; plane < vb->num_planes; ++plane) {
> - ret = call_memop(vb, map_dmabuf, vb->planes[plane].mem_priv);
> - if (ret) {
> - dprintk(1, "failed to map dmabuf for plane %d\n",
> - plane);
> - goto err;
> - }
> - vb->planes[plane].dbuf_mapped = 1;
> - }
> -
>   /*
>* Now that everything is in order, copy relevant information
>* provided by userspace.
> @@ -1296,51 +1282,79 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
> void *pb)
>   vb->planes[plane].data_offset = planes[plane].data_offset;
>   }
>  
> - if (reacquired) {
> - /*
> -  * Call driver-specific initialization on the newly acquired 
> buffer,
> -  * if provided.
> -  */
> - ret = call_vb_qop(vb, buf_init, vb);
> + return 0;
> +err:
> + /* In case of errors, release planes that were already acquired */
> + __vb2_buf_dmabuf_put(vb);
> +
> + return ret;
> +}
> +
> +/**
> + * __buf_map_dmabuf() - map dmabuf for buffer planes
> + */
> +static int __buf_map_dmabuf(struct vb2_buffer *vb)
> +{
> + int ret;
> + unsigned int plane;
> +
> + for (plane = 0; plane < vb->num_planes; ++plane) {
> + ret = call_memop(vb, map_dmabuf, vb->planes[plane].mem_priv);
>   if (ret) {
> - dprintk(1, "buffer initialization failed\n");
> - goto err;
> + dprintk(1, "failed to map dmabuf for plane %d\n",
> + plane);
> + return ret;
>   }
> + vb->planes[plane].dbuf_mapped = 1;
> + }
> +
> + /*
> +  * Call driver-specific initialization on the newly
> +  * acquired buffer, if provided.
> +  */
> + ret = call_vb_qop(vb, buf_init, vb);
> + if (ret) {
> + dprintk(1, "buffer initialization failed\n");
> + return ret;
>   }
>  
>   ret = call_vb_qop(vb, buf_prepare, vb);
>   if (ret) {
>   dprintk(1, "buffer preparation failed\n");
>   call_void_vb_qop(vb, buf_cleanup, vb);
> - goto err;
> + return ret;
>   }
>  
>   return 0;
> -err:
> - /* In case of errors, release planes that were already acquired */
> - __vb2_buf_dmabuf_put(vb);
> -
> - return ret;
>  }
>  
>  /**
>   * __enqueue_in_driver() - enqueue a vb2_buffer in driver for processing
>   */
> -static void __enqueue_in_driver(struct vb2_buffer *vb)
> +static int __enqueue_in_driver(struct vb2_buffer *vb)
>  {
>   struct vb2_queue *q = vb->vb2_queue;
>   unsigned int plane;
> + int ret;
>  
>   vb->state = VB2_BUF_STATE_ACTIVE;
>   atomic_inc(>owned_by_drv_count);
>  
>   

[linuxtv-media:master 478/479] drivers/media/usb/airspy/airspy.c:1084:1: warning: label 'err_unregister_v4l2_dev' defined but not used

[kbuild test robot]

tree:   git://linuxtv.org/media_tree.git master
head:   eca2d34b9d2ce70165a50510659838e28ca22742
commit: 785ef73dba6e9fefd2e5dd24546e0efa8698e5cd [478/479] [media] airspy: fix 
error logic during device register
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
git checkout 785ef73dba6e9fefd2e5dd24546e0efa8698e5cd
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/media/usb/airspy/airspy.c: In function 'airspy_probe':
>> drivers/media/usb/airspy/airspy.c:1084:1: warning: label 
>> 'err_unregister_v4l2_dev' defined but not used [-Wunused-label]
err_unregister_v4l2_dev:
^~~

vim +/err_unregister_v4l2_dev +1084 drivers/media/usb/airspy/airspy.c

634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1068s->vdev.v4l2_dev = >v4l2_dev;
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1069s->vdev.lock = >v4l2_lock;
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1070  
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1071ret = video_register_device(>vdev, VFL_TYPE_SDR, -1);
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1072if (ret) {
617123ae3 drivers/media/usb/airspy/airspy.c Antti Palosaari 2014-08-24  
1073dev_err(s->dev, "Failed to register as video device (%d)\n",
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1074ret);
785ef73db drivers/media/usb/airspy/airspy.c James Patrick-Evans 2016-07-15  
1075goto err_free_controls;
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1076}
617123ae3 drivers/media/usb/airspy/airspy.c Antti Palosaari 2014-08-24  
1077dev_info(s->dev, "Registered as %s\n",
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1078video_device_node_name(>vdev));
617123ae3 drivers/media/usb/airspy/airspy.c Antti Palosaari 2014-08-24  
1079dev_notice(s->dev, "SDR API is still slightly experimental and 
functionality changes may follow\n");
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1080return 0;
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1081  
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1082  err_free_controls:
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1083v4l2_ctrl_handler_free(>hdl);
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27 
@1084  err_unregister_v4l2_dev:
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1085v4l2_device_unregister(>v4l2_dev);
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1086  err_free_mem:
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1087kfree(s);
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1088return ret;
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1089  }
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1090  
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1091  /* USB device ID list */
634fe5033 drivers/staging/media/airspy/airspy.c Antti Palosaari 2014-06-27  
1092  static struct usb_device_id airspy_id_table[] = {

:: The code at line 1084 was first introduced by commit
:: 634fe5033951b80ef4b98d8f047cb1083d29170d [media] airspy: AirSpy SDR 
driver

:: TO: Antti Palosaari 
:: CC: Mauro Carvalho Chehab 

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


.config.gz
Description: Binary data

Re: [PATCH 1/1] subsystem:linux-media CVE-2016-5400

[Kees Cook]

[fixing Mauro's email...]

On Fri, Jul 15, 2016 at 11:52 AM, Kees Cook  wrote:
> On Fri, Jul 15, 2016 at 8:40 AM, James Patrick-Evans  wrote:
>> This patch addresses CVE-2016-5400, a local DOS vulnerability caused by a
>> memory leak in the airspy usb device driver. The vulnerability is triggered
>> when more than 64 usb devices register with v4l2 of type VFL_TYPE_SDR or
>> VFL_TYPE_SUBDEV.A badusb device can emulate 64 of these devices then through
>> continual emulated connect/disconnect of the 65th device, cause the kernel
>> to run out of RAM and crash the kernel. The vulnerability exists in kernel
>> versions from 3.17 to current 4.7.
>> The memory leak is caused by the probe function of the airspy driver
>> mishandeling errors and not freeing the corresponding control structures
>> when an error occours registering the device to v4l2 core.
>
> Thanks for getting this fixed!
>
>> Signed-off-by: James Patrick-Evans 
>
> Reviewed-by: Kees Cook 
>
>> ---
>>  drivers/media/usb/airspy/airspy.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/usb/airspy/airspy.c
>> b/drivers/media/usb/airspy/airspy.c
>> index 87c1293..6c3ac8b 100644
>> --- a/drivers/media/usb/airspy/airspy.c
>> +++ b/drivers/media/usb/airspy/airspy.c
>> @@ -1072,7 +1072,7 @@ static int airspy_probe(struct usb_interface *intf,
>> if (ret) {
>> dev_err(s->dev, "Failed to register as video device (%d)\n",
>> ret);
>> -   goto err_unregister_v4l2_dev;
>> +   goto err_free_controls;
>> }
>> dev_info(s->dev, "Registered as %s\n",
>> video_device_node_name(>vdev));
>> --
>> 1.9.1
>>
>
> -Kees
>
> --
> Kees Cook
> Brillo & Chrome OS Security



-- 
Kees Cook
Brillo & Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] subsystem:linux-media CVE-2016-5400

[Kees Cook]

On Fri, Jul 15, 2016 at 8:40 AM, James Patrick-Evans  wrote:
> This patch addresses CVE-2016-5400, a local DOS vulnerability caused by a
> memory leak in the airspy usb device driver. The vulnerability is triggered
> when more than 64 usb devices register with v4l2 of type VFL_TYPE_SDR or
> VFL_TYPE_SUBDEV.A badusb device can emulate 64 of these devices then through
> continual emulated connect/disconnect of the 65th device, cause the kernel
> to run out of RAM and crash the kernel. The vulnerability exists in kernel
> versions from 3.17 to current 4.7.
> The memory leak is caused by the probe function of the airspy driver
> mishandeling errors and not freeing the corresponding control structures
> when an error occours registering the device to v4l2 core.

Thanks for getting this fixed!

> Signed-off-by: James Patrick-Evans 

Reviewed-by: Kees Cook 

> ---
>  drivers/media/usb/airspy/airspy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/airspy/airspy.c
> b/drivers/media/usb/airspy/airspy.c
> index 87c1293..6c3ac8b 100644
> --- a/drivers/media/usb/airspy/airspy.c
> +++ b/drivers/media/usb/airspy/airspy.c
> @@ -1072,7 +1072,7 @@ static int airspy_probe(struct usb_interface *intf,
> if (ret) {
> dev_err(s->dev, "Failed to register as video device (%d)\n",
> ret);
> -   goto err_unregister_v4l2_dev;
> +   goto err_free_controls;
> }
> dev_info(s->dev, "Registered as %s\n",
> video_device_node_name(>vdev));
> --
> 1.9.1
>

-Kees

-- 
Kees Cook
Brillo & Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/6] [media] vivid: Add support for HSV formats

[Hans Verkuil]

On 07/15/2016 06:13 PM, Ricardo Ribalda Delgado wrote:
> This patch adds support for V4L2_PIX_FMT_HSV24 and V4L2_PIX_FMT_HSV32.
> 
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 94 
> +++--
>  drivers/media/platform/vivid/vivid-vid-common.c | 14 
>  include/media/v4l2-tpg.h|  1 +
>  3 files changed, 105 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
> b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> index acf0e6854832..85b9c1925dd9 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -318,6 +318,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   tpg->hmask[0] = ~1;
>   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>   break;
> + case V4L2_PIX_FMT_HSV24:
> + case V4L2_PIX_FMT_HSV32:
> + tpg->color_representation = TGP_COLOR_REPRESENTATION_HSV;
> + break;
>   default:
>   return false;
>   }
> @@ -351,6 +355,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   break;
>   case V4L2_PIX_FMT_RGB24:
>   case V4L2_PIX_FMT_BGR24:
> + case V4L2_PIX_FMT_HSV24:
>   tpg->twopixelsize[0] = 2 * 3;
>   break;
>   case V4L2_PIX_FMT_BGR666:
> @@ -361,6 +366,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   case V4L2_PIX_FMT_ARGB32:
>   case V4L2_PIX_FMT_ABGR32:
>   case V4L2_PIX_FMT_YUV32:
> + case V4L2_PIX_FMT_HSV32:
>   tpg->twopixelsize[0] = 2 * 4;
>   break;
>   case V4L2_PIX_FMT_NV12:
> @@ -408,6 +414,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   tpg->twopixelsize[1] = 4;
>   break;
>   }
> +
>   return true;
>  }
>  EXPORT_SYMBOL_GPL(tpg_s_fourcc);
> @@ -490,6 +497,64 @@ static inline int linear_to_rec709(int v)
>   return tpg_linear_to_rec709[v];
>  }
>  
> +static void color_to_hsv(struct tpg_data *tpg, int r, int g, int b,
> +int *h, int *s, int *v)
> +{
> + int max_rgb, min_rgb, diff_rgb;
> + int aux;
> + int third;
> +
> + r >>= 4;
> + g >>= 4;
> + b >>= 4;
> +
> + /*V*/

Please add a space after /* and before */.
I also think it is better to write Value, Saturation, Hue instead of
V, S, H.

> + max_rgb = max3(r, g, b);
> + *v = max_rgb;
> + if (!max_rgb) {
> + *h = 0;
> + *s = 0;
> + return;
> + }
> +
> + /*S*/
> + min_rgb = min3(r, g, b);
> + diff_rgb = max_rgb - min_rgb;
> + aux = 255 * diff_rgb;
> + aux += max_rgb / 2;
> + aux /= max_rgb;
> + *s = aux;
> + if (!aux) {
> + *h = 0;
> + return;
> + }
> +
> + /*H*/
> + if (max_rgb == r) {
> + aux =  g - b;
> + third = 0;
> + } else if (max_rgb == g) {
> + aux =  b - r;
> + third = 60;
> + } else {
> + aux =  r - g;
> + third = 120;
> + }
> +
> + aux *= 30;
> + aux += diff_rgb / 2;
> + aux /= diff_rgb;
> + aux += third;
> +
> + /*Clamp H*/
> + if (aux < 0)
> + aux += 180;
> + else if (aux > 180)
> + aux -= 180;
> + *h = aux;
> +
> +}
> +
>  static void rgb2ycbcr(const int m[3][3], int r, int g, int b,
>   int y_offset, int *y, int *cb, int *cr)
>  {
> @@ -829,7 +894,19 @@ static void precalculate_color(struct tpg_data *tpg, int 
> k)
>   ycbcr_to_color(tpg, y, cb, cr, , , );
>   }
>  
> - if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
> + switch (tpg->color_representation) {
> + case TGP_COLOR_REPRESENTATION_HSV:
> + {
> + int h, s, v;
> +
> + color_to_hsv(tpg, r, g, b, , , );
> + tpg->colors[k][0] = h;
> + tpg->colors[k][1] = s;
> + tpg->colors[k][2] = v;

Would quantization (limited/full range) be relevant here? I don't know if 
limited
range would make sense (or what those limits would be).

Regards,

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

Re: [PATCH v2 4/6] [media] vivid: code refactor for color representation

[Hans Verkuil]

On 07/15/2016 06:13 PM, Ricardo Ribalda Delgado wrote:
> Replace is_yuv with color_representation. Which can be used by HSV
> formats.
> 
> This change should ease the review of the following patches.
> 
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 44 ++---
>  drivers/media/platform/vivid/vivid-core.h   |  2 +-
>  drivers/media/platform/vivid/vivid-vid-common.c | 52 
> -
>  include/media/v4l2-tpg.h|  7 +++-
>  4 files changed, 63 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
> b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> index cf1dadd0be9e..acf0e6854832 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -1842,7 +1842,9 @@ static void tpg_recalc(struct tpg_data *tpg)
>  
>   if (tpg->quantization == V4L2_QUANTIZATION_DEFAULT)
>   tpg->real_quantization =
> - V4L2_MAP_QUANTIZATION_DEFAULT(!tpg->is_yuv,
> + V4L2_MAP_QUANTIZATION_DEFAULT(
> + tpg->color_representation ==
> + TGP_COLOR_REPRESENTATION_RGB,

This should be != TGP_COLOR_REPRESENTATION_YUV.

Otherwise HSV would map to limited range by default, which is probably wrong.

Regards,

Hans

>   tpg->colorspace, tpg->real_ycbcr_enc);
>  
>   tpg_precalculate_colors(tpg);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/6] [media] vivid: code refactor for color representation

[Hans Verkuil]

On 07/15/2016 07:58 PM, Hans Verkuil wrote:
> On 07/15/2016 06:13 PM, Ricardo Ribalda Delgado wrote:
>> Replace is_yuv with color_representation. Which can be used by HSV
>> formats.
>>
>> This change should ease the review of the following patches.
> 
> It's a bit of a mouthful. How about calling this color_enc and TPG_COLOR_ENC_?
> (i.e. color encoding).
> 
> I would also like to have a TPG_COLOR_ENC_LUMA for the greyscale formats.
> This patch is a good opportunity to add that.

Also note that docs-next is older than the master branch w.r.t. the tpg.
You're missing two is_yuv checks is docs-next that are present in the master.

Also:

>> +static const char *tpg_color_representation_str(enum 
>> tgp_color_representation
>> + color_representation)
>> +{
>> +switch (color_representation) {
>> +

Drop empty line.

>> +case TGP_COLOR_REPRESENTATION_YUV:
>> +return "YCbCr";
>> +case TGP_COLOR_REPRESENTATION_RGB:
>> +default:
>> +return "RGB";
>> +
>> +}
>> +}

Regards,

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

Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

[Laurent Pinchart]

Hi Ricardo,

Thank you for the patch.

On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
> Describe the HSV formats
> 
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  Documentation/media/uapi/v4l/hsv-formats.rst   |  19 ++
>  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 ++
>  Documentation/media/uapi/v4l/pixfmt.rst|   1 +
>  Documentation/media/uapi/v4l/v4l2.rst  |   5 +
>  4 files changed, 278 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> 
> diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
> b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
> index ..f0f2615eaa95
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
> @@ -0,0 +1,19 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _hsv-formats:
> +
> +***
> +HSV Formats
> +***
> +
> +These formats store the color information of the image
> +in a geometrical representation. The colors are mapped into a
> +cylinder, where the angle is the HUE, the height is the VALUE
> +and the distance to the center is the SATURATION. This is a very
> +useful format for image segmentation algorithms.
> +
> +
> +.. toctree::
> +:maxdepth: 1
> +
> +pixfmt-packed-hsv
> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode 100644
> index ..b297aa4f7ba6
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> @@ -0,0 +1,253 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _packed-hsv:
> +
> +**
> +Packed HSV formats
> +**
> +
> +*man Packed HSV formats(2)*
> +
> +Packed HSV formats
> +
> +
> +Description
> +===
> +
> +The HUE (h) is meassured in degrees, one LSB represents two degrees.

Is this common ? I have a device that can handle HSV data, I need to check how 
it maps the hue values to binary, but I'm pretty sure they cover the full 
0-255 range. We would then have to support the two formats. Separate 4CCs are 
an option, but reporting the range separately (possibly through the colorspace 
API) might be better. Any thought on that ?

> +The SATURATION (s) and the VALUE (v) are measured in percentage of the
> +cylinder: 0 being the smallest value and 255 the maximum.
> +
> +
> +The values are packed in 24 or 32 bit formats.
> +
> +
> +.. flat-table:: Packed HSV Image Formats
> +:header-rows:  2
> +:stub-columns: 0
> +
> +
> +-  .. row 1
> +
> +   -  Identifier
> +
> +   -  Code
> +
> +   -
> +   -  :cspan:`7` Byte 0 in memory
> +

Do we really need all those blank lines ?

[snip]

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 4/6] [media] vivid: code refactor for color representation

[Hans Verkuil]

On 07/15/2016 06:13 PM, Ricardo Ribalda Delgado wrote:
> Replace is_yuv with color_representation. Which can be used by HSV
> formats.
> 
> This change should ease the review of the following patches.

It's a bit of a mouthful. How about calling this color_enc and TPG_COLOR_ENC_?
(i.e. color encoding).

I would also like to have a TPG_COLOR_ENC_LUMA for the greyscale formats.
This patch is a good opportunity to add that.

Regards,

Hans

> 
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 44 ++---
>  drivers/media/platform/vivid/vivid-core.h   |  2 +-
>  drivers/media/platform/vivid/vivid-vid-common.c | 52 
> -
>  include/media/v4l2-tpg.h|  7 +++-
>  4 files changed, 63 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
> b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> index cf1dadd0be9e..acf0e6854832 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -237,13 +237,13 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   case V4L2_PIX_FMT_GREY:
>   case V4L2_PIX_FMT_Y16:
>   case V4L2_PIX_FMT_Y16_BE:
> - tpg->is_yuv = false;
> + tpg->color_representation = TGP_COLOR_REPRESENTATION_RGB;
>   break;
>   case V4L2_PIX_FMT_YUV444:
>   case V4L2_PIX_FMT_YUV555:
>   case V4L2_PIX_FMT_YUV565:
>   case V4L2_PIX_FMT_YUV32:
> - tpg->is_yuv = true;
> + tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>   break;
>   case V4L2_PIX_FMT_YUV420M:
>   case V4L2_PIX_FMT_YVU420M:
> @@ -256,7 +256,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   tpg->hdownsampling[1] = 2;
>   tpg->hdownsampling[2] = 2;
>   tpg->planes = 3;
> - tpg->is_yuv = true;
> + tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>   break;
>   case V4L2_PIX_FMT_YUV422M:
>   case V4L2_PIX_FMT_YVU422M:
> @@ -268,7 +268,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   tpg->hdownsampling[1] = 2;
>   tpg->hdownsampling[2] = 2;
>   tpg->planes = 3;
> - tpg->is_yuv = true;
> + tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>   break;
>   case V4L2_PIX_FMT_NV16M:
>   case V4L2_PIX_FMT_NV61M:
> @@ -280,7 +280,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   tpg->hdownsampling[1] = 1;
>   tpg->hmask[1] = ~1;
>   tpg->planes = 2;
> - tpg->is_yuv = true;
> + tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>   break;
>   case V4L2_PIX_FMT_NV12M:
>   case V4L2_PIX_FMT_NV21M:
> @@ -292,7 +292,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   tpg->hdownsampling[1] = 1;
>   tpg->hmask[1] = ~1;
>   tpg->planes = 2;
> - tpg->is_yuv = true;
> + tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>   break;
>   case V4L2_PIX_FMT_YUV444M:
>   case V4L2_PIX_FMT_YVU444M:
> @@ -302,21 +302,21 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>   tpg->vdownsampling[2] = 1;
>   tpg->hdownsampling[1] = 1;
>   tpg->hdownsampling[2] = 1;
> - tpg->is_yuv = true;
> + tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>   break;
>   case V4L2_PIX_FMT_NV24:
>   case V4L2_PIX_FMT_NV42:
>   tpg->vdownsampling[1] = 1;
>   tpg->hdownsampling[1] = 1;
>   tpg->planes = 2;
> - tpg->is_yuv = true;
> + tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>   break;
>   case V4L2_PIX_FMT_YUYV:
>   case V4L2_PIX_FMT_UYVY:
>   case V4L2_PIX_FMT_YVYU:
>   case V4L2_PIX_FMT_VYUY:
>   tpg->hmask[0] = ~1;
> - tpg->is_yuv = true;
> + tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>   break;
>   default:
>   return false;
> @@ -820,7 +820,7 @@ static void precalculate_color(struct tpg_data *tpg, int 
> k)
>  
>   cb = (128 << 4) + (tmp_cb * tpg->contrast * tpg->saturation) / 
> (128 * 128);
>   cr = (128 << 4) + (tmp_cr * tpg->contrast * tpg->saturation) / 
> (128 * 128);
> - if (tpg->is_yuv) {
> + if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
>   tpg->colors[k][0] = clamp(y >> 4, 1, 254);
>   tpg->colors[k][1] = clamp(cb >> 4, 1, 254);
>   tpg->colors[k][2] = clamp(cr >> 4, 1, 254);
> @@ -829,7 +829,7 @@ static void precalculate_color(struct 

Re: [PATCH] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder

[Hans Verkuil]

On 07/14/2016 08:27 AM, tiffany lin wrote:
> Hi Hans,
> 
> 
> On Mon, 2016-07-11 at 06:32 +0200, Hans Verkuil wrote:
>> Hi Tiffany,
>>
>> My apologies for the delay, but here is my review at last:
>>
>> On 05/30/2016 09:52 AM, Tiffany Lin wrote:
>>> This patch add g/s_selection support for MT8173
>>>
>>> Signed-off-by: Tiffany Lin 
>>> ---
>>>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c |   74 
>>> 
>>>  1 file changed, 74 insertions(+)
>>>
>>> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c 
>>> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
>>> index 6e72d73..23ef9a1 100644
>>> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
>>> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
>>> @@ -630,6 +630,77 @@ static int vidioc_try_fmt_vid_out_mplane(struct file 
>>> *file, void *priv,
>>> return vidioc_try_fmt(f, fmt);
>>>  }
>>>  
>>> +static int vidioc_venc_g_selection(struct file *file, void *priv,
>>> +struct v4l2_selection *s)
>>> +{
>>> +   struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +   struct mtk_q_data *q_data;
>>> +
>>> +   /* crop means compose for output devices */
>>> +   switch (s->target) {
>>> +   case V4L2_SEL_TGT_CROP_DEFAULT:
>>> +   case V4L2_SEL_TGT_CROP_BOUNDS:
>>> +   case V4L2_SEL_TGT_CROP:
>>> +   case V4L2_SEL_TGT_COMPOSE_DEFAULT:
>>> +   case V4L2_SEL_TGT_COMPOSE_BOUNDS:
>>> +   case V4L2_SEL_TGT_COMPOSE:
>>> +   if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
>>> +   mtk_v4l2_err("Invalid s->type = %d", s->type);
>>> +   return -EINVAL;
>>> +   }
>>> +   break;
>>> +   default:
>>> +   mtk_v4l2_err("Invalid s->target = %d", s->target);
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   q_data = mtk_venc_get_q_data(ctx, s->type);
>>> +   if (!q_data)
>>> +   return -EINVAL;
>>> +
>>> +   s->r.top = 0;
>>> +   s->r.left = 0;
>>> +   s->r.width = q_data->visible_width;
>>> +   s->r.height = q_data->visible_height;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static int vidioc_venc_s_selection(struct file *file, void *priv,
>>> +struct v4l2_selection *s)
>>> +{
>>> +   struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +   struct mtk_q_data *q_data;
>>> +
>>> +   switch (s->target) {
>>> +   case V4L2_SEL_TGT_CROP_DEFAULT:
>>> +   case V4L2_SEL_TGT_CROP_BOUNDS:
>>> +   case V4L2_SEL_TGT_CROP:
>>> +   case V4L2_SEL_TGT_COMPOSE_DEFAULT:
>>> +   case V4L2_SEL_TGT_COMPOSE_BOUNDS:
>>> +   case V4L2_SEL_TGT_COMPOSE:
>>> +   if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
>>> +   mtk_v4l2_err("Invalid s->type = %d", s->type);
>>> +   return -EINVAL;
>>> +   }
>>> +   break;
>>> +   default:
>>> +   mtk_v4l2_err("Invalid s->target = %d", s->target);
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   q_data = mtk_venc_get_q_data(ctx, s->type);
>>> +   if (!q_data)
>>> +   return -EINVAL;
>>> +
>>> +   s->r.top = 0;
>>> +   s->r.left = 0;
>>> +   q_data->visible_width = s->r.width;
>>> +   q_data->visible_height = s->r.height;
>>
>> This makes no sense.
>>
>> See this page:
>>
>> https://hverkuil.home.xs4all.nl/spec/media.html#selection-api
>>
>> For the video output direction (memory -> HW encoder) the data source is
>> the memory, the data sink is the HW encoder. For the video capture direction
>> (HW encoder -> memory) the data source is the HW encoder and the data sink
>> is the memory.
>>
>> Usually for m2m devices the video output direction may support cropping and
>> the video capture direction may support composing.
>>
>> It's not clear what you intend here, especially since you set left and right
>> to 0. That's not what the selection operation is supposed to do.
>>
> I am confused about about g/s_selection.
> If application want to configure encode area and crop meta-data, it
> should set crop info to OUTPUT queue, is that right?
> if user space still use g/s_crop ioctl, in 
> v4l_g_crop and v4l_s_crop, it set target to V4L2_SEL_TGT_COMPOSE_ACTIVE
> when buf type is V4L2_TYPE_IS_OUTPUT.
> 
> It looks like when work with g/s_crop ioctl, command set to OUTPUT
> buffer will use target V4L2_SEL_TGT_COMPOSE_ACTIVE.

Correct. The semantics of g/s_crop for output devices is really weird
and g/s_crop is generally useless for mem2mem devices.

You should completely ignore the old g/s_crop and only look at g/s_selection.

> When work with g/s_selection ictol, command set to OUTPUT buffer will
> use V4L2_SEL_TGT_CROP_ACTIVE.
> Is this correct behavior?

Yes. What this means is that userspace has to use g/s_selection for
mem2mem devices since g/s_crop changes the wrong thing: compose instead
of crop for OUTPUT and crop instead of compose for CAPTURE.

The g/s_selection ioctls were added to solve this problem with g/s_crop.
It always confuses people and it was due to a lack of foresight when the

Re: DRM device memory writeback (Mali-DP)

[Eric Anholt]

Ville Syrjälä  writes:

> On Fri, Jul 15, 2016 at 10:09:19AM +0100, Brian Starkey wrote:
>> Hi Daniel,
>> 
>> Thanks for taking a look.
>> 
>> (+Cc Laurent)
>> 
>> On Fri, Jul 15, 2016 at 09:33:34AM +0200, Daniel Vetter wrote:
>> >On Thu, Jul 14, 2016 at 06:03:40PM +0100, Brian Starkey wrote:
>> >> Hi,
>> >>
>> >> The Mali-DP display processors have a memory-writeback engine which
>> >> can write the result of the composition (CRTC output) to a memory
>> >> buffer in a variety of formats.
>> >>
>> >> We're looking for feedback/suggestions on how to expose this in the
>> >> mali-dp DRM kernel driver - possibly via V4L2.
>> >>
>> >> We've got a few use cases where writeback is useful:
>> >>- testing, to check the displayed image
>> >
>> >This might or might not need a separate interface. There are efforts to
>> >make the intel kms validation tests in i-g-t generic (well under way
>> >already), and part of that is creating a generic infrastructure to capture
>> >display CRCs for functional tests (still in progress).
>> >
>> >But it might be better if userspace abstracts between full readback and
>> >display CRC, assuming we can make full writeback cross-vendor enough for
>> >that use-case.
>> >
>> 
>> I'd lean towards the userspace abstraction.
>> Encumbering a simple CRC interface with all the complexity of
>> full-writeback (size, scaling, pixel format, multi-planar etc.) sounds
>> a bit unnecessary.
>> 
>> Of course, if v4l2 isn't going to be the cross-vendor full-writeback
>> implementation, then we need to be aiming to use whatever _is_ in
>> the mali-dp driver.
>> 
>> >>- screen recording
>> >>- wireless display (e.g. Miracast)
>> >>- dual-display clone mode
>> >>- memory-to-memory composition
>> >> Note that the HW is capable of writing one of the input planes instead
>> >> of the CRTC output, but we've no good use-case for wanting to expose
>> >> that.
>> >>
>> >> In our Android ADF driver[1] we exposed the memory write engine as
>> >> part of the ADF device using ADF's "MEMORY" interface type. DRM/KMS
>> >> doesn't have any similar support for memory output from CRTCs, but we
>> >> want to expose the functionality in the mainline Mali-DP DRM driver.
>> >>
>> >> A previous discussion on the topic went towards exposing the
>> >> memory-write engine via V4L2[2].
>> >>
>> >> I'm thinking to userspace this would look like two distinct devices:
>> >>- A DRM KMS display controller.
>> >>- A V4L2 video source.
>> >> They'd both exist in the same kernel driver.
>> >> A V4L2 client can queue up (CAPTURE) buffers in the normal way, and
>> >> the DRM driver would see if there's a buffer to dequeue every time a
>> >> new modeset is received via the DRM API - if so, it can configure the
>> >> HW to dump into it (one-shot operation).
>> >>
>> >> An implication of this is that if the screen is actively displaying a
>> >> static scene and the V4L2 client queues up a buffer, it won't get
>> >> filled until the DRM scene changes. This seems best, otherwise the
>> >> V4L2 driver has to change the HW configuration out-of-band from the
>> >> DRM device which sounds horribly racy.
>> >>
>> >> One further complication is scaling. Our HW has a scaler which can
>> >> tasked with either scaling an input plane or the buffer being written
>> >> to memory, but not both at the same time. This means we need to
>> >> arbitrate the scaler between the DRM device (scaling input planes) and
>> >> the V4L2 device (scaling output buffers).
>> >>
>> >> I think the simplest approach here is to allow V4L2 to "claim" the
>> >> scaler by setting the image size (VIDIOC_S_FMT) to something other
>> >> than the CRTC's current resolution. After that, any attempt to use the
>> >> scaler on an input plane via DRM should fail atomic_check().
>> >
>> >That's perfectly fine atomic_check behaviour. Only trouble is that the v4l
>> >locking must integrate into the drm locking, but that should be doable.
>> >Worst case you must shadow all v4l locks with a wait/wound
>> >drm_modeset_lock to avoid deadlocks (since you could try to grab locks
>> >from either end).
>> >
>> 
>> Yes, I haven't looked at the details of the locking but I'm hoping
>> it's manageable.
>> 
>> >> If the V4L2 client goes away or sets the image size to the CRTC's
>> >> native resolution, then the DRM device is allowed to use the scaler.
>> >> I don't know if/how the DRM device should communicate to userspace
>> >> that the scaler is or isn't available for use.
>> >>
>> >> Any thoughts on this approach?
>> >> Is it acceptable to both V4L2 and DRM folks?
>> >
>> >For streaming a V4L2 capture device seems like the right interface. But if
>> >you want to use writeback in your compositor you must know which atomic
>> >kms update results in which frame, since if you don't you can't use that
>> >composited buffer for the next frame reliable.
>> >
>> >For that case I think a drm-only solution would be better, to make sure
>> >you can 

Re: [RFT PATCH v2] [media] exynos4-is: Fix fimc_is_parse_sensor_config() nodes handling

[Nicolas Dufresne]

Le vendredi 15 juillet 2016 à 12:53 -0400, Nicolas Dufresne a écrit :
> Le jeudi 21 avril 2016 à 09:21 -0400, Javier Martinez Canillas a
> écrit :
> > Hello Sylwester,
> > 
> > On 03/23/2016 08:41 PM, Javier Martinez Canillas wrote:
> > > The same struct device_node * is used for looking up the I2C
> > > sensor, OF
> > > graph endpoint and port. So the reference count is incremented
> > > but
> > > not
> > > decremented for the endpoint and port nodes.
> > > 
> > > Fix this by having separate pointers for each node looked up.
> > > 
> > > Signed-off-by: Javier Martinez Canillas 
> > > 
> > 
> > Any comments about this patch?
> 
> Tested-by: Nicolas Dufresne 

There a typo here.

Tested-by: Nicolas Dufresne 

> 
> Note: I could not verify that leak is gone, but I could verify that
> this driver is still working properly after the change.
> 
> > 
> > Best regards,

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

Re: [RFT PATCH v2] [media] exynos4-is: Fix fimc_is_parse_sensor_config() nodes handling

[Nicolas Dufresne]

Le jeudi 21 avril 2016 à 09:21 -0400, Javier Martinez Canillas a
écrit :
> Hello Sylwester,
> 
> On 03/23/2016 08:41 PM, Javier Martinez Canillas wrote:
> > The same struct device_node * is used for looking up the I2C
> > sensor, OF
> > graph endpoint and port. So the reference count is incremented but
> > not
> > decremented for the endpoint and port nodes.
> > 
> > Fix this by having separate pointers for each node looked up.
> > 
> > Signed-off-by: Javier Martinez Canillas 
> > 
> 
> Any comments about this patch?

Tested-by: Nicolas Dufresne 

Note: I could not verify that leak is gone, but I could verify that
this driver is still working properly after the change.

> 
> Best regards,

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

Re: [RFC PATCH] serio: add hangup support

[Dmitry Torokhov]

Hi Hans,

On Fri, Jul 15, 2016 at 01:27:21PM +0200, Hans Verkuil wrote:
> For the upcoming 4.8 kernel I made a driver for the Pulse-Eight USB CEC 
> adapter.
> This is a usb device that shows up as a ttyACM0 device. It requires that you 
> run
> inputattach in order to communicate with it via serio.
> 
> This all works well, but it would be nice to have a udev rule to automatically
> start inputattach. That too works OK, but the problem comes when the USB 
> device
> is unplugged: the tty hangup is never handled by the serio framework so the
> inputattach utility never exits and you have to kill it manually.
> 
> By adding this hangup callback the inputattach utility now exists as soon as I
> unplug the USB device.
> 
> Is this the correct approach?
> 
> BTW, the new driver is found here:
> 
> https://git.linuxtv.org/media_tree.git/tree/drivers/staging/media/pulse8-cec
> 
> Regards,
> 
>   Hans
> 
> Signed-off-by: Hans Verkuil 
> 
> ---
> diff --git a/drivers/input/serio/serport.c b/drivers/input/serio/serport.c
> index 9c927d3..a615846 100644
> --- a/drivers/input/serio/serport.c
> +++ b/drivers/input/serio/serport.c
> @@ -248,6 +248,14 @@ static long serport_ldisc_compat_ioctl(struct tty_struct 
> *tty,
>  }
>  #endif
> 
> +static int serport_ldisc_hangup(struct tty_struct * tty)
> +{
> + struct serport *serport = (struct serport *) tty->disc_data;
> +
> + serport_serio_close(serport->serio);

I see what you mean, but this is not quite correct. I think we should
make serport_serio_close() only reset the SERPORT_ACTIVE flag and have
serport_ldisc_hangup() actually do:

spin_lock_irqsave(>lock, flags);
set_bit(SERPORT_DEAD, >flags);
spin_unlock_irqrestore(>lock, flags);

wake_up_interruptible(>wait);

i.e. if user (via device-driver - input core - evdev - userspace chain)
stops using serio port we should not kill inputattach instance right
then and there, but wait for the serial port device disconnect or
something else killing inputattach.

Vojtech, do you recall any of this code?

Thanks.

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

[PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Javier Martinez Canillas]

The buffer planes' dma-buf are currently mapped when buffers are queued
from userspace but it's more appropriate to do the mapping when buffers
are queued in the driver since that's when the actual DMA operation are
going to happen.

Suggested-by: Nicolas Dufresne 
Signed-off-by: Javier Martinez Canillas 

---

Hello,

A side effect of this change is that if the dmabuf map fails for some
reasons (i.e: a driver using the DMA contig memory allocator but CMA
not being enabled), the fail will no longer happen on VIDIOC_QBUF but
later (i.e: in VIDIOC_STREAMON).

I don't know if that's an issue though but I think is worth mentioning.

Best regards,
Javier

 drivers/media/v4l2-core/videobuf2-core.c | 88 
 1 file changed, 54 insertions(+), 34 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index ca8ffeb56d72..3fdf882bf279 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -186,7 +186,7 @@ module_param(debug, int, 0644);
 })
 
 static void __vb2_queue_cancel(struct vb2_queue *q);
-static void __enqueue_in_driver(struct vb2_buffer *vb);
+static int __enqueue_in_driver(struct vb2_buffer *vb);
 
 /**
  * __vb2_buf_mem_alloc() - allocate video memory for the given buffer
@@ -1271,20 +1271,6 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
void *pb)
vb->planes[plane].mem_priv = mem_priv;
}
 
-   /* TODO: This pins the buffer(s) with  dma_buf_map_attachment()).. but
-* really we want to do this just before the DMA, not while queueing
-* the buffer(s)..
-*/
-   for (plane = 0; plane < vb->num_planes; ++plane) {
-   ret = call_memop(vb, map_dmabuf, vb->planes[plane].mem_priv);
-   if (ret) {
-   dprintk(1, "failed to map dmabuf for plane %d\n",
-   plane);
-   goto err;
-   }
-   vb->planes[plane].dbuf_mapped = 1;
-   }
-
/*
 * Now that everything is in order, copy relevant information
 * provided by userspace.
@@ -1296,51 +1282,79 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
void *pb)
vb->planes[plane].data_offset = planes[plane].data_offset;
}
 
-   if (reacquired) {
-   /*
-* Call driver-specific initialization on the newly acquired 
buffer,
-* if provided.
-*/
-   ret = call_vb_qop(vb, buf_init, vb);
+   return 0;
+err:
+   /* In case of errors, release planes that were already acquired */
+   __vb2_buf_dmabuf_put(vb);
+
+   return ret;
+}
+
+/**
+ * __buf_map_dmabuf() - map dmabuf for buffer planes
+ */
+static int __buf_map_dmabuf(struct vb2_buffer *vb)
+{
+   int ret;
+   unsigned int plane;
+
+   for (plane = 0; plane < vb->num_planes; ++plane) {
+   ret = call_memop(vb, map_dmabuf, vb->planes[plane].mem_priv);
if (ret) {
-   dprintk(1, "buffer initialization failed\n");
-   goto err;
+   dprintk(1, "failed to map dmabuf for plane %d\n",
+   plane);
+   return ret;
}
+   vb->planes[plane].dbuf_mapped = 1;
+   }
+
+   /*
+* Call driver-specific initialization on the newly
+* acquired buffer, if provided.
+*/
+   ret = call_vb_qop(vb, buf_init, vb);
+   if (ret) {
+   dprintk(1, "buffer initialization failed\n");
+   return ret;
}
 
ret = call_vb_qop(vb, buf_prepare, vb);
if (ret) {
dprintk(1, "buffer preparation failed\n");
call_void_vb_qop(vb, buf_cleanup, vb);
-   goto err;
+   return ret;
}
 
return 0;
-err:
-   /* In case of errors, release planes that were already acquired */
-   __vb2_buf_dmabuf_put(vb);
-
-   return ret;
 }
 
 /**
  * __enqueue_in_driver() - enqueue a vb2_buffer in driver for processing
  */
-static void __enqueue_in_driver(struct vb2_buffer *vb)
+static int __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
unsigned int plane;
+   int ret;
 
vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(>owned_by_drv_count);
 
trace_vb2_buf_queue(q, vb);
 
+   if (q->memory == VB2_MEMORY_DMABUF) {
+   ret = __buf_map_dmabuf(vb);
+   if (ret)
+   return ret;
+   }
+
/* sync buffers */
for (plane = 0; plane < vb->num_planes; ++plane)
call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
 
call_void_vb_qop(vb, buf_queue, vb);
+
+   return 0;
 }
 
 static int 

[PATCH v2 1/6] [media] videodev2.h Add HSV formats

[Ricardo Ribalda Delgado]

These formats store the color information of the image
in a geometrical representation. The colors are mapped into a
cylinder, where the angle is the HUE, the height is the VALUE
and the distance to the center is the SATURATION. This is a very
useful format for image segmentation algorithms.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
 include/uapi/linux/videodev2.h   | 4 
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 28e5be2c2eef..4b67ad06efb7 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1238,6 +1238,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_TM6000:   descr = "A/V + VBI Mux Packet"; break;
case V4L2_PIX_FMT_CIT_YYVYUY:   descr = "GSPCA CIT YYVYUY"; break;
case V4L2_PIX_FMT_KONICA420:descr = "GSPCA KONICA420"; break;
+   case V4L2_PIX_FMT_HSV24:descr = "24-bit HSV 8-8-8"; break;
+   case V4L2_PIX_FMT_HSV32:descr = "32-bit XHSV 8-8-8-8"; break;
case V4L2_SDR_FMT_CU8:  descr = "Complex U8"; break;
case V4L2_SDR_FMT_CU16LE:   descr = "Complex U16LE"; break;
case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 724f43e69d03..c7fb760386cf 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -580,6 +580,10 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG.. 
GBGB.. */
 #define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16  BGBG.. 
GRGR.. */
 
+/* HSV formats */
+#define V4L2_PIX_FMT_HSV24 v4l2_fourcc('H', 'S', 'V', '3')
+#define V4L2_PIX_FMT_HSV32 v4l2_fourcc('H', 'S', 'V', '4')
+
 /* compressed formats */
 #define V4L2_PIX_FMT_MJPEGv4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG   
*/
 #define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG 
*/
-- 
2.8.1

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

[PATCH v2 6/6] [media] vivid: Rename variable

[Ricardo Ribalda Delgado]

r_y and g_u now also contain the H and V components on the HSV formats.
Rename the variables to reflect this.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 209 +-
 1 file changed, 105 insertions(+), 104 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 85b9c1925dd9..dba6656082d8 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -1012,7 +1012,7 @@ static void gen_twopix(struct tpg_data *tpg,
 {
unsigned offset = odd * tpg->twopixelsize[0] / 2;
u8 alpha = tpg->alpha_component;
-   u8 r_y, g_u, b_v;
+   u8 r_y_h, g_u_s, b_v;
 
if (tpg->alpha_red_only && color != TPG_COLOR_CSC_RED &&
   color != TPG_COLOR_100_RED &&
@@ -1020,161 +1020,161 @@ static void gen_twopix(struct tpg_data *tpg,
alpha = 0;
if (color == TPG_COLOR_RANDOM)
precalculate_color(tpg, color);
-   r_y = tpg->colors[color][0]; /* R or precalculated Y, H */
-   g_u = tpg->colors[color][1]; /* G or precalculated U, V */
+   r_y_h = tpg->colors[color][0]; /* R or precalculated Y, H */
+   g_u_s = tpg->colors[color][1]; /* G or precalculated U, V */
b_v = tpg->colors[color][2]; /* B or precalculated V */
 
switch (tpg->fourcc) {
case V4L2_PIX_FMT_GREY:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
break;
case V4L2_PIX_FMT_Y16:
/*
-* Ideally both bytes should be set to r_y, but then you won't
+* Ideally both bytes should be set to r_y_h, but then you won't
 * be able to detect endian problems. So keep it 0 except for
-* the corner case where r_y is 0xff so white really will be
+* the corner case where r_y_h is 0xff so white really will be
 * white (0x).
 */
-   buf[0][offset] = r_y == 0xff ? r_y : 0;
-   buf[0][offset+1] = r_y;
+   buf[0][offset] = r_y_h == 0xff ? r_y_h : 0;
+   buf[0][offset+1] = r_y_h;
break;
case V4L2_PIX_FMT_Y16_BE:
/* See comment for V4L2_PIX_FMT_Y16 above */
-   buf[0][offset] = r_y;
-   buf[0][offset+1] = r_y == 0xff ? r_y : 0;
+   buf[0][offset] = r_y_h;
+   buf[0][offset+1] = r_y_h == 0xff ? r_y_h : 0;
break;
case V4L2_PIX_FMT_YUV422M:
case V4L2_PIX_FMT_YUV422P:
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YUV420M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
-   buf[1][0] = (buf[1][0] + g_u) / 2;
+   buf[1][0] = (buf[1][0] + g_u_s) / 2;
buf[2][0] = (buf[2][0] + b_v) / 2;
buf[1][1] = buf[1][0];
buf[2][1] = buf[2][0];
break;
}
-   buf[1][0] = g_u;
+   buf[1][0] = g_u_s;
buf[2][0] = b_v;
break;
case V4L2_PIX_FMT_YVU422M:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_YVU420M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
buf[1][0] = (buf[1][0] + b_v) / 2;
-   buf[2][0] = (buf[2][0] + g_u) / 2;
+   buf[2][0] = (buf[2][0] + g_u_s) / 2;
buf[1][1] = buf[1][0];
buf[2][1] = buf[2][0];
break;
}
buf[1][0] = b_v;
-   buf[2][0] = g_u;
+   buf[2][0] = g_u_s;
break;
 
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_NV12M:
case V4L2_PIX_FMT_NV16:
case V4L2_PIX_FMT_NV16M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
-   buf[1][0] = (buf[1][0] + g_u) / 2;
+   buf[1][0] = (buf[1][0] + g_u_s) / 2;
buf[1][1] = (buf[1][1] + b_v) / 2;
break;
}
-   buf[1][0] = g_u;
+   buf[1][0] = g_u_s;
buf[1][1] = b_v;
break;
case V4L2_PIX_FMT_NV21:
case V4L2_PIX_FMT_NV21M:
case V4L2_PIX_FMT_NV61:
case V4L2_PIX_FMT_NV61M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
buf[1][0] = (buf[1][0] + b_v) / 2;
-   buf[1][1] = (buf[1][1] + g_u) / 2;
+   buf[1][1] = (buf[1][1] + g_u_s) / 2;
   

[PATCH v2 2/6] [media] Documentation: Add HSV format

[Ricardo Ribalda Delgado]

Describe the HSV formats

Signed-off-by: Ricardo Ribalda Delgado 
---
 Documentation/media/uapi/v4l/hsv-formats.rst   |  19 ++
 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 +
 Documentation/media/uapi/v4l/pixfmt.rst|   1 +
 Documentation/media/uapi/v4l/v4l2.rst  |   5 +
 4 files changed, 278 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst

diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst 
b/Documentation/media/uapi/v4l/hsv-formats.rst
new file mode 100644
index ..f0f2615eaa95
--- /dev/null
+++ b/Documentation/media/uapi/v4l/hsv-formats.rst
@@ -0,0 +1,19 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _hsv-formats:
+
+***
+HSV Formats
+***
+
+These formats store the color information of the image
+in a geometrical representation. The colors are mapped into a
+cylinder, where the angle is the HUE, the height is the VALUE
+and the distance to the center is the SATURATION. This is a very
+useful format for image segmentation algorithms.
+
+
+.. toctree::
+:maxdepth: 1
+
+pixfmt-packed-hsv
diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst 
b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
new file mode 100644
index ..b297aa4f7ba6
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
@@ -0,0 +1,253 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _packed-hsv:
+
+**
+Packed HSV formats
+**
+
+*man Packed HSV formats(2)*
+
+Packed HSV formats
+
+
+Description
+===
+
+The HUE (h) is meassured in degrees, one LSB represents two degrees.
+The SATURATION (s) and the VALUE (v) are measured in percentage of the
+cylinder: 0 being the smallest value and 255 the maximum.
+
+
+The values are packed in 24 or 32 bit formats.
+
+
+.. flat-table:: Packed HSV Image Formats
+:header-rows:  2
+:stub-columns: 0
+
+
+-  .. row 1
+
+   -  Identifier
+
+   -  Code
+
+   -
+   -  :cspan:`7` Byte 0 in memory
+
+   -
+   -  :cspan:`7` Byte 1
+
+   -
+   -  :cspan:`7` Byte 2
+
+   -
+   -  :cspan:`7` Byte 3
+
+-  .. row 2
+
+   -
+   -
+   -  Bit
+
+   -  7
+
+   -  6
+
+   -  5
+
+   -  4
+
+   -  3
+
+   -  2
+
+   -  1
+
+   -  0
+
+   -
+   -  7
+
+   -  6
+
+   -  5
+
+   -  4
+
+   -  3
+
+   -  2
+
+   -  1
+
+   -  0
+
+   -
+   -  7
+
+   -  6
+
+   -  5
+
+   -  4
+
+   -  3
+
+   -  2
+
+   -  1
+
+   -  0
+
+   -
+   -  7
+
+   -  6
+
+   -  5
+
+   -  4
+
+   -  3
+
+   -  2
+
+   -  1
+
+   -  0
+
+-  .. _V4L2-PIX-FMT-HSV32:
+
+   -  ``V4L2_PIX_FMT_HSV32``
+
+   -  'HSV4'
+
+   -
+   -  -
+
+   -  -
+
+   -  -
+
+   -  -
+
+   -  -
+
+   -  -
+
+   -  -
+
+   -  -
+
+   -
+   -  h\ :sub:`7`
+
+   -  h\ :sub:`6`
+
+   -  h\ :sub:`5`
+
+   -  h\ :sub:`4`
+
+   -  h\ :sub:`3`
+
+   -  h\ :sub:`2`
+
+   -  h\ :sub:`1`
+
+   -  h\ :sub:`0`
+
+   -
+   -  s\ :sub:`7`
+
+   -  s\ :sub:`6`
+
+   -  s\ :sub:`5`
+
+   -  s\ :sub:`4`
+
+   -  s\ :sub:`3`
+
+   -  s\ :sub:`2`
+
+   -  s\ :sub:`1`
+
+   -  s\ :sub:`0`
+
+   -
+   -  v\ :sub:`7`
+
+   -  v\ :sub:`6`
+
+   -  v\ :sub:`5`
+
+   -  v\ :sub:`4`
+
+   -  v\ :sub:`3`
+
+   -  v\ :sub:`2`
+
+   -  v\ :sub:`1`
+
+   -  v\ :sub:`0`
+
+-  .. _V4L2-PIX-FMT-HSV24:
+
+   -  ``V4L2_PIX_FMT_HSV24``
+
+   -  'HSV3'
+
+   -
+   -  h\ :sub:`7`
+
+   -  h\ :sub:`6`
+
+   -  h\ :sub:`5`
+
+   -  h\ :sub:`4`
+
+   -  h\ :sub:`3`
+
+   -  h\ :sub:`2`
+
+   -  h\ :sub:`1`
+
+   -  h\ :sub:`0`
+
+   -
+   -  s\ :sub:`7`
+
+   -  s\ :sub:`6`
+
+   -  s\ :sub:`5`
+
+   -  s\ :sub:`4`
+
+   -  s\ :sub:`3`
+
+   -  s\ :sub:`2`
+
+   -  s\ :sub:`1`
+
+   -  s\ :sub:`0`
+
+   -
+   -  v\ :sub:`7`
+
+   -  v\ :sub:`6`
+
+   -  v\ :sub:`5`
+
+   -  v\ :sub:`4`
+
+   -  v\ :sub:`3`
+
+   -  v\ :sub:`2`
+
+   -  v\ :sub:`1`
+
+   -  v\ :sub:`0`
+
+
+Bit 7 is the most significant bit.
diff --git a/Documentation/media/uapi/v4l/pixfmt.rst 
b/Documentation/media/uapi/v4l/pixfmt.rst
index 81222a99f7ce..1d2270422345 100644
--- a/Documentation/media/uapi/v4l/pixfmt.rst
+++ b/Documentation/media/uapi/v4l/pixfmt.rst
@@ -29,6 +29,7 @@ see also :ref:`VIDIOC_G_FBUF `.)
 pixfmt-indexed
 pixfmt-rgb
 yuv-formats
+hsv-formats
 depth-formats
 pixfmt-013
 sdr-formats
diff --git a/Documentation/media/uapi/v4l/v4l2.rst 
b/Documentation/media/uapi/v4l/v4l2.rst
index c0859ebc88ee..6d23bc987f51 100644
--- 

[PATCH v2 5/6] [media] vivid: Add support for HSV formats

[Ricardo Ribalda Delgado]

This patch adds support for V4L2_PIX_FMT_HSV24 and V4L2_PIX_FMT_HSV32.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 94 +++--
 drivers/media/platform/vivid/vivid-vid-common.c | 14 
 include/media/v4l2-tpg.h|  1 +
 3 files changed, 105 insertions(+), 4 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index acf0e6854832..85b9c1925dd9 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -318,6 +318,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hmask[0] = ~1;
tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
+   case V4L2_PIX_FMT_HSV24:
+   case V4L2_PIX_FMT_HSV32:
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_HSV;
+   break;
default:
return false;
}
@@ -351,6 +355,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
break;
case V4L2_PIX_FMT_RGB24:
case V4L2_PIX_FMT_BGR24:
+   case V4L2_PIX_FMT_HSV24:
tpg->twopixelsize[0] = 2 * 3;
break;
case V4L2_PIX_FMT_BGR666:
@@ -361,6 +366,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_ARGB32:
case V4L2_PIX_FMT_ABGR32:
case V4L2_PIX_FMT_YUV32:
+   case V4L2_PIX_FMT_HSV32:
tpg->twopixelsize[0] = 2 * 4;
break;
case V4L2_PIX_FMT_NV12:
@@ -408,6 +414,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->twopixelsize[1] = 4;
break;
}
+
return true;
 }
 EXPORT_SYMBOL_GPL(tpg_s_fourcc);
@@ -490,6 +497,64 @@ static inline int linear_to_rec709(int v)
return tpg_linear_to_rec709[v];
 }
 
+static void color_to_hsv(struct tpg_data *tpg, int r, int g, int b,
+  int *h, int *s, int *v)
+{
+   int max_rgb, min_rgb, diff_rgb;
+   int aux;
+   int third;
+
+   r >>= 4;
+   g >>= 4;
+   b >>= 4;
+
+   /*V*/
+   max_rgb = max3(r, g, b);
+   *v = max_rgb;
+   if (!max_rgb) {
+   *h = 0;
+   *s = 0;
+   return;
+   }
+
+   /*S*/
+   min_rgb = min3(r, g, b);
+   diff_rgb = max_rgb - min_rgb;
+   aux = 255 * diff_rgb;
+   aux += max_rgb / 2;
+   aux /= max_rgb;
+   *s = aux;
+   if (!aux) {
+   *h = 0;
+   return;
+   }
+
+   /*H*/
+   if (max_rgb == r) {
+   aux =  g - b;
+   third = 0;
+   } else if (max_rgb == g) {
+   aux =  b - r;
+   third = 60;
+   } else {
+   aux =  r - g;
+   third = 120;
+   }
+
+   aux *= 30;
+   aux += diff_rgb / 2;
+   aux /= diff_rgb;
+   aux += third;
+
+   /*Clamp H*/
+   if (aux < 0)
+   aux += 180;
+   else if (aux > 180)
+   aux -= 180;
+   *h = aux;
+
+}
+
 static void rgb2ycbcr(const int m[3][3], int r, int g, int b,
int y_offset, int *y, int *cb, int *cr)
 {
@@ -829,7 +894,19 @@ static void precalculate_color(struct tpg_data *tpg, int k)
ycbcr_to_color(tpg, y, cb, cr, , , );
}
 
-   if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
+   switch (tpg->color_representation) {
+   case TGP_COLOR_REPRESENTATION_HSV:
+   {
+   int h, s, v;
+
+   color_to_hsv(tpg, r, g, b, , , );
+   tpg->colors[k][0] = h;
+   tpg->colors[k][1] = s;
+   tpg->colors[k][2] = v;
+   break;
+   }
+   case TGP_COLOR_REPRESENTATION_YUV:
+   {
/* Convert to YCbCr */
int y, cb, cr;
 
@@ -863,7 +940,10 @@ static void precalculate_color(struct tpg_data *tpg, int k)
tpg->colors[k][0] = y;
tpg->colors[k][1] = cb;
tpg->colors[k][2] = cr;
-   } else {
+   break;
+   }
+   case TGP_COLOR_REPRESENTATION_RGB:
+   {
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
r = (r * 219) / 255 + (16 << 4);
g = (g * 219) / 255 + (16 << 4);
@@ -913,6 +993,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
tpg->colors[k][0] = r;
tpg->colors[k][1] = g;
tpg->colors[k][2] = b;
+   break;
+   }
}
 }
 
@@ -938,8 +1020,8 @@ static void gen_twopix(struct tpg_data *tpg,
alpha = 0;
if (color == TPG_COLOR_RANDOM)
precalculate_color(tpg, color);
-   r_y = tpg->colors[color][0]; /* R or precalculated Y */

[PATCH v2 4/6] [media] vivid: code refactor for color representation

[Ricardo Ribalda Delgado]

Replace is_yuv with color_representation. Which can be used by HSV
formats.

This change should ease the review of the following patches.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 44 ++---
 drivers/media/platform/vivid/vivid-core.h   |  2 +-
 drivers/media/platform/vivid/vivid-vid-common.c | 52 -
 include/media/v4l2-tpg.h|  7 +++-
 4 files changed, 63 insertions(+), 42 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index cf1dadd0be9e..acf0e6854832 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -237,13 +237,13 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_Y16:
case V4L2_PIX_FMT_Y16_BE:
-   tpg->is_yuv = false;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_RGB;
break;
case V4L2_PIX_FMT_YUV444:
case V4L2_PIX_FMT_YUV555:
case V4L2_PIX_FMT_YUV565:
case V4L2_PIX_FMT_YUV32:
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_YUV420M:
case V4L2_PIX_FMT_YVU420M:
@@ -256,7 +256,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 2;
tpg->hdownsampling[2] = 2;
tpg->planes = 3;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_YUV422M:
case V4L2_PIX_FMT_YVU422M:
@@ -268,7 +268,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 2;
tpg->hdownsampling[2] = 2;
tpg->planes = 3;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_NV16M:
case V4L2_PIX_FMT_NV61M:
@@ -280,7 +280,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 1;
tpg->hmask[1] = ~1;
tpg->planes = 2;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_NV12M:
case V4L2_PIX_FMT_NV21M:
@@ -292,7 +292,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 1;
tpg->hmask[1] = ~1;
tpg->planes = 2;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_YUV444M:
case V4L2_PIX_FMT_YVU444M:
@@ -302,21 +302,21 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->vdownsampling[2] = 1;
tpg->hdownsampling[1] = 1;
tpg->hdownsampling[2] = 1;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_NV24:
case V4L2_PIX_FMT_NV42:
tpg->vdownsampling[1] = 1;
tpg->hdownsampling[1] = 1;
tpg->planes = 2;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_YUYV:
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_VYUY:
tpg->hmask[0] = ~1;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
default:
return false;
@@ -820,7 +820,7 @@ static void precalculate_color(struct tpg_data *tpg, int k)
 
cb = (128 << 4) + (tmp_cb * tpg->contrast * tpg->saturation) / 
(128 * 128);
cr = (128 << 4) + (tmp_cr * tpg->contrast * tpg->saturation) / 
(128 * 128);
-   if (tpg->is_yuv) {
+   if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
tpg->colors[k][0] = clamp(y >> 4, 1, 254);
tpg->colors[k][1] = clamp(cb >> 4, 1, 254);
tpg->colors[k][2] = clamp(cr >> 4, 1, 254);
@@ -829,7 +829,7 @@ static void precalculate_color(struct tpg_data *tpg, int k)
ycbcr_to_color(tpg, y, cb, cr, , , );
}
 
-   if (tpg->is_yuv) {
+   if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
/* Convert to YCbCr */
int y, cb, cr;
 
@@ -1842,7 +1842,9 @@ static void tpg_recalc(struct tpg_data *tpg)
 
if (tpg->quantization == 

[PATCH v2 0/6] Add HSV format

[Ricardo Ribalda Delgado]

HSV formats are extremely useful for image segmentation. This set of
patches makes v4l2 aware of this kind of formats.

Vivid changes have been divided in three to ease the reviewing process.

We are working on patches for Gstreamer and OpenCV that will make use
of these formats.

Thanks!

Changelog
v2: Suggested by Mauro Carvalho Chehab ,
-Rebase on top of docs-next (port documentation to .rst)
@mchehab, You were right, there was no conflict after the rebase, Thanks!

Ricardo Ribalda Delgado (6):
  [media] videodev2.h Add HSV formats
  [media] Documentation: Add HSV format
  [media] Documentation: Add Ricardo Ribalda
  [media] vivid: code refactor for color representation
  [media] vivid: Add support for HSV formats
  [media] vivid: Rename variable

 Documentation/media/uapi/v4l/hsv-formats.rst   |  19 ++
 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 +++
 Documentation/media/uapi/v4l/pixfmt.rst|   1 +
 Documentation/media/uapi/v4l/v4l2.rst  |   9 +
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c  | 341 ++---
 drivers/media/platform/vivid/vivid-core.h  |   2 +-
 drivers/media/platform/vivid/vivid-vid-common.c|  66 ++--
 drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
 include/media/v4l2-tpg.h   |   8 +-
 include/uapi/linux/videodev2.h |   4 +
 10 files changed, 558 insertions(+), 147 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst

-- 
2.8.1

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

[PATCH v2 3/6] [media] Documentation: Add Ricardo Ribalda

[Ricardo Ribalda Delgado]

My initials were on the Changelog, but there was no link to my name.

Signed-off-by: Ricardo Ribalda Delgado 
---
 Documentation/media/uapi/v4l/v4l2.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/media/uapi/v4l/v4l2.rst 
b/Documentation/media/uapi/v4l/v4l2.rst
index 6d23bc987f51..330674a0f553 100644
--- a/Documentation/media/uapi/v4l/v4l2.rst
+++ b/Documentation/media/uapi/v4l/v4l2.rst
@@ -64,6 +64,10 @@ Authors, in alphabetical order:
 
   - SDR API.
 
+- Ribalda, Ricardo
+
+  - Introduce HSV formats and other minor changes.
+
 - Rubli, Martin
 
   - Designed and documented the VIDIOC_ENUM_FRAMESIZES and 
VIDIOC_ENUM_FRAMEINTERVALS ioctls.
-- 
2.8.1

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

Re: [PATCH 2/6] [media] Documentation: Add HSV format

[Mauro Carvalho Chehab]

Em Fri, 15 Jul 2016 17:36:15 +0200
Ricardo Ribalda Delgado  escreveu:

> Hi Mauro
> 
> On Fri, Jul 15, 2016 at 5:28 PM, Mauro Carvalho Chehab
>  wrote:
> > Hi Ricardo,
> >
> > I'm not seeing patch 1.  
> 
> That is because you blacklisted me :P
> https://lkml.org/lkml/2016/7/15/45
> 
> I resend it to you right away.

Thanks.

> >
> > Anyway, please send documentation patches against the rst files. They're
> > at the "docs-next" branch and will be merged upstream on this merge window.
> >  
> 
> you are absolutely right, I read about it in lwn. Sorry about that.
> 
> 
> How do you prefer it:
> - 2 patchset : One on top of media/master with the code changes, and
> one on top of docs-next with the doc changes.
> or
> -1 patchset on top of doc-next and we will figure out later if there
> is a merge conflict with media

IMHO, the best would be to wait for it to be merged. I'm finishing
handling patches for 4.7 in a few, and applying only on more trivial
patches and bug fixes.

Yet, I suspect that there won't be conflicts if you base your
patches against docs-next, as most of the media stuff is merged
there.

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH][media][V2] mb86a20s: apply mask to val after checking for read failure

[Colin King]

From: Colin Ian King 

Appling the mask 0x0f to the immediate return of the call to
mb86a20s_readreg will always result in a positive value, meaning that the
check of ret < 0 will never work.  Instead, check for a -ve return value
first, and then mask val with 0x0f.

Kudos to Mauro Carvalho Chehab for spotting the mistake in my original fix.

Signed-off-by: Colin Ian King 
---
 drivers/media/dvb-frontends/mb86a20s.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c 
b/drivers/media/dvb-frontends/mb86a20s.c
index fb88ddd..0fffefd 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -301,10 +301,11 @@ static int mb86a20s_read_status(struct dvb_frontend *fe, 
enum fe_status *status)
 
*status = 0;
 
-   val = mb86a20s_readreg(state, 0x0a) & 0xf;
+   val = mb86a20s_readreg(state, 0x0a);
if (val < 0)
return val;
 
+   val &= 0xf;
if (val >= 2)
*status |= FE_HAS_SIGNAL;
 
-- 
2.8.1

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

[PATCH 1/1] subsystem:linux-media CVE-2016-5400

[James Patrick-Evans]

This patch addresses CVE-2016-5400, a local DOS vulnerability caused by a 
memory leak in the airspy usb device driver. The vulnerability is triggered 
when more than 64 usb devices register with v4l2 of type VFL_TYPE_SDR or 
VFL_TYPE_SUBDEV.A badusb device can emulate 64 of these devices then 
through continual emulated connect/disconnect of the 65th device, cause the 
kernel to run out of RAM and crash the kernel. The vulnerability exists in 
kernel versions from 3.17 to current 4.7.
The memory leak is caused by the probe function of the airspy driver 
mishandeling errors and not freeing the corresponding control structures 
when an error occours registering the device to v4l2 core.


Signed-off-by: James Patrick-Evans 
---
 drivers/media/usb/airspy/airspy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/airspy/airspy.c 
b/drivers/media/usb/airspy/airspy.c
index 87c1293..6c3ac8b 100644
--- a/drivers/media/usb/airspy/airspy.c
+++ b/drivers/media/usb/airspy/airspy.c
@@ -1072,7 +1072,7 @@ static int airspy_probe(struct usb_interface *intf,
if (ret) {
dev_err(s->dev, "Failed to register as video device (%d)\n",
ret);
-   goto err_unregister_v4l2_dev;
+   goto err_free_controls;
}
dev_info(s->dev, "Registered as %s\n",
video_device_node_name(>vdev));
--
1.9.1

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

Re: [PATCH] [media] mb86a20s: remove redundant check if val is less than zero

[Colin Ian King]

On 15/07/16 16:20, Mauro Carvalho Chehab wrote:
> Em Tue, 12 Jul 2016 10:30:51 +0100
> Colin King  escreveu:
> 
>> From: Colin Ian King 
>>
>> The result of mb86a20s_readreg(state, 0x0a) & 0xf is always in the range
>> 0x00 to 0x0f and can never be negative, so remove the redundant check
>> of the result being less than zero.
>>
>> Signed-off-by: Colin Ian King 
>> ---
>>  drivers/media/dvb-frontends/mb86a20s.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/media/dvb-frontends/mb86a20s.c 
>> b/drivers/media/dvb-frontends/mb86a20s.c
>> index fb88ddd..0205846 100644
>> --- a/drivers/media/dvb-frontends/mb86a20s.c
>> +++ b/drivers/media/dvb-frontends/mb86a20s.c
>> @@ -302,8 +302,6 @@ static int mb86a20s_read_status(struct dvb_frontend *fe, 
>> enum fe_status *status)
>>  *status = 0;
>>  
>>  val = mb86a20s_readreg(state, 0x0a) & 0xf;
>> -if (val < 0)
>> -return val;
> 
> Actually, mb86a20s_readreg() can return a negative value.

Oops, yep, clearly my code is stupid. I'll send a fix soon.

> 
> Please change the above logic to first check for the value returned
> from mb86a20s_readreg() and then apply the bitmask.
> 
> Thanks,
> Mauro
> 
>>  
>>  if (val >= 2)
>>  *status |= FE_HAS_SIGNAL;
> 
> 
> 
> Thanks,
> Mauro
> 

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

Re: [PATCH 2/6] [media] Documentation: Add HSV format

[Ricardo Ribalda Delgado]

Hi Mauro

On Fri, Jul 15, 2016 at 5:28 PM, Mauro Carvalho Chehab
 wrote:
> Hi Ricardo,
>
> I'm not seeing patch 1.

That is because you blacklisted me :P
https://lkml.org/lkml/2016/7/15/455

I resend it to you right away.


>
> Anyway, please send documentation patches against the rst files. They're
> at the "docs-next" branch and will be merged upstream on this merge window.
>

you are absolutely right, I read about it in lwn. Sorry about that.


How do you prefer it:
- 2 patchset : One on top of media/master with the code changes, and
one on top of docs-next with the doc changes.
or
-1 patchset on top of doc-next and we will figure out later if there
is a merge conflict with media

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

[PATCH 1/2 v2] SDI: add flag for SDI formats and SMPTE 125M definition

[Charles-Antoine Couret]

>From c6b157259081bd40d881a5c642dd1a4a07195ca5 Mon Sep 17 00:00:00 2001
From: Charles-Antoine Couret 
Date: Fri, 15 Jul 2016 15:04:57 +0200
Subject: [PATCH 1/2] SDI: add flag for SDI formats and SMPTE 125M definition

Adding others generic flags, which could be used by many
components like GS1662.

Signed-off-by: Charles-Antoine Couret 
---
 include/uapi/linux/v4l2-dv-timings.h | 12 
 include/uapi/linux/videodev2.h   |  5 +
 2 files changed, 17 insertions(+)

diff --git a/include/uapi/linux/v4l2-dv-timings.h 
b/include/uapi/linux/v4l2-dv-timings.h
index 086168e..eb7dd02 100644
--- a/include/uapi/linux/v4l2-dv-timings.h
+++ b/include/uapi/linux/v4l2-dv-timings.h
@@ -934,4 +934,16 @@
V4L2_DV_FL_REDUCED_BLANKING) \
 }
 
+/* SDI timings definitions */
+
+/* SMPTE-125M */
+#define V4L2_DV_BT_SDI_720X487I60 { \
+   .type = V4L2_DV_BT_656_1120, \
+   V4L2_INIT_BT_TIMINGS(720, 487, 1, \
+   V4L2_DV_HSYNC_POS_POL, \
+   1350, 0, 137, 0, 0, 19, 2, 0, 17, 0, \
+   V4L2_DV_BT_STD_SDI, \
+   V4L2_DV_FIRST_FIELD_EXTRA_LINE) \
+}
+
 #endif
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 8f95191..4641f13 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1259,6 +1259,7 @@ struct v4l2_bt_timings {
 #define V4L2_DV_BT_STD_DMT (1 << 1)  /* VESA Discrete Monitor Timings */
 #define V4L2_DV_BT_STD_CVT (1 << 2)  /* VESA Coordinated Video Timings */
 #define V4L2_DV_BT_STD_GTF (1 << 3)  /* VESA Generalized Timings Formula */
+#define V4L2_DV_BT_STD_SDI (1 << 4)  /* SDI Timings */
 
 /* Flags */
 
@@ -1363,6 +1364,8 @@ struct v4l2_bt_timings_cap {
 #define V4L2_DV_BT_CAP_REDUCED_BLANKING(1 << 2)
 /* Supports custom formats */
 #define V4L2_DV_BT_CAP_CUSTOM  (1 << 3)
+/* In case of odd format, to know the field which has the extra line */
+#define V4L2_DV_FIRST_FIELD_EXTRA_LINE (1 << 4)
 
 /** struct v4l2_dv_timings_cap - DV timings capabilities
  * @type:  the type of the timings (same as in struct v4l2_dv_timings)
@@ -1413,6 +1416,8 @@ struct v4l2_input {
 /* field 'status' - analog */
 #define V4L2_IN_ST_NO_H_LOCK   0x0100  /* No horizontal sync lock */
 #define V4L2_IN_ST_COLOR_KILL  0x0200  /* Color killer is active */
+#define V4L2_IN_ST_NO_V_LOCK   0x0400  /* No vertical sync lock */
+#define V4L2_IN_ST_NO_STD_LOCK 0x0800  /* No standard format lock */
 
 /* field 'status' - digital */
 #define V4L2_IN_ST_NO_SYNC 0x0001  /* No synchronization lock */
-- 
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] [media] Documentation: Add HSV format

[Mauro Carvalho Chehab]

Hi Ricardo,

I'm not seeing patch 1.

Anyway, please send documentation patches against the rst files. They're
at the "docs-next" branch and will be merged upstream on this merge window.

After its merge, we'll drop the DocBook.

Thanks,
Mauro

Em Fri, 15 Jul 2016 17:16:52 +0200
Ricardo Ribalda Delgado  escreveu:

> Describe the HSV formats.
> 
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  .../DocBook/media/v4l/pixfmt-packed-hsv.xml| 195 
> +
>  Documentation/DocBook/media/v4l/pixfmt.xml |  13 ++
>  Documentation/DocBook/media/v4l/v4l2.xml   |   8 +
>  3 files changed, 216 insertions(+)
>  create mode 100644 Documentation/DocBook/media/v4l/pixfmt-packed-hsv.xml
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-hsv.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-packed-hsv.xml
> new file mode 100644
> index ..3b41d567e32b
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-hsv.xml
> @@ -0,0 +1,195 @@
> +
> +  
> +Packed HSV formats
> +
> +  
> +  
> +Packed HSV formats
> +Packed HSV formats
> +  
> +  
> +Description
> +
> +The HUE (h) is meassured in degrees, one LSB represents two
> +degrees. The SATURATION (s) and the VALUE (v) are meassured in percentage
> +of the cylinder: 0 being the smallest value and 255 the maximum.
> +The values are packed in 24 or 32 bit formats. 
> +
> +
> +  Packed YUV Image Formats
> +  
> + 
> + 
> + 
> +
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> +
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> +
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> +
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> +
> + 
> + 
> + 
> + 
> + 
> +   
> + Identifier
> + Code
> + 
> + Byte0 in memory
> + Byte1
> + Byte2
> + Byte3
> +   
> +   
> + 
> + 
> + Bit
> + 7
> + 6
> + 5
> + 4
> + 3
> + 2
> + 1
> + 0
> + 
> + 7
> + 6
> + 5
> + 4
> + 3
> + 2
> + 1
> + 0
> + 
> + 7
> + 6
> + 5
> + 4
> + 3
> + 2
> + 1
> + 0
> + 
> + 7
> + 6
> + 5
> + 4
> + 3
> + 2
> + 1
> + 0
> +   
> + 
> + 
> +   
> + V4L2_PIX_FMT_HSV32
> + 'HSV4'
> + 
> + -
> + -
> + -
> + -
> + -
> + -
> + -
> + -
> + 
> + h7
> + h6
> + h5
> + h4
> + h3
> + h2
> + h1
> + h0
> + 
> + s7
> + s6
> + s5
> + s4
> + s3
> + s2
> + s1
> + s0
> + 
> + v7
> + v6
> + v5
> + v4
> + v3
> + v2
> + v1
> + v0
> +   
> +   
> + V4L2_PIX_FMT_HSV24
> + 'HSV3'
> + 
> + h7
> + h6
> + h5
> + h4
> + h3
> + h2
> + h1
> + h0
> + 
> + s7
> + s6
> + s5
> + s4
> + s3
> + s2
> + s1
> + s0
> + 
> + v7
> + v6
> + v5
> + v4
> + v3
> + v2
> + v1
> + v0
> +   
> + 
> +  
> +
> +
> +Bit 7 is the most significant bit.
> +
> +  
> +
> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
> b/Documentation/DocBook/media/v4l/pixfmt.xml
> index 5a08aeea4360..7b081a6bdc61 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> @@ -1740,6 +1740,19 @@ extended control 
> V4L2_CID_MPEG_STREAM_TYPE, see
>  
>
>  
> +  
> +HSV Formats
> +
> + These formats store the color information of the image
> +in a geometrical representation. The colors are mapped into a
> +cylinder, where the angle is the HUE, the height is the VALUE
> +and the distance to the center is the SATURATION. This is a very
> +useful format for image segmentation algorithms. 
> +
> +
> +
> +  
> +
>
>  SDR Formats
>  
> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
> b/Documentation/DocBook/media/v4l/v4l2.xml
> index 42e626d6c936..f38039b7c338 100644
> --- a/Documentation/DocBook/media/v4l/v4l2.xml
> +++ b/Documentation/DocBook/media/v4l/v4l2.xml
> @@ -152,6 +152,14 @@ structs, ioctls) must be noted in more detail in the 
> history chapter
>  (compat.xml), along with the possible impact on existing drivers and
>  applications. -->
>
> + 4.8
> + 

[PATCH 1/2] SDI: add flag for SDI formats and SMPTE 125M definition

[Charles-Antoine Couret]

>From c6b157259081bd40d881a5c642dd1a4a07195ca5 Mon Sep 17 00:00:00 2001
From: Charles-Antoine Couret 
Date: Fri, 15 Jul 2016 15:04:57 +0200
Subject: [PATCH 1/2] SDI: add flag for SDI formats and SMPTE 125M definition

Adding others generic flags, which could be used by many
components like GS1662.

Signed-off-by: Charles-Antoine Couret 
---
 include/uapi/linux/v4l2-dv-timings.h | 12 
 include/uapi/linux/videodev2.h   |  5 +
 2 files changed, 17 insertions(+)

diff --git a/include/uapi/linux/v4l2-dv-timings.h 
b/include/uapi/linux/v4l2-dv-timings.h
index 086168e..eb7dd02 100644
--- a/include/uapi/linux/v4l2-dv-timings.h
+++ b/include/uapi/linux/v4l2-dv-timings.h
@@ -934,4 +934,16 @@
V4L2_DV_FL_REDUCED_BLANKING) \
 }
 
+/* SDI timings definitions */
+
+/* SMPTE-125M */
+#define V4L2_DV_BT_SDI_720X487I60 { \
+   .type = V4L2_DV_BT_656_1120, \
+   V4L2_INIT_BT_TIMINGS(720, 487, 1, \
+   V4L2_DV_HSYNC_POS_POL, \
+   1350, 0, 137, 0, 0, 19, 2, 0, 17, 0, \
+   V4L2_DV_BT_STD_SDI, \
+   V4L2_DV_FIRST_FIELD_EXTRA_LINE) \
+}
+
 #endif
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 8f95191..4641f13 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1259,6 +1259,7 @@ struct v4l2_bt_timings {
 #define V4L2_DV_BT_STD_DMT (1 << 1)  /* VESA Discrete Monitor Timings */
 #define V4L2_DV_BT_STD_CVT (1 << 2)  /* VESA Coordinated Video Timings */
 #define V4L2_DV_BT_STD_GTF (1 << 3)  /* VESA Generalized Timings Formula */
+#define V4L2_DV_BT_STD_SDI (1 << 4)  /* SDI Timings */
 
 /* Flags */
 
@@ -1363,6 +1364,8 @@ struct v4l2_bt_timings_cap {
 #define V4L2_DV_BT_CAP_REDUCED_BLANKING(1 << 2)
 /* Supports custom formats */
 #define V4L2_DV_BT_CAP_CUSTOM  (1 << 3)
+/* In case of odd format, to know the field which has the extra line */
+#define V4L2_DV_FIRST_FIELD_EXTRA_LINE (1 << 4)
 
 /** struct v4l2_dv_timings_cap - DV timings capabilities
  * @type:  the type of the timings (same as in struct v4l2_dv_timings)
@@ -1413,6 +1416,8 @@ struct v4l2_input {
 /* field 'status' - analog */
 #define V4L2_IN_ST_NO_H_LOCK   0x0100  /* No horizontal sync lock */
 #define V4L2_IN_ST_COLOR_KILL  0x0200  /* Color killer is active */
+#define V4L2_IN_ST_NO_V_LOCK   0x0400  /* No vertical sync lock */
+#define V4L2_IN_ST_NO_STD_LOCK 0x0800  /* No standard format lock */
 
 /* field 'status' - digital */
 #define V4L2_IN_ST_NO_SYNC 0x0001  /* No synchronization lock */
-- 
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] mb86a20s: remove redundant check if val is less than zero

[Mauro Carvalho Chehab]

Em Tue, 12 Jul 2016 10:30:51 +0100
Colin King  escreveu:

> From: Colin Ian King 
> 
> The result of mb86a20s_readreg(state, 0x0a) & 0xf is always in the range
> 0x00 to 0x0f and can never be negative, so remove the redundant check
> of the result being less than zero.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/media/dvb-frontends/mb86a20s.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/media/dvb-frontends/mb86a20s.c 
> b/drivers/media/dvb-frontends/mb86a20s.c
> index fb88ddd..0205846 100644
> --- a/drivers/media/dvb-frontends/mb86a20s.c
> +++ b/drivers/media/dvb-frontends/mb86a20s.c
> @@ -302,8 +302,6 @@ static int mb86a20s_read_status(struct dvb_frontend *fe, 
> enum fe_status *status)
>   *status = 0;
>  
>   val = mb86a20s_readreg(state, 0x0a) & 0xf;
> - if (val < 0)
> - return val;

Actually, mb86a20s_readreg() can return a negative value.

Please change the above logic to first check for the value returned
from mb86a20s_readreg() and then apply the bitmask.

Thanks,
Mauro

>  
>   if (val >= 2)
>   *status |= FE_HAS_SIGNAL;



Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.8] CEC and mediatek vcodec fixes

[Hans Verkuil]

Several mediatek vcodec and CEC fixes.

Regards,

Hans

The following changes since commit 5cac1f67ea0363d463a58ec2d9118268fe2ba5d6:

  [media] rc: nuvoton: fix hang if chip is configured for alternative EFM IO 
address (2016-07-13 15:49:01 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.8k

for you to fetch changes up to e308f81bbba764789d1ba2b9bf1556d133e5939f:

  s5p-cec/TODO: add TODO item (2016-07-15 17:13:01 +0200)


Arnd Bergmann (1):
  mtk-vcodec: fix more type mismatches

Hans Verkuil (5):
  cec: don't zero reply and timeout on error
  vivid: fix typo causing incorrect CEC physical addresses
  cec: set timestamp for selfie transmits
  cec/TODO: drop comment about sphinx documentation
  s5p-cec/TODO: add TODO item

Tiffany Lin (1):
  mtk-vcodec: fix default OUTPUT buffer size

 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c| 13 +
 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c |  4 ++--
 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c  |  4 ++--
 drivers/media/platform/vivid/vivid-core.c |  2 +-
 drivers/staging/media/cec/TODO|  1 -
 drivers/staging/media/cec/cec-adap.c  | 20 ++--
 drivers/staging/media/s5p-cec/TODO| 10 +++---
 7 files changed, 27 insertions(+), 27 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/6] [media] videodev2.h Add HSV formats

[Ricardo Ribalda Delgado]

These formats store the color information of the image
in a geometrical representation. The colors are mapped into a
cylinder, where the angle is the HUE, the height is the VALUE
and the distance to the center is the SATURATION. This is a very
useful format for image segmentation algorithms.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
 include/uapi/linux/videodev2.h   | 4 
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index f899bf1c5fc0..54670cd59212 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1238,6 +1238,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_TM6000:   descr = "A/V + VBI Mux Packet"; break;
case V4L2_PIX_FMT_CIT_YYVYUY:   descr = "GSPCA CIT YYVYUY"; break;
case V4L2_PIX_FMT_KONICA420:descr = "GSPCA KONICA420"; break;
+   case V4L2_PIX_FMT_HSV24:descr = "24-bit HSV 8-8-8"; break;
+   case V4L2_PIX_FMT_HSV32:descr = "32-bit XHSV 8-8-8-8"; break;
case V4L2_SDR_FMT_CU8:  descr = "Complex U8"; break;
case V4L2_SDR_FMT_CU16LE:   descr = "Complex U16LE"; break;
case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 724f43e69d03..c7fb760386cf 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -580,6 +580,10 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG.. 
GBGB.. */
 #define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16  BGBG.. 
GRGR.. */
 
+/* HSV formats */
+#define V4L2_PIX_FMT_HSV24 v4l2_fourcc('H', 'S', 'V', '3')
+#define V4L2_PIX_FMT_HSV32 v4l2_fourcc('H', 'S', 'V', '4')
+
 /* compressed formats */
 #define V4L2_PIX_FMT_MJPEGv4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG   
*/
 #define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG 
*/
-- 
2.8.1

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

[PATCH 5/6] [media] vivid: Add support for HSV formats

[Ricardo Ribalda Delgado]

This patch adds support for V4L2_PIX_FMT_HSV24 and V4L2_PIX_FMT_HSV32.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 94 +++--
 drivers/media/platform/vivid/vivid-vid-common.c | 14 
 include/media/v4l2-tpg.h|  1 +
 3 files changed, 105 insertions(+), 4 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 3cab77ea92a4..d87a7a6a6b22 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -318,6 +318,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hmask[0] = ~1;
tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
+   case V4L2_PIX_FMT_HSV24:
+   case V4L2_PIX_FMT_HSV32:
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_HSV;
+   break;
default:
return false;
}
@@ -351,6 +355,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
break;
case V4L2_PIX_FMT_RGB24:
case V4L2_PIX_FMT_BGR24:
+   case V4L2_PIX_FMT_HSV24:
tpg->twopixelsize[0] = 2 * 3;
break;
case V4L2_PIX_FMT_BGR666:
@@ -361,6 +366,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_ARGB32:
case V4L2_PIX_FMT_ABGR32:
case V4L2_PIX_FMT_YUV32:
+   case V4L2_PIX_FMT_HSV32:
tpg->twopixelsize[0] = 2 * 4;
break;
case V4L2_PIX_FMT_NV12:
@@ -408,6 +414,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->twopixelsize[1] = 4;
break;
}
+
return true;
 }
 EXPORT_SYMBOL_GPL(tpg_s_fourcc);
@@ -490,6 +497,64 @@ static inline int linear_to_rec709(int v)
return tpg_linear_to_rec709[v];
 }
 
+static void color_to_hsv(struct tpg_data *tpg, int r, int g, int b,
+  int *h, int *s, int *v)
+{
+   int max_rgb, min_rgb, diff_rgb;
+   int aux;
+   int third;
+
+   r >>= 4;
+   g >>= 4;
+   b >>= 4;
+
+   /*V*/
+   max_rgb = max3(r, g, b);
+   *v = max_rgb;
+   if (!max_rgb) {
+   *h = 0;
+   *s = 0;
+   return;
+   }
+
+   /*S*/
+   min_rgb = min3(r, g, b);
+   diff_rgb = max_rgb - min_rgb;
+   aux = 255 * diff_rgb;
+   aux += max_rgb / 2;
+   aux /= max_rgb;
+   *s = aux;
+   if (!aux) {
+   *h = 0;
+   return;
+   }
+
+   /*H*/
+   if (max_rgb == r) {
+   aux =  g - b;
+   third = 0;
+   } else if (max_rgb == g) {
+   aux =  b - r;
+   third = 60;
+   } else {
+   aux =  r - g;
+   third = 120;
+   }
+
+   aux *= 30;
+   aux += diff_rgb / 2;
+   aux /= diff_rgb;
+   aux += third;
+
+   /*Clamp H*/
+   if (aux < 0)
+   aux += 180;
+   else if (aux > 180)
+   aux -= 180;
+   *h = aux;
+
+}
+
 static void rgb2ycbcr(const int m[3][3], int r, int g, int b,
int y_offset, int *y, int *cb, int *cr)
 {
@@ -829,7 +894,19 @@ static void precalculate_color(struct tpg_data *tpg, int k)
ycbcr_to_color(tpg, y, cb, cr, , , );
}
 
-   if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
+   switch (tpg->color_representation) {
+   case TGP_COLOR_REPRESENTATION_HSV:
+   {
+   int h, s, v;
+
+   color_to_hsv(tpg, r, g, b, , , );
+   tpg->colors[k][0] = h;
+   tpg->colors[k][1] = s;
+   tpg->colors[k][2] = v;
+   break;
+   }
+   case TGP_COLOR_REPRESENTATION_YUV:
+   {
/* Convert to YCbCr */
int y, cb, cr;
 
@@ -863,7 +940,10 @@ static void precalculate_color(struct tpg_data *tpg, int k)
tpg->colors[k][0] = y;
tpg->colors[k][1] = cb;
tpg->colors[k][2] = cr;
-   } else {
+   break;
+   }
+   case TGP_COLOR_REPRESENTATION_RGB:
+   {
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
r = (r * 219) / 255 + (16 << 4);
g = (g * 219) / 255 + (16 << 4);
@@ -913,6 +993,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
tpg->colors[k][0] = r;
tpg->colors[k][1] = g;
tpg->colors[k][2] = b;
+   break;
+   }
}
 }
 
@@ -938,8 +1020,8 @@ static void gen_twopix(struct tpg_data *tpg,
alpha = 0;
if (color == TPG_COLOR_RANDOM)
precalculate_color(tpg, color);
-   r_y = tpg->colors[color][0]; /* R or precalculated Y */

[PATCH 4/6] [media] vivid: code refactor for color representation

[Ricardo Ribalda Delgado]

Replace is_yuv with color_representation. Which can be used by HSV
formats.

This change should ease the review of the following patches.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 44 ++---
 drivers/media/platform/vivid/vivid-core.h   |  2 +-
 drivers/media/platform/vivid/vivid-vid-common.c | 52 -
 include/media/v4l2-tpg.h|  7 +++-
 4 files changed, 63 insertions(+), 42 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 3ec3cebe62b9..3cab77ea92a4 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -237,13 +237,13 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_Y16:
case V4L2_PIX_FMT_Y16_BE:
-   tpg->is_yuv = false;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_RGB;
break;
case V4L2_PIX_FMT_YUV444:
case V4L2_PIX_FMT_YUV555:
case V4L2_PIX_FMT_YUV565:
case V4L2_PIX_FMT_YUV32:
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_YUV420M:
case V4L2_PIX_FMT_YVU420M:
@@ -256,7 +256,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 2;
tpg->hdownsampling[2] = 2;
tpg->planes = 3;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_YUV422M:
case V4L2_PIX_FMT_YVU422M:
@@ -268,7 +268,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 2;
tpg->hdownsampling[2] = 2;
tpg->planes = 3;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_NV16M:
case V4L2_PIX_FMT_NV61M:
@@ -280,7 +280,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 1;
tpg->hmask[1] = ~1;
tpg->planes = 2;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_NV12M:
case V4L2_PIX_FMT_NV21M:
@@ -292,7 +292,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 1;
tpg->hmask[1] = ~1;
tpg->planes = 2;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_YUV444M:
case V4L2_PIX_FMT_YVU444M:
@@ -302,21 +302,21 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->vdownsampling[2] = 1;
tpg->hdownsampling[1] = 1;
tpg->hdownsampling[2] = 1;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_NV24:
case V4L2_PIX_FMT_NV42:
tpg->vdownsampling[1] = 1;
tpg->hdownsampling[1] = 1;
tpg->planes = 2;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
case V4L2_PIX_FMT_YUYV:
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_VYUY:
tpg->hmask[0] = ~1;
-   tpg->is_yuv = true;
+   tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
break;
default:
return false;
@@ -820,7 +820,7 @@ static void precalculate_color(struct tpg_data *tpg, int k)
 
cb = (128 << 4) + (tmp_cb * tpg->contrast * tpg->saturation) / 
(128 * 128);
cr = (128 << 4) + (tmp_cr * tpg->contrast * tpg->saturation) / 
(128 * 128);
-   if (tpg->is_yuv) {
+   if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
tpg->colors[k][0] = clamp(y >> 4, 1, 254);
tpg->colors[k][1] = clamp(cb >> 4, 1, 254);
tpg->colors[k][2] = clamp(cr >> 4, 1, 254);
@@ -829,7 +829,7 @@ static void precalculate_color(struct tpg_data *tpg, int k)
ycbcr_to_color(tpg, y, cb, cr, , , );
}
 
-   if (tpg->is_yuv) {
+   if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
/* Convert to YCbCr */
int y, cb, cr;
 
@@ -1842,7 +1842,9 @@ static void tpg_recalc(struct tpg_data *tpg)
 
if (tpg->quantization == 

[PATCH 2/6] [media] Documentation: Add HSV format

[Ricardo Ribalda Delgado]

Describe the HSV formats.

Signed-off-by: Ricardo Ribalda Delgado 
---
 .../DocBook/media/v4l/pixfmt-packed-hsv.xml| 195 +
 Documentation/DocBook/media/v4l/pixfmt.xml |  13 ++
 Documentation/DocBook/media/v4l/v4l2.xml   |   8 +
 3 files changed, 216 insertions(+)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-packed-hsv.xml

diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-hsv.xml 
b/Documentation/DocBook/media/v4l/pixfmt-packed-hsv.xml
new file mode 100644
index ..3b41d567e32b
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-packed-hsv.xml
@@ -0,0 +1,195 @@
+
+  
+Packed HSV formats
+
+  
+  
+Packed HSV formats
+Packed HSV formats
+  
+  
+Description
+
+The HUE (h) is meassured in degrees, one LSB represents two
+degrees. The SATURATION (s) and the VALUE (v) are meassured in percentage
+of the cylinder: 0 being the smallest value and 255 the maximum.
+The values are packed in 24 or 32 bit formats. 
+
+
+  Packed YUV Image Formats
+  
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+ 
+   Identifier
+   Code
+   
+   Byte0 in memory
+   Byte1
+   Byte2
+   Byte3
+ 
+ 
+   
+   
+   Bit
+   7
+   6
+   5
+   4
+   3
+   2
+   1
+   0
+   
+   7
+   6
+   5
+   4
+   3
+   2
+   1
+   0
+   
+   7
+   6
+   5
+   4
+   3
+   2
+   1
+   0
+   
+   7
+   6
+   5
+   4
+   3
+   2
+   1
+   0
+ 
+   
+   
+ 
+   V4L2_PIX_FMT_HSV32
+   'HSV4'
+   
+   -
+   -
+   -
+   -
+   -
+   -
+   -
+   -
+   
+   h7
+   h6
+   h5
+   h4
+   h3
+   h2
+   h1
+   h0
+   
+   s7
+   s6
+   s5
+   s4
+   s3
+   s2
+   s1
+   s0
+   
+   v7
+   v6
+   v5
+   v4
+   v3
+   v2
+   v1
+   v0
+ 
+ 
+   V4L2_PIX_FMT_HSV24
+   'HSV3'
+   
+   h7
+   h6
+   h5
+   h4
+   h3
+   h2
+   h1
+   h0
+   
+   s7
+   s6
+   s5
+   s4
+   s3
+   s2
+   s1
+   s0
+   
+   v7
+   v6
+   v5
+   v4
+   v3
+   v2
+   v1
+   v0
+ 
+   
+  
+
+
+Bit 7 is the most significant bit.
+
+  
+
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 5a08aeea4360..7b081a6bdc61 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -1740,6 +1740,19 @@ extended control 
V4L2_CID_MPEG_STREAM_TYPE, see
 
   
 
+  
+HSV Formats
+
+ These formats store the color information of the image
+in a geometrical representation. The colors are mapped into a
+cylinder, where the angle is the HUE, the height is the VALUE
+and the distance to the center is the SATURATION. This is a very
+useful format for image segmentation algorithms. 
+
+
+
+  
+
   
 SDR Formats
 
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
b/Documentation/DocBook/media/v4l/v4l2.xml
index 42e626d6c936..f38039b7c338 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -152,6 +152,14 @@ structs, ioctls) must be noted in more detail in the 
history chapter
 (compat.xml), along with the possible impact on existing drivers and
 applications. -->
   
+   4.8
+   2016-07-15
+   rr
+Introduce HSV formats.
+   
+  
+
+  
4.5
2015-10-29
rr
-- 
2.8.1

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

[PATCH 0/6] Add HSV format

[Ricardo Ribalda Delgado]

HSV formats are extremely useful for image segmentation. This set of
patches makes v4l2 aware of this kind of formats.

Vivid changes have been divided in three to ease the reviewing process.

We are working on patches for Gstreamer and OpenCV that will make use
of these formats.

Thanks!

Ricardo Ribalda Delgado (6):
  [media] videodev2.h Add HSV formats
  [media] Documentation: Add HSV format
  [media] Documentation: Add Ricardo Ribalda as author
  [media] vivid: code refactor for color representation
  [media] vivid: Add support for HSV formats
  [media] vivid: Rename variable

 .../DocBook/media/v4l/pixfmt-packed-hsv.xml| 195 
 Documentation/DocBook/media/v4l/pixfmt.xml |  13 +
 Documentation/DocBook/media/v4l/v4l2.xml   |  19 ++
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c  | 341 ++---
 drivers/media/platform/vivid/vivid-core.h  |   2 +-
 drivers/media/platform/vivid/vivid-vid-common.c|  66 ++--
 drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
 include/media/v4l2-tpg.h   |   8 +-
 include/uapi/linux/videodev2.h |   4 +
 9 files changed, 503 insertions(+), 147 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-packed-hsv.xml

-- 
2.8.1

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

[PATCH 6/6] [media] vivid: Rename variable

[Ricardo Ribalda Delgado]

r_y and g_u now also contain the H and V components on the HSV formats.
Rename the variables to reflect this.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 209 +-
 1 file changed, 105 insertions(+), 104 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index d87a7a6a6b22..1711a9cd20c4 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -1012,7 +1012,7 @@ static void gen_twopix(struct tpg_data *tpg,
 {
unsigned offset = odd * tpg->twopixelsize[0] / 2;
u8 alpha = tpg->alpha_component;
-   u8 r_y, g_u, b_v;
+   u8 r_y_h, g_u_s, b_v;
 
if (tpg->alpha_red_only && color != TPG_COLOR_CSC_RED &&
   color != TPG_COLOR_100_RED &&
@@ -1020,161 +1020,161 @@ static void gen_twopix(struct tpg_data *tpg,
alpha = 0;
if (color == TPG_COLOR_RANDOM)
precalculate_color(tpg, color);
-   r_y = tpg->colors[color][0]; /* R or precalculated Y, H */
-   g_u = tpg->colors[color][1]; /* G or precalculated U, V */
+   r_y_h = tpg->colors[color][0]; /* R or precalculated Y, H */
+   g_u_s = tpg->colors[color][1]; /* G or precalculated U, V */
b_v = tpg->colors[color][2]; /* B or precalculated V */
 
switch (tpg->fourcc) {
case V4L2_PIX_FMT_GREY:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
break;
case V4L2_PIX_FMT_Y16:
/*
-* Ideally both bytes should be set to r_y, but then you won't
+* Ideally both bytes should be set to r_y_h, but then you won't
 * be able to detect endian problems. So keep it 0 except for
-* the corner case where r_y is 0xff so white really will be
+* the corner case where r_y_h is 0xff so white really will be
 * white (0x).
 */
-   buf[0][offset] = r_y == 0xff ? r_y : 0;
-   buf[0][offset+1] = r_y;
+   buf[0][offset] = r_y_h == 0xff ? r_y_h : 0;
+   buf[0][offset+1] = r_y_h;
break;
case V4L2_PIX_FMT_Y16_BE:
/* See comment for V4L2_PIX_FMT_Y16 above */
-   buf[0][offset] = r_y;
-   buf[0][offset+1] = r_y == 0xff ? r_y : 0;
+   buf[0][offset] = r_y_h;
+   buf[0][offset+1] = r_y_h == 0xff ? r_y_h : 0;
break;
case V4L2_PIX_FMT_YUV422M:
case V4L2_PIX_FMT_YUV422P:
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YUV420M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
-   buf[1][0] = (buf[1][0] + g_u) / 2;
+   buf[1][0] = (buf[1][0] + g_u_s) / 2;
buf[2][0] = (buf[2][0] + b_v) / 2;
buf[1][1] = buf[1][0];
buf[2][1] = buf[2][0];
break;
}
-   buf[1][0] = g_u;
+   buf[1][0] = g_u_s;
buf[2][0] = b_v;
break;
case V4L2_PIX_FMT_YVU422M:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_YVU420M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
buf[1][0] = (buf[1][0] + b_v) / 2;
-   buf[2][0] = (buf[2][0] + g_u) / 2;
+   buf[2][0] = (buf[2][0] + g_u_s) / 2;
buf[1][1] = buf[1][0];
buf[2][1] = buf[2][0];
break;
}
buf[1][0] = b_v;
-   buf[2][0] = g_u;
+   buf[2][0] = g_u_s;
break;
 
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_NV12M:
case V4L2_PIX_FMT_NV16:
case V4L2_PIX_FMT_NV16M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
-   buf[1][0] = (buf[1][0] + g_u) / 2;
+   buf[1][0] = (buf[1][0] + g_u_s) / 2;
buf[1][1] = (buf[1][1] + b_v) / 2;
break;
}
-   buf[1][0] = g_u;
+   buf[1][0] = g_u_s;
buf[1][1] = b_v;
break;
case V4L2_PIX_FMT_NV21:
case V4L2_PIX_FMT_NV21M:
case V4L2_PIX_FMT_NV61:
case V4L2_PIX_FMT_NV61M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
buf[1][0] = (buf[1][0] + b_v) / 2;
-   buf[1][1] = (buf[1][1] + g_u) / 2;
+   buf[1][1] = (buf[1][1] + g_u_s) / 2;
   

[PATCH 3/6] [media] Documentation: Add Ricardo Ribalda as author

[Ricardo Ribalda Delgado]

My initials were on the Changelog, but there was no link to my mail.

Signed-off-by: Ricardo Ribalda Delgado 
---
 Documentation/DocBook/media/v4l/v4l2.xml | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
b/Documentation/DocBook/media/v4l/v4l2.xml
index f38039b7c338..e09839d56113 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -117,6 +117,17 @@ Remote Controller chapter.
  

   
+
+  
+   Ricardo
+   Ribalda
+   HSV formats and minor fixes.
+   
+ 
+   ricardo.riba...@gmail.com
+ 
+   
+  
 
 
 
-- 
2.8.1

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

Re: [PATCH 5/5] [media] redrat3: add sysfs attributes for hardware specific options

[Mauro Carvalho Chehab]

Hi Sean,

Em Sun, 10 Jul 2016 17:34:39 +0100
Sean Young  escreveu:

> Signed-off-by: Sean Young 

Please always add a description on your patches.

That's said, I'm not sure about this patch.

I don't like adding private APIs, as different hardware manufacturers tend 
to implement the same features on other hardware. Also, this makes userspace
apps full of per-device hacks, with is not a good idea.

So, why adding those as a redrat3-specific sysfs API? Can't we make them
generic enough and add at the LIRC API instead?

The other patches in this series are OK, and were applied already.

Regards,
Mauro

> ---
>  Documentation/ABI/testing/sysfs-class-rc-redrat3 |  33 
>  drivers/media/rc/redrat3.c   | 200 
> +++
>  2 files changed, 233 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-rc-redrat3
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-rc-redrat3 
> b/Documentation/ABI/testing/sysfs-class-rc-redrat3
> new file mode 100644
> index 000..33a24fa
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-rc-redrat3
> @@ -0,0 +1,33 @@
> +What:/sys/class/rc/rcN/length_fuzz
> +Date:Jul 2016
> +KernelVersion:   4.8
> +Contact: Mauro Carvalho Chehab 
> +Description:
> + The redrat3 encodes an IR signal as set of different lengths
> + and a set of indices into those lengths. Writing this file
> + sets how much two lengths must differ before they are
> + considered distinct, the value is specified in microseconds.
> + Default 5, value 0 to 127.
> +
> +What:/sys/class/rc/rcN/min_pause
> +Date:Jul 2016
> +KernelVersion:   4.8
> +Contact: Mauro Carvalho Chehab 
> +Description:
> + When receiving a continuous ir stream (for example when a user
> + is holding a button down on a remote), this specifies the
> + minimum size of a space when the redrat3 sends a irdata packet
> + to the host. Specified in miliseconds. Default value 18ms.
> + The value can be between 2 and 30 inclusive.
> +
> +What:/sys/class/rc/rcN/periods_measure_carrier
> +Date:Jul 2016
> +KernelVersion:   4.8
> +Contact: Mauro Carvalho Chehab 
> +Description:
> + The carrier frequency is measured during the first pulse of
> + the IR signal. The larger the number of periods used To
> + measure, the more accurate the result is likely to be, however
> + some signals have short initial pulses, so in some case it
> + may be necessary for applications to reduce this value.
> + Default 8, value 1 to 255.
> diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
> index 399f44d..8365547 100644
> --- a/drivers/media/rc/redrat3.c
> +++ b/drivers/media/rc/redrat3.c
> @@ -860,6 +860,195 @@ static void redrat3_led_complete(struct urb *urb)
>   atomic_dec(>flash);
>  }
>  
> +static ssize_t min_pause_store(struct device *dev,
> +  struct device_attribute *attr,
> +  const char *buf, size_t len)
> +{
> + struct rc_dev *rc_dev = to_rc_dev(dev);
> + struct redrat3_dev *rr3 = rc_dev->priv;
> + struct usb_device *udev = rr3->udev;
> + long value;
> + u8 *pause;
> + int rc;
> +
> + rc = kstrtol(buf, 0, );
> + if (rc)
> + return rc;
> +
> + if (value < 2 || value > 30)
> + return -EINVAL;
> +
> + pause = kmalloc(sizeof(*pause), GFP_KERNEL);
> + if (!pause)
> + return -ENOMEM;
> +
> + *pause = (65536 - (value * 2000)) / 256;
> + rc = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), RR3_SET_IR_PARAM,
> +  USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
> +  RR3_IR_IO_MIN_PAUSE, 0, pause, sizeof(*pause), HZ * 25);
> + dev_dbg(dev, "set ir parm min pause %d rc 0x%02x\n", *pause, rc);
> + if (rc == sizeof(*pause))
> + rc = len;
> +
> + kfree(pause);
> +
> + return rc;
> +}
> +
> +static ssize_t min_pause_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct rc_dev *rc_dev = to_rc_dev(dev);
> + struct redrat3_dev *rr3 = rc_dev->priv;
> + struct usb_device *udev = rr3->udev;
> + int rc;
> + u8 *pause;
> +
> + pause = kmalloc(sizeof(*pause), GFP_KERNEL);
> + if (!pause)
> + return -ENOMEM;
> +
> + rc = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), RR3_GET_IR_PARAM,
> +  USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
> +  RR3_IR_IO_MIN_PAUSE, 0, pause, sizeof(*pause), HZ * 25);
> + dev_dbg(dev, "get ir parm len pause %d rc 0x%02x\n", 

[PATCH 2/2] s5p-cec/TODO: add TODO item

[Hans Verkuil]

From: Hans Verkuil 

Mention that the HDMI driver should pass on the physical address
to this driver, rather than requiring userspace to do this.

Signed-off-by: Hans Verkuil 
Cc: Kamil Debski 
Cc: Marek Szyprowski 
---
 drivers/staging/media/s5p-cec/TODO | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/s5p-cec/TODO 
b/drivers/staging/media/s5p-cec/TODO
index 7162f9a..f51d526 100644
--- a/drivers/staging/media/s5p-cec/TODO
+++ b/drivers/staging/media/s5p-cec/TODO
@@ -1,3 +1,7 @@
-There's nothing wrong on this driver, except that it depends on
-the media staging core, that it is currently at staging. So,
-this should be kept here while the core is not promoted.
+This driver depends on the CEC framework, which is currently in
+staging, so therefor this driver is in staging as well.
+
+In addition, this driver requires that userspace sets the physical
+address. However, this should be passed on from the corresponding
+samsung HDMI driver. It is very annoying if userspace has to do this,
+and other than USB CEC adapters this must be handled automatically.
-- 
2.8.1

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

[PATCH 1/2] cec/TODO: drop comment about sphinx documentation

[Hans Verkuil]

From: Hans Verkuil 

The CEC documentation has been converted to sphinx, so this
TODO item can be dropped.

Signed-off-by: Hans Verkuil 
---
 drivers/staging/media/cec/TODO | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/media/cec/TODO b/drivers/staging/media/cec/TODO
index 8221d44..a10d4f8 100644
--- a/drivers/staging/media/cec/TODO
+++ b/drivers/staging/media/cec/TODO
@@ -14,7 +14,6 @@ Other TODOs:
 
 - Add a flag to inhibit passing CEC RC messages to the rc subsystem.
   Applications should be able to choose this when calling S_LOG_ADDRS.
-- Convert cec.txt to sphinx.
 - If the reply field of cec_msg is set then when the reply arrives it
   is only sent to the filehandle that transmitted the original message
   and not to any followers. Should this behavior change or perhaps
-- 
2.8.1

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

cec: set timestamp for selfie transmits

[Hans Verkuil]

Attempts to send CEC messages to yourself are detected in the framework and
returned with a NACK error. However, the tx_ts was never filled in that case.
So just set it.

Signed-off-by: Hans Verkuil 

diff --git a/drivers/staging/media/cec/cec-adap.c 
b/drivers/staging/media/cec/cec-adap.c
index ca34339..bf25875 100644
--- a/drivers/staging/media/cec/cec-adap.c
+++ b/drivers/staging/media/cec/cec-adap.c
@@ -612,6 +612,7 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct 
cec_msg *msg,
 * easy to handle it here so the behavior will be
 * consistent.
 */
+   msg->tx_ts = ktime_get_ns();
msg->tx_status = CEC_TX_STATUS_NACK |
 CEC_TX_STATUS_MAX_RETRIES;
msg->tx_nack_cnt = 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2 v2] Add GS1662 driver, a video serializer

[Charles-Antoine Couret]

>From 111c02ef44dc1588891b40337fb0669fa586ec50 Mon Sep 17 00:00:00 2001
From: Charles-Antoine Couret 
Date: Fri, 15 Jul 2016 15:06:43 +0200
Subject: [PATCH 2/2] Add GS1662 driver, a video serializer

You can read datasheet here:
http://www.c-dis.net/media/871/GS1662_Datasheet.pdf

It's a component which supports HD and SD CEA or SDI formats
to SDI output. It's configured through SPI bus.

GS1662 driver is implemented as v4l2 subdev.

Signed-off-by: Charles-Antoine Couret 
---
 drivers/media/Kconfig  |   1 +
 drivers/media/Makefile |   2 +-
 drivers/media/spi/Kconfig  |   5 +
 drivers/media/spi/Makefile |   1 +
 drivers/media/spi/gs1662.c | 460 +
 5 files changed, 468 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/spi/Kconfig
 create mode 100644 drivers/media/spi/Makefile
 create mode 100644 drivers/media/spi/gs1662.c

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index a8518fb..d2fa6e7 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -215,5 +215,6 @@ config MEDIA_ATTACH
 source "drivers/media/i2c/Kconfig"
 source "drivers/media/tuners/Kconfig"
 source "drivers/media/dvb-frontends/Kconfig"
+source "drivers/media/spi/Kconfig"
 
 endif # MEDIA_SUPPORT
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index e608bbc..75bc82e 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -28,6 +28,6 @@ obj-y += rc/
 # Finally, merge the drivers that require the core
 #
 
-obj-y += common/ platform/ pci/ usb/ mmc/ firewire/
+obj-y += common/ platform/ pci/ usb/ mmc/ firewire/ spi/
 obj-$(CONFIG_VIDEO_DEV) += radio/
 
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..df626cb
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,5 @@
+config VIDEO_GS1662
+   tristate "Gennum Serializers video"
+   depends on SPI
+   ---help---
+ Enable the GS1662 driver which serializes video streams.
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..ea64013
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_GS1662) += gs1662.o
diff --git a/drivers/media/spi/gs1662.c b/drivers/media/spi/gs1662.c
new file mode 100644
index 000..783ab82
--- /dev/null
+++ b/drivers/media/spi/gs1662.c
@@ -0,0 +1,460 @@
+/*
+ * GS1662 device registration.
+ *
+ * Copyright (C) 2015-2016 Nexvision
+ * Author: Charles-Antoine Couret 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_STATUS 0x04
+#define REG_FORCE_FMT  0x06
+#define REG_LINES_PER_FRAME0x12
+#define REG_WORDS_PER_LINE 0x13
+#define REG_WORDS_PER_ACT_LINE 0x14
+#define REG_ACT_LINES_PER_FRAME0x15
+
+#define MASK_H_LOCK0x001
+#define MASK_V_LOCK0x002
+#define MASK_STD_LOCK  0x004
+#define MASK_FORCE_STD 0x020
+#define MASK_STD_STATUS0x3E0
+
+#define GS_WIDTH_MIN 0
+#define GS_WIDTH_MAX 2048
+#define GS_HEIGHT_MIN 0
+#define GS_HEIGHT_MAX 1080
+#define GS_PIXELCLOCK_MIN 10519200
+#define GS_PIXELCLOCK_MAX 7425
+
+struct gs {
+   struct spi_device *pdev;
+   struct v4l2_subdev sd;
+   struct v4l2_dv_timings current_timings;
+   int enabled;
+};
+
+struct gs_reg_fmt {
+   u16 reg_value;
+   struct v4l2_dv_timings format;
+};
+
+struct gs_reg_fmt_custom {
+   u16 reg_value;
+   __u32 width;
+   __u32 height;
+   __u64 pixelclock;
+   __u32 interlaced;
+};
+
+static const struct spi_device_id gs_id[] = {
+   { "gs1662", 0 },
+   { }
+};
+MODULE_DEVICE_TABLE(spi, gs_id);
+
+static const struct v4l2_dv_timings fmt_cap[] = {
+   V4L2_DV_BT_SDI_720X487I60,
+   V4L2_DV_BT_CEA_720X576P50,
+   V4L2_DV_BT_CEA_1280X720P24,
+   V4L2_DV_BT_CEA_1280X720P25,
+   V4L2_DV_BT_CEA_1280X720P30,
+   V4L2_DV_BT_CEA_1280X720P50,
+   V4L2_DV_BT_CEA_1280X720P60,
+   V4L2_DV_BT_CEA_1920X1080P24,
+   V4L2_DV_BT_CEA_1920X1080P25,
+   V4L2_DV_BT_CEA_1920X1080P30,
+   V4L2_DV_BT_CEA_1920X1080I50,
+   V4L2_DV_BT_CEA_1920X1080I60,
+};
+
+static const struct gs_reg_fmt reg_fmt[] = {
+   { 0x00, V4L2_DV_BT_CEA_1280X720P60 },
+   { 0x01, V4L2_DV_BT_CEA_1280X720P60 },
+   { 0x02, V4L2_DV_BT_CEA_1280X720P30 },
+   { 0x03, V4L2_DV_BT_CEA_1280X720P30 },
+   { 0x04, V4L2_DV_BT_CEA_1280X720P50 },
+ 

[PATCH 1/1] media: platform: ti-vpe: call of_node_put on non-null pointer

[Peter Chen]

It should call of_node_put on non-null poiner.

Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab 
Cc: Benoit Parrot 
Signed-off-by: Peter Chen 
---
 drivers/media/platform/ti-vpe/cal.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
index 82001e6..00c3e97 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -1761,13 +1761,13 @@ static int of_cal_create_instance(struct cal_ctx *ctx, 
int inst)
}
 
 cleanup_exit:
-   if (!remote_ep)
+   if (remote_ep)
of_node_put(remote_ep);
-   if (!sensor_node)
+   if (sensor_node)
of_node_put(sensor_node);
-   if (!ep_node)
+   if (ep_node)
of_node_put(ep_node);
-   if (!port)
+   if (port)
of_node_put(port);
 
return ret;
-- 
1.9.1

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

[RFC PATCH] serio: add hangup support

[Hans Verkuil]

For the upcoming 4.8 kernel I made a driver for the Pulse-Eight USB CEC adapter.
This is a usb device that shows up as a ttyACM0 device. It requires that you run
inputattach in order to communicate with it via serio.

This all works well, but it would be nice to have a udev rule to automatically
start inputattach. That too works OK, but the problem comes when the USB device
is unplugged: the tty hangup is never handled by the serio framework so the
inputattach utility never exits and you have to kill it manually.

By adding this hangup callback the inputattach utility now exists as soon as I
unplug the USB device.

Is this the correct approach?

BTW, the new driver is found here:

https://git.linuxtv.org/media_tree.git/tree/drivers/staging/media/pulse8-cec

Regards,

Hans

Signed-off-by: Hans Verkuil 

---
diff --git a/drivers/input/serio/serport.c b/drivers/input/serio/serport.c
index 9c927d3..a615846 100644
--- a/drivers/input/serio/serport.c
+++ b/drivers/input/serio/serport.c
@@ -248,6 +248,14 @@ static long serport_ldisc_compat_ioctl(struct tty_struct 
*tty,
 }
 #endif

+static int serport_ldisc_hangup(struct tty_struct * tty)
+{
+   struct serport *serport = (struct serport *) tty->disc_data;
+
+   serport_serio_close(serport->serio);
+   return 0;
+}
+
 static void serport_ldisc_write_wakeup(struct tty_struct * tty)
 {
struct serport *serport = (struct serport *) tty->disc_data;
@@ -274,6 +282,7 @@ static struct tty_ldisc_ops serport_ldisc = {
.compat_ioctl = serport_ldisc_compat_ioctl,
 #endif
.receive_buf =  serport_ldisc_receive,
+   .hangup =   serport_ldisc_hangup,
.write_wakeup = serport_ldisc_write_wakeup
 };

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

Trying to pass the port number to udev for a multiport DVB card

[David Howells]

Hi,

Can someone give me a hand with unpicking the tangle of spaghetti that's the
DVB core?

Attached is a patch that can pass various attributes, including,
theoretically, the port number of the separate ports of a multiport card, such
as the DVBSky S952 and T982 cards, so that udev can create persistent names.

However, the port number I've added to the dvb_adapter struct is always seen
as zero in the attribute function I've written.  Putting in some printks shows
that the dvb_adapter struct seen in the attribute struct has a *different*
address to the one seen in dvb_register() in cx23885-dvb.c.  Does anyone know
what's going on?  I should also add that the MAC address *does* go through,
though I can't see where it's copied.

David
---
commit c100b0ddc9436152e770a80eedfdd90644c1ee3d
Author: David Howells 
Date:   Wed Jul 13 23:05:34 2016 +0100

dvb: Save port number and provide sysfs attributes to pass values to udev

Some devices, such as the DVBSky S952 and T982 cards, are dual port cards
that provide two cx23885 devices on the same PCI device, which means the
attributes available for writing udev rules are exactly the same, apart
from the adapter number.  Unfortunately, the adapter numbers are dependent
on the order in which things are initialised, so this can change over
different releases of the kernel.

The struct cx23885_tsport has a port number available, which is printed
during boot:

[   10.951517] DVBSky T982 port 1 MAC address: 00:17:42:54:09:87
...
[   10.984875] DVBSky T982 port 2 MAC address: 00:17:42:54:09:88

To make it possible to distinguish these in udev, do the following steps:

 (1) Save the port number into struct dvb_adapter.

 (2) Provide sysfs attributes to export port number and also MAC address,
 adapter number and type.  There are other fields that could perhaps be
 exported also.

The new sysfs attributes can be seen from userspace as:

[root@deneb ~]# ls /sys/class/dvb/dvb0.frontend0/
dev  device  dvb_adapter  dvb_mac  dvb_port  dvb_type
power  subsystem  uevent
[root@deneb ~]# cat /sys/class/dvb/dvb0.frontend0/dvb_*
0
00:17:42:54:09:87
0
frontend

They can be used in udev rules:

SUBSYSTEM=="dvb", ATTRS{vendor}=="0x14f1", ATTRS{device}=="0x8852", 
ATTRS{subsystem_device}=="0x0982", ATTR{dvb_mac}=="00:17:42:54:09:87", 
PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter9820/%%s $${K#*.}'", 
SYMLINK+="%c"
SUBSYSTEM=="dvb", ATTRS{vendor}=="0x14f1", ATTRS{device}=="0x8852", 
ATTRS{subsystem_device}=="0x0982", ATTR{dvb_mac}=="00:17:42:54:09:88", 
PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter9821/%%s $${K#*.}'", 
SYMLINK+="%c"

where the match is made with ATTR{dvb_mac} or similar.  The rules above
make symlinks from /dev/dvb/adapter982/* to /dev/dvb/adapterXX/*.

Note that binding the dvb-net device to a network interface and changing it
there does not reflect back into the the dvb_adapter struct and doesn't
change the MAC address here.  This means that a system with two identical
cards in it may need to distinguish them by some other means than MAC
address.

Signed-off-by: David Howells 

diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 75a3f4b57fd4..638719483167 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -901,6 +901,51 @@ out:
return err;
 }
 
+static ssize_t dvb_adapter_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dvb_device *dvbdev = dev_get_drvdata(dev);
+
+   return sprintf(buf, "%d\n", dvbdev->adapter->num);
+}
+static DEVICE_ATTR_RO(dvb_adapter);
+
+static ssize_t dvb_mac_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dvb_device *dvbdev = dev_get_drvdata(dev);
+
+   return sprintf(buf, "%pM\n", dvbdev->adapter->proposed_mac);
+}
+static DEVICE_ATTR_RO(dvb_mac);
+
+static ssize_t dvb_port_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   struct dvb_device *dvbdev = dev_get_drvdata(dev);
+
+   return sprintf(buf, "%d\n", dvbdev->adapter->port_num);
+}
+static DEVICE_ATTR_RO(dvb_port);
+
+static ssize_t dvb_type_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   struct dvb_device *dvbdev = dev_get_drvdata(dev);
+
+   return sprintf(buf, "%s\n", dnames[dvbdev->type]);
+}
+static DEVICE_ATTR_RO(dvb_type);
+
+static struct attribute *dvb_class_attrs[] = {
+   _attr_dvb_adapter.attr,
+   _attr_dvb_mac.attr,
+   _attr_dvb_port.attr,
+   _attr_dvb_type.attr,
+   NULL
+};

[PATCH] doc-rst: Fix compilation of the pdf docbook

[Mauro Carvalho Chehab]

The rst2pdf tool is a very broken toolchain, with is not capable
of parsing complex documents. As such, it doesn't build the
media book, failing with:

[ERROR] pdfbuilder.py:130 too many values to unpack

(using rst2pdf version 0.93.dev-r0 and Sphinx version 1.4.5)

So, make it build only the books we know that are safe to build.

Signed-off-by: Mauro Carvalho Chehab 

--

Btw, with the standard Sphinx version shipped on Fedora 24 (Sphinx
1.3.1), rst2pdf doesn't build even the simple kernel-documentation,
failing with this error:
writing Kernel... [ERROR] pdfbuilder.py:130 list index out of range

This is a known bug:
https://github.com/sphinx-doc/sphinx/issues/1844

So, maybe we should just disable pdf generation from RST for good,
as I suspect that maintaining it with a broken toolchain will be a
big headache.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/conf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 224240b5bc50..96b7aa66c89c 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -411,7 +411,7 @@ epub_exclude_files = ['search.html']
 # multiple PDF files here actually tries to get the cross-referencing right
 # *between* PDF files.
 pdf_documents = [
-('index', u'Kernel', u'Kernel', u'J. Random Bozo'),
+('kernel-documentation', u'Kernel', u'Kernel', u'J. Random Bozo'),
 ]
 
 # kernel-doc extension configuration for running Sphinx directly (e.g. by Read
-- 
2.7.4


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

Re: DRM device memory writeback (Mali-DP)

[Ville Syrjälä]

On Fri, Jul 15, 2016 at 10:09:19AM +0100, Brian Starkey wrote:
> Hi Daniel,
> 
> Thanks for taking a look.
> 
> (+Cc Laurent)
> 
> On Fri, Jul 15, 2016 at 09:33:34AM +0200, Daniel Vetter wrote:
> >On Thu, Jul 14, 2016 at 06:03:40PM +0100, Brian Starkey wrote:
> >> Hi,
> >>
> >> The Mali-DP display processors have a memory-writeback engine which
> >> can write the result of the composition (CRTC output) to a memory
> >> buffer in a variety of formats.
> >>
> >> We're looking for feedback/suggestions on how to expose this in the
> >> mali-dp DRM kernel driver - possibly via V4L2.
> >>
> >> We've got a few use cases where writeback is useful:
> >>- testing, to check the displayed image
> >
> >This might or might not need a separate interface. There are efforts to
> >make the intel kms validation tests in i-g-t generic (well under way
> >already), and part of that is creating a generic infrastructure to capture
> >display CRCs for functional tests (still in progress).
> >
> >But it might be better if userspace abstracts between full readback and
> >display CRC, assuming we can make full writeback cross-vendor enough for
> >that use-case.
> >
> 
> I'd lean towards the userspace abstraction.
> Encumbering a simple CRC interface with all the complexity of
> full-writeback (size, scaling, pixel format, multi-planar etc.) sounds
> a bit unnecessary.
> 
> Of course, if v4l2 isn't going to be the cross-vendor full-writeback
> implementation, then we need to be aiming to use whatever _is_ in
> the mali-dp driver.
> 
> >>- screen recording
> >>- wireless display (e.g. Miracast)
> >>- dual-display clone mode
> >>- memory-to-memory composition
> >> Note that the HW is capable of writing one of the input planes instead
> >> of the CRTC output, but we've no good use-case for wanting to expose
> >> that.
> >>
> >> In our Android ADF driver[1] we exposed the memory write engine as
> >> part of the ADF device using ADF's "MEMORY" interface type. DRM/KMS
> >> doesn't have any similar support for memory output from CRTCs, but we
> >> want to expose the functionality in the mainline Mali-DP DRM driver.
> >>
> >> A previous discussion on the topic went towards exposing the
> >> memory-write engine via V4L2[2].
> >>
> >> I'm thinking to userspace this would look like two distinct devices:
> >>- A DRM KMS display controller.
> >>- A V4L2 video source.
> >> They'd both exist in the same kernel driver.
> >> A V4L2 client can queue up (CAPTURE) buffers in the normal way, and
> >> the DRM driver would see if there's a buffer to dequeue every time a
> >> new modeset is received via the DRM API - if so, it can configure the
> >> HW to dump into it (one-shot operation).
> >>
> >> An implication of this is that if the screen is actively displaying a
> >> static scene and the V4L2 client queues up a buffer, it won't get
> >> filled until the DRM scene changes. This seems best, otherwise the
> >> V4L2 driver has to change the HW configuration out-of-band from the
> >> DRM device which sounds horribly racy.
> >>
> >> One further complication is scaling. Our HW has a scaler which can
> >> tasked with either scaling an input plane or the buffer being written
> >> to memory, but not both at the same time. This means we need to
> >> arbitrate the scaler between the DRM device (scaling input planes) and
> >> the V4L2 device (scaling output buffers).
> >>
> >> I think the simplest approach here is to allow V4L2 to "claim" the
> >> scaler by setting the image size (VIDIOC_S_FMT) to something other
> >> than the CRTC's current resolution. After that, any attempt to use the
> >> scaler on an input plane via DRM should fail atomic_check().
> >
> >That's perfectly fine atomic_check behaviour. Only trouble is that the v4l
> >locking must integrate into the drm locking, but that should be doable.
> >Worst case you must shadow all v4l locks with a wait/wound
> >drm_modeset_lock to avoid deadlocks (since you could try to grab locks
> >from either end).
> >
> 
> Yes, I haven't looked at the details of the locking but I'm hoping
> it's manageable.
> 
> >> If the V4L2 client goes away or sets the image size to the CRTC's
> >> native resolution, then the DRM device is allowed to use the scaler.
> >> I don't know if/how the DRM device should communicate to userspace
> >> that the scaler is or isn't available for use.
> >>
> >> Any thoughts on this approach?
> >> Is it acceptable to both V4L2 and DRM folks?
> >
> >For streaming a V4L2 capture device seems like the right interface. But if
> >you want to use writeback in your compositor you must know which atomic
> >kms update results in which frame, since if you don't you can't use that
> >composited buffer for the next frame reliable.
> >
> >For that case I think a drm-only solution would be better, to make sure
> >you can do an atomic update and writeback in one step. v4l seems to grow
> >an atomic api of its own, but I don't think we'll have one spanning
> >subsystems anytime soon.

Re: [PATCH] af9035: fix dual tuner detection with PCTV 79e

[Mauro Carvalho Chehab]

Em Fri, 15 Jul 2016 09:21:51 +0300
Antti Palosaari  escreveu:

> Applied and PULL requested for 4.7.

It is too late to be applied on 4.7. I can apply it to the next merge
window.

> 
> Anyhow, it does not apply for 4.6. You must backport that patch to 4.6 
> stable also!
> 
> regards
> Antti
> 
> On 07/11/2016 08:31 PM, Stefan Pöschel wrote:
> > The value 5 of the EEPROM_TS_MODE register (meaning dual tuner presence) is
> > only valid for AF9035 devices. For IT9135 devices it is invalid and led to a
> > false positive dual tuner mode detection with PCTV 79e.
> > Therefore on non-AF9035 devices and with value 5 the driver now defaults to
> > single tuner mode and outputs a regarding info message to log.
> >
> > This fixes Bugzilla bug #118561.
> >
> > Reported-by: Marc Duponcheel 
> > Signed-off-by: Stefan Pöschel 
> > ---
> >  drivers/media/usb/dvb-usb-v2/af9035.c | 50 
> > +++
> >  drivers/media/usb/dvb-usb-v2/af9035.h |  2 +-
> >  2 files changed, 34 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c 
> > b/drivers/media/usb/dvb-usb-v2/af9035.c
> > index eabede4..ca018cd 100644
> > --- a/drivers/media/usb/dvb-usb-v2/af9035.c
> > +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
> > @@ -496,7 +496,8 @@ static int af9035_identify_state(struct dvb_usb_device 
> > *d, const char **name)
> >  {
> > struct state *state = d_to_priv(d);
> > struct usb_interface *intf = d->intf;
> > -   int ret;
> > +   int ret, ts_mode_invalid;
> > +   u8 tmp;
> > u8 wbuf[1] = { 1 };
> > u8 rbuf[4];
> > struct usb_req req = { CMD_FW_QUERYINFO, 0, sizeof(wbuf), wbuf,
> > @@ -530,6 +531,36 @@ static int af9035_identify_state(struct dvb_usb_device 
> > *d, const char **name)
> > state->eeprom_addr = EEPROM_BASE_AF9035;
> > }
> >
> > +
> > +   /* check for dual tuner mode */
> > +   ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
> > +   if (ret < 0)
> > +   goto err;
> > +
> > +   ts_mode_invalid = 0;
> > +   switch (tmp) {
> > +   case 0:
> > +   break;
> > +   case 1:
> > +   case 3:
> > +   state->dual_mode = true;
> > +   break;
> > +   case 5:
> > +   if (state->chip_type != 0x9135 && state->chip_type != 0x9306)
> > +   state->dual_mode = true;/* AF9035 */
> > +   else
> > +   ts_mode_invalid = 1;
> > +   break;
> > +   default:
> > +   ts_mode_invalid = 1;
> > +   }
> > +
> > +   dev_dbg(>dev, "ts mode=%d dual mode=%d\n", tmp, state->dual_mode);
> > +
> > +   if (ts_mode_invalid)
> > +   dev_info(>dev, "ts mode=%d not supported, defaulting to 
> > single tuner mode!", tmp);
> > +
> > +
> > ret = af9035_ctrl_msg(d, );
> > if (ret < 0)
> > goto err;
> > @@ -698,11 +729,7 @@ static int af9035_download_firmware(struct 
> > dvb_usb_device *d,
> >  * which is done by master demod.
> >  * Master feeds also clock and controls power via GPIO.
> >  */
> > -   ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
> > -   if (ret < 0)
> > -   goto err;
> > -
> > -   if (tmp == 1 || tmp == 3 || tmp == 5) {
> > +   if (state->dual_mode) {
> > /* configure gpioh1, reset & power slave demod */
> > ret = af9035_wr_reg_mask(d, 0x00d8b0, 0x01, 0x01);
> > if (ret < 0)
> > @@ -835,17 +862,6 @@ static int af9035_read_config(struct dvb_usb_device *d)
> > }
> >
> >
> > -
> > -   /* check if there is dual tuners */
> > -   ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
> > -   if (ret < 0)
> > -   goto err;
> > -
> > -   if (tmp == 1 || tmp == 3 || tmp == 5)
> > -   state->dual_mode = true;
> > -
> > -   dev_dbg(>dev, "ts mode=%d dual mode=%d\n", tmp, state->dual_mode);
> > -
> > if (state->dual_mode) {
> > /* read 2nd demodulator I2C address */
> > ret = af9035_rd_reg(d,
> > diff --git a/drivers/media/usb/dvb-usb-v2/af9035.h 
> > b/drivers/media/usb/dvb-usb-v2/af9035.h
> > index c91d1a3..1f83c92 100644
> > --- a/drivers/media/usb/dvb-usb-v2/af9035.h
> > +++ b/drivers/media/usb/dvb-usb-v2/af9035.h
> > @@ -113,7 +113,7 @@ static const u32 clock_lut_it9135[] = {
> >   * 0  TS
> >   * 1  DCA + PIP
> >   * 3  PIP
> > - * 5  DCA + PIP
> > + * 5  DCA + PIP (AF9035 only)
> >   * n  DCA
> >   *
> >   * Values 0, 3 and 5 are seen to this day. 0 for single TS and 3/5 for 
> > dual TS.
> >  
> 



Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 00/16] Make use of kref in media device, grab references as needed

[Mauro Carvalho Chehab]

Em Fri, 15 Jul 2016 01:34:55 +0300
Sakari Ailus  escreveu:

> Hi folks,
> 
> I've been working on this for some time now but only got the full patchset
> working some moments ago. The patchset properly, I believe, fixes the
> issue of removing a device whilst streaming.
> 
> Media device is refcounted and its memory is only released once the last
> reference is gone: unregistering is simply unregistering, it no longer
> should release memory which could be further accessed.
> 
> A video node or a sub-device node also gets a reference to the media
> device, i.e. the release function of the video device node will release
> its reference to the media device. The same goes for file handles to the
> media device.
> 
> As a side effect of refcounting the media device, it is allocate together
> with the media devnode. The driver may also rely its own resources to the
> media device. Alternatively there's also a priv field to hold drivers
> private pointer (for container_of() is an option in this case).
> 
> I've tested this by manually unbinding the omap3isp platform device while
> streaming. Driver changes are required for this to work; by not using
> dynamic allocation (i.e. media_device_alloc()) the old behaviour is still
> supported. This is still unlikely to be a grave problem as there are not
> that many device drivers that support physically removable devices. We've
> had this problem for other devices for many years without paying much
> notice --- that doesn't mean I don't think at least drivers for removable
> devices shouldn't be changed as part of the set later on, I'd just like to
> get review comments on the approach first.
> 
> The three patches that originally partially resolved some of these issues
> are reverted in the beginning of the set. I'm still posting this as an RFC
> mainly since the testing is somewhat limited so far.


I didn't look inside this patch series. Won't likely have time to
look at core changes before the end of the merge window. However,
I found several structural problems on this RFC:

1) Please do incremental changes, instead of reverting patches. It is
really hard for reviewers to be sure that nothing breaks when someone
simply reverts a previous approach and add its own.

2) Each individual patch should not cause regressions to none of
the existing drivers or to the core. The revert re-introduces bugs.

3) Each patch should not break compilation. Patch 06/16, for example,
changes the structure used by the release method:

-static void media_device_release(struct media_devnode *mdev)
+static void media_device_release(struct media_devnode *devnode)

Without touching a single driver. That means compilation breakages.
This is not acceptable upstream.

It should be touching *all* drivers that use the function altogether.

4) From a very quick look at the series, without trying to compile the
series (with would very likely break), it seems that all drivers that
uses the media controller should be migrated to the new way.

It means that you'll need to patch all drivers altogether as you're
changing the kAPI at the same patch you change it.

So, please rework your patch series to make it easier for everybody
to review and test it.

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DRM device memory writeback (Mali-DP)

[Brian Starkey]

Hi Daniel,

Thanks for taking a look.

(+Cc Laurent)

On Fri, Jul 15, 2016 at 09:33:34AM +0200, Daniel Vetter wrote:

On Thu, Jul 14, 2016 at 06:03:40PM +0100, Brian Starkey wrote:

Hi,

The Mali-DP display processors have a memory-writeback engine which
can write the result of the composition (CRTC output) to a memory
buffer in a variety of formats.

We're looking for feedback/suggestions on how to expose this in the
mali-dp DRM kernel driver - possibly via V4L2.

We've got a few use cases where writeback is useful:
   - testing, to check the displayed image


This might or might not need a separate interface. There are efforts to
make the intel kms validation tests in i-g-t generic (well under way
already), and part of that is creating a generic infrastructure to capture
display CRCs for functional tests (still in progress).

But it might be better if userspace abstracts between full readback and
display CRC, assuming we can make full writeback cross-vendor enough for
that use-case.



I'd lean towards the userspace abstraction.
Encumbering a simple CRC interface with all the complexity of
full-writeback (size, scaling, pixel format, multi-planar etc.) sounds
a bit unnecessary.

Of course, if v4l2 isn't going to be the cross-vendor full-writeback
implementation, then we need to be aiming to use whatever _is_ in
the mali-dp driver.


   - screen recording
   - wireless display (e.g. Miracast)
   - dual-display clone mode
   - memory-to-memory composition
Note that the HW is capable of writing one of the input planes instead
of the CRTC output, but we've no good use-case for wanting to expose
that.

In our Android ADF driver[1] we exposed the memory write engine as
part of the ADF device using ADF's "MEMORY" interface type. DRM/KMS
doesn't have any similar support for memory output from CRTCs, but we
want to expose the functionality in the mainline Mali-DP DRM driver.

A previous discussion on the topic went towards exposing the
memory-write engine via V4L2[2].

I'm thinking to userspace this would look like two distinct devices:
   - A DRM KMS display controller.
   - A V4L2 video source.
They'd both exist in the same kernel driver.
A V4L2 client can queue up (CAPTURE) buffers in the normal way, and
the DRM driver would see if there's a buffer to dequeue every time a
new modeset is received via the DRM API - if so, it can configure the
HW to dump into it (one-shot operation).

An implication of this is that if the screen is actively displaying a
static scene and the V4L2 client queues up a buffer, it won't get
filled until the DRM scene changes. This seems best, otherwise the
V4L2 driver has to change the HW configuration out-of-band from the
DRM device which sounds horribly racy.

One further complication is scaling. Our HW has a scaler which can
tasked with either scaling an input plane or the buffer being written
to memory, but not both at the same time. This means we need to
arbitrate the scaler between the DRM device (scaling input planes) and
the V4L2 device (scaling output buffers).

I think the simplest approach here is to allow V4L2 to "claim" the
scaler by setting the image size (VIDIOC_S_FMT) to something other
than the CRTC's current resolution. After that, any attempt to use the
scaler on an input plane via DRM should fail atomic_check().


That's perfectly fine atomic_check behaviour. Only trouble is that the v4l
locking must integrate into the drm locking, but that should be doable.
Worst case you must shadow all v4l locks with a wait/wound
drm_modeset_lock to avoid deadlocks (since you could try to grab locks
from either end).



Yes, I haven't looked at the details of the locking but I'm hoping
it's manageable.


If the V4L2 client goes away or sets the image size to the CRTC's
native resolution, then the DRM device is allowed to use the scaler.
I don't know if/how the DRM device should communicate to userspace
that the scaler is or isn't available for use.

Any thoughts on this approach?
Is it acceptable to both V4L2 and DRM folks?


For streaming a V4L2 capture device seems like the right interface. But if
you want to use writeback in your compositor you must know which atomic
kms update results in which frame, since if you don't you can't use that
composited buffer for the next frame reliable.

For that case I think a drm-only solution would be better, to make sure
you can do an atomic update and writeback in one step. v4l seems to grow
an atomic api of its own, but I don't think we'll have one spanning
subsystems anytime soon.



I've been thinking about this from the point of view of a HWComposer
implementation and I think the hybrid DRM-V4L2 device would work OK.
However it depends on the behaviour I mentioned above:


if the screen is actively displaying a
static scene and the V4L2 client queues up a buffer, it won't get
filled until the DRM scene changes.


V4L2 buffer queues are FIFO, so as long as the compositor queues only
one V4L2 buffer per atomic update, there's no 

Re: DRM device memory writeback (Mali-DP)

[Daniel Vetter]

On Thu, Jul 14, 2016 at 06:03:40PM +0100, Brian Starkey wrote:
> Hi,
> 
> The Mali-DP display processors have a memory-writeback engine which
> can write the result of the composition (CRTC output) to a memory
> buffer in a variety of formats.
> 
> We're looking for feedback/suggestions on how to expose this in the
> mali-dp DRM kernel driver - possibly via V4L2.
> 
> We've got a few use cases where writeback is useful:
>- testing, to check the displayed image

This might or might not need a separate interface. There are efforts to
make the intel kms validation tests in i-g-t generic (well under way
already), and part of that is creating a generic infrastructure to capture
display CRCs for functional tests (still in progress).

But it might be better if userspace abstracts between full readback and
display CRC, assuming we can make full writeback cross-vendor enough for
that use-case.

>- screen recording
>- wireless display (e.g. Miracast)
>- dual-display clone mode
>- memory-to-memory composition
> Note that the HW is capable of writing one of the input planes instead
> of the CRTC output, but we've no good use-case for wanting to expose
> that.
> 
> In our Android ADF driver[1] we exposed the memory write engine as
> part of the ADF device using ADF's "MEMORY" interface type. DRM/KMS
> doesn't have any similar support for memory output from CRTCs, but we
> want to expose the functionality in the mainline Mali-DP DRM driver.
> 
> A previous discussion on the topic went towards exposing the
> memory-write engine via V4L2[2].
> 
> I'm thinking to userspace this would look like two distinct devices:
>- A DRM KMS display controller.
>- A V4L2 video source.
> They'd both exist in the same kernel driver.
> A V4L2 client can queue up (CAPTURE) buffers in the normal way, and
> the DRM driver would see if there's a buffer to dequeue every time a
> new modeset is received via the DRM API - if so, it can configure the
> HW to dump into it (one-shot operation).
> 
> An implication of this is that if the screen is actively displaying a
> static scene and the V4L2 client queues up a buffer, it won't get
> filled until the DRM scene changes. This seems best, otherwise the
> V4L2 driver has to change the HW configuration out-of-band from the
> DRM device which sounds horribly racy.
> 
> One further complication is scaling. Our HW has a scaler which can
> tasked with either scaling an input plane or the buffer being written
> to memory, but not both at the same time. This means we need to
> arbitrate the scaler between the DRM device (scaling input planes) and
> the V4L2 device (scaling output buffers).
> 
> I think the simplest approach here is to allow V4L2 to "claim" the
> scaler by setting the image size (VIDIOC_S_FMT) to something other
> than the CRTC's current resolution. After that, any attempt to use the
> scaler on an input plane via DRM should fail atomic_check().

That's perfectly fine atomic_check behaviour. Only trouble is that the v4l
locking must integrate into the drm locking, but that should be doable.
Worst case you must shadow all v4l locks with a wait/wound
drm_modeset_lock to avoid deadlocks (since you could try to grab locks
from either end).

> If the V4L2 client goes away or sets the image size to the CRTC's
> native resolution, then the DRM device is allowed to use the scaler.
> I don't know if/how the DRM device should communicate to userspace
> that the scaler is or isn't available for use.
> 
> Any thoughts on this approach?
> Is it acceptable to both V4L2 and DRM folks?

For streaming a V4L2 capture device seems like the right interface. But if
you want to use writeback in your compositor you must know which atomic
kms update results in which frame, since if you don't you can't use that
composited buffer for the next frame reliable.

For that case I think a drm-only solution would be better, to make sure
you can do an atomic update and writeback in one step. v4l seems to grow
an atomic api of its own, but I don't think we'll have one spanning
subsystems anytime soon.

For the kms-only interface the idea was to add a property on the crtc
where you can attach a writeback drm_framebuffer. Extending that idea to
the drm->v4l case we could create special drm_framebuffer objects
representing a v4l sink, and attach them to the same property. That would
also solve the problem of getting some agreement on buffer metadata
between v4l and drm side.

Laurent had some poc patches a while ago for this, he's definitely the one
to ping.
-Daniel

> 
> Thanks for your time,
> 
> -Brian
> 
> [1] 
> http://malideveloper.arm.com/resources/drivers/open-source-mali-dp-adf-kernel-device-drivers/
> [2] 
> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel=2016-05-04
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, 

Re: [PATCH] af9035: fix dual tuner detection with PCTV 79e

[Antti Palosaari]

Applied and PULL requested for 4.7.

Anyhow, it does not apply for 4.6. You must backport that patch to 4.6 
stable also!


regards
Antti

On 07/11/2016 08:31 PM, Stefan Pöschel wrote:

The value 5 of the EEPROM_TS_MODE register (meaning dual tuner presence) is
only valid for AF9035 devices. For IT9135 devices it is invalid and led to a
false positive dual tuner mode detection with PCTV 79e.
Therefore on non-AF9035 devices and with value 5 the driver now defaults to
single tuner mode and outputs a regarding info message to log.

This fixes Bugzilla bug #118561.

Reported-by: Marc Duponcheel 
Signed-off-by: Stefan Pöschel 
---
 drivers/media/usb/dvb-usb-v2/af9035.c | 50 +++
 drivers/media/usb/dvb-usb-v2/af9035.h |  2 +-
 2 files changed, 34 insertions(+), 18 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c 
b/drivers/media/usb/dvb-usb-v2/af9035.c
index eabede4..ca018cd 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -496,7 +496,8 @@ static int af9035_identify_state(struct dvb_usb_device *d, 
const char **name)
 {
struct state *state = d_to_priv(d);
struct usb_interface *intf = d->intf;
-   int ret;
+   int ret, ts_mode_invalid;
+   u8 tmp;
u8 wbuf[1] = { 1 };
u8 rbuf[4];
struct usb_req req = { CMD_FW_QUERYINFO, 0, sizeof(wbuf), wbuf,
@@ -530,6 +531,36 @@ static int af9035_identify_state(struct dvb_usb_device *d, 
const char **name)
state->eeprom_addr = EEPROM_BASE_AF9035;
}

+
+   /* check for dual tuner mode */
+   ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
+   if (ret < 0)
+   goto err;
+
+   ts_mode_invalid = 0;
+   switch (tmp) {
+   case 0:
+   break;
+   case 1:
+   case 3:
+   state->dual_mode = true;
+   break;
+   case 5:
+   if (state->chip_type != 0x9135 && state->chip_type != 0x9306)
+   state->dual_mode = true; /* AF9035 */
+   else
+   ts_mode_invalid = 1;
+   break;
+   default:
+   ts_mode_invalid = 1;
+   }
+
+   dev_dbg(>dev, "ts mode=%d dual mode=%d\n", tmp, state->dual_mode);
+
+   if (ts_mode_invalid)
+   dev_info(>dev, "ts mode=%d not supported, defaulting to single 
tuner mode!", tmp);
+
+
ret = af9035_ctrl_msg(d, );
if (ret < 0)
goto err;
@@ -698,11 +729,7 @@ static int af9035_download_firmware(struct dvb_usb_device 
*d,
 * which is done by master demod.
 * Master feeds also clock and controls power via GPIO.
 */
-   ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
-   if (ret < 0)
-   goto err;
-
-   if (tmp == 1 || tmp == 3 || tmp == 5) {
+   if (state->dual_mode) {
/* configure gpioh1, reset & power slave demod */
ret = af9035_wr_reg_mask(d, 0x00d8b0, 0x01, 0x01);
if (ret < 0)
@@ -835,17 +862,6 @@ static int af9035_read_config(struct dvb_usb_device *d)
}


-
-   /* check if there is dual tuners */
-   ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
-   if (ret < 0)
-   goto err;
-
-   if (tmp == 1 || tmp == 3 || tmp == 5)
-   state->dual_mode = true;
-
-   dev_dbg(>dev, "ts mode=%d dual mode=%d\n", tmp, state->dual_mode);
-
if (state->dual_mode) {
/* read 2nd demodulator I2C address */
ret = af9035_rd_reg(d,
diff --git a/drivers/media/usb/dvb-usb-v2/af9035.h 
b/drivers/media/usb/dvb-usb-v2/af9035.h
index c91d1a3..1f83c92 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.h
+++ b/drivers/media/usb/dvb-usb-v2/af9035.h
@@ -113,7 +113,7 @@ static const u32 clock_lut_it9135[] = {
  * 0  TS
  * 1  DCA + PIP
  * 3  PIP
- * 5  DCA + PIP
+ * 5  DCA + PIP (AF9035 only)
  * n  DCA
  *
  * Values 0, 3 and 5 are seen to this day. 0 for single TS and 3/5 for dual TS.



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

Re: [PATCH] media: s5p-jpeg add missing blank lines after declarations

[Jacek Anaszewski]

Hi Shuah,

Thanks for the patch.

On 07/14/2016 10:01 PM, Shuah Khan wrote:

Missing blank lines after declarations are making it hard to read the
code. Fix them and also fix other checkpatch warnings at the same time.

Signed-off-by: Shuah Khan 
---
  drivers/media/platform/s5p-jpeg/jpeg-core.c | 13 ++---
  1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 17bc94092..fe5554f 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -537,6 +537,7 @@ static const u32 fourcc_to_dwngrd_schema_id[] = {
  static int s5p_jpeg_get_dwngrd_sch_id_by_fourcc(u32 fourcc)
  {
int i;
+
for (i = 0; i < ARRAY_SIZE(fourcc_to_dwngrd_schema_id); ++i) {
if (fourcc_to_dwngrd_schema_id[i] == fourcc)
return i;
@@ -1273,7 +1274,8 @@ static int enum_fmt(struct s5p_jpeg_fmt *sjpeg_formats, 
int n,
if (num == f->index)
break;
/* Correct type but haven't reached our index yet,
-* just increment per-type index */
+* just increment per-type index
+   */
++num;
}
}
@@ -1349,6 +1351,7 @@ static int s5p_jpeg_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
pix->bytesperline = 0;
if (q_data->fmt->fourcc != V4L2_PIX_FMT_JPEG) {
u32 bpl = q_data->w;
+
if (q_data->fmt->colplanes == 1)
bpl = (bpl * q_data->fmt->depth) >> 3;
pix->bytesperline = bpl;
@@ -1374,6 +1377,7 @@ static struct s5p_jpeg_fmt *s5p_jpeg_find_format(struct 
s5p_jpeg_ctx *ctx,

for (k = 0; k < ARRAY_SIZE(sjpeg_formats); k++) {
struct s5p_jpeg_fmt *fmt = _formats[k];
+
if (fmt->fourcc == pixelformat &&
fmt->flags & fmt_flag &&
fmt->flags & ctx->jpeg->variant->fmt_ver_flag) {
@@ -1431,7 +1435,8 @@ static int vidioc_try_fmt(struct v4l2_format *f, struct 
s5p_jpeg_fmt *fmt,
return -EINVAL;

/* V4L2 specification suggests the driver corrects the format struct
-* if any of the dimensions is unsupported */
+* if any of the dimensions is unsupported
+   */
if (q_type == FMT_TYPE_OUTPUT)
jpeg_bound_align_image(ctx, >width, S5P_JPEG_MIN_WIDTH,
   S5P_JPEG_MAX_WIDTH, 0,
@@ -2490,6 +2495,7 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
if (ctx->mode == S5P_JPEG_DECODE &&
vb->vb2_queue->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
struct s5p_jpeg_q_data tmp, *q_data;
+
ctx->hdr_parsed = s5p_jpeg_parse_hdr(,
 (unsigned long)vb2_plane_vaddr(vb, 0),
 min((unsigned long)ctx->out_q.size,
@@ -3025,7 +3031,8 @@ static int s5p_jpeg_resume(struct device *dev)

  static const struct dev_pm_ops s5p_jpeg_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(s5p_jpeg_suspend, s5p_jpeg_resume)
-   SET_RUNTIME_PM_OPS(s5p_jpeg_runtime_suspend, s5p_jpeg_runtime_resume, 
NULL)
+   SET_RUNTIME_PM_OPS(s5p_jpeg_runtime_suspend, s5p_jpeg_runtime_resume,
+  NULL)
  };

  static struct s5p_jpeg_variant s5p_jpeg_drvdata = {



Acked-by: Jacek Anaszewski 

--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 4.7] af9035 bug fix

[Antti Palosaari]

That is regression fix since 4.6. This patch applies only for 4.7 - new 
patch which applies to 4.6 stable is also needed.




The following changes since commit 5cac1f67ea0363d463a58ec2d9118268fe2ba5d6:

  [media] rc: nuvoton: fix hang if chip is configured for alternative 
EFM IO address (2016-07-13 15:49:01 -0300)


are available in the git repository at:

  git://linuxtv.org/anttip/media_tree.git af9035

for you to fetch changes up to 15d24682241103014a4ba0b47cc602a89a58b97d:

  af9035: fix dual tuner detection with PCTV 79e (2016-07-15 08:57:59 
+0300)



Stefan Pöschel (1):
  af9035: fix dual tuner detection with PCTV 79e

 drivers/media/usb/dvb-usb-v2/af9035.c | 50 
+-

 drivers/media/usb/dvb-usb-v2/af9035.h |  2 +-
 2 files changed, 34 insertions(+), 18 deletions(-)

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