date:20170125

Re: odd kernel messages when running v4l2-compliance

2017-01-25 Thread Niklas Söderlund

On 2017-01-25 21:38:05 +0100, Hans Verkuil wrote:
> On 01/25/2017 08:15 PM, Niklas Söderlund wrote:
> > Hi Hans,
> > 
> > I have noticed an odd printout when running v4l2-compliance while 
> > testing the rcar-vin driver. When testing (v4l2-compliance -d 0) on 
> > ARM64 I see the following messages:
> > 
> > [ 1411.016069] compat_ioctl32: unexpected VIDIOC_FMT1 type 0
> > [ 1411.022981] compat_ioctl32: unexpected VIDIOC_FMT1 type 128
> > [ 1411.033152] compat_ioctl32: unexpected VIDIOC_FMT1 type 128
> > [ 1411.043283] compat_ioctl32: unexpected VIDIOC_FMT1 type 128
> > 
> > Running the same rcar-vin driver on ARM and I see no such messages.  
> > There can of course be problems with my driver but after digging around
> > a bit I'm a bit confused, maybe you can help me understand where the 
> > true problem is.
> > 
> > In the kernel the messages originate from __get_v4l2_format32() in
> > drivers/media/v4l2-core/v4l2-compat-ioctl32.c and they are printed if 
> > the format type is unknown, that is is not one of the specified ones in 
> > a switch statement. That is all entries of enum v4l2_buf_type except 
> > V4L2_BUF_TYPE_PRIVATE.
> > 
> > enum v4l2_buf_type {
> > V4L2_BUF_TYPE_VIDEO_CAPTURE= 1,
> > V4L2_BUF_TYPE_VIDEO_OUTPUT = 2,
> > V4L2_BUF_TYPE_VIDEO_OVERLAY= 3,
> > V4L2_BUF_TYPE_VBI_CAPTURE  = 4,
> > V4L2_BUF_TYPE_VBI_OUTPUT   = 5,
> > V4L2_BUF_TYPE_SLICED_VBI_CAPTURE   = 6,
> > V4L2_BUF_TYPE_SLICED_VBI_OUTPUT= 7,
> > V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
> > V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
> > V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE  = 10,
> > V4L2_BUF_TYPE_SDR_CAPTURE  = 11,
> > V4L2_BUF_TYPE_SDR_OUTPUT   = 12,
> > /* Deprecated, do not use */
> > V4L2_BUF_TYPE_PRIVATE  = 0x80,
> > };
> > 
> > 
> > In v4l2-compliance the message is trigged inside testGetFormats() from 
> > utils/v4l2-compliance/v4l2-test-formats.cpp by:
> > 
> > for (type = 0; type <= V4L2_BUF_TYPE_LAST; type++) {
> > createInvalidFmt(fmt, clip, type);
> > ret = doioctl(node, VIDIOC_G_FMT, );
> > 
> > 
> > }
> > 
> > Here V4L2_BUF_TYPE_LAST is defined to V4L2_BUF_TYPE_SDR_OUTPUT and the 
> > enum struct is the same as in the kernel since it's included from 
> > include/linux/videodev2.h. One format is created with type = 0 and one 
> > with type = 128 which is why the messages gets printed by the kernel.
> > 
> > Is this something I should somehow handle in my driver (I can't see how 
> > I could even do that)? Or is it expected that v4l2-compliance
> > should provoke this messages in order to test the API and I should not 
> > worry about the messages when using v4l2-compliance?
> > 
> 
> Those messages really should be pr_debug instead of pr_info. The idea is
> that when a new format type is added, then that should also be supported
> in the 32-bit compat code. The warning helps identifying this.
> 
> However, the compliance test has a few tests with incorrect type values to
> check that the driver handle those correctly (returns EINVAL), so those
> tests trigger the compat code messages.
> 
> It's harmless, and you only get them when running a 32-bit v4l2-compliance
> on a 64-bit system.

I see, thanks for the explanation. I guess this is what I get for being 
lazy and reusing my 32-bit NFS root on my 64-bit systems :-)

> 
> Regards,
> 
>   Hans

-- 
Regards,
Niklas Söderlund
--
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: WARNINGS

2017-01-25 Thread Hans Verkuil

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

Results of the daily build of media_tree:

date:   Thu Jan 26 05:00:19 CET 2017
media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a
media_build git hash:   3c6ce4ff75f19adf45869e34b376c5b9dee4d50a
v4l-utils git hash: 9df320dd3d1a498fcd6cdeef7d783da609b526e0
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: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.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

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

2017-01-25 Thread Steve Longerbeam




On 01/24/2017 04:44 AM, Javier Martinez Canillas wrote:

Hello Steve,

On Fri, Jan 6, 2017 at 11:11 PM, Steve Longerbeam  wrote:

From: Philipp Zabel 

[snip]


+config VIDEO_MULTIPLEXER
+   tristate "Video Multiplexer"
+   depends on VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER

The driver can be build as a module...


+
+static const struct of_device_id vidsw_dt_ids[] = {
+   { .compatible = "video-multiplexer", },
+   { /* sentinel */ }
+};
+

... so you need a MODULE_DEVICE_TABLE(of, vidsw_dt_ids) here or
otherwise module autoloading won't work.


Hi Javier, thanks for catching, done.

Steve


--
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: odd kernel messages when running v4l2-compliance

2017-01-25 Thread Hans Verkuil

On 01/25/2017 08:15 PM, Niklas Söderlund wrote:
> Hi Hans,
> 
> I have noticed an odd printout when running v4l2-compliance while 
> testing the rcar-vin driver. When testing (v4l2-compliance -d 0) on 
> ARM64 I see the following messages:
> 
> [ 1411.016069] compat_ioctl32: unexpected VIDIOC_FMT1 type 0
> [ 1411.022981] compat_ioctl32: unexpected VIDIOC_FMT1 type 128
> [ 1411.033152] compat_ioctl32: unexpected VIDIOC_FMT1 type 128
> [ 1411.043283] compat_ioctl32: unexpected VIDIOC_FMT1 type 128
> 
> Running the same rcar-vin driver on ARM and I see no such messages.  
> There can of course be problems with my driver but after digging around
> a bit I'm a bit confused, maybe you can help me understand where the 
> true problem is.
> 
> In the kernel the messages originate from __get_v4l2_format32() in
> drivers/media/v4l2-core/v4l2-compat-ioctl32.c and they are printed if 
> the format type is unknown, that is is not one of the specified ones in 
> a switch statement. That is all entries of enum v4l2_buf_type except 
> V4L2_BUF_TYPE_PRIVATE.
> 
> enum v4l2_buf_type {
> V4L2_BUF_TYPE_VIDEO_CAPTURE= 1,
> V4L2_BUF_TYPE_VIDEO_OUTPUT = 2,
> V4L2_BUF_TYPE_VIDEO_OVERLAY= 3,
> V4L2_BUF_TYPE_VBI_CAPTURE  = 4,
> V4L2_BUF_TYPE_VBI_OUTPUT   = 5,
> V4L2_BUF_TYPE_SLICED_VBI_CAPTURE   = 6,
> V4L2_BUF_TYPE_SLICED_VBI_OUTPUT= 7,
> V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE  = 10,
> V4L2_BUF_TYPE_SDR_CAPTURE  = 11,
> V4L2_BUF_TYPE_SDR_OUTPUT   = 12,
> /* Deprecated, do not use */
> V4L2_BUF_TYPE_PRIVATE  = 0x80,
> };
> 
> 
> In v4l2-compliance the message is trigged inside testGetFormats() from 
> utils/v4l2-compliance/v4l2-test-formats.cpp by:
> 
> for (type = 0; type <= V4L2_BUF_TYPE_LAST; type++) {
> createInvalidFmt(fmt, clip, type);
> ret = doioctl(node, VIDIOC_G_FMT, );
> 
> 
> }
> 
> Here V4L2_BUF_TYPE_LAST is defined to V4L2_BUF_TYPE_SDR_OUTPUT and the 
> enum struct is the same as in the kernel since it's included from 
> include/linux/videodev2.h. One format is created with type = 0 and one 
> with type = 128 which is why the messages gets printed by the kernel.
> 
> Is this something I should somehow handle in my driver (I can't see how 
> I could even do that)? Or is it expected that v4l2-compliance
> should provoke this messages in order to test the API and I should not 
> worry about the messages when using v4l2-compliance?
> 

Those messages really should be pr_debug instead of pr_info. The idea is
that when a new format type is added, then that should also be supported
in the 32-bit compat code. The warning helps identifying this.

However, the compliance test has a few tests with incorrect type values to
check that the driver handle those correctly (returns EINVAL), so those
tests trigger the compat code messages.

It's harmless, and you only get them when running a 32-bit v4l2-compliance
on a 64-bit system.

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

odd kernel messages when running v4l2-compliance

2017-01-25 Thread Niklas Söderlund

Hi Hans,

I have noticed an odd printout when running v4l2-compliance while 
testing the rcar-vin driver. When testing (v4l2-compliance -d 0) on 
ARM64 I see the following messages:

[ 1411.016069] compat_ioctl32: unexpected VIDIOC_FMT1 type 0
[ 1411.022981] compat_ioctl32: unexpected VIDIOC_FMT1 type 128
[ 1411.033152] compat_ioctl32: unexpected VIDIOC_FMT1 type 128
[ 1411.043283] compat_ioctl32: unexpected VIDIOC_FMT1 type 128

Running the same rcar-vin driver on ARM and I see no such messages.  
There can of course be problems with my driver but after digging around
a bit I'm a bit confused, maybe you can help me understand where the 
true problem is.

In the kernel the messages originate from __get_v4l2_format32() in
drivers/media/v4l2-core/v4l2-compat-ioctl32.c and they are printed if 
the format type is unknown, that is is not one of the specified ones in 
a switch statement. That is all entries of enum v4l2_buf_type except 
V4L2_BUF_TYPE_PRIVATE.

enum v4l2_buf_type {
V4L2_BUF_TYPE_VIDEO_CAPTURE= 1,
V4L2_BUF_TYPE_VIDEO_OUTPUT = 2,
V4L2_BUF_TYPE_VIDEO_OVERLAY= 3,
V4L2_BUF_TYPE_VBI_CAPTURE  = 4,
V4L2_BUF_TYPE_VBI_OUTPUT   = 5,
V4L2_BUF_TYPE_SLICED_VBI_CAPTURE   = 6,
V4L2_BUF_TYPE_SLICED_VBI_OUTPUT= 7,
V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE  = 10,
V4L2_BUF_TYPE_SDR_CAPTURE  = 11,
V4L2_BUF_TYPE_SDR_OUTPUT   = 12,
/* Deprecated, do not use */
V4L2_BUF_TYPE_PRIVATE  = 0x80,
};


In v4l2-compliance the message is trigged inside testGetFormats() from 
utils/v4l2-compliance/v4l2-test-formats.cpp by:

for (type = 0; type <= V4L2_BUF_TYPE_LAST; type++) {
createInvalidFmt(fmt, clip, type);
ret = doioctl(node, VIDIOC_G_FMT, );


}

Here V4L2_BUF_TYPE_LAST is defined to V4L2_BUF_TYPE_SDR_OUTPUT and the 
enum struct is the same as in the kernel since it's included from 
include/linux/videodev2.h. One format is created with type = 0 and one 
with type = 128 which is why the messages gets printed by the kernel.

Is this something I should somehow handle in my driver (I can't see how 
I could even do that)? Or is it expected that v4l2-compliance
should provoke this messages in order to test the API and I should not 
worry about the messages when using v4l2-compliance?

-- 
Regards,
Niklas Söderlund
--
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 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver

2017-01-25 Thread Steve Longerbeam




On 01/20/2017 06:48 AM, Hans Verkuil wrote:

On 01/07/2017 03:11 AM, Steve Longerbeam wrote:

+
+   /* cached control settings */
+   int ctrl_cache[OV5640_MAX_CONTROLS];

This is just duplicating the cached value in the control framework. I think 
this can be dropped.


done, see below.




+
+static struct ov5640_control ov5640_ctrls[] = {
+   {
+   .set = ov5640_set_agc,
+   .ctrl = {
+   .id = V4L2_CID_AUTOGAIN,
+   .name = "Auto Gain/Exposure Control",
+   .minimum = 0,
+   .maximum = 1,
+   .step = 1,
+   .default_value = 1,
+   .type = V4L2_CTRL_TYPE_BOOLEAN,
+   },
+   }, {
+   .set = ov5640_set_exposure,
+   .ctrl = {
+   .id = V4L2_CID_EXPOSURE,
+   .name = "Exposure",
+   .minimum = 0,
+   .maximum = 65535,
+   .step = 1,
+   .default_value = 0,
+   .type = V4L2_CTRL_TYPE_INTEGER,
+   },
+   }, {
+   .set = ov5640_set_gain,
+   .ctrl = {
+   .id = V4L2_CID_GAIN,
+   .name = "Gain",
+   .minimum = 0,
+   .maximum = 1023,
+   .step = 1,
+   .default_value = 0,
+   .type = V4L2_CTRL_TYPE_INTEGER,
+   },
+   }, {
+   .set = ov5640_set_hue,
+   .ctrl = {
+   .id = V4L2_CID_HUE,
+   .name = "Hue",
+   .minimum = 0,
+   .maximum = 359,
+   .step = 1,
+   .default_value = 0,
+   .type = V4L2_CTRL_TYPE_INTEGER,
+   },
+   }, {
+   .set = ov5640_set_contrast,
+   .ctrl = {
+   .id = V4L2_CID_CONTRAST,
+   .name = "Contrast",
+   .minimum = 0,
+   .maximum = 255,
+   .step = 1,
+   .default_value = 0,
+   .type = V4L2_CTRL_TYPE_INTEGER,
+   },
+   }, {
+   .set = ov5640_set_saturation,
+   .ctrl = {
+   .id = V4L2_CID_SATURATION,
+   .name = "Saturation",
+   .minimum = 0,
+   .maximum = 255,
+   .step = 1,
+   .default_value = 64,
+   .type = V4L2_CTRL_TYPE_INTEGER,
+   },
+   }, {
+   .set = ov5640_set_awb,
+   .ctrl = {
+   .id = V4L2_CID_AUTO_WHITE_BALANCE,
+   .name = "Auto White Balance",
+   .minimum = 0,
+   .maximum = 1,
+   .step = 1,
+   .default_value = 1,
+   .type = V4L2_CTRL_TYPE_BOOLEAN,
+   },
+   }, {
+   .set = ov5640_set_red_balance,
+   .ctrl = {
+   .id = V4L2_CID_RED_BALANCE,
+   .name = "Red Balance",
+   .minimum = 0,
+   .maximum = 4095,
+   .step = 1,
+   .default_value = 0,
+   .type = V4L2_CTRL_TYPE_INTEGER,
+   },
+   }, {
+   .set = ov5640_set_blue_balance,
+   .ctrl = {
+   .id = V4L2_CID_BLUE_BALANCE,
+   .name = "Blue Balance",
+   .minimum = 0,
+   .maximum = 4095,
+   .step = 1,
+   .default_value = 0,
+   .type = V4L2_CTRL_TYPE_INTEGER,
+   },
+   },
+};
+#define OV5640_NUM_CONTROLS ARRAY_SIZE(ov5640_ctrls)

This should use v4l2_ctrl_new_std() instead of this array.
Just put a switch on ctrl->id in s_ctrl, and each case calls the corresponding
set function.


In this case, because there are lots of controls, my preference is to use
table lookup rather than a large switch statement. However I did remove
.name and .type from the table entries, leaving only .def, .min, .max, .step
as required to pass to v4l2_ctrl_new_std(). Also converted to 'struct 
v4l2_ctrl_config'

in the table.





+
+static int ov5640_restore_ctrls(struct ov5640_dev *sensor)
+{
+   struct ov5640_control *c;
+   int i;
+
+   for (i = 0; i < OV5640_NUM_CONTROLS; i++) {
+   c = _ctrls[i];
+   c->set(sensor, sensor->ctrl_cache[i]);
+   }
+
+   return 0;
+}

This does the same as v4l2_ctrl_handler_setup() if I understand the code 
correctly.


yes thanks. I

Re: [PATCH v6] [media] vimc: Virtual Media Controller core, capture and sensor

2017-01-25 Thread Mauro Carvalho Chehab

I won't be doing a review on it yet... I'll try to do it on the next
version. Just a quick notice:

Em Wed, 25 Jan 2017 15:03:46 +0200
Sakari Ailus  escreveu:

> > + * Copyright (C) 2016 Helen Koike F.   
> 
> 2017 might be used now.

Please keep 2016 as the year you did the initial development. It
makes sense to change it to:
2016-2017

In order to reflect that you're also doing some work on it this year,
but preserving the initial date is important, IMHO.

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

[GIT PULL FOR v4.11] Add et8ek8 driver

2017-01-25 Thread Sakari Ailus

Hi Mauro,

This pull request adds the sensor et8ek8 driver which is used on the Nokia
N900. Please pull.


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:

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

for you to fetch changes up to 1d26b93d5341d36cdd45b4d801f85d6c35128385:

  mark myself as mainainer for camera on N900 (2017-01-25 15:49:45 +0200)


Pavel Machek (3):
  media: et8ek8: add device tree binding documentation
  media: Driver for Toshiba et8ek8 5MP sensor
  mark myself as mainainer for camera on N900

 .../bindings/media/i2c/toshiba,et8ek8.txt  |   48 +
 MAINTAINERS|8 +
 drivers/media/i2c/Kconfig  |1 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/et8ek8/Kconfig   |6 +
 drivers/media/i2c/et8ek8/Makefile  |2 +
 drivers/media/i2c/et8ek8/et8ek8_driver.c   | 1515 
 drivers/media/i2c/et8ek8/et8ek8_mode.c |  587 
 drivers/media/i2c/et8ek8/et8ek8_reg.h  |   96 ++
 9 files changed, 2264 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
 create mode 100644 drivers/media/i2c/et8ek8/Kconfig
 create mode 100644 drivers/media/i2c/et8ek8/Makefile
 create mode 100644 drivers/media/i2c/et8ek8/et8ek8_driver.c
 create mode 100644 drivers/media/i2c/et8ek8/et8ek8_mode.c
 create mode 100644 drivers/media/i2c/et8ek8/et8ek8_reg.h

-- 
Kind regards,

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

Re: [PATCH] mark myself as mainainer for camera on N900

2017-01-25 Thread Sakari Ailus

Hi Sebastian and Pavel,

On Wed, Dec 28, 2016 at 12:57:21AM +0100, Sebastian Reichel wrote:
> Hi,
> 
> On Tue, Dec 27, 2016 at 09:59:23PM +0100, Pavel Machek wrote:
> > Mark and Sakari as maintainers for Nokia N900 camera pieces.
> 
> ^^^ missing me after Mark. Otherwise Mark looks like a name :)
> 
> > Signed-off-by: Pavel Machek 
> > 
> > ---
> > 
> > Hi!
> > 
> > > Yeah, there was big flamewar about the permissions. In the end Linus
> > > decided that everyone knows the octal numbers, but the constants are
> > > tricky. It began with patch series with 1000 patches...
> > > 
> > > > Btw. should we update maintainers as well? Would you like to put 
> > > > yourself
> > > > there? Feel free to add me, too...
> > > 
> > > Ok, will do.
> > 
> > Something like this? Actually, I guess we could merge ADP1653 entry
> > there. Yes, it is random collection of devices, but are usually tested
> > "together", so I believe one entry makes sense.
> > 
> > (But I have no problem with having multiple entries, too.)
> > 
> > Thanks,
> > Pavel
> > 
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 63cefa6..1cb1d97 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -8613,6 +8613,14 @@ T:   git 
> > git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2.git
> >  S: Maintained
> >  F: arch/nios2/
> >  
> > +NOKIA N900 CAMERA SUPPORT (ET8EK8 SENSOR, AD5820 FOCUS)
> > +M: Pavel Machek 
> > +M: Sakari Ailus 
> > +L: linux-media@vger.kernel.org
> > +S: Maintained
> > +F: drivers/media/i2c/et8ek8
> > +F: drivers/media/i2c/ad5820.c
> 
> Not sure if this is useful information, but I solved it like this
> for N900 power supply drivers:
> 
> NOKIA N900 POWER SUPPLY DRIVERS
> R:Pali Rohár 
> F:include/linux/power/bq2415x_charger.h
> F:include/linux/power/bq27xxx_battery.h
> F:include/linux/power/isp1704_charger.h
> F:drivers/power/supply/bq2415x_charger.c
> F:drivers/power/supply/bq27xxx_battery.c
> F:drivers/power/supply/bq27xxx_battery_i2c.c
> F:drivers/power/supply/isp1704_charger.c
> F:drivers/power/supply/rx51_battery.c
> 
> TI BQ27XXX POWER SUPPLY DRIVER
> R:Andrew F. Davis 
> F:include/linux/power/bq27xxx_battery.h
> F:drivers/power/supply/bq27xxx_battery.c
> F:drivers/power/supply/bq27xxx_battery_i2c.c
> 
> POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
> M:Sebastian Reichel 
> L:linux...@vger.kernel.org
> T:git 
> git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git
> S:Maintained
> F:Documentation/devicetree/bindings/power/supply/
> F:include/linux/power_supply.h
> F:drivers/power/supply/
> 
> This makes it quite easy to see who applies patches and who should
> be Cc'd for what reason:
> 
> $ ./scripts/get_maintainer.pl -f drivers/power/supply/bq27xxx_battery.c 
> "Pali Rohár"  (reviewer:NOKIA N900 POWER SUPPLY DRIVERS)
> "Andrew F. Davis"  (reviewer:TI BQ27XXX POWER SUPPLY DRIVER)
> Sebastian Reichel  (maintainer:POWER SUPPLY CLASS/SUBSYSTEM 
> and DRIVERS)
> linux...@vger.kernel.org (open list:POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS)
> linux-ker...@vger.kernel.org (open list)

I'm adding Pavel's patch to my tree and then send a pull req to Mauro. If
further changes are needed then let's write more patches.

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

Re: [PATCH v6] [media] vimc: Virtual Media Controller core, capture and sensor

2017-01-25 Thread Sakari Ailus

Hi Helen,

My apologies for the long review time!

Please see my comments below.

On Sun, Sep 04, 2016 at 05:02:18PM -0300, Helen Koike wrote:
> From: Helen Fornazier 
> 
> First version of the Virtual Media Controller.
> Add a simple version of the core of the driver, the capture and
> sensor nodes in the topology, generating a grey image in a hardcoded
> format.
> 
> Signed-off-by: Helen Koike 
> 
> ---
> 
> Patch based in media/master tree, and available here:
> https://github.com/helen-fornazier/opw-staging/tree/vimc/devel/vpu
> 
> Changes since v5:
> - Fix message "Entity type for entity Sensor A was not initialized!"
>   by initializing the sensor entity.function after the calling
>   v4l2_subded_init
> - populate device_caps in vimc_cap_create instead of in
>   vimc_cap_querycap
> - Fix typo in vimc-core.c s/de/the
> 
> Changes since v4:
> - coding style fixes
> - remove BUG_ON
> - change copyright to 2016
> - depens on VIDEO_V4L2_SUBDEV_API instead of select
> - remove assignement of V4L2_CAP_DEVICE_CAPS
> - s/vimc_cap_g_fmt_vid_cap/vimc_cap_fmt_vid_cap
> - fix vimc_cap_queue_setup declaration type
> - remove wrong buffer size check and add it in vimc_cap_buffer_prepare
> - vimc_cap_create: remove unecessary check if v4l2_dev or v4l2_dev->dev is 
> null
> - vimc_cap_create: only allow a single pad
> - vimc_sen_create: only allow source pads, remove unecessary source pads
> checks in vimc_thread_sen
> 
> Changes since v3: fix rmmod crash and built-in compile
> - Re-order unregister calls in vimc_device_unregister function (remove
> rmmod issue)
> - Call media_device_unregister_entity in vimc_raw_destroy
> - Add depends on VIDEO_DEV && VIDEO_V4L2 and select VIDEOBUF2_VMALLOC
> - Check *nplanes in queue_setup (this remove v4l2-compliance fail)
> - Include  in vimc-sensor.c
> - Move include of  from vimc-core.c to vimc-core.h
> - Generate 60 frames per sec instead of 1 in the sensor
> 
> Changes since v2: update with current media master tree
> - Add struct media_pipeline in vimc_cap_device
> - Use vb2_v4l2_buffer instead of vb2_buffer
> - Typos
> - Remove usage of entity->type and use entity->function instead
> - Remove fmt argument from queue setup
> - Use ktime_get_ns instead of v4l2_get_timestamp
> - Iterate over link's list using list_for_each_entry
> - Use media_device_{init, cleanup}
> - Use entity->use_count to keep track of entities instead of the old
> entity->id
> - Replace media_entity_init by media_entity_pads_init
> ---
>  drivers/media/platform/Kconfig |   2 +
>  drivers/media/platform/Makefile|   1 +
>  drivers/media/platform/vimc/Kconfig|   7 +
>  drivers/media/platform/vimc/Makefile   |   3 +
>  drivers/media/platform/vimc/vimc-capture.c | 553 ++
>  drivers/media/platform/vimc/vimc-capture.h |  28 ++
>  drivers/media/platform/vimc/vimc-core.c| 600 
> +
>  drivers/media/platform/vimc/vimc-core.h|  57 +++
>  drivers/media/platform/vimc/vimc-sensor.c  | 279 ++
>  drivers/media/platform/vimc/vimc-sensor.h  |  28 ++
>  10 files changed, 1558 insertions(+)
>  create mode 100644 drivers/media/platform/vimc/Kconfig
>  create mode 100644 drivers/media/platform/vimc/Makefile
>  create mode 100644 drivers/media/platform/vimc/vimc-capture.c
>  create mode 100644 drivers/media/platform/vimc/vimc-capture.h
>  create mode 100644 drivers/media/platform/vimc/vimc-core.c
>  create mode 100644 drivers/media/platform/vimc/vimc-core.h
>  create mode 100644 drivers/media/platform/vimc/vimc-sensor.c
>  create mode 100644 drivers/media/platform/vimc/vimc-sensor.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 46f14dd..4a0577f 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -329,6 +329,8 @@ menuconfig V4L_TEST_DRIVERS
>  
>  if V4L_TEST_DRIVERS
>  
> +source "drivers/media/platform/vimc/Kconfig"
> +
>  source "drivers/media/platform/vivid/Kconfig"
>  
>  config VIDEO_VIM2M
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 536d1d8..dd4f658 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_VIDEO_OMAP3)   += omap3isp/
>  
>  obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
>  
> +obj-$(CONFIG_VIDEO_VIMC) += vimc/
>  obj-$(CONFIG_VIDEO_VIVID)+= vivid/
>  obj-$(CONFIG_VIDEO_VIM2M)+= vim2m.o
>  
> diff --git a/drivers/media/platform/vimc/Kconfig 
> b/drivers/media/platform/vimc/Kconfig
> new file mode 100644
> index 000..b48819c
> --- /dev/null
> +++ b/drivers/media/platform/vimc/Kconfig
> @@ -0,0 +1,7 @@
> +config VIDEO_VIMC
> + tristate "Virtual Media Controller Driver (VIMC)"
> + depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + select VIDEOBUF2_VMALLOC
> + default n
> + ---help---
> +   Skeleton

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

2017-01-25 Thread Sakari Ailus

Hi Vincent,

On Wed, Jan 11, 2017 at 12:36:24PM +, Vincent ABRIOU wrote:
> Hi Sakari,
> 
> On 01/11/2017 12:03 PM, Sakari Ailus wrote:
> > Hi Vincent,
> >
> > On Mon, Jan 09, 2017 at 03:49:00PM +, 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.
> >
> > Do you need (physically) contiguous memory?
> >
> 
> Yes, drm driver that does not have mmu needs to have contiguous buffers.

One option would be to have that driver to allocate the memory. I admit it's
not a great solution as you need special arrangements because you allocate
memory where the hardware has strictest memory allocation requirements.

> 
> > The DMA-BUF API does help sharing the buffers but it, at least currently,
> > does not help allocating memory or specifying a common format so that all
> > the devices the buffer needs to be accessible can actually make use of it.
> >
> > Instead of hacking drivers to make use of different memory allocation
> > strategies required by unrelated devices, we should instead fix these
> > problems in a proper, scalable way.
> >
> 
> Scalable way? Like central allocator?

Yeah. You seem to be working on this already. :-)

Some devices have the weirdest memory requirements, but most (those with
MMU) can manage with any pages in the system memory. Either physically or
virtually (i.e. a buffer consisting of any page in system memory) contiguous
memory can be supported by the vast majority of devices.

It'd be nice, API-wise, to be able to tell in the user space which device
the buffer is used with and only then perform the actual allocation. An
alternative would be to re-allocate if a device's memory requirements do not
match with a buffer what the user is passing to to a device, but this may be
problematic from performance point of view (as you need to reallocate).

An allocator or a couple will be needed, too.

-- 
Kind regards,

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

Re: [PATCH] v4l2-ctrls.c: add NULL check

2017-01-25 Thread Sakari Ailus

On Wed, Jan 25, 2017 at 08:38:07AM +0100, Hans Verkuil wrote:
> Check that the control whose events we want to delete is still there.
> 
> Normally this will always be the case, but I am not 100% certain if there 
> aren't
> any corner cases when a device is forcibly unbound.
> 
> In any case, this will satisfy static checkers and simply make it more robust.
> 
> Signed-off-by: Hans Verkuil 
> Reported-by: Shaobo 

Acked-by: Sakari Ailus 

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

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

2017-01-25 Thread Sakari Ailus

Hi Mauro,

On Tue, Jan 24, 2017 at 08:49:02AM -0200, Mauro Carvalho Chehab wrote:
> Hi Sakari,
> 
> Just returned this week from vacations. I'm reading my long e-mail backlog,
> starting from my main inbox...
> 
> Em Mon, 2 Jan 2017 09:53:49 +0200
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > On Mon, Dec 19, 2016 at 07:46:55AM -0200, Mauro Carvalho Chehab wrote:
> > > Em Fri, 16 Dec 2016 17:07:23 +0200
> > > Sakari Ailus  escreveu:
> > >   
> > > > Hi Hans,  
> > >   
> > > > > chrdev_open in fs/char_dev.c increases the refcount on open() and 
> > > > > decreases it
> > > > > on release(). Thus ensuring that the cdev can never be removed while 
> > > > > in an
> > > > > ioctl.
> > > > 
> > > > It does, but it does not affect memory which is allocated separately of 
> > > > that.
> > > > 
> > > > See this:
> > > > 
> > > > 
> > > >   
> > > 
> > > That sounds promising. If this bug issues other drivers than OMAP3,
> > > then indeed the core has a bug.
> > > 
> > > I'll see if I can reproduce it here with some USB drivers later this 
> > > week.  
> > 
> > It's not a driver problem so yes, it is reproducible on other hardware.
> 
> Didn't have time to test it before entering into vacations.
> 
> I guess I won't have any time this week to test those issues on
> my hardware, as I suspect that my patch queue is full. Also, we're
> approaching the next merge window. So, unfortunately, I won't have
> much time those days to do much testing. 
> 
> Btw, Hans commented that you were planning to working on it this month.
> 
> Do you have some news with regards to the media controller bind/unbind
> fixes?

I have a bunch of meeting notes to send from the Oslo meeting with Hans and
Laurent; I should have that ready by the end of the week. The RFC patchset
certainly needs changes based on that.

> 
> > > While IMHO it is overkill trying to support hot plug on omap3, I won't
> > > mind if you do that, provided that your patch series can be applied in
> > > a way that it won't cause regressions for real hot-pluggable hardware.  
> > 
> > This is not really about the OMAP3 ISP driver hotplug support; it is indeed
> > about the framework's ability to support hotpluggable hardware. The current
> > painpoint is removing hardware; the current frameworks aren't quite up to
> > that at the moment.
> 
> The point here is that, while it would be fun to allow unbinding OMAP3
> V4L2 drivers, OMAP3 doesn't really require hotplug support. On the other
> hand, on USB drivers, where unbind is a requirement, the current status
> of the tree is that hotplug works. I did some massive parallel bind/unbind
> loops here to double check, when we added such fixup patches. Granted, I
> won't doubt that there are still some rare race conditions that I was
> unable to reproduce on the time I tested. I also didn't try to hack the
> Kernel to introduce extra delays to make those race conditions more
> likely to happen.
> 
> Anyway, my main concern with this patch is that it breaks hotplug on devices
> that really need it, while it fix support only for OMAP3 (with doesn't need).

I don't disagree with you. Obviously the intent is not to break
hot-pluggable hardware, albeit the changes needed to avoid that haven't been
implemented yet. (One of the reasons it's been RFC all the time.)

> 
> Also, it starts with a series of patches that will cause regressions.
> 
> I won't matter changing the solution to some other approach that would
> work, provided that the patches are added on an incremented way, and
> won't introduce regressions to USB drivers.

It may be possible to avoid increasing the time window during which bad
things could happen before fully removing them. However the patchset is a
lot easier to work with without bundling the reverts into other (and likely
multiple) patches as the reverted patches took quite a different direction
than is followed in this patchset.

Let's discuss this later, at the time when we have a patchset that produces
a sound code base (on the top of that patchset) that is understood to be
free of object lifetime issues as long as hot-pluggable hardware goes.

> 
> > > On that matter, just like we use vivid as a testbench and as an
> > > example for other drivers, it would be great if we could merge
> > > the vimc driver. What's the status of Helen's patchset?  
> > 
> > That's a good point. I wasn't reviewing that driver back then when the
> > patches were posted, but should it go in, it should make a good example for
> > writing other drivers as well.
> > 
> 
> I saw Laurent's comments about Helen's last patch series. From his
> comments:
> 
>   "I've reviewed the whole patch but haven't had time to test it. I've 
> also 
>skipped the items marked as TODO or FIXME as they're obviously not 
> ready yet 
>:-) Overall this looks good to me, all the issues are minor."
> 
>

Re: [PATCH] media: platform: constify vb2_ops structures

2017-01-25 Thread Lad, Prabhakar

Hi,

Thanks for the patch.

On Sat, Jan 21, 2017 at 9:29 AM, Bhumika Goyal  wrote:
> Declare vb2_ops structures as const as they are only stored in
> the ops field of a vb2_queue structure. This field is of type
> const, so vb2_ops structures having same properties can be made
> const too.
> Done using Coccinelle:
>
> @r1 disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct vb2_ops i@p={...};
>
> @ok1@
> identifier r1.i;
> position p;
> struct sta2x11_vip vip;
> struct vb2_queue q;
> @@
> (
> vip.vb_vidq.ops=@p
> |
> q.ops=@p
> )
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct vb2_ops i;
>
> Cross compiled the media/platform/blackfin/bfin_capture.o file for
> blackfin architecture.
>
> File size before:
>   text data bss dec hex filename
>   6776  176   069521b28 platform/blackfin/bfin_capture.o
>
The description doesnt match the changes. Can you please split the
patches separately one for vpif_capture.c and vpif_display.c,
one for mtk_mdp_m2m.c and lastly for pxa_camera.c .


Cheers,
--Prabhakar Lad
--
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 simple allocator v1 0/2] Simple allocator

2017-01-25 Thread Laura Abbott


On 01/23/2017 09:35 AM, Daniel Vetter wrote:

On Fri, Jan 20, 2017 at 04:32:29PM +0100, Benjamin Gaignard wrote:

The goal of this RFC is to understand if a common ioctl for specific memory
regions allocations is needed/welcome.

Obviously it will not replace allocation done in linux kernel frameworks like
v4l2, drm/kms or others, but offer an alternative when you don't want/need to
use them for buffer allocation.
To keep a compatibility with what already exist allocated buffers are exported
in userland as dmabuf file descriptor (like ION is doing).

"Unix Device Memory Allocator" project [1] wants to create a userland library
which may allow to select, depending of the devices constraint, the best
back-end for allocation. With this RFC I would to propose to have common ioctl
for a maximum of allocators to avoid to duplicated back-ends for this library.

One of the issues that lead me to propose this RFC it is that since the 
beginning
it is a problem to allocate contiguous memory (CMA) without using v4l2 or
drm/kms so the first allocator available in this RFC use CMA memory.

An other question is: do we have others memory regions that could be interested
by this new framework ? I have in mind that some title memory regions could use
it or replace ION heaps (system, carveout, etc...).
Maybe it only solve CMA allocation issue, in this case there is no need to 
create
a new framework but only a dedicated ioctl.

Maybe the first thing to do is to change the name and the location of this
module, suggestions are welcome.

I have testing this code with the following program:


I'm still maintaining that we should just destage ION (with the todo items
fixed), since that is already an uabi to do this (afaiui at least), and
it's used on a few devices ... Please chat with Laura Abott.
-Daniel



(I thought I sent this before but apparently it didn't go through.
Apologies if this ends up as a repeat for anyone)

I've been reviewing this as well. Even if Ion is used on a number of
devices, the model is still a bit clunky. I was hoping to see if it
could be re-written from scratch in a framework like this and then
either add a shim layer or just coax all devices out there to actually
convert to the new framework.

I supposed another option is to destage as you suggested and work on
an improved version in parallel.

Thanks,
Laura


--
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: odd kernel messages when running v4l2-compliance

cron job: media_tree daily build: WARNINGS

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

Re: odd kernel messages when running v4l2-compliance

odd kernel messages when running v4l2-compliance

Re: [PATCH v3 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver

Re: [PATCH v6] [media] vimc: Virtual Media Controller core, capture and sensor

[GIT PULL FOR v4.11] Add et8ek8 driver

Re: [PATCH] mark myself as mainainer for camera on N900

Re: [PATCH v6] [media] vimc: Virtual Media Controller core, capture and sensor

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

Re: [PATCH] v4l2-ctrls.c: add NULL check

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

Re: [PATCH] media: platform: constify vb2_ops structures

Re: [RFC simple allocator v1 0/2] Simple allocator

15 matches

Site Navigation

Mail list logo

Footer information