lening

[QUALITY LOAN SERVICE CORPORATION]

Geachte heer mevrouw

Wij bieden alle soorten van leningen.
Heeft u een lening tegen 1% rente nodig?
Neem contact op met ons kantoor vandaag,
Met het bedrag van de lening en de duur.

LET OP: Dit is een legitiem aanbod. Alleen contact met ons op als u ernstig 
gezind zijn.

Laat deze kans niet aan je voorbij gaan. Hier krijg je een lening om uw 
financiële problemen op te lossen.

Vul en onmiddellijk terug te sturen de lening aanvraagformulier.

INFORMATIE NODIG

Jullie namen:

Adres: ...
Telefoon: ...
Benodigd ...
Duur: ...
Bezetting: ...
Maandelijks Inkomen Level: ..
Geslacht: ..
Geboortedatum: ...
Staat: ...
Land: .
Doel: .

NEEM CONTACT MET ONS OP.
qualityloanserv...@hotmail.com

Beste wensen

Mrs. Isabelle Morgan
--
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] cxd2841er: freeze/unfreeze registers when reading stats

[Abylay Ospan]

ensure multiple separate register reads are from the same snapshot

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

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 09c3934..d2e28ea 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -1570,6 +1570,25 @@ static int cxd2841er_read_ber_t(struct cxd2841er_priv 
*priv,
return 0;
 }
 
+static int cxd2841er_freeze_regs(struct cxd2841er_priv *priv)
+{
+   /*
+* Freeze registers: ensure multiple separate register reads
+* are from the same snapshot
+*/
+   cxd2841er_write_reg(priv, I2C_SLVT, 0x01, 0x01);
+   return 0;
+}
+
+static int cxd2841er_unfreeze_regs(struct cxd2841er_priv *priv)
+{
+   /*
+* un-freeze registers
+*/
+   cxd2841er_write_reg(priv, I2C_SLVT, 0x01, 0x00);
+   return 0;
+}
+
 static u32 cxd2841er_dvbs_read_snr(struct cxd2841er_priv *priv,
u8 delsys, u32 *snr)
 {
@@ -1578,6 +1597,7 @@ static u32 cxd2841er_dvbs_read_snr(struct cxd2841er_priv 
*priv,
int min_index, max_index, index;
static const struct cxd2841er_cnr_data *cn_data;
 
+   cxd2841er_freeze_regs(priv);
/* Set SLV-T Bank : 0xA1 */
cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0xa1);
/*
@@ -1629,9 +1649,11 @@ static u32 cxd2841er_dvbs_read_snr(struct cxd2841er_priv 
*priv,
} else {
dev_dbg(>i2c->dev,
"%s(): no data available\n", __func__);
+   cxd2841er_unfreeze_regs(priv);
return -EINVAL;
}
 done:
+   cxd2841er_unfreeze_regs(priv);
*snr = res;
return 0;
 }
@@ -1655,12 +1677,7 @@ static int cxd2841er_read_snr_c(struct cxd2841er_priv 
*priv, u32 *snr)
return -EINVAL;
}
 
-   /*
-* Freeze registers: ensure multiple separate register reads
-* are from the same snapshot
-*/
-   cxd2841er_write_reg(priv, I2C_SLVT, 0x01, 0x01);
-
+   cxd2841er_freeze_regs(priv);
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);
@@ -1670,6 +1687,7 @@ static int cxd2841er_read_snr_c(struct cxd2841er_priv 
*priv, u32 *snr)
if (reg == 0) {
dev_dbg(>i2c->dev,
"%s(): reg value out of range\n", __func__);
+   cxd2841er_unfreeze_regs(priv);
return 0;
}
 
@@ -1690,9 +1708,11 @@ static int cxd2841er_read_snr_c(struct cxd2841er_priv 
*priv, u32 *snr)
*snr = -88 * (int32_t)sony_log(reg) + 86999;
break;
default:
+   cxd2841er_unfreeze_regs(priv);
return -EINVAL;
}
 
+   cxd2841er_unfreeze_regs(priv);
return 0;
 }
 
@@ -1707,17 +1727,21 @@ static int cxd2841er_read_snr_t(struct cxd2841er_priv 
*priv, u32 *snr)
"%s(): invalid state %d\n", __func__, priv->state);
return -EINVAL;
}
+
+   cxd2841er_freeze_regs(priv);
cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x10);
cxd2841er_read_regs(priv, I2C_SLVT, 0x28, data, sizeof(data));
reg = ((u32)data[0] << 8) | (u32)data[1];
if (reg == 0) {
dev_dbg(>i2c->dev,
"%s(): reg value out of range\n", __func__);
+   cxd2841er_unfreeze_regs(priv);
return 0;
}
if (reg > 4996)
reg = 4996;
*snr = 1 * ((intlog10(reg) - intlog10(5350 - reg)) >> 24) + 28500;
+   cxd2841er_unfreeze_regs(priv);
return 0;
 }
 
@@ -1732,18 +1756,22 @@ static int cxd2841er_read_snr_t2(struct cxd2841er_priv 
*priv, u32 *snr)
"%s(): invalid state %d\n", __func__, priv->state);
return -EINVAL;
}
+
+   cxd2841er_freeze_regs(priv);
cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x20);
cxd2841er_read_regs(priv, I2C_SLVT, 0x28, data, sizeof(data));
reg = ((u32)data[0] << 8) | (u32)data[1];
if (reg == 0) {
dev_dbg(>i2c->dev,
"%s(): reg value out of range\n", __func__);
+   cxd2841er_unfreeze_regs(priv);
return 0;
}
if (reg > 10876)
reg = 10876;
*snr = 1 * ((intlog10(reg) -
intlog10(12600 - reg)) >> 24) + 32000;
+   cxd2841er_unfreeze_regs(priv);
return 0;
 }
 
@@ -1760,21 +1788,20 @@ static int cxd2841er_read_snr_i(struct cxd2841er_priv 
*priv, u32 *snr)
return -EINVAL;
}
 
-   /* Freeze all registers */
-   cxd2841er_write_reg(priv, I2C_SLVT, 0x01, 

Re: [PATCH] [media] gspca: finepix: Remove deprecated create_singlethread_workqueue

[Frank Zago]

On 07/16/2016 03:55 AM, Bhaktipriya Shridhar wrote:
> The workqueue "work_thread" is involved in streaming the camera data.
> It has a single work item(>work_struct) and hence doesn't require
> ordering. Also, it is not being used on a memory reclaim path.
> Hence, the singlethreaded workqueue has been replaced with the use of
> system_wq.
> 
> System workqueues have been able to handle high level of concurrency
> for a long time now and hence it's not required to have a singlethreaded
> workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
> created with create_singlethread_workqueue(), system_wq allows multiple
> work items to overlap executions even on the same CPU; however, a
> per-cpu workqueue doesn't have any CPU locality or global ordering
> guarantee unless the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
> 
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Frank Zago 

Thanks for the patch.
--
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

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:   Tue Jul 19 04:00:08 CEST 2016
git branch: test
git hash:   e05b1872f29a85532c2b34e3a4974a27158f1463
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: OK
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/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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 v2] [media] ad9389b: Remove deprecated create_singlethread_workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 04:34:41PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue work_queue is involved in EDID (Extended Display
> Identification Data) handling.
> 
> It has a single work item(>edid_handler) and hence
> doesn't require ordering. It is not being used on a memory reclaim path.
> Hence, the singlethreaded workqueue has been replaced with
> the use of system_wq.
> 
> >edid_handler is a self requeueing work item and it has been
> been sync cancelled in ad9389b_remove() to ensure that nothing is
> pending when the driver is disconnected.
> 
> The unused label err_unreg has also been dropped.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun
--
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/2] [media] cx25821: Remove deprecated create_singlethread_workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 02:43:20PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue "_irq_audio_queues" runs the audio upstream handler.
> It has a single work item(>_audio_work_entry) and hence doesn't
> require ordering. Also, it is not being used on a memory reclaim path.
> Hence, the singlethreaded workqueue has been replaced with the use of
> system_wq.
> 
> System workqueues have been able to handle high level of concurrency
> for a long time now and hence it's not required to have a singlethreaded
> workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
> created with create_singlethread_workqueue(), system_wq allows multiple
> work items to overlap executions even on the same CPU; however, a
> per-cpu workqueue doesn't have any CPU locality or global ordering
> guarantee unless the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.

The patch seems to be missing update to wq destruction path.

Thanks.

-- 
tejun
--
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/2] [media] cx25821: Drop Freeing of Workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 02:41:49PM +0530, Bhaktipriya Shridhar wrote:
> Workqueues shouldn't be freed. destroy_workqueue should be used instead.
> destroy_workqueue safely destroys a workqueue and ensures that all pending
> work items are done before destroying the workqueue.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

This needs to be marked for stable.

Thanks.

-- 
tejun
--
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] gspca: finepix: Remove deprecated create_singlethread_workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 02:25:56PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue "work_thread" is involved in streaming the camera data.
> It has a single work item(>work_struct) and hence doesn't require
> ordering. Also, it is not being used on a memory reclaim path.
> Hence, the singlethreaded workqueue has been replaced with the use of
> system_wq.
> 
> System workqueues have been able to handle high level of concurrency
> for a long time now and hence it's not required to have a singlethreaded
> workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
> created with create_singlethread_workqueue(), system_wq allows multiple
> work items to overlap executions even on the same CPU; however, a
> per-cpu workqueue doesn't have any CPU locality or global ordering
> guarantee unless the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
> 
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun
--
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] gspca: vicam: Remove deprecated create_singlethread_workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 02:22:19PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue "work_thread" is involved in streaming the camera data.
> It has a single work item(>work_struct) and hence doesn't require
> ordering. Also, it is not being used on a memory reclaim path.
> Hence, the singlethreaded workqueue has been replaced with the use of
> system_wq.
> 
> System workqueues have been able to handle high level of concurrency
> for a long time now and hence it's not required to have a singlethreaded
> workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
> created with create_singlethread_workqueue(), system_wq allows multiple
> work items to overlap executions even on the same CPU; however, a
> per-cpu workqueue doesn't have any CPU locality or global ordering
> guarantee unless the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
> 
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun
--
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] gspca: jl2005bcd: Remove deprecated create_singlethread_workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 02:23:48PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue "work_thread" is involved in streaming the camera data.
> It has a single work item(>work_struct) and hence doesn't require
> ordering. Also, it is not being used on a memory reclaim path.
> Hence, the singlethreaded workqueue has been replaced with the use of
> system_wq.
> 
> System workqueues have been able to handle high level of concurrency
> for a long time now and hence it's not required to have a singlethreaded
> workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
> created with create_singlethread_workqueue(), system_wq allows multiple
> work items to overlap executions even on the same CPU; however, a
> per-cpu workqueue doesn't have any CPU locality or global ordering
> guarantee unless the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
> 
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun
--
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] gspca: sonixj: Remove deprecated create_singlethread_workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 02:20:28PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue "work_thread" is involved in updating the JPEG quality
> of the gspca_dev. It has a single work item(>work) and hence doesn't
> require ordering. Also, it is not being used on a memory reclaim path.
> Hence, the singlethreaded workqueue has been replaced with the use of
> system_wq.
> 
> System workqueues have been able to handle high level of concurrency
> for a long time now and hence it's not required to have a singlethreaded
> workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
> created with create_singlethread_workqueue(), system_wq allows multiple
> work items to overlap executions even on the same CPU; however, a
> per-cpu workqueue doesn't have any CPU locality or global ordering
> guarantee unless the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
> 
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun
--
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] pvrusb2: Remove deprecated create_singlethread_workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 02:02:34PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue "workqueue" is involved in polling the pvrusb2 hardware
> (pvr2_hdw).
> 
> It has a single work item(>workpoll) and hence doesn't require
> ordering. Also, it is not being used on a memory reclaim path.
> Hence, the singlethreaded workqueue has been replaced with the use of
> system_wq.
> 
> System workqueues have been able to handle high level of concurrency
> for a long time now and hence it's not required to have a singlethreaded
> workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
> created with create_singlethread_workqueue(), system_wq allows multiple
> work items to overlap executions even on the same CPU; however, a
> per-cpu workqueue doesn't have any CPU locality or global ordering
> guarantee unless the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
> 
> Work item has been flushed in pvr2_hdw_destroy to ensure that there are no
> pending tasks while disconnecting the driver.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun
--
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-mfc: Remove deprecated create_singlethread_workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 02:00:25PM +0530, Bhaktipriya Shridhar wrote:
> alloc_workqueue replaces deprecated create_singlethread_workqueue().
> 
> The MFC device driver is a v4l2 driver which can encode/decode video
> raw/elementary streams and has support for all popular video codecs.
> 
> The driver's watchdog_workqueue has been replaced with system_wq since
> it queues a single work item, >watchdog_work, which calls for no
> ordering requirement. The work item is involved in running the watchdog
> timer and is not being used on a memory reclaim path.
> 
> Work item has been flushed in s5p_mfc_remove() to ensure
> that there are no pending tasks while disconnecting the driver.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun
--
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-mfc: Remove deprecated create_singlethread_workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 02:00:25PM +0530, Bhaktipriya Shridhar wrote:
> alloc_workqueue replaces deprecated create_singlethread_workqueue().
> 
> The MFC device driver is a v4l2 driver which can encode/decode video
> raw/elementary streams and has support for all popular video codecs.
> 
> The driver's watchdog_workqueue has been replaced with system_wq since
> it queues a single work item, >watchdog_work, which calls for no
> ordering requirement. The work item is involved in running the watchdog
> timer and is not being used on a memory reclaim path.
> 
> Work item has been flushed in s5p_mfc_remove() to ensure
> that there are no pending tasks while disconnecting the driver.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun
--
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] Documentation: add support for V4L touch devices

[y]

From: Nick Dyer 

Signed-off-by: Nick Dyer 
---
 Documentation/media/uapi/mediactl/media-types.rst |   24 +++--
 Documentation/media/uapi/v4l/dev-touch.rst|   55 ++
 Documentation/media/uapi/v4l/devices.rst  |1 +
 Documentation/media/uapi/v4l/pixfmt-tch-td08.rst  |   80 +++
 Documentation/media/uapi/v4l/pixfmt-tch-td16.rst  |  111 +
 Documentation/media/uapi/v4l/pixfmt-tch-tu08.rst  |   78 +++
 Documentation/media/uapi/v4l/pixfmt-tch-tu16.rst  |  110 
 Documentation/media/uapi/v4l/pixfmt.rst   |1 +
 Documentation/media/uapi/v4l/tch-formats.rst  |   18 
 9 files changed, 471 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/dev-touch.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-tch-td08.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-tch-td16.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-tch-tu08.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-tch-tu16.rst
 create mode 100644 Documentation/media/uapi/v4l/tch-formats.rst

diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
b/Documentation/media/uapi/mediactl/media-types.rst
index c77717b..0265edc 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -429,6 +429,16 @@ Types and flags used to represent the media graph elements
 
 -  .. row 11
 
+   ..  _MEDIA-INTF-T-V4L-TOUCH:
+
+   -  ``MEDIA_INTF_T_V4L_TOUCH``
+
+   -  Device node interface for Touch device (V4L)
+
+   -  typically, /dev/v4l-touch?
+
+-  .. row 12
+
..  _MEDIA-INTF-T-ALSA-PCM-CAPTURE:
 
-  ``MEDIA_INTF_T_ALSA_PCM_CAPTURE``
@@ -437,7 +447,7 @@ Types and flags used to represent the media graph elements
 
-  typically, /dev/snd/pcmC?D?c
 
--  .. row 12
+-  .. row 13
 
..  _MEDIA-INTF-T-ALSA-PCM-PLAYBACK:
 
@@ -447,7 +457,7 @@ Types and flags used to represent the media graph elements
 
-  typically, /dev/snd/pcmC?D?p
 
--  .. row 13
+-  .. row 14
 
..  _MEDIA-INTF-T-ALSA-CONTROL:
 
@@ -457,7 +467,7 @@ Types and flags used to represent the media graph elements
 
-  typically, /dev/snd/controlC?
 
--  .. row 14
+-  .. row 15
 
..  _MEDIA-INTF-T-ALSA-COMPRESS:
 
@@ -467,7 +477,7 @@ Types and flags used to represent the media graph elements
 
-  typically, /dev/snd/compr?
 
--  .. row 15
+-  .. row 16
 
..  _MEDIA-INTF-T-ALSA-RAWMIDI:
 
@@ -477,7 +487,7 @@ Types and flags used to represent the media graph elements
 
-  typically, /dev/snd/midi?
 
--  .. row 16
+-  .. row 17
 
..  _MEDIA-INTF-T-ALSA-HWDEP:
 
@@ -487,7 +497,7 @@ Types and flags used to represent the media graph elements
 
-  typically, /dev/snd/hwC?D?
 
--  .. row 17
+-  .. row 18
 
..  _MEDIA-INTF-T-ALSA-SEQUENCER:
 
@@ -497,7 +507,7 @@ Types and flags used to represent the media graph elements
 
-  typically, /dev/snd/seq
 
--  .. row 18
+-  .. row 19
 
..  _MEDIA-INTF-T-ALSA-TIMER:
 
diff --git a/Documentation/media/uapi/v4l/dev-touch.rst 
b/Documentation/media/uapi/v4l/dev-touch.rst
new file mode 100644
index 000..5c71ee9
--- /dev/null
+++ b/Documentation/media/uapi/v4l/dev-touch.rst
@@ -0,0 +1,55 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _touch:
+
+*
+Touch Devices
+*
+
+Touch devices are accessed through character device special files named
+``/dev/v4l-touch0`` to ``/dev/v4l-touch255`` with major number 81 and
+dynamically allocated minor numbers 0 to 255.
+
+Overview
+
+
+Sensors may be Optical, or Projected Capacitive touch (PCT).
+
+Processing is required to analyse the raw data and produce input events. In
+some systems, this may be performed on the ASIC and the raw data is purely a
+side-channel for diagnostics or tuning. In other systems, the ASIC is a simple
+analogue front end device which delivers touch data at high rate, and any touch
+processing must be done on the host.
+
+For capacitive touch sensing, the touchscreen is composed of an array of
+horizontal and vertical conductors (alternatively called rows/columns, X/Y
+lines, or tx/rx). Mutual Capacitance measured is at the nodes where the
+conductors cross. Alternatively, Self Capacitance measures the signal from each
+column and row independently.
+
+A touch input may be determined by comparing the raw capacitance measurement to
+a no-touch reference (or "baseline") measurement:
+
+Delta = Raw - Reference
+
+The reference measurement takes account of variations in the capacitance across
+the touch sensor matrix, for example manufacturing irregularities,
+environmental or edge effects.
+
+Querying Capabilities
+=
+
+Devices supporting the touch interface set the ``V4L2_CAP_VIDEO_CAPTURE`` 

[PATCH v8 10/10] Input: sur40 - use new V4L2 touch input type

[Nick Dyer]

Support both V4L2_TCH_FMT_TU08 and V4L2_PIX_FMT_GREY for backwards
compatibility.

Note: I have not tested these changes (I have no access to the hardware)
so not signing off.
---
 drivers/input/touchscreen/sur40.c |  122 +++--
 1 file changed, 89 insertions(+), 33 deletions(-)

diff --git a/drivers/input/touchscreen/sur40.c 
b/drivers/input/touchscreen/sur40.c
index 4ea4757..fc275cb 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -139,6 +139,27 @@ struct sur40_image_header {
 #define SUR40_GET_STATE   0xc5 /*  4 bytes state (?) */
 #define SUR40_GET_SENSORS 0xb1 /*  8 bytes sensors   */
 
+static const struct v4l2_pix_format sur40_pix_format[] = {
+   {
+   .pixelformat = V4L2_TCH_FMT_TU08,
+   .width  = SENSOR_RES_X / 2,
+   .height = SENSOR_RES_Y / 2,
+   .field = V4L2_FIELD_NONE,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .bytesperline = SENSOR_RES_X / 2,
+   .sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
+   },
+   {
+   .pixelformat = V4L2_PIX_FMT_GREY,
+   .width  = SENSOR_RES_X / 2,
+   .height = SENSOR_RES_Y / 2,
+   .field = V4L2_FIELD_NONE,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .bytesperline = SENSOR_RES_X / 2,
+   .sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
+   }
+};
+
 /* master device state */
 struct sur40_state {
 
@@ -149,6 +170,7 @@ struct sur40_state {
struct v4l2_device v4l2;
struct video_device vdev;
struct mutex lock;
+   struct v4l2_pix_format pix_fmt;
 
struct vb2_queue queue;
struct list_head buf_list;
@@ -169,7 +191,6 @@ struct sur40_buffer {
 
 /* forward declarations */
 static const struct video_device sur40_video_device;
-static const struct v4l2_pix_format sur40_video_format;
 static const struct vb2_queue sur40_queue;
 static void sur40_process_video(struct sur40_state *sur40);
 
@@ -420,7 +441,7 @@ static void sur40_process_video(struct sur40_state *sur40)
goto err_poll;
}
 
-   if (le32_to_cpu(img->size) != sur40_video_format.sizeimage) {
+   if (le32_to_cpu(img->size) != sur40->pix_fmt.sizeimage) {
dev_err(sur40->dev, "image size mismatch\n");
goto err_poll;
}
@@ -431,7 +452,7 @@ static void sur40_process_video(struct sur40_state *sur40)
 
result = usb_sg_init(, sur40->usbdev,
usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT), 0,
-   sgt->sgl, sgt->nents, sur40_video_format.sizeimage, 0);
+   sgt->sgl, sgt->nents, sur40->pix_fmt.sizeimage, 0);
if (result < 0) {
dev_err(sur40->dev, "error %d in usb_sg_init\n", result);
goto err_poll;
@@ -586,13 +607,14 @@ static int sur40_probe(struct usb_interface *interface,
if (error)
goto err_unreg_v4l2;
 
+   sur40->pix_fmt = sur40_pix_format[0];
sur40->vdev = sur40_video_device;
sur40->vdev.v4l2_dev = >v4l2;
sur40->vdev.lock = >lock;
sur40->vdev.queue = >queue;
video_set_drvdata(>vdev, sur40);
 
-   error = video_register_device(>vdev, VFL_TYPE_GRABBER, -1);
+   error = video_register_device(>vdev, VFL_TYPE_TOUCH, -1);
if (error) {
dev_err(>dev,
"Unable to register video subdevice.");
@@ -651,10 +673,10 @@ static int sur40_queue_setup(struct vb2_queue *q,
*nbuffers = 3 - q->num_buffers;
 
if (*nplanes)
-   return sizes[0] < sur40_video_format.sizeimage ? -EINVAL : 0;
+   return sizes[0] < sur40->pix_fmt.sizeimage ? -EINVAL : 0;
 
*nplanes = 1;
-   sizes[0] = sur40_video_format.sizeimage;
+   sizes[0] = sur40->pix_fmt.sizeimage;
 
return 0;
 }
@@ -666,7 +688,7 @@ static int sur40_queue_setup(struct vb2_queue *q,
 static int sur40_buffer_prepare(struct vb2_buffer *vb)
 {
struct sur40_state *sur40 = vb2_get_drv_priv(vb->vb2_queue);
-   unsigned long size = sur40_video_format.sizeimage;
+   unsigned long size = sur40->pix_fmt.sizeimage;
 
if (vb2_plane_size(vb, 0) < size) {
dev_err(>usbdev->dev, "buffer too small (%lu < %lu)\n",
@@ -741,7 +763,7 @@ static int sur40_vidioc_querycap(struct file *file, void 
*priv,
strlcpy(cap->driver, DRIVER_SHORT, sizeof(cap->driver));
strlcpy(cap->card, DRIVER_LONG, sizeof(cap->card));
usb_make_path(sur40->usbdev, cap->bus_info, sizeof(cap->bus_info));
-   cap->device_caps = V4L2_CAP_VIDEO_CAPTURE |
+   cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_TOUCH |
V4L2_CAP_READWRITE |
V4L2_CAP_STREAMING;
cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
@@ -753,7 +775,7 @@ static int sur40_vidioc_enum_input(struct file *file, 

[PATCH v8 0/10] Output raw touch data via V4L2

[Nick Dyer]

This is a series of patches to add output of raw touch diagnostic data via V4L2
to the Atmel maXTouch and Synaptics RMI4 drivers.

It's a rewrite of the previous implementation which output via debugfs: it now
uses a V4L2 device in a similar way to the sur40 driver.

We have a utility which can read the data and display it in a useful format:
https://github.com/ndyer/heatmap/commits/heatmap-v4l

Changes in v8:
- Split out docs changes, rework in RST/Sphinx, and rebase against docs-next
- Update for changes to vb2_queue alloc_ctxs
- Rebase against git://linuxtv.org/media_tree.git and re-test

Changes in v7:
- Tested by Andrew Duggan and Chris Healy.
- Update bus_info to add "rmi4:" bus.
- Fix code style issues in sur40 changes.

Changes in v6:
- Remove BUF_TYPE_TOUCH_CAPTURE, as discussed with Hans V touch devices will
  use BUF_TYPE_VIDEO_CAPTURE.
- Touch devices should now register CAP_VIDEO_CAPTURE: CAP_TOUCH just says that
  this is a touch device, not a video device, but otherwise it acts the same.
- Add some code to v4l_s_fmt() to set sensible default values for fields not
  used by touch.
- Improve naming/doc of RMI4 F54 report types.
- Various minor DocBook fixes, and split to separate patch.
- Update my email address.
- Rework sur40 changes so that PIX_FMT_GREY is supported for backward
  compatibility. Florian is it possible for you to test?

Changes in v5 (Hans Verkuil review):
- Update v4l2-core:
  - Add VFL_TYPE_TOUCH, V4L2_BUF_TYPE_TOUCH_CAPTURE and V4L2_CAP_TOUCH
  - Change V4L2_INPUT_TYPE_TOUCH_SENSOR to V4L2_INPUT_TYPE_TOUCH
  - Improve DocBook documentation
  - Add FMT definitions for touch data
  - Note this will need the latest version of the heatmap util
- Synaptics RMI4 driver:
  - Remove some less important non full frame report types
  - Switch report type names to const char * array
  - Move a static array to inside context struct
- Split sur40 changes to a separate commit

Changes in v4:
- Address nits from the input side in atmel_mxt_ts patches (Dmitry Torokhov)
- Add Synaptics RMI4 F54 support patch

Changes in v3:
- Address V4L2 review comments from Hans Verkuil
- Run v4l-compliance and fix all issues - needs minor patch here:
  https://github.com/ndyer/v4l-utils/commit/cf50469773f

Changes in v2:
- Split pixfmt changes into separate commit and add DocBook
- Introduce VFL_TYPE_TOUCH_SENSOR and /dev/v4l-touch
- Remove "single node" support for now, it may be better to treat it as
  metadata later
- Explicitly set VFL_DIR_RX
- Fix Kconfig

--
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 v8 03/10] Input: atmel_mxt_ts - add support for T37 diagnostic data

[Nick Dyer]

Atmel maXTouch devices have a T37 object which can be used to read raw
touch deltas from the device. This consists of an array of 16-bit
integers, one for each node on the touchscreen matrix.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/Kconfig|6 ++
 drivers/input/touchscreen/atmel_mxt_ts.c |  159 ++
 2 files changed, 165 insertions(+)

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 8ecdc38..da96ecf 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -115,6 +115,12 @@ config TOUCHSCREEN_ATMEL_MXT
  To compile this driver as a module, choose M here: the
  module will be called atmel_mxt_ts.
 
+config TOUCHSCREEN_ATMEL_MXT_T37
+   bool "Support T37 Diagnostic Data"
+   depends on TOUCHSCREEN_ATMEL_MXT
+   help
+ Say Y here if you want support for the T37 Diagnostic Data object.
+
 config TOUCHSCREEN_AUO_PIXCIR
tristate "AUO in-cell touchscreen using Pixcir ICs"
depends on I2C
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 5af7907..0048233 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -124,6 +124,19 @@ struct t9_range {
 #define MXT_COMMS_CTRL 0
 #define MXT_COMMS_CMD  1
 
+/* MXT_DEBUG_DIAGNOSTIC_T37 */
+#define MXT_DIAGNOSTIC_PAGEUP  0x01
+#define MXT_DIAGNOSTIC_DELTAS  0x10
+#define MXT_DIAGNOSTIC_SIZE128
+
+struct t37_debug {
+#ifdef CONFIG_TOUCHSCREEN_ATMEL_MXT_T37
+   u8 mode;
+   u8 page;
+   u8 data[MXT_DIAGNOSTIC_SIZE];
+#endif
+};
+
 /* Define for MXT_GEN_COMMAND_T6 */
 #define MXT_BOOT_VALUE 0xa5
 #define MXT_RESET_VALUE0x01
@@ -205,6 +218,14 @@ struct mxt_object {
u8 num_report_ids;
 } __packed;
 
+struct mxt_dbg {
+   u16 t37_address;
+   u16 diag_cmd_address;
+   struct t37_debug *t37_buf;
+   unsigned int t37_pages;
+   unsigned int t37_nodes;
+};
+
 /* Each client has this additional data */
 struct mxt_data {
struct i2c_client *client;
@@ -233,6 +254,7 @@ struct mxt_data {
u8 num_touchids;
u8 multitouch;
struct t7_config t7_cfg;
+   struct mxt_dbg dbg;
 
/* Cached parameters from object table */
u16 T5_address;
@@ -2043,6 +2065,141 @@ recheck:
return 0;
 }
 
+#ifdef CONFIG_TOUCHSCREEN_ATMEL_MXT_T37
+static u16 mxt_get_debug_value(struct mxt_data *data, unsigned int x,
+  unsigned int y)
+{
+   struct mxt_dbg *dbg = >dbg;
+   unsigned int ofs, page;
+
+   ofs = (y + (x * data->info.matrix_ysize)) * sizeof(u16);
+   page = ofs / MXT_DIAGNOSTIC_SIZE;
+   ofs %= MXT_DIAGNOSTIC_SIZE;
+
+   return get_unaligned_le16(>t37_buf[page].data[ofs]);
+}
+
+static int mxt_convert_debug_pages(struct mxt_data *data, u16 *outbuf)
+{
+   struct mxt_dbg *dbg = >dbg;
+   unsigned int x = 0;
+   unsigned int y = 0;
+   unsigned int i;
+
+   for (i = 0; i < dbg->t37_nodes; i++) {
+   outbuf[i] = mxt_get_debug_value(data, x, y);
+
+   /* Next value */
+   if (++x >= data->info.matrix_xsize) {
+   x = 0;
+   y++;
+   }
+   }
+
+   return 0;
+}
+
+static int mxt_read_diagnostic_debug(struct mxt_data *data, u8 mode,
+u16 *outbuf)
+{
+   struct mxt_dbg *dbg = >dbg;
+   int retries = 0;
+   int page;
+   int ret;
+   u8 cmd = mode;
+   struct t37_debug *p;
+   u8 cmd_poll;
+
+   for (page = 0; page < dbg->t37_pages; page++) {
+   p = dbg->t37_buf + page;
+
+   ret = mxt_write_reg(data->client, dbg->diag_cmd_address,
+   cmd);
+   if (ret)
+   return ret;
+
+   retries = 0;
+   msleep(20);
+wait_cmd:
+   /* Read back command byte */
+   ret = __mxt_read_reg(data->client, dbg->diag_cmd_address,
+sizeof(cmd_poll), _poll);
+   if (ret)
+   return ret;
+
+   /* Field is cleared once the command has been processed */
+   if (cmd_poll) {
+   if (retries++ > 100)
+   return -EINVAL;
+
+   msleep(20);
+   goto wait_cmd;
+   }
+
+   /* Read T37 page */
+   ret = __mxt_read_reg(data->client, dbg->t37_address,
+sizeof(struct t37_debug), p);
+   if (ret)
+   return ret;
+
+   if (p->mode != mode || p->page != page) {
+   dev_err(>client->dev, "T37 page mismatch\n");
+   return 

[PATCH] v4l2-compliance: Changes to support touch sensors

[Nick Dyer]

Signed-off-by: Nick Dyer 
---
 utils/v4l2-compliance/v4l2-compliance.cpp|   51 +-
 utils/v4l2-compliance/v4l2-compliance.h  |1 +
 utils/v4l2-compliance/v4l2-test-input-output.cpp |4 +-
 3 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/utils/v4l2-compliance/v4l2-compliance.cpp 
b/utils/v4l2-compliance/v4l2-compliance.cpp
index 48dc8b4..ca2eec7 100644
--- a/utils/v4l2-compliance/v4l2-compliance.cpp
+++ b/utils/v4l2-compliance/v4l2-compliance.cpp
@@ -55,6 +55,7 @@ enum Option {
OptSetRadioDevice = 'r',
OptStreaming = 's',
OptSetSWRadioDevice = 'S',
+   OptSetTouchDevice = 't',
OptTrace = 'T',
OptVerbose = 'v',
OptSetVbiDevice = 'V',
@@ -105,6 +106,7 @@ static struct option long_options[] = {
{"vbi-device", required_argument, 0, OptSetVbiDevice},
{"sdr-device", required_argument, 0, OptSetSWRadioDevice},
{"expbuf-device", required_argument, 0, OptSetExpBufDevice},
+   {"touch-device", required_argument, 0, OptSetTouchDevice},
{"help", no_argument, 0, OptHelp},
{"verbose", no_argument, 0, OptVerbose},
{"no-warnings", no_argument, 0, OptNoWarnings},
@@ -134,6 +136,9 @@ static void usage(void)
printf("  -S, --sdr-device=\n");
printf(" Use device  as the SDR device.\n");
printf(" If  starts with a digit, then 
/dev/swradio is used.\n");
+   printf("  -t, --touch-device=\n");
+   printf(" Use device  as the touch device.\n");
+   printf(" If  starts with a digit, then 
/dev/v4l-touch is used.\n");
printf("  -e, --expbuf-device=\n");
printf(" Use device  to obtain DMABUF 
handles.\n");
printf(" If  starts with a digit, then 
/dev/video is used.\n");
@@ -206,6 +211,8 @@ std::string cap2s(unsigned cap)
s += "\t\tSDR Capture\n";
if (cap & V4L2_CAP_SDR_OUTPUT)
s += "\t\tSDR Output\n";
+   if (cap & V4L2_CAP_TOUCH)
+   s += "\t\tTouch Capture\n";
if (cap & V4L2_CAP_TUNER)
s += "\t\tTuner\n";
if (cap & V4L2_CAP_HW_FREQ_SEEK)
@@ -533,7 +540,8 @@ static int testCap(struct node *node)
memcmp(vcap.bus_info, "ISA:", 4) &&
memcmp(vcap.bus_info, "I2C:", 4) &&
memcmp(vcap.bus_info, "parport", 7) &&
-   memcmp(vcap.bus_info, "platform:", 9))
+   memcmp(vcap.bus_info, "platform:", 9) &&
+   memcmp(vcap.bus_info, "rmi4:", 5))
return fail("missing bus_info prefix ('%s')\n", vcap.bus_info);
fail_on_test((vcap.version >> 16) < 3);
fail_on_test(check_0(vcap.reserved, sizeof(vcap.reserved)));
@@ -673,6 +681,8 @@ int main(int argc, char **argv)
struct node radio_node2;
struct node sdr_node;
struct node sdr_node2;
+   struct node touch_node;
+   struct node touch_node2;
struct node expbuf_node;
 
/* command args */
@@ -682,6 +692,7 @@ int main(int argc, char **argv)
const char *vbi_device = NULL;  /* -V device */
const char *radio_device = NULL;/* -r device */
const char *sdr_device = NULL;  /* -S device */
+   const char *touch_device = NULL;/* -t device */
const char *expbuf_device = NULL;   /* --expbuf-device device */
struct v4l2_capability vcap;/* list_cap */
unsigned frame_count = 60;
@@ -750,6 +761,15 @@ int main(int argc, char **argv)
sdr_device = newdev;
}
break;
+   case OptSetTouchDevice:
+   touch_device = optarg;
+   if (touch_device[0] >= '0' && touch_device[0] <= '9' && 
strlen(touch_device) <= 3) {
+   static char newdev[20];
+
+   sprintf(newdev, "/dev/v4l-touch%s", 
touch_device);
+   touch_device = newdev;
+   }
+   break;
case OptSetExpBufDevice:
expbuf_device = optarg;
if (expbuf_device[0] >= '0' && expbuf_device[0] <= '9' 
&& strlen(expbuf_device) <= 3) {
@@ -839,7 +859,8 @@ int main(int argc, char **argv)
if (v1 == 2 && v2 == 6)
kernel_version = v3;
 
-   if (!video_device && !vbi_device && !radio_device && !sdr_device)
+   if (!video_device && !vbi_device && !radio_device &&
+   !sdr_device && !touch_device)
video_device = "/dev/video0";
 
if (video_device) {
@@ -886,6 +907,17 @@ int main(int argc, char **argv)
}
}
 
+   if (touch_device) {
+   touch_node.s_trace(options[OptTrace]);
+   

[PATCH v8 01/10] Input: atmel_mxt_ts - update MAINTAINERS email address

[Nick Dyer]

I'm leaving ITDev, so change to my personal email. My understanding is
that someone at Atmel will take this on once their takeover by Microchip
has settled down.

Signed-off-by: Nick Dyer 
---
 MAINTAINERS |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a15d945..9be2570 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2188,9 +2188,9 @@ S:Maintained
 F: drivers/net/wireless/atmel/atmel*
 
 ATMEL MAXTOUCH DRIVER
-M: Nick Dyer 
-T: git git://github.com/atmel-maxtouch/linux.git
-S: Supported
+M: Nick Dyer 
+T: git git://github.com/ndyer/linux.git
+S: Maintained
 F: Documentation/devicetree/bindings/input/atmel,maxtouch.txt
 F: drivers/input/touchscreen/atmel_mxt_ts.c
 F: include/linux/platform_data/atmel_mxt_ts.h
-- 
1.7.9.5

--
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 v8 04/10] Input: atmel_mxt_ts - output diagnostic debug via V4L2 device

[Nick Dyer]

Register a video device to output T37 diagnostic data.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/Kconfig|6 +-
 drivers/input/touchscreen/atmel_mxt_ts.c |  245 ++
 2 files changed, 249 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index da96ecf..7c1c5ec 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -117,9 +117,11 @@ config TOUCHSCREEN_ATMEL_MXT
 
 config TOUCHSCREEN_ATMEL_MXT_T37
bool "Support T37 Diagnostic Data"
-   depends on TOUCHSCREEN_ATMEL_MXT
+   depends on TOUCHSCREEN_ATMEL_MXT && VIDEO_V4L2
+   select VIDEOBUF2_VMALLOC
help
- Say Y here if you want support for the T37 Diagnostic Data object.
+ Say Y here if you want support to output data from the T37
+ Diagnostic Data object using a V4L device.
 
 config TOUCHSCREEN_AUO_PIXCIR
tristate "AUO in-cell touchscreen using Pixcir ICs"
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 0048233..a9f987b 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -28,6 +28,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 /* Firmware files */
 #define MXT_FW_NAME"maxtouch.fw"
@@ -224,6 +228,23 @@ struct mxt_dbg {
struct t37_debug *t37_buf;
unsigned int t37_pages;
unsigned int t37_nodes;
+
+   struct v4l2_device v4l2;
+   struct v4l2_pix_format format;
+   struct video_device vdev;
+   struct vb2_queue queue;
+   struct mutex lock;
+   int input;
+};
+
+static const struct v4l2_file_operations mxt_video_fops = {
+   .owner = THIS_MODULE,
+   .open = v4l2_fh_open,
+   .release = vb2_fop_release,
+   .unlocked_ioctl = video_ioctl2,
+   .read = vb2_fop_read,
+   .mmap = vb2_fop_mmap,
+   .poll = vb2_fop_poll,
 };
 
 /* Each client has this additional data */
@@ -279,6 +300,11 @@ struct mxt_data {
struct completion crc_completion;
 };
 
+struct mxt_vb2_buffer {
+   struct vb2_buffer   vb;
+   struct list_headlist;
+};
+
 static size_t mxt_obj_size(const struct mxt_object *obj)
 {
return obj->size_minus_one + 1;
@@ -1525,6 +1551,11 @@ static void mxt_free_input_device(struct mxt_data *data)
 
 static void mxt_free_object_table(struct mxt_data *data)
 {
+#ifdef CONFIG_TOUCHSCREEN_ATMEL_MXT_T37
+   video_unregister_device(>dbg.vdev);
+   v4l2_device_unregister(>dbg.v4l2);
+#endif
+
kfree(data->object_table);
data->object_table = NULL;
kfree(data->msg_buf);
@@ -2157,10 +2188,191 @@ wait_cmd:
return mxt_convert_debug_pages(data, outbuf);
 }
 
+static int mxt_queue_setup(struct vb2_queue *q,
+  unsigned int *nbuffers, unsigned int *nplanes,
+  unsigned int sizes[], struct device *alloc_devs[])
+{
+   struct mxt_data *data = q->drv_priv;
+   size_t size = data->dbg.t37_nodes * sizeof(u16);
+
+   if (*nplanes)
+   return sizes[0] < size ? -EINVAL : 0;
+
+   *nplanes = 1;
+   sizes[0] = size;
+
+   return 0;
+}
+
+static void mxt_buffer_queue(struct vb2_buffer *vb)
+{
+   struct mxt_data *data = vb2_get_drv_priv(vb->vb2_queue);
+   u16 *ptr;
+   int ret;
+
+   ptr = vb2_plane_vaddr(vb, 0);
+   if (!ptr) {
+   dev_err(>client->dev, "Error acquiring frame ptr\n");
+   goto fault;
+   }
+
+   ret = mxt_read_diagnostic_debug(data, MXT_DIAGNOSTIC_DELTAS, ptr);
+   if (ret)
+   goto fault;
+
+   vb2_set_plane_payload(vb, 0, data->dbg.t37_nodes * sizeof(u16));
+   vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
+   return;
+
+fault:
+   vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
+}
+
+/* V4L2 structures */
+static const struct vb2_ops mxt_queue_ops = {
+   .queue_setup= mxt_queue_setup,
+   .buf_queue  = mxt_buffer_queue,
+   .wait_prepare   = vb2_ops_wait_prepare,
+   .wait_finish= vb2_ops_wait_finish,
+};
+
+static const struct vb2_queue mxt_queue = {
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+   .io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ,
+   .buf_struct_size = sizeof(struct mxt_vb2_buffer),
+   .ops = _queue_ops,
+   .mem_ops = _vmalloc_memops,
+   .timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC,
+   .min_buffers_needed = 1,
+};
+
+static int mxt_vidioc_querycap(struct file *file, void *priv,
+struct v4l2_capability *cap)
+{
+   struct mxt_data *data = video_drvdata(file);
+
+   strlcpy(cap->driver, "atmel_mxt_ts", sizeof(cap->driver));
+   strlcpy(cap->card, "atmel_mxt_ts touch", sizeof(cap->card));
+   snprintf(cap->bus_info, 

[PATCH v8 06/10] Input: atmel_mxt_ts - handle diagnostic data orientation

[Nick Dyer]

Invert the diagnostic data to match the orientation of the input device.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c |   26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 29be261..7376c42 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -125,6 +125,8 @@ struct t9_range {
 
 /* MXT_TOUCH_MULTI_T9 orient */
 #define MXT_T9_ORIENT_SWITCH   (1 << 0)
+#define MXT_T9_ORIENT_INVERTX  (1 << 1)
+#define MXT_T9_ORIENT_INVERTY  (1 << 2)
 
 /* MXT_SPT_COMMSCONFIG_T18 */
 #define MXT_COMMS_CTRL 0
@@ -158,6 +160,8 @@ struct t37_debug {
 #define MXT_T100_YRANGE24
 
 #define MXT_T100_CFG_SWITCHXY  BIT(5)
+#define MXT_T100_CFG_INVERTY   BIT(6)
+#define MXT_T100_CFG_INVERTX   BIT(7)
 
 #define MXT_T100_TCHAUX_VECT   BIT(0)
 #define MXT_T100_TCHAUX_AMPL   BIT(1)
@@ -262,6 +266,8 @@ struct mxt_data {
unsigned int irq;
unsigned int max_x;
unsigned int max_y;
+   bool invertx;
+   bool inverty;
bool xy_switch;
u8 xsize;
u8 ysize;
@@ -1747,6 +1753,8 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
return error;
 
data->xy_switch = orient & MXT_T9_ORIENT_SWITCH;
+   data->invertx = orient & MXT_T9_ORIENT_INVERTX;
+   data->inverty = orient & MXT_T9_ORIENT_INVERTY;
 
return 0;
 }
@@ -1801,6 +1809,8 @@ static int mxt_read_t100_config(struct mxt_data *data)
return error;
 
data->xy_switch = cfg & MXT_T100_CFG_SWITCHXY;
+   data->invertx = cfg & MXT_T100_CFG_INVERTX;
+   data->inverty = cfg & MXT_T100_CFG_INVERTY;
 
/* allocate aux bytes */
error =  __mxt_read_reg(client,
@@ -2145,13 +2155,19 @@ static int mxt_convert_debug_pages(struct mxt_data 
*data, u16 *outbuf)
struct mxt_dbg *dbg = >dbg;
unsigned int x = 0;
unsigned int y = 0;
-   unsigned int i;
+   unsigned int i, rx, ry;
 
for (i = 0; i < dbg->t37_nodes; i++) {
-   outbuf[i] = mxt_get_debug_value(data, x, y);
+   /* Handle orientation */
+   rx = data->xy_switch ? y : x;
+   ry = data->xy_switch ? x : y;
+   rx = data->invertx ? (data->xsize - 1 - rx) : rx;
+   ry = data->inverty ? (data->ysize - 1 - ry) : ry;
+
+   outbuf[i] = mxt_get_debug_value(data, rx, ry);
 
/* Next value */
-   if (++x >= data->xsize) {
+   if (++x >= (data->xy_switch ? data->ysize : data->xsize)) {
x = 0;
y++;
}
@@ -2306,8 +2322,8 @@ static int mxt_set_input(struct mxt_data *data, unsigned 
int i)
if (i > 0)
return -EINVAL;
 
-   f->width = data->xsize;
-   f->height = data->ysize;
+   f->width = data->xy_switch ? data->ysize : data->xsize;
+   f->height = data->xy_switch ? data->xsize : data->ysize;
f->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_RAW;
-- 
1.7.9.5

--
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 v8 05/10] Input: atmel_mxt_ts - read touchscreen size

[Nick Dyer]

The touchscreen may have a margin where not all the matrix is used. Read
the parameters from T9 and T100 and take account of the difference.

Note: this does not read the XORIGIN/YORIGIN fields so it assumes that
the touchscreen starts at (0,0)

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c |   42 +-
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index a9f987b..29be261 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -103,6 +103,8 @@ struct t7_config {
 
 /* MXT_TOUCH_MULTI_T9 field */
 #define MXT_T9_CTRL0
+#define MXT_T9_XSIZE   3
+#define MXT_T9_YSIZE   4
 #define MXT_T9_ORIENT  9
 #define MXT_T9_RANGE   18
 
@@ -150,7 +152,9 @@ struct t37_debug {
 #define MXT_T100_CTRL  0
 #define MXT_T100_CFG1  1
 #define MXT_T100_TCHAUX3
+#define MXT_T100_XSIZE 9
 #define MXT_T100_XRANGE13
+#define MXT_T100_YSIZE 20
 #define MXT_T100_YRANGE24
 
 #define MXT_T100_CFG_SWITCHXY  BIT(5)
@@ -259,6 +263,8 @@ struct mxt_data {
unsigned int max_x;
unsigned int max_y;
bool xy_switch;
+   u8 xsize;
+   u8 ysize;
bool in_bootloader;
u16 mem_size;
u8 t100_aux_ampl;
@@ -1714,6 +1720,18 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
return -EINVAL;
 
error = __mxt_read_reg(client,
+  object->start_address + MXT_T9_XSIZE,
+  sizeof(data->xsize), >xsize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T9_YSIZE,
+  sizeof(data->ysize), >ysize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
   object->start_address + MXT_T9_RANGE,
   sizeof(range), );
if (error)
@@ -1763,6 +1781,18 @@ static int mxt_read_t100_config(struct mxt_data *data)
 
data->max_y = get_unaligned_le16(_y);
 
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T100_XSIZE,
+  sizeof(data->xsize), >xsize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T100_YSIZE,
+  sizeof(data->ysize), >ysize);
+   if (error)
+   return error;
+
/* read orientation config */
error =  __mxt_read_reg(client,
object->start_address + MXT_T100_CFG1,
@@ -2121,7 +2151,7 @@ static int mxt_convert_debug_pages(struct mxt_data *data, 
u16 *outbuf)
outbuf[i] = mxt_get_debug_value(data, x, y);
 
/* Next value */
-   if (++x >= data->info.matrix_xsize) {
+   if (++x >= data->xsize) {
x = 0;
y++;
}
@@ -2276,8 +2306,8 @@ static int mxt_set_input(struct mxt_data *data, unsigned 
int i)
if (i > 0)
return -EINVAL;
 
-   f->width = data->info.matrix_xsize;
-   f->height = data->info.matrix_ysize;
+   f->width = data->xsize;
+   f->height = data->ysize;
f->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_RAW;
@@ -2392,9 +2422,9 @@ static void mxt_debug_init(struct mxt_data *data)
dbg->t37_address = object->start_address;
 
/* Calculate size of data and allocate buffer */
-   dbg->t37_nodes = data->info.matrix_xsize * data->info.matrix_ysize;
-   dbg->t37_pages = DIV_ROUND_UP(dbg->t37_nodes * sizeof(u16),
- sizeof(dbg->t37_buf->data));
+   dbg->t37_nodes = data->xsize * data->ysize;
+   dbg->t37_pages = DIV_ROUND_UP(data->xsize * data->info.matrix_ysize *
+ sizeof(u16), sizeof(dbg->t37_buf->data));
 
dbg->t37_buf = devm_kmalloc_array(>client->dev, dbg->t37_pages,
  sizeof(struct t37_debug), GFP_KERNEL);
-- 
1.7.9.5

--
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 v8 02/10] v4l2-core: Add support for touch devices

[Nick Dyer]

Some touch controllers send out touch data in a similar way to a
greyscale frame grabber.

Add new device type VFL_TYPE_TOUCH:
- This uses a new device prefix v4l-touch for these devices, to stop
  generic capture software from treating them as webcams. Otherwise,
  touch is treated similarly to video capture.
- Add V4L2_INPUT_TYPE_TOUCH
- Add MEDIA_INTF_T_V4L_TOUCH
- Add V4L2_CAP_TOUCH to indicate device is a touch device

Add formats:
- V4L2_TCH_FMT_DELTA_TD16 for signed 16-bit touch deltas
- V4L2_TCH_FMT_DELTA_TD08 for signed 16-bit touch deltas
- V4L2_TCH_FMT_TU16 for unsigned 16-bit touch data
- V4L2_TCH_FMT_TU08 for unsigned 8-bit touch data

This support will be used by:
- Atmel maXTouch (atmel_mxt_ts)
- Synaptics RMI4.
- sur40

Signed-off-by: Nick Dyer 
Tested-By: Chris Healy 
---
 drivers/media/media-entity.c |2 ++
 drivers/media/v4l2-core/v4l2-dev.c   |   16 ---
 drivers/media/v4l2-core/v4l2-ioctl.c |   36 +-
 include/media/v4l2-dev.h |3 ++-
 include/uapi/linux/media.h   |1 +
 include/uapi/linux/videodev2.h   |9 +
 6 files changed, 58 insertions(+), 9 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index d8a2299..9014362 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -65,6 +65,8 @@ static inline const char *intf_type(struct media_interface 
*intf)
return "v4l-subdev";
case MEDIA_INTF_T_V4L_SWRADIO:
return "v4l-swradio";
+   case MEDIA_INTF_T_V4L_TOUCH:
+   return "v4l-touch";
case MEDIA_INTF_T_ALSA_PCM_CAPTURE:
return "alsa-pcm-capture";
case MEDIA_INTF_T_ALSA_PCM_PLAYBACK:
diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index 70b559d..21ba9b4 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -527,6 +527,7 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
bool is_vbi = vdev->vfl_type == VFL_TYPE_VBI;
bool is_radio = vdev->vfl_type == VFL_TYPE_RADIO;
bool is_sdr = vdev->vfl_type == VFL_TYPE_SDR;
+   bool is_tch = vdev->vfl_type == VFL_TYPE_TOUCH;
bool is_rx = vdev->vfl_dir != VFL_DIR_TX;
bool is_tx = vdev->vfl_dir != VFL_DIR_RX;
 
@@ -573,7 +574,7 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
if (ops->vidioc_enum_freq_bands || ops->vidioc_g_tuner || 
ops->vidioc_g_modulator)
set_bit(_IOC_NR(VIDIOC_ENUM_FREQ_BANDS), valid_ioctls);
 
-   if (is_vid) {
+   if (is_vid || is_tch) {
/* video specific ioctls */
if ((is_rx && (ops->vidioc_enum_fmt_vid_cap ||
   ops->vidioc_enum_fmt_vid_cap_mplane ||
@@ -662,7 +663,7 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
set_bit(_IOC_NR(VIDIOC_TRY_FMT), valid_ioctls);
}
 
-   if (is_vid || is_vbi || is_sdr) {
+   if (is_vid || is_vbi || is_sdr || is_tch) {
/* ioctls valid for video, vbi or sdr */
SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
@@ -675,7 +676,7 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_STREAMOFF, vidioc_streamoff);
}
 
-   if (is_vid || is_vbi) {
+   if (is_vid || is_vbi || is_tch) {
/* ioctls valid for video or vbi */
if (ops->vidioc_s_std)
set_bit(_IOC_NR(VIDIOC_ENUMSTD), valid_ioctls);
@@ -751,6 +752,10 @@ static int video_register_media_controller(struct 
video_device *vdev, int type)
intf_type = MEDIA_INTF_T_V4L_SWRADIO;
vdev->entity.function = MEDIA_ENT_F_IO_SWRADIO;
break;
+   case VFL_TYPE_TOUCH:
+   intf_type = MEDIA_INTF_T_V4L_TOUCH;
+   vdev->entity.function = MEDIA_ENT_F_IO_V4L;
+   break;
case VFL_TYPE_RADIO:
intf_type = MEDIA_INTF_T_V4L_RADIO;
/*
@@ -845,6 +850,8 @@ static int video_register_media_controller(struct 
video_device *vdev, int type)
  * %VFL_TYPE_SUBDEV - A subdevice
  *
  * %VFL_TYPE_SDR - Software Defined Radio
+ *
+ * %VFL_TYPE_TOUCH - A touch sensor
  */
 int __video_register_device(struct video_device *vdev, int type, int nr,
int warn_if_nr_in_use, struct module *owner)
@@ -888,6 +895,9 @@ int __video_register_device(struct video_device *vdev, int 
type, int nr,
/* Use device name 'swradio' because 'sdr' was already taken. */
name_base = "swradio";
break;
+   case VFL_TYPE_TOUCH:
+   name_base = "v4l-touch";
+   break;
default:
  

[PATCH v8 09/10] Input: synaptics-rmi4 - add support for F54 diagnostics

[Nick Dyer]

Function 54 implements access to various RMI4 diagnostic features.

This patch adds support for retrieving this data. It registers a V4L2
device to output the data to user space.

Signed-off-by: Nick Dyer 
Tested-by: Andrew Duggan 
Tested-by: Chris Healy 
---
 drivers/input/rmi4/Kconfig  |   11 +
 drivers/input/rmi4/Makefile |1 +
 drivers/input/rmi4/rmi_bus.c|3 +
 drivers/input/rmi4/rmi_driver.h |1 +
 drivers/input/rmi4/rmi_f54.c|  756 +++
 5 files changed, 772 insertions(+)
 create mode 100644 drivers/input/rmi4/rmi_f54.c

diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index f73df24..f3418b6 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -61,3 +61,14 @@ config RMI4_F30
 
  Function 30 provides GPIO and LED support for RMI4 devices. This
  includes support for buttons on TouchPads and ClickPads.
+
+config RMI4_F54
+   bool "RMI4 Function 54 (Analog diagnostics)"
+   depends on RMI4_CORE
+   depends on VIDEO_V4L2
+   select VIDEOBUF2_VMALLOC
+   help
+ Say Y here if you want to add support for RMI4 function 54
+
+ Function 54 provides access to various diagnostic features in certain
+ RMI4 touch sensors.
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 95c00a7..0bafc85 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -7,6 +7,7 @@ rmi_core-$(CONFIG_RMI4_2D_SENSOR) += rmi_2d_sensor.o
 rmi_core-$(CONFIG_RMI4_F11) += rmi_f11.o
 rmi_core-$(CONFIG_RMI4_F12) += rmi_f12.o
 rmi_core-$(CONFIG_RMI4_F30) += rmi_f30.o
+rmi_core-$(CONFIG_RMI4_F54) += rmi_f54.o
 
 # Transports
 obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index b368b05..3aedc65 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -315,6 +315,9 @@ static struct rmi_function_handler *fn_handlers[] = {
 #ifdef CONFIG_RMI4_F30
_f30_handler,
 #endif
+#ifdef CONFIG_RMI4_F54
+   _f54_handler,
+#endif
 };
 
 static void __rmi_unregister_function_handlers(int start_idx)
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index 6e140fa..8dfbebe 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -102,4 +102,5 @@ extern struct rmi_function_handler rmi_f01_handler;
 extern struct rmi_function_handler rmi_f11_handler;
 extern struct rmi_function_handler rmi_f12_handler;
 extern struct rmi_function_handler rmi_f30_handler;
+extern struct rmi_function_handler rmi_f54_handler;
 #endif
diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
new file mode 100644
index 000..bd86d3d
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -0,0 +1,756 @@
+/*
+ * Copyright (c) 2012-2015 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rmi_driver.h"
+
+#define F54_NAME   "rmi4_f54"
+
+/* F54 data offsets */
+#define F54_REPORT_DATA_OFFSET  3
+#define F54_FIFO_OFFSET 1
+#define F54_NUM_TX_OFFSET   1
+#define F54_NUM_RX_OFFSET   0
+
+/* F54 commands */
+#define F54_GET_REPORT  1
+#define F54_FORCE_CAL   2
+
+/* Fixed sizes of reports */
+#define F54_QUERY_LEN  27
+
+/* F54 capabilities */
+#define F54_CAP_BASELINE   (1 << 2)
+#define F54_CAP_IMAGE8 (1 << 3)
+#define F54_CAP_IMAGE16(1 << 6)
+
+/**
+ * enum rmi_f54_report_type - RMI4 F54 report types
+ *
+ * @F54_8BIT_IMAGE:Normalized 8-Bit Image Report. The capacitance variance
+ * from baseline for each pixel.
+ *
+ * @F54_16BIT_IMAGE:   Normalized 16-Bit Image Report. The capacitance variance
+ * from baseline for each pixel.
+ *
+ * @F54_RAW_16BIT_IMAGE:
+ * Raw 16-Bit Image Report. The raw capacitance for each
+ * pixel.
+ *
+ * @F54_TRUE_BASELINE: True Baseline Report. The baseline capacitance for each
+ * pixel.
+ *
+ * @F54_FULL_RAW_CAP:   Full Raw Capacitance Report. The raw capacitance with
+ * low reference set to its minimum value and high
+ * reference set to its maximum value.
+ *
+ * @F54_FULL_RAW_CAP_RX_OFFSET_REMOVED:
+ * Full Raw Capacitance with Receiver Offset Removed
+ * Report. Set Low reference to its minimum value and high
+ * references to its maximum value, then report the raw
+ * capacitance for each pixel.
+ */
+enum rmi_f54_report_type {
+   

[PATCH v8 08/10] Input: atmel_mxt_ts - add support for reference data

[Nick Dyer]

There are different datatypes available from a maXTouch chip. Add
support to retrieve reference data as well.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c |   57 ++
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 584198e..beede8f 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -135,6 +135,7 @@ struct t9_range {
 /* MXT_DEBUG_DIAGNOSTIC_T37 */
 #define MXT_DIAGNOSTIC_PAGEUP  0x01
 #define MXT_DIAGNOSTIC_DELTAS  0x10
+#define MXT_DIAGNOSTIC_REFS0x11
 #define MXT_DIAGNOSTIC_SIZE128
 
 #define MXT_FAMILY_1386160
@@ -249,6 +250,12 @@ struct mxt_dbg {
int input;
 };
 
+enum v4l_dbg_inputs {
+   MXT_V4L_INPUT_DELTAS,
+   MXT_V4L_INPUT_REFS,
+   MXT_V4L_INPUT_MAX,
+};
+
 static const struct v4l2_file_operations mxt_video_fops = {
.owner = THIS_MODULE,
.open = v4l2_fh_open,
@@ -2273,6 +2280,7 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
struct mxt_data *data = vb2_get_drv_priv(vb->vb2_queue);
u16 *ptr;
int ret;
+   u8 mode;
 
ptr = vb2_plane_vaddr(vb, 0);
if (!ptr) {
@@ -2280,7 +2288,18 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
goto fault;
}
 
-   ret = mxt_read_diagnostic_debug(data, MXT_DIAGNOSTIC_DELTAS, ptr);
+   switch (data->dbg.input) {
+   case MXT_V4L_INPUT_DELTAS:
+   default:
+   mode = MXT_DIAGNOSTIC_DELTAS;
+   break;
+
+   case MXT_V4L_INPUT_REFS:
+   mode = MXT_DIAGNOSTIC_REFS;
+   break;
+   }
+
+   ret = mxt_read_diagnostic_debug(data, mode, ptr);
if (ret)
goto fault;
 
@@ -2325,11 +2344,21 @@ static int mxt_vidioc_querycap(struct file *file, void 
*priv,
 static int mxt_vidioc_enum_input(struct file *file, void *priv,
   struct v4l2_input *i)
 {
-   if (i->index > 0)
+   if (i->index >= MXT_V4L_INPUT_MAX)
return -EINVAL;
 
i->type = V4L2_INPUT_TYPE_TOUCH;
-   strlcpy(i->name, "Mutual Capacitance Deltas", sizeof(i->name));
+
+   switch (i->index) {
+   case MXT_V4L_INPUT_REFS:
+   strlcpy(i->name, "Mutual Capacitance References",
+   sizeof(i->name));
+   break;
+   case MXT_V4L_INPUT_DELTAS:
+   strlcpy(i->name, "Mutual Capacitance Deltas", sizeof(i->name));
+   break;
+   }
+
return 0;
 }
 
@@ -2337,12 +2366,16 @@ static int mxt_set_input(struct mxt_data *data, 
unsigned int i)
 {
struct v4l2_pix_format *f = >dbg.format;
 
-   if (i > 0)
+   if (i >= MXT_V4L_INPUT_MAX)
return -EINVAL;
 
+   if (i == MXT_V4L_INPUT_DELTAS)
+   f->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
+   else
+   f->pixelformat = V4L2_TCH_FMT_TU16;
+
f->width = data->xy_switch ? data->ysize : data->xsize;
f->height = data->xy_switch ? data->xsize : data->ysize;
-   f->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_RAW;
f->bytesperline = f->width * sizeof(u16);
@@ -2383,7 +2416,19 @@ static int mxt_vidioc_enum_fmt(struct file *file, void 
*priv,
if (fmt->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
 
-   fmt->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
+   switch (fmt->index) {
+   case 0:
+   fmt->pixelformat = V4L2_TCH_FMT_TU16;
+   break;
+
+   case 1:
+   fmt->pixelformat = V4L2_TCH_FMT_DELTA_TD16;
+   break;
+
+   default:
+   return -EINVAL;
+   }
+
return 0;
 }
 
-- 
1.7.9.5

--
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 v8 07/10] Input: atmel_mxt_ts - add diagnostic data support for mXT1386

[Nick Dyer]

The mXT1386 family of chips have a different architecture which splits
the diagnostic data into 3 columns.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c |   31 +++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 7376c42..584198e 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -137,6 +137,10 @@ struct t9_range {
 #define MXT_DIAGNOSTIC_DELTAS  0x10
 #define MXT_DIAGNOSTIC_SIZE128
 
+#define MXT_FAMILY_1386160
+#define MXT1386_COLUMNS3
+#define MXT1386_PAGES_PER_COLUMN   8
+
 struct t37_debug {
 #ifdef CONFIG_TOUCHSCREEN_ATMEL_MXT_T37
u8 mode;
@@ -2140,13 +2144,27 @@ recheck:
 static u16 mxt_get_debug_value(struct mxt_data *data, unsigned int x,
   unsigned int y)
 {
+   struct mxt_info *info = >info;
struct mxt_dbg *dbg = >dbg;
unsigned int ofs, page;
+   unsigned int col = 0;
+   unsigned int col_width;
+
+   if (info->family_id == MXT_FAMILY_1386) {
+   col_width = info->matrix_ysize / MXT1386_COLUMNS;
+   col = y / col_width;
+   y = y % col_width;
+   } else {
+   col_width = info->matrix_ysize;
+   }
 
-   ofs = (y + (x * data->info.matrix_ysize)) * sizeof(u16);
+   ofs = (y + (x * col_width)) * sizeof(u16);
page = ofs / MXT_DIAGNOSTIC_SIZE;
ofs %= MXT_DIAGNOSTIC_SIZE;
 
+   if (info->family_id == MXT_FAMILY_1386)
+   page += col * MXT1386_PAGES_PER_COLUMN;
+
return get_unaligned_le16(>t37_buf[page].data[ofs]);
 }
 
@@ -2416,6 +2434,7 @@ static const struct video_device mxt_video_device = {
 
 static void mxt_debug_init(struct mxt_data *data)
 {
+   struct mxt_info *info = >info;
struct mxt_dbg *dbg = >dbg;
struct mxt_object *object;
int error;
@@ -2439,8 +2458,14 @@ static void mxt_debug_init(struct mxt_data *data)
 
/* Calculate size of data and allocate buffer */
dbg->t37_nodes = data->xsize * data->ysize;
-   dbg->t37_pages = DIV_ROUND_UP(data->xsize * data->info.matrix_ysize *
- sizeof(u16), sizeof(dbg->t37_buf->data));
+
+   if (info->family_id == MXT_FAMILY_1386)
+   dbg->t37_pages = MXT1386_COLUMNS * MXT1386_PAGES_PER_COLUMN;
+   else
+   dbg->t37_pages = DIV_ROUND_UP(data->xsize *
+ data->info.matrix_ysize *
+ sizeof(u16),
+ sizeof(dbg->t37_buf->data));
 
dbg->t37_buf = devm_kmalloc_array(>client->dev, dbg->t37_pages,
  sizeof(struct t37_debug), GFP_KERNEL);
-- 
1.7.9.5

--
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: si2157: new revision?

[Oleh Kravchenko]

Hello Antii!

I succeed with my tuner Evromedia USB Full Hybrid Full HD!!
$ w_scan -ft -c UA -M
...
tune to: QAM_AUTO f = 474000 kHz I999B8C999D999T999G999Y999 (0:1:43)
(time: 02:59.095)
service = 5 KANAL (Scopus Network Technologies)
service = NEWS ONE (News One)
service = EU MUSIC (EU MUSIC)
service = OTV (SPACECOM)
service = ICTV (ICTV)
service = SONCE (SOLAR MEDIA)

(time: 03:12.851) dumping lists (6 services)

MPlayer and VLC play video and sound, but it's very broken (ugly):
$ mplayer dvb://ICTV
...
[mpeg2video @ 0x7fbec7ae2900]00 motion_type at 43 1
[mpeg2video @ 0x7fbec7ae2900]00 motion_type at 1 4
[mpeg2video @ 0x7fbec7ae2900]00 motion_type at 33 8
[mpeg2video @ 0x7fbec7ae2900]00 motion_type at 27 9
[mpeg2video @ 0x7fbec7ae2900]00 motion_type at 21 13
[mpeg2video @ 0x7fbec7ae2900]00 motion_type at 14 17
[mpeg2video @ 0x7fbec7ae2900]00 motion_type at 23 25
[mpeg2video @ 0x7fbec7ae2900]00 motion_type at 16 27
[mpeg2video @ 0x7fbec7ae2900]ac-tex damaged at 11 31
[mpeg2video @ 0x7fbec7ae2900]slice mismatch
[mpeg2video @ 0x7fbec7ae2900]Warning MVs not available
[mpeg2video @ 0x7fbec7ae2900]concealing 599 DC, 599 AC, 599 MV errors in
B frame

Why happens?

On 13.07.16 11:22, Oleh Kravchenko wrote:
> Hello Antti!
> 
> Thank you for your advice. I succeed with demod chip!
> ...
> [ 3454.060649] cx231xx #0: (pipe 0x8b80): IN:  c0 0d 0f 00 74 00 04
> 00 <<< 6f 03 00 00
> [ 3454.060784] cx231xx #0 at cx231xx_i2c_xfer: read stop addr=0x64 len=10:
> [ 3454.060793] cx231xx #0: (pipe 0x8b80): IN:  c0 05 23 c8 00 00 04 00
> [ 3454.061392] <<< 80 44 33 30
> [ 3454.061403] cx231xx #0: (pipe 0x8b80): IN:  c0 05 63 c8 00 00 04
> 00 <<< 0b 73 33 30
> [ 3454.061899] cx231xx #0: (pipe 0x8b80): IN:  c0 05 61 c8 00 00 02
> 00 <<< 13 01
> [ 3454.062278]  80 44 33 30 0b 73 33 30 13 01
> [ 3454.062294] si2168 17-0064: firmware version: 3.0.19
> 
> But with tuner chip I have only error -32 :(
> ...
> [ 2795.770276] cx231xx #0 at cx231xx_i2c_xfer: read stop addr=0x60 len=1:
> [ 2795.770281] cx231xx #0: (pipe 0x8680): IN:  c0 06 21 c0 00 00 01 00
> [ 2795.771045] <<< fe
> [ 2795.771048]  fe
> [ 2795.771205] cx231xx #0 at cx231xx_i2c_xfer: write stop addr=0x60
> len=15: c0 00 00 00 00 01 01 01 01 01 01 02 00 00 01
> [ 2795.771234] cx231xx #0: (pipe 0x8600): OUT:  40 02 21 c0 00 00 0f 00
> [ 2795.771235] >>>
> [ 2795.771236]  c0
> [ 2795.771237]  00 00 00 00 01 01 01 01 01 01 02 00 00 01FAILED!
> [ 2795.771886] cx231xx 1-2:1.1: cx231xx_send_usb_command: failed with
> status --32
> [ 2795.771888] cx231xx #0 at cx231xx_i2c_xfer:  ERROR: -32
> 
> But I discovered one thing, error will come - if write payload is bigger
> than 4 bytes..
> Any ideas, why this happening?
> ...
> [ 3454.143285] cx231xx #0 at cx231xx_i2c_xfer: write stop addr=0x60
> len=4: c0 00 00 00
> [ 3454.143288] cx231xx #0: (pipe 0x8b00): OUT:  40 02 21 c0 00 00 04 00
> [ 3454.143289] >>> c0 00 00 00
> [ 3454.143884] cx231xx #0 at cx231xx_i2c_xfer: read stop addr=0x60 len=1:
> [ 3454.143893] cx231xx #0: (pipe 0x8b80): IN:  c0 06 21 c0 00 00 01 00
> [ 3454.144242] <<< fe
> [ 3454.144244]  fe
> [ 3454.144391] cx231xx #0 at cx231xx_i2c_xfer: write stop addr=0x60
> len=1: 02
> [ 3454.144406] cx231xx #0: (pipe 0x8b00): OUT:  40 02 21 c0 00 00 01 00
> [ 3454.144406] >>>
> [ 3454.144407]  02
> [ 3454.144767] cx231xx #0 at cx231xx_i2c_xfer: read stop addr=0x60 len=13:
> [ 3454.144767] cx231xx #0: (pipe 0x8b80): IN:  c0 06 23 c0 00 00 04
> 00 <<< fe fe fe fe
> [ 3454.145397] cx231xx #0: (pipe 0x8b80): IN:  c0 06 63 c0 00 00 04
> 00 <<< fe fe fe fe
> [ 3454.145893] cx231xx #0: (pipe 0x8b80): IN:  c0 06 63 c0 00 00 04 00
> [ 3454.146377] <<< fe fe fe fe
> [ 3454.146394] cx231xx #0: (pipe 0x8b80): IN:  c0 06 61 c0 00 00 01 00
> [ 3454.146639] <<< fe
> [ 3454.146640]  fe fe fe fe fe fe fe fe fe fe fe fe fe
> [ 3454.146676] si2157 15-0060: unknown chip version
> Si21254-\xfffe\xfffe\xfffe
> 
> 
> On 10.07.16 01:34, Antti Palosaari wrote:
>> Hey, that's your problem :] Driver development is all the time
>> resolving this kind of issues and you really need to resolve those
>> yourself.
>>
>> You will need to get I2C communication working with all the chips.
>> First si2168 demod and after it answers to I2C you will need to get
>> connection to Si2157 tuner. After both of those are answering you
>> could try to get tuning tests to see if demod locks. After demod locks
>> you know tuner is working and also demod is somehow working. If demod
>> lock but there is no picture you know problem is TS interface. Try
>> different TS settings for both USB-bridge and demod - those should
>> match. If it does not starts working then you have to look sniffs and
>> start replacing driver code with data from sniffs to until it starts
>> working => problematic setting is found.
>>
>> regards
>> Antti
>>
>>
>>
>> On 07/10/2016 12:18 AM, Oleh Kravchenko wrote:
>>> Hello!
>>>
>>> I'm 

Re: [PATCH v4 09/12] [media] vivid: Local optimization

[Ricardo Ribalda Delgado]

Hi Philipp:

On Mon, Jul 18, 2016 at 4:16 PM, Philipp Zabel  wrote:

> I had the best looking result with this variant, btw:
>
> y >>= 4;
> cb >>= 4;
> cr >>= 4;
> if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
> y = clamp(y, 16, 235);
> cb = clamp(cb, 16, 240);
> cr = clamp(cr, 16, 240);
> } else {
> y = clamp(y, 1, 254);
> cb = clamp(cb, 1, 254);
> cr = clamp(cr, 1, 254);
> }

I like this variant much better than mine. I have applied to my local
tree. So it will be what I post on v5

Thanks for you comments :)


btw: it is scary what the compiler optimizations are capable of doing these days


-- 
Ricardo Ribalda
--
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 10/18] [media] cx2341x.rst: add the contents of fw-upload.txt

[Mauro Carvalho Chehab]

Add the contents of fw-upload.txt, after converting it to
ReST format.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx2341x.rst | 53 +
 1 file changed, 53 insertions(+)

diff --git a/Documentation/media/v4l-drivers/cx2341x.rst 
b/Documentation/media/v4l-drivers/cx2341x.rst
index ed7e536c9bd0..0d1bd26623b9 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -152,6 +152,59 @@ Missing documentation
 - Decoder VTRACE event
 
 
+The cx2341x firmware upload
+---
+
+This document describes how to upload the cx2341x firmware to the card.
+
+How to find
+~~~
+
+See the web pages of the various projects that uses this chip for information
+on how to obtain the firmware.
+
+The firmware stored in a Windows driver can be detected as follows:
+
+- Each firmware image is 256k bytes.
+- The 1st 32-bit word of the Encoder image is 0xda7
+- The 1st 32-bit word of the Decoder image is 0x3a7
+- The 2nd 32-bit word of both images is 0xaa55bb66
+
+How to load
+~~~
+
+- Issue the FWapi command to stop the encoder if it is running. Wait for the
+  command to complete.
+- Issue the FWapi command to stop the decoder if it is running. Wait for the
+  command to complete.
+- Issue the I2C command to the digitizer to stop emitting VSYNC events.
+- Issue the FWapi command to halt the encoder's firmware.
+- Sleep for 10ms.
+- Issue the FWapi command to halt the decoder's firmware.
+- Sleep for 10ms.
+- Write 0x to register 0x2800 to stop the Video Display Module.
+- Write 0x0005 to register 0x2D00 to stop the AO (audio output?).
+- Write 0x to register 0xA064 to ping? the APU.
+- Write 0xFFFE to register 0x9058 to stop the VPU.
+- Write 0x to register 0x9054 to reset the HW blocks.
+- Write 0x0001 to register 0x9050 to stop the SPU.
+- Sleep for 10ms.
+- Write 0x001A to register 0x07FC to init the Encoder SDRAM's pre-charge.
+- Write 0x8640 to register 0x07F8 to init the Encoder SDRAM's refresh to 
1us.
+- Write 0x001A to register 0x08FC to init the Decoder SDRAM's pre-charge.
+- Write 0x8640 to register 0x08F8 to init the Decoder SDRAM's refresh to 
1us.
+- Sleep for 512ms. (600ms is recommended)
+- Transfer the encoder's firmware image to offset 0 in Encoder memory space.
+- Transfer the decoder's firmware image to offset 0 in Decoder memory space.
+- Use a read-modify-write operation to Clear bit 0 of register 0x9050 to
+  re-enable the SPU.
+- Sleep for 1 second.
+- Use a read-modify-write operation to Clear bits 3 and 0 of register 0x9058
+  to re-enable the VPU.
+- Sleep for 1 second.
+- Issue status API commands to both firmware images to verify.
+
+
 How to call the firmware API
 
 
-- 
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

[PATCH 12/18] [media] cx2341x: add contents of README.hm12

[Mauro Carvalho Chehab]

The README.hm12 file describes the proprietary format used
by this driver for raw format, called HM12. Add its description
at the document, after converted to ReST.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx2341x.rst   | 125 ++
 Documentation/video4linux/cx2341x/README.hm12 | 120 -
 2 files changed, 125 insertions(+), 120 deletions(-)
 delete mode 100644 Documentation/video4linux/cx2341x/README.hm12

diff --git a/Documentation/media/v4l-drivers/cx2341x.rst 
b/Documentation/media/v4l-drivers/cx2341x.rst
index 57ae45938919..15bfd345df48 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -3681,3 +3681,128 @@ Register 0x0004 holds the DMA Transfer Status:
 - bit 2:   DMA read error
 - bit 3:   DMA write error
 - bit 4:   Scatter-Gather array error
+
+Non-compressed file format
+--
+
+The cx23416 can produce (and the cx23415 can also read) raw YUV output. The
+format of a YUV frame is specific to this chip and is called HM12. 'HM' stands
+for 'Hauppauge Macroblock', which is a misnomer as 'Conexant Macroblock' would
+be more accurate.
+
+The format is YUV 4:2:0 which uses 1 Y byte per pixel and 1 U and V byte per
+four pixels.
+
+The data is encoded as two macroblock planes, the first containing the Y
+values, the second containing UV macroblocks.
+
+The Y plane is divided into blocks of 16x16 pixels from left to right
+and from top to bottom. Each block is transmitted in turn, line-by-line.
+
+So the first 16 bytes are the first line of the top-left block, the
+second 16 bytes are the second line of the top-left block, etc. After
+transmitting this block the first line of the block on the right to the
+first block is transmitted, etc.
+
+The UV plane is divided into blocks of 16x8 UV values going from left
+to right, top to bottom. Each block is transmitted in turn, line-by-line.
+
+So the first 16 bytes are the first line of the top-left block and
+contain 8 UV value pairs (16 bytes in total). The second 16 bytes are the
+second line of 8 UV pairs of the top-left block, etc. After transmitting
+this block the first line of the block on the right to the first block is
+transmitted, etc.
+
+The code below is given as an example on how to convert HM12 to separate
+Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels.
+
+The width of a frame is always 720 pixels, regardless of the actual specified
+width.
+
+If the height is not a multiple of 32 lines, then the captured video is
+missing macroblocks at the end and is unusable. So the height must be a
+multiple of 32.
+
+Raw format c example
+
+
+.. code-block:: c
+
+   #include 
+   #include 
+   #include 
+
+   static unsigned char frame[576*720*3/2];
+   static unsigned char framey[576*720];
+   static unsigned char frameu[576*720 / 4];
+   static unsigned char framev[576*720 / 4];
+
+   static void de_macro_y(unsigned char* dst, unsigned char *src, int 
dstride, int w, int h)
+   {
+   unsigned int y, x, i;
+
+   // descramble Y plane
+   // dstride = 720 = w
+   // The Y plane is divided into blocks of 16x16 pixels
+   // Each block in transmitted in turn, line-by-line.
+   for (y = 0; y < h; y += 16) {
+   for (x = 0; x < w; x += 16) {
+   for (i = 0; i < 16; i++) {
+   memcpy(dst + x + (y + i) * dstride, src, 16);
+   src += 16;
+   }
+   }
+   }
+   }
+
+   static void de_macro_uv(unsigned char *dstu, unsigned char *dstv, 
unsigned char *src, int dstride, int w, int h)
+   {
+   unsigned int y, x, i;
+
+   // descramble U/V plane
+   // dstride = 720 / 2 = w
+   // The U/V values are interlaced (UVUV...).
+   // Again, the UV plane is divided into blocks of 16x16 UV values.
+   // Each block in transmitted in turn, line-by-line.
+   for (y = 0; y < h; y += 16) {
+   for (x = 0; x < w; x += 8) {
+   for (i = 0; i < 16; i++) {
+   int idx = x + (y + i) * dstride;
+
+   dstu[idx+0] = src[0];  dstv[idx+0] = src[1];
+   dstu[idx+1] = src[2];  dstv[idx+1] = src[3];
+   dstu[idx+2] = src[4];  dstv[idx+2] = src[5];
+   dstu[idx+3] = src[6];  dstv[idx+3] = src[7];
+   dstu[idx+4] = src[8];  dstv[idx+4] = src[9];
+   dstu[idx+5] = src[10]; dstv[idx+5] = src[11];
+   dstu[idx+6] = src[12]; dstv[idx+6] = src[13];
+   dstu[idx+7] = src[14]; dstv[idx+7] = src[15];
+   src += 16;
+   }
+   }
+   }
+   }
+
+   
/*/
+   int 

Cycling Email List

[Carmen Adkins]

Hi,

I am Carmen,


Would you be interested in acquiring an email list of  "Cycling Email List" 
from USA?

We have data for Boat Owners Email List, Travelers Email List, RV Owners Email 
List, Iphone users, MotorCycle Owners Email List and many more. Choose the best 
one that meets your need. We provide you with current and active contact on 
every list. Take advantage of that, let your marketing efforts be fruitful.

Each record in the list Contact Name( First, Middle, Last Name), Direct Mailing 
Address ( Address, City, State, Zip Code), List Type, Source, IP Address, and 
Email Address.

All the contacts are opt-in verified, 100% permission based and can be used for 
unlimited multi-channel marketing.

Please let me know your thoughts towards Cycling Email List.

Research Analyst
Carmen Adkins


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
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 18/18] [media] doc-rst: better name the media books

[Mauro Carvalho Chehab]

The titles at the media books were misleading, and some books
were not numbered.

Rename the kAPI book to better reflect its contents, be more
consistent on the initial rst file for each book and better
name them.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/index.rst   |  2 +-
 Documentation/media/dvb-drivers/index.rst |  9 ++---
 Documentation/media/{media_drivers.rst => media_kapi.rst} |  9 ++---
 Documentation/media/media_uapi.rst| 10 +-
 Documentation/media/v4l-drivers/index.rst |  8 +---
 5 files changed, 23 insertions(+), 15 deletions(-)
 rename Documentation/media/{media_drivers.rst => media_kapi.rst} (76%)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 31273cc2e0bc..43c722f15292 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -15,7 +15,7 @@ Contents:
 
kernel-documentation
media/media_uapi
-   media/media_drivers
+   media/media_kapi
media/dvb-drivers/index
media/v4l-drivers/index
 
diff --git a/Documentation/media/dvb-drivers/index.rst 
b/Documentation/media/dvb-drivers/index.rst
index 14da36fe4d01..e1d4d87f2a47 100644
--- a/Documentation/media/dvb-drivers/index.rst
+++ b/Documentation/media/dvb-drivers/index.rst
@@ -2,9 +2,9 @@
 
 .. include:: 
 
-#
-Linux Digital Video Broadcast (DVB) subsystem
-#
+##
+Linux Digital TV driver-specific documentation
+##
 
 **Copyright** |copy| 2001-2016 : LinuxTV Developers
 
@@ -17,6 +17,9 @@ License".
 
 .. toctree::
:maxdepth: 5
+   :numbered:
+   :caption: Table of Contents
+   :name: dvb_mastertoc
 
intro
avermedia
diff --git a/Documentation/media/media_drivers.rst 
b/Documentation/media/media_kapi.rst
similarity index 76%
rename from Documentation/media/media_drivers.rst
rename to Documentation/media/media_kapi.rst
index 8e0f455ff6e0..0af80e90b7b5 100644
--- a/Documentation/media/media_drivers.rst
+++ b/Documentation/media/media_kapi.rst
@@ -2,9 +2,9 @@
 
 .. include:: 
 
-=
-Media subsystem core kAPI
-=
+===
+Media subsystem kernel internal API
+===
 
 **Copyright** |copy| 2009-2016 : LinuxTV Developers
 
@@ -16,6 +16,9 @@ License".
 
 .. toctree::
 :maxdepth: 5
+:numbered:
+:caption: Table of Contents
+:name: kapi_mastertoc
 
 kapi/v4l2-framework
 kapi/v4l2-controls
diff --git a/Documentation/media/media_uapi.rst 
b/Documentation/media/media_uapi.rst
index 5e872c8297b0..debe4531040b 100644
--- a/Documentation/media/media_uapi.rst
+++ b/Documentation/media/media_uapi.rst
@@ -2,9 +2,9 @@
 
 .. include:: 
 
-##
-Linux Media Infrastructure API
-##
+
+Linux Media Infrastructure userspace API
+
 
 **Copyright** |copy| 2009-2016 : LinuxTV Developers
 
@@ -15,10 +15,10 @@ the license is included in the chapter entitled "GNU Free 
Documentation
 License".
 
 
-.. contents::
-
 .. toctree::
 :maxdepth: 5
+:caption: Table of Contents
+:name: uapi_mastertoc
 
 intro
 uapi/v4l/v4l2
diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index 34990b536d39..8d1710234e5a 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -2,9 +2,9 @@
 
 .. include:: 
 
-###
-Video4Linux (V4L) subsystem
-###
+
+Video4Linux (V4L)  driver-specific documentation
+
 
 **Copyright** |copy| 1999-2016 : LinuxTV Developers
 
@@ -18,6 +18,8 @@ License".
 .. toctree::
:maxdepth: 5
:numbered:
+   :caption: Table of Contents
+   :name: v4l_mastertoc
 
fourcc
v4l-with-ir
-- 
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

[PATCH 15/18] [media] cx88.rst: add contents of hauppauge-wintv-cx88-ir.txt

[Mauro Carvalho Chehab]

Import the contents of hauppauge-wintv-cx88-ir.txt, after
converted to ReST into cx88.rst file.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx88.rst   | 62 ++
 .../video4linux/cx88/hauppauge-wintv-cx88-ir.txt   | 54 ---
 .../video4linux/hauppauge-wintv-cx88-ir.txt| 54 ---
 3 files changed, 62 insertions(+), 108 deletions(-)
 delete mode 100644 Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt
 delete mode 100644 Documentation/video4linux/hauppauge-wintv-cx88-ir.txt

diff --git a/Documentation/media/v4l-drivers/cx88.rst 
b/Documentation/media/v4l-drivers/cx88.rst
index c89dbfa5f9d6..97865007f51f 100644
--- a/Documentation/media/v4l-drivers/cx88.rst
+++ b/Documentation/media/v4l-drivers/cx88.rst
@@ -98,3 +98,65 @@ MO_OUTPUT_FORMAT (0x310164)
 0x47 is the sync byte for MPEG-2 transport stream packets.
 Datasheet incorrectly states to use 47 decimal. 188 is the length.
 All DVB compliant frontends output packets with this start code.
+
+Hauppauge WinTV cx88 IR information
+---
+
+The controls for the mux are GPIO [0,1] for source, and GPIO 2 for muting.
+
+==  =
+GPIO0  GPIO1
+==  =
+  00TV Audio
+  10FM radio
+  01Line-In
+  11Mono tuner bypass or CD passthru (tuner specific)
+==  =
+
+GPIO 16(I believe) is tied to the IR port (if present).
+
+
+From the data sheet:
+
+- Register 24'h20004  PCI Interrupt Status
+ - bit [18]  IR_SMP_INT Set when 32 input samples have been collected over
+ - gpio[16] pin into GP_SAMPLE register.
+
+What's missing from the data sheet:
+
+- Setup 4KHz sampling rate (roughly 2x oversampled; good enough for our RC5
+  compat remote)
+- set register 0x35C050 to  0xa80a80
+- enable sampling
+- set register 0x35C054 to 0x5
+- enable the IRQ bit 18 in the interrupt mask register (and
+  provide for a handler)
+
+GP_SAMPLE register is at 0x35C058
+
+Bits are then right shifted into the GP_SAMPLE register at the specified
+rate; you get an interrupt when a full DWORD is received.
+You need to recover the actual RC5 bits out of the (oversampled) IR sensor
+bits. (Hint: look for the 0/1and 1/0 crossings of the RC5 bi-phase data)  An
+actual raw RC5 code will span 2-3 DWORDS, depending on the actual alignment.
+
+I'm pretty sure when no IR signal is present the receiver is always in a
+marking state(1); but stray light, etc can cause intermittent noise values
+as well.  Remember, this is a free running sample of the IR receiver state
+over time, so don't assume any sample starts at any particular place.
+
+Additional info
+~~~
+
+This data sheet (google search) seems to have a lovely description of the
+RC5 basics:
+http://www.atmel.com/dyn/resources/prod_documents/doc2817.pdf
+
+This document has more data:
+http://www.nenya.be/beor/electronics/rc5.htm
+
+This document has a  how to decode a bi-phase data stream:
+http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt
+
+This document has still more info:
+http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm
diff --git a/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt 
b/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt
deleted file mode 100644
index f4329a38878e..
--- a/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-The controls for the mux are GPIO [0,1] for source, and GPIO 2 for muting.
-
-GPIO0  GPIO1
-  00TV Audio
-  10FM radio
-  01Line-In
-  11Mono tuner bypass or CD passthru (tuner specific)
-
-GPIO 16(i believe) is tied to the IR port (if present).
-
-
-
->From the data sheet:
- Register 24'h20004  PCI Interrupt Status
-  bit [18]  IR_SMP_INT Set when 32 input samples have been collected over
-  gpio[16] pin into GP_SAMPLE register.
-
-What's missing from the data sheet:
-
-Setup 4KHz sampling rate (roughly 2x oversampled; good enough for our RC5
-compat remote)
-set register 0x35C050 to  0xa80a80
-
-enable sampling
-set register 0x35C054 to 0x5
-
-Of course, enable the IRQ bit 18 in the interrupt mask register .(and
-provide for a handler)
-
-GP_SAMPLE register is at 0x35C058
-
-Bits are then right shifted into the GP_SAMPLE register at the specified
-rate; you get an interrupt when a full DWORD is received.
-You need to recover the actual RC5 bits out of the (oversampled) IR sensor
-bits. (Hint: look for the 0/1and 1/0 crossings of the RC5 bi-phase data)  An
-actual raw RC5 code will span 2-3 DWORDS, depending on the actual alignment.
-
-I'm pretty sure when no IR signal is present the receiver is always in a
-marking 

[PATCH 13/18] [media] cx2341x.rst: add contents of README.vbi

[Mauro Carvalho Chehab]

Finally, adds the content of README.vbi at cx2341x.rst after
its conversion to ReST format.

Now, add information about this chipset and its driver is
inside a single chapter at the media/v4l-drivers book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx2341x.rst  | 50 
 Documentation/video4linux/cx2341x/README.vbi | 45 -
 2 files changed, 50 insertions(+), 45 deletions(-)
 delete mode 100644 Documentation/video4linux/cx2341x/README.vbi

diff --git a/Documentation/media/v4l-drivers/cx2341x.rst 
b/Documentation/media/v4l-drivers/cx2341x.rst
index 15bfd345df48..e06d07ebdecd 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -3806,3 +3806,53 @@ Raw format c example
fclose(fin);
return 0;
}
+
+
+Format of embedded V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data
+-
+
+Author: Hans Verkuil 
+
+
+This section describes the V4L2_MPEG_STREAM_VBI_FMT_IVTV format of the VBI data
+embedded in an MPEG-2 program stream. This format is in part dictated by some
+hardware limitations of the ivtv driver (the driver for the Conexant cx23415/6
+chips), in particular a maximum size for the VBI data. Anything longer is cut
+off when the MPEG stream is played back through the cx23415.
+
+The advantage of this format is it is very compact and that all VBI data for
+all lines can be stored while still fitting within the maximum allowed size.
+
+The stream ID of the VBI data is 0xBD. The maximum size of the embedded data is
+4 + 43 * 36, which is 4 bytes for a header and 2 * 18 VBI lines with a 1 byte
+header and a 42 bytes payload each. Anything beyond this limit is cut off by
+the cx23415/6 firmware. Besides the data for the VBI lines we also need 36 bits
+for a bitmask determining which lines are captured and 4 bytes for a magic 
cookie,
+signifying that this data package contains V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI 
data.
+If all lines are used, then there is no longer room for the bitmask. To solve 
this
+two different magic numbers were introduced:
+
+'itv0': After this magic number two unsigned longs follow. Bits 0-17 of the 
first
+unsigned long denote which lines of the first field are captured. Bits 18-31 of
+the first unsigned long and bits 0-3 of the second unsigned long are used for 
the
+second field.
+
+'ITV0': This magic number assumes all VBI lines are captured, i.e. it 
implicitly
+implies that the bitmasks are 0x and 0xf.
+
+After these magic cookies (and the 8 byte bitmask in case of cookie 'itv0') the
+captured VBI lines start:
+
+For each line the least significant 4 bits of the first byte contain the data 
type.
+Possible values are shown in the table below. The payload is in the following 
42
+bytes.
+
+Here is the list of possible data types:
+
+.. code-block:: c
+
+   #define IVTV_SLICED_TYPE_TELETEXT   0x1 // Teletext (uses lines 
6-22 for PAL)
+   #define IVTV_SLICED_TYPE_CC 0x4 // Closed Captions 
(line 21 NTSC)
+   #define IVTV_SLICED_TYPE_WSS0x5 // Wide Screen Signal 
(line 23 PAL)
+   #define IVTV_SLICED_TYPE_VPS0x7 // Video Programming 
System (PAL) (line 16)
+
diff --git a/Documentation/video4linux/cx2341x/README.vbi 
b/Documentation/video4linux/cx2341x/README.vbi
deleted file mode 100644
index 5807cf156173..
--- a/Documentation/video4linux/cx2341x/README.vbi
+++ /dev/null
@@ -1,45 +0,0 @@
-
-Format of embedded V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data
-=
-
-This document describes the V4L2_MPEG_STREAM_VBI_FMT_IVTV format of the VBI 
data
-embedded in an MPEG-2 program stream. This format is in part dictated by some
-hardware limitations of the ivtv driver (the driver for the Conexant cx23415/6
-chips), in particular a maximum size for the VBI data. Anything longer is cut
-off when the MPEG stream is played back through the cx23415.
-
-The advantage of this format is it is very compact and that all VBI data for
-all lines can be stored while still fitting within the maximum allowed size.
-
-The stream ID of the VBI data is 0xBD. The maximum size of the embedded data is
-4 + 43 * 36, which is 4 bytes for a header and 2 * 18 VBI lines with a 1 byte
-header and a 42 bytes payload each. Anything beyond this limit is cut off by
-the cx23415/6 firmware. Besides the data for the VBI lines we also need 36 bits
-for a bitmask determining which lines are captured and 4 bytes for a magic 
cookie,
-signifying that this data package contains V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI 
data.
-If all lines are used, then there is no longer room for the bitmask. To solve 
this
-two different magic numbers were introduced:
-
-'itv0': After this magic number two unsigned longs follow. Bits 0-17 of the 
first
-unsigned long denote 

[PATCH 11/18] [media] cx2341x.rst: add contents of fw-osd-api.txt

[Mauro Carvalho Chehab]

Convert it to ReST format and add to cx2341x.rst file.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx2341x.rst  | 675 +++
 Documentation/video4linux/cx2341x/fw-osd-api.txt | 350 
 Documentation/video4linux/cx2341x/fw-upload.txt  |  49 --
 3 files changed, 675 insertions(+), 399 deletions(-)
 delete mode 100644 Documentation/video4linux/cx2341x/fw-osd-api.txt
 delete mode 100644 Documentation/video4linux/cx2341x/fw-upload.txt

diff --git a/Documentation/media/v4l-drivers/cx2341x.rst 
b/Documentation/media/v4l-drivers/cx2341x.rst
index 0d1bd26623b9..57ae45938919 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -280,6 +280,681 @@ an interrupt. Only the 16 Results fields are used, the 
Flags, Command, Return
 value and Timeout words are not used.
 
 
+OSD firmware API description
+
+
+.. note:: this API is part of the decoder firmware, so it's cx23415 only.
+
+
+
+CX2341X_OSD_GET_FRAMEBUFFER
+~~~
+
+Enum: 65/0x41
+
+Description
+^^^
+
+Return base and length of contiguous OSD memory.
+
+Result[0]
+^
+
+OSD base address
+
+Result[1]
+^
+
+OSD length
+
+
+
+CX2341X_OSD_GET_PIXEL_FORMAT
+
+
+Enum: 66/0x42
+
+Description
+^^^
+
+Query OSD format
+
+Result[0]
+^
+
+0=8bit index
+1=16bit RGB 5:6:5
+2=16bit ARGB 1:5:5:5
+3=16bit ARGB 1:4:4:4
+4=32bit ARGB 8:8:8:8
+
+
+
+CX2341X_OSD_SET_PIXEL_FORMAT
+
+
+Enum: 67/0x43
+
+Description
+^^^
+
+Assign pixel format
+
+Param[0]
+
+
+- 0=8bit index
+- 1=16bit RGB 5:6:5
+- 2=16bit ARGB 1:5:5:5
+- 3=16bit ARGB 1:4:4:4
+- 4=32bit ARGB 8:8:8:8
+
+
+
+CX2341X_OSD_GET_STATE
+~
+
+Enum: 68/0x44
+
+Description
+^^^
+
+Query OSD state
+
+Result[0]
+^
+
+- Bit  0   0=off, 1=on
+- Bits 1:2 alpha control
+- Bits 3:5 pixel format
+
+
+
+CX2341X_OSD_SET_STATE
+~
+
+Enum: 69/0x45
+
+Description
+^^^
+
+OSD switch
+
+Param[0]
+
+
+0=off, 1=on
+
+
+
+CX2341X_OSD_GET_OSD_COORDS
+~~
+
+Enum: 70/0x46
+
+Description
+^^^
+
+Retrieve coordinates of OSD area blended with video
+
+Result[0]
+^
+
+OSD buffer address
+
+Result[1]
+^
+
+Stride in pixels
+
+Result[2]
+^
+
+Lines in OSD buffer
+
+Result[3]
+^
+
+Horizontal offset in buffer
+
+Result[4]
+^
+
+Vertical offset in buffer
+
+
+
+CX2341X_OSD_SET_OSD_COORDS
+~~
+
+Enum: 71/0x47
+
+Description
+^^^
+
+Assign the coordinates of the OSD area to blend with video
+
+Param[0]
+
+
+buffer address
+
+Param[1]
+
+
+buffer stride in pixels
+
+Param[2]
+
+
+lines in buffer
+
+Param[3]
+
+
+horizontal offset
+
+Param[4]
+
+
+vertical offset
+
+
+
+CX2341X_OSD_GET_SCREEN_COORDS
+~
+
+Enum: 72/0x48
+
+Description
+^^^
+
+Retrieve OSD screen area coordinates
+
+Result[0]
+^
+
+top left horizontal offset
+
+Result[1]
+^
+
+top left vertical offset
+
+Result[2]
+^
+
+bottom right horizontal offset
+
+Result[3]
+^
+
+bottom right vertical offset
+
+
+
+CX2341X_OSD_SET_SCREEN_COORDS
+~
+
+Enum: 73/0x49
+
+Description
+^^^
+
+Assign the coordinates of the screen area to blend with video
+
+Param[0]
+
+
+top left horizontal offset
+
+Param[1]
+
+
+top left vertical offset
+
+Param[2]
+
+
+bottom left horizontal offset
+
+Param[3]
+
+
+bottom left vertical offset
+
+
+
+CX2341X_OSD_GET_GLOBAL_ALPHA
+
+
+Enum: 74/0x4A
+
+Description
+^^^
+
+Retrieve OSD global alpha
+
+Result[0]
+^
+
+global alpha: 0=off, 1=on
+
+Result[1]
+^
+
+bits 0:7 global alpha
+
+
+
+CX2341X_OSD_SET_GLOBAL_ALPHA
+
+
+Enum: 75/0x4B
+
+Description
+^^^
+
+Update global alpha
+
+Param[0]
+
+
+global alpha: 0=off, 1=on
+
+Param[1]
+
+
+global alpha (8 bits)
+
+Param[2]
+
+
+local alpha: 0=on, 1=off
+
+
+
+CX2341X_OSD_SET_BLEND_COORDS
+
+
+Enum: 78/0x4C
+
+Description
+^^^
+
+Move start of blending area within display buffer
+
+Param[0]
+
+
+horizontal offset in buffer
+
+Param[1]
+
+
+vertical offset in buffer
+
+
+
+CX2341X_OSD_GET_FLICKER_STATE
+~
+
+Enum: 79/0x4F
+
+Description
+^^^
+
+Retrieve flicker reduction module state
+
+Result[0]
+^
+
+flicker state: 0=off, 1=on
+
+
+
+CX2341X_OSD_SET_FLICKER_STATE
+~
+
+Enum: 80/0x50
+
+Description
+^^^
+
+Set flicker reduction module state
+
+Param[0]
+
+
+State: 0=off, 1=on
+
+
+
+CX2341X_OSD_BLT_COPY
+
+
+Enum: 82/0x52
+

[PATCH 17/18] [media] doc-rst: fix media kAPI documentation

[Mauro Carvalho Chehab]

I ended by adding twice each media header, because I saw some
missing stuff at the documents. It seems it was my mistake,
as everything seems to be there.

So, remove those extra stuff, to avoid duplicating the
documentation of the functions.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/kapi/dtv-core.rst  |  4 
 Documentation/media/kapi/mc-core.rst   |  8 
 Documentation/media/kapi/rc-core.rst   |  3 +--
 Documentation/media/kapi/v4l2-core.rst | 21 -
 4 files changed, 1 insertion(+), 35 deletions(-)

diff --git a/Documentation/media/kapi/dtv-core.rst 
b/Documentation/media/kapi/dtv-core.rst
index 3291190c1865..11da77e141ed 100644
--- a/Documentation/media/kapi/dtv-core.rst
+++ b/Documentation/media/kapi/dtv-core.rst
@@ -130,7 +130,3 @@ Digital TV Conditional Access kABI
 --
 
 .. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h
-
-
-.. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h
-   :export: drivers/media/dvb-core/dvb_ca_en50221.c
diff --git a/Documentation/media/kapi/mc-core.rst 
b/Documentation/media/kapi/mc-core.rst
index 2ab541ba6e88..c1fe0d69207d 100644
--- a/Documentation/media/kapi/mc-core.rst
+++ b/Documentation/media/kapi/mc-core.rst
@@ -261,11 +261,3 @@ in the end provide a way to use driver-specific callbacks.
 .. kernel-doc:: include/media/media-devnode.h
 
 .. kernel-doc:: include/media/media-entity.h
-
-
-
-.. kernel-doc:: include/media/media-device.h
-   :export: drivers/media/media-device.c
-
-.. kernel-doc:: include/media/media-entity.h
-   :export: drivers/media/media-entity.c
diff --git a/Documentation/media/kapi/rc-core.rst 
b/Documentation/media/kapi/rc-core.rst
index 9c244ac9ce92..a45895886257 100644
--- a/Documentation/media/kapi/rc-core.rst
+++ b/Documentation/media/kapi/rc-core.rst
@@ -6,8 +6,7 @@ Remote Controller core
 
 .. kernel-doc:: include/media/rc-core.h
 
-.. kernel-doc:: include/media/rc-core.h include/media/rc-map.h
-   :export: drivers/media/rc/rc-main.c drivers/media/rc/rc-raw.c
+.. kernel-doc:: include/media/rc-map.h
 
 LIRC
 
diff --git a/Documentation/media/kapi/v4l2-core.rst 
b/Documentation/media/kapi/v4l2-core.rst
index 4e2aa721d9c8..a1b73e8d6795 100644
--- a/Documentation/media/kapi/v4l2-core.rst
+++ b/Documentation/media/kapi/v4l2-core.rst
@@ -34,24 +34,3 @@ Video2Linux devices
 .. kernel-doc:: include/media/videobuf2-v4l2.h
 
 .. kernel-doc:: include/media/videobuf2-memops.h
-
-
-
-
-.. kernel-doc:: include/media/tveeprom.h
-   :export: drivers/media/common/tveeprom.c
-
-.. kernel-doc:: include/media/v4l2-ctrls.h
-   :export: drivers/media/v4l2-core/v4l2-ctrls.c
-
-.. kernel-doc:: include/media/v4l2-dv-timings.h
-   :export: drivers/media/v4l2-core/v4l2-dv-timings.c
-
-.. kernel-doc:: include/media/v4l2-flash-led-class.h
-   :export: drivers/media/v4l2-core/v4l2-flash-led-class.c
-
-.. kernel-doc:: include/media/v4l2-mc.h
-   :export: drivers/media/v4l2-core/v4l2-mc.c
-
-.. kernel-doc:: include/media/videobuf2-core.h
-   :export: drivers/media/v4l2-core/videobuf2-core.c
-- 
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

[PATCH 14/18] [media] cx88.rst: add contents from not-in-cx2388x-datasheet.txt

[Mauro Carvalho Chehab]

There are some information about missing/wrong documentation at
cx231xx datasheet. Add it to the cx88 chapter.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx88.rst   | 42 ++
 .../video4linux/not-in-cx2388x-datasheet.txt   | 41 -
 2 files changed, 42 insertions(+), 41 deletions(-)
 delete mode 100644 Documentation/video4linux/not-in-cx2388x-datasheet.txt

diff --git a/Documentation/media/v4l-drivers/cx88.rst 
b/Documentation/media/v4l-drivers/cx88.rst
index ac83292776da..c89dbfa5f9d6 100644
--- a/Documentation/media/v4l-drivers/cx88.rst
+++ b/Documentation/media/v4l-drivers/cx88.rst
@@ -55,4 +55,46 @@ the driver.  What to do then?
know which one the card has you can also have a look at the
list in CARDLIST.tuner
 
+Documentation missing at the cx88 datasheet
+---
 
+MO_OUTPUT_FORMAT (0x310164)
+
+.. code-block:: none
+
+  Previous default from DScaler: 0x1c1f0008
+  Digit 8: 31-28
+  28: PREVREMOD = 1
+
+  Digit 7: 27-24 (0xc = 12 = b1100 )
+  27: COMBALT = 1
+  26: PAL_INV_PHASE
+(DScaler apparently set this to 1, resulted in sucky picture)
+
+  Digits 6,5: 23-16
+  25-16: COMB_RANGE = 0x1f [default] (9 bits -> max 512)
+
+  Digit 4: 15-12
+  15: DISIFX = 0
+  14: INVCBF = 0
+  13: DISADAPT = 0
+  12: NARROWADAPT = 0
+
+  Digit 3: 11-8
+  11: FORCE2H
+  10: FORCEREMD
+  9: NCHROMAEN
+  8: NREMODEN
+
+  Digit 2: 7-4
+  7-6: YCORE
+  5-4: CCORE
+
+  Digit 1: 3-0
+  3: RANGE = 1
+  2: HACTEXT
+  1: HSFMT
+
+0x47 is the sync byte for MPEG-2 transport stream packets.
+Datasheet incorrectly states to use 47 decimal. 188 is the length.
+All DVB compliant frontends output packets with this start code.
diff --git a/Documentation/video4linux/not-in-cx2388x-datasheet.txt 
b/Documentation/video4linux/not-in-cx2388x-datasheet.txt
deleted file mode 100644
index edbfe744d21d..
--- a/Documentation/video4linux/not-in-cx2388x-datasheet.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-=
-MO_OUTPUT_FORMAT (0x310164)
-
-  Previous default from DScaler: 0x1c1f0008
-  Digit 8: 31-28
-  28: PREVREMOD = 1
-
-  Digit 7: 27-24 (0xc = 12 = b1100 )
-  27: COMBALT = 1
-  26: PAL_INV_PHASE
-(DScaler apparently set this to 1, resulted in sucky picture)
-
-  Digits 6,5: 23-16
-  25-16: COMB_RANGE = 0x1f [default] (9 bits -> max 512)
-
-  Digit 4: 15-12
-  15: DISIFX = 0
-  14: INVCBF = 0
-  13: DISADAPT = 0
-  12: NARROWADAPT = 0
-
-  Digit 3: 11-8
-  11: FORCE2H
-  10: FORCEREMD
-  9: NCHROMAEN
-  8: NREMODEN
-
-  Digit 2: 7-4
-  7-6: YCORE
-  5-4: CCORE
-
-  Digit 1: 3-0
-  3: RANGE = 1
-  2: HACTEXT
-  1: HSFMT
-
-0x47 is the sync byte for MPEG-2 transport stream packets.
-Datasheet incorrectly states to use 47 decimal. 188 is the length.
-All DVB compliant frontends output packets with this start code.
-
-=
-- 
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

[PATCH 01/18] [media] doc-rst: move bttv documentation to bttv.rst file

[Mauro Carvalho Chehab]

There were several files under Documentation/video4linux/bttv.

Instead of simply copying them to the rst folder, I opted to
merge into a single document and adjust the headers to
adjust the section levels and fix the cards tables.

There are two exceptions on the merge:

- The Tuners were renamed as a separate document, as they
  describe a separate driver;

- I removed the PROBLEMS section. It describes problems with
  the very first generation of 3D boards (Mistique/S3).
  It sounds very unlikely that someone would still need to
  install a bttv board on such hardware. Also, it is not
  very well written, IMHO.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/bttv.rst   | 1881 
 .../bttv/Tuners => media/v4l-drivers/tuners.rst}   |0
 Documentation/video4linux/bttv/CONTRIBUTORS|   25 -
 Documentation/video4linux/bttv/Cards   |  960 --
 Documentation/video4linux/bttv/ICs |   37 -
 Documentation/video4linux/bttv/Insmod-options  |  172 --
 Documentation/video4linux/bttv/MAKEDEV |   27 -
 Documentation/video4linux/bttv/Modprobe.conf   |   11 -
 Documentation/video4linux/bttv/Modules.conf|   14 -
 Documentation/video4linux/bttv/PROBLEMS|   62 -
 Documentation/video4linux/bttv/README  |   90 -
 Documentation/video4linux/bttv/README.WINVIEW  |   33 -
 Documentation/video4linux/bttv/README.freeze   |   74 -
 Documentation/video4linux/bttv/README.quirks   |   83 -
 Documentation/video4linux/bttv/Sound-FAQ   |  148 --
 Documentation/video4linux/bttv/Specs   |3 -
 Documentation/video4linux/bttv/THANKS  |   24 -
 17 files changed, 1881 insertions(+), 1763 deletions(-)
 create mode 100644 Documentation/media/v4l-drivers/bttv.rst
 rename Documentation/{video4linux/bttv/Tuners => media/v4l-drivers/tuners.rst} 
(100%)
 delete mode 100644 Documentation/video4linux/bttv/CONTRIBUTORS
 delete mode 100644 Documentation/video4linux/bttv/Cards
 delete mode 100644 Documentation/video4linux/bttv/ICs
 delete mode 100644 Documentation/video4linux/bttv/Insmod-options
 delete mode 100644 Documentation/video4linux/bttv/MAKEDEV
 delete mode 100644 Documentation/video4linux/bttv/Modprobe.conf
 delete mode 100644 Documentation/video4linux/bttv/Modules.conf
 delete mode 100644 Documentation/video4linux/bttv/PROBLEMS
 delete mode 100644 Documentation/video4linux/bttv/README
 delete mode 100644 Documentation/video4linux/bttv/README.WINVIEW
 delete mode 100644 Documentation/video4linux/bttv/README.freeze
 delete mode 100644 Documentation/video4linux/bttv/README.quirks
 delete mode 100644 Documentation/video4linux/bttv/Sound-FAQ
 delete mode 100644 Documentation/video4linux/bttv/Specs
 delete mode 100644 Documentation/video4linux/bttv/THANKS

diff --git a/Documentation/media/v4l-drivers/bttv.rst 
b/Documentation/media/v4l-drivers/bttv.rst
new file mode 100644
index ..d7d956835e38
--- /dev/null
+++ b/Documentation/media/v4l-drivers/bttv.rst
@@ -0,0 +1,1881 @@
+The bttv driver
+===
+
+
+Release notes for bttv
+--
+
+You'll need at least these config options for bttv:
+   CONFIG_I2C=m
+   CONFIG_I2C_ALGOBIT=m
+   CONFIG_VIDEO_DEV=m
+
+The latest bttv version is available from http://bytesex.org/bttv/
+
+
+Make bttv work with your card
+-
+
+Just try "modprobe bttv" and see if that works.
+
+If it doesn't bttv likely could not autodetect your card and needs some
+insmod options.  The most important insmod option for bttv is "card=n"
+to select the correct card type.  If you get video but no sound you've
+very likely specified the wrong (or no) card type.  A list of supported
+cards is in CARDLIST.bttv
+
+If bttv takes very long to load (happens sometimes with the cheap
+cards which have no tuner), try adding this to your modules.conf:
+   options i2c-algo-bit bit_test=1
+
+For the WinTV/PVR you need one firmware file from the driver CD:
+hcwamc.rbf.  The file is in the pvr45xxx.exe archive (self-extracting
+zip file, unzip can unpack it).  Put it into the /etc/pvr directory or
+use the firm_altera= insmod option to point the driver to the
+location of the file.
+
+If your card isn't listed in CARDLIST.bttv or if you have trouble making
+audio work, you should read the Sound-FAQ.
+
+
+Autodetecting cards
+---
+
+bttv uses the PCI Subsystem ID to autodetect the card type.  lspci lists
+the Subsystem ID in the second line, looks like this:
+
+00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
+   Subsystem: Hauppauge computer works Inc. WinTV/GO
+   Flags: bus master, medium devsel, latency 32, IRQ 5
+   Memory at e200 (32-bit, prefetchable) [size=4K]
+
+only bt878-based cards can have a subsystem ID (which does not mean
+that every card really has one).  bt848 cards can't have a 

[PATCH 03/18] [media] doc-rst: add documentation for tuners

[Mauro Carvalho Chehab]

Convert bttv/Tuners to ReST and add it to the media/v4l-drivers book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/index.rst  |  1 +
 Documentation/media/v4l-drivers/tuners.rst | 90 ++
 2 files changed, 54 insertions(+), 37 deletions(-)

diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index 6cb19b24271e..53bc53c948ab 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -21,6 +21,7 @@ License".
 
fourcc
v4l-with-ir
+   tuners
cardlist
bttv
cafe_ccic
diff --git a/Documentation/media/v4l-drivers/tuners.rst 
b/Documentation/media/v4l-drivers/tuners.rst
index 0a371d349542..c3e8a1cf64a6 100644
--- a/Documentation/media/v4l-drivers/tuners.rst
+++ b/Documentation/media/v4l-drivers/tuners.rst
@@ -1,19 +1,26 @@
-1) Tuner Programming
-
+Tuner drivers
+=
+
+Simple tuner Programming
+
+
 There are some flavors of Tuner programming APIs.
 These differ mainly by the bandswitch byte.
 
-L= LG_API   (VHF_LO=0x01, VHF_HI=0x02, UHF=0x08, radio=0x04)
-P= PHILIPS_API  (VHF_LO=0xA0, VHF_HI=0x90, UHF=0x30, radio=0x04)
-T= TEMIC_API(VHF_LO=0x02, VHF_HI=0x04, UHF=0x01)
-A= ALPS_API (VHF_LO=0x14, VHF_HI=0x12, UHF=0x11)
-M= PHILIPS_MK3  (VHF_LO=0x01, VHF_HI=0x02, UHF=0x04, radio=0x19)
+- L= LG_API   (VHF_LO=0x01, VHF_HI=0x02, UHF=0x08, radio=0x04)
+- P= PHILIPS_API  (VHF_LO=0xA0, VHF_HI=0x90, UHF=0x30, radio=0x04)
+- T= TEMIC_API(VHF_LO=0x02, VHF_HI=0x04, UHF=0x01)
+- A= ALPS_API (VHF_LO=0x14, VHF_HI=0x12, UHF=0x11)
+- M= PHILIPS_MK3  (VHF_LO=0x01, VHF_HI=0x02, UHF=0x04, radio=0x19)
 
-2) Tuner Manufacturers
-==
+Tuner Manufacturers
+---
 
-SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
-  TCP [ABCJLMNQ] 90[89][125] [DP] [ACD] 27 [ABCD]
+- SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
+
+.. code-block:: none
+
+ TCP [ABCJLMNQ] 90[89][125] [DP] [ACD] 27 [ABCD]
  [ABCJLMNQ]:
A= BG+DK
B= BG
@@ -37,9 +44,12 @@ SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
  [ABCD]:
3-wire/I2C tuning, 2-band/3-band
 
- These Tuners are PHILIPS_API compatible.
+These Tuners are PHILIPS_API compatible.
 
 Philips Tuner identification: (e.g. FM1216MF)
+
+.. code-block:: none
+
   F[IRMQ]12[1345]6{MF|ME|MP}
   F[IRMQ]:
FI12x6: Tuner Series
@@ -63,6 +73,9 @@ Philips Tuner identification: (e.g. FM1216MF)
   MK3 series introduced in 2002 w/ PHILIPS_MK3_API
 
 Temic Tuner identification: (.e.g 4006FH5)
+
+.. code-block:: none
+
4[01][0136][269]F[HYNR]5
 40x2: Tuner (5V/33V), TEMIC_API.
 40x6: Tuner 5V
@@ -82,34 +95,37 @@ Temic Tuner identification: (.e.g 4006FH5)
   Note: Only 40x2 series has TEMIC_API, all newer tuners have PHILIPS_API.
 
 LG Innotek Tuner:
-  TPI8NSR11 : NTSC J/M(TPI8NSR01 w/FM)  (P,210/497)
-  TPI8PSB11 : PAL B/G (TPI8PSB01 w/FM)  (P,170/450)
-  TAPC-I701 : PAL I   (TAPC-I001 w/FM)  (P,170/450)
-  TPI8PSB12 : PAL D/K+B/G (TPI8PSB02 w/FM)  (P,170/450)
-  TAPC-H701P: NTSC_JP (TAPC-H001P w/FM) (L,170/450)
-  TAPC-G701P: PAL B/G (TAPC-G001P w/FM) (L,170/450)
-  TAPC-W701P: PAL I   (TAPC-W001P w/FM) (L,170/450)
-  TAPC-Q703P: PAL D/K (TAPC-Q001P w/FM) (L,170/450)
-  TAPC-Q704P: PAL D/K+I   (L,170/450)
-  TAPC-G702P: PAL D/K+B/G (L,170/450)
 
-  TADC-H002F: NTSC (L,175/410?; 2-B, C-W+11, W+12-69)
-  TADC-M201D: PAL D/K+B/G+I (L,143/425)  (sound control at I2C address 0xc8)
-  TADC-T003F: NTSC Taiwan  (L,175/410?; 2-B, C-W+11, W+12-69)
-  Suffix:
-P= Standard phono female socket
-D= IEC female socket
-F= F-connector
+- TPI8NSR11 : NTSC J/M(TPI8NSR01 w/FM)  (P,210/497)
+- TPI8PSB11 : PAL B/G (TPI8PSB01 w/FM)  (P,170/450)
+- TAPC-I701 : PAL I   (TAPC-I001 w/FM)  (P,170/450)
+- TPI8PSB12 : PAL D/K+B/G (TPI8PSB02 w/FM)  (P,170/450)
+- TAPC-H701P: NTSC_JP (TAPC-H001P w/FM) (L,170/450)
+- TAPC-G701P: PAL B/G (TAPC-G001P w/FM) (L,170/450)
+- TAPC-W701P: PAL I   (TAPC-W001P w/FM) (L,170/450)
+- TAPC-Q703P: PAL D/K (TAPC-Q001P w/FM) (L,170/450)
+- TAPC-Q704P: PAL D/K+I   (L,170/450)
+- TAPC-G702P: PAL D/K+B/G (L,170/450)
+
+- TADC-H002F: NTSC (L,175/410?; 2-B, C-W+11, W+12-69)
+- TADC-M201D: PAL D/K+B/G+I (L,143/425)  (sound control at I2C address 0xc8)
+- TADC-T003F: NTSC Taiwan  (L,175/410?; 2-B, C-W+11, W+12-69)
+
+Suffix:
+  - P= Standard phono female socket
+  - D= IEC female socket
+  - F= F-connector
 
 Other Tuners:
-TCL2002MB-1 : PAL BG + DK   =TUNER_LG_PAL_NEW_TAPC
-TCL2002MB-1F: PAL BG + DK w/FM  =PHILIPS_PAL
-TCL2002MI-2 : PAL I= ??
+
+- TCL2002MB-1 : PAL BG + DK   =TUNER_LG_PAL_NEW_TAPC
+- TCL2002MB-1F: PAL BG + DK w/FM  =PHILIPS_PAL
+- TCL2002MI-2 : PAL I  = ??
 
 ALPS Tuners:
-   Most are LG_API compatible
-   TSCH6 has ALPS_API (TSCH5 ?)
-   

[PATCH 09/18] [media] cx2341x.rst: add contents of fw-memory.txt

[Mauro Carvalho Chehab]

Convert the content to ReST and add it at the cx231xx.rst
file.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx2341x.rst | 151 
 Documentation/video4linux/cx2341x/fw-memory.txt | 139 --
 2 files changed, 151 insertions(+), 139 deletions(-)
 delete mode 100644 Documentation/video4linux/cx2341x/fw-memory.txt

diff --git a/Documentation/media/v4l-drivers/cx2341x.rst 
b/Documentation/media/v4l-drivers/cx2341x.rst
index ca2f15c5b8f7..ed7e536c9bd0 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -1,6 +1,157 @@
 The cx2341x driver
 ==
 
+Memory at cx2341x chips
+---
+
+This section describes the cx2341x memory map and documents some of the
+register space.
+
+.. note:: the memory long words are little-endian ('intel format').
+
+.. warning::
+
+   This information was figured out from searching through the memory
+   and registers, this information may not be correct and is certainly
+   not complete, and was not derived from anything more than searching
+   through the memory space with commands like:
+
+   .. code-block:: none
+
+   ivtvctl -O min=0x0200,max=0x02ff
+
+   So take this as is, I'm always searching for more stuff, it's a large
+   register space :-).
+
+Memory Map
+~~
+
+The cx2341x exposes its entire 64M memory space to the PCI host via the PCI 
BAR0
+(Base Address Register 0). The addresses here are offsets relative to the
+address held in BAR0.
+
+.. code-block:: none
+
+   0x-0x00ff Encoder memory space
+   0x-0x0003 Encode.rom
+   ???-??? MPEG buffer(s)
+   ???-??? Raw video capture buffer(s)
+   ???-??? Raw audio capture buffer(s)
+   ???-??? Display buffers (6 or 9)
+
+   0x0100-0x01ff Decoder memory space
+   0x0100-0x0103 Decode.rom
+   ???-??? MPEG buffers(s)
+   0x0114b000-0x0115afff Audio.rom (deprecated?)
+
+   0x0200-0x0200 Register Space
+
+Registers
+~
+
+The registers occupy the 64k space starting at the 0x0200 offset from BAR0.
+All of these registers are 32 bits wide.
+
+.. code-block:: none
+
+   DMA Registers 0x000-0xff:
+
+   0x00 - Control:
+   0=reset/cancel, 1=read, 2=write, 4=stop
+   0x04 - DMA status:
+   1=read busy, 2=write busy, 4=read error, 8=write error, 16=link 
list error
+   0x08 - pci DMA pointer for read link list
+   0x0c - pci DMA pointer for write link list
+   0x10 - read/write DMA enable:
+   1=read enable, 2=write enable
+   0x14 - always 0x, if set any lower instability occurs, 0x00 
crashes
+   0x18 - ??
+   0x1c - always 0x20 or 32, smaller values slow down DMA transactions
+   0x20 - always value of 0x780a010a
+   0x24-0x3c - usually just random values???
+   0x40 - Interrupt status
+   0x44 - Write a bit here and shows up in Interrupt status 0x40
+   0x48 - Interrupt Mask
+   0x4C - always value of 0xfffd,
+   if changed to 0x DMA write interrupts break.
+   0x50 - always 0x
+   0x54 - always 0x (0x4c, 0x50, 0x54 seem like interrupt masks, 
are
+   3 processors on chip, Java ones, VPU, SPU, APU, maybe these are 
the
+   interrupt masks???).
+   0x60-0x7C - random values
+   0x80 - first write linked list reg, for Encoder Memory addr
+   0x84 - first write linked list reg, for pci memory addr
+   0x88 - first write linked list reg, for length of buffer in memory addr
+   (|0x8000 or this for last link)
+   0x8c-0xdc - rest of write linked list reg, 8 sets of 3 total, DMA goes 
here
+   from linked list addr in reg 0x0c, firmware must push through or
+   something.
+   0xe0 - first (and only) read linked list reg, for pci memory addr
+   0xe4 - first (and only) read linked list reg, for Decoder memory addr
+   0xe8 - first (and only) read linked list reg, for length of buffer
+   0xec-0xff - Nothing seems to be in these registers, 0xec-f4 are 
0x.
+
+Memory locations for Encoder Buffers 0x700-0x7ff:
+
+These registers show offsets of memory locations pertaining to each
+buffer area used for encoding, have to shift them by <<1 first.
+
+- 0x07F8: Encoder SDRAM refresh
+- 0x07FC: Encoder SDRAM pre-charge
+
+Memory locations for Decoder Buffers 0x800-0x8ff:
+
+These registers show offsets of memory locations pertaining to each
+buffer area used for decoding, have to shift them by <<1 first.
+
+- 0x08F8: Decoder SDRAM refresh
+- 0x08FC: Decoder SDRAM pre-charge
+
+Other memory locations:
+
+- 0x2800: Video Display Module control
+- 0x2D00: AO (audio output?) control
+- 0x2D24: Bytes Flushed
+- 0x7000: LSB 

[PATCH 00/18] Complete moving media documentation to ReST format

[Mauro Carvalho Chehab]

This patch series finally ends the conversion of the media documents to ReST
format.

After this series, *all* media documentation will be inside a ReST book.

They'll be:

- Linux Media Infrastructure userspace API 
  - With 5 parts:
- Video for Linux API
- Digital TV API
- Remote Controller API
- Media Controller API
- CEC API
-  Media subsystem kernel internal API
-  Linux Digital TV driver-specific documentation
- Video4Linux (V4L) driver-specific documentation

All those documents are built automatically, once by day, at linuxtv.org:

uAPI:
https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html

kAPI:
https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_kapi.html

DVB drivers:

https://linuxtv.org/downloads/v4l-dvb-apis-new/media/dvb-drivers/index.html

V4L drivers:

https://linuxtv.org/downloads/v4l-dvb-apis-new/media/v4l-drivers/index.html

That's said, there are lots of old/deprecated information there. Also, as the 
books
are actually an aggregation of stuff written on different times, by different 
people,
they don't look all the same.

I tried to fix some things while doing the documentation patch series, but 
there are
still lots of things to be done, specially at the DVB and V4L drivers 
documentation.

There are also several V4L2 core functions not documented at the kAPI book, and
the V4L framework document there is not properly cross referenced.

Anyway, now that everything can be seen on 4 books via html, maybe it will now
be easier to identify and fix the gaps. I intend do do it for Kernel 4.9.

I'm merging all stuff on my main development tree:
https://git.linuxtv.org//mchehab/experimental.git/log/?h=docs-next

I should be merge soon today what we currently have at media mainstream tree.

Regards,
Mauro

Mauro Carvalho Chehab (18):
  [media] doc-rst: move bttv documentation to bttv.rst file
  [media] doc-rst: add documentation for bttv driver
  [media] doc-rst: add documentation for tuners
  [media] doc-rst: start adding documentation for cx2341x
  [media] cx2341x.rst: add fw-decoder-registers.txt content
  [media] cx2341x.rst: Add the contents of fw-encoder-api.txt
  [media] cx2341x.rst: add the contents of fw-calling.txt
  [media] cx2341x.rst: add contents of fw-dma.txt
  [media] cx2341x.rst: add contents of fw-memory.txt
  [media] cx2341x.rst: add the contents of fw-upload.txt
  [media] cx2341x.rst: add contents of fw-osd-api.txt
  [media] cx2341x: add contents of README.hm12
  [media] cx2341x.rst: add contents of README.vbi
  [media] cx88.rst: add contents from not-in-cx2388x-datasheet.txt
  [media] cx88.rst: add contents of hauppauge-wintv-cx88-ir.txt
  [media] get rid of Documentation/video4linux/lifeview.txt
  [media] doc-rst: fix media kAPI documentation
  [media] doc-rst: better name the media books

 Documentation/index.rst|2 +-
 Documentation/media/dvb-drivers/index.rst  |9 +-
 Documentation/media/kapi/dtv-core.rst  |4 -
 Documentation/media/kapi/mc-core.rst   |8 -
 Documentation/media/kapi/rc-core.rst   |3 +-
 Documentation/media/kapi/v4l2-core.rst |   21 -
 .../media/{media_drivers.rst => media_kapi.rst}|9 +-
 Documentation/media/media_uapi.rst |   10 +-
 Documentation/media/v4l-drivers/bttv.rst   | 1923 ++
 Documentation/media/v4l-drivers/cx2341x.rst| 3858 
 Documentation/media/v4l-drivers/cx88.rst   |  104 +
 Documentation/media/v4l-drivers/index.rst  |   11 +-
 Documentation/media/v4l-drivers/saa7134.rst|   36 +
 Documentation/media/v4l-drivers/tuners.rst |  131 +
 Documentation/video4linux/bttv/CONTRIBUTORS|   25 -
 Documentation/video4linux/bttv/Cards   |  960 -
 Documentation/video4linux/bttv/ICs |   37 -
 Documentation/video4linux/bttv/Insmod-options  |  172 -
 Documentation/video4linux/bttv/MAKEDEV |   27 -
 Documentation/video4linux/bttv/Modprobe.conf   |   11 -
 Documentation/video4linux/bttv/Modules.conf|   14 -
 Documentation/video4linux/bttv/PROBLEMS|   62 -
 Documentation/video4linux/bttv/README  |   90 -
 Documentation/video4linux/bttv/README.WINVIEW  |   33 -
 Documentation/video4linux/bttv/README.freeze   |   74 -
 Documentation/video4linux/bttv/README.quirks   |   83 -
 Documentation/video4linux/bttv/Sound-FAQ   |  148 -
 Documentation/video4linux/bttv/Specs   |3 -
 Documentation/video4linux/bttv/THANKS  |   24 -
 Documentation/video4linux/bttv/Tuners  |  115 -
 Documentation/video4linux/cx2341x/README.hm12  |  120 -
 Documentation/video4linux/cx2341x/README.vbi   |   45 -
 Documentation/video4linux/cx2341x/fw-calling.txt   |   69 -
 .../video4linux/cx2341x/fw-decoder-api.txt |  297 --
 

[PATCH 07/18] [media] cx2341x.rst: add the contents of fw-calling.txt

[Mauro Carvalho Chehab]

Convert it to ReST and add its contents at this file.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx2341x.rst  | 75 
 Documentation/video4linux/cx2341x/fw-calling.txt | 69 --
 2 files changed, 75 insertions(+), 69 deletions(-)
 delete mode 100644 Documentation/video4linux/cx2341x/fw-calling.txt

diff --git a/Documentation/media/v4l-drivers/cx2341x.rst 
b/Documentation/media/v4l-drivers/cx2341x.rst
index 2677ac6fd649..cbfa14eccd76 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -1,6 +1,81 @@
 The cx2341x driver
 ==
 
+How to call the firmware API
+
+
+The preferred calling convention is known as the firmware mailbox. The
+mailboxes are basically a fixed length array that serves as the call-stack.
+
+Firmware mailboxes can be located by searching the encoder and decoder memory
+for a 16 byte signature. That signature will be located on a 256-byte boundary.
+
+Signature:
+
+.. code-block:: none
+
+   0x78, 0x56, 0x34, 0x12, 0x12, 0x78, 0x56, 0x34,
+   0x34, 0x12, 0x78, 0x56, 0x56, 0x34, 0x12, 0x78
+
+The firmware implements 20 mailboxes of 20 32-bit words. The first 10 are
+reserved for API calls. The second 10 are used by the firmware for event
+notification.
+
+  == =
+  Index  Name
+  == =
+  0  Flags
+  1  Command
+  2  Return value
+  3  Timeout
+  4-19   Parameter/Result
+  == =
+
+
+The flags are defined in the following table. The direction is from the
+perspective of the firmware.
+
+   == 
+  Bit  Direction  Purpose
+   == 
+  2O  Firmware has processed the command.
+  1I  Driver has finished setting the parameters.
+  0I  Driver is using this mailbox.
+   == 
+
+The command is a 32-bit enumerator. The API specifics may be found in this
+chapter.
+
+The return value is a 32-bit enumerator. Only two values are currently defined:
+
+- 0=success
+- -1=command undefined.
+
+There are 16 parameters/results 32-bit fields. The driver populates these 
fields
+with values for all the parameters required by the call. The driver overwrites
+these fields with result values returned by the call.
+
+The timeout value protects the card from a hung driver thread. If the driver
+doesn't handle the completed call within the timeout specified, the firmware
+will reset that mailbox.
+
+To make an API call, the driver iterates over each mailbox looking for the
+first one available (bit 0 has been cleared). The driver sets that bit, fills
+in the command enumerator, the timeout value and any required parameters. The
+driver then sets the parameter ready bit (bit 1). The firmware scans the
+mailboxes for pending commands, processes them, sets the result code, populates
+the result value array with that call's return values and sets the call
+complete bit (bit 2). Once bit 2 is set, the driver should retrieve the results
+and clear all the flags. If the driver does not perform this task within the
+time set in the timeout register, the firmware will reset that mailbox.
+
+Event notifications are sent from the firmware to the host. The host tells the
+firmware which events it is interested in via an API call. That call tells the
+firmware which notification mailbox to use. The firmware signals the host via
+an interrupt. Only the 16 Results fields are used, the Flags, Command, Return
+value and Timeout words are not used.
+
+
 Encoder firmware API description
 
 
diff --git a/Documentation/video4linux/cx2341x/fw-calling.txt 
b/Documentation/video4linux/cx2341x/fw-calling.txt
deleted file mode 100644
index 8d21181de537..
--- a/Documentation/video4linux/cx2341x/fw-calling.txt
+++ /dev/null
@@ -1,69 +0,0 @@
-This page describes how to make calls to the firmware api.
-
-How to call
-===
-
-The preferred calling convention is known as the firmware mailbox. The
-mailboxes are basically a fixed length array that serves as the call-stack.
-
-Firmware mailboxes can be located by searching the encoder and decoder memory
-for a 16 byte signature. That signature will be located on a 256-byte boundary.
-
-Signature:
-0x78, 0x56, 0x34, 0x12, 0x12, 0x78, 0x56, 0x34,
-0x34, 0x12, 0x78, 0x56, 0x56, 0x34, 0x12, 0x78
-
-The firmware implements 20 mailboxes of 20 32-bit words. The first 10 are
-reserved for API calls. The second 10 are used by the firmware for event
-notification.
-
-  Index  Name
-  -  
-  0  Flags
-  1  Command
-  2  Return value
-  3  Timeout
-  4-19   Parameter/Result
-
-
-The flags are defined in the following table. The direction is from the
-perspective 

[PATCH 06/18] [media] cx2341x.rst: Add the contents of fw-encoder-api.txt

[Mauro Carvalho Chehab]

Convert its contents to ReST and add to cx2341x.rst.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx2341x.rst| 1241 
 .../video4linux/cx2341x/fw-encoder-api.txt |  709 ---
 2 files changed, 1241 insertions(+), 709 deletions(-)
 delete mode 100644 Documentation/video4linux/cx2341x/fw-encoder-api.txt

diff --git a/Documentation/media/v4l-drivers/cx2341x.rst 
b/Documentation/media/v4l-drivers/cx2341x.rst
index f1c2d8d5978d..2677ac6fd649 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -1,6 +1,1247 @@
 The cx2341x driver
 ==
 
+Encoder firmware API description
+
+
+CX2341X_ENC_PING_FW
+~~~
+
+Enum: 128/0x80
+
+Description
+^^^
+
+Does nothing. Can be used to check if the firmware is responding.
+
+
+
+CX2341X_ENC_START_CAPTURE
+~
+
+Enum: 129/0x81
+
+Description
+^^^
+
+Commences the capture of video, audio and/or VBI data. All encoding
+parameters must be initialized prior to this API call. Captures frames
+continuously or until a predefined number of frames have been captured.
+
+Param[0]
+
+
+Capture stream type:
+
+   - 0=MPEG
+   - 1=Raw
+   - 2=Raw passthrough
+   - 3=VBI
+
+
+Param[1]
+
+
+Bitmask:
+
+   - Bit 0 when set, captures YUV
+   - Bit 1 when set, captures PCM audio
+   - Bit 2 when set, captures VBI (same as param[0]=3)
+   - Bit 3 when set, the capture destination is the decoder
+ (same as param[0]=2)
+   - Bit 4 when set, the capture destination is the host
+
+.. note:: this parameter is only meaningful for RAW capture type.
+
+
+
+CX2341X_ENC_STOP_CAPTURE
+
+
+Enum: 130/0x82
+
+Description
+^^^
+
+Ends a capture in progress
+
+Param[0]
+
+
+- 0=stop at end of GOP (generates IRQ)
+- 1=stop immediate (no IRQ)
+
+Param[1]
+
+
+Stream type to stop, see param[0] of API 0x81
+
+Param[2]
+
+
+Subtype, see param[1] of API 0x81
+
+
+
+CX2341X_ENC_SET_AUDIO_ID
+
+
+Enum: 137/0x89
+
+Description
+^^^
+
+Assigns the transport stream ID of the encoded audio stream
+
+Param[0]
+
+
+Audio Stream ID
+
+
+
+CX2341X_ENC_SET_VIDEO_ID
+
+
+Enum: 139/0x8B
+
+Description
+^^^
+
+Set video transport stream ID
+
+Param[0]
+
+
+Video stream ID
+
+
+
+CX2341X_ENC_SET_PCR_ID
+~~
+
+Enum: 141/0x8D
+
+Description
+^^^
+
+Assigns the transport stream ID for PCR packets
+
+Param[0]
+
+
+PCR Stream ID
+
+
+
+CX2341X_ENC_SET_FRAME_RATE
+~~
+
+Enum: 143/0x8F
+
+Description
+^^^
+
+Set video frames per second. Change occurs at start of new GOP.
+
+Param[0]
+
+
+- 0=30fps
+- 1=25fps
+
+
+
+CX2341X_ENC_SET_FRAME_SIZE
+~~
+
+Enum: 145/0x91
+
+Description
+^^^
+
+Select video stream encoding resolution.
+
+Param[0]
+
+
+Height in lines. Default 480
+
+Param[1]
+
+
+Width in pixels. Default 720
+
+
+
+CX2341X_ENC_SET_BIT_RATE
+
+
+Enum: 149/0x95
+
+Description
+^^^
+
+Assign average video stream bitrate.
+
+Param[0]
+
+
+0=variable bitrate, 1=constant bitrate
+
+Param[1]
+
+
+bitrate in bits per second
+
+Param[2]
+
+
+peak bitrate in bits per second, divided by 400
+
+Param[3]
+
+
+Mux bitrate in bits per second, divided by 400. May be 0 (default).
+
+Param[4]
+
+
+Rate Control VBR Padding
+
+Param[5]
+
+
+VBV Buffer used by encoder
+
+.. note::
+
+   #) Param\[3\] and Param\[4\] seem to be always 0
+   #) Param\[5\] doesn't seem to be used.
+
+
+
+CX2341X_ENC_SET_GOP_PROPERTIES
+~~
+
+Enum: 151/0x97
+
+Description
+^^^
+
+Setup the GOP structure
+
+Param[0]
+
+
+GOP size (maximum is 34)
+
+Param[1]
+
+
+Number of B frames between the I and P frame, plus 1.
+For example: IBBPBBPBBPBB --> GOP size: 12, number of B frames: 2+1 = 3
+
+.. note::
+
+   GOP size must be a multiple of (B-frames + 1).
+
+
+
+CX2341X_ENC_SET_ASPECT_RATIO
+
+
+Enum: 153/0x99
+
+Description
+^^^
+
+Sets the encoding aspect ratio. Changes in the aspect ratio take effect
+at the start of the next GOP.
+
+Param[0]
+
+
+- '' forbidden
+- '0001' 1:1 square
+- '0010' 4:3
+- '0011' 16:9
+- '0100' 2.21:1
+- '0101' to '' reserved
+
+
+
+CX2341X_ENC_SET_DNR_FILTER_MODE
+~~~
+
+Enum: 155/0x9B
+
+Description
+^^^
+
+Assign Dynamic Noise Reduction operating mode
+
+Param[0]
+
+
+Bit0: Spatial filter, set=auto, clear=manual
+Bit1: Temporal filter, set=auto, clear=manual
+
+Param[1]
+
+
+Median filter:
+
+- 0=Disabled
+- 1=Horizontal
+- 2=Vertical
+- 

[PATCH 08/18] [media] cx2341x.rst: add contents of fw-dma.txt

[Mauro Carvalho Chehab]

Add the contents of fw-dma.txt, converted to ReST, and
drop the old file.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx2341x.rst  | 99 
 Documentation/video4linux/cx2341x/fw-dma.txt | 96 ---
 2 files changed, 99 insertions(+), 96 deletions(-)
 delete mode 100644 Documentation/video4linux/cx2341x/fw-dma.txt

diff --git a/Documentation/media/v4l-drivers/cx2341x.rst 
b/Documentation/media/v4l-drivers/cx2341x.rst
index cbfa14eccd76..ca2f15c5b8f7 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -2703,3 +2703,102 @@ out what values are bad when it hangs.
 


 
+The cx231xx DMA engine
+--
+
+
+This page describes the structures and procedures used by the cx2341x DMA
+engine.
+
+Introduction
+
+
+The cx2341x PCI interface is busmaster capable. This means it has a DMA
+engine to efficiently transfer large volumes of data between the card and main
+memory without requiring help from a CPU. Like most hardware, it must operate
+on contiguous physical memory. This is difficult to come by in large quantities
+on virtual memory machines.
+
+Therefore, it also supports a technique called "scatter-gather". The card can
+transfer multiple buffers in one operation. Instead of allocating one large
+contiguous buffer, the driver can allocate several smaller buffers.
+
+In practice, I've seen the average transfer to be roughly 80K, but transfers
+above 128K were not uncommon, particularly at startup. The 128K figure is
+important, because that is the largest block that the kernel can normally
+allocate. Even still, 128K blocks are hard to come by, so the driver writer is
+urged to choose a smaller block size and learn the scatter-gather technique.
+
+Mailbox #10 is reserved for DMA transfer information.
+
+Note: the hardware expects little-endian data ('intel format').
+
+Flow
+
+
+This section describes, in general, the order of events when handling DMA
+transfers. Detailed information follows this section.
+
+- The card raises the Encoder interrupt.
+- The driver reads the transfer type, offset and size from Mailbox #10.
+- The driver constructs the scatter-gather array from enough free dma buffers
+  to cover the size.
+- The driver schedules the DMA transfer via the ScheduleDMAtoHost API call.
+- The card raises the DMA Complete interrupt.
+- The driver checks the DMA status register for any errors.
+- The driver post-processes the newly transferred buffers.
+
+NOTE! It is possible that the Encoder and DMA Complete interrupts get raised
+simultaneously. (End of the last, start of the next, etc.)
+
+Mailbox #10
+~~~
+
+The Flags, Command, Return Value and Timeout fields are ignored.
+
+- Name:   Mailbox #10
+- Results[0]: Type: 0: MPEG.
+- Results[1]: Offset: The position relative to the card's memory space.
+- Results[2]: Size: The exact number of bytes to transfer.
+
+My speculation is that since the StartCapture API has a capture type of "RAW"
+available, that the type field will have other values that correspond to YUV
+and PCM data.
+
+Scatter-Gather Array
+
+
+The scatter-gather array is a contiguously allocated block of memory that
+tells the card the source and destination of each data-block to transfer.
+Card "addresses" are derived from the offset supplied by Mailbox #10. Host
+addresses are the physical memory location of the target DMA buffer.
+
+Each S-G array element is a struct of three 32-bit words. The first word is
+the source address, the second is the destination address. Both take up the
+entire 32 bits. The lowest 18 bits of the third word is the transfer byte
+count. The high-bit of the third word is the "last" flag. The last-flag tells
+the card to raise the DMA_DONE interrupt. From hard personal experience, if
+you forget to set this bit, the card will still "work" but the stream will
+most likely get corrupted.
+
+The transfer count must be a multiple of 256. Therefore, the driver will need
+to track how much data in the target buffer is valid and deal with it
+accordingly.
+
+Array Element:
+
+- 32-bit Source Address
+- 32-bit Destination Address
+- 14-bit reserved (high bit is the last flag)
+- 18-bit byte count
+
+DMA Transfer Status
+~~~
+
+Register 0x0004 holds the DMA Transfer Status:
+
+- bit 0:   read completed
+- bit 1:   write completed
+- bit 2:   DMA read error
+- bit 3:   DMA write error
+- bit 4:   Scatter-Gather array error
diff --git a/Documentation/video4linux/cx2341x/fw-dma.txt 
b/Documentation/video4linux/cx2341x/fw-dma.txt
deleted file mode 100644
index be52b6fd1e9a..
--- a/Documentation/video4linux/cx2341x/fw-dma.txt
+++ /dev/null
@@ -1,96 +0,0 @@
-This page describes the structures and procedures used by the cx2341x DMA

[PATCH 16/18] [media] get rid of Documentation/video4linux/lifeview.txt

[Mauro Carvalho Chehab]

Move the contents of this file to bttv.rst and saa7134.rst.

With that, we can finally remove Documentation/video4linux.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/bttv.rst|  8 ++
 Documentation/media/v4l-drivers/saa7134.rst | 36 +
 Documentation/video4linux/lifeview.txt  | 42 -
 3 files changed, 44 insertions(+), 42 deletions(-)
 delete mode 100644 Documentation/video4linux/lifeview.txt

diff --git a/Documentation/media/v4l-drivers/bttv.rst 
b/Documentation/media/v4l-drivers/bttv.rst
index 611e8d529f16..f78c135b40e7 100644
--- a/Documentation/media/v4l-drivers/bttv.rst
+++ b/Documentation/media/v4l-drivers/bttv.rst
@@ -782,6 +782,14 @@ FlyVideo A2 (Elta 8680)= LR90 Rev.F (w/Remote, w/o FM, 
stereo TV by tda9821) {Ge
 
 Lifeview 3000 (Elta 8681) as sold by Plus(April 2002), Germany = LR138 w/ 
saa7134
 
+lifeview config coding on gpio pins 0-9
+^^^
+
+- LR50 rev. Q ("PARTS: 7031505116), Tuner wurde als Nr. 5 erkannt, Eing??nge
+  SVideo, TV, Composite, Audio, Remote:
+
+ - CP9..1=11001 (1: 0-Ohm-Widerstand gegen GND unbest??ckt; 0: best??ckt)
+
 
 Typhoon TV card series:
 ~~~
diff --git a/Documentation/media/v4l-drivers/saa7134.rst 
b/Documentation/media/v4l-drivers/saa7134.rst
index 584caf8a3594..36b2ee9e0fdc 100644
--- a/Documentation/media/v4l-drivers/saa7134.rst
+++ b/Documentation/media/v4l-drivers/saa7134.rst
@@ -70,6 +70,42 @@ Some details about 30/34/35:
 - saa7133/35 - saa7135 is probably a marketing decision, since all those
   chips identifies itself as 33 on pci.
 
+LifeView GPIOs
+--
+
+This section was authored by: Peter Missel 
+
+- LifeView FlyTV Platinum FM (LR214WF)
+
+- GP27MDT2005 PB4 pin 10
+- GP26MDT2005 PB3 pin 9
+- GP25MDT2005 PB2 pin 8
+- GP23MDT2005 PB1 pin 7
+- GP22MDT2005 PB0 pin 6
+- GP21MDT2005 PB5 pin 11
+- GP20MDT2005 PB6 pin 12
+- GP19MDT2005 PB7 pin 13
+- nc  MDT2005 PA3 pin 2
+- Remote  MDT2005 PA2 pin 1
+- GP18MDT2005 PA1 pin 18
+- nc  MDT2005 PA0 pin 17 strap low
+- GP17Strap "GP7"=High
+- GP16Strap "GP6"=High
+
+   - 0=Radio 1=TV
+   - Drives SA630D ENCH1 and HEF4052 A1 pinsto do FM radio through
+ SIF input
+
+- GP15nc
+- GP14nc
+- GP13nc
+- GP12Strap "GP5" = High
+- GP11Strap "GP4" = High
+- GP10Strap "GP3" = High
+- GP09Strap "GP2" = Low
+- GP08Strap "GP1" = Low
+- GP07.00 nc
+
 Credits
 ---
 
diff --git a/Documentation/video4linux/lifeview.txt 
b/Documentation/video4linux/lifeview.txt
deleted file mode 100644
index 05f9eb57aac9..
--- a/Documentation/video4linux/lifeview.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-collecting data about the lifeview models and the config coding on
-gpio pins 0-9 ...
-==
-
-bt878:
- LR50 rev. Q ("PARTS: 7031505116), Tuner wurde als Nr. 5 erkannt, Eing??nge
- SVideo, TV, Composite, Audio, Remote. CP9..1=11001 (1: 0-Ohm-Widerstand
- gegen GND unbest??ckt; 0: best??ckt)
-
---
-
-saa7134:
-   /* LifeView FlyTV Platinum FM (LR214WF) */
-   /* "Peter Missel  */
-   .name   = "LifeView FlyTV Platinum FM",
-   /*  GP27MDT2005 PB4 pin 10 */
-   /*  GP26MDT2005 PB3 pin 9 */
-   /*  GP25MDT2005 PB2 pin 8 */
-   /*  GP23MDT2005 PB1 pin 7 */
-   /*  GP22MDT2005 PB0 pin 6 */
-   /*  GP21MDT2005 PB5 pin 11 */
-   /*  GP20MDT2005 PB6 pin 12 */
-   /*  GP19MDT2005 PB7 pin 13 */
-   /*  nc  MDT2005 PA3 pin 2 */
-   /*  Remote  MDT2005 PA2 pin 1 */
-   /*  GP18MDT2005 PA1 pin 18 */
-   /*  nc  MDT2005 PA0 pin 17 strap low */
-
-   /*  GP17Strap "GP7"=High */
-   /*  GP16Strap "GP6"=High
-   0=Radio 1=TV
-   Drives SA630D ENCH1 and HEF4052 A1 pins
-   to do FM radio through SIF input */
-   /*  GP15nc */
-   /*  GP14nc */
-   /*  GP13nc */
-   /*  GP12Strap "GP5" = High */
-   /*  GP11Strap "GP4" = High */
-   /*  GP10Strap "GP3" = High */
-   /*  GP09Strap "GP2" = Low */
-   /*  GP08Strap "GP1" = Low */
-   /*  GP07.00 nc */
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe 

[PATCH 05/18] [media] cx2341x.rst: add fw-decoder-registers.txt content

[Mauro Carvalho Chehab]

Convert the contents of fw-decoder-registers.txt to ReST and
add it to cx2341x.rst file.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx2341x.rst| 1003 ++--
 .../video4linux/cx2341x/fw-decoder-regs.txt|  817 
 2 files changed, 914 insertions(+), 906 deletions(-)
 delete mode 100644 Documentation/video4linux/cx2341x/fw-decoder-regs.txt

diff --git a/Documentation/media/v4l-drivers/cx2341x.rst 
b/Documentation/media/v4l-drivers/cx2341x.rst
index 6f4ac07f52cd..f1c2d8d5978d 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -9,12 +9,12 @@ Decoder firmware API description
 
 
 CX2341X_DEC_PING_FW

+~~~
 
 Enum: 0/0x00
 
 Description
-~~~
+^^^
 
 This API call does nothing. It may be used to check if the firmware
 is responding.
@@ -22,22 +22,22 @@ is responding.
 
 
 CX2341X_DEC_START_PLAYBACK
---
+~~
 
 Enum: 1/0x01
 
 Description
-~~~
+^^^
 
 Begin or resume playback.
 
 Param[0]
-
+
 
 0 based frame number in GOP to begin playback from.
 
 Param[1]
-
+
 
 Specifies the number of muted audio frames to play before normal
 audio resumes. (This is not implemented in the firmware, leave at 0)
@@ -45,18 +45,18 @@ audio resumes. (This is not implemented in the firmware, 
leave at 0)
 
 
 CX2341X_DEC_STOP_PLAYBACK
--
+~
 
 Enum: 2/0x02
 
 Description
-~~~
+^^^
 
 Ends playback and clears all decoder buffers. If PTS is not zero,
 playback stops at specified PTS.
 
 Param[0]
-
+
 
 Display 0=last frame, 1=black
 
@@ -68,24 +68,24 @@ Display 0=last frame, 1=black
to set the screen to black.
 
 Param[1]
-
+
 
 PTS low
 
 Param[2]
-
+
 
 PTS high
 
 
 
 CX2341X_DEC_SET_PLAYBACK_SPEED
---
+~~
 
 Enum: 3/0x03
 
 Description
-~~~
+^^^
 
 Playback stream at speed other than normal. There are two modes of
 operation:
@@ -96,7 +96,7 @@ operation:
  desired speed.
 
 Param[0]
-
+
 
 .. code-block:: none
 
@@ -118,7 +118,7 @@ Param[0]
faster playback. Instead the host should start dropping frames.
 
 Param[1]
-
+
 
 Direction: 0=forward, 1=reverse
 
@@ -128,7 +128,7 @@ Direction: 0=forward, 1=reverse
reverse order.
 
 Param[2]
-
+
 
 .. code-block:: none
 
@@ -138,7 +138,7 @@ Param[2]
7=I, P, B frames
 
 Param[3]
-
+
 
 B frames per GOP (for reverse play only)
 
@@ -149,17 +149,17 @@ B frames per GOP (for reverse play only)
has to be set to the correct value in order to keep the timing correct.
 
 Param[4]
-
+
 
 Mute audio: 0=disable, 1=enable
 
 Param[5]
-
+
 
 Display 0=frame, 1=field
 
 Param[6]
-
+
 
 Specifies the number of muted audio frames to play before normal audio
 resumes. (Not implemented in the firmware, leave at 0)
@@ -167,35 +167,35 @@ resumes. (Not implemented in the firmware, leave at 0)
 
 
 CX2341X_DEC_STEP_VIDEO
---
+~~
 
 Enum: 5/0x05
 
 Description
-~~~
+^^^
 
 Each call to this API steps the playback to the next unit defined below
 in the current playback direction.
 
 Param[0]
-
+
 
 0=frame, 1=top field, 2=bottom field
 
 
 
 CX2341X_DEC_SET_DMA_BLOCK_SIZE
---
+~~
 
 Enum: 8/0x08
 
 Description
-~~~
+^^^
 
 Set DMA transfer block size. Counterpart to API 0xC9
 
 Param[0]
-
+
 
 DMA transfer block size in bytes. A different size may be specified
 when issuing the DMA transfer command.
@@ -203,114 +203,114 @@ when issuing the DMA transfer command.
 
 
 CX2341X_DEC_GET_XFER_INFO
--
+~
 
 Enum: 9/0x09
 
 Description
-~~~
+^^^
 
 This API call may be used to detect an end of stream condition.
 
 Result[0]
-~
+^
 
 Stream type
 
 Result[1]
-~
+^
 
 Address offset
 
 Result[2]
-~
+^
 
 Maximum bytes to transfer
 
 Result[3]
-~
+^
 
 Buffer fullness
 
 
 
 CX2341X_DEC_GET_DMA_STATUS
---
+~~
 
 Enum: 10/0x0A
 
 Description
-~~~
+^^^
 
 Status of the last DMA transfer
 
 Result[0]
-~
+^
 
 Bit 1 set means transfer complete
 Bit 2 set means DMA error
 Bit 3 set means linked list error
 
 Result[1]
-~
+^
 
 DMA type: 0=MPEG, 1=OSD, 2=YUV
 
 
 
 CX2341X_DEC_SCHED_DMA_FROM_HOST

+~~~
 
 Enum: 11/0x0B
 
 Description
-~~~

[PATCH 02/18] [media] doc-rst: add documentation for bttv driver

[Mauro Carvalho Chehab]

Convert it to ReST and add it to media/v4l-drivers book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/bttv.rst  | 156 ++
 Documentation/media/v4l-drivers/index.rst |   1 +
 2 files changed, 96 insertions(+), 61 deletions(-)

diff --git a/Documentation/media/v4l-drivers/bttv.rst 
b/Documentation/media/v4l-drivers/bttv.rst
index d7d956835e38..611e8d529f16 100644
--- a/Documentation/media/v4l-drivers/bttv.rst
+++ b/Documentation/media/v4l-drivers/bttv.rst
@@ -1,11 +1,13 @@
 The bttv driver
 ===
 
-
 Release notes for bttv
 --
 
 You'll need at least these config options for bttv:
+
+.. code-block:: none
+
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_VIDEO_DEV=m
@@ -26,6 +28,9 @@ cards is in CARDLIST.bttv
 
 If bttv takes very long to load (happens sometimes with the cheap
 cards which have no tuner), try adding this to your modules.conf:
+
+.. code-block:: none
+
options i2c-algo-bit bit_test=1
 
 For the WinTV/PVR you need one firmware file from the driver CD:
@@ -44,10 +49,12 @@ Autodetecting cards
 bttv uses the PCI Subsystem ID to autodetect the card type.  lspci lists
 the Subsystem ID in the second line, looks like this:
 
-00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
-   Subsystem: Hauppauge computer works Inc. WinTV/GO
-   Flags: bus master, medium devsel, latency 32, IRQ 5
-   Memory at e200 (32-bit, prefetchable) [size=4K]
+.. code-block:: none
+
+   00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 
02)
+   Subsystem: Hauppauge computer works Inc. WinTV/GO
+   Flags: bus master, medium devsel, latency 32, IRQ 5
+   Memory at e200 (32-bit, prefetchable) [size=4K]
 
 only bt878-based cards can have a subsystem ID (which does not mean
 that every card really has one).  bt848 cards can't have a Subsystem
@@ -66,7 +73,7 @@ If you have some knowledge and spare time, please try to fix 
this
 yourself (patches very welcome of course...)  You know: The linux
 slogan is "Do it yourself".
 
-There is a mailing list: linux-media@vger.kernel.org
+There is a mailing list at
 http://vger.kernel.org/vger-lists.html#linux-media
 
 If you have trouble with some specific TV card, try to ask there
@@ -91,7 +98,7 @@ This list tends to be outdated because it is updated manually 
...
 
 bttv.o
 
-::
+.. code-block:: none
 
the bt848/878 (grabber chip) driver
 
@@ -159,7 +166,7 @@ bttv.o
 
 tuner.o
 
-::
+.. code-block:: none
 
The tuner driver.  You need this unless you want to use only
with a camera or external tuner ...
@@ -173,7 +180,7 @@ tuner.o
 
 tvaudio.o
 
-::
+.. code-block:: none
 
new, experimental module which is supported to provide a single
driver for all simple i2c audio control chips (tda/tea*).
@@ -224,8 +231,7 @@ tvaudio.o
 
 msp3400.o
 
-::
-
+.. code-block:: none
 
The driver for the msp34xx sound processor chips. If you have a
stereo card, you probably want to insmod this one.
@@ -246,7 +252,7 @@ msp3400.o
 
 tea6300.o - OBSOLETE (use tvaudio instead)
 
-::
+.. code-block:: none
 
The driver for the tea6300 fader chip.  If you have a stereo
card and the msp3400.o doesn't work, you might want to try this
@@ -258,7 +264,7 @@ tea6300.o - OBSOLETE (use tvaudio instead)
 
 tda8425.o - OBSOLETE (use tvaudio instead)
 
-::
+.. code-block:: none
 
The driver for the tda8425 fader chip.  This driver used to be
part of bttv.c, so if your sound used to work but does not
@@ -269,7 +275,7 @@ tda8425.o - OBSOLETE (use tvaudio instead)
 
 tda985x.o - OBSOLETE (use tvaudio instead)
 
-::
+.. code-block:: none
 
The driver for the tda9850/55 audio chips.
 
@@ -444,6 +450,8 @@ Sound will work only, if the correct entry is used (for 
video it often
 makes no difference).  The bttv driver prints a line to the kernel
 log, telling which card type is used.  Like this one:
 
+.. code-block:: none
+
bttv0: model: BT848(Hauppauge old) [autodetected]
 
 You should verify this is correct.  If it isn't, you have to pass the
@@ -489,19 +497,21 @@ As mentioned above, there is a array which holds the 
required
 information for each known board.  You basically have to create a new
 line for your board.  The important fields are these two:
 
-struct tvcard
-{
-   [ ... ]
-   u32 gpiomask;
-   u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, stereo */
-};
+.. code-block:: c
+
+   struct tvcard
+   {
+   [ ... ]
+   u32 gpiomask;
+   u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, 
stereo */
+   };
 
 gpiomask specifies which pins are used to control the audio mux chip.
 The corresponding bits in the output enable register
 (BT848_GPIO_OUT_EN) will be set as these pins must be driven by the
 bt848 

[PATCH 04/18] [media] doc-rst: start adding documentation for cx2341x

[Mauro Carvalho Chehab]

move the contents of fw-decoder-api.txt to cx2341x and
convert it to ReST file, adding it to media/v4l-drivers

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/v4l-drivers/cx2341x.rst| 564 +
 Documentation/media/v4l-drivers/index.rst  |   1 +
 .../video4linux/cx2341x/fw-decoder-api.txt | 297 ---
 3 files changed, 565 insertions(+), 297 deletions(-)
 create mode 100644 Documentation/media/v4l-drivers/cx2341x.rst
 delete mode 100644 Documentation/video4linux/cx2341x/fw-decoder-api.txt

diff --git a/Documentation/media/v4l-drivers/cx2341x.rst 
b/Documentation/media/v4l-drivers/cx2341x.rst
new file mode 100644
index ..6f4ac07f52cd
--- /dev/null
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -0,0 +1,564 @@
+The cx2341x driver
+==
+
+Decoder firmware API description
+
+
+.. note:: this API is part of the decoder firmware, so it's cx23415 only.
+
+
+
+CX2341X_DEC_PING_FW
+---
+
+Enum: 0/0x00
+
+Description
+~~~
+
+This API call does nothing. It may be used to check if the firmware
+is responding.
+
+
+
+CX2341X_DEC_START_PLAYBACK
+--
+
+Enum: 1/0x01
+
+Description
+~~~
+
+Begin or resume playback.
+
+Param[0]
+
+
+0 based frame number in GOP to begin playback from.
+
+Param[1]
+
+
+Specifies the number of muted audio frames to play before normal
+audio resumes. (This is not implemented in the firmware, leave at 0)
+
+
+
+CX2341X_DEC_STOP_PLAYBACK
+-
+
+Enum: 2/0x02
+
+Description
+~~~
+
+Ends playback and clears all decoder buffers. If PTS is not zero,
+playback stops at specified PTS.
+
+Param[0]
+
+
+Display 0=last frame, 1=black
+
+.. note::
+
+   this takes effect immediately, so if you want to wait for a PTS,
+   then use '0', otherwise the screen goes to black at once.
+   You can call this later (even if there is no playback) with a 1 value
+   to set the screen to black.
+
+Param[1]
+
+
+PTS low
+
+Param[2]
+
+
+PTS high
+
+
+
+CX2341X_DEC_SET_PLAYBACK_SPEED
+--
+
+Enum: 3/0x03
+
+Description
+~~~
+
+Playback stream at speed other than normal. There are two modes of
+operation:
+
+   - Smooth: host transfers entire stream and firmware drops unused
+ frames.
+   - Coarse: host drops frames based on indexing as required to achieve
+ desired speed.
+
+Param[0]
+
+
+.. code-block:: none
+
+   Bitmap:
+   0:7  0 normal
+1 fast only "1.5 times"
+n nX fast, 1/nX slow
+   30   Framedrop:
+'0' during 1.5 times play, every other B frame is dropped
+'1' during 1.5 times play, stream is unchanged (bitrate
+must not exceed 8mbps)
+   31   Speed:
+'0' slow
+'1' fast
+
+.. note::
+
+   n is limited to 2. Anything higher does not result in
+   faster playback. Instead the host should start dropping frames.
+
+Param[1]
+
+
+Direction: 0=forward, 1=reverse
+
+.. note::
+
+   to make reverse playback work you have to write full GOPs in
+   reverse order.
+
+Param[2]
+
+
+.. code-block:: none
+
+   Picture mask:
+   1=I frames
+   3=I, P frames
+   7=I, P, B frames
+
+Param[3]
+
+
+B frames per GOP (for reverse play only)
+
+.. note::
+
+   for reverse playback the Picture Mask should be set to I or I, P.
+   Adding B frames to the mask will result in corrupt video. This field
+   has to be set to the correct value in order to keep the timing correct.
+
+Param[4]
+
+
+Mute audio: 0=disable, 1=enable
+
+Param[5]
+
+
+Display 0=frame, 1=field
+
+Param[6]
+
+
+Specifies the number of muted audio frames to play before normal audio
+resumes. (Not implemented in the firmware, leave at 0)
+
+
+
+CX2341X_DEC_STEP_VIDEO
+--
+
+Enum: 5/0x05
+
+Description
+~~~
+
+Each call to this API steps the playback to the next unit defined below
+in the current playback direction.
+
+Param[0]
+
+
+0=frame, 1=top field, 2=bottom field
+
+
+
+CX2341X_DEC_SET_DMA_BLOCK_SIZE
+--
+
+Enum: 8/0x08
+
+Description
+~~~
+
+Set DMA transfer block size. Counterpart to API 0xC9
+
+Param[0]
+
+
+DMA transfer block size in bytes. A different size may be specified
+when issuing the DMA transfer command.
+
+
+
+CX2341X_DEC_GET_XFER_INFO
+-
+
+Enum: 9/0x09
+
+Description
+~~~
+
+This API call may be used to detect an end of stream condition.
+
+Result[0]
+~
+
+Stream type
+
+Result[1]
+~
+
+Address offset
+
+Result[2]
+~
+
+Maximum bytes to transfer
+
+Result[3]
+~
+
+Buffer fullness
+
+
+

[PATCH next] [media] vb2: Fix allocation size of dma_parms

[Vincent Stehlé]

When allocating memory to hold the device dma parameters in
vb2_dma_contig_set_max_seg_size(), the requested size is by mistake only
the size of a pointer. Request the correct size instead.

Fixes: 3f0339691896 ("media: vb2-dma-contig: add helper for setting dma max seg 
size")
Signed-off-by: Vincent Stehlé <vincent.ste...@laposte.net>
Cc: Marek Szyprowski <m.szyprow...@samsung.com>
Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
---


Hi,

I saw that in linux next-20160718.

Best regards,

Vincent.


 drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index b09b2c9..59fa204 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -743,7 +743,7 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
 int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size)
 {
if (!dev->dma_parms) {
-   dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL);
+   dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL);
if (!dev->dma_parms)
return -ENOMEM;
}
-- 
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/2 v2] Add GS1662 driver, a video serializer

[kbuild test robot]

Hi,

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

url:
https://github.com/0day-ci/linux/commits/Charles-Antoine-Couret/SDI-add-flag-for-SDI-formats-and-SMPTE-125M-definition/20160715-234104
base:   git://linuxtv.org/media_tree.git master
config: i386-randconfig-b0-07182210 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `get_register_timings':
>> gs1662.c:(.text+0xd48b6a): undefined reference to `v4l2_match_dv_timings'
   drivers/built-in.o: In function `gs_remove':
>> gs1662.c:(.text+0xd48c13): undefined reference to 
>> `v4l2_device_unregister_subdev'
   drivers/built-in.o: In function `gs_probe':
>> gs1662.c:(.text+0xd494fb): undefined reference to `v4l2_spi_subdev_init'

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


.config.gz
Description: Binary data

Re: DRM device memory writeback (Mali-DP)

[Rob Clark]

On Mon, Jul 18, 2016 at 11:01 AM, Daniel Vetter  wrote:
> On Mon, Jul 18, 2016 at 12:47:38PM +0200, Hans Verkuil wrote:
>> On 07/18/2016 12:29 PM, Brian Starkey wrote:
>> > OK, so let's talk about using connectors instead then :-)
>> >
>> > We can attach a generic fixed_mode property which can represent panel
>> > fitters or Mali-DP's writeback scaling, that sounds good.
>> >
>> > The DRM driver can create a new "virtual" encoder/connector pair, I
>> > guess with a new connector type specifically for memory-writeback?
>> > On this connector we allow the fb_id property to attach a framebuffer
>> > for writing into.
>> > We'd probably want an additional property to enable writeback, perhaps
>> > an enum: "disabled", "streaming", "oneshot".
>> >
>> > I think it makes sense to put the output buffer format, size etc.
>> > validation in the virtual encoder's atomic_check. It has access to
>> > both CRTC and connector state, and the encoder is supposed to
>> > represent the format/stream conversion element anyway.
>> >
>> > What I'm not so clear on is how to manage the API with userspace.
>>
>> I am not terribly enthusiastic (to say the least) if a new drm API is
>> created for video capture. That's what V4L2 is for and it comes with
>> kernel frameworks, documentation and utilities. Creating a new API will
>> not make userspace develoeprs happy.
>>
>> I know it is a pain to work with different subsystems, but reinventing
>> the wheel is a much bigger pain. For you and for the poor sods who have
>> to use yet another API to do the same thing.
>>
>> Of course this has to be hooked up to drm at the low level, and anything
>> that can be done to help out with that from the V4L2 side of things is
>> fine, but creating duplicate public APIs isn't the way IMHO.
>
> I agree for the streaming video use-case. But for compositors I do agree
> with Eric that a simple frame capture interface integrated with the drm
> atomic ioctl is what we want. At least my understanding of v4l is that
> it's not that well suited to grabbing specific (single) frames.

same here, we defn want to use v4l for the streaming case (so we can
take advantage of existing userspace support for
capture/encode/stream, etc)..  but for compositors, I think v4l would
be awkward.  Ideal case is single set of driver APIs, so driver
doesn't have to care so much about the use case, and then some drm_v4l
helpers to expose a v4l device for the streaming case.

There are some older patches floating around that implemented v4l
inside drm/msm.. which looked simple enough, although I don't think we
should need to do that in each drm driver..

BR,
-R
--
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)

[Daniel Vetter]

On Mon, Jul 18, 2016 at 12:47:38PM +0200, Hans Verkuil wrote:
> On 07/18/2016 12:29 PM, Brian Starkey wrote:
> > Hi,
> > 
> > On Fri, Jul 15, 2016 at 10:42:01AM -0700, Eric Anholt wrote:
> >> 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
> 

[PATCH 4/6] radio: zoltrix: Utilize the module_isa_driver macro

[William Breathitt Gray]

This driver does not do anything special in module init/exit. This patch
eliminates the module init/exit boilerplate code by utilizing the
module_isa_driver macro.

Signed-off-by: William Breathitt Gray 
---
 drivers/media/radio/radio-zoltrix.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/media/radio/radio-zoltrix.c 
b/drivers/media/radio/radio-zoltrix.c
index 026e88e..597da26 100644
--- a/drivers/media/radio/radio-zoltrix.c
+++ b/drivers/media/radio/radio-zoltrix.c
@@ -233,16 +233,4 @@ static struct radio_isa_driver zoltrix_driver = {
.max_volume = 15,
 };
 
-static int __init zoltrix_init(void)
-{
-   return isa_register_driver(_driver.driver, ZOLTRIX_MAX);
-}
-
-static void __exit zoltrix_exit(void)
-{
-   isa_unregister_driver(_driver.driver);
-}
-
-module_init(zoltrix_init);
-module_exit(zoltrix_exit);
-
+module_isa_driver(zoltrix_driver.driver, ZOLTRIX_MAX);
-- 
2.7.3

--
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 3/6] radio: trust: Utilize the module_isa_driver macro

[William Breathitt Gray]

This driver does not do anything special in module init/exit. This patch
eliminates the module init/exit boilerplate code by utilizing the
module_isa_driver macro.

Signed-off-by: William Breathitt Gray 
---
 drivers/media/radio/radio-trust.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/media/radio/radio-trust.c 
b/drivers/media/radio/radio-trust.c
index 26a8c60..e4bec5e 100644
--- a/drivers/media/radio/radio-trust.c
+++ b/drivers/media/radio/radio-trust.c
@@ -229,15 +229,4 @@ static struct radio_isa_driver trust_driver = {
.max_volume = 31,
 };
 
-static int __init trust_init(void)
-{
-   return isa_register_driver(_driver.driver, TRUST_MAX);
-}
-
-static void __exit trust_exit(void)
-{
-   isa_unregister_driver(_driver.driver);
-}
-
-module_init(trust_init);
-module_exit(trust_exit);
+module_isa_driver(trust_driver.driver, TRUST_MAX);
-- 
2.7.3

--
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] radio: aimslab: Utilize the module_isa_driver macro

[William Breathitt Gray]

This driver does not do anything special in module init/exit. This patch
eliminates the module init/exit boilerplate code by utilizing the
module_isa_driver macro.

Cc: Hans Verkuil 
Signed-off-by: William Breathitt Gray 
---
 drivers/media/radio/radio-aimslab.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/media/radio/radio-aimslab.c 
b/drivers/media/radio/radio-aimslab.c
index ea930879..d1566a3 100644
--- a/drivers/media/radio/radio-aimslab.c
+++ b/drivers/media/radio/radio-aimslab.c
@@ -180,15 +180,4 @@ static struct radio_isa_driver rtrack_driver = {
.max_volume = 0xff,
 };
 
-static int __init rtrack_init(void)
-{
-   return isa_register_driver(_driver.driver, RTRACK_MAX);
-}
-
-static void __exit rtrack_exit(void)
-{
-   isa_unregister_driver(_driver.driver);
-}
-
-module_init(rtrack_init);
-module_exit(rtrack_exit);
+module_isa_driver(rtrack_driver.driver, RTRACK_MAX);
-- 
2.7.3

--
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] radio: aztech: Utilize the module_isa_driver macro

[William Breathitt Gray]

This driver does not do anything special in module init/exit. This patch
eliminates the module init/exit boilerplate code by utilizing the
module_isa_driver macro.

Cc: Hans Verkuil 
Signed-off-by: William Breathitt Gray 
---
 drivers/media/radio/radio-aztech.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/media/radio/radio-aztech.c 
b/drivers/media/radio/radio-aztech.c
index 705dd6f..7b39655 100644
--- a/drivers/media/radio/radio-aztech.c
+++ b/drivers/media/radio/radio-aztech.c
@@ -147,15 +147,4 @@ static struct radio_isa_driver aztech_driver = {
.max_volume = 3,
 };
 
-static int __init aztech_init(void)
-{
-   return isa_register_driver(_driver.driver, AZTECH_MAX);
-}
-
-static void __exit aztech_exit(void)
-{
-   isa_unregister_driver(_driver.driver);
-}
-
-module_init(aztech_init);
-module_exit(aztech_exit);
+module_isa_driver(aztech_driver.driver, AZTECH_MAX);
-- 
2.7.3

--
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/6] radio: rtrack2: Utilize the module_isa_driver macro

[William Breathitt Gray]

This driver does not do anything special in module init/exit. This patch
eliminates the module init/exit boilerplate code by utilizing the
module_isa_driver macro.

Signed-off-by: William Breathitt Gray 
---
 drivers/media/radio/radio-rtrack2.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/media/radio/radio-rtrack2.c 
b/drivers/media/radio/radio-rtrack2.c
index 09cfbc3..82b8794 100644
--- a/drivers/media/radio/radio-rtrack2.c
+++ b/drivers/media/radio/radio-rtrack2.c
@@ -127,15 +127,4 @@ static struct radio_isa_driver rtrack2_driver = {
.has_stereo = true,
 };
 
-static int __init rtrack2_init(void)
-{
-   return isa_register_driver(_driver.driver, RTRACK2_MAX);
-}
-
-static void __exit rtrack2_exit(void)
-{
-   isa_unregister_driver(_driver.driver);
-}
-
-module_init(rtrack2_init);
-module_exit(rtrack2_exit);
+module_isa_driver(rtrack2_driver.driver, RTRACK2_MAX);
-- 
2.7.3

--
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] radio: terratec: Utilize the module_isa_driver macro

[William Breathitt Gray]

This driver does not do anything special in module init/exit. This patch
eliminates the module init/exit boilerplate code by utilizing the
module_isa_driver macro.

Signed-off-by: William Breathitt Gray 
---
 drivers/media/radio/radio-terratec.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/media/radio/radio-terratec.c 
b/drivers/media/radio/radio-terratec.c
index be10a80..621bbb2 100644
--- a/drivers/media/radio/radio-terratec.c
+++ b/drivers/media/radio/radio-terratec.c
@@ -155,16 +155,4 @@ static struct radio_isa_driver terratec_driver = {
.max_volume = 10,
 };
 
-static int __init terratec_init(void)
-{
-   return isa_register_driver(_driver.driver, 1);
-}
-
-static void __exit terratec_exit(void)
-{
-   isa_unregister_driver(_driver.driver);
-}
-
-module_init(terratec_init);
-module_exit(terratec_exit);
-
+module_isa_driver(terratec_driver.driver, 1);
-- 
2.7.3

--
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] radio: Utilize the module_isa_driver macro

[William Breathitt Gray]

The module_isa_driver macro is a helper macro for ISA drivers which do
not do anything special in module init/exit. This patchset eliminates a
lot of ISA driver registration boilerplate code by utilizing
module_isa_driver, which replaces module_init and module_exit.

William Breathitt Gray (6):
  radio: terratec: Utilize the module_isa_driver macro
  radio: rtrack2: Utilize the module_isa_driver macro
  radio: trust: Utilize the module_isa_driver macro
  radio: zoltrix: Utilize the module_isa_driver macro
  radio: aztech: Utilize the module_isa_driver macro
  radio: aimslab: Utilize the module_isa_driver macro

 drivers/media/radio/radio-aimslab.c  | 13 +
 drivers/media/radio/radio-aztech.c   | 13 +
 drivers/media/radio/radio-rtrack2.c  | 13 +
 drivers/media/radio/radio-terratec.c | 14 +-
 drivers/media/radio/radio-trust.c| 13 +
 drivers/media/radio/radio-zoltrix.c  | 14 +-
 6 files changed, 6 insertions(+), 74 deletions(-)

-- 
2.7.3

--
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 v4 09/12] [media] vivid: Local optimization

[Philipp Zabel]

Hi Ricardo,

Am Montag, den 18.07.2016, 15:21 +0200 schrieb Ricardo Ribalda Delgado:
> Hi Philipp
> 
> On Mon, Jul 18, 2016 at 3:13 PM, Philipp Zabel  wrote:
> > Since the constant expressions are evaluated at compile time, you are
> > not actually removing shifts. The code generated for precalculate_color
> > by gcc 5.4 even grows by one asr instruction with this patch.
> >
> 
> I dont think that I follow you completely here. The original code was

Sorry, I forgot to mention I compiled both versions for ARMv7-A, saw
that object size increased, had a look the diff between objdump -d
outputs and noticed an additional shift instruction. I have not checked
this for x86_64.

> if (a)
>y= clamp(y, 16<<4, 235<<4)
> 
> y = clamp(y>>4, 1, 254)
>
> And now is
> 
> if (a)
>y= clamp(y >>4, 16, 235)
> else
> y = clamp(y, 1, 254)
 y = clamp(y >>4, 1, 254)

> On the previous case, when a was true there was 2 clamp operations.
> Now it is only one.

Yes. And now there's two shift operations (overall, still just one in
each conditional path).

It seems in my case the compiler was not clever enough to move all the
right shifts out of the conditional paths, so I ended up with one more
than before. You are right that in the limited range path the second
clamps are now avoided though. Basically, feel free to disregard my
comment.

I had the best looking result with this variant, btw:

y >>= 4;
cb >>= 4;
cr >>= 4;
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
y = clamp(y, 16, 235);
cb = clamp(cb, 16, 240);
cr = clamp(cr, 16, 240);
} else {
y = clamp(y, 1, 254);
cb = clamp(cb, 1, 254);
cr = clamp(cr, 1, 254);
}

regards
Philipp

--
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 Hans, Michael and Marek,

Thanks a lot for your feedback.

On 07/18/2016 04:34 AM, Hans Verkuil wrote:
> On 07/15/2016 06:26 PM, 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.
> 
> Does this solve anything? Once the DMA has started the behavior is the same
> as before (QBUF maps the dmabuf), only while the DMA engine hasn't started
> yet are the QBUF calls just accepted and the mapping takes place when the
> DMA is kickstarted. This makes QBUF behave inconsistently.
> 
> You don't describe here WHY this change is needed.
>

Nicolas pointed me to the TODO and suggested me the patch for the reasons
he explained in his latest email. And yes, this should had been tagged as
a RFC and just to know what you think about it. Sorry for missing that.

> I'm not sure I agree with the TODO, and even if I did, I'm not sure I agree
> with this solution. Since queuing the buffer to the driver is not the same
> as 'just before the DMA', since there may be many buffers queued up in the
> driver and you don't know in vb2 when the buffer is at the 'just before the 
> DMA'
> stage.
>

Right, I meant "as closer as possible to when the actual DMA is going to happen"
rather than "just before the DMA".

> Regards,
> 
>   Hans
> 

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] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Nicolas Dufresne]

Le lundi 18 juillet 2016 à 10:34 +0200, Hans Verkuil a écrit :
> On 07/15/2016 06:26 PM, 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.
> 
> Does this solve anything? Once the DMA has started the behavior is the same
> as before (QBUF maps the dmabuf), only while the DMA engine hasn't started
> yet are the QBUF calls just accepted and the mapping takes place when the
> DMA is kickstarted. This makes QBUF behave inconsistently.

The expected behaviour would have been to ensure that DMABuf mapping
only happen when the driver need the buffer (as late as possible). As
you describes it, the goal is not met.

> 
> You don't describe here WHY this change is needed.

It should have been explained (just like this patch should have been
marked as RFC). The is numerous reason why you don't want to spend
userspace time mapping a buffers.

First the context, mapping a DMA-Buf is a costy operation. With the
venu of DMA-Buf fences, (in implicit mode) this operation becomes even
more expensive in term of time you block userspace. By mapping in QBUF,
you do block the userspace process for a certain duration.

By delaying the mapping later, the time spent mapping is now in the
driver thread, without blocking the userspace. This allow running with
much lower latency, as the userspace can (if already available) fetch
the following buffer and put it in the queue without further delays. As
the buffers are available earlier, the streaming can be started sooner
and no time is lost.

Another reason, which was not part of our discussion, is that if you
have a display at lower framerate, it would allow appropriate frame
skipping to be implemented. Mapping all the frames, even the one that
won't be displayed would be inefficient.

So basically, what we are saying, is that the currently implemented
mechanism is a was of userspace time, reduce the benefit of using
fences and increase latency.
 
> 
> I'm not sure I agree with the TODO, and even if I did, I'm not sure I agree
> with this solution. Since queuing the buffer to the driver is not the same
> as 'just before the DMA', since there may be many buffers queued up in the
> driver and you don't know in vb2 when the buffer is at the 'just before the 
> DMA'
> stage.

Unfortunate, but it's just software ;-P An idea would be to introduce
some new state for preparing a buffers, so the driver don't endup
waiting at an unfortunate moment. Again, this is all only needed if we
can provide the same level of buffer validation we had at QBUF. As we
don't expose to userspace the information needed to validate if a DMA-
Buf is compatible, we started (not yet merged) implementing fallback at
QBuf. Failing asynchronously would leave userspace with absolutely no
way to handle the case of incompatible DMA-Buf.

Regards,
Nicolas

p.s. I'll be away for the rest of the summer, see you in September.

> 
> Regards,
> 
>   Hans
> 
> > 
> > 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 

Re: [PATCH v4 09/12] [media] vivid: Local optimization

[Ricardo Ribalda Delgado]

Hi Philipp

On Mon, Jul 18, 2016 at 3:13 PM, Philipp Zabel  wrote:
> Since the constant expressions are evaluated at compile time, you are
> not actually removing shifts. The code generated for precalculate_color
> by gcc 5.4 even grows by one asr instruction with this patch.
>

I dont think that I follow you completely here. The original code was

if (a)
   y= clamp(y, 16<<4, 235<<4)

y = clamp(y>>4, 1, 254)


And now is

if (a)
   y= clamp(y >>4, 16, 235)
else
y = clamp(y, 1, 254)


On the previous case, when a was true there was 2 clamp operations.
Now it is only one.


Best regards!

-- 
Ricardo Ribalda
--
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 v4 09/12] [media] vivid: Local optimization

[Philipp Zabel]

Hi Ricardo,

Am Montag, den 18.07.2016, 14:42 +0200 schrieb Ricardo Ribalda Delgado:
> Avoid duplicated data shifts when possible.
> 
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
> b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> index a26172575e56..7f284c591f25 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -919,13 +919,14 @@ static void precalculate_color(struct tpg_data *tpg, 
> int k)
>   color_to_ycbcr(tpg, r, g, b, , , );
>  
>   if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
> - y = clamp(y, 16 << 4, 235 << 4);
> - cb = clamp(cb, 16 << 4, 240 << 4);
> - cr = clamp(cr, 16 << 4, 240 << 4);
> + y = clamp(y >> 4, 16, 235);
> + cb = clamp(cb >> 4, 16, 240);
> + cr = clamp(cr >> 4, 16, 240);

Since the constant expressions are evaluated at compile time, you are
not actually removing shifts. The code generated for precalculate_color
by gcc 5.4 even grows by one asr instruction with this patch.

> + } else {
> + y = clamp(y >> 4, 1, 254);
> + cb = clamp(cb >> 4, 1, 254);
> + cr = clamp(cr >> 4, 1, 254);
>   }
> - y = clamp(y >> 4, 1, 254);
> - cb = clamp(cb >> 4, 1, 254);
> - cr = clamp(cr >> 4, 1, 254);
>   switch (tpg->fourcc) {
>   case V4L2_PIX_FMT_YUV444:
>   y >>= 4;

regards
Philipp

--
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] dma-buf: Release module reference on creation failure

[Sumit Semwal]

Hi Chris,

On 18 July 2016 at 17:40, Daniel Vetter  wrote:
> On Mon, Jul 18, 2016 at 12:16:22PM +0100, Chris Wilson wrote:
>> If we fail to create the anon file, we need to remember to release the
>> module reference on the owner.
>>
Thanks for the patch.

>> Signed-off-by: Chris Wilson 
>> Reviewed-by: Joonas Lahtinen 
>> Cc: Joonas Lahtinen 
>> Cc: Sumit Semwal 
>> Cc: Daniel Vetter 
>> Cc: linux-media@vger.kernel.org
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linaro-mm-...@lists.linaro.org
>> ---
>>  drivers/dma-buf/dma-buf.c | 15 +++
>>  1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 20ce0687b111..ddaee60ae52a 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -334,6 +334,7 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>   struct reservation_object *resv = exp_info->resv;
>>   struct file *file;
>>   size_t alloc_size = sizeof(struct dma_buf);
>> + int ret;
>
> Not sure this really helps readability, but meh. Will apply to drm-misc,
> with a cc: stable.
Daniel, fwiw, please feel free to add
Acked-by: Sumit Semwal 

> -Daniel

BR,
~Sumit.
>
>>
>>   if (!exp_info->resv)
>>   alloc_size += sizeof(struct reservation_object);
>> @@ -357,8 +358,8 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>
>>   dmabuf = kzalloc(alloc_size, GFP_KERNEL);
>>   if (!dmabuf) {
>> - module_put(exp_info->owner);
>> - return ERR_PTR(-ENOMEM);
>> + ret = -ENOMEM;
>> + goto err_module;
>>   }
>>
>>   dmabuf->priv = exp_info->priv;
>> @@ -379,8 +380,8 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>   file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf,
>>   exp_info->flags);
>>   if (IS_ERR(file)) {
>> - kfree(dmabuf);
>> - return ERR_CAST(file);
>> + ret = PTR_ERR(file);
>> + goto err_dmabuf;
>>   }
>>
>>   file->f_mode |= FMODE_LSEEK;
>> @@ -394,6 +395,12 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>   mutex_unlock(_list.lock);
>>
>>   return dmabuf;
>> +
>> +err_dmabuf:
>> + kfree(dmabuf);
>> +err_module:
>> + module_put(exp_info->owner);
>> + return ERR_PTR(ret);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_export);
>>
>> --
>> 2.8.1
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
--
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 v4 01/12] [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 v4 04/12] [media] vivid: Code refactor for color encoding

[Ricardo Ribalda Delgado]

Replace is_yuv with color_enc Which can be used by other
color encodings such us HSV.

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   | 49 +++
 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, 66 insertions(+), 44 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..4d0c9ab408da 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_enc = TGP_COLOR_ENC_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_enc = TGP_COLOR_ENC_YCBCR;
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_enc = TGP_COLOR_ENC_YCBCR;
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_enc = TGP_COLOR_ENC_YCBCR;
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_enc = TGP_COLOR_ENC_YCBCR;
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_enc = TGP_COLOR_ENC_YCBCR;
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_enc = TGP_COLOR_ENC_YCBCR;
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_enc = TGP_COLOR_ENC_YCBCR;
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_enc = TGP_COLOR_ENC_YCBCR;
break;
default:
return false;
@@ -777,7 +777,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
 * Remember that r, g and b are still in the 0 - 0xff0 range.
 */
if (tpg->real_rgb_range == V4L2_DV_RGB_RANGE_LIMITED &&
-   tpg->rgb_range == V4L2_DV_RGB_RANGE_FULL && !tpg->is_yuv) {
+   tpg->rgb_range == V4L2_DV_RGB_RANGE_FULL &&
+   tpg->color_enc == TGP_COLOR_ENC_RGB) {
/*
 * Convert from full range (which is what r, g and b are)
 * to limited range (which is the 'real' RGB range), which
@@ -787,7 +788,9 @@ static void precalculate_color(struct tpg_data *tpg, int k)
g = (g * 219) / 255 + (16 << 4);
b = (b * 219) / 255 + (16 << 4);
} else if (tpg->real_rgb_range != V4L2_DV_RGB_RANGE_LIMITED &&
-  tpg->rgb_range == V4L2_DV_RGB_RANGE_LIMITED && !tpg->is_yuv) 
{
+  tpg->rgb_range == V4L2_DV_RGB_RANGE_LIMITED &&
+  tpg->color_enc == TGP_COLOR_ENC_RGB) {
+
/*
 * Clamp r, g and b to the limited range and convert to full
 * range since that's what we deliver.
@@ 

[PATCH v4 00/12] 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 to ease the reviewing process.

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

We still need to decide if and how we will support HUE range 0-255


Changelog:
v4:  
Suggested by Hans Verkuil  and
- Rename YUV to YCBCR
- Fix numerical error

Suggested by Hans Verkuil  and
Laurent Pinchart 
-Implement hsv_encoding for supporting 0-255 range


v3:  
-Fix wrong handling of some YUV formats when brightness != 128

Suggested by Laurent Pinchart 
-Remove unneeded empty lines on .rst file
Thanks!

Suggested by Hans Verkuil 
-Rebase over master and docs-next
-Introduce TPG_COLOR_ENC_LUMA for gray formats
-CodeStyle
Thanks!

v2:
Suggested by Mauro Carvalho Chehab ,
-Rebase on top of docs-next (port documentation to .rst)

Ricardo Ribalda Delgado (12):
  [media] videodev2.h Add HSV formats
  [media] Documentation: Add HSV format
  [media] Documentation: Add Ricardo Ribalda
  [media] vivid: Code refactor for color encoding
  [media] vivid: Add support for HSV formats
  [media] vivid: Rename variable
  [media] vivid: Introduce TPG_COLOR_ENC_LUMA
  [media] vivid: Fix YUV555 and YUV565 handling
  [media] vivid: Local optimization
  [media] videodev2.h Add HSV encoding
  [media] Documentation: Add HSV encodings
  [media] vivid: Add support for HSV encoding

 Documentation/media/uapi/v4l/hsv-formats.rst   |  19 +
 Documentation/media/uapi/v4l/pixfmt-002.rst|  12 +-
 Documentation/media/uapi/v4l/pixfmt-003.rst|  14 +-
 Documentation/media/uapi/v4l/pixfmt-006.rst|  38 ++
 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 159 
 Documentation/media/uapi/v4l/pixfmt.rst|   1 +
 Documentation/media/uapi/v4l/v4l2.rst  |   9 +
 Documentation/media/videodev2.h.rst.exceptions |   4 +
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c  | 408 ++---
 drivers/media/platform/vivid/vivid-core.h  |   3 +-
 drivers/media/platform/vivid/vivid-ctrls.c |  25 ++
 drivers/media/platform/vivid/vivid-vid-cap.c   |  17 +-
 drivers/media/platform/vivid/vivid-vid-common.c|  68 ++--
 drivers/media/platform/vivid/vivid-vid-out.c   |   1 +
 drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
 include/media/v4l2-tpg.h   |  24 +-
 include/uapi/linux/videodev2.h |  25 +-
 17 files changed, 652 insertions(+), 177 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 v4 03/12] [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

[PATCH v4 07/12] [media] vivid: Introduce TPG_COLOR_ENC_LUMA

[Ricardo Ribalda Delgado]

Simplifies handling of Gray formats.

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

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index da77cdd4f2e5..41cc402ddeef 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -234,10 +234,12 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_XBGR32:
case V4L2_PIX_FMT_ARGB32:
case V4L2_PIX_FMT_ABGR32:
+   tpg->color_enc = TGP_COLOR_ENC_RGB;
+   break;
case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_Y16:
case V4L2_PIX_FMT_Y16_BE:
-   tpg->color_enc = TGP_COLOR_ENC_RGB;
+   tpg->color_enc = TGP_COLOR_ENC_LUMA;
break;
case V4L2_PIX_FMT_YUV444:
case V4L2_PIX_FMT_YUV555:
@@ -825,9 +827,9 @@ static void precalculate_color(struct tpg_data *tpg, int k)
g <<= 4;
b <<= 4;
}
-   if (tpg->qual == TPG_QUAL_GRAY || tpg->fourcc == V4L2_PIX_FMT_GREY ||
-   tpg->fourcc == V4L2_PIX_FMT_Y16 ||
-   tpg->fourcc == V4L2_PIX_FMT_Y16_BE) {
+
+   if (tpg->qual == TPG_QUAL_GRAY ||
+   tpg->color_enc ==  TGP_COLOR_ENC_LUMA) {
/* Rec. 709 Luma function */
/* (0.2126, 0.7152, 0.0722) * (255 * 256) */
r = g = b = (13879 * r + 46688 * g + 4713 * b) >> 16;
@@ -867,8 +869,9 @@ static void precalculate_color(struct tpg_data *tpg, int k)
b = (b - (16 << 4)) * 255 / 219;
}
 
-   if (tpg->brightness != 128 || tpg->contrast != 128 ||
-   tpg->saturation != 128 || tpg->hue) {
+   if ((tpg->brightness != 128 || tpg->contrast != 128 ||
+tpg->saturation != 128 || tpg->hue) &&
+   tpg->color_enc != TGP_COLOR_ENC_LUMA) {
/* Implement these operations */
int y, cb, cr;
int tmp_cb, tmp_cr;
@@ -894,6 +897,10 @@ static void precalculate_color(struct tpg_data *tpg, int k)
return;
}
ycbcr_to_color(tpg, y, cb, cr, , , );
+   } else if ((tpg->brightness != 128 || tpg->contrast != 128) &&
+  tpg->color_enc == TGP_COLOR_ENC_LUMA) {
+   r = (16 << 4) + ((r - (16 << 4)) * tpg->contrast) / 128;
+   r += (tpg->brightness << 4) - (128 << 4);
}
 
switch (tpg->color_enc) {
@@ -944,6 +951,11 @@ static void precalculate_color(struct tpg_data *tpg, int k)
tpg->colors[k][2] = cr;
break;
}
+   case TGP_COLOR_ENC_LUMA:
+   {
+   tpg->colors[k][0] = r >> 4;
+   break;
+   }
case TGP_COLOR_ENC_RGB:
{
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
@@ -1985,6 +1997,8 @@ static const char *tpg_color_enc_str(enum tgp_color_enc
return "HSV";
case TGP_COLOR_ENC_YCBCR:
return "Y'CbCr";
+   case TGP_COLOR_ENC_LUMA:
+   return "Luma";
case TGP_COLOR_ENC_RGB:
default:
return "R'G'B";
diff --git a/drivers/media/platform/vivid/vivid-vid-common.c 
b/drivers/media/platform/vivid/vivid-vid-common.c
index 20822b5111b3..e0df44151461 100644
--- a/drivers/media/platform/vivid/vivid-vid-common.c
+++ b/drivers/media/platform/vivid/vivid-vid-common.c
@@ -184,7 +184,7 @@ struct vivid_fmt vivid_formats[] = {
.fourcc   = V4L2_PIX_FMT_GREY,
.vdownsampling = { 1 },
.bit_depth = { 8 },
-   .color_enc = TGP_COLOR_ENC_YCBCR,
+   .color_enc = TGP_COLOR_ENC_LUMA,
.planes   = 1,
.buffers = 1,
},
@@ -192,7 +192,7 @@ struct vivid_fmt vivid_formats[] = {
.fourcc   = V4L2_PIX_FMT_Y16,
.vdownsampling = { 1 },
.bit_depth = { 16 },
-   .color_enc = TGP_COLOR_ENC_YCBCR,
+   .color_enc = TGP_COLOR_ENC_LUMA,
.planes   = 1,
.buffers = 1,
},
@@ -200,7 +200,7 @@ struct vivid_fmt vivid_formats[] = {
.fourcc   = V4L2_PIX_FMT_Y16_BE,
.vdownsampling = { 1 },
.bit_depth = { 16 },
-   .color_enc = TGP_COLOR_ENC_YCBCR,
+   .color_enc = TGP_COLOR_ENC_LUMA,
.planes   = 1,
.buffers = 1,
},
diff --git a/include/media/v4l2-tpg.h b/include/media/v4l2-tpg.h
index 4a40f9b79053..8abed92317e8 100644
--- a/include/media/v4l2-tpg.h
+++ b/include/media/v4l2-tpg.h
@@ -91,6 +91,7 @@ enum 

[PATCH v4 10/12] [media] videodev2.h Add HSV encoding

[Ricardo Ribalda Delgado]

Some hardware maps the Hue between 0 and 255 instead of 0-179. Support
this format with a new field hsv_enc.

Signed-off-by: Ricardo Ribalda Delgado 
---
 include/uapi/linux/videodev2.h | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index c7fb760386cf..49edc462ca8e 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -330,6 +330,15 @@ enum v4l2_ycbcr_encoding {
V4L2_YCBCR_ENC_SMPTE240M  = 8,
 };
 
+enum v4l2_hsv_encoding {
+
+   /* Hue mapped to 0 - 179 */
+   V4L2_HSV_ENC_180= 16,
+
+   /* Hue mapped to 0-255 */
+   V4L2_HSV_ENC_256= 17,
+};
+
 /*
  * Determine how YCBCR_ENC_DEFAULT should map to a proper Y'CbCr encoding.
  * This depends on the colorspace.
@@ -455,7 +464,12 @@ struct v4l2_pix_format {
__u32   colorspace; /* enum v4l2_colorspace */
__u32   priv;   /* private data, depends on 
pixelformat */
__u32   flags;  /* format flags 
(V4L2_PIX_FMT_FLAG_*) */
-   __u32   ycbcr_enc;  /* enum v4l2_ycbcr_encoding */
+   union {
+   /* enum v4l2_ycbcr_encoding */
+   __u32   ycbcr_enc;
+   /* enum v4l2_hsv_encoding */
+   __u32   hsv_enc;
+   };
__u32   quantization;   /* enum v4l2_quantization */
__u32   xfer_func;  /* enum v4l2_xfer_func */
 };
@@ -1988,7 +2002,10 @@ struct v4l2_pix_format_mplane {
struct v4l2_plane_pix_formatplane_fmt[VIDEO_MAX_PLANES];
__u8num_planes;
__u8flags;
-   __u8ycbcr_enc;
+union {
+   __u8ycbcr_enc;
+   __u8hsv_enc;
+   };
__u8quantization;
__u8xfer_func;
__u8reserved[7];
-- 
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 v4 05/12] [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   | 93 +++--
 drivers/media/platform/vivid/vivid-vid-common.c | 14 
 include/media/v4l2-tpg.h|  1 +
 3 files changed, 104 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 4d0c9ab408da..ec8f887a84e5 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_enc = TGP_COLOR_ENC_YCBCR;
break;
+   case V4L2_PIX_FMT_HSV24:
+   case V4L2_PIX_FMT_HSV32:
+   tpg->color_enc = TGP_COLOR_ENC_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:
@@ -490,6 +496,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;
+
+   /* Value */
+   max_rgb = max3(r, g, b);
+   *v = max_rgb;
+   if (!max_rgb) {
+   *h = 0;
+   *s = 0;
+   return;
+   }
+
+   /* Saturation */
+   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;
+   }
+
+   /* Hue */
+   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 Hue */
+   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)
 {
@@ -832,7 +896,19 @@ static void precalculate_color(struct tpg_data *tpg, int k)
ycbcr_to_color(tpg, y, cb, cr, , , );
}
 
-   if (tpg->color_enc == TGP_COLOR_ENC_YCBCR) {
+   switch (tpg->color_enc) {
+   case TGP_COLOR_ENC_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_ENC_YCBCR:
+   {
/* Convert to YCbCr */
int y, cb, cr;
 
@@ -866,7 +942,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_ENC_RGB:
+   {
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
r = (r * 219) / 255 + (16 << 4);
g = (g * 219) / 255 + (16 << 4);
@@ -916,6 +995,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;
+   }
}
 }
 
@@ -941,8 +1022,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 */
-   g_u = tpg->colors[color][1]; /* G or precalculated U */
+   r_y = tpg->colors[color][0]; /* R or precalculated Y, H */
+   g_u = tpg->colors[color][1]; /* G or precalculated U, V */
b_v = tpg->colors[color][2]; /* B or precalculated V */
 
switch 

[PATCH v4 08/12] [media] vivid: Fix YUV555 and YUV565 handling

[Ricardo Ribalda Delgado]

precalculate_color() had a optimization that avoided duplicated
conversion for YUV formats. This optimization did not take into
consideration YUV444, YUV555, YUV565 or limited range quantization.

This patch keeps the optimization, but fixes the wrong handling.

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

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 41cc402ddeef..a26172575e56 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -797,6 +797,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
int r = tpg_colors[col].r;
int g = tpg_colors[col].g;
int b = tpg_colors[col].b;
+   int y, cb, cr;
+   bool ycbcr_valid = false;
 
if (k == TPG_COLOR_TEXTBG) {
col = tpg_get_textbg_color(tpg);
@@ -873,7 +875,6 @@ static void precalculate_color(struct tpg_data *tpg, int k)
 tpg->saturation != 128 || tpg->hue) &&
tpg->color_enc != TGP_COLOR_ENC_LUMA) {
/* Implement these operations */
-   int y, cb, cr;
int tmp_cb, tmp_cr;
 
/* First convert to YCbCr */
@@ -890,13 +891,10 @@ 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->color_enc == TGP_COLOR_ENC_YCBCR) {
-   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);
-   return;
-   }
-   ycbcr_to_color(tpg, y, cb, cr, , , );
+   if (tpg->color_enc == TGP_COLOR_ENC_YCBCR)
+   ycbcr_valid = true;
+   else
+   ycbcr_to_color(tpg, y, cb, cr, , , );
} else if ((tpg->brightness != 128 || tpg->contrast != 128) &&
   tpg->color_enc == TGP_COLOR_ENC_LUMA) {
r = (16 << 4) + ((r - (16 << 4)) * tpg->contrast) / 128;
@@ -917,9 +915,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
case TGP_COLOR_ENC_YCBCR:
{
/* Convert to YCbCr */
-   int y, cb, cr;
-
-   color_to_ycbcr(tpg, r, g, b, , , );
+   if (!ycbcr_valid)
+   color_to_ycbcr(tpg, r, g, b, , , );
 
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
y = clamp(y, 16 << 4, 235 << 4);
-- 
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] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder

[Hans Verkuil]

On 07/18/2016 02:28 PM, tiffany lin wrote:
> Understood now.
> 
> Now I am trying to figure out how to make this function right.
> Our encoder only support crop range from (0, 0) to (width, height), so
> if s->r.top and s->r.left not 0, I will return -EINVAL.
> 
> 
> Another thing is that in v4l2-compliance test, it has testLegacyCrop.
> It looks like we still need to support 
>  V4L2_SEL_TGT_COMPOSE_DEFAULT:
>  V4L2_SEL_TGT_COMPOSE_BOUNDS:
>  V4L2_SEL_TGT_COMPOSE:
> to pass v4l2 compliance test, Or it will fail in 
> fail: v4l2-test-formats.cpp(1318): !doioctl(node, VIDIOC_G_SELECTION,
> )
> fail: v4l2-test-formats.cpp(1336): testLegacyCrop(node)
> test Cropping: FAIL

Against which kernel are you testing? In the current media_tree master
there is a bug in drivers/media/v4l2-core/v4l2-ioctl.c, v4l_cropcap():

This code:

if (WARN_ON(!ops->vidioc_cropcap && !ops->vidioc_cropcap))

should be:

if (WARN_ON(!ops->vidioc_cropcap && !ops->vidioc_g_selection))

The fix is waiting for a pull from Linus.

Also update to the latest v4l2-compliance: I've made some changes that
might affect this. And I added additional checks to verify if all the
colorspace-related format fields are properly propagated from the
output format to the capture format.

Regards,

Hans

> 
> I don't understand the following testing code.
> 
> /*
>  * If either CROPCAP or G_CROP works, then G_SELECTION should
>  * work as well.
>  * If neither CROPCAP nor G_CROP work, then G_SELECTION
> shouldn't
>  * work either.
>  */
> if (!doioctl(node, VIDIOC_CROPCAP, )) {
> fail_on_test(doioctl(node, VIDIOC_G_SELECTION, ));
> 
> // Checks for invalid types
> if (cap.type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> cap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> else
> cap.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> fail_on_test(doioctl(node, VIDIOC_CROPCAP, ) !=
> EINVAL);
> cap.type = 0xff;
> fail_on_test(doioctl(node, VIDIOC_CROPCAP, ) !=
> EINVAL);
> } else {
> fail_on_test(!doioctl(node, VIDIOC_G_SELECTION, ));
> -> fail here
> }
> 
> When test OUTPUT queue, it fail because v4l_cropcap will fail when
> s.target = V4L2_SEL_TGT_COMPOSE_BOUNDS.
> If VIDIOC_CROPCAP ioctl fail, VIDIOC_G_SELECTION should fail.
> But VIDIOC_G_SELECTION target on CROP not COMPOSE and it success.
> 
> 
> best regards,
> Tiffany
> 
> 
> 
>> Regards,
>>
>>  Hans
>>
>>>
>>>
>>> static int v4l_g_crop(const struct v4l2_ioctl_ops *ops,
>>> struct file *file, void *fh, void *arg)
>>> {
>>> struct v4l2_crop *p = arg;
>>> struct v4l2_selection s = {
>>> .type = p->type,
>>> };
>>> int ret;
>>>
>>> if (ops->vidioc_g_crop)
>>> return ops->vidioc_g_crop(file, fh, p);
>>> /* simulate capture crop using selection api */
>>>
>>> /* crop means compose for output devices */
>>> if (V4L2_TYPE_IS_OUTPUT(p->type))
>>> s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
>>> else
>>> s.target = V4L2_SEL_TGT_CROP_ACTIVE;
>>>
>>> ret = ops->vidioc_g_selection(file, fh, );
>>>
>>> /* copying results to old structure on success */
>>> if (!ret)
>>> p->c = s.r;
>>> return ret;
>>> }
>>>
>>> static int v4l_s_crop(const struct v4l2_ioctl_ops *ops,
>>> struct file *file, void *fh, void *arg)
>>> {
>>> struct v4l2_crop *p = arg;
>>> struct v4l2_selection s = {
>>> .type = p->type,
>>> .r = p->c,
>>> };
>>>
>>> if (ops->vidioc_s_crop)
>>> return ops->vidioc_s_crop(file, fh, p);
>>> /* simulate capture crop using selection api */
>>>
>>> /* crop means compose for output devices */
>>> if (V4L2_TYPE_IS_OUTPUT(p->type))
>>> s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
>>> else
>>> s.target = V4L2_SEL_TGT_CROP_ACTIVE;
>>>
>>> return ops->vidioc_s_selection(file, fh, );
>>> }
>>>
>>>
>>> best regards,
>>> Tiffany
>>>
>>>
>>>
>>>
 Regards,

Hans

> +
> + return 0;
> +}
> +
>  static int vidioc_venc_qbuf(struct file *file, void *priv,
>   struct v4l2_buffer *buf)
>  {
> @@ -688,6 +759,9 @@ const struct v4l2_ioctl_ops mtk_venc_ioctl_ops = {
>  
>   .vidioc_create_bufs = v4l2_m2m_ioctl_create_bufs,
>   .vidioc_prepare_buf = v4l2_m2m_ioctl_prepare_buf,
> +
> + .vidioc_g_selection = vidioc_venc_g_selection,
> + .vidioc_s_selection = vidioc_venc_s_selection,
>  };
>  
>  static int vb2ops_venc_queue_setup(struct vb2_queue *vq,
>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to 

[PATCH v4 06/12] [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 ec8f887a84e5..da77cdd4f2e5 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -1014,7 +1014,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 &&
@@ -1022,161 +1022,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 v4 02/12] [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 | 158 +
 Documentation/media/uapi/v4l/pixfmt.rst|   1 +
 Documentation/media/uapi/v4l/v4l2.rst  |   5 +
 4 files changed, 183 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 ..60ac821e309d
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
@@ -0,0 +1,158 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _packed-hsv:
+
+**
+Packed HSV formats
+**
+
+*man Packed HSV formats(2)*
+
+Packed HSV formats
+
+
+Description
+===
+
+The *hue* (h) is measured 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
--- a/Documentation/media/uapi/v4l/v4l2.rst
+++ b/Documentation/media/uapi/v4l/v4l2.rst
@@ -85,6 +85,11 @@ part can be used and distributed without restrictions.
 Revision History
 

[PATCH v4 12/12] [media] vivid: Add support for HSV encoding

[Ricardo Ribalda Delgado]

Support HSV encoding. Most of the logic is replicated from ycbcr_enc.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 25 +
 drivers/media/platform/vivid/vivid-core.h   |  1 +
 drivers/media/platform/vivid/vivid-ctrls.c  | 25 +
 drivers/media/platform/vivid/vivid-vid-cap.c| 17 +++--
 drivers/media/platform/vivid/vivid-vid-common.c |  2 ++
 drivers/media/platform/vivid/vivid-vid-out.c|  1 +
 include/media/v4l2-tpg.h| 15 +++
 7 files changed, 76 insertions(+), 10 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 7f284c591f25..2341d8ee2601 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -504,6 +504,7 @@ static void color_to_hsv(struct tpg_data *tpg, int r, int 
g, int b,
int max_rgb, min_rgb, diff_rgb;
int aux;
int third;
+   int third_size;
 
r >>= 4;
g >>= 4;
@@ -530,30 +531,36 @@ static void color_to_hsv(struct tpg_data *tpg, int r, int 
g, int b,
return;
}
 
+   third_size = (tpg->real_hsv_enc == V4L2_HSV_ENC_180) ? 60 : 85;
+
/* Hue */
if (max_rgb == r) {
aux =  g - b;
third = 0;
} else if (max_rgb == g) {
aux =  b - r;
-   third = 60;
+   third = third_size;
} else {
aux =  r - g;
-   third = 120;
+   third = third_size * 2;
}
 
-   aux *= 30;
+   aux *= third_size / 2;
aux += diff_rgb / 2;
aux /= diff_rgb;
aux += third;
 
/* Clamp Hue */
-   if (aux < 0)
-   aux += 180;
-   else if (aux > 180)
-   aux -= 180;
-   *h = aux;
+   if (tpg->real_hsv_enc == V4L2_HSV_ENC_180) {
+   if (aux < 0)
+   aux += 180;
+   else if (aux > 180)
+   aux -= 180;
+   } else {
+   aux = aux & 0xff;
+   }
 
+   *h = aux;
 }
 
 static void rgb2ycbcr(const int m[3][3], int r, int g, int b,
@@ -1927,6 +1934,7 @@ static void tpg_recalc(struct tpg_data *tpg)
tpg->recalc_lines = true;
tpg->real_xfer_func = tpg->xfer_func;
tpg->real_ycbcr_enc = tpg->ycbcr_enc;
+   tpg->real_hsv_enc = tpg->hsv_enc;
tpg->real_quantization = tpg->quantization;
 
if (tpg->xfer_func == V4L2_XFER_FUNC_DEFAULT)
@@ -2017,6 +2025,7 @@ void tpg_log_status(struct tpg_data *tpg)
pr_info("tpg colorspace: %d\n", tpg->colorspace);
pr_info("tpg transfer function: %d/%d\n", tpg->xfer_func, 
tpg->real_xfer_func);
pr_info("tpg Y'CbCr encoding: %d/%d\n", tpg->ycbcr_enc, 
tpg->real_ycbcr_enc);
+   pr_info("tpg HSV encoding: %d/%d\n", tpg->hsv_enc, tpg->real_hsv_enc);
pr_info("tpg quantization: %d/%d\n", tpg->quantization, 
tpg->real_quantization);
pr_info("tpg RGB range: %d/%d\n", tpg->rgb_range, tpg->real_rgb_range);
 }
diff --git a/drivers/media/platform/vivid/vivid-core.h 
b/drivers/media/platform/vivid/vivid-core.h
index b59b49456d45..5cdf95bdc4d1 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -346,6 +346,7 @@ struct vivid_dev {
struct v4l2_dv_timings  dv_timings_out;
u32 colorspace_out;
u32 ycbcr_enc_out;
+   u32 hsv_enc_out;
u32 quantization_out;
u32 xfer_func_out;
u32 service_set_out;
diff --git a/drivers/media/platform/vivid/vivid-ctrls.c 
b/drivers/media/platform/vivid/vivid-ctrls.c
index b98089c95ef5..2e1c0b6d6842 100644
--- a/drivers/media/platform/vivid/vivid-ctrls.c
+++ b/drivers/media/platform/vivid/vivid-ctrls.c
@@ -79,6 +79,7 @@
 #define VIVID_CID_MAX_EDID_BLOCKS  (VIVID_CID_VIVID_BASE + 40)
 #define VIVID_CID_PERCENTAGE_FILL  (VIVID_CID_VIVID_BASE + 41)
 #define VIVID_CID_REDUCED_FPS  (VIVID_CID_VIVID_BASE + 42)
+#define VIVID_CID_HSV_ENC  (VIVID_CID_VIVID_BASE + 43)
 
 #define VIVID_CID_STD_SIGNAL_MODE  (VIVID_CID_VIVID_BASE + 60)
 #define VIVID_CID_STANDARD (VIVID_CID_VIVID_BASE + 61)
@@ -378,6 +379,14 @@ static int vivid_vid_cap_s_ctrl(struct v4l2_ctrl *ctrl)
vivid_send_source_change(dev, HDMI);
vivid_send_source_change(dev, WEBCAM);
break;
+   case VIVID_CID_HSV_ENC:
+   tpg_s_hsv_enc(>tpg, ctrl->val ? V4L2_HSV_ENC_256 :
+V4L2_HSV_ENC_180);
+   

[PATCH v4 11/12] [media] Documentation: Add HSV encodings

[Ricardo Ribalda Delgado]

Describe the hsv_enc field and its use.

Signed-off-by: Ricardo Ribalda Delgado 
---
 Documentation/media/uapi/v4l/pixfmt-002.rst| 12 ++-
 Documentation/media/uapi/v4l/pixfmt-003.rst| 14 ++--
 Documentation/media/uapi/v4l/pixfmt-006.rst| 38 ++
 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst |  3 +-
 Documentation/media/videodev2.h.rst.exceptions |  4 +++
 5 files changed, 67 insertions(+), 4 deletions(-)

diff --git a/Documentation/media/uapi/v4l/pixfmt-002.rst 
b/Documentation/media/uapi/v4l/pixfmt-002.rst
index fae9b2d40a85..9a59e87b590f 100644
--- a/Documentation/media/uapi/v4l/pixfmt-002.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-002.rst
@@ -177,6 +177,16 @@ Single-planar format structure
 
 -  .. row 13
 
+   -  enum :ref:`v4l2_hsv_encoding `
+
+   -  ``hsv_enc``
+
+   -  This information supplements the ``colorspace`` and must be set by
+ the driver for capture streams and by the application for output
+ streams, see :ref:`colorspaces`.
+
+-  .. row 14
+
-  enum :ref:`v4l2_quantization `
 
-  ``quantization``
@@ -185,7 +195,7 @@ Single-planar format structure
  the driver for capture streams and by the application for output
  streams, see :ref:`colorspaces`.
 
--  .. row 14
+-  .. row 15
 
-  enum :ref:`v4l2_xfer_func `
 
diff --git a/Documentation/media/uapi/v4l/pixfmt-003.rst 
b/Documentation/media/uapi/v4l/pixfmt-003.rst
index 25c54872fbe1..f212d1feaaa0 100644
--- a/Documentation/media/uapi/v4l/pixfmt-003.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-003.rst
@@ -138,6 +138,16 @@ describing all planes of that format.
 
 -  .. row 10
 
+   -  enum :ref:`v4l2_hsv_encoding `
+
+   -  ``hsv_enc``
+
+   -  This information supplements the ``colorspace`` and must be set by
+ the driver for capture streams and by the application for output
+ streams, see :ref:`colorspaces`.
+
+-  .. row 11
+
-  enum :ref:`v4l2_quantization `
 
-  ``quantization``
@@ -146,7 +156,7 @@ describing all planes of that format.
  the driver for capture streams and by the application for output
  streams, see :ref:`colorspaces`.
 
--  .. row 11
+-  .. row 12
 
-  enum :ref:`v4l2_xfer_func `
 
@@ -156,7 +166,7 @@ describing all planes of that format.
  the driver for capture streams and by the application for output
  streams, see :ref:`colorspaces`.
 
--  .. row 12
+-  .. row 13
 
-  __u8
 
diff --git a/Documentation/media/uapi/v4l/pixfmt-006.rst 
b/Documentation/media/uapi/v4l/pixfmt-006.rst
index 987b9a8a9eb4..ef7518077e8a 100644
--- a/Documentation/media/uapi/v4l/pixfmt-006.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-006.rst
@@ -19,6 +19,15 @@ colorspace field of struct :ref:`v4l2_pix_format 
`
 or struct :ref:`v4l2_pix_format_mplane `
 needs to be filled in.
 
+.. _hsv-colorspace:
+
+On :ref:`HSV formats ` the *Hue* is defined as the angle on
+the cylindrical color representation. Usually this angle is measured in
+degrees, i.e. 0-360. When we map this angle value into 8 bits, there are
+two basic ways to do it: Divide the angular value by 2 (0-179), or use the
+whole range, 0-255, dividing the angular value by 1.41. The
+`v4l2_hsv_encoding ` field specify which encoding is used.
+
 .. note:: The default R'G'B' quantization is full range for all
colorspaces except for BT.2020 which uses limited range R'G'B'
quantization.
@@ -286,3 +295,32 @@ needs to be filled in.
-  Use the limited range quantization encoding. I.e. the range [0…1]
  is mapped to [16…235]. Cb and Cr are mapped from [-0.5…0.5] to
  [16…240].
+
+
+
+.. _v4l2-hsv-encoding:
+
+.. flat-table:: V4L2 HSV Encodings
+:header-rows:  1
+:stub-columns: 0
+
+
+-  .. row 1
+
+   -  Identifier
+
+   -  Details
+
+-  .. row 2
+
+   -  ``V4L2_HSV_ENC_180``
+
+   -  For the Hue, each LSB is two degrees.
+
+-  .. row 3
+
+   -  ``V4L2_HSV_ENC_256``
+
+   -  For the Hue, the 360 degrees are mapped into 8 bits, i.e. each
+  LSB is roughtly 1.41 degrees.
+
diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst 
b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
index 60ac821e309d..c0239fd2c216 100644
--- a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
@@ -14,7 +14,8 @@ Packed HSV formats
 Description
 ===
 
-The *hue* (h) is measured in degrees, one LSB represents two degrees.
+The *hue* (h) is measured in degrees, the equivalence between degrees and LSBs
+depends on the hsv-encoding used, see :ref:`colorspaces`.
 The *saturation* (s) and the *value* (v) are measured in percentage of the
 cylinder: 0 being the smallest value and 255 the maximum.
 
diff --git a/Documentation/media/videodev2.h.rst.exceptions 

[PATCH v4 09/12] [media] vivid: Local optimization

[Ricardo Ribalda Delgado]

Avoid duplicated data shifts when possible.

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

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index a26172575e56..7f284c591f25 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -919,13 +919,14 @@ static void precalculate_color(struct tpg_data *tpg, int 
k)
color_to_ycbcr(tpg, r, g, b, , , );
 
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
-   y = clamp(y, 16 << 4, 235 << 4);
-   cb = clamp(cb, 16 << 4, 240 << 4);
-   cr = clamp(cr, 16 << 4, 240 << 4);
+   y = clamp(y >> 4, 16, 235);
+   cb = clamp(cb >> 4, 16, 240);
+   cr = clamp(cr >> 4, 16, 240);
+   } else {
+   y = clamp(y >> 4, 1, 254);
+   cb = clamp(cb >> 4, 1, 254);
+   cr = clamp(cr >> 4, 1, 254);
}
-   y = clamp(y >> 4, 1, 254);
-   cb = clamp(cb >> 4, 1, 254);
-   cr = clamp(cr >> 4, 1, 254);
switch (tpg->fourcc) {
case V4L2_PIX_FMT_YUV444:
y >>= 4;
-- 
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] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder

[tiffany lin]

On Fri, 2016-07-15 at 19:50 +0200, Hans Verkuil wrote:
> 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 

Re: [PATCH] [media] dw2102: Add support for Terratec Cinergy S2 USB BOX

[Philipp Zabel]

Am Montag, den 18.07.2016, 08:59 -0300 schrieb Mauro Carvalho Chehab:
> Em Mon, 18 Jul 2016 07:49:49 +0200
> Olli Salonen  escreveu:
> 
> > Hi Mauro,
> > 
> > I have a feeling that this device equals DVBSky S960 (driver
> > dvb-usb-dvbsky) which might be equal to TechnoTrend S2-4600 (driver
> > dvb-usb-dw2102).
> > 
> > If so, I think it would be good to move all devices to the dvbsky driver as
> > that's dvb-usb-v2 unlike the dw2102 driver. I've got the S2-4600 myself, so
> > I can take a look at that later on when not travelling.
> 
> If the driver is identical, then yeah, the best is to move everything
> to the one based on dvb-usb-v2. I would really love to get rid of the
> old dvb-usb driver, but, unfortunately, I don't have all devices.
> 
> I may try to port dib0700 some day, as this is likely the most complex
> one, and may require some adjustments at dvb-usb-v2 that only the
> dibcom drivers are currently using.
> 
> With regards to Terratec Cinergy S2 USB BOX, let's remove it from one
> of the drivers. Could someone send me a patch doing that? It would be
> nice if both Philipp and Benjamin test such patch, for us to be sure
> that it would work for both.

I'll test dvbsky next time I have access to the device.

regards
Philipp

--
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/4] media: Add Mediatek MDP Driver

[Hans Verkuil]

On 07/14/2016 02:18 PM, Minghsiu Tsai wrote:
> Add MDP driver for MT8173
> 
> Signed-off-by: Minghsiu Tsai 
> ---
>  drivers/media/platform/Kconfig|   16 +
>  drivers/media/platform/Makefile   |2 +
>  drivers/media/platform/mtk-mdp/Makefile   |9 +
>  drivers/media/platform/mtk-mdp/mtk_mdp_comp.c |  159 +++
>  drivers/media/platform/mtk-mdp/mtk_mdp_comp.h |   72 ++
>  drivers/media/platform/mtk-mdp/mtk_mdp_core.c |  294 ++
>  drivers/media/platform/mtk-mdp/mtk_mdp_core.h |  233 +
>  drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h  |  126 +++
>  drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c  | 1304 
> +
>  drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h  |   22 +
>  drivers/media/platform/mtk-mdp/mtk_mdp_regs.c |  153 +++
>  drivers/media/platform/mtk-mdp/mtk_mdp_regs.h |   31 +
>  drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c  |  140 +++
>  drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h  |   41 +
>  14 files changed, 2602 insertions(+)
>  create mode 100644 drivers/media/platform/mtk-mdp/Makefile
>  create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
>  create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
>  create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.c
>  create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.h
>  create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h
>  create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
>  create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h
>  create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.c
>  create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.h
>  create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
>  create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 2c2670c..782b618 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -166,6 +166,22 @@ config VIDEO_MEDIATEK_VPU
>   To compile this driver as a module, choose M here: the
>   module will be called mtk-vpu.
>  
> +config VIDEO_MEDIATEK_MDP
> + tristate "Mediatek MDP driver"
> + depends on MTK_IOMMU || COMPILE_TEST
> + depends on VIDEO_DEV && VIDEO_V4L2
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_MEM2MEM_DEV
> + select VIDEO_MEDIATEK_VPU
> + default n
> + ---help---
> + It is a v4l2 driver and present in Mediatek MT8173 SoCs.
> + The driver supports for scaling and color space conversion.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called mtk-mdp.
> +
>  config VIDEO_MEDIATEK_VCODEC
>   tristate "Mediatek Video Codec driver"
>   depends on MTK_IOMMU || COMPILE_TEST
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index c6b3b92..9c54f1a 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -62,3 +62,5 @@ ccflags-y += -I$(srctree)/drivers/media/i2c
>  obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/
>  
>  obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)  += mtk-vcodec/
> +
> +obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp/
> diff --git a/drivers/media/platform/mtk-mdp/Makefile 
> b/drivers/media/platform/mtk-mdp/Makefile
> new file mode 100644
> index 000..f802569
> --- /dev/null
> +++ b/drivers/media/platform/mtk-mdp/Makefile
> @@ -0,0 +1,9 @@
> +mtk-mdp-y += mtk_mdp_core.o
> +mtk-mdp-y += mtk_mdp_comp.o
> +mtk-mdp-y += mtk_mdp_m2m.o
> +mtk-mdp-y += mtk_mdp_regs.o
> +mtk-mdp-y += mtk_mdp_vpu.o
> +
> +obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp.o
> +
> +ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c 
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> new file mode 100644
> index 000..aa8f9fd
> --- /dev/null
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> @@ -0,0 +1,159 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: Ming Hsiu Tsai 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "mtk_mdp_comp.h"
> +
> +
> +static const char * const mtk_mdp_comp_stem[MTK_MDP_COMP_TYPE_MAX] = {
> + "mdp_rdma",
> + "mdp_rsz",
> + "mdp_wdma",
> + "mdp_wrot",
> +};
> +
> +struct mtk_mdp_comp_match {
> +   

Re: [PATCH] dma-buf: Release module reference on creation failure

[Daniel Vetter]

On Mon, Jul 18, 2016 at 12:16:22PM +0100, Chris Wilson wrote:
> If we fail to create the anon file, we need to remember to release the
> module reference on the owner.
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Joonas Lahtinen 
> Cc: Joonas Lahtinen 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> Cc: linux-media@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
>  drivers/dma-buf/dma-buf.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 20ce0687b111..ddaee60ae52a 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -334,6 +334,7 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>   struct reservation_object *resv = exp_info->resv;
>   struct file *file;
>   size_t alloc_size = sizeof(struct dma_buf);
> + int ret;

Not sure this really helps readability, but meh. Will apply to drm-misc,
with a cc: stable.
-Daniel

>  
>   if (!exp_info->resv)
>   alloc_size += sizeof(struct reservation_object);
> @@ -357,8 +358,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>  
>   dmabuf = kzalloc(alloc_size, GFP_KERNEL);
>   if (!dmabuf) {
> - module_put(exp_info->owner);
> - return ERR_PTR(-ENOMEM);
> + ret = -ENOMEM;
> + goto err_module;
>   }
>  
>   dmabuf->priv = exp_info->priv;
> @@ -379,8 +380,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>   file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf,
>   exp_info->flags);
>   if (IS_ERR(file)) {
> - kfree(dmabuf);
> - return ERR_CAST(file);
> + ret = PTR_ERR(file);
> + goto err_dmabuf;
>   }
>  
>   file->f_mode |= FMODE_LSEEK;
> @@ -394,6 +395,12 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>   mutex_unlock(_list.lock);
>  
>   return dmabuf;
> +
> +err_dmabuf:
> + kfree(dmabuf);
> +err_module:
> + module_put(exp_info->owner);
> + return ERR_PTR(ret);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_export);
>  
> -- 
> 2.8.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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] dw2102: Add support for Terratec Cinergy S2 USB BOX

[Mauro Carvalho Chehab]

Em Mon, 18 Jul 2016 07:49:49 +0200
Olli Salonen  escreveu:

> Hi Mauro,
> 
> I have a feeling that this device equals DVBSky S960 (driver
> dvb-usb-dvbsky) which might be equal to TechnoTrend S2-4600 (driver
> dvb-usb-dw2102).
> 
> If so, I think it would be good to move all devices to the dvbsky driver as
> that's dvb-usb-v2 unlike the dw2102 driver. I've got the S2-4600 myself, so
> I can take a look at that later on when not travelling.

If the driver is identical, then yeah, the best is to move everything
to the one based on dvb-usb-v2. I would really love to get rid of the
old dvb-usb driver, but, unfortunately, I don't have all devices.

I may try to port dib0700 some day, as this is likely the most complex
one, and may require some adjustments at dvb-usb-v2 that only the
dibcom drivers are currently using.

With regards to Terratec Cinergy S2 USB BOX, let's remove it from one
of the drivers. Could someone send me a patch doing that? It would be
nice if both Philipp and Benjamin test such patch, for us to be sure
that it would work for both.

Regards,
Mauro

> 
> Cheers,
> -olli
> 
> On 16 July 2016 at 18:47, Mauro Carvalho Chehab 
> wrote:
> 
> > Em Sat, 16 Jul 2016 18:26:35 +0200
> > Olli Salonen  escreveu:
> >  
> > > Hi guys,
> > >
> > > It seems Philipp added the support for this device in dw2102 driver
> > > and Benjamin did that for the dvbsky driver a bit earlier.
> > >
> > > # grep -i 0ccdp0105 /lib/modules/$(uname -r)/modules.alias
> > > alias usb:v0CCDp0105d*dc*dsc*dp*ic*isc*ip*in* dvb_usb_dvbsky
> > > alias usb:v0CCDp0105d*dc*dsc*dp*ic*isc*ip*in* dvb_usb_dw2102
> > >
> > > Any suggestions on how to resolve this conflict?  
> >
> > Let me understand something: the same chipset is supported by both
> > modules? Or the device at dvbsky uses a different hardware than
> > the one at dw2102? In the latter case, sometimes it is possible
> > to distinguish the hardware based on the USB release info. We have
> > a few cases like that. One that comes on my mind is a pixelview
> > device, that uses the same ID for two different devices:
> >
> > cx231xx:
> >
> > {USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x4000,
> > 0x4001),
> >  .driver_info = CX231XX_BOARD_PV_PLAYTV_USB_HYBRID},
> >
> > dib0700:
> >
> > { USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x000,
> > 0x3f00) },
> >
> > Regards,
> > Mauro
> >
> >
> >  
> > >
> > > Cheers,
> > > -olli
> > >
> > > On 4 January 2016 at 20:32, Philipp Zabel   
> > wrote:  
> > > > The Terratec Cinergy S2 USB BOX uses a Montage M88TS2022 tuner
> > > > and a M88DS3103 demodulator, same as Technotrend TT-connect S2-4600.
> > > > This patch adds the missing USB Product ID to make it work.
> > > >
> > > > Signed-off-by: Philipp Zabel 
> > > > ---
> > > >  drivers/media/usb/dvb-usb/dw2102.c | 8 +++-
> > > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/media/usb/dvb-usb/dw2102.c  
> > b/drivers/media/usb/dvb-usb/dw2102.c  
> > > > index 14ef25d..9d18801 100644
> > > > --- a/drivers/media/usb/dvb-usb/dw2102.c
> > > > +++ b/drivers/media/usb/dvb-usb/dw2102.c
> > > > @@ -1688,6 +1688,7 @@ enum dw2102_table_entry {
> > > > TECHNOTREND_S2_4600,
> > > > TEVII_S482_1,
> > > > TEVII_S482_2,
> > > > +   TERRATEC_CINERGY_S2_BOX,
> > > >  };
> > > >
> > > >  static struct usb_device_id dw2102_table[] = {
> > > > @@ -1715,6 +1716,7 @@ static struct usb_device_id dw2102_table[] = {
> > > > USB_PID_TECHNOTREND_CONNECT_S2_4600)},
> > > > [TEVII_S482_1] = {USB_DEVICE(0x9022, 0xd483)},
> > > > [TEVII_S482_2] = {USB_DEVICE(0x9022, 0xd484)},
> > > > +   [TERRATEC_CINERGY_S2_BOX] = {USB_DEVICE(USB_VID_TERRATEC,  
> > 0x0105)},  
> > > > { }
> > > >  };
> > > >
> > > > @@ -2232,7 +2234,7 @@ static struct dvb_usb_device_properties  
> > tt_s2_4600_properties = {  
> > > > } },
> > > > }
> > > > },
> > > > -   .num_device_descs = 3,
> > > > +   .num_device_descs = 4,
> > > > .devices = {
> > > > { "TechnoTrend TT-connect S2-4600",
> > > > { _table[TECHNOTREND_S2_4600], NULL },
> > > > @@ -2246,6 +2248,10 @@ static struct dvb_usb_device_properties  
> > tt_s2_4600_properties = {  
> > > > { _table[TEVII_S482_2], NULL },
> > > > { NULL },
> > > > },
> > > > +   { "Terratec Cinergy S2 USB BOX",
> > > > +   { _table[TERRATEC_CINERGY_S2_BOX], NULL  
> > },  
> > > > +   { NULL },
> > > > +   },
> > > > }
> > > >  };
> > > >
> > > > --
> > > > 2.6.2
> > > >  
> >
> >
> > --
> > Thanks,
> > Mauro
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a 

Re: [PATCH v2 3/3] [media] hva: add H.264 video encoding support

[Hans Verkuil]

On 07/11/2016 05:14 PM, Jean-Christophe Trotin wrote:
> This patch adds the H.264 video encoding capability in the V4L2 HVA
> video encoder driver for STMicroelectronics SoC (hva-h264.c).
> 
> The main supported features are:
> - profile: baseline, main, high, stereo high
> - level: up to 4.2
> - bitrate mode: CBR, VBR
> - entropy mode: CABAC, CAVLC
> - video aspect: 1x1 only
> 
> Signed-off-by: Yannick Fertre 
> Signed-off-by: Jean-Christophe Trotin 
> ---
>  drivers/media/platform/sti/hva/Makefile   |2 +-
>  drivers/media/platform/sti/hva/hva-h264.c | 1053 
> +
>  drivers/media/platform/sti/hva/hva-v4l2.c |  107 ++-
>  drivers/media/platform/sti/hva/hva.h  |  115 +++-
>  4 files changed, 1270 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/media/platform/sti/hva/hva-h264.c
> 



> diff --git a/drivers/media/platform/sti/hva/hva.h 
> b/drivers/media/platform/sti/hva/hva.h
> index 9a1b503b..a81f313 100644
> --- a/drivers/media/platform/sti/hva/hva.h
> +++ b/drivers/media/platform/sti/hva/hva.h
> @@ -23,6 +23,9 @@
>  
>  #define HVA_PREFIX "[---:]"
>  
> +extern const struct hva_enc nv12h264enc;
> +extern const struct hva_enc nv21h264enc;
> +
>  /**
>   * struct hva_frameinfo - information about hva frame
>   *
> @@ -67,13 +70,35 @@ struct hva_streaminfo {
>   * @gop_size:   groupe of picture size
>   * @bitrate:bitrate (in kbps)
>   * @aspect: video aspect
> + * @profile:H.264 profile
> + * @level:  H.264 level
> + * @entropy_mode:   H.264 entropy mode (CABAC or CVLC)
> + * @cpb_size:   coded picture buffer size (in kbps)
> + * @dct8x8: transform mode 8x8 enable
> + * @qpmin:  minimum quantizer
> + * @qpmax:  maximum quantizer
> + * @vui_sar:pixel aspect ratio enable
> + * @vui_sar_idc:pixel aspect ratio identifier
> + * @sei_fp: sei frame packing arrangement enable
> + * @sei_fp_type:sei frame packing arrangement type
>   */
>  struct hva_controls {
> - struct v4l2_fract   time_per_frame;
> - enum v4l2_mpeg_video_bitrate_mode   bitrate_mode;
> - u32 gop_size;
> - u32 bitrate;
> - enum v4l2_mpeg_video_aspect aspect;
> + struct v4l2_fract   time_per_frame;
> + enum v4l2_mpeg_video_bitrate_mode   bitrate_mode;
> + u32 gop_size;
> + u32 bitrate;
> + enum v4l2_mpeg_video_aspect aspect;
> + enum v4l2_mpeg_video_h264_profile   profile;
> + enum v4l2_mpeg_video_h264_level level;
> + enum v4l2_mpeg_video_h264_entropy_mode  entropy_mode;
> + u32 cpb_size;
> + booldct8x8;
> + u32 qpmin;
> + u32 qpmax;
> + boolvui_sar;
> + enum v4l2_mpeg_video_h264_vui_sar_idc   vui_sar_idc;
> + boolsei_fp;
> + enum v4l2_mpeg_video_h264_sei_fp_arrangement_type   sei_fp_type;
>  };
>  
>  /**
> @@ -281,4 +306,84 @@ struct hva_enc {
> struct hva_stream *stream);
>  };
>  
> +static inline const char *profile_str(unsigned int p)
> +{
> + switch (p) {
> + case V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE:
> + return "baseline profile";
> + case V4L2_MPEG_VIDEO_H264_PROFILE_MAIN:
> + return "main profile";
> + case V4L2_MPEG_VIDEO_H264_PROFILE_EXTENDED:
> + return "extended profile";
> + case V4L2_MPEG_VIDEO_H264_PROFILE_HIGH:
> + return "high profile";
> + case V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_10:
> + return "high 10 profile";
> + case V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_422:
> + return "high 422 profile";
> + case V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_444_PREDICTIVE:
> + return "high 444 predictive profile";
> + case V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_10_INTRA:
> + return "high 10 intra profile";
> + case V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_422_INTRA:
> + return "high 422 intra profile";
> + case V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_444_INTRA:
> + return "high 444 intra profile";
> + case V4L2_MPEG_VIDEO_H264_PROFILE_CAVLC_444_INTRA:
> + return "calvc 444 intra profile";
> + case V4L2_MPEG_VIDEO_H264_PROFILE_SCALABLE_BASELINE:
> + return "scalable baseline profile";
> + case 

Re: Troubles with kernel-doc and RST files

[Mauro Carvalho Chehab]

Em Sun, 17 Jul 2016 20:37:19 -0600
Jonathan Corbet  escreveu:

> [Back home and trying to get going on stuff for real.  I'll look at the
> issues listed in this message one at a time.]
> 
> On Sun, 17 Jul 2016 10:01:54 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > 1) We now need to include each header file with documentation twice,
> > one to get the enums, structs, typedefs, ... and another one for the
> > functions:
> > 
> > .. kernel-doc:: include/media/media-device.h
> > 
> > .. kernel-doc:: include/media/media-entity.h
> >:export: drivers/media/media-entity.c  
> 
> So I'm a little confused here; you're including from two different header
> files here.  Did you want media-entity.h in both directives?

Yeah, on my patch I was including every header twice. The first
one to get the structs:

.. kernel-doc:: include/media/media-device.h

.. kernel-doc:: include/media/media-devnode.h

.. kernel-doc:: include/media/media-entity.h

And the next one to get the functions:

.. kernel-doc:: include/media/media-device.h
   :export: drivers/media/media-device.c

.. kernel-doc:: include/media/media-entity.h
   :export: drivers/media/media-entity.c


> If I do a simple test with a single line:
> 
>   .. kernel-doc:: include/media/media-entity.h
> 
> I get everything - structs, functions, etc. - as I would expect.  Are you
> seeing something different?

Weird, now it worked... I noticed this issue because some of the cross
references were broken if I didn't include everything twice, but it
seems that including just one time is enough. Not sure what happened
when I tested it.

> It probably would be nice to have an option for "data structures, doc
> sections, and exported functions only" at some point.

Yeah. Well, actually, I ended by moving the doc sections from the
headers, adding them as a separate rst file. This way, I don't have
to workaround on some parsing issues that might happen with kernel-doc
parsing. Also, IMHO, it makes easier to edit and keep it organized.

Yet, still it could be interesting to be able of putting data structs
on a separate page than the functions. One of the (minor) issues.
What I'm noticing now is that some HTML pages are becoming too big,
as Sphinx is associating one output page per one input page.

It means that, for something like the V4L2 core:

Video2Linux devices
---

.. kernel-doc:: include/media/tuner.h

.. kernel-doc:: include/media/tuner-types.h

.. kernel-doc:: include/media/tveeprom.h

.. kernel-doc:: include/media/v4l2-async.h

.. kernel-doc:: include/media/v4l2-ctrls.h

.. kernel-doc:: include/media/v4l2-dv-timings.h

.. kernel-doc:: include/media/v4l2-event.h

.. kernel-doc:: include/media/v4l2-flash-led-class.h

.. kernel-doc:: include/media/v4l2-mc.h

.. kernel-doc:: include/media/v4l2-mediabus.h

.. kernel-doc:: include/media/v4l2-mem2mem.h

.. kernel-doc:: include/media/v4l2-of.h

.. kernel-doc:: include/media/v4l2-rect.h

.. kernel-doc:: include/media/v4l2-subdev.h

.. kernel-doc:: include/media/videobuf2-core.h

.. kernel-doc:: include/media/videobuf2-v4l2.h

.. kernel-doc:: include/media/videobuf2-memops.h

It produces a 337.4KB document with 3739 lines:

  3739  24703 337487 
/devel/v4l/patchwork/Documentation/output/html/media/kapi/v4l2-core.html


Btw, if you want to see how the media conversion to ReST is going,
I have it altogether at:
https://linuxtv.org/downloads/v4l-dvb-apis-new/index.html

Almost everything is there already, including all documents that
were at Documentation/dvb, and almost all that were at
Documentation/video4linux/. There are just 30 documents left that I still
need to handle, and that requires more care to be ported:

Documentation/video4linux/
├── bttv
│   ├── Cards
│   ├── CONTRIBUTORS
│   ├── ICs
│   ├── Insmod-options
│   ├── MAKEDEV
│   ├── Modprobe.conf
│   ├── Modules.conf
│   ├── PROBLEMS
│   ├── README
│   ├── README.freeze
│   ├── README.quirks
│   ├── README.WINVIEW
│   ├── Sound-FAQ
│   ├── Specs
│   ├── THANKS
│   └── Tuners
├── cx2341x
│   ├── fw-calling.txt
│   ├── fw-decoder-api.txt
│   ├── fw-decoder-regs.txt
│   ├── fw-dma.txt
│   ├── fw-encoder-api.txt
│   ├── fw-memory.txt
│   ├── fw-osd-api.txt
│   ├── fw-upload.txt
│   ├── README.hm12
│   └── README.vbi
├── cx88
│   └── hauppauge-wintv-cx88-ir.txt
├── hauppauge-wintv-cx88-ir.txt
├── lifeview.txt
└── not-in-cx2388x-datasheet.txt

3 directories, 30 files

My plan is to handle those today, likely merging some text files
into a few ones.

I still need to do a second round of review on the kAPI book and at the
V4L and DVB drivers books, to make them to look more like a single
document, and not a "Frankenstein" glue.

Some documents are too outdated too. So, their contents need to be
adjusted. My plan is to do an extra review on that for 4.9, in
order to either update or drop them.

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a 

Re: [PATCH v2 2/3] [media] hva: multi-format video encoder V4L2 driver

[Hans Verkuil]

Hi Jean-Christophe,

See my review comments below. Nothing really major, but I do need to know more
about the g/s_parm and the restriction on the number of open()s has to be 
lifted.
That's not allowed.

On 07/11/2016 05:14 PM, Jean-Christophe Trotin wrote:
> This patch adds V4L2 HVA (Hardware Video Accelerator) video encoder
> driver for STMicroelectronics SoC. It uses the V4L2 mem2mem framework.
> 
> This patch only contains the core parts of the driver:
> - the V4L2 interface with the userland (hva-v4l2.c)
> - the hardware services (hva-hw.c)
> - the memory management utilities (hva-mem.c)
> 
> This patch doesn't include the support of specific codec (e.g. H.264)
> video encoding: this support is part of subsequent patches.
> 
> Signed-off-by: Yannick Fertre 
> Signed-off-by: Jean-Christophe Trotin 
> ---
>  drivers/media/platform/Kconfig|   14 +
>  drivers/media/platform/Makefile   |1 +
>  drivers/media/platform/sti/hva/Makefile   |2 +
>  drivers/media/platform/sti/hva/hva-hw.c   |  534 
>  drivers/media/platform/sti/hva/hva-hw.h   |   42 +
>  drivers/media/platform/sti/hva/hva-mem.c  |   60 ++
>  drivers/media/platform/sti/hva/hva-mem.h  |   36 +
>  drivers/media/platform/sti/hva/hva-v4l2.c | 1299 
> +
>  drivers/media/platform/sti/hva/hva.h  |  284 +++
>  9 files changed, 2272 insertions(+)
>  create mode 100644 drivers/media/platform/sti/hva/Makefile
>  create mode 100644 drivers/media/platform/sti/hva/hva-hw.c
>  create mode 100644 drivers/media/platform/sti/hva/hva-hw.h
>  create mode 100644 drivers/media/platform/sti/hva/hva-mem.c
>  create mode 100644 drivers/media/platform/sti/hva/hva-mem.h
>  create mode 100644 drivers/media/platform/sti/hva/hva-v4l2.c
>  create mode 100644 drivers/media/platform/sti/hva/hva.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 382f393..182d63f 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -227,6 +227,20 @@ config VIDEO_STI_BDISP
>   help
> This v4l2 mem2mem driver is a 2D blitter for STMicroelectronics SoC.
>  
> +config VIDEO_STI_HVA
> + tristate "STMicroelectronics STiH41x HVA multi-format video encoder 
> V4L2 driver"
> + depends on VIDEO_DEV && VIDEO_V4L2
> + depends on ARCH_STI || COMPILE_TEST
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_MEM2MEM_DEV
> + help
> +   This V4L2 driver enables HVA multi-format video encoder of

Please mention here what HVA stands for.

> +   STMicroelectronics SoC STiH41x series, allowing hardware encoding of 
> raw
> +   uncompressed formats in various compressed video bitstreams format.
> +
> +   To compile this driver as a module, choose M here:
> +   the module will be called hva.

How about sti-hva as the module name? 'hva' is a bit too generic.

> +
>  config VIDEO_SH_VEU
>   tristate "SuperH VEU mem2mem video processing driver"
>   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA



> diff --git a/drivers/media/platform/sti/hva/hva-v4l2.c 
> b/drivers/media/platform/sti/hva/hva-v4l2.c
> new file mode 100644
> index 000..bacc9ff
> --- /dev/null
> +++ b/drivers/media/platform/sti/hva/hva-v4l2.c
> @@ -0,0 +1,1299 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2015
> + * Authors: Yannick Fertre 
> + *  Hugues Fruchet 
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "hva.h"
> +#include "hva-hw.h"
> +
> +#define HVA_NAME "hva"
> +
> +#define MIN_FRAMES   1
> +#define MIN_STREAMS  1
> +
> +#define HVA_MIN_WIDTH32
> +#define HVA_MAX_WIDTH1920
> +#define HVA_MIN_HEIGHT   32
> +#define HVA_MAX_HEIGHT   1920
> +
> +/* HVA requires a 16x16 pixels alignment for frames */
> +#define HVA_WIDTH_ALIGNMENT  16
> +#define HVA_HEIGHT_ALIGNMENT 16
> +
> +#define DEFAULT_WIDTHHVA_MIN_WIDTH
> +#define  DEFAULT_HEIGHT  HVA_MIN_HEIGHT
> +#define DEFAULT_FRAME_NUM1
> +#define DEFAULT_FRAME_DEN30
> +
> +#define to_type_str(type) (type == V4L2_BUF_TYPE_VIDEO_OUTPUT ? \
> +"frame" : "stream")
> +
> +#define fh_to_ctx(f)(container_of(f, struct hva_ctx, fh))
> +
> +/* registry of available encoders */
> +const struct hva_enc *hva_encoders[] = {
> +};
> +
> +static inline int frame_size(u32 w, u32 h, u32 fmt)
> +{
> + switch (fmt) {
> + case V4L2_PIX_FMT_NV12:
> + case V4L2_PIX_FMT_NV21:
> + return (w * h * 3) / 2;
> + default:
> + return 0;
> + }
> +}
> +
> +static inline int frame_stride(u32 w, u32 fmt)
> +{
> + switch (fmt) {
> + case V4L2_PIX_FMT_NV12:
> + case V4L2_PIX_FMT_NV21:
> + return w;
> + default:
> + return 0;
> +  

[PATCH] dma-buf: Release module reference on creation failure

[Chris Wilson]

If we fail to create the anon file, we need to remember to release the
module reference on the owner.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Cc: Joonas Lahtinen 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
Cc: linux-media@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/dma-buf/dma-buf.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 20ce0687b111..ddaee60ae52a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -334,6 +334,7 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
struct reservation_object *resv = exp_info->resv;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
+   int ret;
 
if (!exp_info->resv)
alloc_size += sizeof(struct reservation_object);
@@ -357,8 +358,8 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
 
dmabuf = kzalloc(alloc_size, GFP_KERNEL);
if (!dmabuf) {
-   module_put(exp_info->owner);
-   return ERR_PTR(-ENOMEM);
+   ret = -ENOMEM;
+   goto err_module;
}
 
dmabuf->priv = exp_info->priv;
@@ -379,8 +380,8 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf,
exp_info->flags);
if (IS_ERR(file)) {
-   kfree(dmabuf);
-   return ERR_CAST(file);
+   ret = PTR_ERR(file);
+   goto err_dmabuf;
}
 
file->f_mode |= FMODE_LSEEK;
@@ -394,6 +395,12 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
mutex_unlock(_list.lock);
 
return dmabuf;
+
+err_dmabuf:
+   kfree(dmabuf);
+err_module:
+   module_put(exp_info->owner);
+   return ERR_PTR(ret);
 }
 EXPORT_SYMBOL_GPL(dma_buf_export);
 
-- 
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] vim2m: copy the other colorspace-related fields as well

[Hans Verkuil]

The xfer_func, ycbcr_enc and quantization fields should also be copied from
output to capture format.

Since this driver serves as example code it is important that this is handled
correctly.

Signed-off-by: Hans Verkuil 

diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index 6b17015..cd0ff4a 100644
--- a/drivers/media/platform/vim2m.c
+++ b/drivers/media/platform/vim2m.c
@@ -171,6 +171,9 @@ struct vim2m_ctx {
int mode;

enum v4l2_colorspacecolorspace;
+   enum v4l2_ycbcr_encoding ycbcr_enc;
+   enum v4l2_xfer_func xfer_func;
+   enum v4l2_quantization  quant;

/* Source and destination queue data */
struct vim2m_q_data   q_data[2];
@@ -493,6 +496,9 @@ static int vidioc_g_fmt(struct vim2m_ctx *ctx, struct 
v4l2_format *f)
f->fmt.pix.bytesperline = (q_data->width * q_data->fmt->depth) >> 3;
f->fmt.pix.sizeimage= q_data->sizeimage;
f->fmt.pix.colorspace   = ctx->colorspace;
+   f->fmt.pix.xfer_func= ctx->xfer_func;
+   f->fmt.pix.ycbcr_enc= ctx->ycbcr_enc;
+   f->fmt.pix.quantization = ctx->quant;

return 0;
 }
@@ -549,6 +555,9 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void 
*priv,
return -EINVAL;
}
f->fmt.pix.colorspace = ctx->colorspace;
+   f->fmt.pix.xfer_func = ctx->xfer_func;
+   f->fmt.pix.ycbcr_enc = ctx->ycbcr_enc;
+   f->fmt.pix.quantization = ctx->quant;

return vidioc_try_fmt(f, fmt);
 }
@@ -630,8 +639,12 @@ static int vidioc_s_fmt_vid_out(struct file *file, void 
*priv,
return ret;

ret = vidioc_s_fmt(file2ctx(file), f);
-   if (!ret)
+   if (!ret) {
ctx->colorspace = f->fmt.pix.colorspace;
+   ctx->xfer_func = f->fmt.pix.xfer_func;
+   ctx->ycbcr_enc = f->fmt.pix.ycbcr_enc;
+   ctx->quant = f->fmt.pix.quantization;
+   }
return ret;
 }

--
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)

[Hans Verkuil]

On 07/18/2016 12:29 PM, Brian Starkey wrote:
> Hi,
> 
> On Fri, Jul 15, 2016 at 10:42:01AM -0700, Eric Anholt wrote:
>> 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 

Re: DRM device memory writeback (Mali-DP)

[Brian Starkey]

Hi,

On Fri, Jul 15, 2016 at 10:42:01AM -0700, Eric Anholt wrote:

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 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 

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

[Marek Szyprowski]

Hello,


On 2016-07-15 18:26, 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 


Sorry, but I don't get why such change is really needed. If possible it is
better to report errors to userspace as early as possible, not postpone them
to the moment, when they cannot be easily debugged.



---

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 

[PATCH] cec: always check all_device_types and features

[Hans Verkuil]

>From e553f06a95a48ac541e20086e9c6b2f50cc663cd Mon Sep 17 00:00:00 2001
From: Hans Verkuil 
Date: Mon, 18 Jul 2016 08:44:10 +0200
Subject: [PATCH] cec: always check all_device_types and features

Even when the adapter is configured for CEC 1.4, we still check and
use the CEC 2.0 parts of struct cec_log_addrs. Although these aren't
used in CEC messages, the information contained in them is still of
use in the CEC framework itself, so keep this information.

Also zero the unused trailing features[] data and unused logical address
data so the contents isn't random data.

Signed-off-by: Hans Verkuil 
---
 drivers/staging/media/cec/cec-adap.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/media/cec/cec-adap.c 
b/drivers/staging/media/cec/cec-adap.c
index 3298f1b..a58165c 100644
--- a/drivers/staging/media/cec/cec-adap.c
+++ b/drivers/staging/media/cec/cec-adap.c
@@ -1210,13 +1210,8 @@ int __cec_s_log_addrs(struct cec_adapter *adap,
return -EINVAL;
}

-   if (log_addrs->cec_version < CEC_OP_CEC_VERSION_2_0) {
-   memset(log_addrs->all_device_types, 0,
-  sizeof(log_addrs->all_device_types));
-   memset(log_addrs->features, 0, sizeof(log_addrs->features));
-   }
-
for (i = 0; i < log_addrs->num_log_addrs; i++) {
+   const u8 feature_sz = ARRAY_SIZE(log_addrs->features[0]);
u8 *features = log_addrs->features[i];
bool op_is_dev_features = false;

@@ -1245,21 +1240,19 @@ int __cec_s_log_addrs(struct cec_adapter *adap,
dprintk(1, "unknown logical address type\n");
return -EINVAL;
}
-   if (log_addrs->cec_version < CEC_OP_CEC_VERSION_2_0)
-   continue;
-
-   for (i = 0; i < ARRAY_SIZE(log_addrs->features[0]); i++) {
+   for (i = 0; i < feature_sz; i++) {
if ((features[i] & 0x80) == 0) {
if (op_is_dev_features)
break;
op_is_dev_features = true;
}
}
-   if (!op_is_dev_features ||
-   i == ARRAY_SIZE(log_addrs->features[0])) {
+   if (!op_is_dev_features || i == feature_sz) {
dprintk(1, "malformed features\n");
return -EINVAL;
}
+   /* Zero unused part of the feature array */
+   memset(features + i, 0, feature_sz - i);
}

if (log_addrs->cec_version >= CEC_OP_CEC_VERSION_2_0) {
@@ -1281,6 +1274,15 @@ int __cec_s_log_addrs(struct cec_adapter *adap,
}
}

+   /* Zero unused LAs */
+   for (i = log_addrs->num_log_addrs; i < CEC_MAX_LOG_ADDRS; i++) {
+   log_addrs->primary_device_type[i] = 0;
+   log_addrs->log_addr_type[i] = 0;
+   log_addrs->all_device_types[i] = 0;
+   memset(log_addrs->features[i], 0,
+  sizeof(log_addrs->features[i]));
+   }
+
log_addrs->log_addr_mask = adap->log_addrs.log_addr_mask;
adap->log_addrs = *log_addrs;
if (adap->phys_addr != CEC_PHYS_ADDR_INVALID)
-- 
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 v5] [media] pci: Add tw5864 driver

[Hans Verkuil]

Hi Andrey,

Just a few small comments, I'd say the next version should be ready for merging
in 4.9 (it's too late for 4.8).

On 07/13/2016 04:12 PM, Andrey Utkin wrote:
> Changes since v4:
>  - Decrease motion data buffer to bare minimum
>  - Fix all "checkpatch.pl --strict" notices (whitespace)
> 
> Changes since v3:
>  - updated copyright year
>  - Add VB2_DMABUF flag
>  - fix whitespace as suggested
>  - Move dma_sync_single_for_*() calls to tasklet function
>  - Reflow warning messages (add newlines)
>  - amend caps declaration as suggested
> 
> 
> News here!
> 
> Briefly: there's a new hope for fixing artifacts, but please consider 
> accepting
> current submission.
> 
> One nice guy, a user of tw5864-based board, got in touch with me and
> shared different vendor-provided driver. It was obfuscated, but after trivial
> de-obfuscation it seems much clearer than what I had to tinker with during
> these long 1.5 years of development of this driver.
> https://github.com/bluecherrydvr/linux/blob/new_tw5864/drivers/media/pci/Isil5864/tw5864.c
> 
> I don't swear that I'll fix video artifacts soon, though. I will have time to
> tinker with this not sooner than August (and my free time is going to get very
> limited by then). And what our driver does is still very similar to what this
> new driver does, so the difference must be subtle, so please don't hold your
> breath.
> 
> 
> 
> 16:55:49j@zver /j/Sync/src/linux
>  $ ./scripts/checkpatch.pl --strict 0001-media-pci-Add-tw5864-driver.patch 
> total: 0 errors, 0 warnings, 0 checks, 4555 lines checked
> 
> 0001-media-pci-Add-tw5864-driver.patch has no obvious style problems and is 
> ready for submission.
> [OK]
> 16:56:00j@zver /j/Sync/src/linux
>  $ make M=drivers/media/pci/tw5864 C=2
>   CHECK   drivers/media/pci/tw5864/tw5864-core.c
>   CC [M]  drivers/media/pci/tw5864/tw5864-core.o
>   CHECK   drivers/media/pci/tw5864/tw5864-video.c
>   CC [M]  drivers/media/pci/tw5864/tw5864-video.o
>   CHECK   drivers/media/pci/tw5864/tw5864-h264.c
>   CC [M]  drivers/media/pci/tw5864/tw5864-h264.o
>   CHECK   drivers/media/pci/tw5864/tw5864-util.c
>   CC [M]  drivers/media/pci/tw5864/tw5864-util.o
>   LD [M]  drivers/media/pci/tw5864/tw5864.o
>   Building modules, stage 2.
>   MODPOST 1 modules
>   LD [M]  drivers/media/pci/tw5864/tw5864.ko
> [OK]
> 
> 
> root@localhost:/src/linux# v4l2-compliance -d 6 -s
> v4l2-compliance SHA   : 5e74f6a15aa14c01d8319e086d98f33d96a6a04d
> 
> Driver Info:
> Driver name   : tw5864
> Card type : TW5864 Encoder 2
> Bus info  : PCI::06:05.0
> Driver version: 4.7.0
> Capabilities  : 0x8521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps   : 0x0521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> 
> Compliance test for device /dev/video6 (not using libv4l2):
> 
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> 
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Test input 0:
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 11 Private Controls: 0
> 
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK
> test VIDIOC_G_FBUF: OK (Not Supported)
>   

Re: [PATCH v3 8/9] [media] vivid: Fix YUV555 and YUV565 handling

[Ricardo Ribalda Delgado]

Hi Hans


On Mon, Jul 18, 2016 at 10:51 AM, Hans Verkuil  wrote:
>> + int y, cb, cr;
>> + bool ycbbr_valid = false;
>
> I guess you mean ycbcr_valid?

Yes, I think the medical term is Saturday dyslexia :)

It is fixed on the next version.

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

Re: [PATCH v3 8/9] [media] vivid: Fix YUV555 and YUV565 handling

[Hans Verkuil]

On 07/16/2016 12:41 PM, Ricardo Ribalda Delgado wrote:
> precalculate_color() had a optimization that avoided duplicated
> conversion for YUV formats. This optimization did not take into
> consideration YUV444, YUV555, YUV565 or limited range quantization.
> 
> This patch keeps the optimization, but fixes the wrong handling.
> 
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 19 ---
>  1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
> b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> index e91bf3cbaab9..1c862465e335 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -797,6 +797,8 @@ static void precalculate_color(struct tpg_data *tpg, int 
> k)
>   int r = tpg_colors[col].r;
>   int g = tpg_colors[col].g;
>   int b = tpg_colors[col].b;
> + int y, cb, cr;
> + bool ycbbr_valid = false;

I guess you mean ycbcr_valid?

Regards,

Hans

>  
>   if (k == TPG_COLOR_TEXTBG) {
>   col = tpg_get_textbg_color(tpg);
> @@ -873,7 +875,6 @@ static void precalculate_color(struct tpg_data *tpg, int 
> k)
>tpg->saturation != 128 || tpg->hue) &&
>   tpg->color_enc != TGP_COLOR_ENC_LUMA) {
>   /* Implement these operations */
> - int y, cb, cr;
>   int tmp_cb, tmp_cr;
>  
>   /* First convert to YCbCr */
> @@ -890,13 +891,10 @@ 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->color_enc == TGP_COLOR_ENC_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);
> - return;
> - }
> - ycbcr_to_color(tpg, y, cb, cr, , , );
> + if (tpg->color_enc == TGP_COLOR_ENC_YUV)
> + ycbbr_valid = true;
> + else
> + ycbcr_to_color(tpg, y, cb, cr, , , );
>   } else if ((tpg->brightness != 128 || tpg->contrast != 128) &&
>  tpg->color_enc == TGP_COLOR_ENC_LUMA) {
>   r = (16 << 4) + ((r - (16 << 4)) * tpg->contrast) / 128;
> @@ -917,9 +915,8 @@ static void precalculate_color(struct tpg_data *tpg, int 
> k)
>   case TGP_COLOR_ENC_YUV:
>   {
>   /* Convert to YCbCr */
> - int y, cb, cr;
> -
> - color_to_ycbcr(tpg, r, g, b, , , );
> + if (!ycbbr_valid)
> + color_to_ycbcr(tpg, r, g, b, , , );
>  
>   if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
>   y = clamp(y, 16 << 4, 235 << 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 v3 4/9] [media] vivid: code refactor for color encoding

[Hans Verkuil]

On 07/16/2016 12:41 PM, Ricardo Ribalda Delgado wrote:
> Replace is_yuv with color_enc Which can be used by other
> color encodings such us HSV.
> 
> 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   | 49 +++
>  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, 66 insertions(+), 44 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..e8d2bf388597 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -1889,11 +1893,24 @@ static int tpg_pattern_avg(const struct tpg_data *tpg,
>   return -1;
>  }
>  
> +static const char *tpg_color_enc_str(enum tgp_color_enc
> +  color_enc)
> +{
> + switch (color_enc) {
> + case TGP_COLOR_ENC_YUV:
> + return "YCbCr";

Use "Y'CbCr"

> + case TGP_COLOR_ENC_RGB:
> + default:
> + return "RGB";

and "R'G'B'".

That's more precise.

> +
> + }
> +}
> +
>  void tpg_log_status(struct tpg_data *tpg)
>  {
>   pr_info("tpg source WxH: %ux%u (%s)\n",
> - tpg->src_width, tpg->src_height,
> - tpg->is_yuv ? "YCbCr" : "RGB");
> + tpg->src_width, tpg->src_height,
> + tpg_color_enc_str(tpg->color_enc));
>   pr_info("tpg field: %u\n", tpg->field);
>   pr_info("tpg crop: %ux%u@%dx%d\n", tpg->crop.width, tpg->crop.height,
>   tpg->crop.left, tpg->crop.top);
> diff --git a/include/media/v4l2-tpg.h b/include/media/v4l2-tpg.h
> index 329bebfa930c..e4da507d40e2 100644
> --- a/include/media/v4l2-tpg.h
> +++ b/include/media/v4l2-tpg.h
> @@ -87,6 +87,11 @@ enum tpg_move_mode {
>   TPG_MOVE_POS_FAST,
>  };
>  
> +enum tgp_color_enc {
> + TGP_COLOR_ENC_RGB,
> + TGP_COLOR_ENC_YUV,

Rename this to YCBCR. It's the technically correct name.

Regards,

Hans

> +};
> +
>  extern const char * const tpg_aspect_strings[];
>  
>  #define TPG_MAX_PLANES 3
> @@ -119,7 +124,7 @@ struct tpg_data {
>   u8  saturation;
>   s16 hue;
>   u32 fourcc;
> - boolis_yuv;
> + enum tgp_color_enc  color_enc;
>   u32 colorspace;
>   u32 xfer_func;
>   u32 ycbcr_enc;
> 
--
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

[Hans Verkuil]

On 07/15/2016 06:26 PM, 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.

Does this solve anything? Once the DMA has started the behavior is the same
as before (QBUF maps the dmabuf), only while the DMA engine hasn't started
yet are the QBUF calls just accepted and the mapping takes place when the
DMA is kickstarted. This makes QBUF behave inconsistently.

You don't describe here WHY this change is needed.

I'm not sure I agree with the TODO, and even if I did, I'm not sure I agree
with this solution. Since queuing the buffer to the driver is not the same
as 'just before the DMA', since there may be many buffers queued up in the
driver and you don't know in vb2 when the buffer is at the 'just before the DMA'
stage.

Regards,

Hans

> 
> 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 */
> - 

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

[Michael Olbrich]

Hi,

On Fri, Jul 15, 2016 at 12:26:06PM -0400, 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.

And for mem2mem devices? Does this mean that the second VIDIOC_STREAMON
will fail? That would make it impossible detect if the buffers on the
capture or the output side are incorrect.

It's already quite difficult to handle these issues gracefully and without
loosing any data. This would make it even worse.

Regards,
Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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