Re: [PATCH] [media] atmel-isc: add the isc pipeline function

[Wu, Songjun]

Hi Hans,

Thank you for your comments.

On 1/9/2017 20:10, Hans Verkuil wrote:

+
+static int isc_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct isc_device *isc = container_of(ctrl->handler,
+struct isc_device, ctrls.handler);
+   struct isc_ctrls *ctrls = >ctrls;
+
+   switch (ctrl->id) {
+   case V4L2_CID_BRIGHTNESS:
+   ctrls->brightness = ctrl->val & ISC_CBC_BRIGHT_MASK;
+   break;
+   case V4L2_CID_CONTRAST:
+   ctrls->contrast = (ctrl->val << 8) & ISC_CBC_CONTRAST_MASK;

As I understand it only bits 11-8 contain the contrast in the register?

Wouldn't '(ctrl->val & ISC_CBC_CONTRAST_MASK) << 8' be more readable?

Either that or the mask should be 0xf00, not 0xfff.

Actually, bits 12-0 contain the contrast, it is a fixed-point 
number(signed 12 bits 1:3:8), ranges from -2048 to 2047. Then only the 
integral part is output to be adjusted.

Maybe both the fractional part and integral part should be output.
Then the contrast control should be written as below.

v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 1);

Do you have any good suggestion?


+   break;
+   case V4L2_CID_GAMMA:
+   ctrls->gamma_index = ctrl->val;
+   break;
+   case V4L2_CID_AUTO_WHITE_BALANCE:
+   ctrls->awb = ctrl->val;
+   if (ctrls->hist_stat != HIST_ENABLED) {
+   ctrls->r_gain = 0x1 << 9;
+   ctrls->b_gain = 0x1 << 9;
+   }
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static const struct v4l2_ctrl_ops isc_ctrl_ops = {
+   .s_ctrl = isc_s_ctrl,
+};
+
+static int isc_ctrl_init(struct isc_device *isc)
+{
+   const struct v4l2_ctrl_ops *ops = _ctrl_ops;
+   struct isc_ctrls *ctrls = >ctrls;
+   struct v4l2_ctrl_handler *hdl = >handler;
+   int ret;
+
+   ctrls->hist_stat = HIST_INIT;
+
+   ret = v4l2_ctrl_handler_init(hdl, 4);
+   if (ret < 0)
+   return ret;
+
+   v4l2_ctrl_new_std(hdl, ops, V4L2_CID_BRIGHTNESS, -1024, 1023, 1, 0);
+   v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -8, 7, 1, 1);
+   v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, GAMMA_MAX - 1, 1, 2);

Why is the maximum GAMMA_MAX - 1? I would assume that GAMMA_MAX is the maximum.

Looks weird. It's either a bug or it needs a comment.


+   v4l2_ctrl_new_std(hdl, ops, V4L2_CID_AUTO_WHITE_BALANCE, 0, 1, 1, 1);
+
+   v4l2_ctrl_handler_setup(hdl);
+
+   return 0;
+}
+
+
 static int isc_async_bound(struct v4l2_async_notifier *notifier,
struct v4l2_subdev *subdev,
struct v4l2_async_subdev *asd)
@@ -1047,10 +1435,11 @@ static void isc_async_unbind(struct v4l2_async_notifier 
*notifier,
 {
struct isc_device *isc = container_of(notifier->v4l2_dev,
  struct isc_device, v4l2_dev);
-
+   cancel_work_sync(>awb_work);
video_unregister_device(>video_dev);
if (isc->current_subdev->config)
v4l2_subdev_free_pad_config(isc->current_subdev->config);
+   v4l2_ctrl_handler_free(>ctrls.handler);
 }

 static struct isc_format *find_format_by_code(unsigned int code, int *index)
@@ -1081,7 +1470,9 @@ static int isc_formats_init(struct isc_device *isc)

fmt = _formats[0];
for (i = 0; i < ARRAY_SIZE(isc_formats); i++) {
-   fmt->support = false;
+   fmt->isc_support = false;
+   fmt->sd_support = false;
+
fmt++;
}

@@ -1092,8 +1483,22 @@ static int isc_formats_init(struct isc_device *isc)
if (!fmt)
continue;

-   fmt->support = true;
-   num_fmts++;
+   fmt->sd_support = true;
+
+   if (i <= RAW_FMT_INDEX_END) {
+   for (j = ISC_FMT_INDEX_START;
+j <= ISC_FMT_INDEX_END; j++)

Just merge these two lines, easier to read.

Do you mean merge these two lines like 'for (j = ISC_FMT_INDEX_START; j 
<= ISC_FMT_INDEX_END; j++)', but the line is over 80 characters



+   isc_formats[j].isc_support = true;
+
+   isc->raw_fmt = fmt;
+   }

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

Re: [PATCH v3 13/24] platform: add video-multiplexer subdevice driver

[Rob Herring]

On Fri, Jan 06, 2017 at 06:11:31PM -0800, Steve Longerbeam wrote:
> From: Philipp Zabel 
> 
> This driver can handle SoC internal and external video bus multiplexers,
> controlled either by register bit fields or by a GPIO. The subdevice
> passes through frame interval and mbus configuration of the active input
> to the output side.
> 
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Philipp Zabel 
> 
> --
> 
> - fixed a cut error in vidsw_remove(): v4l2_async_register_subdev()
>   should be unregister.
> 
> - added media_entity_cleanup() and v4l2_device_unregister_subdev()
>   to vidsw_remove().
> 
> - there was a line left over from a previous iteration that negated
>   the new way of determining the pad count just before it which
>   has been removed (num_pads = of_get_child_count(np)).
> 
> - Philipp Zabel has developed a set of patches that allow adding
>   to the subdev async notifier waiting list using a chaining method
>   from the async registered callbacks (v4l2_of_subdev_registered()
>   and the prep patches for that). For now, I've removed the use of
>   v4l2_of_subdev_registered() for the vidmux driver's registered
>   callback. This doesn't affect the functionality of this driver,
>   but allows for it to be merged now, before adding the chaining
>   support.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  .../bindings/media/video-multiplexer.txt   |  59 +++
>  drivers/media/platform/Kconfig |   8 +
>  drivers/media/platform/Makefile|   2 +
>  drivers/media/platform/video-multiplexer.c | 472 
> +
>  4 files changed, 541 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/video-multiplexer.txt
>  create mode 100644 drivers/media/platform/video-multiplexer.c
> 
> diff --git a/Documentation/devicetree/bindings/media/video-multiplexer.txt 
> b/Documentation/devicetree/bindings/media/video-multiplexer.txt
> new file mode 100644
> index 000..9d133d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/video-multiplexer.txt
> @@ -0,0 +1,59 @@
> +Video Multiplexer
> +=
> +
> +Video multiplexers allow to select between multiple input ports. Video 
> received
> +on the active input port is passed through to the output port. Muxes 
> described
> +by this binding may be controlled by a syscon register bitfield or by a GPIO.
> +
> +Required properties:
> +- compatible : should be "video-multiplexer"

This should have an SoC/chip specific compatible string additionally. 
Just need a note to that effect here, but i.MX will need a compat 
string.

> +- reg: should be register base of the register containing the control 
> bitfield
> +- bit-mask: bitmask of the control bitfield in the control register
> +- bit-shift: bit offset of the control bitfield in the control register
> +- gpios: alternatively to reg, bit-mask, and bit-shift, a single GPIO phandle
> +  may be given to switch between two inputs
> +- #address-cells: should be <1>
> +- #size-cells: should be <0>
> +- port@*: at least three port nodes containing endpoints connecting to the
> +  source and sink devices according to of_graph bindings. The last port is
> +  the output port, all others are inputs.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Tue Jan 10 05:00:18 CET 2017
media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a
media_build git hash:   3c6ce4ff75f19adf45869e34b376c5b9dee4d50a
v4l-utils git hash: 7715d870ab8da6436ac97eeb11f0780fbb99fade
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10-rc3-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: OK
linux-3.12.67-x86_64: OK
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: OK
linux-4.9-x86_64: OK
linux-4.10-rc3-x86_64: OK
apps: WARNINGS
spec-git: ERRORS
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.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 v3 2/2] [media] em28xx: support for Hauppauge WinTV-dualHD 01595 ATSC/QAM

[Kevin Cheng]

Hauppauge WinTV-dualHD model 01595 is a USB 2.0 dual ATSC/QAM tuner with
the following components:

USB bridge: Empia em28274
Demodulator: 2x LG LGDT3306a at addresses 0xb2 and 0x1c
Tuner: 2x Silicon Labs si2157 at addresses 0xc0 and 0xc4

This patch enables only the first tuner.

Signed-off-by: Kevin Cheng 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 19 +
 drivers/media/usb/em28xx/em28xx-dvb.c   | 74 +
 drivers/media/usb/em28xx/em28xx.h   |  1 +
 3 files changed, 94 insertions(+)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 23c6749..5f90d08 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -509,6 +509,7 @@ static struct em28xx_reg_seq plex_px_bcud[] = {
 
 /*
  * 2040:0265 Hauppauge WinTV-dualHD DVB
+ * 2040:026d Hauppauge WinTV-dualHD ATSC/QAM
  * reg 0x80/0x84:
  * GPIO_0: Yellow LED tuner 1, 0=on, 1=off
  * GPIO_1: Green LED tuner 1, 0=on, 1=off
@@ -2389,6 +2390,21 @@ struct em28xx_board em28xx_boards[] = {
.ir_codes  = RC_MAP_HAUPPAUGE,
.leds  = hauppauge_dualhd_leds,
},
+   /*
+* 2040:026d Hauppauge WinTV-dualHD (model 01595 - ATSC/QAM).
+* Empia EM28274, 2x LG LGDT3306A, 2x Silicon Labs Si2157
+*/
+   [EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595] = {
+   .name  = "Hauppauge WinTV-dualHD 01595 ATSC/QAM",
+   .def_i2c_bus   = 1,
+   .i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE |
+EM28XX_I2C_FREQ_400_KHZ,
+   .tuner_type= TUNER_ABSENT,
+   .tuner_gpio= hauppauge_dualhd_dvb,
+   .has_dvb   = 1,
+   .ir_codes  = RC_MAP_HAUPPAUGE,
+   .leds  = hauppauge_dualhd_leds,
+   },
 };
 EXPORT_SYMBOL_GPL(em28xx_boards);
 
@@ -2514,6 +2530,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850 },
{ USB_DEVICE(0x2040, 0x0265),
.driver_info = EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB 
},
+   { USB_DEVICE(0x2040, 0x026d),
+   .driver_info = 
EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 },
{ USB_DEVICE(0x0438, 0xb002),
.driver_info = EM2880_BOARD_AMD_ATI_TV_WONDER_HD_600 },
{ USB_DEVICE(0x2001, 0xf112),
@@ -2945,6 +2963,7 @@ static void em28xx_card_setup(struct em28xx *dev)
case EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950:
case EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C:
case EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB:
+   case EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595:
{
struct tveeprom tv;
 
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 75a75da..82edd37 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -37,6 +37,7 @@
 
 #include "lgdt330x.h"
 #include "lgdt3305.h"
+#include "lgdt3306a.h"
 #include "zl10353.h"
 #include "s5h1409.h"
 #include "mt2060.h"
@@ -920,6 +921,17 @@ static struct tda18271_config pinnacle_80e_dvb_config = {
.role= TDA18271_MASTER,
 };
 
+static struct lgdt3306a_config hauppauge_01595_lgdt3306a_config = {
+   .qam_if_khz = 4000,
+   .vsb_if_khz = 3250,
+   .spectral_inversion = 0,
+   .deny_i2c_rptr  = 0,
+   .mpeg_mode  = LGDT3306A_MPEG_SERIAL,
+   .tpclk_edge = LGDT3306A_TPCLK_RISING_EDGE,
+   .tpvalid_polarity   = LGDT3306A_TP_VALID_HIGH,
+   .xtalMHz= 25,
+};
+
 /* -- */
 
 static int em28xx_attach_xc3028(u8 addr, struct em28xx *dev)
@@ -1950,6 +1962,68 @@ static int em28xx_dvb_init(struct em28xx *dev)
 
}
break;
+   case EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595:
+   {
+   struct i2c_adapter *adapter;
+   struct i2c_client *client;
+   struct i2c_board_info info = {};
+   struct lgdt3306a_config lgdt3306a_config;
+   struct si2157_config si2157_config = {};
+
+   /* attach demod */
+   lgdt3306a_config = hauppauge_01595_lgdt3306a_config;
+   lgdt3306a_config.fe = >fe[0];
+   lgdt3306a_config.i2c_adapter = 
+   strlcpy(info.type, "lgdt3306a", sizeof(info.type));
+   info.addr = 0x59;
+   info.platform_data = _config;
+   request_module(info.type);
+   client = 
i2c_new_device(>i2c_adap[dev->def_i2c_bus],
+   );
+   if (client == NULL || 

[PATCH v3 0/2] Support for Hauppauge WinTV-dualHD 01595 ATSC/QAM

[Kevin Cheng]

Adds support for the Hauppauge WinTV-dualHD TV tuner USB stick.


Changes in response to review comments:
* Removed extra struct initialization in lgdt3306a.c
* Simplified initialization in em28xx-dvb.c


Kevin Cheng (2):
  [media] lgdt3306a: support i2c mux for use by em28xx
  [media] em28xx: support for Hauppauge WinTV-dualHD 01595 ATSC/QAM

 drivers/media/dvb-frontends/Kconfig |   2 +-
 drivers/media/dvb-frontends/lgdt3306a.c | 108 
 drivers/media/dvb-frontends/lgdt3306a.h |   4 ++
 drivers/media/usb/em28xx/em28xx-cards.c |  19 ++
 drivers/media/usb/em28xx/em28xx-dvb.c   |  78 +++
 drivers/media/usb/em28xx/em28xx.h   |   1 +
 6 files changed, 211 insertions(+), 1 deletion(-)

-- 
2.9.3

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

[PATCH v3 1/2] [media] lgdt3306a: support i2c mux for use by em28xx

[Kevin Cheng]

Adds an i2c mux to the lgdt3306a demodulator.  This was done to support
the Hauppauge WinTV-dualHD 01595 USB TV tuner (em28xx), which utilizes two
si2157 tuners behind gate control.

Signed-off-by: Kevin Cheng 
---
 drivers/media/dvb-frontends/Kconfig |   2 +-
 drivers/media/dvb-frontends/lgdt3306a.c | 108 
 drivers/media/dvb-frontends/lgdt3306a.h |   4 ++
 3 files changed, 113 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/Kconfig 
b/drivers/media/dvb-frontends/Kconfig
index c841fa1..16f9afa 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -619,7 +619,7 @@ config DVB_LGDT3305
 
 config DVB_LGDT3306A
tristate "LG Electronics LGDT3306A based"
-   depends on DVB_CORE && I2C
+   depends on DVB_CORE && I2C && I2C_MUX
default m if !MEDIA_SUBDRV_AUTOSELECT
help
  An ATSC 8VSB and QAM-B 64/256 demodulator module. Say Y when you want
diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
b/drivers/media/dvb-frontends/lgdt3306a.c
index 19dca46..c9b1eb3 100644
--- a/drivers/media/dvb-frontends/lgdt3306a.c
+++ b/drivers/media/dvb-frontends/lgdt3306a.c
@@ -22,6 +22,7 @@
 #include 
 #include "dvb_math.h"
 #include "lgdt3306a.h"
+#include 
 
 
 static int debug;
@@ -65,6 +66,8 @@ struct lgdt3306a_state {
enum fe_modulation current_modulation;
u32 current_frequency;
u32 snr;
+
+   struct i2c_mux_core *muxc;
 };
 
 /*
@@ -2131,6 +2134,111 @@ static const struct dvb_frontend_ops lgdt3306a_ops = {
.search   = lgdt3306a_search,
 };
 
+static int lgdt3306a_select(struct i2c_mux_core *muxc, u32 chan)
+{
+   struct i2c_client *client = i2c_mux_priv(muxc);
+   struct lgdt3306a_state *state = i2c_get_clientdata(client);
+
+   return lgdt3306a_i2c_gate_ctrl(>frontend, 1);
+}
+
+static int lgdt3306a_deselect(struct i2c_mux_core *muxc, u32 chan)
+{
+   struct i2c_client *client = i2c_mux_priv(muxc);
+   struct lgdt3306a_state *state = i2c_get_clientdata(client);
+
+   return lgdt3306a_i2c_gate_ctrl(>frontend, 0);
+}
+
+static int lgdt3306a_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct lgdt3306a_config *config;
+   struct lgdt3306a_state *state;
+   struct dvb_frontend *fe;
+   int ret;
+
+   config = kzalloc(sizeof(struct lgdt3306a_config), GFP_KERNEL);
+   if (config == NULL) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   memcpy(config, client->dev.platform_data,
+   sizeof(struct lgdt3306a_config));
+
+   config->i2c_addr = client->addr;
+   fe = lgdt3306a_attach(config, client->adapter);
+   if (fe == NULL) {
+   ret = -ENODEV;
+   goto err_fe;
+   }
+
+   i2c_set_clientdata(client, fe->demodulator_priv);
+   state = fe->demodulator_priv;
+
+   /* create mux i2c adapter for tuner */
+   state->muxc = i2c_mux_alloc(client->adapter, >dev,
+ 1, 0, I2C_MUX_LOCKED,
+ lgdt3306a_select, lgdt3306a_deselect);
+   if (!state->muxc) {
+   ret = -ENOMEM;
+   goto err_kfree;
+   }
+   state->muxc->priv = client;
+   ret = i2c_mux_add_adapter(state->muxc, 0, 0, 0);
+   if (ret)
+   goto err_kfree;
+
+   /* create dvb_frontend */
+   fe->ops.i2c_gate_ctrl = NULL;
+   *config->i2c_adapter = state->muxc->adapter[0];
+   *config->fe = fe;
+
+   return 0;
+
+err_kfree:
+   kfree(state);
+err_fe:
+   kfree(config);
+fail:
+   dev_dbg(>dev, "failed=%d\n", ret);
+   return ret;
+}
+
+static int lgdt3306a_remove(struct i2c_client *client)
+{
+   struct lgdt3306a_state *state = i2c_get_clientdata(client);
+
+   i2c_mux_del_adapters(state->muxc);
+
+   state->frontend.ops.release = NULL;
+   state->frontend.demodulator_priv = NULL;
+
+   kfree(state->cfg);
+   kfree(state);
+
+   return 0;
+}
+
+static const struct i2c_device_id lgdt3306a_id_table[] = {
+   {"lgdt3306a", 0},
+   {}
+};
+MODULE_DEVICE_TABLE(i2c, lgdt3306a_id_table);
+
+static struct i2c_driver lgdt3306a_driver = {
+   .driver = {
+   .name= "lgdt3306a",
+   .suppress_bind_attrs = true,
+   },
+   .probe  = lgdt3306a_probe,
+   .remove = lgdt3306a_remove,
+   .id_table   = lgdt3306a_id_table,
+};
+
+module_i2c_driver(lgdt3306a_driver);
+
 MODULE_DESCRIPTION("LG Electronics LGDT3306A ATSC/QAM-B Demodulator Driver");
 MODULE_AUTHOR("Fred Richter ");
 MODULE_LICENSE("GPL");
diff --git a/drivers/media/dvb-frontends/lgdt3306a.h 
b/drivers/media/dvb-frontends/lgdt3306a.h
index 9dbb2dc..6ce337e 100644
--- a/drivers/media/dvb-frontends/lgdt3306a.h
+++ b/drivers/media/dvb-frontends/lgdt3306a.h
@@ 

Re: [PATCH 1/2] Documentation: devicetree: Add document bindings for mtk-cir

[Sean Wang]

Hi Rob,

thanks for your effort for reviewing. I added comments inline.

On Mon, 2017-01-09 at 12:32 -0600, Rob Herring wrote:
> On Fri, Jan 06, 2017 at 12:06:23AM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > This patch adds documentation for devicetree bindings for
> > Mediatek IR controller.
> > 
> > Signed-off-by: Sean Wang 
> > ---
> >  .../devicetree/bindings/media/mtk-cir.txt  | 23 
> > ++
> >  1 file changed, 23 insertions(+)
> >  create mode 100644 
> > linux-4.8.rc1_p0/Documentation/devicetree/bindings/media/mtk-cir.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt 
> > b/Documentation/devicetree/bindings/media/mtk-cir.txt
> > new file mode 100644
> > index 000..bbedd71
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
> > @@ -0,0 +1,23 @@
> > +Device-Tree bindings for Mediatek IR controller found in Mediatek SoC 
> > family
> > +
> > +Required properties:
> > +- compatible   : "mediatek,mt7623-ir"
> > +- clocks   : list of clock specifiers, corresponding to
> > + entries in clock-names property;
> > +- clock-names  : should contain "clk" entries;
> > +- interrupts   : should contain IR IRQ number;
> > +- reg  : should contain IO map address for IR.
> > +
> > +Optional properties:
> > +- linux,rc-map-name : Remote control map name.
> 
> Would 'label' be appropriate here instead? If not, this needs to be 
> documented in a common location and explained better.
> 
I checked with how the way applied in other IR drivers is and found that
most IR driver also use the same label to identify the scan/key table
they prefer to use such as gpio-ir-recv, ir-hix5hd2, meson-ir and
sunxi-cir or use hard coding inside the driver. So I thought it should
be appropriate here currently.

> > +
> > +Example:
> > +
> > +cir: cir@0x10013000 {
> 
> Drop the '0x'.
> 

okay, I will.

> > +   compatible = "mediatek,mt7623-ir";
> > +   reg = <0 0x10013000 0 0x1000>;
> > +   interrupts = ;
> > +   clocks = < CLK_INFRA_IRRX>;
> > +   clock-names = "clk";
> > +   linux,rc-map-name = "rc-rc6-mce";
> > +};
> > -- 
> > 1.9.1
> > 


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

Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

[Eddie Huang]

Hi Matthias,

On Mon, 2017-01-09 at 19:45 +0100, Matthias Brugger wrote:
> 
> On 09/01/17 12:29, Hans Verkuil wrote:
> > Hi Rick,
> >
> > On 01/06/2017 03:34 AM, Rick Chang wrote:
> >> Hi Hans,
> >>
> >> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
> >> any idea about this patch series? Should we wait for [2] or we could merge
> >> the source code and dt-binding first?
> >
> > Looking at [2] I noticed that the last comment was July 4th. What is the 
> > reason
> > it hasn't been merged yet?
> >
> > If I know [2] will be merged for 4.11, then I am fine with merging this 
> > media
> > patch series. The dependency of this patch on [2] is something Mauro can 
> > handle.
> >
> > If [2] is not merged for 4.11, then I think it is better to wait until it is
> > merged.
> >
> 
> I can't take [2] because there is no scpsys in the dts present. It seems 
> that it got never posted.
> 
> Rick can you please follow-up with James and provide a patch which adds 
> a scpsys node to the mt2701.dtsi?
> 

James sent three MT2701 dts patches [1] two weeks ago, these three
patches include scpsys node. Please take a reference. And We will send
new MT2701 ionmmu/smi dtsi node patch base on [1] later, thus you can
accept and merge to 4.11.

[1]
https://patchwork.kernel.org/patch/9489991/
https://patchwork.kernel.org/patch/9489985/
https://patchwork.kernel.org/patch/9489989/

Thanks,
Eddie


--
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 00/21] Basic i.MX IPUv3 capture support

[Steve Longerbeam]

Hi Philipp,


On 01/09/2017 11:43 AM, Philipp Zabel wrote:

Hi Steve,

Am Freitag, den 30.12.2016, 12:26 -0800 schrieb Steve Longerbeam:

On 12/30/2016 11:06 AM, Marek Vasut wrote:

On 12/29/2016 09:51 PM, Robert Schwebel wrote:

Hi Jean-Michel,

Hi,


On Thu, Dec 29, 2016 at 04:08:33PM +0100, Jean-Michel Hautbois wrote:

What is the status of this work?

Philipp's patches have been reworked with the review feedback from the
last round and a new version will be posted when he is back from
holidays.

IMO Philipp's patches are better integrated and well structured, so I'd
rather like to see his work in at some point.

Granted I am biased, but I will state my case. "Better integrated" - my
patches
are also well integrated with the media core infrastructure. Philipp's
patches
in fact require modification to media core, whereas mine require none.
Some changes are needed of course (more subdev type definitions for
one).

As for "well structured", I don't really understand what is meant by that,
but my driver is also well structured.

I agree that this driver is well structured and well documented. Many of
my earlier concerns regarding the device tree bindings and media
controller interface have been addressed.


Thanks! Your input is crucial, so I really appreciate it.


  But there are still a few
design choices that I don't agree with, and some are userspace visible,
which makes me worry about not being able to change them later.


Ok.


One is the amount and organization of subdevices/media entities visible
to userspace. The SMFCs should not be user controllable subdevices, but
can be implicitly enabled when a CSI is directly linked to a camif.


I agree the SMFC could be folded into the CSI, but I see at least one
issue.

From the dot graph you'll see that the PRPVF entity can receive directly
from the CSI, or indirectly via the SMFC. If the SMFC entity were folded
into the CSI entity, there would have to be a "direct to PRPVF" output pad
and a "indirect via SMFC" output pad and I'm not sure how that info would
be conveyed to the user. With a SMFC entity those pipelines are explicit.


Also I'm not convinced the 1:1 mapping of IC task to subdevices is the
best choice. It is true that the three tasks can be enabled separately,
but to my understanding, the PRP ENC and PRP VF tasks share a single
input channel. Shouldn't this be a single PRP subdevice with one input
and two (VF, ENC) outputs?


Since the VDIC sends its motion compensated frames to the PRP VF task,
I've created the PRPVF entity solely for motion compensated de-interlace
support. I don't really see any other use for the PRPVF task except for
motion compensated de-interlace.

So really, the PRPVF entity is a combination of the VDIC and PRPVF subunits.

So looking at link_setup() in imx-csi.c, you'll see that when the CSI is 
linked

to PRPVF entity, it is actually sending to IPU_CSI_DEST_VDIC.

But if we were to create a VDIC entity, I can see how we could then
have a single PRP entity. Then if the PRP entity is receiving from the VDIC,
the PRP VF task would be activated.

Another advantage of creating a distinct VDIC entity is that frames could
potentially be routed directly from the VDIC to camif, for 
motion-compensated

frame capture only with no scaling/CSC. I think that would be IDMAC channel
5, we've tried to get that pipeline to work in the past without success. 
That's
mainly why I decided not to attempt it and instead fold VDIC into PRPVF 
entity.




On the other hand, there is currently no way to communicate to userspace
that the IC can't downscale bilinearly, but only to 1/2 or 1/4 of the
input resolution, and then scale up bilinearly for there. So instead of
pretending to be able to downscale to any resolution, it would be better
to split each IC task into two subdevs, one for the
1/2-or-1/4-downscaler, and one for the bilinear upscaler.


Hmm, good point, but couldn't we just document that fact?




Next there is the issue of the custom mem2mem infrastructure inside the
IPU driver. I think this should be ultimately implemented at a higher
level,


if we were to move it up, into what subsystem would it go? I guess
v4l2, but then we lose the possibility of other subsystems making use
of it, such as drm.


  but I see no way this will ever move out of the IPU driver once
the userspace inferface gets established.


it would be more difficult at that point, true.


Then there are a few issues that are not userspace visible, so less
pressing. For example modelling the internal subdevs as separate
platform devices with async subdevices seems unnecessarily indirect. Why
not drop the platform devices and create the subdevs directly instead of
asynchronously?


This came out of a previous implementation where the IPU internal
subunits and their links were represented as an OF graph (the patches
I floated by you that you didn't like :) I've been meaning to ask you why
you don't like to expose the IPU internals via OF graph, I have my 

Re: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

[Laurent Pinchart]

Hello Hans,

On Monday 09 Jan 2017 14:36:55 Hans Verkuil wrote:
> On 01/03/2017 04:20 PM, Ramesh Shanmugasundaram wrote:
> >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote:
>  Add binding documentation for Renesas R-Car Digital Radio Interface
>  (DRIF) controller.
>  
>  Signed-off-by: Ramesh Shanmugasundaram
>   ---
>  
>   .../devicetree/bindings/media/renesas,drif.txt | 202 +
>   1 file changed, 202 insertions(+)
>   create mode 100644
>  
>  Documentation/devicetree/bindings/media/renesas,drif.txt
>  
>  diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
>  b/Documentation/devicetree/bindings/media/renesas,drif.txt new file
>  mode 100644
>  index 000..1f3feaf
>  --- /dev/null
>  +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>  
>  +Optional properties of an internal channel when:
>  + - It is the only enabled channel of the bond (or)
>  + - If it acts as primary among enabled bonds
>  +
>  +- renesas,syncmd   : sync mode
>  +  0 (Frame start sync pulse mode. 1-bit width
>  pulse
>  + indicates start of a frame)
>  +  1 (L/R sync or I2S mode) (default)
>  +- renesas,lsb-first: empty property indicates lsb bit is received
>  first.
>  +  When not defined msb bit is received first
>  +(default)
>  +- renesas,syncac-active: Indicates sync signal polarity, 0/1 for
>  low/high
> 
> Shouldn't this be 'renesas,sync-active' instead of syncac-active?
> 
> I'm not sure if syncac is intended or if it is a typo.
> 
>  +  respectively. The default is 1 (active high)
>  +- renesas,dtdl : delay between sync signal and start of
>  reception.
>  +  The possible values are represented in 0.5 clock
>  +  cycle units and the range is 0 to 4. The default
>  +  value is 2 (i.e.) 1 clock cycle delay.
>  +- renesas,syncdl   : delay between end of reception and sync
>  signal edge.
>  +  The possible values are represented in 0.5 clock
>  +  cycle units and the range is 0 to 4 & 6. The
>  default
>  +  value is 0 (i.e.) no delay.
> >>> 
> >>> Most of these properties are pretty similar to the video bus
> >>> properties defined at the endpoint level in
> >>> Documentation/devicetree/bindings/media/video-interfaces.txt. I
> >>> believe it would make sense to use OF graph and try to standardize
> >>> these properties similarly.
> 
> Other than sync-active, is there really anything else that is similar? And
> even the sync-active isn't a good fit since here there is only one sync
> signal instead of two for video (h and vsync).

That's why I said similar, not identical :-) My point is that, if we consider 
that we could connect multiple sources to the DRIF, using OF graph would make 
sense, and the above properties should then be defined per endpoint. If we 
define them per endpoint we should then also try standardize the ones that are 
not really Renesas-specific (that's at least syncac-active). For the syncmd 
and lsb-first properties, it could also make sense to query them from the 
connected subdev at runtime, as they're similar in purpose to formats and 
media bus configuration (struct v4l2_mbus_config).

I'm not an SDR expert, so I'd like to have your opinion on this.

> >> Note that the last two properties match the those in
> >> Documentation/devicetree/bindings/spi/sh-msiof.txt.
> >> We may want to use one DRIF channel as a plain SPI slave with the
> >> (modified) MSIOF driver in the future.
> > 
> > Should I leave it as it is or modify these as in video-interfaces.txt?
> > Shall we conclude on this please?

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] [media] cx231xx: Initial support Evromedia USB Full Hybrid Full HD

[Antti Palosaari]

On 01/09/2017 11:49 PM, Oleh Kravchenko wrote:

Hello!

On 09.01.17 18:59, Antti Palosaari wrote:



On 01/09/2017 05:23 PM, Oleh Kravchenko wrote:

This patch provide only digital support.

The device is based on Si2168 30-demodulator,
Si2158-20 tuner and CX23102-11Z chipset;
USB id: 1b80:d3b2.

Status:
- DVB-T2 works fine;
- Composite and SVideo works fine;
- Analog not implemented.

Signed-off-by: Oleh Kravchenko 
Tested-by: Oleh Kravchenko 
---
 drivers/media/usb/cx231xx/Kconfig |  1 +
 drivers/media/usb/cx231xx/cx231xx-cards.c | 29 +
 drivers/media/usb/cx231xx/cx231xx-dvb.c   | 71 +++
 drivers/media/usb/cx231xx/cx231xx-i2c.c   | 37 
 drivers/media/usb/cx231xx/cx231xx.h   |  1 +
 5 files changed, 139 insertions(+)

diff --git a/drivers/media/usb/cx231xx/Kconfig 
b/drivers/media/usb/cx231xx/Kconfig
index 0cced3e..58de80b 100644
--- a/drivers/media/usb/cx231xx/Kconfig
+++ b/drivers/media/usb/cx231xx/Kconfig
@@ -50,6 +50,7 @@ config VIDEO_CX231XX_DVB
 select DVB_LGDT3306A if MEDIA_SUBDRV_AUTOSELECT
 select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
 select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
+select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
 select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT

 ---help---
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 36bc254..9b1df5a 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -841,6 +841,33 @@ struct cx231xx_board cx231xx_boards[] = {
 .gpio = NULL,
 } },
 },
+[CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD] = {
+.name = "Evromedia USB Full Hybrid Full HD",
+.tuner_type = TUNER_ABSENT,
+.demod_addr = 0xc8 >> 1,
+.demod_i2c_master = I2C_1_MUX_3,
+.has_dvb = 1,
+.ir_i2c_master = I2C_0,
+.norm = V4L2_STD_PAL,
+.output_mode = OUT_MODE_VIP11,
+.tuner_addr = 0xc0 >> 1,


These "8-bit" I2C addresses looks funny, but if that's used by cx231xx driver 
then leave...


To avoid misunderstanding, Windows driver use shifted i2c addresses.


eh, I2C addresses are 7-bit + lsb which is bit read/write. Just use 
correct addresses. I assume you saw "8-bit" addresses on usb sniffs - 
that is very commonly used for usb hardware api...





+.tuner_i2c_master = I2C_2,
+.input = {{
+.type = CX231XX_VMUX_TELEVISION,
+.vmux = 0,
+.amux = CX231XX_AMUX_VIDEO,
+}, {
+.type = CX231XX_VMUX_COMPOSITE1,
+.vmux = CX231XX_VIN_2_1,
+.amux = CX231XX_AMUX_LINE_IN,
+}, {
+.type = CX231XX_VMUX_SVIDEO,
+.vmux = CX231XX_VIN_1_1 |
+(CX231XX_VIN_1_2 << 8) |
+CX25840_SVIDEO_ON,
+.amux = CX231XX_AMUX_LINE_IN,
+} },
+},
 };
 const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);

@@ -908,6 +935,8 @@ struct usb_device_id cx231xx_id_table[] = {
  .driver_info = CX231XX_BOARD_OTG102},
 {USB_DEVICE(USB_VID_TERRATEC, 0x00a6),
  .driver_info = CX231XX_BOARD_TERRATEC_GRABBY},
+{USB_DEVICE(0x1b80, 0xd3b2),
+.driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
 {},
 };

diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 1417515..08472a3 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -33,6 +33,7 @@
 #include "s5h1411.h"
 #include "lgdt3305.h"
 #include "si2165.h"
+#include "si2168.h"
 #include "mb86a20s.h"
 #include "si2157.h"
 #include "lgdt3306a.h"
@@ -949,6 +950,76 @@ static int dvb_init(struct cx231xx *dev)
_tda18271_config);
 break;

+case CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD:
+{
+struct si2157_config si2157_config = {};
+struct si2168_config si2168_config = {};
+struct i2c_board_info info = {};
+struct i2c_client *client;
+struct i2c_adapter *adapter;
+
+/* attach demodulator chip */
+si2168_config.ts_mode = SI2168_TS_SERIAL; /* from *.inf file */
+si2168_config.fe = >dvb->frontend;
+si2168_config.i2c_adapter = 
+si2168_config.ts_clock_inv = true;
+
+strlcpy(info.type, "si2168", info.type);
+info.addr = dev->board.demod_addr;
+info.platform_data = _config;
+
+request_module(info.type);
+client = i2c_new_device(demod_i2c, );
+
+if (client == NULL || client->dev.driver == NULL || dev->dvb->frontend 
== NULL) {


No need to check frontend here, or at least I cannot see why it should? Does 
the cx231xx initialize with some special value before calling si2168 probe - 
which will set it? client and driver will be null in case si2168 probe fails. 
Also, frontend pointer is not set if si2168 probe 

Re: [PATCH] [media] cx231xx: Initial support Evromedia USB Full Hybrid Full HD

[Oleh Kravchenko]

Hello!

On 09.01.17 18:59, Antti Palosaari wrote:
> 
> 
> On 01/09/2017 05:23 PM, Oleh Kravchenko wrote:
>> This patch provide only digital support.
>>
>> The device is based on Si2168 30-demodulator,
>> Si2158-20 tuner and CX23102-11Z chipset;
>> USB id: 1b80:d3b2.
>>
>> Status:
>> - DVB-T2 works fine;
>> - Composite and SVideo works fine;
>> - Analog not implemented.
>>
>> Signed-off-by: Oleh Kravchenko 
>> Tested-by: Oleh Kravchenko 
>> ---
>>  drivers/media/usb/cx231xx/Kconfig |  1 +
>>  drivers/media/usb/cx231xx/cx231xx-cards.c | 29 +
>>  drivers/media/usb/cx231xx/cx231xx-dvb.c   | 71 
>> +++
>>  drivers/media/usb/cx231xx/cx231xx-i2c.c   | 37 
>>  drivers/media/usb/cx231xx/cx231xx.h   |  1 +
>>  5 files changed, 139 insertions(+)
>>
>> diff --git a/drivers/media/usb/cx231xx/Kconfig 
>> b/drivers/media/usb/cx231xx/Kconfig
>> index 0cced3e..58de80b 100644
>> --- a/drivers/media/usb/cx231xx/Kconfig
>> +++ b/drivers/media/usb/cx231xx/Kconfig
>> @@ -50,6 +50,7 @@ config VIDEO_CX231XX_DVB
>>  select DVB_LGDT3306A if MEDIA_SUBDRV_AUTOSELECT
>>  select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
>>  select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
>> +select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
>>  select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
>>
>>  ---help---
>> diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
>> b/drivers/media/usb/cx231xx/cx231xx-cards.c
>> index 36bc254..9b1df5a 100644
>> --- a/drivers/media/usb/cx231xx/cx231xx-cards.c
>> +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
>> @@ -841,6 +841,33 @@ struct cx231xx_board cx231xx_boards[] = {
>>  .gpio = NULL,
>>  } },
>>  },
>> +[CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD] = {
>> +.name = "Evromedia USB Full Hybrid Full HD",
>> +.tuner_type = TUNER_ABSENT,
>> +.demod_addr = 0xc8 >> 1,
>> +.demod_i2c_master = I2C_1_MUX_3,
>> +.has_dvb = 1,
>> +.ir_i2c_master = I2C_0,
>> +.norm = V4L2_STD_PAL,
>> +.output_mode = OUT_MODE_VIP11,
>> +.tuner_addr = 0xc0 >> 1,
> 
> These "8-bit" I2C addresses looks funny, but if that's used by cx231xx driver 
> then leave...

To avoid misunderstanding, Windows driver use shifted i2c addresses.
 
>> +.tuner_i2c_master = I2C_2,
>> +.input = {{
>> +.type = CX231XX_VMUX_TELEVISION,
>> +.vmux = 0,
>> +.amux = CX231XX_AMUX_VIDEO,
>> +}, {
>> +.type = CX231XX_VMUX_COMPOSITE1,
>> +.vmux = CX231XX_VIN_2_1,
>> +.amux = CX231XX_AMUX_LINE_IN,
>> +}, {
>> +.type = CX231XX_VMUX_SVIDEO,
>> +.vmux = CX231XX_VIN_1_1 |
>> +(CX231XX_VIN_1_2 << 8) |
>> +CX25840_SVIDEO_ON,
>> +.amux = CX231XX_AMUX_LINE_IN,
>> +} },
>> +},
>>  };
>>  const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
>>
>> @@ -908,6 +935,8 @@ struct usb_device_id cx231xx_id_table[] = {
>>   .driver_info = CX231XX_BOARD_OTG102},
>>  {USB_DEVICE(USB_VID_TERRATEC, 0x00a6),
>>   .driver_info = CX231XX_BOARD_TERRATEC_GRABBY},
>> +{USB_DEVICE(0x1b80, 0xd3b2),
>> +.driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
>>  {},
>>  };
>>
>> diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
>> b/drivers/media/usb/cx231xx/cx231xx-dvb.c
>> index 1417515..08472a3 100644
>> --- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
>> +++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
>> @@ -33,6 +33,7 @@
>>  #include "s5h1411.h"
>>  #include "lgdt3305.h"
>>  #include "si2165.h"
>> +#include "si2168.h"
>>  #include "mb86a20s.h"
>>  #include "si2157.h"
>>  #include "lgdt3306a.h"
>> @@ -949,6 +950,76 @@ static int dvb_init(struct cx231xx *dev)
>> _tda18271_config);
>>  break;
>>
>> +case CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD:
>> +{
>> +struct si2157_config si2157_config = {};
>> +struct si2168_config si2168_config = {};
>> +struct i2c_board_info info = {};
>> +struct i2c_client *client;
>> +struct i2c_adapter *adapter;
>> +
>> +/* attach demodulator chip */
>> +si2168_config.ts_mode = SI2168_TS_SERIAL; /* from *.inf file */
>> +si2168_config.fe = >dvb->frontend;
>> +si2168_config.i2c_adapter = 
>> +si2168_config.ts_clock_inv = true;
>> +
>> +strlcpy(info.type, "si2168", info.type);
>> +info.addr = dev->board.demod_addr;
>> +info.platform_data = _config;
>> +
>> +request_module(info.type);
>> +client = i2c_new_device(demod_i2c, );
>> +
>> +if (client == NULL || client->dev.driver == NULL || 
>> dev->dvb->frontend == NULL) {
> 
> No need to check frontend here, or at least I cannot see why it should? Does 
> the cx231xx initialize with some special value before calling si2168 probe - 
> 

[PATCH] [media] cx231xx: Initial support Evromedia USB Full Hybrid Full HD

[Oleh Kravchenko]

This patch provide only digital support.

The device is based on Si2168 30-demodulator,
Si2158-20 tuner and CX23102-11Z chipset;
USB id: 1b80:d3b2.

Status:
- DVB-T2 works fine;
- Composite and SVideo works fine;
- Analog not implemented.

Signed-off-by: Oleh Kravchenko 
Tested-by: Oleh Kravchenko 
---
 drivers/media/usb/cx231xx/Kconfig |  1 +
 drivers/media/usb/cx231xx/cx231xx-cards.c | 29 +
 drivers/media/usb/cx231xx/cx231xx-dvb.c   | 70 +++
 drivers/media/usb/cx231xx/cx231xx-i2c.c   | 37 
 drivers/media/usb/cx231xx/cx231xx.h   |  1 +
 5 files changed, 138 insertions(+)

diff --git a/drivers/media/usb/cx231xx/Kconfig 
b/drivers/media/usb/cx231xx/Kconfig
index 0cced3e..58de80b 100644
--- a/drivers/media/usb/cx231xx/Kconfig
+++ b/drivers/media/usb/cx231xx/Kconfig
@@ -50,6 +50,7 @@ config VIDEO_CX231XX_DVB
select DVB_LGDT3306A if MEDIA_SUBDRV_AUTOSELECT
select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
 
---help---
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 36bc254..9b1df5a 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -841,6 +841,33 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+   [CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD] = {
+   .name = "Evromedia USB Full Hybrid Full HD",
+   .tuner_type = TUNER_ABSENT,
+   .demod_addr = 0xc8 >> 1,
+   .demod_i2c_master = I2C_1_MUX_3,
+   .has_dvb = 1,
+   .ir_i2c_master = I2C_0,
+   .norm = V4L2_STD_PAL,
+   .output_mode = OUT_MODE_VIP11,
+   .tuner_addr = 0xc0 >> 1,
+   .tuner_i2c_master = I2C_2,
+   .input = {{
+   .type = CX231XX_VMUX_TELEVISION,
+   .vmux = 0,
+   .amux = CX231XX_AMUX_VIDEO,
+   }, {
+   .type = CX231XX_VMUX_COMPOSITE1,
+   .vmux = CX231XX_VIN_2_1,
+   .amux = CX231XX_AMUX_LINE_IN,
+   }, {
+   .type = CX231XX_VMUX_SVIDEO,
+   .vmux = CX231XX_VIN_1_1 |
+   (CX231XX_VIN_1_2 << 8) |
+   CX25840_SVIDEO_ON,
+   .amux = CX231XX_AMUX_LINE_IN,
+   } },
+   },
 };
 const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
 
@@ -908,6 +935,8 @@ struct usb_device_id cx231xx_id_table[] = {
 .driver_info = CX231XX_BOARD_OTG102},
{USB_DEVICE(USB_VID_TERRATEC, 0x00a6),
 .driver_info = CX231XX_BOARD_TERRATEC_GRABBY},
+   {USB_DEVICE(0x1b80, 0xd3b2),
+   .driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
{},
 };
 
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 1417515..1925329 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -33,6 +33,7 @@
 #include "s5h1411.h"
 #include "lgdt3305.h"
 #include "si2165.h"
+#include "si2168.h"
 #include "mb86a20s.h"
 #include "si2157.h"
 #include "lgdt3306a.h"
@@ -949,6 +950,75 @@ static int dvb_init(struct cx231xx *dev)
   _tda18271_config);
break;
 
+   case CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD:
+   {
+   struct si2157_config si2157_config = {};
+   struct si2168_config si2168_config = {};
+   struct i2c_board_info info = {};
+   struct i2c_client *client;
+   struct i2c_adapter *adapter;
+
+   /* attach demodulator chip */
+   si2168_config.ts_mode = SI2168_TS_SERIAL; /* from *.inf file */
+   si2168_config.fe = >dvb->frontend;
+   si2168_config.i2c_adapter = 
+   si2168_config.ts_clock_inv = true;
+
+   strlcpy(info.type, "si2168", sizeof(info.type));
+   info.addr = dev->board.demod_addr;
+   info.platform_data = _config;
+
+   request_module(info.type);
+   client = i2c_new_device(demod_i2c, );
+
+   if (client == NULL || client->dev.driver == NULL || 
dev->dvb->frontend == NULL) {
+   dev_err(dev->dev, "Failed to attach Si2168 front 
end\n");
+   result = -EINVAL;
+   goto out_free;
+   }
+
+   if (!try_module_get(client->dev.driver->owner)) {
+   i2c_unregister_device(client);
+   result = -ENODEV;
+   

[PATCH 3/3] PCI/msi: remove pci_enable_msi_{exact,range}

[Christoph Hellwig]

All multi-MSI allocations are now done through pci_irq_alloc_vectors,
so remove the old interface.

Signed-off-by: Christoph Hellwig 
---
 Documentation/PCI/MSI-HOWTO.txt |  6 ++
 drivers/pci/msi.c   | 26 +-
 include/linux/pci.h | 16 ++--
 3 files changed, 13 insertions(+), 35 deletions(-)

diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt
index cd9c9f6..b570a92 100644
--- a/Documentation/PCI/MSI-HOWTO.txt
+++ b/Documentation/PCI/MSI-HOWTO.txt
@@ -162,8 +162,6 @@ The following old APIs to enable and disable MSI or MSI-X 
interrupts should
 not be used in new code:
 
   pci_enable_msi() /* deprecated */
-  pci_enable_msi_range()   /* deprecated */
-  pci_enable_msi_exact()   /* deprecated */
   pci_disable_msi()/* deprecated */
   pci_enable_msix_range()  /* deprecated */
   pci_enable_msix_exact()  /* deprecated */
@@ -268,5 +266,5 @@ or disabled (0).  If 0 is found in any of the msi_bus files 
belonging
 to bridges between the PCI root and the device, MSIs are disabled.
 
 It is also worth checking the device driver to see whether it supports MSIs.
-For example, it may contain calls to pci_enable_msi_range() or
-pci_enable_msix_range().
+For example, it may contain calls to pci_irq_alloc_vectors with the
+PCI_IRQ_MSI or PCI_IRQ_MSIX flags.
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 50c5003..16dda43 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1109,23 +1109,15 @@ static int __pci_enable_msi_range(struct pci_dev *dev, 
int minvec, int maxvec,
}
 }
 
-/**
- * pci_enable_msi_range - configure device's MSI capability structure
- * @dev: device to configure
- * @minvec: minimal number of interrupts to configure
- * @maxvec: maximum number of interrupts to configure
- *
- * This function tries to allocate a maximum possible number of interrupts in a
- * range between @minvec and @maxvec. It returns a negative errno if an error
- * occurs. If it succeeds, it returns the actual number of interrupts allocated
- * and updates the @dev's irq member to the lowest new interrupt number;
- * the other interrupt numbers allocated to this device are consecutive.
- **/
-int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
+/* deprecated, don't use */
+int pci_enable_msi(struct pci_dev *dev)
 {
-   return __pci_enable_msi_range(dev, minvec, maxvec, NULL);
+   int rc = __pci_enable_msi_range(dev, 1, 1, NULL);
+   if (rc < 0)
+   return rc;
+   return 0;
 }
-EXPORT_SYMBOL(pci_enable_msi_range);
+EXPORT_SYMBOL(pci_enable_msi);
 
 static int __pci_enable_msix_range(struct pci_dev *dev,
   struct msix_entry *entries, int minvec,
@@ -1381,7 +1373,7 @@ int pci_msi_domain_check_cap(struct irq_domain *domain,
 {
struct msi_desc *desc = first_pci_msi_entry(to_pci_dev(dev));
 
-   /* Special handling to support pci_enable_msi_range() */
+   /* Special handling to support __pci_enable_msi_range() */
if (pci_msi_desc_is_multi_msi(desc) &&
!(info->flags & MSI_FLAG_MULTI_PCI_MSI))
return 1;
@@ -1394,7 +1386,7 @@ int pci_msi_domain_check_cap(struct irq_domain *domain,
 static int pci_msi_domain_handle_error(struct irq_domain *domain,
   struct msi_desc *desc, int error)
 {
-   /* Special handling to support pci_enable_msi_range() */
+   /* Special handling to support __pci_enable_msi_range() */
if (pci_msi_desc_is_multi_msi(desc) && error == -ENOSPC)
return 1;
 
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e2d1a12..2159376 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1309,14 +1309,7 @@ void pci_msix_shutdown(struct pci_dev *dev);
 void pci_disable_msix(struct pci_dev *dev);
 void pci_restore_msi_state(struct pci_dev *dev);
 int pci_msi_enabled(void);
-int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec);
-static inline int pci_enable_msi_exact(struct pci_dev *dev, int nvec)
-{
-   int rc = pci_enable_msi_range(dev, nvec, nvec);
-   if (rc < 0)
-   return rc;
-   return 0;
-}
+int pci_enable_msi(struct pci_dev *dev);
 int pci_enable_msix_range(struct pci_dev *dev, struct msix_entry *entries,
  int minvec, int maxvec);
 static inline int pci_enable_msix_exact(struct pci_dev *dev,
@@ -1347,10 +1340,7 @@ static inline void pci_msix_shutdown(struct pci_dev 
*dev) { }
 static inline void pci_disable_msix(struct pci_dev *dev) { }
 static inline void pci_restore_msi_state(struct pci_dev *dev) { }
 static inline int pci_msi_enabled(void) { return 0; }
-static inline int pci_enable_msi_range(struct pci_dev *dev, int minvec,
-  int maxvec)
-{ return -ENOSYS; }
-static inline int pci_enable_msi_exact(struct pci_dev *dev, int nvec)
+static inline 

[PATCH 2/3] xgbe: switch to pci_irq_alloc_vectors

[Christoph Hellwig]

The newly added xgbe drivers uses the deprecated pci_enable_msi_exact
and pci_enable_msix_range interfaces.  Switch it to use
pci_irq_alloc_vectors instead.

Signed-off-by: Christoph Hellwig 
---
 drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 47 +---
 drivers/net/ethernet/amd/xgbe/xgbe.h |  1 -
 2 files changed, 19 insertions(+), 29 deletions(-)

diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c 
b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
index e76b7f6..be2690e 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
@@ -133,12 +133,13 @@ static int xgbe_config_msi(struct xgbe_prv_data *pdata)
 pdata->tx_ring_count);
msi_count = roundup_pow_of_two(msi_count);
 
-   ret = pci_enable_msi_exact(pdata->pcidev, msi_count);
+   ret = pci_alloc_irq_vectors(pdata->pcidev, msi_count, msi_count,
+   PCI_IRQ_MSI);
if (ret < 0) {
dev_info(pdata->dev, "MSI request for %u interrupts failed\n",
 msi_count);
 
-   ret = pci_enable_msi(pdata->pcidev);
+   ret = pci_alloc_irq_vectors(pdata->pcidev, 1, 1, PCI_IRQ_MSI);
if (ret < 0) {
dev_info(pdata->dev, "MSI enablement failed\n");
return ret;
@@ -149,25 +150,26 @@ static int xgbe_config_msi(struct xgbe_prv_data *pdata)
 
pdata->irq_count = msi_count;
 
-   pdata->dev_irq = pdata->pcidev->irq;
+   pdata->dev_irq = pci_irq_vector(pdata->pcidev, 0);
 
if (msi_count > 1) {
-   pdata->ecc_irq = pdata->pcidev->irq + 1;
-   pdata->i2c_irq = pdata->pcidev->irq + 2;
-   pdata->an_irq = pdata->pcidev->irq + 3;
+   pdata->ecc_irq = pci_irq_vector(pdata->pcidev, 1);
+   pdata->i2c_irq = pci_irq_vector(pdata->pcidev, 2);
+   pdata->an_irq = pci_irq_vector(pdata->pcidev, 3);
 
for (i = XGBE_MSIX_BASE_COUNT, j = 0;
 (i < msi_count) && (j < XGBE_MAX_DMA_CHANNELS);
 i++, j++)
-   pdata->channel_irq[j] = pdata->pcidev->irq + i;
+   pdata->channel_irq[j] =
+   pci_irq_vector(pdata->pcidev, i);
pdata->channel_irq_count = j;
 
pdata->per_channel_irq = 1;
pdata->channel_irq_mode = XGBE_IRQ_MODE_LEVEL;
} else {
-   pdata->ecc_irq = pdata->pcidev->irq;
-   pdata->i2c_irq = pdata->pcidev->irq;
-   pdata->an_irq = pdata->pcidev->irq;
+   pdata->ecc_irq = pci_irq_vector(pdata->pcidev, 0);
+   pdata->i2c_irq = pci_irq_vector(pdata->pcidev, 0);
+   pdata->an_irq = pci_irq_vector(pdata->pcidev, 0);
}
 
if (netif_msg_probe(pdata))
@@ -186,33 +188,22 @@ static int xgbe_config_msix(struct xgbe_prv_data *pdata)
msix_count += max(pdata->rx_ring_count,
  pdata->tx_ring_count);
 
-   pdata->msix_entries = devm_kcalloc(pdata->dev, msix_count,
-  sizeof(struct msix_entry),
-  GFP_KERNEL);
-   if (!pdata->msix_entries)
-   return -ENOMEM;
-
-   for (i = 0; i < msix_count; i++)
-   pdata->msix_entries[i].entry = i;
-
-   ret = pci_enable_msix_range(pdata->pcidev, pdata->msix_entries,
-   XGBE_MSIX_MIN_COUNT, msix_count);
+   ret = pci_alloc_irq_vectors(pdata->pcidev, XGBE_MSIX_MIN_COUNT,
+   msix_count, PCI_IRQ_MSIX);
if (ret < 0) {
dev_info(pdata->dev, "MSI-X enablement failed\n");
-   devm_kfree(pdata->dev, pdata->msix_entries);
-   pdata->msix_entries = NULL;
return ret;
}
 
pdata->irq_count = ret;
 
-   pdata->dev_irq = pdata->msix_entries[0].vector;
-   pdata->ecc_irq = pdata->msix_entries[1].vector;
-   pdata->i2c_irq = pdata->msix_entries[2].vector;
-   pdata->an_irq = pdata->msix_entries[3].vector;
+   pdata->dev_irq = pci_irq_vector(pdata->pcidev, 0);
+   pdata->ecc_irq = pci_irq_vector(pdata->pcidev, 1);
+   pdata->i2c_irq = pci_irq_vector(pdata->pcidev, 2);
+   pdata->an_irq = pci_irq_vector(pdata->pcidev, 3);
 
for (i = XGBE_MSIX_BASE_COUNT, j = 0; i < ret; i++, j++)
-   pdata->channel_irq[j] = pdata->msix_entries[i].vector;
+   pdata->channel_irq[j] = pci_irq_vector(pdata->pcidev, i);
pdata->channel_irq_count = j;
 
pdata->per_channel_irq = 1;
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe.h 
b/drivers/net/ethernet/amd/xgbe/xgbe.h
index f52a9bd..3bcb6f5 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe.h
+++ b/drivers/net/ethernet/amd/xgbe/xgbe.h
@@ -980,7 +980,6 @@ struct xgbe_prv_data {

[PATCH 1/3] media/cobalt: use pci_irq_allocate_vectors

[Christoph Hellwig]

Simply the interrupt setup by using the new PCI layer helpers.

Despite using pci_enable_msi_range, this driver was only requesting a
single MSI vector anyway.

Signed-off-by: Christoph Hellwig 
---
 drivers/media/pci/cobalt/cobalt-driver.c | 8 ++--
 drivers/media/pci/cobalt/cobalt-driver.h | 2 --
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/media/pci/cobalt/cobalt-driver.c 
b/drivers/media/pci/cobalt/cobalt-driver.c
index 9796340..d5c911c 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.c
+++ b/drivers/media/pci/cobalt/cobalt-driver.c
@@ -308,9 +308,7 @@ static void cobalt_pci_iounmap(struct cobalt *cobalt, 
struct pci_dev *pci_dev)
 static void cobalt_free_msi(struct cobalt *cobalt, struct pci_dev *pci_dev)
 {
free_irq(pci_dev->irq, (void *)cobalt);
-
-   if (cobalt->msi_enabled)
-   pci_disable_msi(pci_dev);
+   pci_free_irq_vectors(pci_dev);
 }
 
 static int cobalt_setup_pci(struct cobalt *cobalt, struct pci_dev *pci_dev,
@@ -387,14 +385,12 @@ static int cobalt_setup_pci(struct cobalt *cobalt, struct 
pci_dev *pci_dev,
   from being generated. */
cobalt_set_interrupt(cobalt, false);
 
-   if (pci_enable_msi_range(pci_dev, 1, 1) < 1) {
+   if (pci_alloc_irq_vectors(pci_dev, 1, 1, PCI_IRQ_MSI) < 1) {
cobalt_err("Could not enable MSI\n");
-   cobalt->msi_enabled = false;
ret = -EIO;
goto err_release;
}
msi_config_show(cobalt, pci_dev);
-   cobalt->msi_enabled = true;
 
/* Register IRQ */
if (request_irq(pci_dev->irq, cobalt_irq_handler, IRQF_SHARED,
diff --git a/drivers/media/pci/cobalt/cobalt-driver.h 
b/drivers/media/pci/cobalt/cobalt-driver.h
index ed00dc9..00f773e 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.h
+++ b/drivers/media/pci/cobalt/cobalt-driver.h
@@ -287,8 +287,6 @@ struct cobalt {
u32 irq_none;
u32 irq_full_fifo;
 
-   bool msi_enabled;
-
/* omnitek dma */
int dma_channels;
int first_fifo_channel;
-- 
2.1.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

kill off pci_enable_msi_{exact,range}

[Christoph Hellwig]

I had hope that we could kill these old interfaces of for 4.10-rc,
but as of today Linus tree still has two users:

 (1) the cobalt media driver, for which I sent a patch long time ago,
 it got missed in the merge window.
 (2) the new xgbe driver was merged in 4.10-rc but used the old interfaces
 anyway

This series resend the patch for (1) and adds a new one for (2), as well
as having the final removal patch behind it.  Maybe we should just queue
up all three together in the PCI tree for 4.11?
--
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] cx231xx: Initial support Evromedia USB Full Hybrid Full HD

[kbuild test robot]

Hi Oleh,

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

url:
https://github.com/0day-ci/linux/commits/Oleh-Kravchenko/cx231xx-Initial-support-Evromedia-USB-Full-Hybrid-Full-HD/20170110-033153
base:   git://linuxtv.org/media_tree.git master
config: x86_64-rhel-7.2 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/media/usb/cx231xx/cx231xx-dvb.c: In function 'dvb_init':
>> drivers/media/usb/cx231xx/cx231xx-dvb.c:967:32: warning: passing argument 3 
>> of 'strlcpy' makes integer from pointer without a cast [-Wint-conversion]
  strlcpy(info.type, "si2168", info.type);
   ^~~~
   In file included from include/linux/bitmap.h:8:0,
from include/linux/cpumask.h:11,
from arch/x86/include/asm/cpumask.h:4,
from arch/x86/include/asm/msr.h:10,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/videodev2.h:59,
from drivers/media/usb/cx231xx/cx231xx.h:25,
from drivers/media/usb/cx231xx/cx231xx-dvb.c:22:
   include/linux/string.h:27:8: note: expected 'size_t {aka long unsigned int}' 
but argument is of type 'char *'
size_t strlcpy(char *, const char *, size_t);
   ^~~
   drivers/media/usb/cx231xx/cx231xx-dvb.c:999:32: warning: passing argument 3 
of 'strlcpy' makes integer from pointer without a cast [-Wint-conversion]
  strlcpy(info.type, "si2157", info.type);
   ^~~~
   In file included from include/linux/bitmap.h:8:0,
from include/linux/cpumask.h:11,
from arch/x86/include/asm/cpumask.h:4,
from arch/x86/include/asm/msr.h:10,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/videodev2.h:59,
from drivers/media/usb/cx231xx/cx231xx.h:25,
from drivers/media/usb/cx231xx/cx231xx-dvb.c:22:
   include/linux/string.h:27:8: note: expected 'size_t {aka long unsigned int}' 
but argument is of type 'char *'
size_t strlcpy(char *, const char *, size_t);
   ^~~

vim +/strlcpy +967 drivers/media/usb/cx231xx/cx231xx-dvb.c

   951  break;
   952  
   953  case CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD:
   954  {
   955  struct si2157_config si2157_config = {};
   956  struct si2168_config si2168_config = {};
   957  struct i2c_board_info info = {};
   958  struct i2c_client *client;
   959  struct i2c_adapter *adapter;
   960  
   961  /* attach demodulator chip */
   962  si2168_config.ts_mode = SI2168_TS_SERIAL; /* from *.inf 
file */
   963  si2168_config.fe = >dvb->frontend;
   964  si2168_config.i2c_adapter = 
   965  si2168_config.ts_clock_inv = true;
   966  
 > 967  strlcpy(info.type, "si2168", info.type);
   968  info.addr = dev->board.demod_addr;
   969  info.platform_data = _config;
   970  
   971  request_module(info.type);
   972  client = i2c_new_device(demod_i2c, );
   973  
   974  if (client == NULL || client->dev.driver == NULL || 
dev->dvb->frontend == NULL) {
   975  dev_err(dev->dev, "Failed to attach Si2168 
front end\n");

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


.config.gz
Description: application/gzip

Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support

[Philipp Zabel]

Hi Steve,

Am Freitag, den 30.12.2016, 12:26 -0800 schrieb Steve Longerbeam:
> 
> On 12/30/2016 11:06 AM, Marek Vasut wrote:
> > On 12/29/2016 09:51 PM, Robert Schwebel wrote:
> >> Hi Jean-Michel,
> > Hi,
> >
> >> On Thu, Dec 29, 2016 at 04:08:33PM +0100, Jean-Michel Hautbois wrote:
> >>> What is the status of this work?
> >> Philipp's patches have been reworked with the review feedback from the
> >> last round and a new version will be posted when he is back from
> >> holidays.
> > IMO Philipp's patches are better integrated and well structured, so I'd
> > rather like to see his work in at some point.
> 
> Granted I am biased, but I will state my case. "Better integrated" - my 
> patches
> are also well integrated with the media core infrastructure. Philipp's 
> patches
> in fact require modification to media core, whereas mine require none.
> Some changes are needed of course (more subdev type definitions for
> one).
> 
> As for "well structured", I don't really understand what is meant by that,
> but my driver is also well structured.

I agree that this driver is well structured and well documented. Many of
my earlier concerns regarding the device tree bindings and media
controller interface have been addressed. But there are still a few
design choices that I don't agree with, and some are userspace visible,
which makes me worry about not being able to change them later.

One is the amount and organization of subdevices/media entities visible
to userspace. The SMFCs should not be user controllable subdevices, but
can be implicitly enabled when a CSI is directly linked to a camif.
Also I'm not convinced the 1:1 mapping of IC task to subdevices is the
best choice. It is true that the three tasks can be enabled separately,
but to my understanding, the PRP ENC and PRP VF tasks share a single
input channel. Shouldn't this be a single PRP subdevice with one input
and two (VF, ENC) outputs?
On the other hand, there is currently no way to communicate to userspace
that the IC can't downscale bilinearly, but only to 1/2 or 1/4 of the
input resolution, and then scale up bilinearly for there. So instead of
pretending to be able to downscale to any resolution, it would be better
to split each IC task into two subdevs, one for the
1/2-or-1/4-downscaler, and one for the bilinear upscaler.
Next there is the issue of the custom mem2mem infrastructure inside the
IPU driver. I think this should be ultimately implemented at a higher
level, but I see no way this will ever move out of the IPU driver once
the userspace inferface gets established.

Then there are a few issues that are not userspace visible, so less
pressing. For example modelling the internal subdevs as separate
platform devices with async subdevices seems unnecessarily indirect. Why
not drop the platform devices and create the subdevs directly instead of
asynchronously?
I'll try to give the driver a proper review in the next days.

> Philipp's driver only supports unconverted image capture from the SMFC. 
> In addition
> to that, mine allows for all the hardware links supported by the IPU, 
> including routing
> frames from the CSI directly to the Image converter for scaling up to 
> 4096x4096,

Note that tiled scaling (anything > 1024x1024) currently doesn't produce
correct results due to the fractional reset at the seam. This is not a
property of this driver, but still needs to be fixed in the ipu-v3 core.

> colorspace conversion, rotation, and motion compensated de-interlace. 
> Yes all these
> conversion can be carried out post-capture via a mem2mem device, but 
> conversion
> directly from CSI capture has advantages, including minimized CPU 
> utilization and
> lower AXI bus traffic.

These benefits are limited by the hardware to non-rotated frames <
1024x1024 pixels.

regards
Philipp

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

Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

[Matthias Brugger]

On 09/01/17 19:45, Matthias Brugger wrote:



On 09/01/17 12:29, Hans Verkuil wrote:

Hi Rick,

On 01/06/2017 03:34 AM, Rick Chang wrote:

Hi Hans,

The dependence on [1] has been merged in 4.10, but [2] has not.Do you
have
any idea about this patch series? Should we wait for [2] or we could
merge
the source code and dt-binding first?


Looking at [2] I noticed that the last comment was July 4th. What is
the reason
it hasn't been merged yet?

If I know [2] will be merged for 4.11, then I am fine with merging
this media
patch series. The dependency of this patch on [2] is something Mauro
can handle.

If [2] is not merged for 4.11, then I think it is better to wait until
it is
merged.



I can't take [2] because there is no scpsys in the dts present. It seems
that it got never posted.

Rick can you please follow-up with James and provide a patch which adds
a scpsys node to the mt2701.dtsi?



Ah I forgot, dts patches should go through my tree, so Hans please don't 
merge this patch. Bindings should go through your branch though.


Thanks,
Matthias
--
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 v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

[Matthias Brugger]

On 09/01/17 12:29, Hans Verkuil wrote:

Hi Rick,

On 01/06/2017 03:34 AM, Rick Chang wrote:

Hi Hans,

The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
any idea about this patch series? Should we wait for [2] or we could merge
the source code and dt-binding first?


Looking at [2] I noticed that the last comment was July 4th. What is the reason
it hasn't been merged yet?

If I know [2] will be merged for 4.11, then I am fine with merging this media
patch series. The dependency of this patch on [2] is something Mauro can handle.

If [2] is not merged for 4.11, then I think it is better to wait until it is
merged.



I can't take [2] because there is no scpsys in the dts present. It seems 
that it got never posted.


Rick can you please follow-up with James and provide a patch which adds 
a scpsys node to the mt2701.dtsi?


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

Re: [PATCH 1/2] Documentation: devicetree: Add document bindings for mtk-cir

[Rob Herring]

On Fri, Jan 06, 2017 at 12:06:23AM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> This patch adds documentation for devicetree bindings for
> Mediatek IR controller.
> 
> Signed-off-by: Sean Wang 
> ---
>  .../devicetree/bindings/media/mtk-cir.txt  | 23 
> ++
>  1 file changed, 23 insertions(+)
>  create mode 100644 
> linux-4.8.rc1_p0/Documentation/devicetree/bindings/media/mtk-cir.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt 
> b/Documentation/devicetree/bindings/media/mtk-cir.txt
> new file mode 100644
> index 000..bbedd71
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
> @@ -0,0 +1,23 @@
> +Device-Tree bindings for Mediatek IR controller found in Mediatek SoC family
> +
> +Required properties:
> +- compatible : "mediatek,mt7623-ir"
> +- clocks : list of clock specifiers, corresponding to
> +   entries in clock-names property;
> +- clock-names: should contain "clk" entries;
> +- interrupts : should contain IR IRQ number;
> +- reg: should contain IO map address for IR.
> +
> +Optional properties:
> +- linux,rc-map-name : Remote control map name.

Would 'label' be appropriate here instead? If not, this needs to be 
documented in a common location and explained better.

> +
> +Example:
> +
> +cir: cir@0x10013000 {

Drop the '0x'.

> + compatible = "mediatek,mt7623-ir";
> + reg = <0 0x10013000 0 0x1000>;
> + interrupts = ;
> + clocks = < CLK_INFRA_IRRX>;
> + clock-names = "clk";
> + linux,rc-map-name = "rc-rc6-mce";
> +};
> -- 
> 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: [media] uvcvideo: support for contiguous DMA buffers

[Laurent Pinchart]

Hi Vincent,

(CC'ing Nicolas)

On Monday 09 Jan 2017 15:49:00 Vincent ABRIOU wrote:
> On 01/09/2017 04:37 PM, Laurent Pinchart wrote:
> > Hi Vincent,
> > 
> > Thank you for the patch.
> > 
> > On Monday 03 Oct 2016 13:27:16 Vincent Abriou wrote:
> >> Allow uvcvideo compatible devices to allocate their output buffers using
> >> contiguous DMA buffers.
> > 
> > Why do you need this ? If it's for buffer sharing with a device that
> > requires dma-contig, can't you allocate the buffers on the other device
> > and import them on the UVC side ?
> 
> Hi Laurent,
> 
> I need this using Gstreamer simple pipeline to connect an usb webcam
> (v4l2src) with a display (waylandsink) activating the zero copy path.
> 
> The waylandsink plugin does not have any contiguous memory pool to
> allocate contiguous buffer. So it is up to the upstream element, here
> v4l2src, to provide such contiguous buffers.

Isn't that a gstreamer issue ?

> >> Add the "allocators" module parameter option to let uvcvideo use the
> >> dma-contig instead of vmalloc.
> >> 
> >> Signed-off-by: Vincent Abriou 
> >> ---
> >> 
> >>  Documentation/media/v4l-drivers/uvcvideo.rst | 12 
> >>  drivers/media/usb/uvc/Kconfig|  2 ++
> >>  drivers/media/usb/uvc/uvc_driver.c   |  3 ++-
> >>  drivers/media/usb/uvc/uvc_queue.c| 23 ++---
> >>  drivers/media/usb/uvc/uvcvideo.h |  4 ++--
> >>  5 files changed, 38 insertions(+), 6 deletions(-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] [media] cx231xx: Initial support Evromedia USB Full Hybrid Full HD

[Antti Palosaari]

On 01/09/2017 05:23 PM, Oleh Kravchenko wrote:

This patch provide only digital support.

The device is based on Si2168 30-demodulator,
Si2158-20 tuner and CX23102-11Z chipset;
USB id: 1b80:d3b2.

Status:
- DVB-T2 works fine;
- Composite and SVideo works fine;
- Analog not implemented.

Signed-off-by: Oleh Kravchenko 
Tested-by: Oleh Kravchenko 
---
 drivers/media/usb/cx231xx/Kconfig |  1 +
 drivers/media/usb/cx231xx/cx231xx-cards.c | 29 +
 drivers/media/usb/cx231xx/cx231xx-dvb.c   | 71 +++
 drivers/media/usb/cx231xx/cx231xx-i2c.c   | 37 
 drivers/media/usb/cx231xx/cx231xx.h   |  1 +
 5 files changed, 139 insertions(+)

diff --git a/drivers/media/usb/cx231xx/Kconfig 
b/drivers/media/usb/cx231xx/Kconfig
index 0cced3e..58de80b 100644
--- a/drivers/media/usb/cx231xx/Kconfig
+++ b/drivers/media/usb/cx231xx/Kconfig
@@ -50,6 +50,7 @@ config VIDEO_CX231XX_DVB
select DVB_LGDT3306A if MEDIA_SUBDRV_AUTOSELECT
select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT

---help---
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 36bc254..9b1df5a 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -841,6 +841,33 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+   [CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD] = {
+   .name = "Evromedia USB Full Hybrid Full HD",
+   .tuner_type = TUNER_ABSENT,
+   .demod_addr = 0xc8 >> 1,
+   .demod_i2c_master = I2C_1_MUX_3,
+   .has_dvb = 1,
+   .ir_i2c_master = I2C_0,
+   .norm = V4L2_STD_PAL,
+   .output_mode = OUT_MODE_VIP11,
+   .tuner_addr = 0xc0 >> 1,


These "8-bit" I2C addresses looks funny, but if that's used by cx231xx 
driver then leave...




+   .tuner_i2c_master = I2C_2,
+   .input = {{
+   .type = CX231XX_VMUX_TELEVISION,
+   .vmux = 0,
+   .amux = CX231XX_AMUX_VIDEO,
+   }, {
+   .type = CX231XX_VMUX_COMPOSITE1,
+   .vmux = CX231XX_VIN_2_1,
+   .amux = CX231XX_AMUX_LINE_IN,
+   }, {
+   .type = CX231XX_VMUX_SVIDEO,
+   .vmux = CX231XX_VIN_1_1 |
+   (CX231XX_VIN_1_2 << 8) |
+   CX25840_SVIDEO_ON,
+   .amux = CX231XX_AMUX_LINE_IN,
+   } },
+   },
 };
 const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);

@@ -908,6 +935,8 @@ struct usb_device_id cx231xx_id_table[] = {
 .driver_info = CX231XX_BOARD_OTG102},
{USB_DEVICE(USB_VID_TERRATEC, 0x00a6),
 .driver_info = CX231XX_BOARD_TERRATEC_GRABBY},
+   {USB_DEVICE(0x1b80, 0xd3b2),
+   .driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
{},
 };

diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 1417515..08472a3 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -33,6 +33,7 @@
 #include "s5h1411.h"
 #include "lgdt3305.h"
 #include "si2165.h"
+#include "si2168.h"
 #include "mb86a20s.h"
 #include "si2157.h"
 #include "lgdt3306a.h"
@@ -949,6 +950,76 @@ static int dvb_init(struct cx231xx *dev)
   _tda18271_config);
break;

+   case CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD:
+   {
+   struct si2157_config si2157_config = {};
+   struct si2168_config si2168_config = {};
+   struct i2c_board_info info = {};
+   struct i2c_client *client;
+   struct i2c_adapter *adapter;
+
+   /* attach demodulator chip */
+   si2168_config.ts_mode = SI2168_TS_SERIAL; /* from *.inf file */
+   si2168_config.fe = >dvb->frontend;
+   si2168_config.i2c_adapter = 
+   si2168_config.ts_clock_inv = true;
+
+   strlcpy(info.type, "si2168", info.type);
+   info.addr = dev->board.demod_addr;
+   info.platform_data = _config;
+
+   request_module(info.type);
+   client = i2c_new_device(demod_i2c, );
+
+   if (client == NULL || client->dev.driver == NULL || 
dev->dvb->frontend == NULL) {


No need to check frontend here, or at least I cannot see why it should? 
Does the cx231xx initialize with some special value before calling 
si2168 probe - which will set it? client and driver will be null in case 
si2168 

RE: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

[Ramesh Shanmugasundaram]

Hi Hans,

Thanks for the review.

> >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote:
>  Add binding documentation for Renesas R-Car Digital Radio Interface
>  (DRIF) controller.
> 
>  Signed-off-by: Ramesh Shanmugasundaram
>   ---
>   .../devicetree/bindings/media/renesas,drif.txt | 202
> >> ++
>   1 file changed, 202 insertions(+)
>   create mode 100644
>  Documentation/devicetree/bindings/media/renesas,drif.txt
> 
>  diff --git
>  a/Documentation/devicetree/bindings/media/renesas,drif.txt
>  b/Documentation/devicetree/bindings/media/renesas,drif.txt new file
>  mode
>  100644
>  index 000..1f3feaf
>  --- /dev/null
>  +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> >>
>  +Optional properties of an internal channel when:
>  + - It is the only enabled channel of the bond (or)
>  + - If it acts as primary among enabled bonds
>  +
>  +- renesas,syncmd   : sync mode
>  +  0 (Frame start sync pulse mode. 1-bit width
> >> pulse
>  + indicates start of a frame)
>  +  1 (L/R sync or I2S mode) (default)
>  +- renesas,lsb-first: empty property indicates lsb bit is
> received
>  first.
>  +  When not defined msb bit is received first
>  +(default)
>  +- renesas,syncac-active: Indicates sync signal polarity, 0/1 for
> >> low/high
> 
> Shouldn't this be 'renesas,sync-active' instead of syncac-active?
> 
> I'm not sure if syncac is intended or if it is a typo.

Yes, "syncac" is intended. I kept the same name as in h/w manual for easy 
reference. Same for other properties - syncmd, dtdl & syncdl.

> 
>  +  respectively. The default is 1 (active high)
>  +- renesas,dtdl : delay between sync signal and start of
> >> reception.
>  +  The possible values are represented in 0.5
> clock
>  +  cycle units and the range is 0 to 4. The
> default
>  +  value is 2 (i.e.) 1 clock cycle delay.
>  +- renesas,syncdl   : delay between end of reception and sync
> >> signal
>  edge.
>  +  The possible values are represented in 0.5
> clock
>  +  cycle units and the range is 0 to 4 & 6. The
> >> default
>  +  value is 0 (i.e.) no delay.
> >>>
> >>> Most of these properties are pretty similar to the video bus
> >>> properties defined at the endpoint level in
> >>> Documentation/devicetree/bindings/media/video-interfaces.txt. I
> >>> believe it would make sense to use OF graph and try to standardize
> >>> these properties similarly.
> 
> Other than sync-active, is there really anything else that is similar? And
> even the sync-active isn't a good fit since here there is only one sync
> signal instead of two for video (h and vsync).
> 
> Regards,
> 
>   Hans
> 

Thanks,
Ramesh
N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

Re: [media] uvcvideo: support for contiguous DMA buffers

[Vincent ABRIOU]

On 01/09/2017 04:37 PM, Laurent Pinchart wrote:
> Hi Vincent,
>
> Thank you for the patch.
>
> On Monday 03 Oct 2016 13:27:16 Vincent Abriou wrote:
>> Allow uvcvideo compatible devices to allocate their output buffers using
>> contiguous DMA buffers.
>
> Why do you need this ? If it's for buffer sharing with a device that requires
> dma-contig, can't you allocate the buffers on the other device and import them
> on the UVC side ?
>

Hi Laurent,

I need this using Gstreamer simple pipeline to connect an usb webcam 
(v4l2src) with a display (waylandsink) activating the zero copy path.

The waylandsink plugin does not have any contiguous memory pool to 
allocate contiguous buffer. So it is up to the upstream element, here 
v4l2src, to provide such contiguous buffers.

Vincent

>> Add the "allocators" module parameter option to let uvcvideo use the
>> dma-contig instead of vmalloc.
>>
>> Signed-off-by: Vincent Abriou 
>> ---
>>  Documentation/media/v4l-drivers/uvcvideo.rst | 12 
>>  drivers/media/usb/uvc/Kconfig|  2 ++
>>  drivers/media/usb/uvc/uvc_driver.c   |  3 ++-
>>  drivers/media/usb/uvc/uvc_queue.c| 23 ---
>>  drivers/media/usb/uvc/uvcvideo.h |  4 ++--
>>  5 files changed, 38 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/media/v4l-drivers/uvcvideo.rst
>> b/Documentation/media/v4l-drivers/uvcvideo.rst index d68b3d5..786cff5
>> 100644
>> --- a/Documentation/media/v4l-drivers/uvcvideo.rst
>> +++ b/Documentation/media/v4l-drivers/uvcvideo.rst
>> @@ -7,6 +7,18 @@ driver-specific ioctls and implementation notes.
>>  Questions and remarks can be sent to the Linux UVC development mailing list
>> at linux-uvc-de...@lists.berlios.de.
>>
>> +Configuring the driver
>> +--
>> +
>> +The driver is configurable using the following module option:
>> +
>> +- allocators:
>> +
>> +memory allocator selection, default is 0. It specifies the way buffers
>> +will be allocated.
>> +
>> +- 0: vmalloc
>> +- 1: dma-contig
>>
>>  Extension Unit (XU) support
>>  ---
>> diff --git a/drivers/media/usb/uvc/Kconfig b/drivers/media/usb/uvc/Kconfig
>> index 6ed85efa..71e4d7e 100644
>> --- a/drivers/media/usb/uvc/Kconfig
>> +++ b/drivers/media/usb/uvc/Kconfig
>> @@ -1,7 +1,9 @@
>>  config USB_VIDEO_CLASS
>>  tristate "USB Video Class (UVC)"
>>  depends on VIDEO_V4L2
>> +depends on HAS_DMA
>
> This will prevent using the uvcvideo driver on platforms that don't set
> HAS_DMA, which would be a regression compared to the current situation.
>
>>  select VIDEOBUF2_VMALLOC
>> +select VIDEOBUF2_DMA_CONTIG
>
> Shouldn't you make this configurable ? I don't think we want to hardcode the
> dependency on VIDEOBUF2_DMA_CONTIG, it should be possible to compile a kernel
> with USB_VIDEO_CLASS and without VIDEOBUF2_DMA_CONTIG when the user isn't
> interested in the dma-contig allocator.
>
>>  ---help---
>>Support for the USB Video Class (UVC).  Currently only video
>>input devices, such as webcams, are supported.
>> diff --git a/drivers/media/usb/uvc/uvc_driver.c
>> b/drivers/media/usb/uvc/uvc_driver.c index 302e284..1c20aa0 100644
>> --- a/drivers/media/usb/uvc/uvc_driver.c
>> +++ b/drivers/media/usb/uvc/uvc_driver.c
>> @@ -1757,7 +1757,8 @@ static int uvc_register_video(struct uvc_device *dev,
>>  int ret;
>>
>>  /* Initialize the video buffers queue. */
>> -ret = uvc_queue_init(>queue, stream->type,
> !uvc_no_drop_param);
>> +ret = uvc_queue_init(dev, >queue, stream->type,
>> + !uvc_no_drop_param);
>>  if (ret)
>>  return ret;
>>
>> diff --git a/drivers/media/usb/uvc/uvc_queue.c
>> b/drivers/media/usb/uvc/uvc_queue.c index 77edd20..5eab146 100644
>> --- a/drivers/media/usb/uvc/uvc_queue.c
>> +++ b/drivers/media/usb/uvc/uvc_queue.c
>> @@ -22,6 +22,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>
> Alphabetically sorted please.
>
>>  #include "uvcvideo.h"
>>
>> @@ -37,6 +38,12 @@
>>   * the driver.
>>   */
>>
>> +static unsigned int allocators;
>> +module_param(allocators, uint, 0444);
>> +MODULE_PARM_DESC(allocators, " memory allocator selection, default is 0.\n"
>> + "\t\t0 == vmalloc\n"
>> + "\t\t1 == dma-contig");
>> +
>>  static inline struct uvc_streaming *
>>  uvc_queue_to_stream(struct uvc_video_queue *queue)
>>  {
>> @@ -188,20 +195,30 @@ static const struct vb2_ops uvc_queue_qops = {
>>  .stop_streaming = uvc_stop_streaming,
>>  };
>>
>> -int uvc_queue_init(struct uvc_video_queue *queue, enum v4l2_buf_type type,
>> -int drop_corrupted)
>> +int uvc_queue_init(struct uvc_device *dev, struct uvc_video_queue *queue,
>
> You don't need the new argument, you can call uvc_queue_to_stream() to get the
> struct uvc_streaming pointer for the queue, from which you can retrieve 

[PATCH] media/usbvision: remove ctrl_urb_wq

[Davidlohr Bueso]

While the wakeup path seems to be set up, this waitqueue is actually
never used as no-one enqueues themselves on the list. As such, wakeups
are meaningless without waiters, so lets just get rid of the whole
thing.

Signed-off-by: Davidlohr Bueso 
---
 drivers/media/usb/usbvision/usbvision-core.c  | 2 --
 drivers/media/usb/usbvision/usbvision-video.c | 1 -
 drivers/media/usb/usbvision/usbvision.h   | 1 -
 3 files changed, 4 deletions(-)

diff --git a/drivers/media/usb/usbvision/usbvision-core.c 
b/drivers/media/usb/usbvision/usbvision-core.c
index bf041a9e69db..c938aa477edf 100644
--- a/drivers/media/usb/usbvision/usbvision-core.c
+++ b/drivers/media/usb/usbvision/usbvision-core.c
@@ -1417,8 +1417,6 @@ static void usbvision_ctrl_urb_complete(struct urb *urb)
 
PDEBUG(DBG_IRQ, "");
usbvision->ctrl_urb_busy = 0;
-   if (waitqueue_active(>ctrl_urb_wq))
-   wake_up_interruptible(>ctrl_urb_wq);
 }
 
 
diff --git a/drivers/media/usb/usbvision/usbvision-video.c 
b/drivers/media/usb/usbvision/usbvision-video.c
index a7529196c327..97685d0ad7c9 100644
--- a/drivers/media/usb/usbvision/usbvision-video.c
+++ b/drivers/media/usb/usbvision/usbvision-video.c
@@ -1340,7 +1340,6 @@ static struct usb_usbvision *usbvision_alloc(struct 
usb_device *dev,
usbvision->ctrl_urb = usb_alloc_urb(USBVISION_URB_FRAMES, GFP_KERNEL);
if (usbvision->ctrl_urb == NULL)
goto err_unreg;
-   init_waitqueue_head(>ctrl_urb_wq);
 
return usbvision;
 
diff --git a/drivers/media/usb/usbvision/usbvision.h 
b/drivers/media/usb/usbvision/usbvision.h
index 4f2e4fde38f2..a5268c4f6a17 100644
--- a/drivers/media/usb/usbvision/usbvision.h
+++ b/drivers/media/usb/usbvision/usbvision.h
@@ -370,7 +370,6 @@ struct usb_usbvision {
unsigned char ctrl_urb_buffer[8];
int ctrl_urb_busy;
struct usb_ctrlrequest ctrl_urb_setup;
-   wait_queue_head_t ctrl_urb_wq;  /* 
Processes waiting */
 
/* configuration part */
int have_tuner;
-- 
2.6.6

--
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: [media] uvcvideo: support for contiguous DMA buffers

[Laurent Pinchart]

Hi Vincent,

Thank you for the patch.

On Monday 03 Oct 2016 13:27:16 Vincent Abriou wrote:
> Allow uvcvideo compatible devices to allocate their output buffers using
> contiguous DMA buffers.

Why do you need this ? If it's for buffer sharing with a device that requires 
dma-contig, can't you allocate the buffers on the other device and import them 
on the UVC side ?

> Add the "allocators" module parameter option to let uvcvideo use the
> dma-contig instead of vmalloc.
> 
> Signed-off-by: Vincent Abriou 
> ---
>  Documentation/media/v4l-drivers/uvcvideo.rst | 12 
>  drivers/media/usb/uvc/Kconfig|  2 ++
>  drivers/media/usb/uvc/uvc_driver.c   |  3 ++-
>  drivers/media/usb/uvc/uvc_queue.c| 23 ---
>  drivers/media/usb/uvc/uvcvideo.h |  4 ++--
>  5 files changed, 38 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/media/v4l-drivers/uvcvideo.rst
> b/Documentation/media/v4l-drivers/uvcvideo.rst index d68b3d5..786cff5
> 100644
> --- a/Documentation/media/v4l-drivers/uvcvideo.rst
> +++ b/Documentation/media/v4l-drivers/uvcvideo.rst
> @@ -7,6 +7,18 @@ driver-specific ioctls and implementation notes.
>  Questions and remarks can be sent to the Linux UVC development mailing list
> at linux-uvc-de...@lists.berlios.de.
> 
> +Configuring the driver
> +--
> +
> +The driver is configurable using the following module option:
> +
> +- allocators:
> +
> + memory allocator selection, default is 0. It specifies the way buffers
> + will be allocated.
> +
> + - 0: vmalloc
> + - 1: dma-contig
> 
>  Extension Unit (XU) support
>  ---
> diff --git a/drivers/media/usb/uvc/Kconfig b/drivers/media/usb/uvc/Kconfig
> index 6ed85efa..71e4d7e 100644
> --- a/drivers/media/usb/uvc/Kconfig
> +++ b/drivers/media/usb/uvc/Kconfig
> @@ -1,7 +1,9 @@
>  config USB_VIDEO_CLASS
>   tristate "USB Video Class (UVC)"
>   depends on VIDEO_V4L2
> + depends on HAS_DMA

This will prevent using the uvcvideo driver on platforms that don't set 
HAS_DMA, which would be a regression compared to the current situation.

>   select VIDEOBUF2_VMALLOC
> + select VIDEOBUF2_DMA_CONTIG

Shouldn't you make this configurable ? I don't think we want to hardcode the 
dependency on VIDEOBUF2_DMA_CONTIG, it should be possible to compile a kernel 
with USB_VIDEO_CLASS and without VIDEOBUF2_DMA_CONTIG when the user isn't 
interested in the dma-contig allocator.

>   ---help---
> Support for the USB Video Class (UVC).  Currently only video
> input devices, such as webcams, are supported.
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index 302e284..1c20aa0 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1757,7 +1757,8 @@ static int uvc_register_video(struct uvc_device *dev,
>   int ret;
> 
>   /* Initialize the video buffers queue. */
> - ret = uvc_queue_init(>queue, stream->type, 
!uvc_no_drop_param);
> + ret = uvc_queue_init(dev, >queue, stream->type,
> +  !uvc_no_drop_param);
>   if (ret)
>   return ret;
> 
> diff --git a/drivers/media/usb/uvc/uvc_queue.c
> b/drivers/media/usb/uvc/uvc_queue.c index 77edd20..5eab146 100644
> --- a/drivers/media/usb/uvc/uvc_queue.c
> +++ b/drivers/media/usb/uvc/uvc_queue.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Alphabetically sorted please.

>  #include "uvcvideo.h"
> 
> @@ -37,6 +38,12 @@
>   * the driver.
>   */
> 
> +static unsigned int allocators;
> +module_param(allocators, uint, 0444);
> +MODULE_PARM_DESC(allocators, " memory allocator selection, default is 0.\n"
> +  "\t\t0 == vmalloc\n"
> +  "\t\t1 == dma-contig");
> +
>  static inline struct uvc_streaming *
>  uvc_queue_to_stream(struct uvc_video_queue *queue)
>  {
> @@ -188,20 +195,30 @@ static const struct vb2_ops uvc_queue_qops = {
>   .stop_streaming = uvc_stop_streaming,
>  };
> 
> -int uvc_queue_init(struct uvc_video_queue *queue, enum v4l2_buf_type type,
> - int drop_corrupted)
> +int uvc_queue_init(struct uvc_device *dev, struct uvc_video_queue *queue,

You don't need the new argument, you can call uvc_queue_to_stream() to get the 
struct uvc_streaming pointer for the queue, from which you can retrieve the 
device pointer you're interested in.

> +enum v4l2_buf_type type, int drop_corrupted)
>  {
>   int ret;
> + static const struct vb2_mem_ops * const uvc_mem_ops[2] = {
> + _vmalloc_memops,
> + _dma_contig_memops,
> + };
> +
> + if (allocators == 1)

Please define macros instead of hardcoding values.

> + dma_coerce_mask_and_coherent(dev->vdev.dev, DMA_BIT_MASK(32));

This is completely artificial, why 32 bits and not 24 or 

[PATCH] [media] cx231xx: Initial support Evromedia USB Full Hybrid Full HD

[Oleh Kravchenko]

This patch provide only digital support.

The device is based on Si2168 30-demodulator,
Si2158-20 tuner and CX23102-11Z chipset;
USB id: 1b80:d3b2.

Status:
- DVB-T2 works fine;
- Composite and SVideo works fine;
- Analog not implemented.

Signed-off-by: Oleh Kravchenko 
Tested-by: Oleh Kravchenko 
---
 drivers/media/usb/cx231xx/Kconfig |  1 +
 drivers/media/usb/cx231xx/cx231xx-cards.c | 29 +
 drivers/media/usb/cx231xx/cx231xx-dvb.c   | 71 +++
 drivers/media/usb/cx231xx/cx231xx-i2c.c   | 37 
 drivers/media/usb/cx231xx/cx231xx.h   |  1 +
 5 files changed, 139 insertions(+)

diff --git a/drivers/media/usb/cx231xx/Kconfig 
b/drivers/media/usb/cx231xx/Kconfig
index 0cced3e..58de80b 100644
--- a/drivers/media/usb/cx231xx/Kconfig
+++ b/drivers/media/usb/cx231xx/Kconfig
@@ -50,6 +50,7 @@ config VIDEO_CX231XX_DVB
select DVB_LGDT3306A if MEDIA_SUBDRV_AUTOSELECT
select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
 
---help---
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 36bc254..9b1df5a 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -841,6 +841,33 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+   [CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD] = {
+   .name = "Evromedia USB Full Hybrid Full HD",
+   .tuner_type = TUNER_ABSENT,
+   .demod_addr = 0xc8 >> 1,
+   .demod_i2c_master = I2C_1_MUX_3,
+   .has_dvb = 1,
+   .ir_i2c_master = I2C_0,
+   .norm = V4L2_STD_PAL,
+   .output_mode = OUT_MODE_VIP11,
+   .tuner_addr = 0xc0 >> 1,
+   .tuner_i2c_master = I2C_2,
+   .input = {{
+   .type = CX231XX_VMUX_TELEVISION,
+   .vmux = 0,
+   .amux = CX231XX_AMUX_VIDEO,
+   }, {
+   .type = CX231XX_VMUX_COMPOSITE1,
+   .vmux = CX231XX_VIN_2_1,
+   .amux = CX231XX_AMUX_LINE_IN,
+   }, {
+   .type = CX231XX_VMUX_SVIDEO,
+   .vmux = CX231XX_VIN_1_1 |
+   (CX231XX_VIN_1_2 << 8) |
+   CX25840_SVIDEO_ON,
+   .amux = CX231XX_AMUX_LINE_IN,
+   } },
+   },
 };
 const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
 
@@ -908,6 +935,8 @@ struct usb_device_id cx231xx_id_table[] = {
 .driver_info = CX231XX_BOARD_OTG102},
{USB_DEVICE(USB_VID_TERRATEC, 0x00a6),
 .driver_info = CX231XX_BOARD_TERRATEC_GRABBY},
+   {USB_DEVICE(0x1b80, 0xd3b2),
+   .driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
{},
 };
 
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 1417515..08472a3 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -33,6 +33,7 @@
 #include "s5h1411.h"
 #include "lgdt3305.h"
 #include "si2165.h"
+#include "si2168.h"
 #include "mb86a20s.h"
 #include "si2157.h"
 #include "lgdt3306a.h"
@@ -949,6 +950,76 @@ static int dvb_init(struct cx231xx *dev)
   _tda18271_config);
break;
 
+   case CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD:
+   {
+   struct si2157_config si2157_config = {};
+   struct si2168_config si2168_config = {};
+   struct i2c_board_info info = {};
+   struct i2c_client *client;
+   struct i2c_adapter *adapter;
+
+   /* attach demodulator chip */
+   si2168_config.ts_mode = SI2168_TS_SERIAL; /* from *.inf file */
+   si2168_config.fe = >dvb->frontend;
+   si2168_config.i2c_adapter = 
+   si2168_config.ts_clock_inv = true;
+
+   strlcpy(info.type, "si2168", info.type);
+   info.addr = dev->board.demod_addr;
+   info.platform_data = _config;
+
+   request_module(info.type);
+   client = i2c_new_device(demod_i2c, );
+
+   if (client == NULL || client->dev.driver == NULL || 
dev->dvb->frontend == NULL) {
+   dev_err(dev->dev, "Failed to attach Si2168 front 
end\n");
+   result = -EINVAL;
+   goto out_free;
+   }
+
+   if (!try_module_get(client->dev.driver->owner)) {
+   i2c_unregister_device(client);
+   result = -ENODEV;
+   

Re: [PATCH v2] [media] vivid: support for contiguous DMA buffers

[Hans Verkuil]

On 09/12/2016 10:47 AM, Vincent Abriou wrote:
> It allows to simulate the behavior of hardware with such limitations or
> to connect vivid to real hardware with such limitations.
> 
> Add the "allocators" module parameter option to let vivid use the
> dma-contig instead of vmalloc.
> 
> Signed-off-by: Philipp Zabel 
> Signed-off-by: Hans Verkuil 
> Signed-off-by: Vincent Abriou 
> 
> Cc: Philipp Zabel 
> Cc: Hans Verkuil 
> ---
>  Documentation/media/v4l-drivers/vivid.rst |  8 
>  drivers/media/platform/vivid/Kconfig  |  2 ++
>  drivers/media/platform/vivid/vivid-core.c | 32 
> ++-
>  3 files changed, 37 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/media/v4l-drivers/vivid.rst 
> b/Documentation/media/v4l-drivers/vivid.rst
> index c8cf371..3e44b22 100644
> --- a/Documentation/media/v4l-drivers/vivid.rst
> +++ b/Documentation/media/v4l-drivers/vivid.rst
> @@ -263,6 +263,14 @@ all configurable using the following module options:
>   removed. Unless overridden by ccs_cap_mode and/or ccs_out_mode the
>   will default to enabling crop, compose and scaling.
>  
> +- allocators:
> +
> + memory allocator selection, default is 0. It specifies the way buffers
> + will be allocated.
> +
> + - 0: vmalloc
> + - 1: dma-contig

Could you add support for dma-sg as well? I think that would be fairly trivial 
(unless
I missed something).

Once that's added (or it's clear dma-sg won't work for some reason), then I'll 
merge this.

Regards,

Hans

> +
>  Taken together, all these module options allow you to precisely customize
>  the driver behavior and test your application with all sorts of permutations.
>  It is also very suitable to emulate hardware that is not yet available, e.g.
> diff --git a/drivers/media/platform/vivid/Kconfig 
> b/drivers/media/platform/vivid/Kconfig
> index 8e6918c..2e238a1 100644
> --- a/drivers/media/platform/vivid/Kconfig
> +++ b/drivers/media/platform/vivid/Kconfig
> @@ -1,6 +1,7 @@
>  config VIDEO_VIVID
>   tristate "Virtual Video Test Driver"
>   depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64 && FB
> + depends on HAS_DMA
>   select FONT_SUPPORT
>   select FONT_8x16
>   select FB_CFB_FILLRECT
> @@ -8,6 +9,7 @@ config VIDEO_VIVID
>   select FB_CFB_IMAGEBLIT
>   select MEDIA_CEC_EDID
>   select VIDEOBUF2_VMALLOC
> + select VIDEOBUF2_DMA_CONTIG
>   select VIDEO_V4L2_TPG
>   default n
>   ---help---
> diff --git a/drivers/media/platform/vivid/vivid-core.c 
> b/drivers/media/platform/vivid/vivid-core.c
> index 741460a..02e1909 100644
> --- a/drivers/media/platform/vivid/vivid-core.c
> +++ b/drivers/media/platform/vivid/vivid-core.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -151,6 +152,12 @@ static bool no_error_inj;
>  module_param(no_error_inj, bool, 0444);
>  MODULE_PARM_DESC(no_error_inj, " if set disable the error injecting 
> controls");
>  
> +static unsigned int allocators[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 
> 1)] = 0 };
> +module_param_array(allocators, uint, NULL, 0444);
> +MODULE_PARM_DESC(allocators, " memory allocator selection, default is 0.\n"
> +  "\t\t0 == vmalloc\n"
> +  "\t\t1 == dma-contig");
> +
>  static struct vivid_dev *vivid_devs[VIVID_MAX_DEVS];
>  
>  const struct v4l2_rect vivid_min_rect = {
> @@ -636,6 +643,10 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>  {
>   static const struct v4l2_dv_timings def_dv_timings =
>   V4L2_DV_BT_CEA_1280X720P60;
> + static const struct vb2_mem_ops * const vivid_mem_ops[2] = {
> + _vmalloc_memops,
> + _dma_contig_memops,
> + };
>   unsigned in_type_counter[4] = { 0, 0, 0, 0 };
>   unsigned out_type_counter[4] = { 0, 0, 0, 0 };
>   int ccs_cap = ccs_cap_mode[inst];
> @@ -646,6 +657,7 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>   struct video_device *vfd;
>   struct vb2_queue *q;
>   unsigned node_type = node_types[inst];
> + unsigned int allocator = allocators[inst];
>   v4l2_std_id tvnorms_cap = 0, tvnorms_out = 0;
>   int ret;
>   int i;
> @@ -1036,6 +1048,11 @@ static int vivid_create_instance(struct 
> platform_device *pdev, int inst)
>   if (!dev->cec_workqueue)
>   goto unreg_dev;
>  
> + if (allocator == 1)
> + dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
> + else if (allocator >= ARRAY_SIZE(vivid_mem_ops))
> + allocator = 0;
> +
>   /* start creating the vb2 queues */
>   if (dev->has_vid_cap) {
>   /* initialize vid_cap queue */
> @@ -1046,10 +1063,11 @@ 

Re: [PATCH v2] [media] vivid: support for contiguous DMA buffers

[Hans Verkuil]

On 11/22/2016 02:18 PM, Vincent ABRIOU wrote:
> Hi Hans,
> 
> Is there any issue so that those 2 patches cannot be merged?
> [media] vivid: support for contiguous DMA buffer

I've requested support for dma-sg, see my reply to the patch. Looks good
otherwise.

> [media] uvcvideo: support for contiguous DMA buffers

This is up to Laurent (CC-ed).

Regards,

Hans

> 
> They both have same approach and have been tested against ARM and X86 
> platform.
> 
> Thanks.
> BR
> Vincent
> 
> On 09/12/2016 05:56 PM, Javier Martinez Canillas wrote:
>> Hello Vincent,
>>
>> On Mon, Sep 12, 2016 at 4:47 AM, Vincent Abriou  
>> wrote:
>>> It allows to simulate the behavior of hardware with such limitations or
>>> to connect vivid to real hardware with such limitations.
>>>
>>> Add the "allocators" module parameter option to let vivid use the
>>> dma-contig instead of vmalloc.
>>>
>>> Signed-off-by: Philipp Zabel 
>>> Signed-off-by: Hans Verkuil 
>>> Signed-off-by: Vincent Abriou 
>>>
>>> Cc: Philipp Zabel 
>>> Cc: Hans Verkuil 
>>> ---
>>
>> The patch looks good to me.
>>
>> Reviewed-by: Javier Martinez Canillas 
>>
>> I've also tested on an Exynos5 board to share DMA buffers between a
>> vivid capture device and the Exynos DRM driver, so:
>>
>> Tested-by: Javier Martinez Canillas 
>>
>> Before $SUBJECT, when vivid was always using the vb2 vmalloc memory
>> allocator, the Exynos DRM driver wasn't able to import the dma-buf
>> because the GEM buffers are non-contiguous:
>>
>> $ gst-launch-1.0 v4l2src device=/dev/video7 io-mode=dmabuf ! kmssink
>> Setting pipeline to PAUSED ...
>> Pipeline is live and does not need PREROLL ...
>> Setting pipeline to PLAYING ...
>> New clock: GstSystemClock
>> 0:00:00.853895814  29570xd6260 ERROR   kmsallocator
>> gstkmsallocator.c:334:gst_kms_allocator_add_fb:
>> Failed to bind to framebuffer: Invalid argument (-22)
>>
>> [ 1757.390564] [drm:exynos_drm_framebuffer_init] *ERROR* cannot use
>> this gem memory type for fb.
>>
>> The issue goes away when using the the vb2 DMA contig memory allocator.
>>
>> Best regards,
>> Javier
>> N�r��y���b�X��ǧv�^�)޺{.n�+{���bj)���w*jg����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a�����G���h��j:+v���w�٥

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

Possible media summit in Portland: who will be at the ELC?

[Hans Verkuil]

Mauro is on vacation until the 21st, so he asked me to see who will go to the 
ELC
in Portland in February.

If there are enough core developers there, then we can organize a summit meeting
on the Monday (Feb 20).

Please mail me if you can (and want) attend a possible summit meeting on the 
20th.

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] [sur40] mapping of sensor parameters to V4L2?

[Hans Verkuil]

On 01/03/2017 01:57 PM, Florian Echtler wrote:
> Hi everyone,
> 
> next chapter in the neverending story of reverse-engineering the SUR40:
> 
> I've identified a couple of internal LCD panel registers which control 
> some aspects of the built-in image sensor. In particular, these are called 
> "Video Voltage", "Video Bias", and "IR Illumination Level".
> 
> Now, I have two questions:
> 
> - Video Voltage & Bias seem to affect the sensor gain. Does anyone with 
> extensive background knowledge of image sensors want to venture a guess 
> what the exact relation is? My own interpretation would be that Video 
> Voltage is the actual amplifier gain and Video Bias is the black level...
> 
> - Is there a sensible mapping of these values to V4L2 controls? Should I 
> pick something from the USER class, or from CAMERA, or FLASH, or ...

I think it would be best to add a control class for touch device and add
these controls there.

It's pretty specific to such devices, so that would make sense.

Regards,

Hans

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

Re: [PATCH 01/10] doc: DT: camss: Binding document for Qualcomm Camera subsystem driver

[Todor Tomov]

Hi Rob,

Happy new year,
And thank you for the review.

On 12/01/2016 12:03 AM, Rob Herring wrote:
> On Fri, Nov 25, 2016 at 04:56:53PM +0200, Todor Tomov wrote:
>> Add DT binding document for Qualcomm Camera subsystem driver.
>>
>> Signed-off-by: Todor Tomov 
>> ---
>>  .../devicetree/bindings/media/qcom,camss.txt   | 196 
>> +
>>  1 file changed, 196 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/qcom,camss.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt 
>> b/Documentation/devicetree/bindings/media/qcom,camss.txt
>> new file mode 100644
>> index 000..76ad89a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
>> @@ -0,0 +1,196 @@
>> +Qualcomm Camera Subsystem
>> +
>> +* Properties
>> +
>> +- compatible:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain:
>> +- "qcom,8x16-camss"
> 
> Don't use wildcards in compatible strings. One string per SoC.

Ok, I'll fix this.

> 
>> +- reg:
>> +Usage: required
>> +Value type: 
>> +Definition: Register ranges as listed in the reg-names property.
>> +- reg-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain the following entries:
>> +- "csiphy0"
>> +- "csiphy0_clk_mux"
>> +- "csiphy1"
>> +- "csiphy1_clk_mux"
>> +- "csid0"
>> +- "csid1"
>> +- "ispif"
>> +- "csi_clk_mux"
>> +- "vfe0"
> 
> Kind of looks like the phy's should be separate nodes since each phy has 
> its own register range, irq, clocks, etc.

Yes, there are a lot of hardware resources here.
I have decided to keep everything into a single platform device as this
represents it better from system point of view.

> 
>> +- interrupts:
>> +Usage: required
>> +Value type: 
>> +Definition: Interrupts as listed in the interrupt-names property.
>> +- interrupt-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain the following entries:
>> +- "csiphy0"
>> +- "csiphy1"
>> +- "csid0"
>> +- "csid1"
>> +- "ispif"
>> +- "vfe0"
>> +- power-domains:
>> +Usage: required
>> +Value type: 
>> +Definition: A phandle and power domain specifier pairs to the
>> +power domain which is responsible for collapsing
>> +and restoring power to the peripheral.
>> +- clocks:
>> +Usage: required
>> +Value type: 
>> +Definition: A list of phandle and clock specifier pairs as listed
>> +in clock-names property.
>> +- clock-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain the following entries:
>> +- "camss_top_ahb_clk"
>> +- "ispif_ahb_clk"
>> +- "csiphy0_timer_clk"
>> +- "csiphy1_timer_clk"
>> +- "csi0_ahb_clk"
>> +- "csi0_clk"
>> +- "csi0_phy_clk"
>> +- "csi0_pix_clk"
>> +- "csi0_rdi_clk"
>> +- "csi1_ahb_clk"
>> +- "csi1_clk"
>> +- "csi1_phy_clk"
>> +- "csi1_pix_clk"
>> +- "csi1_rdi_clk"
>> +- "camss_ahb_clk"
>> +- "camss_vfe_vfe_clk"
>> +- "camss_csi_vfe_clk"
>> +- "iface_clk"
>> +- "bus_clk"
>> +- vdda-supply:
>> +Usage: required
>> +Value type: 
>> +Definition: A phandle to voltage supply for CSI2.
>> +- iommus:
>> +Usage: required
>> +Value type: 
>> +Definition: A list of phandle and IOMMU specifier pairs.
>> +
>> +* Nodes
>> +
>> +- ports:
>> +Usage: required
>> +Definition: As described in video-interfaces.txt in same directory.
>> +Properties:
>> +- reg:
>> +Usage: required
>> +Value type: 
>> +Definition: Selects CSI2 PHY interface - PHY0 or PHY1.
>> +Endpoint node properties:
>> +- clock-lanes:
>> +Usage: required
>> +Value type: 
>> +Definition: The clock lane.
>> +- data-lanes:
>> +Usage: required
>> +Value type: 
>> +Definition: An array of data lanes.
>> +- qcom,settle-cnt:
> 
> This should go in phy node ideally.
> 
>> +Usage: required
>> +Value type: 
>> +Definition: The settle count parameter for CSI PHY.
>> +
>> +* An Example
>> +
>> +camss: camss@1b0 {
>> +compatible = "qcom,8x16-camss";
>> +reg = <0x1b0ac00 0x200>,
>> +<0x1b00030 0x4>,
>> +<0x1b0b000 0x200>,
>> +<0x1b00038 0x4>,
>> +<0x1b08000 0x100>,
>> +

[GIT PULL v2 FOR v4.11] More fixes/enhancements

[Hans Verkuil]

Changes since v1:

- removed the "v4l2-common: fix aligned value calculation": it was withdrawn 
and I
  missed that.
- added pvrusb2-io cleanup patches.

Regards,

Hans

The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a:

  [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.11b

for you to fetch changes up to e8338cdfa3ccef452c3a521d447d8f6dce231d03:

  pvrusb2-io: Add some spaces for better code readability (2017-01-09 15:13:11 
+0100)


Andrzej Hajda (1):
  v4l: s5c73m3: fix negation operator

Kees Cook (2):
  mtk-vcodec: use designated initializers
  solo6x10: use designated initializers

Kevin Hilman (5):
  davinci: VPIF: fix module loading, init errors
  davinci: vpif_capture: remove hard-coded I2C adapter id
  davinci: vpif_capture: fix start/stop streaming locking
  dt-bindings: add TI VPIF documentation
  davinci: VPIF: add basic support for DT init

Markus Elfring (4):
  v4l2-async: Use kmalloc_array() in v4l2_async_notifier_unregister()
  v4l2-async: Delete an error message for a failed memory allocation in 
v4l2_async_notifier_unregister()
  pvrusb2-io: Use kmalloc_array() in pvr2_stream_buffer_count()
  pvrusb2-io: Add some spaces for better code readability

Pavel Machek (1):
  mark myself as mainainer for camera on N900

Randy Dunlap (1):
  media: fix dm1105.c build error

Santosh Kumar Singh (5):
  vim2m: Clean up file handle in open() error path.
  zoran: Clean up file handle in open() error path.
  tm6000: Clean up file handle in open() error path.
  ivtv: Clean up file handle in open() error path.
  pvrusb2: Clean up file handle in open() error path.

Shyam Saini (1):
  media: usb: cpia2: Use kmemdup instead of kmalloc and memcpy

Sudip Mukherjee (1):
  bt8xx: fix memory leak

 Documentation/devicetree/bindings/media/ti,da850-vpif.txt |  83 

 MAINTAINERS   |   8 +++
 drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c |   2 +-
 drivers/media/pci/bt8xx/dvb-bt8xx.c   |   1 +
 drivers/media/pci/dm1105/Kconfig  |   2 +-
 drivers/media/pci/ivtv/ivtv-alsa-pcm.c|   1 +
 drivers/media/pci/solo6x10/solo6x10-g723.c|   2 +-
 drivers/media/pci/zoran/zoran_driver.c|   1 +
 drivers/media/platform/davinci/vpif.c |  14 -
 drivers/media/platform/davinci/vpif_capture.c |  24 +++--
 drivers/media/platform/davinci/vpif_capture.h |   2 +-
 drivers/media/platform/davinci/vpif_display.c |   6 +++
 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c |   8 +--
 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c  |   8 +--
 drivers/media/platform/vim2m.c|   2 +
 drivers/media/usb/cpia2/cpia2_usb.c   |   4 +-
 drivers/media/usb/pvrusb2/pvrusb2-io.c| 123 
+-
 drivers/media/usb/pvrusb2/pvrusb2-v4l2.c  |   3 +-
 drivers/media/usb/tm6000/tm6000-video.c   |   5 +-
 drivers/media/v4l2-core/v4l2-async.c  |   7 +--
 include/media/davinci/vpif_types.h|   1 +
 21 files changed, 218 insertions(+), 89 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt
--
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 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

[Hans Verkuil]

On 01/03/2017 04:20 PM, Ramesh Shanmugasundaram wrote:
> Hi Laurent, Geert,
> 
> Thanks for the review comments.
> 
>>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote:
 Add binding documentation for Renesas R-Car Digital Radio Interface
 (DRIF) controller.

 Signed-off-by: Ramesh Shanmugasundaram
  ---
  .../devicetree/bindings/media/renesas,drif.txt | 202
>> ++
  1 file changed, 202 insertions(+)
  create mode 100644
 Documentation/devicetree/bindings/media/renesas,drif.txt

 diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
 b/Documentation/devicetree/bindings/media/renesas,drif.txt new file
 mode
 100644
 index 000..1f3feaf
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>>
 +Optional properties of an internal channel when:
 + - It is the only enabled channel of the bond (or)
 + - If it acts as primary among enabled bonds
 +
 +- renesas,syncmd   : sync mode
 +  0 (Frame start sync pulse mode. 1-bit width
>> pulse
 + indicates start of a frame)
 +  1 (L/R sync or I2S mode) (default)
 +- renesas,lsb-first: empty property indicates lsb bit is received
 first.
 +  When not defined msb bit is received first
 +(default)
 +- renesas,syncac-active: Indicates sync signal polarity, 0/1 for
>> low/high

Shouldn't this be 'renesas,sync-active' instead of syncac-active?

I'm not sure if syncac is intended or if it is a typo.

 +  respectively. The default is 1 (active high)
 +- renesas,dtdl : delay between sync signal and start of
>> reception.
 +  The possible values are represented in 0.5 clock
 +  cycle units and the range is 0 to 4. The default
 +  value is 2 (i.e.) 1 clock cycle delay.
 +- renesas,syncdl   : delay between end of reception and sync
>> signal
 edge.
 +  The possible values are represented in 0.5 clock
 +  cycle units and the range is 0 to 4 & 6. The
>> default
 +  value is 0 (i.e.) no delay.
>>>
>>> Most of these properties are pretty similar to the video bus
>>> properties defined at the endpoint level in
>>> Documentation/devicetree/bindings/media/video-interfaces.txt. I
>>> believe it would make sense to use OF graph and try to standardize
>>> these properties similarly.

Other than sync-active, is there really anything else that is similar? And
even the sync-active isn't a good fit since here there is only one sync
signal instead of two for video (h and vsync).

Regards,

Hans

>> Note that the last two properties match the those in
>> Documentation/devicetree/bindings/spi/sh-msiof.txt.
>> We may want to use one DRIF channel as a plain SPI slave with the
>> (modified) MSIOF driver in the future.
> 
> Should I leave it as it is or modify these as in video-interfaces.txt? Shall 
> we conclude on this please?
> 
> Thanks,
> Ramesh
> N�r��y���b�X��ǧv�^�)޺{.n�+{���bj)���w*jg����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a�����G���h��j:+v���w�٥
> 

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

[GIT PULL FOR v4.11] New st-delta driver

[Hans Verkuil]

See the v4 series for details:

https://www.spinics.net/lists/linux-media/msg108737.html

Regards,

Hans

The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a:

  [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git delta

for you to fetch changes up to e6f199d01e7b8bc4436738b6c666fda31b9f3340:

  st-delta: debug: trace stream/frame information & summary (2017-01-09 
14:16:45 +0100)


Hugues Fruchet (10):
  Documentation: DT: add bindings for ST DELTA
  ARM: dts: STiH410: add DELTA dt node
  ARM: multi_v7_defconfig: enable STMicroelectronics DELTA Support
  MAINTAINERS: add st-delta driver
  st-delta: STiH4xx multi-format video decoder v4l2 driver
  st-delta: add memory allocator helper functions
  st-delta: rpmsg ipc support
  st-delta: EOS (End Of Stream) support
  st-delta: add mjpeg support
  st-delta: debug: trace stream/frame information & summary

 Documentation/devicetree/bindings/media/st,st-delta.txt |   17 +
 MAINTAINERS |8 +
 arch/arm/boot/dts/stih410.dtsi  |   10 +
 arch/arm/configs/multi_v7_defconfig |1 +
 drivers/media/platform/Kconfig  |   27 +
 drivers/media/platform/Makefile |2 +
 drivers/media/platform/sti/delta/Makefile   |6 +
 drivers/media/platform/sti/delta/delta-cfg.h|   63 ++
 drivers/media/platform/sti/delta/delta-debug.c  |   72 ++
 drivers/media/platform/sti/delta/delta-debug.h  |   18 +
 drivers/media/platform/sti/delta/delta-ipc.c|  591 +
 drivers/media/platform/sti/delta/delta-ipc.h|   76 ++
 drivers/media/platform/sti/delta/delta-mem.c|   51 ++
 drivers/media/platform/sti/delta/delta-mem.h|   14 +
 drivers/media/platform/sti/delta/delta-mjpeg-dec.c  |  454 ++
 drivers/media/platform/sti/delta/delta-mjpeg-fw.h   |  221 +
 drivers/media/platform/sti/delta/delta-mjpeg-hdr.c  |  150 
 drivers/media/platform/sti/delta/delta-mjpeg.h  |   35 +
 drivers/media/platform/sti/delta/delta-v4l2.c   | 1977 
+++
 drivers/media/platform/sti/delta/delta.h|  566 +
 20 files changed, 4359 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,st-delta.txt
 create mode 100644 drivers/media/platform/sti/delta/Makefile
 create mode 100644 drivers/media/platform/sti/delta/delta-cfg.h
 create mode 100644 drivers/media/platform/sti/delta/delta-debug.c
 create mode 100644 drivers/media/platform/sti/delta/delta-debug.h
 create mode 100644 drivers/media/platform/sti/delta/delta-ipc.c
 create mode 100644 drivers/media/platform/sti/delta/delta-ipc.h
 create mode 100644 drivers/media/platform/sti/delta/delta-mem.c
 create mode 100644 drivers/media/platform/sti/delta/delta-mem.h
 create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg-dec.c
 create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg-fw.h
 create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg-hdr.c
 create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg.h
 create mode 100644 drivers/media/platform/sti/delta/delta-v4l2.c
 create mode 100644 drivers/media/platform/sti/delta/delta.h
--
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 00/10] Qualcomm 8x16 Camera Subsystem driver

[Todor Tomov]

Hi Hans,

On 01/09/2017 03:08 PM, Hans Verkuil wrote:
> Hi Todor,
> 
> What is the status of this patch series? There were comments for patch 1/10 
> and 8/10,
> and I haven't seen a v2 of this patch series.

And Happy new year!

I'm just starting today for the new year and this is the first thing to do - go 
over the comments received.
I'll reply for each of them.
Thank you for your notification and the also for the review done!

Best regards,
Todor

> 
> Regards,
> 
>   Hans
> 
> On 11/25/2016 03:56 PM, Todor Tomov wrote:
>> This patchset adds basic support for the Qualcomm Camera Subsystem found
>> on Qualcomm MSM8916 and APQ8016 processors.
>>
>> The driver implements V4L2, Media controller and V4L2 subdev interfaces.
>> Camera sensor using V4L2 subdev interface in the kernel is supported.
>>
>> The driver is implemented using as a reference the Qualcomm Camera
>> Subsystem driver for Android as found in Code Aurora [1].
>>
>> The driver supports raw dump of the input data to memory. ISP processing
>> is not supported.
>>
>> The driver is tested on Dragonboard 410C (APQ8016) with one and two
>> OV5645 camera sensors. media-ctl [2] and yavta [3] applications were
>> used for testing. Also Gstreamer 1.4.4 with v4l2src plugin is supported.
>>
>> More information is present in the document added by the third patch.
>>
>>
>> The patchset depends on:
>> v4l: Add packed Bayer raw12 pixel formats [4]
>> media: venus: enable building of Venus video codec driver [5]
>>
>>
>> V4L2 compliance test result:
>>
>> root@linaro-alip:~/v4l-utils/utils/v4l2-compliance# ./v4l2-compliance -s -d 
>> /dev/video0
>> v4l2-compliance SHA   : 6a760145f1a6809591a1cb17ee1b06913e4fddd1
>>
>> Driver Info:
>> Driver name   : qcom-camss
>> Card type : Qualcomm Camera Subsystem
>> Bus info  : platform:qcom-camss
>> Driver version: 4.9.0
>> Capabilities  : 0x8421
>> Video Capture
>> Streaming
>> Extended Pix Format
>> Device Capabilities
>> Device Caps   : 0x0421
>> Video Capture
>> Streaming
>> Extended Pix Format
>>
>> Compliance test for device /dev/video0 (not using libv4l2):
>>
>> Required ioctls:
>> test VIDIOC_QUERYCAP: OK
>>
>> Allow for multiple opens:
>> test second video open: OK
>> test VIDIOC_QUERYCAP: OK
>> test VIDIOC_G/S_PRIORITY: OK
>> test for unlimited opens: OK
>>
>> Debug ioctls:
>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>> test VIDIOC_LOG_STATUS: OK (Not Supported)
>>
>> Input ioctls:
>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>> test VIDIOC_G/S/ENUMINPUT: OK
>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>> Inputs: 1 Audio Inputs: 0 Tuners: 0
>>
>> Output ioctls:
>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>
>> Input/Output configuration ioctls:
>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>
>> Test input 0:
>>
>> Control ioctls:
>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
>> test VIDIOC_QUERYCTRL: OK (Not Supported)
>> test VIDIOC_G/S_CTRL: OK (Not Supported)
>> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>> Standard Controls: 0 Private Controls: 0
>>
>> Format ioctls:
>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>> test VIDIOC_G/S_PARM: OK (Not Supported)
>> test VIDIOC_G_FBUF: OK (Not Supported)
>> test VIDIOC_G_FMT: OK
>> test VIDIOC_TRY_FMT: OK
>> test VIDIOC_S_FMT: OK
>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
>> test Cropping: OK (Not Supported)
>> test Composing: OK (Not Supported)
>> test Scaling: OK (Not Supported)
>>
>> Codec ioctls:
>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>>

Re: [PATCH 00/10] Qualcomm 8x16 Camera Subsystem driver

[Hans Verkuil]

Hi Todor,

What is the status of this patch series? There were comments for patch 1/10 and 
8/10,
and I haven't seen a v2 of this patch series.

Regards,

Hans

On 11/25/2016 03:56 PM, Todor Tomov wrote:
> This patchset adds basic support for the Qualcomm Camera Subsystem found
> on Qualcomm MSM8916 and APQ8016 processors.
> 
> The driver implements V4L2, Media controller and V4L2 subdev interfaces.
> Camera sensor using V4L2 subdev interface in the kernel is supported.
> 
> The driver is implemented using as a reference the Qualcomm Camera
> Subsystem driver for Android as found in Code Aurora [1].
> 
> The driver supports raw dump of the input data to memory. ISP processing
> is not supported.
> 
> The driver is tested on Dragonboard 410C (APQ8016) with one and two
> OV5645 camera sensors. media-ctl [2] and yavta [3] applications were
> used for testing. Also Gstreamer 1.4.4 with v4l2src plugin is supported.
> 
> More information is present in the document added by the third patch.
> 
> 
> The patchset depends on:
> v4l: Add packed Bayer raw12 pixel formats [4]
> media: venus: enable building of Venus video codec driver [5]
> 
> 
> V4L2 compliance test result:
> 
> root@linaro-alip:~/v4l-utils/utils/v4l2-compliance# ./v4l2-compliance -s -d 
> /dev/video0
> v4l2-compliance SHA   : 6a760145f1a6809591a1cb17ee1b06913e4fddd1
> 
> Driver Info:
> Driver name   : qcom-camss
> Card type : Qualcomm Camera Subsystem
> Bus info  : platform:qcom-camss
> Driver version: 4.9.0
> Capabilities  : 0x8421
> Video Capture
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps   : 0x0421
> Video Capture
> Streaming
> Extended Pix Format
> 
> Compliance test for device /dev/video0 (not using libv4l2):
> 
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> test for unlimited opens: OK
> 
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK (Not Supported)
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Test input 0:
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> test VIDIOC_QUERYCTRL: OK (Not Supported)
> test VIDIOC_G/S_CTRL: OK (Not Supported)
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 0 Private Controls: 0
> 
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK (Not Supported)
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> test VIDIOC_TRY_FMT: OK
> test VIDIOC_S_FMT: OK
> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> test Cropping: OK (Not Supported)
> test Composing: OK (Not Supported)
> test Scaling: OK (Not Supported)
> 
> Codec ioctls:
> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> 
> Buffer ioctls:
> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> test VIDIOC_EXPBUF: OK (Not Supported)
> 
> Test input 0:
> 
> Streaming ioctls:
> test read/write: OK (Not Supported)
> test MMAP: OK 
> test USERPTR: OK (Not Supported)
> test DMABUF: OK (Not Supported)
> 
> 
> Total: 47, Succeeded: 

Re: [PATCH v4 8/9] media: venus: hfi: add Venus HFI files

[Hans Verkuil]

On 12/05/2016 01:20 PM, Stanimir Varbanov wrote:
> Hi Hans,
> 
> On 12/05/2016 02:05 PM, Hans Verkuil wrote:
>> On 12/01/2016 10:03 AM, Stanimir Varbanov wrote:
>>> Here is the implementation of Venus video accelerator low-level
>>> functionality. It contanins code which setup the registers and
>>> startup uthe processor, allocate and manipulates with the shared
>>> memory used for sending commands and receiving messages.
>>>
>>> Signed-off-by: Stanimir Varbanov 
>>> ---
>>>  drivers/media/platform/qcom/venus/hfi_venus.c| 1508 
>>> ++
>>>  drivers/media/platform/qcom/venus/hfi_venus.h|   23 +
>>>  drivers/media/platform/qcom/venus/hfi_venus_io.h |   98 ++
>>>  3 files changed, 1629 insertions(+)
>>>  create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.c
>>>  create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.h
>>>  create mode 100644 drivers/media/platform/qcom/venus/hfi_venus_io.h
>>>
>>> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
>>> b/drivers/media/platform/qcom/venus/hfi_venus.c
>>> new file mode 100644
>>> index ..f004a9a80d85
>>> --- /dev/null
>>> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
>>> @@ -0,0 +1,1508 @@
>>> +static int venus_tzbsp_set_video_state(enum tzbsp_video_state state)
>>> +{
>>> +   return qcom_scm_video_set_state(state, 0);
>>
>> This functions doesn't seem to exist. Is there a prerequisite patch series 
>> that
>> introduces this function?
> 
> yes, the patchset [1] is under review.
> 

What is the status of this patchset?

Regards,

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

Re: [PATCH v2 7/7] uapi: export all headers under uapi directories

[Christoph Hellwig]

On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
> 
> In fact, all headers under uapi directories should be exported, thus it's
> useless to have an exhaustive list.
> 
> After this patch, the following files, which were not exported, are now
> exported (with make headers_install_all):

... snip ...

> linux/genwqe/.install
> linux/genwqe/..install.cmd
> linux/cifs/.install
> linux/cifs/..install.cmd

I'm pretty sure these should not be exported!
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR v4.11] More fixes/enhancements

[Hans Verkuil]

The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a:

  [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.11b

for you to fetch changes up to 62c53755afc004b9979a0790e762f711f12ceb03:

  davinci: VPIF: add basic support for DT init (2017-01-09 13:19:03 +0100)


Andrzej Hajda (1):
  v4l: s5c73m3: fix negation operator

Jean-Christophe Trotin (1):
  v4l2-common: fix aligned value calculation

Kees Cook (2):
  mtk-vcodec: use designated initializers
  solo6x10: use designated initializers

Kevin Hilman (5):
  davinci: VPIF: fix module loading, init errors
  davinci: vpif_capture: remove hard-coded I2C adapter id
  davinci: vpif_capture: fix start/stop streaming locking
  dt-bindings: add TI VPIF documentation
  davinci: VPIF: add basic support for DT init

Markus Elfring (2):
  v4l2-async: Use kmalloc_array() in v4l2_async_notifier_unregister()
  v4l2-async: Delete an error message for a failed memory allocation in 
v4l2_async_notifier_unregister()

Pavel Machek (1):
  mark myself as mainainer for camera on N900

Randy Dunlap (1):
  media: fix dm1105.c build error

Santosh Kumar Singh (5):
  vim2m: Clean up file handle in open() error path.
  zoran: Clean up file handle in open() error path.
  tm6000: Clean up file handle in open() error path.
  ivtv: Clean up file handle in open() error path.
  pvrusb2: Clean up file handle in open() error path.

Shyam Saini (1):
  media: usb: cpia2: Use kmemdup instead of kmalloc and memcpy

Sudip Mukherjee (1):
  bt8xx: fix memory leak

 Documentation/devicetree/bindings/media/ti,da850-vpif.txt | 83 
+++
 MAINTAINERS   |  8 +
 drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c |  2 +-
 drivers/media/pci/bt8xx/dvb-bt8xx.c   |  1 +
 drivers/media/pci/dm1105/Kconfig  |  2 +-
 drivers/media/pci/ivtv/ivtv-alsa-pcm.c|  1 +
 drivers/media/pci/solo6x10/solo6x10-g723.c|  2 +-
 drivers/media/pci/zoran/zoran_driver.c|  1 +
 drivers/media/platform/davinci/vpif.c | 14 +++-
 drivers/media/platform/davinci/vpif_capture.c | 24 ++---
 drivers/media/platform/davinci/vpif_capture.h |  2 +-
 drivers/media/platform/davinci/vpif_display.c |  6 
 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c |  8 ++---
 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c  |  8 ++---
 drivers/media/platform/vim2m.c|  2 ++
 drivers/media/usb/cpia2/cpia2_usb.c   |  4 +--
 drivers/media/usb/pvrusb2/pvrusb2-v4l2.c  |  3 +-
 drivers/media/usb/tm6000/tm6000-video.c   |  5 ++-
 drivers/media/v4l2-core/v4l2-async.c  |  7 +---
 drivers/media/v4l2-core/v4l2-common.c |  2 +-
 include/media/davinci/vpif_types.h|  1 +
 21 files changed, 157 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

[Sean Young]

On Mon, Jan 09, 2017 at 11:13:21AM +0800, Sean Wang wrote:
> I had another question. I found multiple and same IR messages being
> received when using SONY remote controller. Should driver needs to
> report each message or only one of these to the upper layer ?

In general the driver shouldn't try to change any IR message, this should
be done in rc-core if necessary.

rc-core should handle this correctly. If the same key is received twice
within IR_KEYPRESS_TIMEOUT (250ms) then it not reported to the input
layer.

Thanks
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

Re: [PATCH] [media] cx231xx: Initial support for Evromedia USB Full Hybrid Full HD

[Hans Verkuil]

On 01/01/2017 06:28 PM, Oleh Kravchenko wrote:
> Add initial support for the Evromedia USB Full Hybrid Full HD
> with USB ID 1b80:d3b2.
> 
> Status:
> - DVB-T2 works fine;
> - Analog not implemented.
> 
> Signed-off-by: Oleh Kravchenko 
> ---
>  drivers/media/usb/cx231xx/Kconfig |  1 +
>  drivers/media/usb/cx231xx/cx231xx-cards.c | 16 +++
>  drivers/media/usb/cx231xx/cx231xx-dvb.c   | 74 
> +++
>  drivers/media/usb/cx231xx/cx231xx-i2c.c   | 37 
>  drivers/media/usb/cx231xx/cx231xx.h   |  1 +
>  5 files changed, 129 insertions(+)
> 
> diff --git a/drivers/media/usb/cx231xx/Kconfig 
> b/drivers/media/usb/cx231xx/Kconfig
> index 0cced3e..58de80b 100644
> --- a/drivers/media/usb/cx231xx/Kconfig
> +++ b/drivers/media/usb/cx231xx/Kconfig
> @@ -50,6 +50,7 @@ config VIDEO_CX231XX_DVB
>   select DVB_LGDT3306A if MEDIA_SUBDRV_AUTOSELECT
>   select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
>   select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
> + select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
>   select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
>  
>   ---help---
> diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
> b/drivers/media/usb/cx231xx/cx231xx-cards.c
> index 36bc254..380aff7 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-cards.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
> @@ -841,6 +841,20 @@ struct cx231xx_board cx231xx_boards[] = {
>   .gpio = NULL,
>   } },
>   },
> + [CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD] = {
> + .name = "Evromedia USB Full Hybrid Full HD",
> + .tuner_type = TUNER_ABSENT,
> + .has_dvb = 1,
> + .demod_i2c_master = I2C_1_MUX_3,
> + .demod_addr = 0xc8 >> 1,
> + .tuner_i2c_master = I2C_2,
> + .tuner_addr = 0xc0 >> 1,
> + .input = {{
> + .type = CX231XX_VMUX_TELEVISION,
> + .vmux = 0,
> + .amux = CX231XX_AMUX_VIDEO,
> + } },
> + },
>  };
>  const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
>  
> @@ -908,6 +922,8 @@ struct usb_device_id cx231xx_id_table[] = {
>.driver_info = CX231XX_BOARD_OTG102},
>   {USB_DEVICE(USB_VID_TERRATEC, 0x00a6),
>.driver_info = CX231XX_BOARD_TERRATEC_GRABBY},
> + {USB_DEVICE(0x1b80, 0xd3b2),
> + .driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
>   {},
>  };
>  
> diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
> b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> index 1417515..131c1e2 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> @@ -33,6 +33,7 @@
>  #include "s5h1411.h"
>  #include "lgdt3305.h"
>  #include "si2165.h"
> +#include "si2168.h"
>  #include "mb86a20s.h"
>  #include "si2157.h"
>  #include "lgdt3306a.h"
> @@ -949,6 +950,79 @@ static int dvb_init(struct cx231xx *dev)
>  _tda18271_config);
>   break;
>  
> + case CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD:
> + {
> + struct si2157_config si2157_config;
> + struct si2168_config si2168_config;
> + struct i2c_board_info info;

Zero these explicitly:

struct si2157_config si2157_config = { };
struct si2168_config si2168_config = { };
struct i2c_board_info info = { };

And drop the corresponding memsets below.

> + struct i2c_client *client;
> + struct i2c_adapter *adapter;
> +
> + /* attach demodulator chip */
> + memset(_config, 0, sizeof(si2168_config));
> + si2168_config.ts_mode = SI2168_TS_SERIAL; /* from *.inf file */
> + si2168_config.fe = >dvb->frontend;
> + si2168_config.i2c_adapter = 
> + si2168_config.ts_clock_inv = true;
> +
> + memset(, 0, sizeof(info));
> + strlcpy(info.type, "si2168", I2C_NAME_SIZE);

use sizeof(info.type).

> + info.addr = dev->board.demod_addr;
> + info.platform_data = _config;
> +
> + request_module(info.type);
> + client = i2c_new_device(demod_i2c, );
> +
> + if (client == NULL || client->dev.driver == NULL || 
> dev->dvb->frontend == NULL) {
> + dev_err(dev->dev, "Failed to attach Si2168 front 
> end\n");
> + result = -EINVAL;
> + goto out_free;
> + }
> +
> + if (!try_module_get(client->dev.driver->owner)) {
> + i2c_unregister_device(client);
> + result = -ENODEV;
> + goto out_free;
> + }
> +
> + dvb->i2c_client_demod = client;
> + dev->dvb->frontend->ops.i2c_gate_ctrl = NULL;
> + dvb->frontend->callback = cx231xx_tuner_callback;
> +
> +  

Re: [PATCH] [media] atmel-isc: add the isc pipeline function

[Hans Verkuil]

On 12/23/2016 10:24 AM, Songjun Wu wrote:
> Image Sensor Controller has an internal image processor.
> It can convert raw format to the other formats, like
> RGB565, YUV420P. A module parameter 'sensor_preferred'
> is used to enable or disable the pipeline function.
> Some v4l2 controls are added to tuning the image when
> the pipeline function is enabled.
> 
> Signed-off-by: Songjun Wu 
> ---
> 
>  drivers/media/platform/atmel/atmel-isc-regs.h | 102 -
>  drivers/media/platform/atmel/atmel-isc.c  | 629 
> +-
>  2 files changed, 623 insertions(+), 108 deletions(-)
> 
> diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h 
> b/drivers/media/platform/atmel/atmel-isc-regs.h
> index 00c449717cde..6936ac467609 100644
> --- a/drivers/media/platform/atmel/atmel-isc-regs.h
> +++ b/drivers/media/platform/atmel/atmel-isc-regs.h
> @@ -65,6 +65,7 @@
>  #define ISC_INTSR   0x0034
>  
>  #define ISC_INT_DDONEBIT(8)
> +#define ISC_INT_HISDONE  BIT(12)
>  
>  /* ISC White Balance Control Register */
>  #define ISC_WB_CTRL 0x0058
> @@ -72,30 +73,98 @@
>  /* ISC White Balance Configuration Register */
>  #define ISC_WB_CFG  0x005c
>  
> +/* ISC White Balance Offset for R, GR Register */
> +#define ISC_WB_O_RGR 0x0060
> +
> +/* ISC White Balance Offset for B, GB Register */
> +#define ISC_WB_O_BGR 0x0064
> +
> +/* ISC White Balance Gain for R, GR Register */
> +#define ISC_WB_G_RGR 0x0068
> +
> +/* ISC White Balance Gain for B, GB Register */
> +#define ISC_WB_G_BGR 0x006c
> +
>  /* ISC Color Filter Array Control Register */
>  #define ISC_CFA_CTRL0x0070
>  
>  /* ISC Color Filter Array Configuration Register */
>  #define ISC_CFA_CFG 0x0074
> +#define ISC_CFA_CFG_EITPOL   BIT(4)
>  
>  #define ISC_BAY_CFG_GRGR 0x0
>  #define ISC_BAY_CFG_RGRG 0x1
>  #define ISC_BAY_CFG_GBGB 0x2
>  #define ISC_BAY_CFG_BGBG 0x3
> -#define ISC_BAY_CFG_MASK GENMASK(1, 0)
>  
>  /* ISC Color Correction Control Register */
>  #define ISC_CC_CTRL 0x0078
>  
> +/* ISC Color Correction RR RG Register */
> +#define ISC_CC_RR_RG 0x007c
> +
> +/* ISC Color Correction RB OR Register */
> +#define ISC_CC_RB_OR 0x0080
> +
> +/* ISC Color Correction GR GG Register */
> +#define ISC_CC_GR_GG 0x0084
> +
> +/* ISC Color Correction GB OG Register */
> +#define ISC_CC_GB_OG 0x0088
> +
> +/* ISC Color Correction BR BG Register */
> +#define ISC_CC_BR_BG 0x008c
> +
> +/* ISC Color Correction BB OB Register */
> +#define ISC_CC_BB_OB 0x0090
> +
>  /* ISC Gamma Correction Control Register */
>  #define ISC_GAM_CTRL0x0094
>  
> +/* ISC_Gamma Correction Blue Entry Register */
> +#define ISC_GAM_BENTRY   0x0098
> +
> +/* ISC_Gamma Correction Green Entry Register */
> +#define ISC_GAM_GENTRY   0x0198
> +
> +/* ISC_Gamma Correction Green Entry Register */
> +#define ISC_GAM_RENTRY   0x0298
> +
>  /* Color Space Conversion Control Register */
>  #define ISC_CSC_CTRL0x0398
>  
> +/* Color Space Conversion YR YG Register */
> +#define ISC_CSC_YR_YG0x039c
> +
> +/* Color Space Conversion YB OY Register */
> +#define ISC_CSC_YB_OY0x03a0
> +
> +/* Color Space Conversion CBR CBG Register */
> +#define ISC_CSC_CBR_CBG  0x03a4
> +
> +/* Color Space Conversion CBB OCB Register */
> +#define ISC_CSC_CBB_OCB  0x03a8
> +
> +/* Color Space Conversion CRR CRG Register */
> +#define ISC_CSC_CRR_CRG  0x03ac
> +
> +/* Color Space Conversion CRB OCR Register */
> +#define ISC_CSC_CRB_OCR  0x03b0
> +
>  /* Contrast And Brightness Control Register */
>  #define ISC_CBC_CTRL0x03b4
>  
> +/* Contrast And Brightness Configuration Register */
> +#define ISC_CBC_CFG  0x03b8
> +
> +/* Brightness Register */
> +#define ISC_CBC_BRIGHT   0x03bc
> +#define ISC_CBC_BRIGHT_MASK  GENMASK(10, 0)
> +
> +/* Contrast Register */
> +#define ISC_CBC_CONTRAST 0x03c0
> +#define ISC_CBC_CONTRAST_MASKGENMASK(11, 0)
> +
>  /* Subsampling 4:4:4 to 4:2:2 Control Register */
>  #define ISC_SUB422_CTRL 0x03c4
>  
> @@ -120,6 +189,27 @@
>  #define ISC_RLP_CFG_MODE_YYCC_LIMITED   0xc
>  #define ISC_RLP_CFG_MODE_MASK   GENMASK(3, 0)
>  
> +/* Histogram Control Register */
> +#define ISC_HIS_CTRL 0x03d4
> +
> +#define ISC_HIS_CTRL_EN  BIT(0)
> +#define ISC_HIS_CTRL_DIS 0x0
> +
> +/* Histogram Configuration Register */
> +#define ISC_HIS_CFG  0x03d8
> +
> +#define ISC_HIS_CFG_MODE_GR  0x0
> +#define ISC_HIS_CFG_MODE_R   0x1
> +#define ISC_HIS_CFG_MODE_GB  0x2
> +#define ISC_HIS_CFG_MODE_B   0x3
> +#define ISC_HIS_CFG_MODE_Y   0x4
> +#define ISC_HIS_CFG_MODE_RAW 0x5
> +#define ISC_HIS_CFG_MODE_YCCIR6560x6
> +
> +#define ISC_HIS_CFG_BAYSEL_SHIFT 4
> +
> +#define ISC_HIS_CFG_RAR  

Re: [PATCH v2 1/7] arm: put types.h in uapi

[Russell King - ARM Linux]

On Mon, Jan 09, 2017 at 12:33:02PM +0100, Arnd Bergmann wrote:
> On Friday, January 6, 2017 10:43:53 AM CET Nicolas Dichtel wrote:
> > 
> > diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> > index a53cdb8f068c..c48fee3d7b3b 100644
> > --- a/arch/arm/include/asm/types.h
> > +++ b/arch/arm/include/asm/types.h
> > @@ -1,40 +1,6 @@
> >  #ifndef _ASM_TYPES_H
> >  #define _ASM_TYPES_H
> >  
> > -#include 
> ...
> > -#define __UINTPTR_TYPE__   unsigned long
> > -#endif
> > +#include 
> >  
> >  #endif /* _ASM_TYPES_H */
> > 
> 
> Moving the file is correct as far as I can tell, but the extra
> #include is not necessary here, as the kernel will automatically
> search both arch/arm/include/ and arch/arm/include/uapi/.

Indeed, I'd like to see the include/asm file gone.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 7/7] uapi: export all headers under uapi directories

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
> diff --git a/arch/arm/include/uapi/asm/Kbuild 
> b/arch/arm/include/uapi/asm/Kbuild
> index 46a76cd6acb6..607f702c2d62 100644
> --- a/arch/arm/include/uapi/asm/Kbuild
> +++ b/arch/arm/include/uapi/asm/Kbuild
> @@ -1,23 +1,6 @@
>  # UAPI Header export list
>  include include/uapi/asm-generic/Kbuild.asm
>  
> -header-y += auxvec.h
> -header-y += byteorder.h
> -header-y += fcntl.h
> -header-y += hwcap.h
> -header-y += ioctls.h
> -header-y += kvm_para.h
> -header-y += mman.h
> -header-y += perf_regs.h
> -header-y += posix_types.h
> -header-y += ptrace.h
> -header-y += setup.h
> -header-y += sigcontext.h
> -header-y += signal.h
> -header-y += stat.h
> -header-y += statfs.h
> -header-y += swab.h
> -header-y += unistd.h
>  genhdr-y += unistd-common.h
>  genhdr-y += unistd-oabi.h
>  genhdr-y += unistd-eabi.h

Acked-by: Russell King 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] [media] em28xx: support for Hauppauge WinTV-dualHD 01595 ATSC/QAM

[Hans Verkuil]

On 12/18/2016 03:55 AM, Kevin Cheng wrote:
> Hauppauge WinTV-dualHD model 01595 is a USB 2.0 dual ATSC/QAM tuner with
> the following components:
> 
> USB bridge: Empia em28274
> Demodulator: 2x LG LGDT3306a at addresses 0xb2 and 0x1c
> Tuner: 2x Silicon Labs si2157 at addresses 0xc0 and 0xc4
> 
> This patch enables only the first tuner.
> 
> Signed-off-by: Kevin Cheng 
> ---
>  drivers/media/usb/em28xx/em28xx-cards.c | 19 
>  drivers/media/usb/em28xx/em28xx-dvb.c   | 78 
> +
>  drivers/media/usb/em28xx/em28xx.h   |  1 +
>  3 files changed, 98 insertions(+)
> 
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index 23c6749..5f90d08 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -509,6 +509,7 @@ static struct em28xx_reg_seq plex_px_bcud[] = {
>  
>  /*
>   * 2040:0265 Hauppauge WinTV-dualHD DVB
> + * 2040:026d Hauppauge WinTV-dualHD ATSC/QAM
>   * reg 0x80/0x84:
>   * GPIO_0: Yellow LED tuner 1, 0=on, 1=off
>   * GPIO_1: Green LED tuner 1, 0=on, 1=off
> @@ -2389,6 +2390,21 @@ struct em28xx_board em28xx_boards[] = {
>   .ir_codes  = RC_MAP_HAUPPAUGE,
>   .leds  = hauppauge_dualhd_leds,
>   },
> + /*
> +  * 2040:026d Hauppauge WinTV-dualHD (model 01595 - ATSC/QAM).
> +  * Empia EM28274, 2x LG LGDT3306A, 2x Silicon Labs Si2157
> +  */
> + [EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595] = {
> + .name  = "Hauppauge WinTV-dualHD 01595 ATSC/QAM",
> + .def_i2c_bus   = 1,
> + .i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE |
> +  EM28XX_I2C_FREQ_400_KHZ,
> + .tuner_type= TUNER_ABSENT,
> + .tuner_gpio= hauppauge_dualhd_dvb,
> + .has_dvb   = 1,
> + .ir_codes  = RC_MAP_HAUPPAUGE,
> + .leds  = hauppauge_dualhd_leds,
> + },
>  };
>  EXPORT_SYMBOL_GPL(em28xx_boards);
>  
> @@ -2514,6 +2530,8 @@ struct usb_device_id em28xx_id_table[] = {
>   .driver_info = EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850 },
>   { USB_DEVICE(0x2040, 0x0265),
>   .driver_info = EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB 
> },
> + { USB_DEVICE(0x2040, 0x026d),
> + .driver_info = 
> EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 },
>   { USB_DEVICE(0x0438, 0xb002),
>   .driver_info = EM2880_BOARD_AMD_ATI_TV_WONDER_HD_600 },
>   { USB_DEVICE(0x2001, 0xf112),
> @@ -2945,6 +2963,7 @@ static void em28xx_card_setup(struct em28xx *dev)
>   case EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950:
>   case EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C:
>   case EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB:
> + case EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595:
>   {
>   struct tveeprom tv;
>  
> diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
> b/drivers/media/usb/em28xx/em28xx-dvb.c
> index 75a75da..35c186e 100644
> --- a/drivers/media/usb/em28xx/em28xx-dvb.c
> +++ b/drivers/media/usb/em28xx/em28xx-dvb.c
> @@ -37,6 +37,7 @@
>  
>  #include "lgdt330x.h"
>  #include "lgdt3305.h"
> +#include "lgdt3306a.h"
>  #include "zl10353.h"
>  #include "s5h1409.h"
>  #include "mt2060.h"
> @@ -920,6 +921,17 @@ static struct tda18271_config pinnacle_80e_dvb_config = {
>   .role= TDA18271_MASTER,
>  };
>  
> +static struct lgdt3306a_config hauppauge_01595_lgdt3306a_config = {
> + .qam_if_khz = 4000,
> + .vsb_if_khz = 3250,
> + .spectral_inversion = 0,
> + .deny_i2c_rptr  = 0,
> + .mpeg_mode  = LGDT3306A_MPEG_SERIAL,
> + .tpclk_edge = LGDT3306A_TPCLK_RISING_EDGE,
> + .tpvalid_polarity   = LGDT3306A_TP_VALID_HIGH,
> + .xtalMHz= 25,
> +};
> +
>  /* -- */
>  
>  static int em28xx_attach_xc3028(u8 addr, struct em28xx *dev)
> @@ -1950,6 +1962,72 @@ static int em28xx_dvb_init(struct em28xx *dev)
>  
>   }
>   break;
> + case EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595:
> + {
> + struct i2c_adapter *adapter;
> + struct i2c_client *client;
> + struct i2c_board_info info;

Init to zero to avoid the memset below:

struct i2c_board_info info = { };

> + struct lgdt3306a_config lgdt3306a_config;
> + struct si2157_config si2157_config;
> +
> + /* attach demod */
> + memcpy(_config,
> + _01595_lgdt3306a_config,
> + sizeof(struct lgdt3306a_config));

Use this instead of the memcpy:

lgdt3306a_config = hauppauge_01595_lgdt3306a_config;

> + 

Re: [PATCH v2 1/2] [media] lgdt3306a: support i2c mux for use by em28xx

[Hans Verkuil]

On 12/18/2016 03:55 AM, Kevin Cheng wrote:
> Adds an i2c mux to the lgdt3306a demodulator.  This was done to support
> the Hauppauge WinTV-dualHD 01595 USB TV tuner (em28xx), which utilizes two
> si2157 tuners behind gate control.
> 
> Signed-off-by: Kevin Cheng 
> ---
>  drivers/media/dvb-frontends/Kconfig |   2 +-
>  drivers/media/dvb-frontends/lgdt3306a.c | 108 
> 
>  drivers/media/dvb-frontends/lgdt3306a.h |   4 ++
>  3 files changed, 113 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/dvb-frontends/Kconfig 
> b/drivers/media/dvb-frontends/Kconfig
> index c841fa1..16f9afa 100644
> --- a/drivers/media/dvb-frontends/Kconfig
> +++ b/drivers/media/dvb-frontends/Kconfig
> @@ -619,7 +619,7 @@ config DVB_LGDT3305
>  
>  config DVB_LGDT3306A
>   tristate "LG Electronics LGDT3306A based"
> - depends on DVB_CORE && I2C
> + depends on DVB_CORE && I2C && I2C_MUX
>   default m if !MEDIA_SUBDRV_AUTOSELECT
>   help
> An ATSC 8VSB and QAM-B 64/256 demodulator module. Say Y when you want
> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
> b/drivers/media/dvb-frontends/lgdt3306a.c
> index 19dca46..b191e01 100644
> --- a/drivers/media/dvb-frontends/lgdt3306a.c
> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include "dvb_math.h"
>  #include "lgdt3306a.h"
> +#include 
>  
>  
>  static int debug;
> @@ -65,6 +66,8 @@ struct lgdt3306a_state {
>   enum fe_modulation current_modulation;
>   u32 current_frequency;
>   u32 snr;
> +
> + struct i2c_mux_core *muxc;
>  };
>  
>  /*
> @@ -2131,6 +2134,111 @@ static const struct dvb_frontend_ops lgdt3306a_ops = {
>   .search   = lgdt3306a_search,
>  };
>  
> +static int lgdt3306a_select(struct i2c_mux_core *muxc, u32 chan)
> +{
> + struct i2c_client *client = i2c_mux_priv(muxc);
> + struct lgdt3306a_state *state = i2c_get_clientdata(client);
> +
> + return lgdt3306a_i2c_gate_ctrl(>frontend, 1);
> +}
> +
> +static int lgdt3306a_deselect(struct i2c_mux_core *muxc, u32 chan)
> +{
> + struct i2c_client *client = i2c_mux_priv(muxc);
> + struct lgdt3306a_state *state = i2c_get_clientdata(client);
> +
> + return lgdt3306a_i2c_gate_ctrl(>frontend, 0);
> +}
> +
> +static int lgdt3306a_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct lgdt3306a_config *config = client->dev.platform_data;

You assign config here...

> + struct lgdt3306a_state *state;
> + struct dvb_frontend *fe;
> + int ret;
> +
> + config = kzalloc(sizeof(struct lgdt3306a_config), GFP_KERNEL);

...and then overwrite it here.

Don't assign config the first time, it's confusing.

> + if (config == NULL) {
> + ret = -ENOMEM;
> + goto fail;
> + }
> +
> + memcpy(config, client->dev.platform_data,
> + sizeof(struct lgdt3306a_config));
> +
> + config->i2c_addr = client->addr;
> + fe = lgdt3306a_attach(config, client->adapter);
> + if (fe == NULL) {
> + ret = -ENODEV;
> + goto err_fe;
> + }
> +
> + i2c_set_clientdata(client, fe->demodulator_priv);
> + state = fe->demodulator_priv;
> +
> + /* create mux i2c adapter for tuner */
> + state->muxc = i2c_mux_alloc(client->adapter, >dev,
> +   1, 0, I2C_MUX_LOCKED,
> +   lgdt3306a_select, lgdt3306a_deselect);
> + if (!state->muxc) {
> + ret = -ENOMEM;
> + goto err_kfree;
> + }
> + state->muxc->priv = client;
> + ret = i2c_mux_add_adapter(state->muxc, 0, 0, 0);
> + if (ret)
> + goto err_kfree;
> +
> + /* create dvb_frontend */
> + fe->ops.i2c_gate_ctrl = NULL;
> + *config->i2c_adapter = state->muxc->adapter[0];
> + *config->fe = fe;
> +
> + return 0;
> +
> +err_kfree:
> + kfree(state);
> +err_fe:
> + kfree(config);
> +fail:
> + dev_dbg(>dev, "failed=%d\n", ret);
> + return ret;
> +}
> +
> +static int lgdt3306a_remove(struct i2c_client *client)
> +{
> + struct lgdt3306a_state *state = i2c_get_clientdata(client);
> +
> + i2c_mux_del_adapters(state->muxc);
> +
> + state->frontend.ops.release = NULL;
> + state->frontend.demodulator_priv = NULL;
> +
> + kfree(state->cfg);
> + kfree(state);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id lgdt3306a_id_table[] = {
> + {"lgdt3306a", 0},
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, lgdt3306a_id_table);
> +
> +static struct i2c_driver lgdt3306a_driver = {
> + .driver = {
> + .name= "lgdt3306a",
> + .suppress_bind_attrs = true,
> + },
> + .probe  = lgdt3306a_probe,
> + .remove = lgdt3306a_remove,
> + .id_table   = lgdt3306a_id_table,
> +};
> +
> +module_i2c_driver(lgdt3306a_driver);
> +
>  MODULE_DESCRIPTION("LG 

Re: [PATCH v2 1/7] arm: put types.h in uapi

[Arnd Bergmann]

On Friday, January 6, 2017 10:43:53 AM CET Nicolas Dichtel wrote:
> 
> diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> index a53cdb8f068c..c48fee3d7b3b 100644
> --- a/arch/arm/include/asm/types.h
> +++ b/arch/arm/include/asm/types.h
> @@ -1,40 +1,6 @@
>  #ifndef _ASM_TYPES_H
>  #define _ASM_TYPES_H
>  
> -#include 
...
> -#define __UINTPTR_TYPE__   unsigned long
> -#endif
> +#include 
>  
>  #endif /* _ASM_TYPES_H */
> 

Moving the file is correct as far as I can tell, but the extra
#include is not necessary here, as the kernel will automatically
search both arch/arm/include/ and arch/arm/include/uapi/.

The same applies to patches 2 and 4.

Arnd
--
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 3/7] nios2: put setup.h in uapi

[Arnd Bergmann]

On Friday, January 6, 2017 10:43:55 AM CET Nicolas Dichtel wrote:

> diff --git a/arch/nios2/include/uapi/asm/setup.h 
> b/arch/nios2/include/uapi/asm/setup.h
> new file mode 100644
> index ..8d8285997ba8
> --- /dev/null
> +++ b/arch/nios2/include/uapi/asm/setup.h
> @@ -0,0 +1,6 @@
> +#ifndef _UAPI_ASM_NIOS2_SETUP_H
> +#define _UAPI_ASM_NIOS2_SETUP_H
> +
> +#include 
> +
> +#endif /* _UAPI_ASM_NIOS2_SETUP_H */
> 

This one is only a redirect to an asm-generic header, so it can be
removed completely and replaced with a line in the 
arch/nios2/include/uapi/asm/ file:

generic-y += setup.h

Arnd
--
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 0/7] uapi: export all headers under uapi directories

[Arnd Bergmann]

On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote:
> Here is the v2 of this series. The first 5 patches are just cleanup: some
> exported headers were still under a non-uapi directory.

Since this is meant as a cleanup, I commented on this to point out a cleaner
way to do the same.

> The patch 6 was spotted by code review: there is no in-tree user of this
> functionality.
> The last patch remove the use of header-y. Now all files under an uapi
> directory are exported.

Very nice!

> asm is a bit special, most of architectures export asm//include/uapi/asm
> only, but there is two exceptions:
>  - cris which exports arch/cris/include/uapi/arch-v[10|32];

This is interesting, though not your problem. Maybe someone who understands
cris better can comment on this: How is the decision made about which of
the arch/user.h headers gets used? I couldn't find that in the sources,
but it appears to be based on kernel compile-time settings, which is
wrong for user space header files that should be independent of the kernel
config.

>  - tile which exports arch/tile/include/uapi/arch.
> Because I don't know if the output of 'make headers_install_all' can be 
> changed,
> I introduce subdir-y in Kbuild file. The headers_install_all target copies all
> asm//include/uapi/asm to usr/include/asm- but
> arch/cris/include/uapi/arch-v[10|32] and arch/tile/include/uapi/arch are not
> prefixed (they are put asis in usr/include/). If it's acceptable to modify the
> output of 'make headers_install_all' to export asm headers in
> usr/include/asm-/asm, then I could remove this new subdir-y and exports
> everything under arch//include/uapi/.

I don't know if anyone still uses "make headers_install_all", I suspect
distros these days all use "make headers_install", so it probably
doesn't matter much.

In case of cris, it should be easy enough to move all the contents of the
uapi/arch-*/*.h headers into the respective uapi/asm/*.h headers, they
only seem to be referenced from there.

For tile, I suspect that would not work as the arch/*.h headers are
apparently defined as interfaces for both user space and kernel.

> Note also that exported files for asm are a mix of files listed by:
>  - include/uapi/asm-generic/Kbuild.asm;
>  - arch/x86/include/uapi/asm/Kbuild;
>  - arch/x86/include/asm/Kbuild.
> This complicates a lot the processing (arch/x86/include/asm/Kbuild is also
> used by scripts/Makefile.asm-generic).
> 
> This series has been tested with a 'make headers_install' on x86 and a
> 'make headers_install_all'. I've checked the result of both commands.
> 
> This patch is built against linus tree. I don't know if it should be
> made against antoher tree.

The series should probably get merged through the kbuild tree, but testing
it on mainline is fine here.

Arnd
--
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 v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

[Hans Verkuil]

Hi Rick,

On 01/06/2017 03:34 AM, Rick Chang wrote:
> Hi Hans,
> 
> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have 
> any idea about this patch series? Should we wait for [2] or we could merge
> the source code and dt-binding first?

Looking at [2] I noticed that the last comment was July 4th. What is the reason
it hasn't been merged yet?

If I know [2] will be merged for 4.11, then I am fine with merging this media
patch series. The dependency of this patch on [2] is something Mauro can handle.

If [2] is not merged for 4.11, then I think it is better to wait until it is
merged.

Regards,

Hans

> 
> Best Regards,
> Rick
> 
> On Wed, 2016-11-23 at 17:43 +0800, Rick Chang wrote:
>> On Wed, 2016-11-23 at 09:54 +0800, Rick Chang wrote:
>>> Hi Hans,
>>>
>>> On Tue, 2016-11-22 at 13:43 +0100, Hans Verkuil wrote:
 On 22/11/16 04:21, Rick Chang wrote:
> Hi Hans,
>
> On Mon, 2016-11-21 at 15:51 +0100, Hans Verkuil wrote:
>> On 17/11/16 04:38, Rick Chang wrote:
>>> Signed-off-by: Rick Chang 
>>> Signed-off-by: Minghsiu Tsai 
>>> ---
>>> This patch depends on:
>>>   CCF "Add clock support for Mediatek MT2701"[1]
>>>   iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
>>>
>>> [1] 
>>> http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
>>> [2] https://patchwork.kernel.org/patch/9164013/
>>
>> I assume that 1 & 2 will appear in 4.10? So this patch needs to go in
>> after the
>> other two are merged in 4.10?
>>
>> Regards,
>>
>>  Hans
>
> [1] will appear in 4.10, but [2] will appear latter than 4.10.So this
> patch needs to go in after [1] & [2] will be merged in 4.11.

 So what should I do? Merge the driver for 4.11 and wait with this patch
 until [2] is merged in 4.11? Does that sound reasonable?

 Regards,

Hans
>>>
>>> What do you think about this? You merge the driver first and I send this
>>> patch again after [1] & [2] is merged.
>>
>> BTW, to prevent merging conflict, the dtsi should be merged by mediatek
>> SoC maintainer, Matthias.I think we can only take care on the driver
>> part at this moment.
>>
> 
> 
> 
> --
> 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

[GIT PULL FOR v4.11] Various fixes & enhancements

[Hans Verkuil]

The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a:

  [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.11a

for you to fetch changes up to f77fb0d794484029f83605f05bfcd3ef25dab98f:

  staging/media/s5p-cec/exynos_hdmi_cecctrl.c Fixed blank line before closing 
brace '}' (2017-01-09 12:07:39 +0100)


Baruch Siach (2):
  ov2659: remove NOP assignment
  adv7170: drop redundant ret local

Colin Ian King (4):
  dvb-frontends: fix spelling mistake on cx24123_pll_calcutate
  cobalt: fix spelling mistake: "Celcius" -> "Celsius"
  b2c2: fix spelling mistake: "Contunuity" -> "Continuity"
  gp8psk: fix spelling mistake: "firmare" -> "firmware"

Corentin Labbe (2):
  media: s5p-cec: Remove unneeded linux/miscdevice.h include
  media: s5p-cec: Remove references to non-existent PLAT_S5P symbol

Hans Verkuil (1):
  gen-errors.rst: document EIO

Jean-Christophe Trotin (2):
  st-hva: encoding summary at instance release
  st-hva: add debug file system

Lars-Peter Clausen (1):
  adv7604: Initialize drive strength to default when using DT

Nicolas Iooss (1):
  am437x-vpfe: always assign bpp variable

Scott Matheina (2):
  staging:media:s5p-cec:exynos_hdmi_cecctrl.c Fixed Alignment should match 
open parenthesis
  staging/media/s5p-cec/exynos_hdmi_cecctrl.c Fixed blank line before 
closing brace '}'

Soren Brinkmann (1):
  vivid: Enable 4k resolution for webcam capture device

 Documentation/media/uapi/gen-errors.rst |  10 +-
 drivers/media/dvb-frontends/cx24123.c   |   2 +-
 drivers/media/i2c/adv7170.c |   5 +-
 drivers/media/i2c/adv7604.c |   3 +
 drivers/media/i2c/ov2659.c  |   1 -
 drivers/media/pci/b2c2/flexcop-pci.c|   2 +-
 drivers/media/pci/cobalt/cobalt-cpld.c  |   4 +-
 drivers/media/platform/Kconfig  |  11 ++
 drivers/media/platform/am437x/am437x-vpfe.c |   2 +-
 drivers/media/platform/sti/hva/Makefile |   1 +
 drivers/media/platform/sti/hva/hva-debugfs.c| 422 

 drivers/media/platform/sti/hva/hva-h264.c   |   6 +
 drivers/media/platform/sti/hva/hva-hw.c |  48 ++
 drivers/media/platform/sti/hva/hva-hw.h |   3 +
 drivers/media/platform/sti/hva/hva-mem.c|   5 +-
 drivers/media/platform/sti/hva/hva-v4l2.c   |  78 +++--
 drivers/media/platform/sti/hva/hva.h|  96 ++-
 drivers/media/platform/vivid/vivid-vid-cap.c|   5 +-
 drivers/media/usb/dvb-usb/gp8psk.c  |   2 +-
 drivers/staging/media/s5p-cec/Kconfig   |   2 +-
 drivers/staging/media/s5p-cec/exynos_hdmi_cec.h |   1 -
 drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c |   5 +-
 22 files changed, 683 insertions(+), 31 deletions(-)
 create mode 100644 drivers/media/platform/sti/hva/hva-debugfs.c
--
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 4/8] [media] videobuf-dma-sg: Adjust 24 checks for null values

[Dan Carpenter]

On Mon, Dec 26, 2016 at 09:48:19PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 26 Dec 2016 20:30:19 +0100
> 
> Convert comparisons with the preprocessor symbol "NULL" or the value "0"
> to condition checks without it.

Generally lengths are numbers and not booleans so "len == 0" is ok.
Checkpatch doesn't complain about that.

regards,
dan carpenter


--
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 7/7] uapi: export all headers under uapi directories

[Daniel Vetter]

On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
> 
> In fact, all headers under uapi directories should be exported, thus it's
> useless to have an exhaustive list.
> 
> After this patch, the following files, which were not exported, are now
> exported (with make headers_install_all):
> asm-unicore32/shmparam.h
> asm-unicore32/ucontext.h
> asm-hexagon/shmparam.h
> asm-mips/ucontext.h
> asm-mips/hwcap.h
> asm-mips/reg.h
> drm/vgem_drm.h
> drm/armada_drm.h
> drm/omap_drm.h
> drm/etnaviv_drm.h
> asm-tile/shmparam.h
> asm-blackfin/shmparam.h
> asm-blackfin/ucontext.h
> asm-powerpc/perf_regs.h
> rdma/qedr-abi.h
> asm-parisc/kvm_para.h
> asm-openrisc/shmparam.h
> asm-nios2/kvm_para.h
> asm-nios2/ucontext.h
> asm-sh/kvm_para.h
> asm-sh/ucontext.h
> asm-xtensa/kvm_para.h
> asm-avr32/kvm_para.h
> asm-m32r/kvm_para.h
> asm-h8300/shmparam.h
> asm-h8300/ucontext.h
> asm-metag/kvm_para.h
> asm-metag/shmparam.h
> asm-metag/ucontext.h
> asm-m68k/kvm_para.h
> asm-m68k/shmparam.h
> linux/bcache.h
> linux/kvm.h
> linux/kvm_para.h
> linux/kfd_ioctl.h
> linux/cryptouser.h
> linux/kcm.h
> linux/kcov.h
> linux/seg6_iptunnel.h
> linux/stm.h
> linux/genwqe
> linux/genwqe/.install
> linux/genwqe/genwqe_card.h
> linux/genwqe/..install.cmd
> linux/seg6.h
> linux/cifs
> linux/cifs/.install
> linux/cifs/cifs_mount.h
> linux/cifs/..install.cmd
> linux/auto_dev-ioctl.h
> 
> Thanks to Julien Floret  for the tip to get all
> subdirs with a pure makefile command.
> 
> Signed-off-by: Nicolas Dichtel 

Makes lots of sense.

Acked-by: Daniel Vetter 
> ---
>  Documentation/kbuild/makefiles.txt  |  41 ++-
>  arch/alpha/include/uapi/asm/Kbuild  |  41 ---
>  arch/arc/include/uapi/asm/Kbuild|   3 -
>  arch/arm/include/uapi/asm/Kbuild|  17 -
>  arch/arm64/include/uapi/asm/Kbuild  |  18 --
>  arch/avr32/include/uapi/asm/Kbuild  |  20 --
>  arch/blackfin/include/uapi/asm/Kbuild   |  17 -
>  arch/c6x/include/uapi/asm/Kbuild|   8 -
>  arch/cris/include/uapi/arch-v10/arch/Kbuild |   5 -
>  arch/cris/include/uapi/arch-v32/arch/Kbuild |   3 -
>  arch/cris/include/uapi/asm/Kbuild   |  43 +--
>  arch/frv/include/uapi/asm/Kbuild|  33 --
>  arch/h8300/include/uapi/asm/Kbuild  |  28 --
>  arch/hexagon/include/asm/Kbuild |   3 -
>  arch/hexagon/include/uapi/asm/Kbuild|  13 -
>  arch/ia64/include/uapi/asm/Kbuild   |  45 ---
>  arch/m32r/include/uapi/asm/Kbuild   |  31 --
>  arch/m68k/include/uapi/asm/Kbuild   |  24 --
>  arch/metag/include/uapi/asm/Kbuild  |   8 -
>  arch/microblaze/include/uapi/asm/Kbuild |  32 --
>  arch/mips/include/uapi/asm/Kbuild   |  37 ---
>  arch/mn10300/include/uapi/asm/Kbuild|  32 --
>  arch/nios2/include/uapi/asm/Kbuild  |   4 +-
>  arch/openrisc/include/asm/Kbuild|   3 -
>  arch/openrisc/include/uapi/asm/Kbuild   |   8 -
>  arch/parisc/include/uapi/asm/Kbuild |  28 --
>  arch/powerpc/include/uapi/asm/Kbuild|  45 ---
>  arch/s390/include/uapi/asm/Kbuild   |  52 ---
>  arch/score/include/asm/Kbuild   |   4 -
>  arch/score/include/uapi/asm/Kbuild  |  32 --
>  arch/sh/include/uapi/asm/Kbuild |  23 --
>  arch/sparc/include/uapi/asm/Kbuild  |  48 ---
>  arch/tile/include/asm/Kbuild|   3 -
>  arch/tile/include/uapi/arch/Kbuild  |  17 -
>  arch/tile/include/uapi/asm/Kbuild   |  19 +-
>  arch/unicore32/include/uapi/asm/Kbuild  |   6 -
>  arch/x86/include/uapi/asm/Kbuild|  59 
>  arch/xtensa/include/uapi/asm/Kbuild |  23 --
>  include/Kbuild  |   2 -
>  include/asm-generic/Kbuild.asm  |   1 -
>  include/scsi/fc/Kbuild  |   0
>  include/uapi/Kbuild |  15 -
>  include/uapi/asm-generic/Kbuild |  36 ---
>  include/uapi/asm-generic/Kbuild.asm |  62 ++--
>  include/uapi/drm/Kbuild |  22 --
>  include/uapi/linux/Kbuild   | 482 
> 
>  include/uapi/linux/android/Kbuild   |   2 -
>  include/uapi/linux/byteorder/Kbuild |   3 -
>  include/uapi/linux/caif/Kbuild  |   3 -
>  include/uapi/linux/can/Kbuild   |   6 -
>  include/uapi/linux/dvb/Kbuild   |   9 -
>  include/uapi/linux/hdlc/Kbuild  |   2 -
>  include/uapi/linux/hsi/Kbuild   |   2 -
>  include/uapi/linux/iio/Kbuild   |   3 -
>  include/uapi/linux/isdn/Kbuild  |   2 -
>  include/uapi/linux/mmc/Kbuild   |   2 -
>  

Re: astrometa device driver

[Dieter Miosga]

That's a clear instruction and it seems that
not much more efforts above the code-cook level are required.
I already took a look at the cx231xx, umt-10  and other drivers
related to the predecessor HanfTek 15f4:0131, but from the first view
I could not derive such a procedure!

Will report back to you on any remarkable progress
Dieter

On 01/09/17 00:44, Martin Blumenstingl wrote:

On Mon, Jan 9, 2017 at 1:45 AM, Dieter Miosga  wrote:

Here's the result of the lsusb on the HanfTek 15f4:0135

This USB ID is not registered with the cx231xx driver yet - thus the
driver simply ignores your device.
The basics steps for adding support for your card would be:
1. add new "#define CX231XX_BOARD_..." in cx231xx.h
2. add new entry to cx231xx_boards[] in cx231xx-cards.c with the
correct values (NOTE: has to figure out the correct values, maybe
Antti can give a hint which of the existing boards could be used as
staring point)
3. add a new entry to cx231xx_id_table (with USB vendor/device IDs) in
cx231xx-cards.c
4. add r820t_config to cx231xx-dvb.c (maybe you can even copy the one
from rtl28xxu.c)
5. add mn88473_config to cx231xx-dvb.c (again, copying the one from
rtl28xxu.c may work)
6. add a new case statement to dvb_init in cx231xx-dvb.c and connect
the rt820t_config and mn88473_config (you can probably use the code of
another board and adapt it accordingly)
7. test + bugfix :)


Regards,
Martin



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