[GIT PULL] rtl28xxu / mn88472 / mn88473

[Antti Palosaari]

V2. Fixed issues pointed by Mauro.

regards
Antti

The following changes since commit c02ef64aab828d80040b5dce934729312e698c33:

  [media] cx23885: add DVBSky T982(Dual DVB-T2/T/C) support (2014-11-14 
18:28:41 -0200)


are available in the git repository at:

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

for you to fetch changes up to 52028b9f5b3a4c4c349a50ac626f7a97a48a51ca:

  rtl28xxu: add SDR module for devices having R828D tuner (2014-11-18 
09:16:54 +0200)



Antti Palosaari (6):
  rtl2832: implement option to bypass slave demod TS
  rtl28xxu: add support for Panasonic MN88472 slave demod
  rtl28xxu: add support for Panasonic MN88473 slave demod
  rtl28xxu: rename tuner I2C client pointer
  rtl28xxu: remove unused SDR attach logic
  rtl28xxu: add SDR module for devices having R828D tuner

 drivers/media/dvb-frontends/rtl2832.c   |  60 
---

 drivers/media/dvb-frontends/rtl2832.h   |  11 ++
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 194 
+++

 drivers/media/usb/dvb-usb-v2/rtl28xxu.h |   7 +-

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

[PATCHv2 6/6] rtl28xxu: add SDR module for devices having R828D tuner

[Antti Palosaari]

Load SDR sub-driver in order to support SDR for devices having
this tuner too.

Signed-off-by: Antti Palosaari 
---
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index a30ed17..896a225 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1113,6 +1113,10 @@ static int rtl2832u_tuner_attach(struct dvb_usb_adapter 
*adap)
adap->fe[1]->ops.read_signal_strength =

adap->fe[1]->ops.tuner_ops.get_rf_strength;
}
+
+   /* attach SDR */
+   dvb_attach_sdr(rtl2832_sdr_attach, adap->fe[0], &d->i2c_adap,
+   &rtl28xxu_rtl2832_r820t_config, NULL);
break;
default:
dev_err(&d->udev->dev, "%s: unknown tuner=%d\n", KBUILD_MODNAME,
-- 
http://palosaari.fi/

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

[PATCHv2 1/6] rtl2832: implement option to bypass slave demod TS

[Antti Palosaari]

Implement partial PIP mode to carry TS from slave demodulator,
through that master demodulator. RTL2832 demod has TS input
interface to connected another demodulator TS output.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-frontends/rtl2832.c | 60 +--
 drivers/media/dvb-frontends/rtl2832.h | 11 +++
 2 files changed, 68 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/rtl2832.c 
b/drivers/media/dvb-frontends/rtl2832.c
index eb737cf..9026e1a 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -258,13 +258,11 @@ static int rtl2832_rd_regs(struct rtl2832_priv *priv, u8 
reg, u8 page, u8 *val,
return rtl2832_rd(priv, reg, val, len);
 }
 
-#if 0 /* currently not used */
 /* write single register */
 static int rtl2832_wr_reg(struct rtl2832_priv *priv, u8 reg, u8 page, u8 val)
 {
return rtl2832_wr_regs(priv, reg, page, &val, 1);
 }
-#endif
 
 /* read single register */
 static int rtl2832_rd_reg(struct rtl2832_priv *priv, u8 reg, u8 page, u8 *val)
@@ -599,6 +597,11 @@ static int rtl2832_set_frontend(struct dvb_frontend *fe)
if (fe->ops.tuner_ops.set_params)
fe->ops.tuner_ops.set_params(fe);
 
+   /* PIP mode related */
+   ret = rtl2832_wr_regs(priv, 0x92, 1, "\x00\x0f\xff", 3);
+   if (ret)
+   goto err;
+
/* If the frontend has get_if_frequency(), use it */
if (fe->ops.tuner_ops.get_if_frequency) {
u32 if_freq;
@@ -661,7 +664,6 @@ static int rtl2832_set_frontend(struct dvb_frontend *fe)
if (ret)
goto err;
 
-
/* soft reset */
ret = rtl2832_wr_demod_reg(priv, DVBT_SOFT_RST, 0x1);
if (ret)
@@ -1020,6 +1022,58 @@ static int rtl2832_deselect(struct i2c_adapter *adap, 
void *mux_priv,
return 0;
 }
 
+int rtl2832_enable_external_ts_if(struct dvb_frontend *fe)
+{
+   struct rtl2832_priv *priv = fe->demodulator_priv;
+   int ret;
+
+   dev_dbg(&priv->i2c->dev, "%s: setting PIP mode\n", __func__);
+
+   ret = rtl2832_wr_regs(priv, 0x0c, 1, "\x5f\xff", 2);
+   if (ret)
+   goto err;
+
+   ret = rtl2832_wr_demod_reg(priv, DVBT_PIP_ON, 0x1);
+   if (ret)
+   goto err;
+
+   ret = rtl2832_wr_reg(priv, 0xbc, 0, 0x18);
+   if (ret)
+   goto err;
+
+   ret = rtl2832_wr_reg(priv, 0x22, 0, 0x01);
+   if (ret)
+   goto err;
+
+   ret = rtl2832_wr_reg(priv, 0x26, 0, 0x1f);
+   if (ret)
+   goto err;
+
+   ret = rtl2832_wr_reg(priv, 0x27, 0, 0xff);
+   if (ret)
+   goto err;
+
+   ret = rtl2832_wr_regs(priv, 0x92, 1, "\x7f\xf7\xff", 3);
+   if (ret)
+   goto err;
+
+   /* soft reset */
+   ret = rtl2832_wr_demod_reg(priv, DVBT_SOFT_RST, 0x1);
+   if (ret)
+   goto err;
+
+   ret = rtl2832_wr_demod_reg(priv, DVBT_SOFT_RST, 0x0);
+   if (ret)
+   goto err;
+
+   return 0;
+err:
+   dev_dbg(&priv->i2c->dev, "%s: failed=%d\n", __func__, ret);
+   return ret;
+
+}
+EXPORT_SYMBOL(rtl2832_enable_external_ts_if);
+
 struct i2c_adapter *rtl2832_get_i2c_adapter(struct dvb_frontend *fe)
 {
struct rtl2832_priv *priv = fe->demodulator_priv;
diff --git a/drivers/media/dvb-frontends/rtl2832.h 
b/drivers/media/dvb-frontends/rtl2832.h
index cb3b6b0..5254c1d 100644
--- a/drivers/media/dvb-frontends/rtl2832.h
+++ b/drivers/media/dvb-frontends/rtl2832.h
@@ -64,6 +64,10 @@ extern struct i2c_adapter *rtl2832_get_private_i2c_adapter(
struct dvb_frontend *fe
 );
 
+extern int rtl2832_enable_external_ts_if(
+   struct dvb_frontend *fe
+);
+
 #else
 
 static inline struct dvb_frontend *rtl2832_attach(
@@ -89,6 +93,13 @@ static inline struct i2c_adapter 
*rtl2832_get_private_i2c_adapter(
return NULL;
 }
 
+static inline int rtl2832_enable_external_ts_if(
+   struct dvb_frontend *fe
+)
+{
+   return -ENODEV;
+}
+
 #endif
 
 
-- 
http://palosaari.fi/

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

[PATCHv2 5/6] rtl28xxu: remove unused SDR attach logic

[Antti Palosaari]

That logic was duplicated from rtl2832_sdr.h in order to avoid hard
dependency for staging directory. rtl2832_sdr is moved to media, so
we could remove that code now.

Signed-off-by: Antti Palosaari 
---
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index a527330d..a30ed17 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -24,6 +24,7 @@
 
 #include "rtl2830.h"
 #include "rtl2832.h"
+#include "rtl2832_sdr.h"
 #include "mn88472.h"
 #include "mn88473.h"
 
@@ -37,25 +38,6 @@
 #include "tua9001.h"
 #include "r820t.h"
 
-/*
- * RTL2832_SDR module is in staging. That logic is added in order to avoid any
- * hard dependency to drivers/staging/ directory as we want compile mainline
- * driver even whole staging directory is missing.
- */
-#include 
-
-#if IS_ENABLED(CONFIG_DVB_RTL2832_SDR)
-struct dvb_frontend *rtl2832_sdr_attach(struct dvb_frontend *fe,
-   struct i2c_adapter *i2c, const struct rtl2832_config *cfg,
-   struct v4l2_subdev *sd);
-#else
-static inline struct dvb_frontend *rtl2832_sdr_attach(struct dvb_frontend *fe,
-   struct i2c_adapter *i2c, const struct rtl2832_config *cfg,
-   struct v4l2_subdev *sd)
-{
-   return NULL;
-}
-#endif
 
 #ifdef CONFIG_MEDIA_ATTACH
 #define dvb_attach_sdr(FUNCTION, ARGS...) ({ \
-- 
http://palosaari.fi/

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

[PATCHv2 4/6] rtl28xxu: rename tuner I2C client pointer

[Antti Palosaari]

Better to rename tuner I2C to something which clearly says it is
for tuner as there is now multiple different I2C clients used.

Signed-off-by: Antti Palosaari 
---
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 6 +++---
 drivers/media/usb/dvb-usb-v2/rtl28xxu.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index cb54d2a..a527330d 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1078,7 +1078,7 @@ static int rtl2832u_tuner_attach(struct dvb_usb_adapter 
*adap)
break;
}
 
-   priv->client = client;
+   priv->i2c_client_tuner = client;
sd = i2c_get_clientdata(client);
i2c_set_adapdata(i2c_adap_internal, d);
 
@@ -1137,7 +1137,7 @@ static int rtl2832u_tuner_attach(struct dvb_usb_adapter 
*adap)
priv->tuner);
}
 
-   if (fe == NULL && priv->client == NULL) {
+   if (fe == NULL && priv->i2c_client_tuner == NULL) {
ret = -ENODEV;
goto err;
}
@@ -1190,7 +1190,7 @@ static void rtl28xxu_exit(struct dvb_usb_device *d)
dev_dbg(&d->udev->dev, "%s:\n", __func__);
 
/* remove I2C tuner */
-   client = priv->client;
+   client = priv->i2c_client_tuner;
if (client) {
module_put(client->dev.driver->owner);
i2c_unregister_device(client);
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.h 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
index 7f959ff..3e3ea9d 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
@@ -57,7 +57,7 @@ struct rtl28xxu_priv {
u8 page; /* integrated demod active register page */
struct i2c_adapter *demod_i2c_adapter;
bool rc_active;
-   struct i2c_client *client;
+   struct i2c_client *i2c_client_tuner;
struct i2c_client *i2c_client_slave_demod;
#define SLAVE_DEMOD_NONE   0
#define SLAVE_DEMOD_MN884721
-- 
http://palosaari.fi/

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

[PATCHv2 2/6] rtl28xxu: add support for Panasonic MN88472 slave demod

[Antti Palosaari]

There is RTL2832P devices having extra MN88472 demodulator. This
patch add support for such configuration. Logically MN88472 slave
demodulator is connected to RTL2832 master demodulator, both I2C
bus and TS input. RTL2832 is integrated to RTL2832U and RTL2832P
chips. Chip version RTL2832P has extra TS interface for connecting
slave demodulator.

Signed-off-by: Antti Palosaari 
---
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 135 
 drivers/media/usb/dvb-usb-v2/rtl28xxu.h |   4 +
 2 files changed, 108 insertions(+), 31 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 5ea52c7..d9ee1a9 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -24,6 +24,7 @@
 
 #include "rtl2830.h"
 #include "rtl2832.h"
+#include "mn88472.h"
 
 #include "qt1010.h"
 #include "mt2060.h"
@@ -420,6 +421,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
struct rtl28xxu_req req_tda18272 = {0x00c0, CMD_I2C_RD, 2, buf};
struct rtl28xxu_req req_r820t = {0x0034, CMD_I2C_RD, 1, buf};
struct rtl28xxu_req req_r828d = {0x0074, CMD_I2C_RD, 1, buf};
+   struct rtl28xxu_req req_mn88472 = {0xff38, CMD_I2C_RD, 1, buf};
 
dev_dbg(&d->udev->dev, "%s:\n", __func__);
 
@@ -449,7 +451,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0xa1) {
priv->tuner = TUNER_RTL2832_FC0012;
priv->tuner_name = "FC0012";
-   goto found;
+   goto tuner_found;
}
 
/* check FC0013 ID register; reg=00 val=a3 */
@@ -457,7 +459,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0xa3) {
priv->tuner = TUNER_RTL2832_FC0013;
priv->tuner_name = "FC0013";
-   goto found;
+   goto tuner_found;
}
 
/* check MT2266 ID register; reg=00 val=85 */
@@ -465,7 +467,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0x85) {
priv->tuner = TUNER_RTL2832_MT2266;
priv->tuner_name = "MT2266";
-   goto found;
+   goto tuner_found;
}
 
/* check FC2580 ID register; reg=01 val=56 */
@@ -473,7 +475,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0x56) {
priv->tuner = TUNER_RTL2832_FC2580;
priv->tuner_name = "FC2580";
-   goto found;
+   goto tuner_found;
}
 
/* check MT2063 ID register; reg=00 val=9e || 9c */
@@ -481,7 +483,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && (buf[0] == 0x9e || buf[0] == 0x9c)) {
priv->tuner = TUNER_RTL2832_MT2063;
priv->tuner_name = "MT2063";
-   goto found;
+   goto tuner_found;
}
 
/* check MAX3543 ID register; reg=00 val=38 */
@@ -489,7 +491,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0x38) {
priv->tuner = TUNER_RTL2832_MAX3543;
priv->tuner_name = "MAX3543";
-   goto found;
+   goto tuner_found;
}
 
/* check TUA9001 ID register; reg=7e val=2328 */
@@ -497,7 +499,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0x23 && buf[1] == 0x28) {
priv->tuner = TUNER_RTL2832_TUA9001;
priv->tuner_name = "TUA9001";
-   goto found;
+   goto tuner_found;
}
 
/* check MXL5007R ID register; reg=d9 val=14 */
@@ -505,7 +507,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0x14) {
priv->tuner = TUNER_RTL2832_MXL5007T;
priv->tuner_name = "MXL5007T";
-   goto found;
+   goto tuner_found;
}
 
/* check E4000 ID register; reg=02 val=40 */
@@ -513,7 +515,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0x40) {
priv->tuner = TUNER_RTL2832_E4000;
priv->tuner_name = "E4000";
-   goto found;
+   goto tuner_found;
}
 
/* check TDA18272 ID register; reg=00 val=c760  */
@@ -521,7 +523,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && (buf[0] == 0xc7 || buf[1] == 0x60)) {
priv->tuner = TUNER_RTL2832_TDA18272;
priv->tuner_name = "TDA18272";
-   goto found;
+   goto tuner_found;
}
 
/* check R820T ID register; reg=00 val=69 */
@@ -529,7 +531,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0x69) {
 

[PATCHv2 3/6] rtl28xxu: add support for Panasonic MN88473 slave demod

[Antti Palosaari]

There is RTL2832P devices having extra MN88473 demodulator. This
patch add support for such configuration. Logically MN88473 slave
demodulator is connected to RTL2832 master demodulator, both I2C
bus and TS input. RTL2832 is integrated to RTL2832U and RTL2832P
chips. Chip version RTL2832P has extra TS interface for connecting
slave demodulator.

Signed-off-by: Antti Palosaari 
---
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 31 +++
 drivers/media/usb/dvb-usb-v2/rtl28xxu.h |  3 ++-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index d9ee1a9..cb54d2a 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -25,6 +25,7 @@
 #include "rtl2830.h"
 #include "rtl2832.h"
 #include "mn88472.h"
+#include "mn88473.h"
 
 #include "qt1010.h"
 #include "mt2060.h"
@@ -422,6 +423,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
struct rtl28xxu_req req_r820t = {0x0034, CMD_I2C_RD, 1, buf};
struct rtl28xxu_req req_r828d = {0x0074, CMD_I2C_RD, 1, buf};
struct rtl28xxu_req req_mn88472 = {0xff38, CMD_I2C_RD, 1, buf};
+   struct rtl28xxu_req req_mn88473 = {0xff38, CMD_I2C_RD, 1, buf};
 
dev_dbg(&d->udev->dev, "%s:\n", __func__);
 
@@ -567,6 +569,13 @@ tuner_found:
priv->slave_demod = SLAVE_DEMOD_MN88472;
goto demod_found;
}
+
+   ret = rtl28xxu_ctrl_msg(d, &req_mn88473);
+   if (ret == 0 && buf[0] == 0x03) {
+   dev_dbg(&d->udev->dev, "%s: MN88473 found\n", __func__);
+   priv->slave_demod = SLAVE_DEMOD_MN88473;
+   goto demod_found;
+   }
}
 
 demod_found:
@@ -877,6 +886,28 @@ static int rtl2832u_frontend_attach(struct dvb_usb_adapter 
*adap)
}
 
priv->i2c_client_slave_demod = client;
+   } else {
+   struct mn88473_config mn88473_config = {};
+
+   mn88473_config.fe = &adap->fe[1];
+   mn88473_config.i2c_wr_max = 22,
+   strlcpy(info.type, "mn88473", I2C_NAME_SIZE);
+   info.addr = 0x18;
+   info.platform_data = &mn88473_config;
+   request_module(info.type);
+   client = i2c_new_device(priv->demod_i2c_adapter, &info);
+   if (client == NULL || client->dev.driver == NULL) {
+   priv->slave_demod = SLAVE_DEMOD_NONE;
+   goto err_slave_demod_failed;
+   }
+
+   if (!try_module_get(client->dev.driver->owner)) {
+   i2c_unregister_device(client);
+   priv->slave_demod = SLAVE_DEMOD_NONE;
+   goto err_slave_demod_failed;
+   }
+
+   priv->i2c_client_slave_demod = client;
}
}
 
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.h 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
index c1b00b9..7f959ff 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
@@ -61,7 +61,8 @@ struct rtl28xxu_priv {
struct i2c_client *i2c_client_slave_demod;
#define SLAVE_DEMOD_NONE   0
#define SLAVE_DEMOD_MN884721
-   unsigned int slave_demod:1;
+   #define SLAVE_DEMOD_MN884732
+   unsigned int slave_demod:2;
 };
 
 enum rtl28xxu_chip_id {
-- 
http://palosaari.fi/

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

Re: [REVIEW PATCH v2 0/5] Add V4L2_SEL_TGT_NATIVE_SIZE target

[Sakari Ailus]

On Tue, Nov 18, 2014 at 07:40:15AM +0200, Sakari Ailus wrote:
> since v2:

This obviously should have been v1.

Also a spelling fix in documentation has been included, as Hans suggested.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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

[REVIEW PATCH v2 06/11] smiapp: The sensor only needs a single clock, name may be NULL

[Sakari Ailus]

The SMIA compatible sensors only need a single clock.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/smiapp/smiapp-core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index ba05d97..b02fa64 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2484,7 +2484,7 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
}
 
if (!sensor->platform_data->set_xclk) {
-   sensor->ext_clk = devm_clk_get(&client->dev, "ext_clk");
+   sensor->ext_clk = devm_clk_get(&client->dev, NULL);
if (IS_ERR(sensor->ext_clk)) {
dev_err(&client->dev, "could not get clock\n");
return PTR_ERR(sensor->ext_clk);
-- 
1.7.10.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

[REVIEW PATCH v2 05/11] smiapp: Register async subdev

[Sakari Ailus]

Register and unregister async sub-device for DT.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/smiapp/smiapp-core.c |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index ab917a6..ba05d97 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2944,8 +2944,21 @@ static int smiapp_probe(struct i2c_client *client,
sensor->src->sensor = sensor;
 
sensor->src->pads[0].flags = MEDIA_PAD_FL_SOURCE;
-   return media_entity_init(&sensor->src->sd.entity, 2,
+   rval = media_entity_init(&sensor->src->sd.entity, 2,
 sensor->src->pads, 0);
+   if (rval < 0)
+   return rval;
+
+   rval = v4l2_async_register_subdev(&sensor->src->sd);
+   if (rval < 0)
+   goto out_media_entity_cleanup;
+
+   return 0;
+
+out_media_entity_cleanup:
+   media_entity_cleanup(&sensor->src->sd.entity);
+
+   return rval;
 }
 
 static int smiapp_remove(struct i2c_client *client)
@@ -2954,6 +2967,8 @@ static int smiapp_remove(struct i2c_client *client)
struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
unsigned int i;
 
+   v4l2_async_unregister_subdev(subdev);
+
if (sensor->power_count) {
if (gpio_is_valid(sensor->platform_data->xshutdown))
gpio_set_value(sensor->platform_data->xshutdown, 0);
-- 
1.7.10.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

[REVIEW PATCH v2 01/11] smiapp: Remove FSF's address from the license header

[Sakari Ailus]

Remove FSF's address information from the license header in the smiapp
driver and the smiapp-pll PLL calculator. This should no longer be needed,
and would be rendered outdated in case the FSF chooses to relocate its
office.

Signed-off-by: Sakari Ailus 
Cc: Timo Ahonen 
---
 drivers/media/i2c/smiapp-pll.c |6 --
 drivers/media/i2c/smiapp-pll.h |6 --
 drivers/media/i2c/smiapp/smiapp-core.c |6 --
 drivers/media/i2c/smiapp/smiapp-limits.c   |6 --
 drivers/media/i2c/smiapp/smiapp-limits.h   |6 --
 drivers/media/i2c/smiapp/smiapp-quirk.c|6 --
 drivers/media/i2c/smiapp/smiapp-quirk.h|6 --
 drivers/media/i2c/smiapp/smiapp-reg-defs.h |6 --
 drivers/media/i2c/smiapp/smiapp-reg.h  |6 --
 drivers/media/i2c/smiapp/smiapp-regs.c |6 --
 drivers/media/i2c/smiapp/smiapp-regs.h |6 --
 drivers/media/i2c/smiapp/smiapp.h  |6 --
 12 files changed, 72 deletions(-)

diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c
index e40d902..2b84d09 100644
--- a/drivers/media/i2c/smiapp-pll.c
+++ b/drivers/media/i2c/smiapp-pll.c
@@ -14,12 +14,6 @@
  * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
  */
 
 #include 
diff --git a/drivers/media/i2c/smiapp-pll.h b/drivers/media/i2c/smiapp-pll.h
index e8f035a..77f7ff2f 100644
--- a/drivers/media/i2c/smiapp-pll.h
+++ b/drivers/media/i2c/smiapp-pll.h
@@ -14,12 +14,6 @@
  * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
  */
 
 #ifndef SMIAPP_PLL_H
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 65e4e05..ab917a6 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -18,12 +18,6 @@
  * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
  */
 
 #include 
diff --git a/drivers/media/i2c/smiapp/smiapp-limits.c 
b/drivers/media/i2c/smiapp/smiapp-limits.c
index 847cb23..784b114 100644
--- a/drivers/media/i2c/smiapp/smiapp-limits.c
+++ b/drivers/media/i2c/smiapp/smiapp-limits.c
@@ -14,12 +14,6 @@
  * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
  */
 
 #include "smiapp.h"
diff --git a/drivers/media/i2c/smiapp/smiapp-limits.h 
b/drivers/media/i2c/smiapp/smiapp-limits.h
index 343e9c3..b201248 100644
--- a/drivers/media/i2c/smiapp/smiapp-limits.h
+++ b/drivers/media/i2c/smiapp/smiapp-limits.h
@@ -14,12 +14,6 @@
  * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
  */
 
 #define SMIAPP_LIMIT_ANALOGUE_GAIN_CAPABILITY  0
diff --git a/drivers/media/i2c/smiapp/smiapp-quirk.c 
b/drivers/media/i2c/smiapp/smiapp-quirk.c
index e0bee87..dd4ae6f 100644
--- a/drivers/media/i2c/smiapp/smiapp-quirk.c
+++ b/drivers/media/i2c/smiapp/smiapp-quirk.c
@@ -14,12 +14,6 @@
  * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
  */
 
 #include 
diff --git a/drivers/media/i2c/smiapp/smiapp-qui

[REVIEW PATCH v2 02/11] smiapp: List include/uapi/linux/smiapp.h in MAINTAINERS

[Sakari Ailus]

This is part of the smiapp driver.

Signed-off-by: Sakari Ailus 
---
 MAINTAINERS |1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a6288ca..2378a5f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8618,6 +8618,7 @@ F:drivers/media/i2c/smiapp/
 F: include/media/smiapp.h
 F: drivers/media/i2c/smiapp-pll.c
 F: drivers/media/i2c/smiapp-pll.h
+F: include/uapi/linux/smiapp.h
 
 SMM665 HARDWARE MONITOR DRIVER
 M: Guenter Roeck 
-- 
1.7.10.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

[REVIEW PATCH v2 10/11] smiapp: Split sub-device initialisation off from the registered callback

[Sakari Ailus]

The registered callback is called by the V4L2 async framework after the
bound callback. This allows separating the functionality in the registered
callback so that on DT based systems only sub-device registration is done
there.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/smiapp/smiapp-core.c |   83 +---
 1 file changed, 55 insertions(+), 28 deletions(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 899d32d..8663dfb 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2469,6 +2469,57 @@ static const struct v4l2_subdev_ops smiapp_ops;
 static const struct v4l2_subdev_internal_ops smiapp_internal_ops;
 static const struct media_entity_operations smiapp_entity_ops;
 
+static int smiapp_register_subdevs(struct v4l2_subdev *subdev)
+{
+   struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
+   struct i2c_client *client = v4l2_get_subdevdata(&sensor->src->sd);
+   struct smiapp_subdev *ssds[] = {
+   sensor->scaler,
+   sensor->binner,
+   sensor->pixel_array,
+   };
+   unsigned int i;
+   int rval;
+
+   for (i = 0; i < SMIAPP_SUBDEVS - 1; i++) {
+   struct smiapp_subdev *this = ssds[i + 1];
+   struct smiapp_subdev *last = ssds[i];
+
+   if (!last)
+   continue;
+
+   rval = media_entity_init(&this->sd.entity,
+this->npads, this->pads, 0);
+   if (rval) {
+   dev_err(&client->dev,
+   "media_entity_init failed\n");
+   return rval;
+   }
+
+   rval = media_entity_create_link(&this->sd.entity,
+   this->source_pad,
+   &last->sd.entity,
+   last->sink_pad,
+   MEDIA_LNK_FL_ENABLED |
+   MEDIA_LNK_FL_IMMUTABLE);
+   if (rval) {
+   dev_err(&client->dev,
+   "media_entity_create_link failed\n");
+   return rval;
+   }
+
+   rval = v4l2_device_register_subdev(sensor->src->sd.v4l2_dev,
+  &this->sd);
+   if (rval) {
+   dev_err(&client->dev,
+   "v4l2_device_register_subdev failed\n");
+   return rval;
+   }
+   }
+
+   return 0;
+}
+
 static int smiapp_registered(struct v4l2_subdev *subdev)
 {
struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
@@ -2707,37 +2758,13 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
this->sd.owner = THIS_MODULE;
v4l2_set_subdevdata(&this->sd, client);
 
-   rval = media_entity_init(&this->sd.entity,
-this->npads, this->pads, 0);
-   if (rval) {
-   dev_err(&client->dev,
-   "media_entity_init failed\n");
-   goto out_nvm_release;
-   }
-
-   rval = media_entity_create_link(&this->sd.entity,
-   this->source_pad,
-   &last->sd.entity,
-   last->sink_pad,
-   MEDIA_LNK_FL_ENABLED |
-   MEDIA_LNK_FL_IMMUTABLE);
-   if (rval) {
-   dev_err(&client->dev,
-   "media_entity_create_link failed\n");
-   goto out_nvm_release;
-   }
-
-   rval = v4l2_device_register_subdev(sensor->src->sd.v4l2_dev,
-  &this->sd);
-   if (rval) {
-   dev_err(&client->dev,
-   "v4l2_device_register_subdev failed\n");
-   goto out_nvm_release;
-   }
-
last = this;
}
 
+   rval = smiapp_register_subdevs(&sensor->src->sd);
+   if (rval)
+   goto out_nvm_release;
+
dev_dbg(&client->dev, "profile %d\n", sensor->minfo.smiapp_profile);
 
sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
-- 
1.7.10.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

[REVIEW PATCH v2 04/11] smiapp: Use types better suitable for DT

[Sakari Ailus]

Signed-off-by: Sakari Ailus 
---
 include/media/smiapp.h |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/media/smiapp.h b/include/media/smiapp.h
index 0b8f124..268a3cd 100644
--- a/include/media/smiapp.h
+++ b/include/media/smiapp.h
@@ -65,19 +65,19 @@ struct smiapp_platform_data {
unsigned short i2c_addr_dfl;/* Default i2c addr */
unsigned short i2c_addr_alt;/* Alternate i2c addr */
 
-   unsigned int nvm_size;  /* bytes */
-   unsigned int ext_clk;   /* sensor external clk */
+   uint32_t nvm_size;  /* bytes */
+   uint32_t ext_clk;   /* sensor external clk */
 
unsigned int lanes; /* Number of CSI-2 lanes */
-   u8 csi_signalling_mode; /* SMIAPP_CSI_SIGNALLING_MODE_* */
-   const s64 *op_sys_clock;
+   uint32_t csi_signalling_mode;   /* SMIAPP_CSI_SIGNALLING_MODE_* */
+   uint64_t *op_sys_clock;
 
enum smiapp_module_board_orient module_board_orient;
 
struct smiapp_flash_strobe_parms *strobe_setup;
 
int (*set_xclk)(struct v4l2_subdev *sd, int hz);
-   int xshutdown;  /* gpio or SMIAPP_NO_XSHUTDOWN */
+   int32_t xshutdown;  /* gpio or SMIAPP_NO_XSHUTDOWN */
 };
 
 #endif /* __SMIAPP_H_  */
-- 
1.7.10.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

[REVIEW PATCH v2 00/11] smiapp OF support

[Sakari Ailus]

Hi folks,

This patchset adds support for Device tree in the smiapp driver. Platform   
data support is retained as well. The actual DT related changes are 
prepended by a few simple cleanups. 

A new link-frequency property is defined in video-interfaces.txt, as this is
hardly something which is specific to the SMIA compliant sensors.   

since v1:

- Only use dev->of_node to determine whether the OF node is there.

- Add clock-lanes and data-lanes properties to mandatory properties list in
  documentation.

- Add a patch to include include/uapi/linux/smiapp.h in MAINTAINERS section
  for the smiapp driver.

-- 
Kind regards,
Sakari
--
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

[REVIEW PATCH v2 11/11] smiapp: Fully probe the device in probe

[Sakari Ailus]

In the case of platform data, ISPs that provide clocks to the sensor must
probe before the sensor does. Accessing the sensor does require the clocks,
and thus, probe cannot access the sensor in such a system.

This limitation does not exist in the case of the DT. Perform all
initialisation except Media entity initialisation, link creation and
sub-device registration in probe.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/smiapp/smiapp-core.c |   58 +++-
 1 file changed, 42 insertions(+), 16 deletions(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 8663dfb..5c85b89 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2520,7 +2520,16 @@ static int smiapp_register_subdevs(struct v4l2_subdev 
*subdev)
return 0;
 }
 
-static int smiapp_registered(struct v4l2_subdev *subdev)
+static void smiapp_subdev_cleanup(struct v4l2_subdev *subdev)
+{
+   struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
+   struct i2c_client *client = v4l2_get_subdevdata(&sensor->src->sd);
+
+   device_remove_file(&client->dev, &dev_attr_nvm);
+   device_remove_file(&client->dev, &dev_attr_ident);
+}
+
+static int smiapp_subdev_init(struct v4l2_subdev *subdev)
 {
struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
struct i2c_client *client = v4l2_get_subdevdata(subdev);
@@ -2649,13 +2658,13 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
if (sensor->nvm == NULL) {
dev_err(&client->dev, "nvm buf allocation failed\n");
rval = -ENOMEM;
-   goto out_ident_release;
+   goto out_cleanup;
}
 
if (device_create_file(&client->dev, &dev_attr_nvm) != 0) {
dev_err(&client->dev, "sysfs nvm entry failed\n");
rval = -EBUSY;
-   goto out_ident_release;
+   goto out_cleanup;
}
}
 
@@ -2699,7 +2708,7 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
rval = smiapp_get_mbus_formats(sensor);
if (rval) {
rval = -ENODEV;
-   goto out_nvm_release;
+   goto out_cleanup;
}
 
for (i = 0; i < SMIAPP_SUBDEVS; i++) {
@@ -2761,10 +2770,6 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
last = this;
}
 
-   rval = smiapp_register_subdevs(&sensor->src->sd);
-   if (rval)
-   goto out_nvm_release;
-
dev_dbg(&client->dev, "profile %d\n", sensor->minfo.smiapp_profile);
 
sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
@@ -2773,14 +2778,14 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
smiapp_read_frame_fmt(sensor);
rval = smiapp_init_controls(sensor);
if (rval < 0)
-   goto out_nvm_release;
+   goto out_cleanup;
 
mutex_lock(&sensor->mutex);
rval = smiapp_update_mode(sensor);
mutex_unlock(&sensor->mutex);
if (rval) {
dev_err(&client->dev, "update mode failed\n");
-   goto out_nvm_release;
+   goto out_cleanup;
}
 
sensor->streaming = false;
@@ -2790,23 +2795,38 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
rval = smiapp_read(sensor, SMIAPP_REG_U8_FLASH_MODE_CAPABILITY, &tmp);
sensor->flash_capability = tmp;
if (rval)
-   goto out_nvm_release;
+   goto out_cleanup;
 
smiapp_power_off(sensor);
 
return 0;
 
-out_nvm_release:
-   device_remove_file(&client->dev, &dev_attr_nvm);
-
-out_ident_release:
-   device_remove_file(&client->dev, &dev_attr_ident);
+out_cleanup:
+   smiapp_subdev_cleanup(&sensor->src->sd);
 
 out_power_off:
smiapp_power_off(sensor);
return rval;
 }
 
+static int smiapp_registered(struct v4l2_subdev *subdev)
+{
+   struct i2c_client *client = v4l2_get_subdevdata(subdev);
+   int rval;
+
+   if (!client->dev.of_node) {
+   rval = smiapp_subdev_init(subdev);
+   if (rval)
+   return rval;
+   }
+
+   rval = smiapp_register_subdevs(subdev);
+   if (rval)
+   smiapp_subdev_cleanup(subdev);
+
+   return rval;
+}
+
 static int smiapp_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
 {
struct smiapp_subdev *ssd = to_smiapp_subdev(sd);
@@ -3066,6 +3086,12 @@ static int smiapp_probe(struct i2c_client *client,
if (rval < 0)
return rval;
 
+   if (client->dev.of_node) {
+   rval = smiapp_subdev_init(&sensor->src->sd);
+   if (rval)
+   goto out_media_entity_cleanup;
+   }
+
rval = v4l2_async_register_subdev(&sensor->src->sd)

[REVIEW PATCH v2 08/11] of: smiapp: Add documentation

[Sakari Ailus]

Document the smiapp device tree properties.

Signed-off-by: Sakari Ailus 
Cc: devicet...@vger.kernel.org
---
 .../devicetree/bindings/media/i2c/nokia,smia.txt   |   68 
 MAINTAINERS|1 +
 2 files changed, 69 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/nokia,smia.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt 
b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
new file mode 100644
index 000..a0081f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
@@ -0,0 +1,68 @@
+SMIA/SMIA++ sensor
+
+SMIA (Standard Mobile Imaging Architecture) is an image sensor standard
+defined jointly by Nokia and ST. SMIA++, defined by Nokia, is an extension
+of that. These definitions are valid for both types of sensors.
+
+
+Mandatory properties
+
+
+- compatible: "nokia,smia"
+- reg: I2C address (0x10, or an alternative address)
+- vana-supply: Analogue voltage supply (VANA), typically 2,8 volts (sensor
+  dependent).
+- clocks: External clock phandle
+- clock-names: Name of the external clock
+- clock-frequency: Frequency of the external clock to the sensor
+- link-frequency: List of allowed data link frequencies. An array of 64-bit
+  elements.
+- clock-lanes: <0>
+- data-lanes: <1..n>
+
+
+Optional properties
+---
+
+- nokia,nvm-size: The size of the NVM, in bytes. If the size is not given,
+  the NVM contents will not be read.
+- reset-gpios: XSHUTDOWN GPIO
+
+
+Port node
+-
+
+These properties are mandatory in the port node:
+
+- clock-lanes: <0>
+- data-lanes: <1..n>
+
+More detailed port node documentation can be found in
+Documentation/devicetree/bindings/media/video-interfaces.txt .
+
+
+Example
+---
+
+&i2c2 {
+   clock-frequency = <40>;
+
+   smiapp_1: camera@10 {
+   compatible = "nokia,smia";
+   reg = <0x10>;
+   reset-gpios = <&gpio3 20 0>;
+   vana-supply = <&vaux3>;
+   clocks = <&omap3_isp 0>;
+   clock-names = "ext_clk";
+   clock-frequency = <960>;
+   nokia,nvm-size = <512>; /* 8 * 64 */
+   link-frequency = /bits/ 64 <19920 21000 49920>;
+   port {
+   smiapp_1_1: endpoint {
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   remote-endpoint = <&csi2a_ep>;
+   };
+   };
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 2378a5f..285c1ba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8619,6 +8619,7 @@ F:include/media/smiapp.h
 F: drivers/media/i2c/smiapp-pll.c
 F: drivers/media/i2c/smiapp-pll.h
 F: include/uapi/linux/smiapp.h
+F: Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
 
 SMM665 HARDWARE MONITOR DRIVER
 M: Guenter Roeck 
-- 
1.7.10.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

[REVIEW PATCH v2 07/11] of: v4l: Document link-frequency property in video-interfaces.txt

[Sakari Ailus]

link-frequency is a 64-bit unsigned integer array of allowed link
frequencies.

Signed-off-by: Sakari Ailus 
Cc: devicet...@vger.kernel.org
---
 Documentation/devicetree/bindings/media/video-interfaces.txt |3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index ce719f8..7d8f07f 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -103,6 +103,9 @@ Optional endpoint properties
   array contains only one entry.
 - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
   clock mode.
+- link-frequency: Allowed data bus frequencies. For MIPI CSI-2, for
+  instance, this is the actual frequency of the bus, not bits per clock per
+  lane value. An array of 64-bit unsigned integers.
 
 
 Example
-- 
1.7.10.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

[REVIEW PATCH v2 03/11] smiapp-pll: include linux/device.h in smiapp-pll.c, not in smiapp-pll.h

[Sakari Ailus]

struct device has a forward declaration in the header already. The header is
only needed in the .c file.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/smiapp-pll.c |1 +
 drivers/media/i2c/smiapp-pll.h |2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c
index 2b84d09..e3348db 100644
--- a/drivers/media/i2c/smiapp-pll.c
+++ b/drivers/media/i2c/smiapp-pll.c
@@ -16,6 +16,7 @@
  * General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/media/i2c/smiapp-pll.h b/drivers/media/i2c/smiapp-pll.h
index 77f7ff2f..b98d143 100644
--- a/drivers/media/i2c/smiapp-pll.h
+++ b/drivers/media/i2c/smiapp-pll.h
@@ -19,8 +19,6 @@
 #ifndef SMIAPP_PLL_H
 #define SMIAPP_PLL_H
 
-#include 
-
 /* CSI-2 or CCP-2 */
 #define SMIAPP_PLL_BUS_TYPE_CSI2   0x00
 #define SMIAPP_PLL_BUS_TYPE_PARALLEL   0x01
-- 
1.7.10.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

[REVIEW PATCH v2 09/11] smiapp: Obtain device information from the Device Tree if OF node exists

[Sakari Ailus]

Platform data support is retained.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/smiapp/smiapp-core.c |  100 +++-
 1 file changed, 98 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index b02fa64..899d32d 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -25,11 +25,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "smiapp.h"
 
@@ -2921,19 +2923,107 @@ static int smiapp_resume(struct device *dev)
 
 #endif /* CONFIG_PM */
 
+static struct smiapp_platform_data *smiapp_get_pdata(struct device *dev)
+{
+   struct smiapp_platform_data *pdata;
+   struct v4l2_of_endpoint bus_cfg;
+   struct device_node *ep;
+   uint32_t asize;
+   int rval;
+
+   if (!dev->of_node)
+   return dev->platform_data;
+
+   ep = of_graph_get_next_endpoint(dev->of_node, NULL);
+   if (!ep)
+   return NULL;
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   rval = -ENOMEM;
+   goto out_err;
+   }
+
+   v4l2_of_parse_endpoint(ep, &bus_cfg);
+
+   switch (bus_cfg.bus_type) {
+   case V4L2_MBUS_CSI2:
+   pdata->csi_signalling_mode = SMIAPP_CSI_SIGNALLING_MODE_CSI2;
+   break;
+   /* FIXME: add CCP2 support. */
+   default:
+   rval = -EINVAL;
+   goto out_err;
+   }
+
+   pdata->lanes = bus_cfg.bus.mipi_csi2.num_data_lanes;
+   dev_dbg(dev, "lanes %u\n", pdata->lanes);
+
+   /* xshutdown GPIO is optional */
+   pdata->xshutdown = of_get_named_gpio(dev->of_node, "reset-gpios", 0);
+
+   /* NVM size is not mandatory */
+   of_property_read_u32(dev->of_node, "nokia,nvm-size",
+   &pdata->nvm_size);
+
+   rval = of_property_read_u32(dev->of_node, "clock-frequency",
+   &pdata->ext_clk);
+   if (rval) {
+   dev_warn(dev, "can't get clock-frequency\n");
+   goto out_err;
+   }
+
+   dev_dbg(dev, "reset %d, nvm %d, clk %d, csi %d\n", pdata->xshutdown,
+   pdata->nvm_size, pdata->ext_clk, pdata->csi_signalling_mode);
+
+   rval = of_get_property(
+   dev->of_node, "link-frequency", &asize) ? 0 : -ENOENT;
+   if (rval) {
+   dev_warn(dev, "can't get link-frequency array size\n");
+   goto out_err;
+   }
+
+   pdata->op_sys_clock = devm_kzalloc(dev, asize, GFP_KERNEL);
+   if (!pdata->op_sys_clock) {
+   rval = -ENOMEM;
+   goto out_err;
+   }
+
+   asize /= sizeof(*pdata->op_sys_clock);
+   rval = of_property_read_u64_array(
+   dev->of_node, "link-frequency", pdata->op_sys_clock, asize);
+   if (rval) {
+   dev_warn(dev, "can't get link-frequency\n");
+   goto out_err;
+   }
+
+   for (; asize > 0; asize--)
+   dev_dbg(dev, "freq %d: %lld\n", asize - 1,
+   pdata->op_sys_clock[asize - 1]);
+
+   of_node_put(ep);
+   return pdata;
+
+out_err:
+   of_node_put(ep);
+   return NULL;
+}
+
 static int smiapp_probe(struct i2c_client *client,
const struct i2c_device_id *devid)
 {
struct smiapp_sensor *sensor;
+   struct smiapp_platform_data *pdata = smiapp_get_pdata(&client->dev);
+   int rval;
 
-   if (client->dev.platform_data == NULL)
+   if (pdata == NULL)
return -ENODEV;
 
sensor = devm_kzalloc(&client->dev, sizeof(*sensor), GFP_KERNEL);
if (sensor == NULL)
return -ENOMEM;
 
-   sensor->platform_data = client->dev.platform_data;
+   sensor->platform_data = pdata;
mutex_init(&sensor->mutex);
mutex_init(&sensor->power_mutex);
sensor->src = &sensor->ssds[sensor->ssds_used];
@@ -2992,6 +3082,11 @@ static int smiapp_remove(struct i2c_client *client)
return 0;
 }
 
+static const struct of_device_id smiapp_of_table[] = {
+   { .compatible = "nokia,smia" },
+   { },
+};
+
 static const struct i2c_device_id smiapp_id_table[] = {
{ SMIAPP_NAME, 0 },
{ },
@@ -3005,6 +3100,7 @@ static const struct dev_pm_ops smiapp_pm_ops = {
 
 static struct i2c_driver smiapp_i2c_driver = {
.driver = {
+   .of_match_table = smiapp_of_table,
.name = SMIAPP_NAME,
.pm = &smiapp_pm_ops,
},
-- 
1.7.10.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

[REVIEW PATCH v2 2/5] v4l: Add V4L2_SEL_TGT_NATIVE_SIZE selection target

[Sakari Ailus]

The V4L2_SEL_TGT_NATIVE_SIZE target is used to denote e.g. the size of a
sensor's pixel array.

Signed-off-by: Sakari Ailus 
---
 Documentation/DocBook/media/v4l/selections-common.xml |   10 ++
 include/uapi/linux/v4l2-common.h  |2 ++
 2 files changed, 12 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/selections-common.xml 
b/Documentation/DocBook/media/v4l/selections-common.xml
index 7502f78..99c984c 100644
--- a/Documentation/DocBook/media/v4l/selections-common.xml
+++ b/Documentation/DocBook/media/v4l/selections-common.xml
@@ -63,6 +63,16 @@
Yes
  
  
+   V4L2_SEL_TGT_NATIVE_SIZE
+   0x0003
+   The native size of the device, e.g. a sensor's
+   pixel array. top and
+   left fields are zero for this target.
+   
+   Yes
+   Yes
+ 
+ 
V4L2_SEL_TGT_COMPOSE
0x0100
Compose rectangle. Used to configure scaling
diff --git a/include/uapi/linux/v4l2-common.h b/include/uapi/linux/v4l2-common.h
index 2f6f8ca..1527398 100644
--- a/include/uapi/linux/v4l2-common.h
+++ b/include/uapi/linux/v4l2-common.h
@@ -43,6 +43,8 @@
 #define V4L2_SEL_TGT_CROP_DEFAULT  0x0001
 /* Cropping bounds */
 #define V4L2_SEL_TGT_CROP_BOUNDS   0x0002
+/* Native frame size */
+#define V4L2_SEL_TGT_NATIVE_SIZE   0x0003
 /* Current composing area */
 #define V4L2_SEL_TGT_COMPOSE   0x0100
 /* Default composing area */
-- 
1.7.10.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

[REVIEW PATCH v2 1/5] v4l: Clean up sub-device format documentation

[Sakari Ailus]

The sub-device format documentation documented scaling configuration through
formats. Instead the compose selection rectangle is elsewhere documented to
be used for the purpose. Remove scaling related part of the documentation.

Signed-off-by: Sakari Ailus 
---
 Documentation/DocBook/media/v4l/dev-subdev.xml |  108 ++--
 1 file changed, 62 insertions(+), 46 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml 
b/Documentation/DocBook/media/v4l/dev-subdev.xml
index d15aaf8..c129196 100644
--- a/Documentation/DocBook/media/v4l/dev-subdev.xml
+++ b/Documentation/DocBook/media/v4l/dev-subdev.xml
@@ -195,53 +195,59 @@
Sample Pipeline Configuration

  
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
  

  
- Sensor/0
- Frontend/0
- Frontend/1
- Scaler/0
- Scaler/1
+ Sensor/0 format
+ Frontend/0 format
+ Frontend/1 format
+ Scaler/0 format
+ Scaler/0 compose selection rectangle
+ Scaler/1 format

  
  

  Initial state
- 2048x1536
- -
- -
- -
- -
+ 2048x1536/SGRBG8_1X8
+ (default)
+ (default)
+ (default)
+ (default)
+ (default)


- Configure frontend input
- 2048x1536
- 2048x1536
- 2046x1534
- -
- -
+ Configure frontend sink format
+ 2048x1536/SGRBG8_1X8
+ 2048x1536/SGRBG8_1X8
+ 2046x1534/SGRBG8_1X8
+ (default)
+ (default)
+ (default)


- Configure scaler input
- 2048x1536
- 2048x1536
- 2046x1534
- 2046x1534
- 2046x1534
+ Configure scaler sink format
+ 2048x1536/SGRBG8_1X8
+ 2048x1536/SGRBG8_1X8
+ 2046x1534/SGRBG8_1X8
+ 2046x1534/SGRBG8_1X8
+ 0,0/2046x1534
+ 2046x1534/SGRBG8_1X8


- Configure scaler output
- 2048x1536
- 2048x1536
- 2046x1534
- 2046x1534
- 1280x960
+ Configure scaler sink compose selection
+ 2048x1536/SGRBG8_1X8
+ 2048x1536/SGRBG8_1X8
+ 2046x1534/SGRBG8_1X8
+ 2046x1534/SGRBG8_1X8
+ 0,0/1280x960
+ 1280x960/SGRBG8_1X8

  

@@ -249,19 +255,29 @@
 
   
   
-   Initial state. The sensor output is set to its native 
3MP
-   resolution. Resolutions on the host frontend and scaler input and output
-   pads are undefined.
-   The application configures the frontend input pad 
resolution to
-   2048x1536. The driver propagates the format to the frontend output pad.
-   Note that the propagated output format can be different, as in this 
case,
-   than the input format, as the hardware might need to crop pixels (for
-   instance when converting a Bayer filter pattern to RGB or 
YUV).
-   The application configures the scaler input pad 
resolution to
-   2046x1534 to match the frontend output resolution. The driver propagates
-   the format to the scaler output pad.
-   The application configures the scaler output pad 
resolution to
-   1280x960.
+   Initial state. The sensor source pad format is
+   set to its native 3MP size and V4L2_MBUS_FMT_SGRBG8_1X8
+   media bus code. Formats on the host frontend and scaler sink
+   and source pads have the default values, as well as the
+   compose rectangle on the scaler's sink pad.
+
+   The application configures the frontend sink
+   pad format's size to 2048x1536 and its media bus code to
+   V4L2_MBUS_FMT_SGRBG_1X8. The driver propagates the format to
+   the frontend source pad.
+
+   The application configures the scaler sink pad
+   format's size to 2046x1534 and the media bus code to
+   V4L2_MBUS_FMT_SGRBG_1X8 to match the frontend source size and
+   media bus code. The media bus code on the sink pad is set to
+   V4L2_MBUS_FMT_SGRBG_1X8. The driver propagates the size to the
+   compose selection rectangle on the scaler's sink pad, and the
+   format to the scaler source pad.
+
+   The application configures the compose
+   selection rectangle of the scaler's sink pad and scaler source
+   pad format's size to 1280x960.
+
   
   
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majo

[REVIEW PATCH v2 3/5] v4l: Add intput and output capability flags for native size setting

[Sakari Ailus]

Add input and output capability flags for setting native size of the device,
and document them.

Signed-off-by: Sakari Ailus 
---
 Documentation/DocBook/media/v4l/vidioc-enuminput.xml  |8 
 Documentation/DocBook/media/v4l/vidioc-enumoutput.xml |8 
 include/uapi/linux/videodev2.h|2 ++
 3 files changed, 18 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/vidioc-enuminput.xml 
b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
index 493a39a..603fece 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
@@ -287,6 +287,14 @@ input/output interface to linux-media@vger.kernel.org on 
19 Oct 2009.
0x0004
This input supports setting the TV standard by using 
VIDIOC_S_STD.
  
+ 
+   V4L2_IN_CAP_NATIVE_SIZE
+   0x0008
+   This input supports setting the native size using
+   the V4L2_SEL_TGT_NATIVE_SIZE
+   selection target, see .
+ 

   
 
diff --git a/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml 
b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
index 2654e09..773fb12 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
@@ -172,6 +172,14 @@ input/output interface to linux-media@vger.kernel.org on 
19 Oct 2009.
0x0004
This output supports setting the TV standard by using 
VIDIOC_S_STD.
  
+ 
+   V4L2_OUT_CAP_NATIVE_SIZE
+   0x0008
+   This output supports setting the native size using
+   the V4L2_SEL_TGT_NATIVE_SIZE
+   selection target, see .
+ 

   
 
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 1c2f84f..e445b48 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1249,6 +1249,7 @@ struct v4l2_input {
 #define V4L2_IN_CAP_DV_TIMINGS 0x0002 /* Supports S_DV_TIMINGS */
 #define V4L2_IN_CAP_CUSTOM_TIMINGS V4L2_IN_CAP_DV_TIMINGS /* For 
compatibility */
 #define V4L2_IN_CAP_STD0x0004 /* Supports S_STD */
+#define V4L2_IN_CAP_NATIVE_SIZE0x0008 /* Supports setting 
native size */
 
 /*
  * V I D E O   O U T P U T S
@@ -1272,6 +1273,7 @@ struct v4l2_output {
 #define V4L2_OUT_CAP_DV_TIMINGS0x0002 /* Supports 
S_DV_TIMINGS */
 #define V4L2_OUT_CAP_CUSTOM_TIMINGSV4L2_OUT_CAP_DV_TIMINGS /* For 
compatibility */
 #define V4L2_OUT_CAP_STD   0x0004 /* Supports S_STD */
+#define V4L2_OUT_CAP_NATIVE_SIZE   0x0008 /* Supports setting native 
size */
 
 /*
  * C O N T R O L S
-- 
1.7.10.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

[REVIEW PATCH v2 0/5] Add V4L2_SEL_TGT_NATIVE_SIZE target

[Sakari Ailus]

Hi all,

This small set cleans up sub-device format documentation --- the
documentation noted the source format is used to configure scaling, which   
was contradicting what was said right after on the selections on
sub-devices. This part was written before the selections interface. 

The two latter patches create a V4L2_SEL_TGT_NATIVE_SIZE target which is
used in the smiapp driver. The CROP_BOUNDS target is still supported as 
compatibility means.

since v2:

- Document that left and top are zero for the native size target.

- Add a patch to zero left and top in the smiapp driver.

- Add a patch to document native size setting input and output capability
  flags.

-- 
Kind regards,
Sakari

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

[REVIEW PATCH v2 4/5] smiapp: Set left and top to zero for crop bounds selection

[Sakari Ailus]

The fields were previously uninitialised, leaving the returned values to
where the user had set them. This was never the intention.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/smiapp/smiapp-core.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 193af1c..022ad44 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2191,6 +2191,7 @@ static int __smiapp_get_selection(struct v4l2_subdev 
*subdev,
switch (sel->target) {
case V4L2_SEL_TGT_CROP_BOUNDS:
if (ssd == sensor->pixel_array) {
+   sel->r.left = sel->r.top = 0;
sel->r.width =
sensor->limits[SMIAPP_LIMIT_X_ADDR_MAX] + 1;
sel->r.height =
-- 
1.7.10.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

[REVIEW PATCH v2 5/5] smiapp: Support V4L2_SEL_TGT_NATIVE_SIZE

[Sakari Ailus]

Add support for selection target V4L2_SEL_TGT_NATIVE_SIZE. It is equivalent
of what V4L2_SEL_TGT_CROP_BOUNDS used to be. Support for
V4L2_SEL_TGT_CROP_BOUNDS is still supported by the driver as a compatibility
interface.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/smiapp/smiapp-core.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 022ad44..65e4e05 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2092,6 +2092,11 @@ static int __smiapp_sel_supported(struct v4l2_subdev 
*subdev,
== SMIAPP_DIGITAL_CROP_CAPABILITY_INPUT_CROP)
return 0;
return -EINVAL;
+   case V4L2_SEL_TGT_NATIVE_SIZE:
+   if (ssd == sensor->pixel_array
+   && sel->pad == SMIAPP_PA_PAD_SRC)
+   return 0;
+   return -EINVAL;
case V4L2_SEL_TGT_COMPOSE:
case V4L2_SEL_TGT_COMPOSE_BOUNDS:
if (sel->pad == ssd->source_pad)
@@ -2190,6 +2195,7 @@ static int __smiapp_get_selection(struct v4l2_subdev 
*subdev,
 
switch (sel->target) {
case V4L2_SEL_TGT_CROP_BOUNDS:
+   case V4L2_SEL_TGT_NATIVE_SIZE:
if (ssd == sensor->pixel_array) {
sel->r.left = sel->r.top = 0;
sel->r.width =
-- 
1.7.10.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

cron job: media_tree daily build: OK

[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 Nov 18 04:00:15 CET 2014
git branch: test
git hash:   c02ef64aab828d80040b5dce934729312e698c33
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-35-gc1c3f96
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:3.17-2.slh.2-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: OK
linux-2.6.33.7-i686: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16-i686: OK
linux-3.17-i686: OK
linux-3.18-rc1-i686: OK
linux-2.6.32.27-x86_64: OK
linux-2.6.33.7-x86_64: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16-x86_64: OK
linux-3.17-x86_64: OK
linux-3.18-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

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

[PATCH] [media] s2255drv: fix payload size for JPG, MJPEG

[Dean Anderson]

Signed-off-by: Dean Anderson 
---
 drivers/media/usb/s2255/s2255drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/s2255/s2255drv.c 
b/drivers/media/usb/s2255/s2255drv.c
index a56a05b..82014bb 100644
--- a/drivers/media/usb/s2255/s2255drv.c
+++ b/drivers/media/usb/s2255/s2255drv.c
@@ -635,7 +635,7 @@ static void s2255_fillbuff(struct s2255_vc *vc,
break;
case V4L2_PIX_FMT_JPEG:
case V4L2_PIX_FMT_MJPEG:
-   buf->vb.v4l2_buf.length = jpgsize;
+   vb2_set_plane_payload(&buf->vb, 0, jpgsize);
memcpy(vbuf, tmpbuf, jpgsize);
break;
case V4L2_PIX_FMT_YUV422P:
-- 
1.9.1

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

Re: Using the coda driver with Gstreamer

[Fabio Estevam]

Hi Robert,

On Mon, Nov 17, 2014 at 4:55 PM, Robert Schwebel
 wrote:

> Philipp is on vacation this week, he can have a look when he is back in
> the office next monday.

Thanks for letting me know.

> Just a wild guess - we usually test here with dmabuf capable devices and
> without X. As you are using gstglimagesink, the code around
> ext/gl/gstglimagesink.c (453) looks like gst_gl_context_create() went
> wrong. Does your GL work correctly? Maybe you can test the glimagesink
> with a simpler pipeline first.

Yes, maybe it would be better to remove X from my initial tests. I
will give it a try.

Thanks for the suggestions.

Regards,

Fabio Estevam
--
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: Using the coda driver with Gstreamer

[Robert Schwebel]

Hi Fabio,

On Mon, Nov 17, 2014 at 03:29:17PM -0200, Fabio Estevam wrote:
> I am running linux-next 20141117 on a mx6qsabresd board and trying to
> play a mp4 video via Gstreamer 1.4.1, but I am getting the following
> error:
> 
> root@imx6qsabresd:/mnt/nfs# gst-play-1.0 sample.mp4
> Volume: 100%
> Now playing /mnt/nfs/sample.mp4
> [  506.983809] [ cut here ]
> [  506.988522] WARNING: CPU: 0 PID: 954 at
> drivers/media/v4l2-core/videobuf2-core.c:1781
> vb2_start_streaming+0xc4/0x160()
> [  506.999301] Modules linked in:
> [  507.002489] CPU: 0 PID: 954 Comm: multiqueue0:src Tainted: G
> W  3.18.0-rc4-next-20141117-dirty #2044
> [  507.012660] Backtrace:
> [  507.015253] [<80011f44>] (dump_backtrace) from [<800120e0>]
> (show_stack+0x18/0x1c)
> [  507.022891]  r6:06f5 r5: r4: r3:
> [  507.028707] [<800120c8>] (show_stack) from [<806b730c>]
> (dump_stack+0x88/0xa4)
> [  507.035954] [<806b7284>] (dump_stack) from [<8002a4dc>]
> (warn_slowpath_common+0x80/0xbc)
> [  507.044135]  r5:804a80a8 r4:
> [  507.047802] [<8002a45c>] (warn_slowpath_common) from [<8002a53c>]
> (warn_slowpath_null+0x24/0x2c)
> [  507.056605]  r8: r7:bd71c640 r6:bd614ef0 r5:bd614ee0 r4:ffea
> [  507.063470] [<8002a518>] (warn_slowpath_null) from [<804a80a8>]
> (vb2_start_streaming+0xc4/0x160)
> [  507.072293] [<804a7fe4>] (vb2_start_streaming) from [<804a9efc>]
> (vb2_internal_streamon+0xfc/0x158)
> [  507.081385]  r7:bd71c640 r6:bd6c29ec r5:bd614c00 r4:bd614de0
> [  507.087133] [<804a9e00>] (vb2_internal_streamon) from [<804ab0a8>]
> (vb2_streamon+0x34/0x58)
> [  507.095567]  r5:bd614c00 r4:0002
> [  507.099231] [<804ab074>] (vb2_streamon) from [<804a3b10>]
> (v4l2_m2m_streamon+0x28/0x40)
> [  507.107287] [<804a3ae8>] (v4l2_m2m_streamon) from [<804a3b40>]
> (v4l2_m2m_ioctl_streamon+0x18/0x1c)
> [  507.116292]  r5:bd9083c8 r4:40045612
> [  507.120016] [<804a3b28>] (v4l2_m2m_ioctl_streamon) from
> [<80492e48>] (v4l_streamon+0x20/0x24)
> [  507.128693] [<80492e28>] (v4l_streamon) from [<80494dc4>]
> (__video_do_ioctl+0x24c/0x2e0)
> [  507.136826] [<80494b78>] (__video_do_ioctl) from [<804953a8>]
> (video_usercopy+0x118/0x480)
> [  507.145133]  r10:0001 r9:bd6cbe10 r8:74a1164c r7:
> r6: r5:80494b78
> [  507.153073]  r4:40045612
> [  507.155632] [<80495290>] (video_usercopy) from [<80495724>]
> (video_ioctl2+0x14/0x1c)
> [  507.163408]  r10:bd8fccb8 r9:74a1164c r8:bd909064 r7:74a1164c
> r6:40045612 r5:bd71c640
> [  507.171343]  r4:bd9083c8
> [  507.173902] [<80495710>] (video_ioctl2) from [<804918f8>]
> (v4l2_ioctl+0x104/0x14c)
> [  507.181512] [<804917f4>] (v4l2_ioctl) from [<800fc944>]
> (do_vfs_ioctl+0x80/0x634)
> [  507.189019]  r8:0009 r7:74a1164c r6:0009 r5:800fcf34
> r4:bd71c640 r3:804917f4
> [  507.196870] [<800fc8c4>] (do_vfs_ioctl) from [<800fcf34>]
> (SyS_ioctl+0x3c/0x60)
> [  507.204203]  r10: r9:bd6ca000 r8:0009 r7:74a1164c
> r6:40045612 r5:bd71c640
> [  507.212159]  r4:bd71c641
> [  507.214722] [<800fcef8>] (SyS_ioctl) from [<8000ec60>]
> (ret_fast_syscall+0x0/0x48)
> [  507.222311]  r8:8000ee24 r7:0036 r6:73c183a0 r5:754248e0
> r4: r3:
> [  507.230168] ---[ end trace c3703a604edaf0d0 ]---
> ERROR Failed to connect to X display server for file:///mnt/nfs/sample.mp4
> ERROR debug information:
> /code/yocto/dizzy/build/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-bad/1.4.1-r0/gst-plugins-bad-1.4.1/ext/gl/gstglimagesink.c(453):
> _ensure_gl_setup ():
> /GstPlayBin:playbin/GstPlaySink:playsink/GstBin:vbin/GstGLImageSink:glimagesink0
> GLib (gthread-posix.c): Unexpected error from C library during
> 'pthread_mutex_lock': Invalid argument.  Aborting.
> Aborted
> 
> Any suggestions?

Philipp is on vacation this week, he can have a look when he is back in
the office next monday.

Just a wild guess - we usually test here with dmabuf capable devices and
without X. As you are using gstglimagesink, the code around
ext/gl/gstglimagesink.c (453) looks like gst_gl_context_create() went
wrong. Does your GL work correctly? Maybe you can test the glimagesink
with a simpler pipeline first.

rsc <- being no gst expert
-- 
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

Re: Using the coda driver with Gstreamer

[Fabio Estevam]

Hi Andrey,

On Mon, Nov 17, 2014 at 3:48 PM, Andrey Utkin
 wrote:
> could you give `lspci -v` so that i see what module is a driver for
> that component?

I am using a mx6 processor that has a built-in hardware video
encoder/decoder. The driver is located at drivers/media/platform/coda/

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: Using the coda driver with Gstreamer

[Fabio Estevam]

Hi Nicolas,

On Mon, Nov 17, 2014 at 3:45 PM, Nicolas Dufresne
 wrote:
> Note, I'm only commenting about the GStreamer side...
>
> Le 2014-11-17 12:29, Fabio Estevam a écrit :
>> Hi,
>>
>> I am running linux-next 20141117 on a mx6qsabresd board and trying to
>> play a mp4 video via Gstreamer 1.4.1, but I am getting the following
>> error:
> You should update to latest stable version, this is a general rule. Not
> keeping track of stable branches is never a good idea. Current stable is
> 1.4.4.

Ok, let me upgrade Gstreamer to 1.4.4.

>> ERROR Failed to connect to X display server for file:///mnt/nfs/sample.mp4
> You have built glimagesink (hence libgstgl, part of gst-plugins-bad)
> against X11 but you don't have a X11 display running, or DISPLAY
> environment isn't set properly.

Yes, let me fix this first.

Thanks,

Fabio Estevam
--
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: Using the coda driver with Gstreamer

[Andrey Utkin]

could you give `lspci -v` so that i see what module is a driver for
that component?

Try playing to same device with recent ffmpeg: ffmpeg -i sample.mp4
-codec copy -f v4l2 -y /dev/videoWhatYouHave
and check if you have the same kernel warning.

-- 
Bluecherry developer.
--
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: Using the coda driver with Gstreamer

[Nicolas Dufresne]

Note, I'm only commenting about the GStreamer side...

Le 2014-11-17 12:29, Fabio Estevam a écrit :
> Hi,
>
> I am running linux-next 20141117 on a mx6qsabresd board and trying to
> play a mp4 video via Gstreamer 1.4.1, but I am getting the following
> error:
You should update to latest stable version, this is a general rule. Not
keeping track of stable branches is never a good idea. Current stable is
1.4.4.

Note that as of today, there is known issue with supporting this driver
(not that driver itself, I really mean supporting the driver features):

- Need to fix EOS Handling,
https://bugzilla.gnome.org/show_bug.cgi?id=733864
- Output size negotiation https://bugzilla.gnome.org/show_bug.cgi?id=733828
- Output pixel format negotiation
https://bugzilla.gnome.org/show_bug.cgi?id=733827
- Encoding is not yet supported
https://bugzilla.gnome.org/show_bug.cgi?id=728438

First one is the main blocker, but kernel folks will be able to clarify
more. Help is of course appreciated. Note that some of the issues kind
of lack a specification to accomplished. We recently had a meeting in
Dusseldorf to propose solutions.

>
> root@imx6qsabresd:/mnt/nfs# gst-play-1.0 sample.mp4
> Volume: 100%
> Now playing /mnt/nfs/sample.mp4
> [  506.983809] [ cut here ]
> [  506.988522] WARNING: CPU: 0 PID: 954 at
> drivers/media/v4l2-core/videobuf2-core.c:1781
> vb2_start_streaming+0xc4/0x160()
> [  506.999301] Modules linked in:
> [  507.002489] CPU: 0 PID: 954 Comm: multiqueue0:src Tainted: G
> W  3.18.0-rc4-next-20141117-dirty #2044
> [  507.012660] Backtrace:
> [  507.015253] [<80011f44>] (dump_backtrace) from [<800120e0>]
> (show_stack+0x18/0x1c)
> [  507.022891]  r6:06f5 r5: r4: r3:
> [  507.028707] [<800120c8>] (show_stack) from [<806b730c>]
> (dump_stack+0x88/0xa4)
> [  507.035954] [<806b7284>] (dump_stack) from [<8002a4dc>]
> (warn_slowpath_common+0x80/0xbc)
> [  507.044135]  r5:804a80a8 r4:
> [  507.047802] [<8002a45c>] (warn_slowpath_common) from [<8002a53c>]
> (warn_slowpath_null+0x24/0x2c)
> [  507.056605]  r8: r7:bd71c640 r6:bd614ef0 r5:bd614ee0 r4:ffea
> [  507.063470] [<8002a518>] (warn_slowpath_null) from [<804a80a8>]
> (vb2_start_streaming+0xc4/0x160)
> [  507.072293] [<804a7fe4>] (vb2_start_streaming) from [<804a9efc>]
> (vb2_internal_streamon+0xfc/0x158)
> [  507.081385]  r7:bd71c640 r6:bd6c29ec r5:bd614c00 r4:bd614de0
> [  507.087133] [<804a9e00>] (vb2_internal_streamon) from [<804ab0a8>]
> (vb2_streamon+0x34/0x58)
> [  507.095567]  r5:bd614c00 r4:0002
> [  507.099231] [<804ab074>] (vb2_streamon) from [<804a3b10>]
> (v4l2_m2m_streamon+0x28/0x40)
> [  507.107287] [<804a3ae8>] (v4l2_m2m_streamon) from [<804a3b40>]
> (v4l2_m2m_ioctl_streamon+0x18/0x1c)
> [  507.116292]  r5:bd9083c8 r4:40045612
> [  507.120016] [<804a3b28>] (v4l2_m2m_ioctl_streamon) from
> [<80492e48>] (v4l_streamon+0x20/0x24)
> [  507.128693] [<80492e28>] (v4l_streamon) from [<80494dc4>]
> (__video_do_ioctl+0x24c/0x2e0)
> [  507.136826] [<80494b78>] (__video_do_ioctl) from [<804953a8>]
> (video_usercopy+0x118/0x480)
> [  507.145133]  r10:0001 r9:bd6cbe10 r8:74a1164c r7:
> r6: r5:80494b78
> [  507.153073]  r4:40045612
> [  507.155632] [<80495290>] (video_usercopy) from [<80495724>]
> (video_ioctl2+0x14/0x1c)
> [  507.163408]  r10:bd8fccb8 r9:74a1164c r8:bd909064 r7:74a1164c
> r6:40045612 r5:bd71c640
> [  507.171343]  r4:bd9083c8
> [  507.173902] [<80495710>] (video_ioctl2) from [<804918f8>]
> (v4l2_ioctl+0x104/0x14c)
> [  507.181512] [<804917f4>] (v4l2_ioctl) from [<800fc944>]
> (do_vfs_ioctl+0x80/0x634)
> [  507.189019]  r8:0009 r7:74a1164c r6:0009 r5:800fcf34
> r4:bd71c640 r3:804917f4
> [  507.196870] [<800fc8c4>] (do_vfs_ioctl) from [<800fcf34>]
> (SyS_ioctl+0x3c/0x60)
> [  507.204203]  r10: r9:bd6ca000 r8:0009 r7:74a1164c
> r6:40045612 r5:bd71c640
> [  507.212159]  r4:bd71c641
> [  507.214722] [<800fcef8>] (SyS_ioctl) from [<8000ec60>]
> (ret_fast_syscall+0x0/0x48)
> [  507.222311]  r8:8000ee24 r7:0036 r6:73c183a0 r5:754248e0
> r4: r3:
> [  507.230168] ---[ end trace c3703a604edaf0d0 ]---
Looks like a backtrace of a warning, though I'm not sure I get what this
warning is about. Maybe you are missing some information, or one need to
look at videobuf2-core.c:178.
> ERROR Failed to connect to X display server for file:///mnt/nfs/sample.mp4
You have built glimagesink (hence libgstgl, part of gst-plugins-bad)
against X11 but you don't have a X11 display running, or DISPLAY
environment i

Re: patchwork on solo6x10: fix a race in IRQ handler

[Hans Verkuil]

On 11/17/2014 05:47 PM, Andrey Utkin wrote:
> Dear linux-media maintainers, I fail to do `git am` on mbox-formatted
> patch downloadable from https://patchwork.linuxtv.org/patch/26970/
> so i worry if the Krzyztof's patch i resubmitted is well-formed, and
> whether you are fine with integration of this patch to media_tree and
> further to upstream. Please let me know if there you experience any
> issues with that.
> 

I plan to merge it Friday. It's in my TODO list.

Regards,

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

Using the coda driver with Gstreamer

[Fabio Estevam]

Hi,

I am running linux-next 20141117 on a mx6qsabresd board and trying to
play a mp4 video via Gstreamer 1.4.1, but I am getting the following
error:

root@imx6qsabresd:/mnt/nfs# gst-play-1.0 sample.mp4
Volume: 100%
Now playing /mnt/nfs/sample.mp4
[  506.983809] [ cut here ]
[  506.988522] WARNING: CPU: 0 PID: 954 at
drivers/media/v4l2-core/videobuf2-core.c:1781
vb2_start_streaming+0xc4/0x160()
[  506.999301] Modules linked in:
[  507.002489] CPU: 0 PID: 954 Comm: multiqueue0:src Tainted: G
W  3.18.0-rc4-next-20141117-dirty #2044
[  507.012660] Backtrace:
[  507.015253] [<80011f44>] (dump_backtrace) from [<800120e0>]
(show_stack+0x18/0x1c)
[  507.022891]  r6:06f5 r5: r4: r3:
[  507.028707] [<800120c8>] (show_stack) from [<806b730c>]
(dump_stack+0x88/0xa4)
[  507.035954] [<806b7284>] (dump_stack) from [<8002a4dc>]
(warn_slowpath_common+0x80/0xbc)
[  507.044135]  r5:804a80a8 r4:
[  507.047802] [<8002a45c>] (warn_slowpath_common) from [<8002a53c>]
(warn_slowpath_null+0x24/0x2c)
[  507.056605]  r8: r7:bd71c640 r6:bd614ef0 r5:bd614ee0 r4:ffea
[  507.063470] [<8002a518>] (warn_slowpath_null) from [<804a80a8>]
(vb2_start_streaming+0xc4/0x160)
[  507.072293] [<804a7fe4>] (vb2_start_streaming) from [<804a9efc>]
(vb2_internal_streamon+0xfc/0x158)
[  507.081385]  r7:bd71c640 r6:bd6c29ec r5:bd614c00 r4:bd614de0
[  507.087133] [<804a9e00>] (vb2_internal_streamon) from [<804ab0a8>]
(vb2_streamon+0x34/0x58)
[  507.095567]  r5:bd614c00 r4:0002
[  507.099231] [<804ab074>] (vb2_streamon) from [<804a3b10>]
(v4l2_m2m_streamon+0x28/0x40)
[  507.107287] [<804a3ae8>] (v4l2_m2m_streamon) from [<804a3b40>]
(v4l2_m2m_ioctl_streamon+0x18/0x1c)
[  507.116292]  r5:bd9083c8 r4:40045612
[  507.120016] [<804a3b28>] (v4l2_m2m_ioctl_streamon) from
[<80492e48>] (v4l_streamon+0x20/0x24)
[  507.128693] [<80492e28>] (v4l_streamon) from [<80494dc4>]
(__video_do_ioctl+0x24c/0x2e0)
[  507.136826] [<80494b78>] (__video_do_ioctl) from [<804953a8>]
(video_usercopy+0x118/0x480)
[  507.145133]  r10:0001 r9:bd6cbe10 r8:74a1164c r7:
r6: r5:80494b78
[  507.153073]  r4:40045612
[  507.155632] [<80495290>] (video_usercopy) from [<80495724>]
(video_ioctl2+0x14/0x1c)
[  507.163408]  r10:bd8fccb8 r9:74a1164c r8:bd909064 r7:74a1164c
r6:40045612 r5:bd71c640
[  507.171343]  r4:bd9083c8
[  507.173902] [<80495710>] (video_ioctl2) from [<804918f8>]
(v4l2_ioctl+0x104/0x14c)
[  507.181512] [<804917f4>] (v4l2_ioctl) from [<800fc944>]
(do_vfs_ioctl+0x80/0x634)
[  507.189019]  r8:0009 r7:74a1164c r6:0009 r5:800fcf34
r4:bd71c640 r3:804917f4
[  507.196870] [<800fc8c4>] (do_vfs_ioctl) from [<800fcf34>]
(SyS_ioctl+0x3c/0x60)
[  507.204203]  r10: r9:bd6ca000 r8:0009 r7:74a1164c
r6:40045612 r5:bd71c640
[  507.212159]  r4:bd71c641
[  507.214722] [<800fcef8>] (SyS_ioctl) from [<8000ec60>]
(ret_fast_syscall+0x0/0x48)
[  507.222311]  r8:8000ee24 r7:0036 r6:73c183a0 r5:754248e0
r4: r3:
[  507.230168] ---[ end trace c3703a604edaf0d0 ]---
ERROR Failed to connect to X display server for file:///mnt/nfs/sample.mp4
ERROR debug information:
/code/yocto/dizzy/build/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-bad/1.4.1-r0/gst-plugins-bad-1.4.1/ext/gl/gstglimagesink.c(453):
_ensure_gl_setup ():
/GstPlayBin:playbin/GstPlaySink:playsink/GstBin:vbin/GstGLImageSink:glimagesink0
GLib (gthread-posix.c): Unexpected error from C library during
'pthread_mutex_lock': Invalid argument.  Aborting.
Aborted

Any suggestions?

Thanks,

Fabio Estevam
--
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] Update MAINTAINERS for solo6x10

[Andrey Utkin]

Signed-off-by: Andrey Utkin 
---
 MAINTAINERS | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index bb38f02..f5cef1b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8787,7 +8787,9 @@ S:Maintained
 F: drivers/leds/leds-net48xx.c
 
 SOFTLOGIC 6x10 MPEG CODEC
-M: Ismael Luceno 
+M: Bluecherry Maintainers 
+M: Andrey Utkin 
+M: Andrey Utkin 
 L: linux-media@vger.kernel.org
 S: Supported
 F: drivers/media/pci/solo6x10/
-- 
2.0.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

patchwork on solo6x10: fix a race in IRQ handler

[Andrey Utkin]

Dear linux-media maintainers, I fail to do `git am` on mbox-formatted
patch downloadable from https://patchwork.linuxtv.org/patch/26970/
so i worry if the Krzyztof's patch i resubmitted is well-formed, and
whether you are fine with integration of this patch to media_tree and
further to upstream. Please let me know if there you experience any
issues with that.

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

Is it fair to say that the Terratec S7 does not in fact work with DVB-S2?

[mpdcband]

I have a Terratec S7 USB device(actually an Elgato EyeTV Sat). This
works fine on a Mac Mini running EyeTV. It doesn't seem to scan DVB-S2
channels at all under Linux-DVB. I've noticed numerous messages in the
mailing list archive documenting problems with this device in regards to
S2. The only maintenance that seems to occur on the driver for this
device is to periodically update the list of identification strings for
this device.

So, because I want to use Linux-DVB for receiving DVB-S2 channels I have
the following questions:

   1) Is the Terratec S7 (in its many guises) actually supported at all
by either Terratec or someone else for use with DVB-S2 under linux-dvb?
And are there any cases where the device actually works under linux-dvb
as well as it does on a Mac or Windows system? 

   2) If not, are there in fact any devices for DVB-S2 with drivers that
are fully supported in linux-dvb and that in fact work on DVB-S2
channels with the utilities found in linux-dvb? (If there are I'd get
rid of my Terratec S7 and get something else).

   3) Or, is it not the case that there is any (active) support at all
in the linux-dvb community for DVB-S2 (perhaps because interest is
focused on different modulation methods and transmission types)?

Thanks for any information you can impart regarding this.

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

git.linuxtv.org repos refuse to fetch

[Andrey Utkin]

This happens always, and I noticed it quite long time ago. At the
moment I have 1 mbit internet link, but AFAIR it was the same with
much bigger bandwidth.

20:17:06krieger@zver /usr/local/src/linux-next
 $ git remote add verk_media_tree git://linuxtv.org/hverkuil/media_tree.git
[OK]
20:17:16krieger@zver /usr/local/src/linux-next
 $ git fetch verk_media_tree
fatal: read error: Connection reset by peer
[ERR]


"git clone" seems to work, at last it starts; but i haven't done full
clone from it yet, at the moment i've started it and now it is
"counting objects".
-- 
Andrey Utkin
--
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/3] tuners: si2157: Si2148 support.

[Michael Holzer]

Hi Olli,

re ' we start to have quite a list of chips there in the printouts
(Si2147/Si2148/Si2157/Si2158) and
more is coming -...
Should we just say "Si214x/Si215x" there or something?'

I'd see merit to show the supported chips explicitly as otherwise users
may be confused if a new unsupported chip  (lets assume Si2159)
appears and the message is generic as proposed "Si215x".
To get clarity for this case source code reading would be required.
 just my 5 cent ;-)
Mike
--
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: (bisected) Logitech C920 (uvcvideo) stutters since 3.9

[Grazvydas Ignotas]

On Thu, Nov 6, 2014 at 12:29 AM, Grazvydas Ignotas  wrote:
> On Wed, Nov 5, 2014 at 4:05 PM, Laurent Pinchart
>  wrote:
>> Hi Rémi,
>>
>> On Tuesday 04 November 2014 22:41:44 Rémi Denis-Courmont wrote:
>>> Le mardi 04 novembre 2014, 15:42:37 Rémi Denis-Courmont a écrit :
>>> > Le 2014-11-04 14:58, Sakari Ailus a écrit :
>>> > >> > Have you tried with a different application to see if the problem
>>> > >> > persists?
>>> > >>
>>> > >> Tried mplayer and cheese now, and it seems they are not affected, so
>>> > >> it's an issue with vlc. I wonder why it doesn't like newer flags..
>>> > >>
>>> > >> Ohwell, sorry for the noise.
>>> > >
>>> > > I guess the newer VLC could indeed pay attention to the monotonic
>>> > > timestamp flag. Remi, any idea?
>>> >
>>> > VLC takes the kernel timestamp, if monotonic, since version 2.1.
>>> > Otherwise, it generates its own inaccurate timestamp. So either that
>>> > code is wrong, or the kernel timestamps are.
>>>
>>> From a quick check with C920, the timestamps from the kernel are quite
>>> jittery, and but seem to follow a pattern. When requesting a 10 Hz frame
>>> rate, I actually get a frame interval of about 8/9 (i.e. 89ms) jumping to
>>> 1/3 every approximately 2 seconds.
>>>
>>> From my user-space point of view, this is a kernel issue. The problem
>>> probably just manifests when both VLC and Linux versions support monotonic
>>> timestamps.
>>>
>>> Whether the root cause is in the kernel, the device driver or the firmware,
>>> I can´t say.
>>
>> Would you be able to capture images from the C920 using yavta, with the
>> uvcvideo trace parameter set to 4096, and send me both the yavta log and the
>> kernel log ? Let's start with a capture sequence of 50 to 100 images.
>
> I've done 2 captures, if that helps:
> http://notaz.gp2x.de/tmp/c920_yavta/
>
> The second one was done using low exposure setting, which allows
> camera to achieve higher frame rate.

So, has anyone had time to look at these?

Gražvydas
--
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] Add RGB444_1X12 and RGB565_1X16 media bus formats

[Sakari Ailus]

Hi Boris,

On Sun, Nov 16, 2014 at 09:24:38AM +0100, Boris Brezillon wrote:
> Add RGB444_1X12 and RGB565_1X16 format definitions and update the
> documentation.
> 
> Signed-off-by: Boris Brezillon 
> Acked-by: Mauro Carvalho Chehab 
> ---
> Changes since v1:
> - keep BPP and bits per sample ordering
> 
>  Documentation/DocBook/media/v4l/subdev-formats.xml | 40 
> ++
>  include/uapi/linux/media-bus-format.h  |  4 ++-
>  2 files changed, 43 insertions(+), 1 deletion(-)

Acked-by: Sakari Ailus 

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Pali Rohár]

On Monday 17 November 2014 16:06:17 Tony Lindgren wrote:
> * Pali Rohár  [141117 07:03]:
> > On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
> > > There's nothing stopping us from initializing the camera
> > > code from pdata-quirks.c for now to keep it working.
> > > Certainly the binding should be added to the driver, but
> > > that removes a dependency to the legacy booting mode if
> > > things are otherwise working.
> > 
> > Tony, legacy board code for n900 is not in mainline tree.
> > And that omap3 camera subsystem for n900 is broken since
> > 3.5 kernel... (both Front and Back camera on n900 show only
> > green picture).
> 
> I'm still seeing the legacy board code for n900 in mainline
> tree :) It's deprecated, but still there.
> 

Yes, it is there because conversion from board code to DT is not 
complete yet... It is slow progress but you can watch it on page 
http://elinux.org/N900 (last two columns).

> Are you maybe talking about some other piece of platform_data
> that's no longer in the mainline kernel?
> 

Yes, about platform_data which were never in mainline kernel. 
Just only in other trees. That code is: camera subsystem (with 
all other devices), cellular modem, bluetooth, radio.

> No idea what might be wrong with the camera though.
> 
> Regards,
> 
> Tony

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: [PATCH 2/3] v4l: Add V4L2_SEL_TGT_NATIVE_SIZE selection target

[Sakari Ailus]

Hi Hans,

On Mon, Nov 17, 2014 at 10:34:37AM +0100, Hans Verkuil wrote:
> On 11/16/2014 05:40 PM, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > Thank you for the review.
> > 
> > On Fri, Nov 14, 2014 at 09:46:54AM +0100, Hans Verkuil wrote:
> >> On 11/09/2014 12:04 AM, Sakari Ailus wrote:
> >>> The V4L2_SEL_TGT_NATIVE_SIZE target is used to denote e.g. the size of a
> >>> sensor's pixel array.
> >>>
> >>> Signed-off-by: Sakari Ailus 
> >>> ---
> >>>  Documentation/DocBook/media/v4l/selections-common.xml |8 
> >>>  include/uapi/linux/v4l2-common.h  |2 ++
> >>>  2 files changed, 10 insertions(+)
> >>>
> >>> diff --git a/Documentation/DocBook/media/v4l/selections-common.xml 
> >>> b/Documentation/DocBook/media/v4l/selections-common.xml
> >>> index 7502f78..5fc833a 100644
> >>> --- a/Documentation/DocBook/media/v4l/selections-common.xml
> >>> +++ b/Documentation/DocBook/media/v4l/selections-common.xml
> >>> @@ -63,6 +63,14 @@
> >>>   Yes
> >>> 
> >>> 
> >>> + V4L2_SEL_TGT_NATIVE_SIZE
> >>> + 0x0003
> >>> + The native size of the device, e.g. a sensor's
> >>> + pixel array.
> >>
> >> You might want to state that top and left are always 0.
> > 
> > Fixed. I also added a patch to fix this in the smiapp driver --- the values
> > were uninitialised. :-P
> > 
> >>> + Yes
> >>> + Yes
> >>> +   
> >>> +   
> >>>   V4L2_SEL_TGT_COMPOSE
> >>>   0x0100
> >>>   Compose rectangle. Used to configure scaling
> >>> diff --git a/include/uapi/linux/v4l2-common.h 
> >>> b/include/uapi/linux/v4l2-common.h
> >>> index 2f6f8ca..1527398 100644
> >>> --- a/include/uapi/linux/v4l2-common.h
> >>> +++ b/include/uapi/linux/v4l2-common.h
> >>> @@ -43,6 +43,8 @@
> >>>  #define V4L2_SEL_TGT_CROP_DEFAULT0x0001
> >>>  /* Cropping bounds */
> >>>  #define V4L2_SEL_TGT_CROP_BOUNDS 0x0002
> >>> +/* Native frame size */
> >>> +#define V4L2_SEL_TGT_NATIVE_SIZE 0x0003
> >>>  /* Current composing area */
> >>>  #define V4L2_SEL_TGT_COMPOSE 0x0100
> >>>  /* Default composing area */
> >>>
> >>
> >> I like this. This would also make it possible to set the 'canvas' size of 
> >> an
> >> mem2mem device. Currently calling S_FMT for a mem2mem device cannot setup 
> >> any
> >> scaler since there is no native size. Instead S_FMT effectively *sets* the 
> >> native
> >> size. The same is true for webcams with a scaler, which is why you added 
> >> this in
> >> the first place. Obviously for sensors this target is read-only, but for a 
> >> mem2mem
> >> device it can be writable as well.
> >>
> >> However, to make full use of this you also need to add input and output
> >> capabilities if the native size can be set:
> >>
> >>V4L2_IN_CAP_NATIVE_SIZE
> >>V4L2_OUT_CAP_NATIVE_SIZE
> > 
> > Do you think this would require a capability flag, rather than just
> > returning an error if the target is unsettable, as we otherwise already do
> > if a selection target isn't supported? For the compound controls it's even
> > easier, you just don't have a read-only flag set in the equivalent control.
> 
> No, I really want a capability flag here. Otherwise applications would have to
> call ENUMINPUT *and* call G_SELECTION followed by S_SELECTION just to test if
> it can be set. Besides, this is also a per-input capability, so you want to 
> get
> hold of the capabilities without having to do a S_INPUT first. I.e. you don't
> want to have to do this:
> 
>   // pseudo code just to give the idea
>   for (i = 0; i < max_input; i++) {
>   struct v4l2_selection sel = { NATIVE_SIZE };
> 
>   ioctl(S_INPUT, i);
>   ioctl(G_SELECTION, &sel);
>   if (ioctl(S_SELECTION, &sel))
>   // does not support NATIVE_SIZE
>   }

Fair enough. I'll add a patch for that.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Pali Rohár]

On Monday 17 November 2014 16:04:07 Sakari Ailus wrote:
> Hi Pali,
> 
> On Mon, Nov 17, 2014 at 04:01:31PM +0100, Pali Rohár wrote:
> > On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
> > > * Pavel Machek  [141117 02:17]:
> > > > On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
> > > > > On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
> > > > > > Hi!
> > > > > > 
> > > > > > On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> > > > > > > On Sunday 16 November 2014 08:59:28 Pavel Machek 
wrote:
> > > > > > > > For device tree people: Yes, I know I'll have to
> > > > > > > > create file in documentation, but does the
> > > > > > > > binding below look acceptable?
> > > > > > > > 
> > > > > > > > I'll clean up driver code a bit more, remove the
> > > > > > > > printks. Anything else obviously wrong?
> > > > > > > 
> > > > > > > I think that this patch is probably not good and
> > > > > > > specially not for n900. adp1653 should be
> > > > > > > registered throw omap3 isp camera subsystem which
> > > > > > > does not have DT support yet.
> > > > > > 
> > > > > > Can you explain?
> > > > > > 
> > > > > > adp1653 is independend device on i2c bus, and we
> > > > > > have kernel driver for it (unlike rest of n900
> > > > > > camera system). Just now it is unusable due to lack
> > > > > > of DT binding. It has two functions, LED light and
> > > > > > a camera flash; yes, the second one should be
> > > > > > integrated to the rest of camera system, but that
> > > > > > is not yet merged. That should not prevent us from
> > > > > > merging DT support for the flash, so that this part
> > > > > > can be tested/maintained.
> > > > > 
> > > > > Ok. When ISP camera subsystem has DT support somebody
> > > > > will modify n900 DT to add camera flash from adp1653
> > > > > to ISP... I believe it will not be hard.
> > > > 
> > > > Exactly. And yes, I'd like to get complete camera
> > > > support for n900 merged. But first step is "make sure
> > > > existing support does not break".
> > > 
> > > There's nothing stopping us from initializing the camera
> > > code from pdata-quirks.c for now to keep it working.
> > > Certainly the binding should be added to the driver, but
> > > that removes a dependency to the legacy booting mode if
> > > things are otherwise working.
> > > 
> > > Regards,
> > > 
> > > Tony
> > 
> > Tony, legacy board code for n900 is not in mainline tree.
> > And that omap3 camera subsystem for n900 is broken since
> > 3.5 kernel... (both Front and Back camera on n900 show only
> > green picture).
> 
> Can you capture raw bayer images correctly? I assume green
> means YUV buffers that are all zero.
> 
> Do you know more specifically which patch breaks it?

CCing freemangordon (Ivaylo Dimitrov). He tried to debug it 
months ago but without success. Should know more info about this 
problem.

I think that commit which broke it was not bisected...

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Tony Lindgren]

* Pali Rohár  [141117 07:03]:
> On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
> > 
> > There's nothing stopping us from initializing the camera code
> > from pdata-quirks.c for now to keep it working. Certainly the
> > binding should be added to the driver, but that removes a
> > dependency to the legacy booting mode if things are otherwise
> > working.
> 
> Tony, legacy board code for n900 is not in mainline tree. And 
> that omap3 camera subsystem for n900 is broken since 3.5 
> kernel... (both Front and Back camera on n900 show only green 
> picture).

I'm still seeing the legacy board code for n900 in mainline tree :)
It's deprecated, but still there.

Are you maybe talking about some other piece of platform_data that's
no longer in the mainline kernel?

No idea what might be wrong with the camera though.

Regards,

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

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Sakari Ailus]

Hi Pali,

On Mon, Nov 17, 2014 at 04:01:31PM +0100, Pali Rohár wrote:
> On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
> > * Pavel Machek  [141117 02:17]:
> > > On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
> > > > On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
> > > > > Hi!
> > > > > 
> > > > > On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> > > > > > On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> > > > > > > For device tree people: Yes, I know I'll have to
> > > > > > > create file in documentation, but does the binding
> > > > > > > below look acceptable?
> > > > > > > 
> > > > > > > I'll clean up driver code a bit more, remove the
> > > > > > > printks. Anything else obviously wrong?
> > > > > > 
> > > > > > I think that this patch is probably not good and
> > > > > > specially not for n900. adp1653 should be registered
> > > > > > throw omap3 isp camera subsystem which does not have
> > > > > > DT support yet.
> > > > > 
> > > > > Can you explain?
> > > > > 
> > > > > adp1653 is independend device on i2c bus, and we have
> > > > > kernel driver for it (unlike rest of n900 camera
> > > > > system). Just now it is unusable due to lack of DT
> > > > > binding. It has two functions, LED light and a camera
> > > > > flash; yes, the second one should be integrated to the
> > > > > rest of camera system, but that is not yet merged. That
> > > > > should not prevent us from merging DT support for the
> > > > > flash, so that this part can be tested/maintained.
> > > > 
> > > > Ok. When ISP camera subsystem has DT support somebody will
> > > > modify n900 DT to add camera flash from adp1653 to ISP...
> > > > I believe it will not be hard.
> > > 
> > > Exactly. And yes, I'd like to get complete camera support
> > > for n900 merged. But first step is "make sure existing
> > > support does not break".
> > 
> > There's nothing stopping us from initializing the camera code
> > from pdata-quirks.c for now to keep it working. Certainly the
> > binding should be added to the driver, but that removes a
> > dependency to the legacy booting mode if things are otherwise
> > working.
> > 
> > Regards,
> > 
> > Tony
> 
> Tony, legacy board code for n900 is not in mainline tree. And 
> that omap3 camera subsystem for n900 is broken since 3.5 
> kernel... (both Front and Back camera on n900 show only green 
> picture).

Can you capture raw bayer images correctly? I assume green means YUV buffers
that are all zero.

Do you know more specifically which patch breaks it?

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Pali Rohár]

On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
> * Pavel Machek  [141117 02:17]:
> > On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
> > > On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
> > > > Hi!
> > > > 
> > > > On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> > > > > On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> > > > > > For device tree people: Yes, I know I'll have to
> > > > > > create file in documentation, but does the binding
> > > > > > below look acceptable?
> > > > > > 
> > > > > > I'll clean up driver code a bit more, remove the
> > > > > > printks. Anything else obviously wrong?
> > > > > 
> > > > > I think that this patch is probably not good and
> > > > > specially not for n900. adp1653 should be registered
> > > > > throw omap3 isp camera subsystem which does not have
> > > > > DT support yet.
> > > > 
> > > > Can you explain?
> > > > 
> > > > adp1653 is independend device on i2c bus, and we have
> > > > kernel driver for it (unlike rest of n900 camera
> > > > system). Just now it is unusable due to lack of DT
> > > > binding. It has two functions, LED light and a camera
> > > > flash; yes, the second one should be integrated to the
> > > > rest of camera system, but that is not yet merged. That
> > > > should not prevent us from merging DT support for the
> > > > flash, so that this part can be tested/maintained.
> > > 
> > > Ok. When ISP camera subsystem has DT support somebody will
> > > modify n900 DT to add camera flash from adp1653 to ISP...
> > > I believe it will not be hard.
> > 
> > Exactly. And yes, I'd like to get complete camera support
> > for n900 merged. But first step is "make sure existing
> > support does not break".
> 
> There's nothing stopping us from initializing the camera code
> from pdata-quirks.c for now to keep it working. Certainly the
> binding should be added to the driver, but that removes a
> dependency to the legacy booting mode if things are otherwise
> working.
> 
> Regards,
> 
> Tony

Tony, legacy board code for n900 is not in mainline tree. And 
that omap3 camera subsystem for n900 is broken since 3.5 
kernel... (both Front and Back camera on n900 show only green 
picture).

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Sakari Ailus]

Hi Pavel,

On Sun, Nov 16, 2014 at 08:59:28AM +0100, Pavel Machek wrote:
> For device tree people: Yes, I know I'll have to create file in
> documentation, but does the binding below look acceptable?
> 
> I'll clean up driver code a bit more, remove the printks. Anything
> else obviously wrong?

Jacek Anaszewski is working on flash support for LED devices. I think it'd
be good to sync the DT bindings for the two, as the types of devices
supported by the LED API and the V4L2 flash API are quite similar.

Cc Jacek.

> Signed-off-by: Pavel Machek 
> 
> Thanks,
>   Pavel
> 
> 
> diff --git a/arch/arm/boot/dts/omap3-n900.dts 
> b/arch/arm/boot/dts/omap3-n900.dts
> index 739fcf2..ed0bfc1 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -553,6 +561,18 @@
>  
>   ti,usb-charger-detection = <&isp1704>;
>   };
> +
> + adp1653: adp1653@30 {
> + compatible = "ad,adp1653";
> + reg = <0x30>;
> +
> + max-flash-timeout-usec = <50>;
> + max-flash-intensity-uA= <32>;
> + max-torch-intensity-uA = <5>;
> + max-indicator-intensity-uA = <17500>;
> +
> + gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* Want 88 */
> + };
>  };
>  
>  &i2c3 {
> diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
> index 873fe19..e21ed02 100644
> --- a/drivers/media/i2c/adp1653.c
> +++ b/drivers/media/i2c/adp1653.c
> @@ -8,6 +8,7 @@
>   * Contributors:
>   *   Sakari Ailus 
>   *   Tuukka Toivonen 
> + *  Pavel Machek 
>   *
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License
> @@ -34,9 +35,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> +#include 
> +
>  #define TIMEOUT_MAX  82
>  #define TIMEOUT_STEP 54600
>  #define TIMEOUT_MIN  (TIMEOUT_MAX - ADP1653_REG_CONFIG_TMR_SET_MAX \
> @@ -308,7 +316,16 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
>  {
>   int ret;
>  
> - ret = flash->platform_data->power(&flash->subdev, on);
> + if (flash->platform_data->power)
> + ret = flash->platform_data->power(&flash->subdev, on);
> + else {
> + gpio_set_value(flash->platform_data->power_gpio, on);
> + if (on) {
> + /* Some delay is apparently required. */
> + udelay(20);
> + }
> + }
> + 
>   if (ret < 0)
>   return ret;
>  
> @@ -316,8 +333,13 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
>   return 0;
>  
>   ret = adp1653_init_device(flash);
> - if (ret < 0)
> + if (ret >= 0)
> + return ret;
> +
> + if (flash->platform_data->power)
>   flash->platform_data->power(&flash->subdev, 0);
> + else
> + gpio_set_value(flash->platform_data->power_gpio, 0);
>  
>   return ret;
>  }
> @@ -407,21 +429,87 @@ static int adp1653_resume(struct device *dev)
>  
>  #endif /* CONFIG_PM */
>  
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +static int adp1653_of_init(struct i2c_client *client, struct adp1653_flash 
> *flash, 
> +struct device_node *node)
> +{
> + u32 val;
> + struct adp1653_platform_data *pd;
> + enum of_gpio_flags flags;
> + int gpio;
> +
> + if (!node)
> + return -EINVAL;
> +
> + printk("adp1653: no platform data\n");
> + pd = devm_kzalloc(&client->dev, sizeof(*pd), GFP_KERNEL);
> + if (!pd)
> + return -ENOMEM;
> + flash->platform_data = pd;
> +
> +
> +
> +
> +
> +
> +
> + if (of_property_read_u32(node, "max-flash-timeout-usec", &val)) return 
> -EINVAL;
> + pd->max_flash_timeout = val;
> + if (of_property_read_u32(node, "max-flash-intensity-uA", &val)) return 
> -EINVAL;
> + pd->max_flash_intensity = val/1000;
> + if (of_property_read_u32(node, "max-torch-intensity-uA", &val)) return 
> -EINVAL;
> + pd->max_torch_intensity = val/1000;
> + if (of_property_read_u32(node, "max-indicator-intensity-uA", &val)) 
> return -EINVAL;
> + pd->max_indicator_intensity = val;
> +
> + if (!of_find_property(node, "gpios", NULL)) {
> + printk("No gpio node\n");
> + return -EINVAL;
> + }
> +
> + gpio = of_get_gpio_flags(node, 0, &flags);
> + if (gpio < 0) {
> + printk("Error getting GPIO\n"); 
> + return -EINVAL;
> + }
> +
> + pd->power_gpio = gpio;
> +
> + return 0;
> +}
> +
> +
>  static int adp1653_probe(struct i2c_client *client,
>const struct i2c_device_id *devid)
>  {
>   struct adp1653_flash *flash;
>   int ret;
>  
> - /* we couldn't work without platform data */
> - if (client->dev.platform_data == NUL

Re: staging: media: lirc: lirc_zilog.c: replace custom print macros with dev_* and pr_*

[Mauro Carvalho Chehab]

Em Sun, 9 Nov 2014 21:35:17 +
Sean Young  escreveu:

> On Thu, Nov 06, 2014 at 08:56:47AM -0500, Andy Walls wrote:
> > On November 6, 2014 8:54:28 AM EST, Andy Walls  
> > wrote:
> > >Sean,
> > >
> > >Ir-kbd-i2c was never intended for Tx.
> > >
> > >You can transmit *short* arbitrary pulse-space streams with the zilog
> > >chip, by feeding it a parameter block that has the pulse timing
> > >information and then subsequently has been obfuscated.  The firmware
> > >file that LIRC uses in userspace is full of predefined versions of
> > >these things for RC5 and NEC IIRC.  This LIRC firmware file also holds
> > >the (de)obfuscation key.
> > >
> > >I've got a bunch of old notes on this stuff from essentially reverse
> > >engineering the firmware in the Z8.  IANAL, but to me, its use in
> > >developing in-kernel stuff could be dubious.
> > >
> > >Regards,
> > >Andy
> 
> Very interesting.
> 
> I had considered reverse engineering the z8 firmware but I never found a
> way to access it. I guess we have three options:
> 
> 1. I could use Andy's notes to implement Tx. I have not seen the original
>firmware code so I'm not contaminated by reverse engineering it. IANAL 
>but I thought this is an acceptable way of writing a driver.
> 
> 2. Hauppauge could prove us with documentation to write a driver with.

I tried to get some info about that, but they are unable to get anything
related to this design so far.

So, I think that, if you have some time to dedicate to it, the best would
be to go for  option #1.

> 3. Leave it as-is, lirc_zilog will eventually be deleted from staging as it
>can't be ported to rc-core.
> 
> 
> Sean
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Tony Lindgren]

* Pavel Machek  [141117 02:17]:
> On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
> > On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
> > > Hi!
> > > 
> > > On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> > > > On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> > > > > For device tree people: Yes, I know I'll have to create
> > > > > file in documentation, but does the binding below look
> > > > > acceptable?
> > > > > 
> > > > > I'll clean up driver code a bit more, remove the printks.
> > > > > Anything else obviously wrong?
> > > > 
> > > > I think that this patch is probably not good and specially
> > > > not for n900. adp1653 should be registered throw omap3 isp
> > > > camera subsystem which does not have DT support yet.
> > > 
> > > Can you explain?
> > > 
> > > adp1653 is independend device on i2c bus, and we have kernel
> > > driver for it (unlike rest of n900 camera system). Just now
> > > it is unusable due to lack of DT binding. It has two
> > > functions, LED light and a camera flash; yes, the second one
> > > should be integrated to the rest of camera system, but that
> > > is not yet merged. That should not prevent us from merging DT
> > > support for the flash, so that this part can be
> > > tested/maintained.
> > > 
> > 
> > Ok. When ISP camera subsystem has DT support somebody will modify 
> > n900 DT to add camera flash from adp1653 to ISP... I believe it 
> > will not be hard.
> 
> Exactly. And yes, I'd like to get complete camera support for n900
> merged. But first step is "make sure existing support does not break".

There's nothing stopping us from initializing the camera code from
pdata-quirks.c for now to keep it working. Certainly the binding
should be added to the driver, but that removes a dependency to
the legacy booting mode if things are otherwise working.

Regards,

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

WARNING: CPU: 2 PID: 28560 at /home/apw/COD/linux/drivers/media/v4l2-core/videobuf2-core.c:2144 __vb2_queue_cancel+0x1d0/0x240 [videobuf2_core]()

[Steve Cookson]

While trying to debug a particularly recalcitrant segfault on entering 
GStreamer, I found all this on dmesg.  I don't know if it is connected, 
but I haven't seen it before.  I'm using a Dazzle DVC 100 Rev 1.1.


I get it across several different platforms (this is an Asus Zen 
laptop).  The operating system is Kubuntu 14.04 LTS and 
3.17.0-031700-generic.


Can anyone offer any guidence?

Regards,

Steve.

[32550.400043] [ cut here ]
[32550.400079] WARNING: CPU: 2 PID: 28560 at 
/home/apw/COD/linux/drivers/media/v4l2-core/videobuf2-core.c:2144 
__vb2_queue_cancel+0x1d0/0x240 [videobuf2_core]()
[32550.400083] Modules linked in: saa7115 em28xx_v4l snd_usb_audio 
snd_usbmidi_lib em28xx tveeprom hid_sensor_accel_3d hid_sensor_gyro_3d 
hid_sensor_magn_3d hid_sensor_incl_3d hid_sensor_rotation 
hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio 
hid_sensor_iio_common hid_sensor_hub ctr ccm snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
snd_hda_controller snd_hda_codec snd_hwdep snd_pcm asus_nb_wmi asus_wmi 
sparse_keymap snd_seq_midi intel_rapl x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel snd_seq_midi_event kvm arc4 
snd_rawmidi crct10dif_pclmul uvcvideo crc32_pclmul iwldvm 
ghash_clmulni_intel videobuf2_vmalloc videobuf2_memops aesni_intel 
mac80211 videobuf2_core aes_x86_64 v4l2_common lrw videodev gf128mul 
media glue_helper ablk_helper snd_seq cryptd joydev rtc_efi serio_raw 
iwlwifi hid_multitouch cfg80211 btusb snd_seq_device lpc_ich snd_timer 
int3403_thermal snd soundcore intel_rst mac_hid bnep rfcomm bluetooth 
mei_me mei parport_pc ppdev lp parport nls_iso8859_1 hid_generic usbhid 
hid i915 i2c_algo_bit psmouse drm_kms_helper ahci libahci drm wmi video
[32550.400152] CPU: 2 PID: 28560 Comm: qv4l2 Tainted: G W  
3.17.0-031700-generic #201410060605
[32550.400153] Hardware name: ASUSTeK COMPUTER INC. TAICHI21A/TAICHI21A, 
BIOS TAICHI21A.203 02/04/2013
[32550.400154]  0860 880117a6fbd8 81796bd7 
0007
[32550.400156]   880117a6fc18 81074a3c 
0292
[32550.400158]  880112d73148 0001 88005fceca00 
c0aa4960

[32550.400160] Call Trace:
[32550.400165]  [] dump_stack+0x46/0x58
[32550.400168]  [] warn_slowpath_common+0x8c/0xc0
[32550.400171]  [] warn_slowpath_null+0x1a/0x20
[32550.400175]  [] __vb2_queue_cancel+0x1d0/0x240 
[videobuf2_core]
[32550.400179]  [] vb2_internal_streamoff+0x45/0xe0 
[videobuf2_core]
[32550.400182]  [] vb2_streamoff+0x35/0x60 
[videobuf2_core]
[32550.400186]  [] vb2_ioctl_streamoff+0x58/0x70 
[videobuf2_core]

[32550.400191]  [] v4l_streamoff+0x1a/0x20 [videodev]
[32550.400196]  [] __video_do_ioctl+0x274/0x310 [videodev]
[32550.400202]  [] video_usercopy+0x29c/0x4a0 [videodev]
[32550.400207]  [] ? v4l_printk_ioctl+0xb0/0xb0 [videodev]
[32550.400210]  [] ? do_readv_writev+0x187/0x2e0
[32550.400214]  [] video_ioctl2+0x15/0x20 [videodev]
[32550.400218]  [] v4l2_ioctl+0x133/0x160 [videodev]
[32550.400221]  [] ? __fget_light+0x25/0x70
[32550.400223]  [] do_vfs_ioctl+0x75/0x2c0
[32550.400226]  [] ? __sys_recvmsg+0x75/0x90
[32550.400228]  [] ? __fget_light+0x25/0x70
[32550.400229]  [] SyS_ioctl+0x91/0xb0
[32550.400232]  [] system_call_fastpath+0x1a/0x1f
[32550.400233] ---[ end trace 039a366d7d2aff19 ]---

--
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] ITU BT2020 support in v4l2_colorspace

[Hans Verkuil]

On 08/01/2014 05:02 PM, Jean-Marc VOLLE wrote:
> From: vollejm 
> 
> UHD video content may be encoded using a new color space (BT2020). This patch
> adds it to the  v4l2_colorspace enum

FYI: I've just posted a patch series that enhances V4L2 colorspace support to
include BT.2020 (among others).

See: http://www.mail-archive.com/linux-media@vger.kernel.org/msg81883.html

Regards,

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

Re: [RFC PATCH 06/11] videodev2.h: add new v4l2_ext_control flags field

[Sakari Ailus]

Hi Hans,

On Mon, Nov 17, 2014 at 09:57:24AM +0100, Hans Verkuil wrote:
> On 11/15/2014 06:44 PM, Sakari Ailus wrote:
> > Hi,
> > 
> > On Sat, Nov 15, 2014 at 04:18:59PM +0200, Sakari Ailus wrote:
> > ...
> >>>   union {
> >>>   __s32 value;
> >>>   __s64 value64;
> >>> @@ -1294,6 +1294,10 @@ struct v4l2_ext_control {
> >>>   };
> >>>  } __attribute__ ((packed));
> >>>  
> >>> +/* v4l2_ext_control flags */
> >>> +#define V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE 0x0001
> >>> +#define V4L2_EXT_CTRL_FL_IGN_STORE   0x0002
> >>
> >> Do we need both? Aren't these mutually exclusive, and you must have either
> >> to be meaningful in the context of a store?
> > 
> > Ah. Now I think I understand what do these mean. Please ignore my previous
> > comment.
> > 
> > I might call them differently. What would you think of
> 
> I was never happy with the naming :-)

:-)

> > V4L2_EXT_CTRL_FL_STORE_IGNORE and V4L2_EXT_CTRL_FL_STORE_ONCE?
> 
> I will give this some more thought.
> 
> > V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE is quite long IMO. Up to you.
> > 
> > I wonder if we need EXT in V4L2_EXT_CTRL_FL. It's logical but also
> > redundant since the old control interface won't have flags either.
> 
> True.

I think I'm inclined to keep EXT there. These values aren't used in that
many places in typical programs.

> > I'd assume that for cameras the vast majority of users will always want to
> > just apply the values once. How are the use cases in video decoding?
> 
> I am wondering whether 'apply once' shouldn't be the default and whether I
> really need to implement the 'apply always' (Hey, not bad names either!)
> functionality for this initial version.

After thinking more about it, I'm still leaning towards making the values
stick to a store by default. Forgetting the values after use is something on
top of the basic behaviour. Just my 5 euro cents. Pawel, others?

It could be nice to be able to forget an entire store. An application might
fill it, but only later figure out it will never be needed.

Do you think this could be a button control? :-) No need for this now,
though, we could see when someone needs that.

> I only used the 'apply always' functionality for a somewhat contrived test
> example where I changed the cropping rectangle (this is with the selection
> controls from patch 10/11) for each buffer so that while streaming I would
> get a continuous zoom-in/zoom-out effect. While nice for testing, it isn't
> really practical in reality.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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: [RFCv1 PATCH 0/8] improve colorspace support

[Hans Verkuil]

On 11/17/2014 03:16 PM, Hans Verkuil wrote:
> This patch series improves the V4L2 colorspace support. Specifically
> it adds support for AdobeRGB and BT.2020 (UHDTV) colorspaces and it allows
> configuring the Y'CbCr encoding and the quantization explicitly if
> non-standard methods are used.
> 
> It's almost identical to the version shown during the mini-summit in 
> Düsseldorf,
> but the V4L2_QUANTIZATION_ALT_RANGE has been replaced by LIM_RANGE and
> FULL_RANGE. After some more research additional YCbCr encodings have
> been added as well:
> 
> - V4L2_YCBCR_ENC_BT2020NC
> - V4L2_YCBCR_ENC_SYCC
> - V4L2_YCBCR_ENC_SMPTE240M
> 
> The SYCC encoding was missing (I thought I could use ENC_601 for this, but
> it's not quite the same) and the other two were implicitly defined via
> YCBCR_ENC_DEFAULT and the current colorspace. That's a bit too magical
> and these encodings should be defined explicitly.
> 
> The first three patches add the new defines and fields to the core. The 
> changes are very minor.
> 
> The fourth patch completely overhauls the Colorspace chapter in the spec.
> There is no point trying to read the diff, instead I've made the html
> available here:
> 
> http://hverkuil.home.xs4all.nl/colorspace.html#colorspaces
> 
> The remaining patches add support for the new colorspace functionality
> to the test pattern generator and the vivid driver.

I forgot to mention that for the final version of this patch series I plan
to add support for these newer colorspaces to the adv7604, 7842 and 7511
drivers. This requires a bit more work, though.

Regards,

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

[RFCv1 PATCH 7/8] vivid: add new colorspaces

[Hans Verkuil]

From: Hans Verkuil 

Add AdobeRGB and BT.2020 support.

The colorspace control now orders the colorspaces according to how often
they are used. So rarely used colorspaces are moved to the end. This makes
it more logical when testing colorspace support.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-core.h| 11 +++
 drivers/media/platform/vivid/vivid-ctrls.c   | 27 +--
 drivers/media/platform/vivid/vivid-vid-cap.c | 16 
 3 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-core.h 
b/drivers/media/platform/vivid/vivid-core.h
index 811c286..834e425 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -116,6 +116,17 @@ enum vivid_signal_mode {
CUSTOM_DV_TIMINGS,
 };
 
+enum vivid_colorspace {
+   VIVID_CS_170M,
+   VIVID_CS_709,
+   VIVID_CS_SRGB,
+   VIVID_CS_ADOBERGB,
+   VIVID_CS_2020,
+   VIVID_CS_240M,
+   VIVID_CS_SYS_M,
+   VIVID_CS_SYS_BG,
+};
+
 #define VIVID_INVALID_SIGNAL(mode) \
((mode) == NO_SIGNAL || (mode) == NO_LOCK || (mode) == OUT_OF_RANGE)
 
diff --git a/drivers/media/platform/vivid/vivid-ctrls.c 
b/drivers/media/platform/vivid/vivid-ctrls.c
index ad8df5c..dcb912d 100644
--- a/drivers/media/platform/vivid/vivid-ctrls.c
+++ b/drivers/media/platform/vivid/vivid-ctrls.c
@@ -333,6 +333,16 @@ static const struct v4l2_ctrl_ops vivid_user_vid_ctrl_ops 
= {
 
 static int vivid_vid_cap_s_ctrl(struct v4l2_ctrl *ctrl)
 {
+   static const u32 colorspaces[] = {
+   V4L2_COLORSPACE_SMPTE170M,
+   V4L2_COLORSPACE_REC709,
+   V4L2_COLORSPACE_SRGB,
+   V4L2_COLORSPACE_ADOBERGB,
+   V4L2_COLORSPACE_BT2020,
+   V4L2_COLORSPACE_SMPTE240M,
+   V4L2_COLORSPACE_470_SYSTEM_M,
+   V4L2_COLORSPACE_470_SYSTEM_BG,
+   };
struct vivid_dev *dev = container_of(ctrl->handler, struct vivid_dev, 
ctrl_hdl_vid_cap);
unsigned i;
 
@@ -342,7 +352,7 @@ static int vivid_vid_cap_s_ctrl(struct v4l2_ctrl *ctrl)
tpg_s_pattern(&dev->tpg, ctrl->val);
break;
case VIVID_CID_COLORSPACE:
-   tpg_s_colorspace(&dev->tpg, ctrl->val);
+   tpg_s_colorspace(&dev->tpg, colorspaces[ctrl->val]);
vivid_send_source_change(dev, TV);
vivid_send_source_change(dev, SVID);
vivid_send_source_change(dev, HDMI);
@@ -662,15 +672,14 @@ static const struct v4l2_ctrl_config 
vivid_ctrl_max_edid_blocks = {
 };
 
 static const char * const vivid_ctrl_colorspace_strings[] = {
-   "",
"SMPTE 170M",
-   "SMPTE 240M",
"REC 709",
-   "", /* Skip Bt878 entry */
+   "sRGB",
+   "AdobeRGB",
+   "BT.2020",
+   "SMPTE 240M",
"470 System M",
"470 System BG",
-   "", /* Skip JPEG entry */
-   "sRGB",
NULL,
 };
 
@@ -679,10 +688,8 @@ static const struct v4l2_ctrl_config vivid_ctrl_colorspace 
= {
.id = VIVID_CID_COLORSPACE,
.name = "Colorspace",
.type = V4L2_CTRL_TYPE_MENU,
-   .min = 1,
-   .max = 8,
-   .menu_skip_mask = (1 << 4) | (1 << 7),
-   .def = 8,
+   .max = 7,
+   .def = 2,
.qmenu = vivid_ctrl_colorspace_strings,
 };
 
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c 
b/drivers/media/platform/vivid/vivid-vid-cap.c
index 331c544..5caf912 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -443,12 +443,12 @@ void vivid_update_format_cap(struct vivid_dev *dev, bool 
keep_controls)
break;
if (bt->standards & V4L2_DV_BT_STD_CEA861) {
if (bt->width == 720 && bt->height <= 576)
-   v4l2_ctrl_s_ctrl(dev->colorspace, 
V4L2_COLORSPACE_SMPTE170M);
+   v4l2_ctrl_s_ctrl(dev->colorspace, 
VIVID_CS_170M);
else
-   v4l2_ctrl_s_ctrl(dev->colorspace, 
V4L2_COLORSPACE_REC709);
+   v4l2_ctrl_s_ctrl(dev->colorspace, VIVID_CS_709);
v4l2_ctrl_s_ctrl(dev->real_rgb_range_cap, 1);
} else {
-   v4l2_ctrl_s_ctrl(dev->colorspace, V4L2_COLORSPACE_SRGB);
+   v4l2_ctrl_s_ctrl(dev->colorspace, VIVID_CS_SRGB);
v4l2_ctrl_s_ctrl(dev->real_rgb_range_cap, 0);
}
tpg_s_rgb_range(&dev->tpg, 
v4l2_ctrl_g_ctrl(dev->rgb_range_cap));
@@ -1307,20 +1307,20 @@ int vidioc_s_input(struct file *file, void *priv, 
unsigned i)
if (dev->colorspace) {
switch (dev->input_type[i]) {
case WEBCAM:
-   v4l2_ctrl_s_ctrl(dev->colorspace, V4L2_COLORSPACE_SRGB);
+   v4l2_ctrl_s_

[RFCv1 PATCH 8/8] vivid: add support for YCbCr encoding and quantization

[Hans Verkuil]

From: Hans Verkuil 

Implement controls to set the YCbCr encoding and the quantization
range for the colorspace.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-core.h   |  2 +
 drivers/media/platform/vivid/vivid-ctrls.c  | 86 +
 drivers/media/platform/vivid/vivid-vid-cap.c| 18 ++
 drivers/media/platform/vivid/vivid-vid-common.c |  4 ++
 drivers/media/platform/vivid/vivid-vid-out.c| 25 +--
 5 files changed, 116 insertions(+), 19 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-core.h 
b/drivers/media/platform/vivid/vivid-core.h
index 834e425..387af6f 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -329,6 +329,8 @@ struct vivid_dev {
v4l2_std_id std_out;
struct v4l2_dv_timings  dv_timings_out;
u32 colorspace_out;
+   u32 ycbcr_enc_out;
+   u32 quantization_out;
u32 service_set_out;
u32 bytesperline_out[2];
unsignedtv_field_out;
diff --git a/drivers/media/platform/vivid/vivid-ctrls.c 
b/drivers/media/platform/vivid/vivid-ctrls.c
index dcb912d..857e786 100644
--- a/drivers/media/platform/vivid/vivid-ctrls.c
+++ b/drivers/media/platform/vivid/vivid-ctrls.c
@@ -62,19 +62,21 @@
 #define VIVID_CID_DV_TIMINGS_ASPECT_RATIO  (VIVID_CID_VIVID_BASE + 23)
 #define VIVID_CID_TSTAMP_SRC   (VIVID_CID_VIVID_BASE + 24)
 #define VIVID_CID_COLORSPACE   (VIVID_CID_VIVID_BASE + 25)
-#define VIVID_CID_LIMITED_RGB_RANGE(VIVID_CID_VIVID_BASE + 26)
-#define VIVID_CID_ALPHA_MODE   (VIVID_CID_VIVID_BASE + 27)
-#define VIVID_CID_HAS_CROP_CAP (VIVID_CID_VIVID_BASE + 28)
-#define VIVID_CID_HAS_COMPOSE_CAP  (VIVID_CID_VIVID_BASE + 29)
-#define VIVID_CID_HAS_SCALER_CAP   (VIVID_CID_VIVID_BASE + 30)
-#define VIVID_CID_HAS_CROP_OUT (VIVID_CID_VIVID_BASE + 31)
-#define VIVID_CID_HAS_COMPOSE_OUT  (VIVID_CID_VIVID_BASE + 32)
-#define VIVID_CID_HAS_SCALER_OUT   (VIVID_CID_VIVID_BASE + 33)
-#define VIVID_CID_LOOP_VIDEO   (VIVID_CID_VIVID_BASE + 34)
-#define VIVID_CID_SEQ_WRAP (VIVID_CID_VIVID_BASE + 35)
-#define VIVID_CID_TIME_WRAP(VIVID_CID_VIVID_BASE + 36)
-#define VIVID_CID_MAX_EDID_BLOCKS  (VIVID_CID_VIVID_BASE + 37)
-#define VIVID_CID_PERCENTAGE_FILL  (VIVID_CID_VIVID_BASE + 38)
+#define VIVID_CID_YCBCR_ENC(VIVID_CID_VIVID_BASE + 26)
+#define VIVID_CID_QUANTIZATION (VIVID_CID_VIVID_BASE + 27)
+#define VIVID_CID_LIMITED_RGB_RANGE(VIVID_CID_VIVID_BASE + 28)
+#define VIVID_CID_ALPHA_MODE   (VIVID_CID_VIVID_BASE + 29)
+#define VIVID_CID_HAS_CROP_CAP (VIVID_CID_VIVID_BASE + 30)
+#define VIVID_CID_HAS_COMPOSE_CAP  (VIVID_CID_VIVID_BASE + 31)
+#define VIVID_CID_HAS_SCALER_CAP   (VIVID_CID_VIVID_BASE + 32)
+#define VIVID_CID_HAS_CROP_OUT (VIVID_CID_VIVID_BASE + 33)
+#define VIVID_CID_HAS_COMPOSE_OUT  (VIVID_CID_VIVID_BASE + 34)
+#define VIVID_CID_HAS_SCALER_OUT   (VIVID_CID_VIVID_BASE + 35)
+#define VIVID_CID_LOOP_VIDEO   (VIVID_CID_VIVID_BASE + 36)
+#define VIVID_CID_SEQ_WRAP (VIVID_CID_VIVID_BASE + 37)
+#define VIVID_CID_TIME_WRAP(VIVID_CID_VIVID_BASE + 38)
+#define VIVID_CID_MAX_EDID_BLOCKS  (VIVID_CID_VIVID_BASE + 39)
+#define VIVID_CID_PERCENTAGE_FILL  (VIVID_CID_VIVID_BASE + 40)
 
 #define VIVID_CID_STD_SIGNAL_MODE  (VIVID_CID_VIVID_BASE + 60)
 #define VIVID_CID_STANDARD (VIVID_CID_VIVID_BASE + 61)
@@ -358,6 +360,20 @@ 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_YCBCR_ENC:
+   tpg_s_ycbcr_enc(&dev->tpg, ctrl->val);
+   vivid_send_source_change(dev, TV);
+   vivid_send_source_change(dev, SVID);
+   vivid_send_source_change(dev, HDMI);
+   vivid_send_source_change(dev, WEBCAM);
+   break;
+   case VIVID_CID_QUANTIZATION:
+   tpg_s_quantization(&dev->tpg, ctrl->val);
+   vivid_send_source_change(dev, TV);
+   vivid_send_source_change(dev, SVID);
+   vivid_send_source_change(dev, HDMI);
+   vivid_send_source_change(dev, WEBCAM);
+   break;
case V4L2_CID_DV_RX_RGB_RANGE:
if (!vivid_is_hdmi_cap(dev))
break;
@@ -693,6 +709,44 @@ static const struct v4l2_ctrl_config vivid_ctrl_colorspace 
= {
.qmenu = vivid_ctrl_colorspace_strings,
 };
 
+static const char * const vivid_ctrl_ycbcr_enc_strings[] = {
+   "Default",
+   "ITU-R 601",
+   "Rec. 709",
+   "xvYCC 601",
+   

[RFCv1 PATCH 6/8] vivid-tpg: improve colorspace support

[Hans Verkuil]

From: Hans Verkuil 

Add support for the new AdobeRGB and BT.2020 colorspaces. Also support
explicit Y'CbCr and quantization settings.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-tpg.c | 327 +--
 drivers/media/platform/vivid/vivid-tpg.h |  38 
 2 files changed, 258 insertions(+), 107 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-tpg.c 
b/drivers/media/platform/vivid/vivid-tpg.c
index cbcd625..fe61b6c 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -296,127 +296,193 @@ static enum tpg_color tpg_get_textfg_color(struct 
tpg_data *tpg)
}
 }
 
-static u16 color_to_y(struct tpg_data *tpg, int r, int g, int b)
+static inline int rec709_to_linear(int v)
 {
-   switch (tpg->colorspace) {
-   case V4L2_COLORSPACE_SMPTE170M:
-   case V4L2_COLORSPACE_470_SYSTEM_M:
-   case V4L2_COLORSPACE_470_SYSTEM_BG:
-   return ((16829 * r + 33039 * g + 6416 * b + 16 * 32768) >> 16) 
+ (16 << 4);
-   case V4L2_COLORSPACE_SMPTE240M:
-   return ((11932 * r + 39455 * g + 4897 * b + 16 * 32768) >> 16) 
+ (16 << 4);
-   case V4L2_COLORSPACE_REC709:
-   case V4L2_COLORSPACE_SRGB:
-   default:
-   return ((11966 * r + 40254 * g + 4064 * b + 16 * 32768) >> 16) 
+ (16 << 4);
-   }
+   v = clamp(v, 0, 0xff0);
+   return tpg_rec709_to_linear[v];
 }
 
-static u16 color_to_cb(struct tpg_data *tpg, int r, int g, int b)
+static inline int linear_to_rec709(int v)
 {
-   switch (tpg->colorspace) {
-   case V4L2_COLORSPACE_SMPTE170M:
-   case V4L2_COLORSPACE_470_SYSTEM_M:
-   case V4L2_COLORSPACE_470_SYSTEM_BG:
-   return ((-9714 * r - 19070 * g + 28784 * b + 16 * 32768) >> 16) 
+ (128 << 4);
-   case V4L2_COLORSPACE_SMPTE240M:
-   return ((-6684 * r - 22100 * g + 28784 * b + 16 * 32768) >> 16) 
+ (128 << 4);
-   case V4L2_COLORSPACE_REC709:
-   case V4L2_COLORSPACE_SRGB:
-   default:
-   return ((-6596 * r - 22189 * g + 28784 * b + 16 * 32768) >> 16) 
+ (128 << 4);
-   }
+   v = clamp(v, 0, 0xff0);
+   return tpg_linear_to_rec709[v];
 }
 
-static u16 color_to_cr(struct tpg_data *tpg, int r, int g, int b)
+static void rgb2ycbcr(const int m[3][3], int r, int g, int b,
+   int y_offset, int *y, int *cb, int *cr)
 {
-   switch (tpg->colorspace) {
-   case V4L2_COLORSPACE_SMPTE170M:
-   case V4L2_COLORSPACE_470_SYSTEM_M:
-   case V4L2_COLORSPACE_470_SYSTEM_BG:
-   return ((28784 * r - 24103 * g - 4681 * b + 16 * 32768) >> 16) 
+ (128 << 4);
-   case V4L2_COLORSPACE_SMPTE240M:
-   return ((28784 * r - 25606 * g - 3178 * b + 16 * 32768) >> 16) 
+ (128 << 4);
-   case V4L2_COLORSPACE_REC709:
-   case V4L2_COLORSPACE_SRGB:
-   default:
-   return ((28784 * r - 26145 * g - 2639 * b + 16 * 32768) >> 16) 
+ (128 << 4);
-   }
+   *y  = ((m[0][0] * r + m[0][1] * g + m[0][2] * b) >> 16) + (y_offset << 
4);
+   *cb = ((m[1][0] * r + m[1][1] * g + m[1][2] * b) >> 16) + (128 << 4);
+   *cr = ((m[2][0] * r + m[2][1] * g + m[2][2] * b) >> 16) + (128 << 4);
 }
 
-static u16 ycbcr_to_r(struct tpg_data *tpg, int y, int cb, int cr)
+static void color_to_ycbcr(struct tpg_data *tpg, int r, int g, int b,
+  int *y, int *cb, int *cr)
 {
-   int r;
+#define COEFF(v, r) ((int)(0.5 + (v) * (r) * 256.0))
 
-   y -= 16 << 4;
-   cb -= 128 << 4;
-   cr -= 128 << 4;
-   switch (tpg->colorspace) {
-   case V4L2_COLORSPACE_SMPTE170M:
-   case V4L2_COLORSPACE_470_SYSTEM_M:
-   case V4L2_COLORSPACE_470_SYSTEM_BG:
-   r = 4769 * y + 6537 * cr;
+   static const int bt601[3][3] = {
+   { COEFF(0.299, 219),  COEFF(0.587, 219),  COEFF(0.114, 219)  },
+   { COEFF(-0.169, 224), COEFF(-0.331, 224), COEFF(0.5, 224)},
+   { COEFF(0.5, 224),COEFF(-0.419, 224), COEFF(-0.081, 224) },
+   };
+   static const int bt601_full[3][3] = {
+   { COEFF(0.299, 255),  COEFF(0.587, 255),  COEFF(0.114, 255)  },
+   { COEFF(-0.169, 255), COEFF(-0.331, 255), COEFF(0.5, 255)},
+   { COEFF(0.5, 255),COEFF(-0.419, 255), COEFF(-0.081, 255) },
+   };
+   static const int rec709[3][3] = {
+   { COEFF(0.2126, 219),  COEFF(0.7152, 219),  COEFF(0.0722, 219)  
},
+   { COEFF(-0.1146, 224), COEFF(-0.3854, 224), COEFF(0.5, 224) 
},
+   { COEFF(0.5, 224), COEFF(-0.4542, 224), COEFF(-0.0458, 224) 
},
+   };
+   static const int rec709_full[3][3] = {
+   { COEFF(0.2126, 255),  COEFF(0.7152, 255),  COEFF(0.0722, 255)  
},
+   { COEFF(-0.1146, 255), COEFF(-0.3854, 255), COEFF(0.5, 255) 
},
+   { COEFF(0.5, 255), COEFF(-0.4542, 255), COEFF(-0.0458, 255) 
},
+   };
+

[RFCv1 PATCH 3/8] v4l2-ioctl.c: log the new ycbcr_enc and quantization fields

[Hans Verkuil]

From: Hans Verkuil 

Log the new ycbcr_enc and quantization fields. Note that it now
also logs the flags field for the multiplanar buffer type. This was
forgotten when the flags field was added.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 9ccb19a..aced84d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -257,7 +257,7 @@ static void v4l_print_format(const void *arg, bool 
write_only)
pr_cont(", width=%u, height=%u, "
"pixelformat=%c%c%c%c, field=%s, "
"bytesperline=%u, sizeimage=%u, colorspace=%d, "
-   "flags %u\n",
+   "flags %x, ycbcr_enc=%u, quantization=%u\n",
pix->width, pix->height,
(pix->pixelformat & 0xff),
(pix->pixelformat >>  8) & 0xff,
@@ -265,21 +265,24 @@ static void v4l_print_format(const void *arg, bool 
write_only)
(pix->pixelformat >> 24) & 0xff,
prt_names(pix->field, v4l2_field_names),
pix->bytesperline, pix->sizeimage,
-   pix->colorspace, pix->flags);
+   pix->colorspace, pix->flags, pix->ycbcr_enc,
+   pix->quantization);
break;
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
mp = &p->fmt.pix_mp;
pr_cont(", width=%u, height=%u, "
"format=%c%c%c%c, field=%s, "
-   "colorspace=%d, num_planes=%u\n",
+   "colorspace=%d, num_planes=%u, flags=%x, "
+   "ycbcr_enc=%u, quantization=%u\n",
mp->width, mp->height,
(mp->pixelformat & 0xff),
(mp->pixelformat >>  8) & 0xff,
(mp->pixelformat >> 16) & 0xff,
(mp->pixelformat >> 24) & 0xff,
prt_names(mp->field, v4l2_field_names),
-   mp->colorspace, mp->num_planes);
+   mp->colorspace, mp->num_planes, mp->flags,
+   mp->ycbcr_enc, mp->quantization);
for (i = 0; i < mp->num_planes; i++)
printk(KERN_DEBUG "plane %u: bytesperline=%u 
sizeimage=%u\n", i,
mp->plane_fmt[i].bytesperline,
-- 
2.1.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

[RFCv1 PATCH 2/8] v4l2-mediabus: improve colorspace support

[Hans Verkuil]

From: Hans Verkuil 

Add and copy the new ycbcr_enc and quantization fields.

Signed-off-by: Hans Verkuil 
---
 include/media/v4l2-mediabus.h  | 4 
 include/uapi/linux/v4l2-mediabus.h | 6 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 59d7397..38d960d 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -94,6 +94,8 @@ static inline void v4l2_fill_pix_format(struct 
v4l2_pix_format *pix_fmt,
pix_fmt->height = mbus_fmt->height;
pix_fmt->field = mbus_fmt->field;
pix_fmt->colorspace = mbus_fmt->colorspace;
+   pix_fmt->ycbcr_enc = mbus_fmt->ycbcr_enc;
+   pix_fmt->quantization = mbus_fmt->quantization;
 }
 
 static inline void v4l2_fill_mbus_format(struct v4l2_mbus_framefmt *mbus_fmt,
@@ -104,6 +106,8 @@ static inline void v4l2_fill_mbus_format(struct 
v4l2_mbus_framefmt *mbus_fmt,
mbus_fmt->height = pix_fmt->height;
mbus_fmt->field = pix_fmt->field;
mbus_fmt->colorspace = pix_fmt->colorspace;
+   mbus_fmt->ycbcr_enc = pix_fmt->ycbcr_enc;
+   mbus_fmt->quantization = pix_fmt->quantization;
mbus_fmt->code = code;
 }
 
diff --git a/include/uapi/linux/v4l2-mediabus.h 
b/include/uapi/linux/v4l2-mediabus.h
index b1934a3..5a86d8e 100644
--- a/include/uapi/linux/v4l2-mediabus.h
+++ b/include/uapi/linux/v4l2-mediabus.h
@@ -22,6 +22,8 @@
  * @code:  data format code (from enum v4l2_mbus_pixelcode)
  * @field: used interlacing type (from enum v4l2_field)
  * @colorspace:colorspace of the data (from enum v4l2_colorspace)
+ * @ycbcr_enc: YCbCr encoding of the data (from enum v4l2_ycbcr_encoding)
+ * @quantization: quantization of the data (from enum v4l2_quantization)
  */
 struct v4l2_mbus_framefmt {
__u32   width;
@@ -29,7 +31,9 @@ struct v4l2_mbus_framefmt {
__u32   code;
__u32   field;
__u32   colorspace;
-   __u32   reserved[7];
+   __u32   ycbcr_enc;
+   __u32   quantization;
+   __u32   reserved[5];
 };
 
 #ifndef __KERNEL__
-- 
2.1.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

[RFCv1 PATCH 1/8] videodev2.h: improve colorspace support

[Hans Verkuil]

From: Hans Verkuil 

Add support for the new AdobeRGB and BT.2020 colorspaces as needed for
HDMI 2.0.

Add support to specify the Y'CbCr encoding and quantization range explicitly.

Signed-off-by: Hans Verkuil 
---
 include/uapi/linux/videodev2.h | 99 +-
 1 file changed, 89 insertions(+), 10 deletions(-)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 1c2f84f..df37e0cf 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -178,30 +178,103 @@ enum v4l2_memory {
 
 /* see also http://vektor.theorem.ca/graphics/ycbcr/ */
 enum v4l2_colorspace {
-   /* ITU-R 601 -- broadcast NTSC/PAL */
+   /* SMPTE 170M: used for broadcast NTSC/PAL SDTV */
V4L2_COLORSPACE_SMPTE170M = 1,
 
-   /* 1125-Line (US) HDTV */
+   /* Obsolete pre-1998 SMPTE 240M HDTV standard, superseded by Rec 709 */
V4L2_COLORSPACE_SMPTE240M = 2,
 
-   /* HD and modern captures. */
+   /* Rec.709: used for HDTV */
V4L2_COLORSPACE_REC709= 3,
 
-   /* broken BT878 extents (601, luma range 16-253 instead of 16-235) */
+   /*
+* Deprecated, do not use. No driver will ever return this. This was
+* based on a misunderstanding of the bt878 datasheet.
+*/
V4L2_COLORSPACE_BT878 = 4,
 
-   /* These should be useful.  Assume 601 extents. */
+   /*
+* NTSC 1953 colorspace. This only makes sense when dealing with
+* really, really old NTSC recordings. Superseded by SMPTE 170M.
+*/
V4L2_COLORSPACE_470_SYSTEM_M  = 5,
+
+   /*
+* EBU Tech 3213 PAL/SECAM colorspace. This only makes sense when
+* dealing with really old PAL/SECAM recordings. Superseded by
+* SMPTE 170M.
+*/
V4L2_COLORSPACE_470_SYSTEM_BG = 6,
 
-   /* I know there will be cameras that send this.  So, this is
-* unspecified chromaticities and full 0-255 on each of the
-* Y'CbCr components
+   /*
+* Effectively shorthand for V4L2_COLORSPACE_SRGB, V4L2_YCBCR_ENC_601
+* and V4L2_QUANTIZATION_FULL_RANGE. To be used for (Motion-)JPEG.
 */
V4L2_COLORSPACE_JPEG  = 7,
 
-   /* For RGB colourspaces, this is probably a good start. */
+   /* For RGB colorspaces such as produces by most webcams. */
V4L2_COLORSPACE_SRGB  = 8,
+
+   /* AdobeRGB colorspace */
+   V4L2_COLORSPACE_ADOBERGB  = 9,
+
+   /* BT.2020 colorspace, used for UHDTV. */
+   V4L2_COLORSPACE_BT2020= 10,
+};
+
+enum v4l2_ycbcr_encoding {
+   /*
+* Mapping of V4L2_YCBCR_ENC_DEFAULT to actual encodings for the
+* various colorspaces:
+*
+* V4L2_COLORSPACE_SMPTE170M, V4L2_COLORSPACE_470_SYSTEM_M,
+* V4L2_COLORSPACE_470_SYSTEM_BG, V4L2_COLORSPACE_ADOBERGB and
+* V4L2_COLORSPACE_JPEG: V4L2_YCBCR_ENC_601
+*
+* V4L2_COLORSPACE_REC709: V4L2_YCBCR_ENC_709
+*
+* V4L2_COLORSPACE_SRGB: V4L2_YCBCR_ENC_SYCC
+*
+* V4L2_COLORSPACE_BT2020: V4L2_YCBCR_ENC_BT2020NC
+*
+* V4L2_COLORSPACE_SMPTE240M: V4L2_YCBCR_ENC_SMPTE240M
+*/
+   V4L2_YCBCR_ENC_DEFAULT= 0,
+
+   /* ITU-R 601 -- SDTV */
+   V4L2_YCBCR_ENC_601= 1,
+
+   /* Rec. 709 -- HDTV */
+   V4L2_YCBCR_ENC_709= 2,
+
+   /* ITU-R 601/EN 61966-2-4 Extended Gamut -- SDTV */
+   V4L2_YCBCR_ENC_XV601  = 3,
+
+   /* Rec. 709/EN 61966-2-4 Extended Gamut -- HDTV */
+   V4L2_YCBCR_ENC_XV709  = 4,
+
+   /* sYCC (Y'CbCr encoding of sRGB) */
+   V4L2_YCBCR_ENC_SYCC   = 5,
+
+   /* BT.2020 Non-constant Luminance Y'CbCr */
+   V4L2_YCBCR_ENC_BT2020NC   = 6,
+
+   /* BT.2020 Constant Luminance Y'CbcCrc */
+   V4L2_YCBCR_ENC_BT2020C= 7,
+
+   /* SMPTE 240M -- Obsolete HDTV */
+   V4L2_YCBCR_ENC_SMPTE240M  = 8,
+};
+
+enum v4l2_quantization {
+   /*
+* The default for R'G'B' quantization is always full range. For
+* Y'CbCr the quantization is always limited range, except for
+* SYCC, XV601, XV709 or JPEG: those are full range.
+*/
+   V4L2_QUANTIZATION_DEFAULT = 0,
+   V4L2_QUANTIZATION_FULL_RANGE  = 1,
+   V4L2_QUANTIZATION_LIM_RANGE   = 2,
 };
 
 enum v4l2_priority {
@@ -294,6 +367,8 @@ 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 */
+   __u32   quantization;   /* enum v4l2_quantization */
 };
 
 /*  Pixel format FOURCC  depth  
Description  */
@@ 

[RFCv1 PATCH 5/8] vivid-tpg-colors: add AdobeRGB and BT.2020 support

[Hans Verkuil]

From: Hans Verkuil 

This extends the precalculated tpg_csc_colors matrix with AdobeRGB and BT.2020
colorspace support.

It also adds two precalculated tables that convert between linear RGB and 
non-linear
Rec.709 R'G'B' values, i.e. the Rec. 709 transfer function. This is needed to
efficiently handle the BT.2020 Constant Luminance Yc'CbcCrc encoding and 
decoding.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-tpg-colors.c | 704 ++--
 drivers/media/platform/vivid/vivid-tpg-colors.h |   4 +-
 2 files changed, 665 insertions(+), 43 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-tpg-colors.c 
b/drivers/media/platform/vivid/vivid-tpg-colors.c
index 2adddc0..424aa7a 100644
--- a/drivers/media/platform/vivid/vivid-tpg-colors.c
+++ b/drivers/media/platform/vivid/vivid-tpg-colors.c
@@ -12,7 +12,7 @@
  * This source also contains the code used to generate the tpg_csc_colors
  * table. Run the following command to compile it:
  *
- * gcc vivid-colors.c -DCOMPILE_APP -o gen-colors -lm
+ * gcc vivid-tpg-colors.c -DCOMPILE_APP -o gen-colors -lm
  *
  * and run the utility.
  *
@@ -78,22 +78,542 @@ const struct color tpg_colors[TPG_COLOR_MAX] = {
 #ifndef COMPILE_APP
 
 /* Generated table */
-const struct color16 tpg_csc_colors[V4L2_COLORSPACE_SRGB + 
1][TPG_COLOR_CSC_BLACK + 1] = {
-   [V4L2_COLORSPACE_SMPTE170M][0] = { 2953, 2939, 2939 },
-   [V4L2_COLORSPACE_SMPTE170M][1] = { 2954, 2963, 585 },
-   [V4L2_COLORSPACE_SMPTE170M][2] = { 84, 2967, 2937 },
-   [V4L2_COLORSPACE_SMPTE170M][3] = { 93, 2990, 575 },
-   [V4L2_COLORSPACE_SMPTE170M][4] = { 3030, 259, 2933 },
-   [V4L2_COLORSPACE_SMPTE170M][5] = { 3031, 406, 557 },
-   [V4L2_COLORSPACE_SMPTE170M][6] = { 544, 428, 2931 },
-   [V4L2_COLORSPACE_SMPTE170M][7] = { 551, 547, 547 },
+const unsigned short tpg_rec709_to_linear[255 * 16 + 1] = {
+  0,0,0,1,1,1,1,2,2,2,2,2, 
   3,3,3,3,
+  4,4,4,4,4,5,5,5,5,6,6,6, 
   6,6,7,7,
+  7,7,8,8,8,8,8,9,9,9,9,   10, 
  10,   10,   10,   10,
+ 11,   11,   11,   11,   12,   12,   12,   12,   12,   13,   13,   13, 
  13,   14,   14,   14,
+ 14,   14,   15,   15,   15,   15,   16,   16,   16,   16,   16,   17, 
  17,   17,   17,   18,
+ 18,   18,   18,   18,   19,   19,   19,   19,   20,   20,   20,   20, 
  20,   21,   21,   21,
+ 21,   22,   22,   22,   22,   22,   23,   23,   23,   23,   24,   24, 
  24,   24,   24,   25,
+ 25,   25,   25,   26,   26,   26,   26,   26,   27,   27,   27,   27, 
  28,   28,   28,   28,
+ 28,   29,   29,   29,   29,   30,   30,   30,   30,   30,   31,   31, 
  31,   31,   32,   32,
+ 32,   32,   32,   33,   33,   33,   33,   34,   34,   34,   34,   34, 
  35,   35,   35,   35,
+ 36,   36,   36,   36,   36,   37,   37,   37,   37,   38,   38,   38, 
  38,   38,   39,   39,
+ 39,   39,   40,   40,   40,   40,   40,   41,   41,   41,   41,   42, 
  42,   42,   42,   42,
+ 43,   43,   43,   43,   44,   44,   44,   44,   44,   45,   45,   45, 
  45,   46,   46,   46,
+ 46,   46,   47,   47,   47,   47,   48,   48,   48,   48,   48,   49, 
  49,   49,   49,   50,
+ 50,   50,   50,   50,   51,   51,   51,   51,   52,   52,   52,   52, 
  52,   53,   53,   53,
+ 53,   54,   54,   54,   54,   54,   55,   55,   55,   55,   56,   56, 
  56,   56,   56,   57,
+ 57,   57,   57,   58,   58,   58,   58,   58,   59,   59,   59,   59, 
  60,   60,   60,   60,
+ 60,   61,   61,   61,   61,   62,   62,   62,   62,   62,   63,   63, 
  63,   63,   64,   64,
+ 64,   64,   64,   65,   65,   65,   65,   66,   66,   66,   66,   66, 
  67,   67,   67,   67,
+ 68,   68,   68,   68,   68,   69,   69,   69,   69,   70,   70,   70, 
  70,   70,   71,   71,
+ 71,   71,   72,   72,   72,   72,   72,   73,   73,   73,   73,   73, 
  74,   74,   74,   74,
+ 74,   75,   75,   75,   75,   76,   76,   76,   76,   76,   77,   77, 
  77,   77,   78,   78,
+ 78,   78,   79,   79,   79,   79,   79,   80,   80,   80,   80,   81, 
  81,   81,   81,   82,
+ 82,   82,   82,   82,   83,   83,   83,   83,   84,   84,   84,   84, 
  85,   85,   85,   85,
+ 86,   86,   86,   86,   87,   87,   87,   87,   88,   88,   88,   88, 
  89,   89,   89,   89,
+ 90,   90,   90,   90,   91,   91,   91,   91,   92,   92,   92,   92, 
  93,   93,   93,   93,
+ 94,   94,   94,   94,   95,   95,   95,   95,   96,   96,   96,   96, 
  97,   97,   97,   97,
+ 98,   98,   98,   98,   99,   99,   99,   99,  100,  100,  100,  101, 
 101,  101,  101,  102,
+102,  102,  102,  103,  103,  103,  103,  104,  104,  104,  105,  105, 
 105,  105,  106,  106,
+106,  106,  107,  107,  107,  107,  

[RFCv1 PATCH 4/8] DocBook media: rewrite the Colorspace chapter

[Hans Verkuil]

From: Hans Verkuil 

The colorspace chapter in the V4L2 Specification was always poorly
written. This patch rewrites it, documenting the new Y'CbCr encoding
and quantization defines and going into much more detail with respect
to how colorspaces are used and what it all means.

Signed-off-by: Hans Verkuil 
---
 Documentation/DocBook/media/v4l/biblio.xml |   75 ++
 Documentation/DocBook/media/v4l/pixfmt.xml | 1223 +---
 2 files changed, 1008 insertions(+), 290 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
b/Documentation/DocBook/media/v4l/biblio.xml
index d2eb79e..ac32322 100644
--- a/Documentation/DocBook/media/v4l/biblio.xml
+++ b/Documentation/DocBook/media/v4l/biblio.xml
@@ -178,6 +178,65 @@ Signal - NTSC for Studio Applications"
 1125-Line High-Definition Production"
 
 
+
+  sRGB
+  
+   International Electrotechnical Commission
+(http://www.iec.ch";>http://www.iec.ch)
+  
+  IEC 61966-2-1 ed1.0 "Multimedia systems and equipment - Colour 
measurement
+and management - Part 2-1: Colour management - Default RGB colour space - 
sRGB"
+
+
+
+  sYCC
+  
+   International Electrotechnical Commission
+(http://www.iec.ch";>http://www.iec.ch)
+  
+  IEC 61966-2-1-am1 ed1.0 "Amendment 1 - Multimedia systems and 
equipment - Colour measurement
+and management - Part 2-1: Colour management - Default RGB colour space - 
sRGB"
+
+
+
+  xvYCC
+  
+   International Electrotechnical Commission
+(http://www.iec.ch";>http://www.iec.ch)
+  
+  IEC 61966-2-4 ed1.0 "Multimedia systems and equipment - Colour 
measurement
+and management - Part 2-4: Colour management - Extended-gamut YCC colour space 
for video
+applications - xvYCC"
+
+
+
+  AdobeRGB
+  
+   Adobe Systems Incorporated (http://www.adobe.com";>http://www.adobe.com)
+  
+  Adobe© RGB (1998) Color Image Encoding Version 
2005-05
+
+
+
+  ITU BT.2020
+  
+   International Telecommunication Union (http://www.itu.ch";>http://www.itu.ch)
+  
+  ITU-R Recommendation BT.2020 (08/2012) "Parameter values for 
ultra-high
+definition television systems for production and international programme 
exchange"
+
+
+
+
+  EBU Tech 3213
+  
+   European Broadcast Union (http://www.ebu.ch";>http://www.ebu.ch)
+  
+  E.B.U. Standard for Chromaticity Tolerances for Studio 
Monitors"
+
+
 
   IEC 62106
   
@@ -266,4 +325,20 @@ in the frequency range from 87,5 to 108,0 MHz
   Version 1, Revision 2
 
 
+
+  poynton
+  
+   Charles Poynton
+  
+  Digital Video and HDTV, Algorithms and Interfaces
+
+
+
+  colimg
+  
+   Erik Reinhard et al.
+  
+  Color Imaging: Fundamentals and Applications
+
+
   
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index df5b23d..ff37f7c 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -296,343 +296,986 @@ in the 2-planar version or with each component in its 
own buffer in the
   
 Colorspaces
 
-[intro]
+'Color' is a very complex concept and depends on physics, chemistry 
and
+biology. Just because you have three numbers that describe the 'red', 'green'
+and 'blue' components of the color of a pixel does not mean that you can 
accurately
+display that color. A colorspace defines what it actually 
means
+to have an RGB value of e.g. (255, 0, 0). That is, which color 
should be
+reproduced on the screen in a perfectly calibrated environment.
 
-
+In order to do that we first need to have a good definition of
+color, i.e. some way to uniquely and unambiguously define a color so that 
someone
+else can reproduce it. Human color vision is trichromatic since the human eye 
has
+color receptors that are sensitive to three different wavelengths of light. 
Hence
+the need to use three numbers to describe color. Be glad you are not a mantis 
shrimp
+as those are sensitive to 12 different wavelengths, so instead of RGB we would 
be
+using the ABCDEFGHIJKL colorspace...
 
-
-  
-   
- Gamma Correction
- 
-   [to do]
-   E'R = f(R)
-   E'G = f(G)
-   E'B = f(B)
- 
-   
-   
- Construction of luminance and color-difference
-signals
- 
-   [to do]
-   E'Y =
-CoeffR E'R
-+ CoeffG E'G
-+ CoeffB E'B
-   (E'R - E'Y) = 
E'R
-- CoeffR E'R
-- CoeffG E'G
-- CoeffB E'B
-   (E'B - E'Y) = 
E'B
-- CoeffR E'R
-- CoeffG E'G
-- CoeffB E'B
- 
-   
-   
- Re-normalized color-difference signals
- 
-   The color-difference signals are scaled back to unity
-range [-0.5;+0.5]:
-   KB = 0.5 / (1 - 
CoeffB)
-   KR = 0.5 / (1 - 
CoeffR)
-   PB =
-KB (E'B - 
E'Y) =
-  0.5 (CoeffR / Coe

[RFCv1 PATCH 0/8] improve colorspace support

[Hans Verkuil]

This patch series improves the V4L2 colorspace support. Specifically
it adds support for AdobeRGB and BT.2020 (UHDTV) colorspaces and it allows
configuring the Y'CbCr encoding and the quantization explicitly if
non-standard methods are used.

It's almost identical to the version shown during the mini-summit in Düsseldorf,
but the V4L2_QUANTIZATION_ALT_RANGE has been replaced by LIM_RANGE and
FULL_RANGE. After some more research additional YCbCr encodings have
been added as well:

- V4L2_YCBCR_ENC_BT2020NC
- V4L2_YCBCR_ENC_SYCC
- V4L2_YCBCR_ENC_SMPTE240M

The SYCC encoding was missing (I thought I could use ENC_601 for this, but
it's not quite the same) and the other two were implicitly defined via
YCBCR_ENC_DEFAULT and the current colorspace. That's a bit too magical
and these encodings should be defined explicitly.

The first three patches add the new defines and fields to the core. The 
changes are very minor.

The fourth patch completely overhauls the Colorspace chapter in the spec.
There is no point trying to read the diff, instead I've made the html
available here:

http://hverkuil.home.xs4all.nl/colorspace.html#colorspaces

The remaining patches add support for the new colorspace functionality
to the test pattern generator and the vivid driver.

Regards,

Hans

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

[REVIEW PATCH 5/5] MAINTAINERS: Add myself as img-ir maintainer

[James Hogan]

Add myself as the maintainer for the Imagination Technologies Infrared
Decoder driver.

Signed-off-by: James Hogan 
Cc: Mauro Carvalho Chehab 
Cc: linux-media@vger.kernel.org
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ea4d0058fd1b..814cf15448ad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4757,6 +4757,11 @@ L:   linux-security-mod...@vger.kernel.org
 S: Supported
 F: security/integrity/ima/
 
+IMGTEC IR DECODER DRIVER
+M: James Hogan 
+S: Maintained
+F: drivers/media/rc/img-ir/
+
 IMS TWINTURBO FRAMEBUFFER DRIVER
 L: linux-fb...@vger.kernel.org
 S: Orphan
-- 
2.0.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

[REVIEW PATCH FOR v3.18 1/5] img-ir/hw: Always read data to clear buffer

[James Hogan]

From: Dylan Rajaratnam 

A problem was found on Polaris where if the unit it booted via the power
button on the infrared remote then the next button press on the remote
would return the key code used to power on the unit.

The sequence is:
 - The polaris powered off but with the powerdown controller (PDC) block
   still powered.
 - Press power key on remote, IR block receives the key.
 - Kernel starts, IR code is in IMG_IR_DATA_x but neither IMG_IR_RXDVAL
   or IMG_IR_RXDVALD2 are set.
 - Wait any amount of time.
 - Press any key.
 - IMG_IR_RXDVAL or IMG_IR_RXDVALD2 is set but IMG_IR_DATA_x is
   unchanged since the powerup key data was never read.

This is worked around by always reading the IMG_IR_DATA_x in
img_ir_set_decoder(), rather than only when the IMG_IR_RXDVAL or
IMG_IR_RXDVALD2 bit is set.

Signed-off-by: Dylan Rajaratnam 
Signed-off-by: James Hogan 
Cc: Mauro Carvalho Chehab 
Cc: linux-media@vger.kernel.org
Cc:  # v3.15+
---
 drivers/media/rc/img-ir/img-ir-hw.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/img-ir/img-ir-hw.c 
b/drivers/media/rc/img-ir/img-ir-hw.c
index ec49f94425fc..9db065344b41 100644
--- a/drivers/media/rc/img-ir/img-ir-hw.c
+++ b/drivers/media/rc/img-ir/img-ir-hw.c
@@ -541,10 +541,12 @@ static void img_ir_set_decoder(struct img_ir_priv *priv,
if (ir_status & (IMG_IR_RXDVAL | IMG_IR_RXDVALD2)) {
ir_status &= ~(IMG_IR_RXDVAL | IMG_IR_RXDVALD2);
img_ir_write(priv, IMG_IR_STATUS, ir_status);
-   img_ir_read(priv, IMG_IR_DATA_LW);
-   img_ir_read(priv, IMG_IR_DATA_UP);
}
 
+   /* always read data to clear buffer if IR wakes the device */
+   img_ir_read(priv, IMG_IR_DATA_LW);
+   img_ir_read(priv, IMG_IR_DATA_UP);
+
/* stop the end timer and switch back to normal mode */
del_timer_sync(&hw->end_timer);
hw->mode = IMG_IR_M_NORMAL;
-- 
2.0.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

[REVIEW PATCH 4/5] img-ir: Don't set driver's module owner

[James Hogan]

Don't bother setting .owner = THIS_MODULE, since it's already handled by
the platform_driver_register macro.

Signed-off-by: James Hogan 
Cc: Mauro Carvalho Chehab 
Cc: linux-media@vger.kernel.org
---
 drivers/media/rc/img-ir/img-ir-core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/rc/img-ir/img-ir-core.c 
b/drivers/media/rc/img-ir/img-ir-core.c
index a0cac2f09109..77c78de4f5bf 100644
--- a/drivers/media/rc/img-ir/img-ir-core.c
+++ b/drivers/media/rc/img-ir/img-ir-core.c
@@ -166,7 +166,6 @@ MODULE_DEVICE_TABLE(of, img_ir_match);
 static struct platform_driver img_ir_driver = {
.driver = {
.name = "img-ir",
-   .owner  = THIS_MODULE,
.of_match_table = img_ir_match,
.pm = &img_ir_pmops,
},
-- 
2.0.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

[REVIEW PATCH 3/5] img-ir: Depend on METAG or MIPS or COMPILE_TEST

[James Hogan]

The ImgTec Infrared decoder block which img-ir drives is only used in
IMGWorks SoCs so far, such as the TZ1090 (Meta based) and the upcoming
Pistachio (MIPS based). Therefore make the driver depend on METAG (for
TZ1090) or MIPS (for Pistachio) or COMPILE_TEST (so that it is included
in x86 allmodconfig builds), to avoid cluttering the Kconfig menu with
drivers for hardware that isn't yet available on other platforms.

Signed-off-by: James Hogan 
Cc: Mauro Carvalho Chehab 
Cc: linux-media@vger.kernel.org
---
 drivers/media/rc/img-ir/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/rc/img-ir/Kconfig b/drivers/media/rc/img-ir/Kconfig
index 03ba9fc170fb..580715c7fc5e 100644
--- a/drivers/media/rc/img-ir/Kconfig
+++ b/drivers/media/rc/img-ir/Kconfig
@@ -1,6 +1,7 @@
 config IR_IMG
tristate "ImgTec IR Decoder"
depends on RC_CORE
+   depends on METAG || MIPS || COMPILE_TEST
select IR_IMG_HW if !IR_IMG_RAW
help
   Say Y or M here if you want to use the ImgTec infrared decoder
-- 
2.0.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

[REVIEW PATCH 2/5] img-ir/hw: Drop [un]register_decoder declarations

[James Hogan]

The img_ir_register_decoder() and img_ir_unregister_decoder() functions
were dropped prior to the img-ir driver being applied to simplify the
protocol decoder setup. However the declarations of these functions in
img-ir-hw.h were still included. Delete them since they're completely
unused.

Signed-off-by: James Hogan 
Cc: Mauro Carvalho Chehab 
Cc: linux-media@vger.kernel.org
---
 drivers/media/rc/img-ir/img-ir-hw.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/rc/img-ir/img-ir-hw.h 
b/drivers/media/rc/img-ir/img-ir-hw.h
index 8fcc16c32c5b..a8c6a8d40206 100644
--- a/drivers/media/rc/img-ir/img-ir-hw.h
+++ b/drivers/media/rc/img-ir/img-ir-hw.h
@@ -186,9 +186,6 @@ struct img_ir_reg_timings {
struct img_ir_timing_regvalsrtimings;
 };
 
-int img_ir_register_decoder(struct img_ir_decoder *dec);
-void img_ir_unregister_decoder(struct img_ir_decoder *dec);
-
 struct img_ir_priv;
 
 #ifdef CONFIG_IR_IMG_HW
-- 
2.0.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

[REVIEW PATCH 0/5] img-ir: Some fixes

[James Hogan]

Here are a few fixes for the img-ir RC driver.

Patch 1 is the important one. I've tagged it for stable.

The other 4 are minor fixes/improvements that don't need backporting to
stable.

Dylan Rajaratnam (1):
  img-ir/hw: Always read data to clear buffer

James Hogan (4):
  img-ir/hw: Drop [un]register_decoder declarations
  img-ir: Depend on METAG or MIPS or COMPILE_TEST
  img-ir: Don't set driver's module owner
  MAINTAINERS: Add myself as img-ir maintainer

 MAINTAINERS   | 5 +
 drivers/media/rc/img-ir/Kconfig   | 1 +
 drivers/media/rc/img-ir/img-ir-core.c | 1 -
 drivers/media/rc/img-ir/img-ir-hw.c   | 6 --
 drivers/media/rc/img-ir/img-ir-hw.h   | 3 ---
 5 files changed, 10 insertions(+), 6 deletions(-)

-- 
2.0.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: [REVIEW] Submitting Media Patches

[James Hogan]

On 22 October 2014 15:12, Hans Verkuil  wrote:
> How to submit patches for a stable kernel
> =
>
> The standard method is to add this tag:
>
> Cc: sta...@vger.kernel.org
>
> possibly with a comment saying to which versions it should be applied, like:
>
> Cc: sta...@vger.kernel.org  # for v3.5 and up

Maybe put angled brackets around the email address. Some versions of
git-send-email get confused by the comment otherwise and try sending
to e.g. "".

Cheers
James
--
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/RFC v6 1/2] media: Add registration helpers for V4L2 flash

[Jacek Anaszewski]

Hi Sakari,

On 09/22/2014 05:21 PM, Jacek Anaszewski wrote:

This patch adds helper functions for registering/unregistering
LED class flash devices as V4L2 subdevs. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.

Signed-off-by: Jacek Anaszewski 
Acked-by: Kyungmin Park 
Cc: Sakari Ailus 
Cc: Hans Verkuil 
Cc: Bryan Wu 
Cc: Richard Purdie 
---
  drivers/media/v4l2-core/Kconfig  |   11 +
  drivers/media/v4l2-core/Makefile |2 +
  drivers/media/v4l2-core/v4l2-flash.c |  502 ++
  include/media/v4l2-flash.h   |  135 +
  4 files changed, 650 insertions(+)
  create mode 100644 drivers/media/v4l2-core/v4l2-flash.c
  create mode 100644 include/media/v4l2-flash.h


[...]

After discussing on IRC the way of using compound controls for
v4l2-flash sub-device I started to re-implement the patch but
encountered subsequent issues, which make my inclination for
abiding by the current version of the patch (separate v4l2-flash
device for each sub-led) even stronger.

Let's list arguments for both options:

1. Single v4l2-flash sub-device for a flash device that can control
   several sub-leds:

a) a flash device driver has one related i2c device
b) there exist hardware designs where some registers are
   shared between sub-leds (e.g. flash timeout, flash status)

2. Separate v4l2-flash sub-device for each sub-led of a flash device

a) LED Flash class drivers create separate LED Flash device for
  sub-leds (enforced by led-triggers design). This way there is
  a simple one-to-one "LED Flash device" - "v4l2-flash sub-device"
  relation.
b) if a single v4l2-flash sub-device was to control several
  LED Flash devices then array controls would have to be
  used for accessing the settings of every LED Flash device.
  This poses following issues:
- the type of each V4L2 Flash control would have to be
  set to the compound one (e.g. V4L2_CTRL_TYPE_U32), which in
  turn would make the menu controls unavailable for querying
  and displaying e.g. in qv4l2. Also the types as bitmask, button
  would have to be avoided.
- All elements of an array control have to have the same
  constraints and it would make impossible setting different min,
  max values (e.g. current, timeout, external strobe) for each
  sub-led. All the advantageous v4l2-ctrl mechanism related
  to validating and caching controls would have to be avoided
  and the user space would only get feedback in the form of
  failing ioctl when the value to be set is not properly aligned
- it is not possible to set only one element of the control
  array and thus the settings of each sub-led would have to be
  cached to avoid superfluous device register access
  (functionality already secured by non-array v4l2-controls)
- the flash devices supporting single led could be provided
  with standard non-array controls, but it would produce
  cumbersome v4l2-flash code and inconsistent user space interface

From the above it looks like the option 2. has much more advantages.
The argument 1.a doesn't seem to be so vital in view of the fact
that LED subsystem already breaks it. The argument 1.b can be obviated
by caching the relevant values in the driver as it is for max77693-led.

I think that choosing option 2. would allow for avoiding much work
that is already done in v4l2-ctrls.c. Moreover it would keep the
V4L2 Flash controls maintainable with qv4l2.

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

Re: [PATCH] media: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*()

[Prabhakar Lad]

Hi Sakari,

On Mon, Nov 17, 2014 at 10:53 AM, Sakari Ailus
 wrote:
> Hi Prabhakar,
>
> Thank you for the patch.
>
> Lad, Prabhakar wrote:
>>
>> this patch removes the guard CONFIG_VIDEO_V4L2_SUBDEV_API
>> for v4l2_subdev_get_try_*() functions.
>> In cases where a subdev using v4l2_subdev_get_try_*() calls
>> internally and the bridge using subdev pad ops which is
>> not MC aware forces to select MEDIA_CONTROLLER, as
>> VIDEO_V4L2_SUBDEV_API is dependent on it.
>>
>> Signed-off-by: Lad, Prabhakar 
>> ---
>>   include/media/v4l2-subdev.h | 2 --
>>   1 file changed, 2 deletions(-)
>>
>> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
>> index 5860292..076ca11 100644
>> --- a/include/media/v4l2-subdev.h
>> +++ b/include/media/v4l2-subdev.h
>> @@ -642,7 +642,6 @@ struct v4l2_subdev_fh {
>>   #define to_v4l2_subdev_fh(fh) \
>> container_of(fh, struct v4l2_subdev_fh, vfh)
>>
>> -#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
>
>
> Wouldn't you need to drop these from struct v4l2_subdev_fh as well? The code
> won't compile if the fields aren't there.
>
Ah missed it, thanks for the catch!

Thanks,
--Prabhakar Lad

>>   #define __V4L2_SUBDEV_MK_GET_TRY(rtype, fun_name, field_name) \
>> static inline struct rtype *\
>> v4l2_subdev_get_try_##fun_name(struct v4l2_subdev_fh *fh,   \
>> @@ -656,7 +655,6 @@ struct v4l2_subdev_fh {
>>   __V4L2_SUBDEV_MK_GET_TRY(v4l2_mbus_framefmt, format, try_fmt)
>>   __V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, crop, try_crop)
>>   __V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, compose, try_compose)
>> -#endif
>>
>>   extern const struct v4l2_file_operations v4l2_subdev_fops;
>>
>>
>
> --
> Kind regards,
>
> Sakari Ailus
> sakari.ai...@linux.intel.com
--
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: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*()

[Sakari Ailus]

Hi Prabhakar,

Thank you for the patch.

Lad, Prabhakar wrote:

this patch removes the guard CONFIG_VIDEO_V4L2_SUBDEV_API
for v4l2_subdev_get_try_*() functions.
In cases where a subdev using v4l2_subdev_get_try_*() calls
internally and the bridge using subdev pad ops which is
not MC aware forces to select MEDIA_CONTROLLER, as
VIDEO_V4L2_SUBDEV_API is dependent on it.

Signed-off-by: Lad, Prabhakar 
---
  include/media/v4l2-subdev.h | 2 --
  1 file changed, 2 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 5860292..076ca11 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -642,7 +642,6 @@ struct v4l2_subdev_fh {
  #define to_v4l2_subdev_fh(fh) \
container_of(fh, struct v4l2_subdev_fh, vfh)

-#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)


Wouldn't you need to drop these from struct v4l2_subdev_fh as well? The 
code won't compile if the fields aren't there.



  #define __V4L2_SUBDEV_MK_GET_TRY(rtype, fun_name, field_name) \
static inline struct rtype *\
v4l2_subdev_get_try_##fun_name(struct v4l2_subdev_fh *fh,   \
@@ -656,7 +655,6 @@ struct v4l2_subdev_fh {
  __V4L2_SUBDEV_MK_GET_TRY(v4l2_mbus_framefmt, format, try_fmt)
  __V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, crop, try_crop)
  __V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, compose, try_compose)
-#endif

  extern const struct v4l2_file_operations v4l2_subdev_fops;




--
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com
--
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: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*()

[Lad, Prabhakar]

this patch removes the guard CONFIG_VIDEO_V4L2_SUBDEV_API
for v4l2_subdev_get_try_*() functions.
In cases where a subdev using v4l2_subdev_get_try_*() calls
internally and the bridge using subdev pad ops which is
not MC aware forces to select MEDIA_CONTROLLER, as
VIDEO_V4L2_SUBDEV_API is dependent on it.

Signed-off-by: Lad, Prabhakar 
---
 include/media/v4l2-subdev.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 5860292..076ca11 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -642,7 +642,6 @@ struct v4l2_subdev_fh {
 #define to_v4l2_subdev_fh(fh)  \
container_of(fh, struct v4l2_subdev_fh, vfh)
 
-#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
 #define __V4L2_SUBDEV_MK_GET_TRY(rtype, fun_name, field_name)  \
static inline struct rtype *\
v4l2_subdev_get_try_##fun_name(struct v4l2_subdev_fh *fh,   \
@@ -656,7 +655,6 @@ struct v4l2_subdev_fh {
 __V4L2_SUBDEV_MK_GET_TRY(v4l2_mbus_framefmt, format, try_fmt)
 __V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, crop, try_crop)
 __V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, compose, try_compose)
-#endif
 
 extern const struct v4l2_file_operations v4l2_subdev_fops;
 
-- 
1.9.1

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

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Pavel Machek]

On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
> On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
> > Hi!
> > 
> > On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> > > On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> > > > For device tree people: Yes, I know I'll have to create
> > > > file in documentation, but does the binding below look
> > > > acceptable?
> > > > 
> > > > I'll clean up driver code a bit more, remove the printks.
> > > > Anything else obviously wrong?
> > > 
> > > I think that this patch is probably not good and specially
> > > not for n900. adp1653 should be registered throw omap3 isp
> > > camera subsystem which does not have DT support yet.
> > 
> > Can you explain?
> > 
> > adp1653 is independend device on i2c bus, and we have kernel
> > driver for it (unlike rest of n900 camera system). Just now
> > it is unusable due to lack of DT binding. It has two
> > functions, LED light and a camera flash; yes, the second one
> > should be integrated to the rest of camera system, but that
> > is not yet merged. That should not prevent us from merging DT
> > support for the flash, so that this part can be
> > tested/maintained.
> > 
> 
> Ok. When ISP camera subsystem has DT support somebody will modify 
> n900 DT to add camera flash from adp1653 to ISP... I believe it 
> will not be hard.

Exactly. And yes, I'd like to get complete camera support for n900
merged. But first step is "make sure existing support does not break".

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: STK1160 Sharpness

[Mauro Carvalho Chehab]

Em Mon, 17 Nov 2014 12:51:46 +0300
Барт Гопник  escreveu:

> (Where) can I find the the full list of the (key) differences between
> SAA7113 and GM7113?

I've no idea. Perhaps you would need to get both datasheets and compare
them.

> If it is not hard to do it, can anybody please implement it?

The hardest part seems to graduate the sharpness levels, as sharpness
actually is split into 3 different controls.

Of course, one interested on doing that would need to have a device
with the needed chipsets and time/interest on doing that.

Adding control framework at stk1160 also requires some time. I can't
volunteer myself of doing that. I don't have any stk1160-based
devices.

> Unfortunately, I'm not very good with system drivers programming.
> 
> I'm interesting only in sharpness control because the image quality
> (sharpness) during capture using CVBS input is bad (on my EasyCap
> device). If I use S-Video input, the quality (sharpness) is better. 

Yeah, the saa7115 datasheet (freely available at NXP site) mentions that 
sharpness control may be needed for some kinds of output.

> It is important to implement it, because the sharpness control
> implemented in hardware (not in software, post-processing filtering).
> Control of other parameters like gamma are also don't work, but I'm
> not sure that gamma control is hardware (not software) implemented
> (I'm not found any info about gamma in saa7113 datasheet).

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

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Pali Rohár]

On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
> Hi!
> 
> On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> > On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> > > For device tree people: Yes, I know I'll have to create
> > > file in documentation, but does the binding below look
> > > acceptable?
> > > 
> > > I'll clean up driver code a bit more, remove the printks.
> > > Anything else obviously wrong?
> > 
> > I think that this patch is probably not good and specially
> > not for n900. adp1653 should be registered throw omap3 isp
> > camera subsystem which does not have DT support yet.
> 
> Can you explain?
> 
> adp1653 is independend device on i2c bus, and we have kernel
> driver for it (unlike rest of n900 camera system). Just now
> it is unusable due to lack of DT binding. It has two
> functions, LED light and a camera flash; yes, the second one
> should be integrated to the rest of camera system, but that
> is not yet merged. That should not prevent us from merging DT
> support for the flash, so that this part can be
> tested/maintained.
> 

Ok. When ISP camera subsystem has DT support somebody will modify 
n900 DT to add camera flash from adp1653 to ISP... I believe it 
will not be hard.

> > See n900 legacy board camera code in file
> > board-rx51-camera.c.
> 
> I have seen that.
>   Pavel

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Pavel Machek]

Hi!

On Mon 2014-11-17 09:43:19, Pali Rohár wrote:
> On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> > For device tree people: Yes, I know I'll have to create file
> > in documentation, but does the binding below look acceptable?
> > 
> > I'll clean up driver code a bit more, remove the printks.
> > Anything else obviously wrong?

> I think that this patch is probably not good and specially not 
> for n900. adp1653 should be registered throw omap3 isp camera 
> subsystem which does not have DT support yet.

Can you explain?

adp1653 is independend device on i2c bus, and we have kernel driver
for it (unlike rest of n900 camera system). Just now it is unusable
due to lack of DT binding. It has two functions, LED light and a
camera flash; yes, the second one should be integrated to the rest of
camera system, but that is not yet merged. That should not prevent us
from merging DT support for the flash, so that this part can be
tested/maintained.

> See n900 legacy board camera code in file board-rx51-camera.c.

I have seen that.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: STK1160 Sharpness

[Барт Гопник]

(Where) can I find the the full list of the (key) differences between
SAA7113 and GM7113?

If it is not hard to do it, can anybody please implement it?
Unfortunately, I'm not very good with system drivers programming.

I'm interesting only in sharpness control because the image quality
(sharpness) during capture using CVBS input is bad (on my EasyCap
device). If I use S-Video input, the quality (sharpness) is better. It
is important to implement it, because the sharpness control
implemented in hardware (not in software, post-processing filtering).
Control of other parameters like gamma are also don't work, but I'm
not sure that gamma control is hardware (not software) implemented
(I'm not found any info about gamma in saa7113 datasheet).
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 07/11] v4l2-ctrls: implement 'ignore after use' support.

[Hans Verkuil]

On 11/17/2014 10:31 AM, Sakari Ailus wrote:
> Hi Hans,
> 
> On Mon, Nov 17, 2014 at 10:02:03AM +0100, Hans Verkuil wrote:
>> On 11/15/2014 10:10 PM, Sakari Ailus wrote:
 @@ -197,6 +207,8 @@ struct v4l2_ctrl {
u32 nr_of_dims;
u16 nr_of_stores;
u16 store;
 +  DECLARE_BITMAP(ignore_store, V4L2_CTRLS_MAX_STORES);
 +  DECLARE_BITMAP(ignore_store_after_use, V4L2_CTRLS_MAX_STORES);
>>>
>>> I'd store this information next to the value itself. The reason is that
>>> stores are typically accessed one at a time, and thus keeping data related
>>> to a single store in a single contiguous location reduces cache misses.
>>
>> Hmm, sounds like overengineering to me. If I can do that without sacrificing
>> readability, then I can more it around. It's likely that these datastructures
>> will change anyway.
> 
> The controls are accessed very often in practice so this kind of things
> count. There's already a lot of code which gets executed in order to set a
> single control that's relevant only in some cases, such as clusters.

Complexity is the biggest problem in video drivers, not speed. Optimizations for
the sake of speeding up code at the expense of complexity should only be 
implemented
if you can *prove* that there is a measurable speedup.

Personally I would be very surprised if you can measure this in this specific
case.

Anyway, it doesn't matter in this case since I intend to rework those data
structures in any case.

Regards,

Hans

> I think it'd probably be more readable as well if information related to a
> store was located in a single place. As a bonus you wouldn't need to set a
> global maximum for the number of stores one may have.

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

Re: [RFC PATCH 07/11] v4l2-ctrls: implement 'ignore after use' support.

[Sakari Ailus]

Hi Hans,

On Mon, Nov 17, 2014 at 10:02:03AM +0100, Hans Verkuil wrote:
> On 11/15/2014 10:10 PM, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > A few comments below.
> > 
> > On Sun, Sep 21, 2014 at 04:48:25PM +0200, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
> >> Sometimes you want to apply a value every time v4l2_ctrl_apply_store
> >> is called, and sometimes you want to apply that value only once.
> >>
> >> This adds support for that feature.
> >>
> >> Signed-off-by: Hans Verkuil 
> >> ---
> >>  drivers/media/v4l2-core/v4l2-ctrls.c | 75 
> >> 
> >>  drivers/media/v4l2-core/v4l2-ioctl.c | 14 +++
> >>  include/media/v4l2-ctrls.h   | 12 ++
> >>  3 files changed, 79 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> >> b/drivers/media/v4l2-core/v4l2-ctrls.c
> >> index e5dccf2..21560b0 100644
> >> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> >> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> >> @@ -1475,6 +1475,7 @@ static int ptr_to_user(struct v4l2_ext_control *c,
> >>  static int cur_to_user(struct v4l2_ext_control *c,
> >>   struct v4l2_ctrl *ctrl)
> >>  {
> >> +  c->flags = 0;
> >>return ptr_to_user(c, ctrl, ctrl->p_cur);
> >>  }
> >>  
> >> @@ -1482,8 +1483,13 @@ static int cur_to_user(struct v4l2_ext_control *c,
> >>  static int store_to_user(struct v4l2_ext_control *c,
> >>   struct v4l2_ctrl *ctrl, unsigned store)
> >>  {
> >> +  c->flags = 0;
> >>if (store == 0)
> >>return ptr_to_user(c, ctrl, ctrl->p_new);
> >> +  if (test_bit(store - 1, ctrl->cluster[0]->ignore_store_after_use))
> >> +  c->flags |= V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE;
> >> +  if (test_bit(store - 1, ctrl->cluster[0]->ignore_store))
> >> +  c->flags |= V4L2_EXT_CTRL_FL_IGN_STORE;
> >>return ptr_to_user(c, ctrl, ctrl->p_stores[store - 1]);
> >>  }
> >>  
> >> @@ -1491,6 +1497,7 @@ static int store_to_user(struct v4l2_ext_control *c,
> >>  static int new_to_user(struct v4l2_ext_control *c,
> >>   struct v4l2_ctrl *ctrl)
> >>  {
> >> +  c->flags = 0;
> >>return ptr_to_user(c, ctrl, ctrl->p_new);
> >>  }
> >>  
> >> @@ -1546,6 +1553,8 @@ static int user_to_ptr(struct v4l2_ext_control *c,
> >>  static int user_to_new(struct v4l2_ext_control *c,
> >>   struct v4l2_ctrl *ctrl)
> >>  {
> >> +  ctrl->cluster[0]->new_ignore_store_after_use =
> >> +  c->flags & V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE;
> >>return user_to_ptr(c, ctrl, ctrl->p_new);
> >>  }
> >>  
> >> @@ -1597,8 +1606,11 @@ static void new_to_cur(struct v4l2_fh *fh, struct 
> >> v4l2_ctrl *ctrl, u32 ch_flags)
> >>  /* Helper function: copy the new control value to the store */
> >>  static void new_to_store(struct v4l2_ctrl *ctrl)
> >>  {
> >> +  if (ctrl == NULL)
> >> +  return;
> >> +
> >>/* has_changed is set by cluster_changed */
> >> -  if (ctrl && ctrl->has_changed)
> >> +  if (ctrl->has_changed)
> >>ptr_to_ptr(ctrl, ctrl->p_new, ctrl->p_stores[ctrl->store - 1]);
> >>  }
> >>  
> >> @@ -2328,6 +2340,12 @@ void v4l2_ctrl_cluster(unsigned ncontrols, struct 
> >> v4l2_ctrl **controls)
> >>  
> >>for (i = 0; i < ncontrols; i++) {
> >>if (controls[i]) {
> >> +  /*
> >> +   * All controls in a cluster must have the same
> >> +   * V4L2_CTRL_FLAG_CAN_STORE flag value.
> >> +   */
> >> +  WARN_ON((controls[0]->flags & controls[i]->flags) &
> >> +  V4L2_CTRL_FLAG_CAN_STORE);
> >>controls[i]->cluster = controls;
> >>controls[i]->ncontrols = ncontrols;
> >>if (controls[i]->flags & V4L2_CTRL_FLAG_VOLATILE)
> >> @@ -2850,6 +2868,10 @@ static int extend_store(struct v4l2_ctrl *ctrl, 
> >> unsigned stores)
> >>unsigned s, idx;
> >>union v4l2_ctrl_ptr *p;
> >>  
> >> +  /* round up to the next multiple of 4 */
> >> +  stores = (stores + 3) & ~3;
> > 
> > You said it, round_up(). :-)
> > 
> > The comment becomes redundant as a result, too.
> > 
> > The above may also overflow. 
> 
> Will fix.

I just realised round_up() will naturally also overflow, but it'll overflow
"correctly" to zero. So the upper limit check must be before this. The
change then effectually only makes the comment unnecessary.

> > 
> >> +  if (stores > V4L2_CTRLS_MAX_STORES)
> >> +  return -EINVAL;
> >>p = kcalloc(stores, sizeof(union v4l2_ctrl_ptr), GFP_KERNEL);
> >>if (p == NULL)
> >>return -ENOMEM;
> >> @@ -2868,6 +2890,7 @@ static int extend_store(struct v4l2_ctrl *ctrl, 
> >> unsigned stores)
> >>memcpy(p, ctrl->p_stores, ctrl->nr_of_stores * sizeof(union 
> >> v4l2_ctrl_ptr));
> >>kfree(ctrl->p_stores);
> >>ctrl->p_stores = p;
> >> +  bitmap_set(ctrl->ignore_store, ctrl->nr_of_stores, stores - 
> >> ctrl->nr_of_stores);
> >>ctrl->nr_of

Re: [PATCH 2/3] v4l: Add V4L2_SEL_TGT_NATIVE_SIZE selection target

[Hans Verkuil]

On 11/16/2014 05:40 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> Thank you for the review.
> 
> On Fri, Nov 14, 2014 at 09:46:54AM +0100, Hans Verkuil wrote:
>> On 11/09/2014 12:04 AM, Sakari Ailus wrote:
>>> The V4L2_SEL_TGT_NATIVE_SIZE target is used to denote e.g. the size of a
>>> sensor's pixel array.
>>>
>>> Signed-off-by: Sakari Ailus 
>>> ---
>>>  Documentation/DocBook/media/v4l/selections-common.xml |8 
>>>  include/uapi/linux/v4l2-common.h  |2 ++
>>>  2 files changed, 10 insertions(+)
>>>
>>> diff --git a/Documentation/DocBook/media/v4l/selections-common.xml 
>>> b/Documentation/DocBook/media/v4l/selections-common.xml
>>> index 7502f78..5fc833a 100644
>>> --- a/Documentation/DocBook/media/v4l/selections-common.xml
>>> +++ b/Documentation/DocBook/media/v4l/selections-common.xml
>>> @@ -63,6 +63,14 @@
>>> Yes
>>>   
>>>   
>>> +   V4L2_SEL_TGT_NATIVE_SIZE
>>> +   0x0003
>>> +   The native size of the device, e.g. a sensor's
>>> +   pixel array.
>>
>> You might want to state that top and left are always 0.
> 
> Fixed. I also added a patch to fix this in the smiapp driver --- the values
> were uninitialised. :-P
> 
>>> +   Yes
>>> +   Yes
>>> + 
>>> + 
>>> V4L2_SEL_TGT_COMPOSE
>>> 0x0100
>>> Compose rectangle. Used to configure scaling
>>> diff --git a/include/uapi/linux/v4l2-common.h 
>>> b/include/uapi/linux/v4l2-common.h
>>> index 2f6f8ca..1527398 100644
>>> --- a/include/uapi/linux/v4l2-common.h
>>> +++ b/include/uapi/linux/v4l2-common.h
>>> @@ -43,6 +43,8 @@
>>>  #define V4L2_SEL_TGT_CROP_DEFAULT  0x0001
>>>  /* Cropping bounds */
>>>  #define V4L2_SEL_TGT_CROP_BOUNDS   0x0002
>>> +/* Native frame size */
>>> +#define V4L2_SEL_TGT_NATIVE_SIZE   0x0003
>>>  /* Current composing area */
>>>  #define V4L2_SEL_TGT_COMPOSE   0x0100
>>>  /* Default composing area */
>>>
>>
>> I like this. This would also make it possible to set the 'canvas' size of an
>> mem2mem device. Currently calling S_FMT for a mem2mem device cannot setup any
>> scaler since there is no native size. Instead S_FMT effectively *sets* the 
>> native
>> size. The same is true for webcams with a scaler, which is why you added 
>> this in
>> the first place. Obviously for sensors this target is read-only, but for a 
>> mem2mem
>> device it can be writable as well.
>>
>> However, to make full use of this you also need to add input and output
>> capabilities if the native size can be set:
>>
>>  V4L2_IN_CAP_NATIVE_SIZE
>>  V4L2_OUT_CAP_NATIVE_SIZE
> 
> Do you think this would require a capability flag, rather than just
> returning an error if the target is unsettable, as we otherwise already do
> if a selection target isn't supported? For the compound controls it's even
> easier, you just don't have a read-only flag set in the equivalent control.

No, I really want a capability flag here. Otherwise applications would have to
call ENUMINPUT *and* call G_SELECTION followed by S_SELECTION just to test if
it can be set. Besides, this is also a per-input capability, so you want to get
hold of the capabilities without having to do a S_INPUT first. I.e. you don't
want to have to do this:

// pseudo code just to give the idea
for (i = 0; i < max_input; i++) {
struct v4l2_selection sel = { NATIVE_SIZE };

ioctl(S_INPUT, i);
ioctl(G_SELECTION, &sel);
if (ioctl(S_SELECTION, &sel))
// does not support NATIVE_SIZE
}

> 
>> (see ENUMINPUT/ENUMOUTPUT)
>>
>> This would nicely fill in a hole in the V4L2 Spec.
> 

Regards,

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

Re: [RFCv6 PATCH 04/16] vb2-dma-sg: add allocation context to dma-sg

[Hans Verkuil]

Hi Pawel,

On 11/16/2014 02:13 PM, Pawel Osciak wrote:
> On Mon, Nov 10, 2014 at 8:49 PM, Hans Verkuil  wrote:
>> From: Hans Verkuil 
>>
>> Require that dma-sg also uses an allocation context. This is in preparation
>> for adding prepare/finish memops to sync the memory between DMA and CPU.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
> 
> [...]
> 
>> @@ -166,6 +177,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, 
>> unsigned long vaddr,
>> unsigned long size,
>> enum dma_data_direction dma_dir)
>>  {
>> +   struct vb2_dma_sg_conf *conf = alloc_ctx;
>> struct vb2_dma_sg_buf *buf;
>> unsigned long first, last;
>> int num_pages_from_user;
>> @@ -235,6 +247,8 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, 
>> unsigned long vaddr,
>> buf->num_pages, buf->offset, size, 0))
>> goto userptr_fail_alloc_table_from_pages;
>>
>> +   /* Prevent the device from being released while the buffer is used */
>> +   buf->dev = get_device(conf->dev);
> 
> I'm not sure if we should be managing this... As far as I understand
> the logic behind taking a ref in alloc, if we are the exporter, we may
> have to keep it in case we need to free the buffers after our device
> goes away. But for userptr, we only need this for syncs, and in that
> case it's triggered by our driver, so I think we don't have to worry
> about that. If we do though, then dma-contig should be doing this as
> well.

You are correct. I'll remove this for get/put_userptr.

> 
>> return buf;
>>
>>  userptr_fail_alloc_table_from_pages:
>> @@ -274,6 +288,7 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
>> }
>> kfree(buf->pages);
>> vb2_put_vma(buf->vma);
>> +   put_device(buf->dev);
>> kfree(buf);
>>  }
>>
>> @@ -356,6 +371,27 @@ const struct vb2_mem_ops vb2_dma_sg_memops = {
>>  };
>>  EXPORT_SYMBOL_GPL(vb2_dma_sg_memops);
>>
>> +void *vb2_dma_sg_init_ctx(struct device *dev)
>> +{
>> +   struct vb2_dma_sg_conf *conf;
>> +
>> +   conf = kzalloc(sizeof(*conf), GFP_KERNEL);
>> +   if (!conf)
>> +   return ERR_PTR(-ENOMEM);
>> +
>> +   conf->dev = dev;
>> +
>> +   return conf;
>> +}
>> +EXPORT_SYMBOL_GPL(vb2_dma_sg_init_ctx);
>> +
>> +void vb2_dma_sg_cleanup_ctx(void *alloc_ctx)
>> +{
>> +   if (!IS_ERR_OR_NULL(alloc_ctx))
> 
> I would prefer not doing this, it's very weird and would really just
> be a programming bug.

Erm, I rather like it since it allows you to call cleanup_ctx even if init_ctx
failed. It's actually used like that in the solo driver. Basically for the same
reason that kfree can handle a NULL pointer. Although if I do it here, then it
should also be added to dma-contig.

Regards,

Hans

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

Re: [RFC PATCH 07/11] v4l2-ctrls: implement 'ignore after use' support.

[Hans Verkuil]

On 11/15/2014 10:10 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> A few comments below.
> 
> On Sun, Sep 21, 2014 at 04:48:25PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Sometimes you want to apply a value every time v4l2_ctrl_apply_store
>> is called, and sometimes you want to apply that value only once.
>>
>> This adds support for that feature.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  drivers/media/v4l2-core/v4l2-ctrls.c | 75 
>> 
>>  drivers/media/v4l2-core/v4l2-ioctl.c | 14 +++
>>  include/media/v4l2-ctrls.h   | 12 ++
>>  3 files changed, 79 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>> index e5dccf2..21560b0 100644
>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>> @@ -1475,6 +1475,7 @@ static int ptr_to_user(struct v4l2_ext_control *c,
>>  static int cur_to_user(struct v4l2_ext_control *c,
>> struct v4l2_ctrl *ctrl)
>>  {
>> +c->flags = 0;
>>  return ptr_to_user(c, ctrl, ctrl->p_cur);
>>  }
>>  
>> @@ -1482,8 +1483,13 @@ static int cur_to_user(struct v4l2_ext_control *c,
>>  static int store_to_user(struct v4l2_ext_control *c,
>> struct v4l2_ctrl *ctrl, unsigned store)
>>  {
>> +c->flags = 0;
>>  if (store == 0)
>>  return ptr_to_user(c, ctrl, ctrl->p_new);
>> +if (test_bit(store - 1, ctrl->cluster[0]->ignore_store_after_use))
>> +c->flags |= V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE;
>> +if (test_bit(store - 1, ctrl->cluster[0]->ignore_store))
>> +c->flags |= V4L2_EXT_CTRL_FL_IGN_STORE;
>>  return ptr_to_user(c, ctrl, ctrl->p_stores[store - 1]);
>>  }
>>  
>> @@ -1491,6 +1497,7 @@ static int store_to_user(struct v4l2_ext_control *c,
>>  static int new_to_user(struct v4l2_ext_control *c,
>> struct v4l2_ctrl *ctrl)
>>  {
>> +c->flags = 0;
>>  return ptr_to_user(c, ctrl, ctrl->p_new);
>>  }
>>  
>> @@ -1546,6 +1553,8 @@ static int user_to_ptr(struct v4l2_ext_control *c,
>>  static int user_to_new(struct v4l2_ext_control *c,
>> struct v4l2_ctrl *ctrl)
>>  {
>> +ctrl->cluster[0]->new_ignore_store_after_use =
>> +c->flags & V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE;
>>  return user_to_ptr(c, ctrl, ctrl->p_new);
>>  }
>>  
>> @@ -1597,8 +1606,11 @@ static void new_to_cur(struct v4l2_fh *fh, struct 
>> v4l2_ctrl *ctrl, u32 ch_flags)
>>  /* Helper function: copy the new control value to the store */
>>  static void new_to_store(struct v4l2_ctrl *ctrl)
>>  {
>> +if (ctrl == NULL)
>> +return;
>> +
>>  /* has_changed is set by cluster_changed */
>> -if (ctrl && ctrl->has_changed)
>> +if (ctrl->has_changed)
>>  ptr_to_ptr(ctrl, ctrl->p_new, ctrl->p_stores[ctrl->store - 1]);
>>  }
>>  
>> @@ -2328,6 +2340,12 @@ void v4l2_ctrl_cluster(unsigned ncontrols, struct 
>> v4l2_ctrl **controls)
>>  
>>  for (i = 0; i < ncontrols; i++) {
>>  if (controls[i]) {
>> +/*
>> + * All controls in a cluster must have the same
>> + * V4L2_CTRL_FLAG_CAN_STORE flag value.
>> + */
>> +WARN_ON((controls[0]->flags & controls[i]->flags) &
>> +V4L2_CTRL_FLAG_CAN_STORE);
>>  controls[i]->cluster = controls;
>>  controls[i]->ncontrols = ncontrols;
>>  if (controls[i]->flags & V4L2_CTRL_FLAG_VOLATILE)
>> @@ -2850,6 +2868,10 @@ static int extend_store(struct v4l2_ctrl *ctrl, 
>> unsigned stores)
>>  unsigned s, idx;
>>  union v4l2_ctrl_ptr *p;
>>  
>> +/* round up to the next multiple of 4 */
>> +stores = (stores + 3) & ~3;
> 
> You said it, round_up(). :-)
> 
> The comment becomes redundant as a result, too.
> 
> The above may also overflow. 

Will fix.

> 
>> +if (stores > V4L2_CTRLS_MAX_STORES)
>> +return -EINVAL;
>>  p = kcalloc(stores, sizeof(union v4l2_ctrl_ptr), GFP_KERNEL);
>>  if (p == NULL)
>>  return -ENOMEM;
>> @@ -2868,6 +2890,7 @@ static int extend_store(struct v4l2_ctrl *ctrl, 
>> unsigned stores)
>>  memcpy(p, ctrl->p_stores, ctrl->nr_of_stores * sizeof(union 
>> v4l2_ctrl_ptr));
>>  kfree(ctrl->p_stores);
>>  ctrl->p_stores = p;
>> +bitmap_set(ctrl->ignore_store, ctrl->nr_of_stores, stores - 
>> ctrl->nr_of_stores);
>>  ctrl->nr_of_stores = stores;
>>  return 0;
>>  }
>> @@ -3081,21 +3104,33 @@ static int try_or_set_cluster(struct v4l2_fh *fh, 
>> struct v4l2_ctrl *master,
>>  
>>  ret = call_op(master, try_ctrl);
>>  
>> -/* Don't set if there is no change */
>> -if (ret || !set || !cluster_changed(master))
>> -return ret;
>> -ret = call_op(master, s_ctrl);
>> -if (ret)
>> +if (ret || !set)
>>  re

Re: [RFC PATCH 06/11] videodev2.h: add new v4l2_ext_control flags field

[Hans Verkuil]

On 11/15/2014 06:44 PM, Sakari Ailus wrote:
> Hi,
> 
> On Sat, Nov 15, 2014 at 04:18:59PM +0200, Sakari Ailus wrote:
> ...
>>> union {
>>> __s32 value;
>>> __s64 value64;
>>> @@ -1294,6 +1294,10 @@ struct v4l2_ext_control {
>>> };
>>>  } __attribute__ ((packed));
>>>  
>>> +/* v4l2_ext_control flags */
>>> +#define V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE   0x0001
>>> +#define V4L2_EXT_CTRL_FL_IGN_STORE 0x0002
>>
>> Do we need both? Aren't these mutually exclusive, and you must have either
>> to be meaningful in the context of a store?
> 
> Ah. Now I think I understand what do these mean. Please ignore my previous
> comment.
> 
> I might call them differently. What would you think of

I was never happy with the naming :-)

> V4L2_EXT_CTRL_FL_STORE_IGNORE and V4L2_EXT_CTRL_FL_STORE_ONCE?

I will give this some more thought.

> V4L2_EXT_CTRL_FL_IGN_STORE_AFTER_USE is quite long IMO. Up to you.
> 
> I wonder if we need EXT in V4L2_EXT_CTRL_FL. It's logical but also
> redundant since the old control interface won't have flags either.

True.

> I'd assume that for cameras the vast majority of users will always want to
> just apply the values once. How are the use cases in video decoding?

I am wondering whether 'apply once' shouldn't be the default and whether I
really need to implement the 'apply always' (Hey, not bad names either!)
functionality for this initial version.

I only used the 'apply always' functionality for a somewhat contrived test
example where I changed the cropping rectangle (this is with the selection
controls from patch 10/11) for each buffer so that while streaming I would
get a continuous zoom-in/zoom-out effect. While nice for testing, it isn't
really practical in reality.

Regards,

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

Re: [RFC PATCH 06/11] videodev2.h: add new v4l2_ext_control flags field

[Hans Verkuil]

On 11/15/2014 03:18 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> On Sun, Sep 21, 2014 at 04:48:24PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Replace reserved2 by a flags field. This is used to tell whether
>> setting a new store value is applied only once or every time that
>> v4l2_ctrl_apply_store() is called for that store.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  include/uapi/linux/videodev2.h | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 2ca44ed..fa84070 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -1282,7 +1282,7 @@ struct v4l2_control {
>>  struct v4l2_ext_control {
>>  __u32 id;
>>  __u32 size;
>> -__u32 reserved2[1];
>> +__u32 flags;
> 
> 16 bits, please.

Good idea.

> The pad number (for sub-devices) would need to be added
> here as well,

Why? We never needed that for subdevs in the past. Not that I am against
reserving space for it, I'm just wondering if you have something specific
in mind.

> and that's 16 bits. A flag might be needed to tell it's valid,
> too.

Regards,

Hans

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

Re: [RFC PATCH 04/11] v4l2-ctrls: add config store support

[Hans Verkuil]

On 11/14/2014 04:44 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> Some comments below.
> 
> On Sun, Sep 21, 2014 at 04:48:22PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  drivers/media/v4l2-core/v4l2-ctrls.c | 150 
>> +--
>>  drivers/media/v4l2-core/v4l2-ioctl.c |   4 +-
>>  include/media/v4l2-ctrls.h   |  14 
>>  3 files changed, 141 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>> index 35d1f3d..df0f3ee 100644
>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>> @@ -1478,6 +1478,15 @@ static int cur_to_user(struct v4l2_ext_control *c,
>>  return ptr_to_user(c, ctrl, ctrl->p_cur);
>>  }
>>  
>> +/* Helper function: copy the store's control value back to the caller */
>> +static int store_to_user(struct v4l2_ext_control *c,
>> +   struct v4l2_ctrl *ctrl, unsigned store)
>> +{
>> +if (store == 0)
>> +return ptr_to_user(c, ctrl, ctrl->p_new);
>> +return ptr_to_user(c, ctrl, ctrl->p_stores[store - 1]);
>> +}
>> +
>>  /* Helper function: copy the new control value back to the caller */
>>  static int new_to_user(struct v4l2_ext_control *c,
>> struct v4l2_ctrl *ctrl)
>> @@ -1585,6 +1594,14 @@ static void new_to_cur(struct v4l2_fh *fh, struct 
>> v4l2_ctrl *ctrl, u32 ch_flags)
>>  }
>>  }
>>  
>> +/* Helper function: copy the new control value to the store */
>> +static void new_to_store(struct v4l2_ctrl *ctrl)
>> +{
>> +/* has_changed is set by cluster_changed */
>> +if (ctrl && ctrl->has_changed)
>> +ptr_to_ptr(ctrl, ctrl->p_new, ctrl->p_stores[ctrl->store - 1]);
>> +}
>> +
>>  /* Copy the current value to the new value */
>>  static void cur_to_new(struct v4l2_ctrl *ctrl)
>>  {
>> @@ -1603,13 +1620,18 @@ static int cluster_changed(struct v4l2_ctrl *master)
>>  
>>  for (i = 0; i < master->ncontrols; i++) {
>>  struct v4l2_ctrl *ctrl = master->cluster[i];
>> +union v4l2_ctrl_ptr ptr;
>>  bool ctrl_changed = false;
>>  
>>  if (ctrl == NULL)
>>  continue;
>> +if (ctrl->store)
>> +ptr = ctrl->p_stores[ctrl->store - 1];
>> +else
>> +ptr = ctrl->p_cur;
>>  for (idx = 0; !ctrl_changed && idx < ctrl->elems; idx++)
>>  ctrl_changed = !ctrl->type_ops->equal(ctrl, idx,
>> -ctrl->p_cur, ctrl->p_new);
>> +ptr, ctrl->p_new);
>>  ctrl->has_changed = ctrl_changed;
>>  changed |= ctrl->has_changed;
>>  }
>> @@ -1740,6 +1762,13 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler 
>> *hdl)
>>  list_del(&ctrl->node);
>>  list_for_each_entry_safe(sev, next_sev, &ctrl->ev_subs, node)
>>  list_del(&sev->node);
>> +if (ctrl->p_stores) {
>> +unsigned s;
>> +
>> +for (s = 0; s < ctrl->nr_of_stores; s++)
>> +kfree(ctrl->p_stores[s].p);
>> +}
>> +kfree(ctrl->p_stores);
>>  kfree(ctrl);
>>  }
>>  kfree(hdl->buckets);
>> @@ -1970,7 +1999,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
>> v4l2_ctrl_handler *hdl,
>>  handler_set_err(hdl, -ERANGE);
>>  return NULL;
>>  }
>> -if (is_array &&
>> +if ((is_array || (flags & V4L2_CTRL_FLAG_CAN_STORE)) &&
>>  (type == V4L2_CTRL_TYPE_BUTTON ||
>>   type == V4L2_CTRL_TYPE_CTRL_CLASS)) {
>>  handler_set_err(hdl, -EINVAL);
>> @@ -2084,8 +2113,10 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct 
>> v4l2_ctrl_handler *hdl,
>>  is_menu ? cfg->menu_skip_mask : step, def,
>>  cfg->dims, cfg->elem_size,
>>  flags, qmenu, qmenu_int, priv);
>> -if (ctrl)
>> +if (ctrl) {
> 
> I think it'd be cleaner to return NULL here if ctrl == NULL. Up to you.

Agreed.

> 
>>  ctrl->is_private = cfg->is_private;
>> +ctrl->can_store = cfg->can_store;
>> +}
>>  return ctrl;
>>  }
>>  EXPORT_SYMBOL(v4l2_ctrl_new_custom);
>> @@ -2452,6 +2483,7 @@ int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler 
>> *hdl)
>>  cur_to_new(master->cluster[i]);
>>  master->cluster[i]->is_new = 1;
>>  master->cluster[i]->done = true;
>> +master->cluster[i]->store = 0;
>>  }
>>  }
>>  ret = call_op(master, s_ctrl);
>> @@ -2539,6 +2571,8 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl_handler *hdl, 
>> struct v4l2_query_ext_ctr
>>  qc->id = ctrl->id;
>>  strlcpy(qc->name, ctrl->name, sizeof(qc->name));
>>   

Re: [RFC] adp1653: Add device tree bindings for LED controller

[Pali Rohár]

On Sunday 16 November 2014 08:59:28 Pavel Machek wrote:
> For device tree people: Yes, I know I'll have to create file
> in documentation, but does the binding below look acceptable?
> 
> I'll clean up driver code a bit more, remove the printks.
> Anything else obviously wrong?
> 
> Signed-off-by: Pavel Machek 
> 
> Thanks,
>   Pavel
> 
> 

Hello,

I think that this patch is probably not good and specially not 
for n900. adp1653 should be registered throw omap3 isp camera 
subsystem which does not have DT support yet.

See n900 legacy board camera code in file board-rx51-camera.c.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: [RFC PATCH 03/11] videodev2.h: rename reserved2 to config_store in v4l2_buffer.

[Hans Verkuil]

On 11/14/2014 04:35 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> One more comment...
> 
> On Sun, Sep 21, 2014 at 04:48:21PM +0200, Hans Verkuil wrote:
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 83ef28a..2ca44ed 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -672,6 +672,7 @@ struct v4l2_plane {
>>   * @length: size in bytes of the buffer (NOT its payload) for single-plane
>>   *  buffers (when type != *_MPLANE); number of elements in the
>>   *  planes array for multi-plane buffers
>> + * @config_store: this buffer should use this configuration store
>>   *
>>   * Contains data exchanged by application and driver using one of the 
>> Streaming
>>   * I/O methods.
>> @@ -695,7 +696,7 @@ struct v4l2_buffer {
>>  __s32   fd;
>>  } m;
>>  __u32   length;
>> -__u32   reserved2;
>> +__u32   config_store;
>>  __u32   reserved;
>>  };
>>  
> 
> I would use __u16 instead since the value is 16-bit on the control
> interface.
> 

Good point. Will do.

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

Re: [RFC PATCH 03/11] videodev2.h: rename reserved2 to config_store in v4l2_buffer.

[Hans Verkuil]

On 11/14/2014 03:42 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> On Sun, Sep 21, 2014 at 04:48:21PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> When queuing buffers allow for passing the configuration store ID that
>> should be associated with this buffer. Use the 'reserved2' field for this.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  drivers/media/usb/cpia2/cpia2_v4l.c   | 2 +-
>>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 ++--
>>  drivers/media/v4l2-core/videobuf2-core.c  | 4 +++-
>>  include/uapi/linux/videodev2.h| 3 ++-
>>  4 files changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
>> b/drivers/media/usb/cpia2/cpia2_v4l.c
>> index 9caea83..0f28d2b 100644
>> --- a/drivers/media/usb/cpia2/cpia2_v4l.c
>> +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
>> @@ -952,7 +952,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, 
>> struct v4l2_buffer *buf)
>>  buf->sequence = cam->buffers[buf->index].seq;
>>  buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
>>  buf->length = cam->frame_size;
>> -buf->reserved2 = 0;
>> +buf->config_store = 0;
>>  buf->reserved = 0;
>>  memset(&buf->timecode, 0, sizeof(buf->timecode));
>>  
>> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
>> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> index e502a5f..5afef3a 100644
>> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> @@ -324,7 +324,7 @@ struct v4l2_buffer32 {
>>  __s32   fd;
>>  } m;
>>  __u32   length;
>> -__u32   reserved2;
>> +__u32   config_store;
>>  __u32   reserved;
>>  };
>>  
>> @@ -489,7 +489,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, 
>> struct v4l2_buffer32 __user
>>  put_user(kp->timestamp.tv_usec, &up->timestamp.tv_usec) ||
>>  copy_to_user(&up->timecode, &kp->timecode, sizeof(struct 
>> v4l2_timecode)) ||
>>  put_user(kp->sequence, &up->sequence) ||
>> -put_user(kp->reserved2, &up->reserved2) ||
>> +put_user(kp->config_store, &up->config_store) ||
>>  put_user(kp->reserved, &up->reserved))
>>  return -EFAULT;
>>  
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
>> b/drivers/media/v4l2-core/videobuf2-core.c
>> index 7e6aff6..e3b6c50 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> @@ -655,7 +655,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
>> struct v4l2_buffer *b)
>>  
>>  /* Copy back data such as timestamp, flags, etc. */
>>  memcpy(b, &vb->v4l2_buf, offsetof(struct v4l2_buffer, m));
>> -b->reserved2 = vb->v4l2_buf.reserved2;
>> +b->config_store = vb->v4l2_buf.config_store;
>>  b->reserved = vb->v4l2_buf.reserved;
>>  
>>  if (V4L2_TYPE_IS_MULTIPLANAR(q->type)) {
>> @@ -680,6 +680,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
>> struct v4l2_buffer *b)
>>  else if (q->memory == V4L2_MEMORY_DMABUF)
>>  b->m.fd = vb->v4l2_planes[0].m.fd;
>>  }
>> +b->config_store = vb->v4l2_buf.config_store;
> 
> Either this chunk or the one above it is redundant. I'd keep the upper one.

Well spotted. I agree, I'll keep the upper one.

Regards,

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