cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Sat Jan 28 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/Saturday.log

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Fwd: Upside down webcam

[Hamidreza Jafari]

Hello,
There is a problem with the webcam that uses v4l code. If anyone has a
hint, contact me on hamidrjaf...@gmail.com since I am going off the
mailing list since
The mailing list is sending numerous notifications

Hamid
با سپاس،
حمیدرضا جعفری



‎-- Forwarded message --‎
From: Hamidreza Jafari ‎‎
Date: 2017-01-27 22:08 GMT+03:30
Subject: Upside down webcam
To:  ‫linux-media@vger.kernel.org‬


Hello,

https://linuxtv.org/wiki/index.php/Libv4l_Upside_Down_Webcams

The webcam is upside down and the solution does not work (as it did in
a previous Ubuntu version). On Kubuntu 16.10 with 4.8.0-34 kernel I
installed an app called Webcamoid to test and ran the following
commands:

$export LIBV4LCONTROL_FLAGS=3 &&
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libv4l/v4l1compat.so webcamoid &
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/TextField.qml:635:5:
QML TextInputWithHandles: Binding loop detected for property "text"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/TextField.qml:635:5:
QML TextInputWithHandles: Binding loop detected for property "text"
libv4l2: error setting pixformat: Device or resource busy
libv4l2: error setting pixformat: Device or resource busy
VideoCapture: No streams available.

$ v4l2-ctl -d /dev/video0 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Index : 0
Type : Video Capture
Pixel Format: 'YUYV'
Name : YUYV 4:2:2
Size: Discrete 640x480
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Size: Discrete 352x288
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Size: Discrete 320x240
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Size: Discrete 176x144
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Size: Discrete 160x120
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.067s (15.000 fps)

$v4l2-ctl --device=/dev/video0 --list-inputs
ioctl: VIDIOC_ENUMINPUT
Input : 0
Name : Camera 1
Type : 0x0002
Audioset : 0x
Tuner : 0x
Standard : 0x ()
Status : 0x (ok)
Capabilities: 0x (not defined)

How to fix the problem?

Hamid
با سپاس،
حمیدرضا جعفری
--
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 6/6] staging: bcm2835-v4l2: Apply spelling fixes from checkpatch.

[Joe Perches]

On Fri, 2017-01-27 at 13:55 -0800, Eric Anholt wrote:
> Generated with checkpatch.pl --fix-inplace and git add -p out of the
> results.

Maybe another.

> diff --git a/drivers/staging/media/platform/bcm2835/mmal-vchiq.c 
> b/drivers/staging/media/platform/bcm2835/mmal-vchiq.c
[]
> @@ -239,7 +239,7 @@ static int bulk_receive(struct vchiq_mmal_instance 
> *instance,
>   pr_err("buffer list empty trying to submit bulk receive\n");
>  
>   /* todo: this is a serious error, we should never have
> -  * commited a buffer_to_host operation to the mmal
> +  * committed a buffer_to_host operation to the mmal
>* port without the buffer to back it up (underflow
>* handling) and there is no obvious way to deal with
>* this - how is the mmal servie going to react when

Perhaps s/servie/service/ ?


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

[GIT PULL 4.11] af9035 misc changes

[Antti Palosaari]

The following changes since commit d183e4efcae8d88a2f252e546978658ca6d273cc:

  [media] v4l: tvp5150: Add missing break in set control handler 
(2016-12-12 07:49:58 -0200)


are available in the git repository at:

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

for you to fetch changes up to 935e7e49e1cdf6f4c9beb1366c060fb1226c23ae:

  af9033: estimate cnr from formula (2016-12-19 18:38:23 +0200)


Antti Palosaari (10):
  af9035: read and store whole eeprom
  af9033: convert to regmap api
  af9033: use 64-bit div macro where possible
  af9033: style related and minor changes
  af9033: return regmap for integrated IT913x tuner driver
  it913x: change driver model from i2c to platform
  af9035: register it9133 tuner using platform binding
  it913x: add chip device ids for binding
  af9035: correct demod i2c addresses
  af9033: estimate cnr from formula

 drivers/media/dvb-frontends/Kconfig   |   1 +
 drivers/media/dvb-frontends/af9033.c  | 837 


 drivers/media/dvb-frontends/af9033.h  |  13 ++-
 drivers/media/dvb-frontends/af9033_priv.h | 185 
+++

 drivers/media/tuners/it913x.c |  92 +++-
 drivers/media/tuners/it913x.h |  26 ++---
 drivers/media/usb/dvb-usb-v2/af9035.c | 267 
+

 drivers/media/usb/dvb-usb-v2/af9035.h |   7 +-
 8 files changed, 582 insertions(+), 846 deletions(-)

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

Re: [ANN] Media object lifetime management meeting report from Oslo

[Sakari Ailus]

Hi Mauro,

Obrigado for the comments! Please see my replies below.

On Fri, Jan 27, 2017 at 09:38:31AM -0200, Mauro Carvalho Chehab wrote:
> Hi Sakari/Hans/Laurent,
> 
> First of all, thanks for looking into those issues. Unfortunately, I was in
> vacations, and were not able to be with you there for such discussions.
> 
> While I have a somewhat different view on some of the introductory points of 
> this RFC, what really matters is the "proposal" part of it. So, based on the
> experiments I did when I addressed the hotplug issues with the media
> controller on USB drivers, I'm adding a few comments below.
> 
> 
> Em Fri, 27 Jan 2017 12:08:22 +0200
> Sakari Ailus  escreveu:
> 
> > Allocating struct media_devnode separately from struct media_device
> > ---
> > 
> > The current codebase allocates struct media_devnode dynamically. This was
> > done in order to reduce the time window during which unallocated kernel
> > memory could be accessed. However, there is no specific need for such a
> > separation as the entire data structure, including the media device which
> > used to contain struct media_devnode, will have the same lifetime. Thus the
> > struct media_devnode should be allocated as part of struct media_device.
> > Later on, struct media_devnode may be merged with struct media_device if so
> > decided.
> 
> There is one issue merging struct media_devnode at struct media_device.
> The problem is that, if the same struct device is used for two different
> APIs (like V4L2 and media_controller) , e. g. if the cdev parent points
> to the same struct device, you may end by having a double free when the
> device is unregistered on the second core. That's basically why 
> currently struct cdev is at struct media_devnode: this way, it has its own
> struct device.

One of the conclusions of the memorandum I wrote is that the data structures
that are involved in executing a system call (including IOCTLs) must stay
intact during that system call. (Well, the alternative I can think of is
using an rw_semaphore but I certainly do not advocate that solution.)

Otherwise, we will continue to have serialisation issues: kernel memory that
may be released at any point of time independently of a system call in
progress:



That one is a NULL pointer dereference but released kernel memory can be
accessed as well.

> 
> IMHO, it also makes sense to embeed struct cdev at the V4L2 side, as I
> detected some race issues at the V4L2 side when I ran the bind/unbind
> race tests, when we tried to merge the snd-usb-audio MC support patch.
> I remember Shuah reported something similar on that time.
> 
> > Allocating struct media_device dynamically
> > --
> > 
> > Traditionally the media device has been allocated as part of drivers' own
> > structures. This is certainly fine as such, but many drivers have allocated
> > the driver private struct using the devm_() family of functions. This causes
> > such memory to be released at the time of device removal rather than at the
> > time when the memory is no longer accessible by e.g. user space processes or
> > interrupt handlers. Besides the media device, the driver's own data
> > structure is very likely to have the precisely same lifetime issue: it may
> > also be accessed through IOCTLs after the device has been removed from the
> > system.
> > 
> > Instead, the memory needs to be released as part of the release() callback
> > of the media device which is called when the last reference to the media
> > device is gone. Still, allocating the media device outside another
> > containing driver specific struct will be required in some cases: sharing
> > the media device mandates that. Implementing this can certainly be postponed
> > until sharing the media device is otherwise supported as well.
> 
> The patches adding MC support for snd-usb-audio, pending since Kernel
> 4.7 (I guess) require such functionatilty. Last year, on the audio
> summit, they asked about its status, as they're needing MC suppor there.
> 
> So, whatever solution taken, this should be part of the solution.
> 
> (c/c Shuah, as she is the one working on it)

I think we should postpone that, or at least resolve that in a separate
patchset. This is already getting very big. The refcounting problems will be
harder to fix, should we extend the MC framework with media device sharing
without considering the object lifetime issues first. So the order should
be: first fix object lifetime issues, then add more features.

Matters unrelated to the object lifetime issues such as the device (driver)
specific fields in struct media_device need to be addressed before support
for sharing the media device can be implemented. That work can be done
independently of fixing the object lifetime issues.

Implemeting media device sharing 

[PATCH 5/6] staging: bcm2835-v4l2: Apply many whitespace fixes from checkpatch.

[Eric Anholt]

Generated with checkpatch.pl --fix-inplace, some manual fixes for
cases where checkpatch fixed one out of multiple lines of mis-indented
function parameters, and then git add -p out of the results.

I skipped some fixes that should probably instead be replaced with the
BIT() macro.

Signed-off-by: Eric Anholt 
---
 .../media/platform/bcm2835/bcm2835-camera.c|  90 
 drivers/staging/media/platform/bcm2835/controls.c  | 236 ++---
 .../staging/media/platform/bcm2835/mmal-vchiq.c|  13 +-
 3 files changed, 167 insertions(+), 172 deletions(-)

diff --git a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c 
b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
index 4f03949aecf3..4541a363905c 100644
--- a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
+++ b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
@@ -38,7 +38,7 @@
 #define BM2835_MMAL_MODULE_NAME "bcm2835-v4l2"
 #define MIN_WIDTH 32
 #define MIN_HEIGHT 32
-#define MIN_BUFFER_SIZE (80*1024)
+#define MIN_BUFFER_SIZE (80 * 1024)
 
 #define MAX_VIDEO_MODE_WIDTH 1280
 #define MAX_VIDEO_MODE_HEIGHT 720
@@ -420,6 +420,7 @@ static void buffer_cb(struct vchiq_mmal_instance *instance,
 static int enable_camera(struct bm2835_mmal_dev *dev)
 {
int ret;
+
if (!dev->camera_use_count) {
ret = vchiq_mmal_port_parameter_set(
dev->instance,
@@ -451,6 +452,7 @@ static int enable_camera(struct bm2835_mmal_dev *dev)
 static int disable_camera(struct bm2835_mmal_dev *dev)
 {
int ret;
+
if (!dev->camera_use_count) {
v4l2_err(>v4l2_dev,
 "Disabled the camera when already disabled\n");
@@ -459,6 +461,7 @@ static int disable_camera(struct bm2835_mmal_dev *dev)
dev->camera_use_count--;
if (!dev->camera_use_count) {
unsigned int i = 0x;
+
v4l2_dbg(1, bcm2835_v4l2_debug, >v4l2_dev,
 "Disabling camera\n");
ret =
@@ -643,12 +646,14 @@ static void stop_streaming(struct vb2_queue *vq)
 static void bm2835_mmal_lock(struct vb2_queue *vq)
 {
struct bm2835_mmal_dev *dev = vb2_get_drv_priv(vq);
+
mutex_lock(>mutex);
 }
 
 static void bm2835_mmal_unlock(struct vb2_queue *vq)
 {
struct bm2835_mmal_dev *dev = vb2_get_drv_priv(vq);
+
mutex_unlock(>mutex);
 }
 
@@ -737,7 +742,7 @@ static int vidioc_try_fmt_vid_overlay(struct file *file, 
void *priv,
  1, 0);
 
v4l2_dbg(1, bcm2835_v4l2_debug, >v4l2_dev,
-   "Overlay: Now w/h %dx%d l/t %dx%d\n",
+"Overlay: Now w/h %dx%d l/t %dx%d\n",
f->fmt.win.w.width, f->fmt.win.w.height,
f->fmt.win.w.left, f->fmt.win.w.top);
 
@@ -759,7 +764,7 @@ static int vidioc_s_fmt_vid_overlay(struct file *file, void 
*priv,
dev->overlay = f->fmt.win;
if (dev->component[MMAL_COMPONENT_PREVIEW]->enabled) {
set_overlay_params(dev,
-   >component[MMAL_COMPONENT_PREVIEW]->input[0]);
+  
>component[MMAL_COMPONENT_PREVIEW]->input[0]);
}
 
return 0;
@@ -771,6 +776,7 @@ static int vidioc_overlay(struct file *file, void *f, 
unsigned int on)
struct bm2835_mmal_dev *dev = video_drvdata(file);
struct vchiq_mmal_port *src;
struct vchiq_mmal_port *dst;
+
if ((on && dev->component[MMAL_COMPONENT_PREVIEW]->enabled) ||
(!on && !dev->component[MMAL_COMPONENT_PREVIEW]->enabled))
return 0;   /* already in requested state */
@@ -842,7 +848,7 @@ static int vidioc_g_fbuf(struct file *file, void *fh,
a->fmt.pixelformat = V4L2_PIX_FMT_YUV420;
a->fmt.bytesperline = preview_port->es.video.width;
a->fmt.sizeimage = (preview_port->es.video.width *
-  preview_port->es.video.height * 3)>>1;
+  preview_port->es.video.height * 3) >> 1;
a->fmt.colorspace = V4L2_COLORSPACE_SMPTE170M;
 
return 0;
@@ -958,8 +964,8 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void 
*priv,
f->fmt.pix.field = V4L2_FIELD_NONE;
 
v4l2_dbg(1, bcm2835_v4l2_debug, >v4l2_dev,
-   "Clipping/aligning %dx%d format %08X\n",
-   f->fmt.pix.width, f->fmt.pix.height, f->fmt.pix.pixelformat);
+"Clipping/aligning %dx%d format %08X\n",
+f->fmt.pix.width, f->fmt.pix.height, f->fmt.pix.pixelformat);
 
v4l_bound_align_image(>fmt.pix.width, MIN_WIDTH, dev->max_width, 1,
  >fmt.pix.height, MIN_HEIGHT, dev->max_height,
@@ -969,8 +975,8 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void 
*priv,
/* Image buffer has to be padded to allow for alignment, even though
 * we then remove that padding before delivering the buffer.
 */
-   

[PATCH 6/6] staging: bcm2835-v4l2: Apply spelling fixes from checkpatch.

[Eric Anholt]

Generated with checkpatch.pl --fix-inplace and git add -p out of the
results.

Signed-off-by: Eric Anholt 
---
 drivers/staging/media/platform/bcm2835/bcm2835-camera.c |  6 +++---
 drivers/staging/media/platform/bcm2835/mmal-vchiq.c | 12 ++--
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c 
b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
index 4541a363905c..105d88102cd9 100644
--- a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
+++ b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
@@ -1027,7 +1027,7 @@ static int mmal_setup_components(struct bm2835_mmal_dev 
*dev,
 
dev->capture.encode_component = NULL;
}
-   /* format dependant port setup */
+   /* format dependent port setup */
switch (mfmt->mmal_component) {
case MMAL_COMPONENT_CAMERA:
/* Make a further decision on port based on resolution */
@@ -1336,7 +1336,7 @@ int vidioc_enum_framesizes(struct file *file, void *fh,
return 0;
 }
 
-/* timeperframe is arbitrary and continous */
+/* timeperframe is arbitrary and continuous */
 static int vidioc_enum_frameintervals(struct file *file, void *priv,
  struct v4l2_frmivalenum *fival)
 {
@@ -1359,7 +1359,7 @@ static int vidioc_enum_frameintervals(struct file *file, 
void *priv,
 
fival->type = V4L2_FRMIVAL_TYPE_CONTINUOUS;
 
-   /* fill in stepwise (step=1.0 is requred by V4L2 spec) */
+   /* fill in stepwise (step=1.0 is required by V4L2 spec) */
fival->stepwise.min  = tpf_min;
fival->stepwise.max  = tpf_max;
fival->stepwise.step = (struct v4l2_fract) {1, 1};
diff --git a/drivers/staging/media/platform/bcm2835/mmal-vchiq.c 
b/drivers/staging/media/platform/bcm2835/mmal-vchiq.c
index cc968442adc4..f71dc3e9c3ae 100644
--- a/drivers/staging/media/platform/bcm2835/mmal-vchiq.c
+++ b/drivers/staging/media/platform/bcm2835/mmal-vchiq.c
@@ -239,7 +239,7 @@ static int bulk_receive(struct vchiq_mmal_instance 
*instance,
pr_err("buffer list empty trying to submit bulk receive\n");
 
/* todo: this is a serious error, we should never have
-* commited a buffer_to_host operation to the mmal
+* committed a buffer_to_host operation to the mmal
 * port without the buffer to back it up (underflow
 * handling) and there is no obvious way to deal with
 * this - how is the mmal servie going to react when
@@ -352,7 +352,7 @@ static int inline_receive(struct vchiq_mmal_instance 
*instance,
pr_err("buffer list empty trying to receive inline\n");
 
/* todo: this is a serious error, we should never have
-* commited a buffer_to_host operation to the mmal
+* committed a buffer_to_host operation to the mmal
 * port without the buffer to back it up (with
 * underflow handling) and there is no obvious way to
 * deal with this. Less bad than the bulk case as we
@@ -653,7 +653,7 @@ static void service_callback(void *param,
break;
 
default:
-   /* messages dependant on header context to complete */
+   /* messages dependent on header context to complete */
 
/* todo: the msg.context really ought to be sanity
 * checked before we just use it, afaict it comes back
@@ -780,7 +780,7 @@ static void dump_port_info(struct vchiq_mmal_port *port)
 port->current_buffer.num,
 port->current_buffer.size, port->current_buffer.alignment);
 
-   pr_debug("elementry stream: type:%d encoding:0x%x varient:0x%x\n",
+   pr_debug("elementry stream: type:%d encoding:0x%x variant:0x%x\n",
 port->format.type,
 port->format.encoding, port->format.encoding_variant);
 
@@ -883,7 +883,7 @@ static int port_info_set(struct vchiq_mmal_instance 
*instance,
return ret;
 }
 
-/* use port info get message to retrive port information */
+/* use port info get message to retrieve port information */
 static int port_info_get(struct vchiq_mmal_instance *instance,
 struct vchiq_mmal_port *port)
 {
@@ -923,7 +923,7 @@ static int port_info_get(struct vchiq_mmal_instance 
*instance,
/* copy the values out of the message */
port->handle = rmsg->u.port_info_get_reply.port_handle;
 
-   /* port type and index cached to use on port info set becuase
+   /* port type and index cached to use on port info set because
 * it does not use a port handle
 */
port->type = rmsg->u.port_info_get_reply.port_type;
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to 

[PATCH 4/6] staging: bcm2835-v4l2: Add a TODO file for improvements we need.

[Eric Anholt]

Signed-off-by: Eric Anholt 
---
 drivers/staging/media/platform/bcm2835/TODO | 39 +
 1 file changed, 39 insertions(+)
 create mode 100644 drivers/staging/media/platform/bcm2835/TODO

diff --git a/drivers/staging/media/platform/bcm2835/TODO 
b/drivers/staging/media/platform/bcm2835/TODO
new file mode 100644
index ..61a509992b9a
--- /dev/null
+++ b/drivers/staging/media/platform/bcm2835/TODO
@@ -0,0 +1,39 @@
+1) Support dma-buf memory management.
+
+In order to zero-copy import camera images into the 3D or display
+pipelines, we need to export our buffers through dma-buf so that the
+vc4 driver can import them.  This may involve bringing in the VCSM
+driver (which allows long-term management of regions of memory in the
+space that the VPU reserved and Linux otherwise doesn't have access
+to), or building some new protocol that allows VCSM-style management
+of Linux's CMA memory.
+
+2) Avoid extra copies for padding of images.
+
+We expose V4L2_PIX_FMT_* formats that have a specified stride/height
+padding in the V4L2 spec, but that padding doesn't match what the
+hardware can do.  If we exposed the native padding requirements
+through the V4L2 "multiplanar" formats, the firmware would have one
+less copy it needed to do.
+
+3) Port to ARM64
+
+The bulk_receive() does some manual cache flushing that are 32-bit ARM
+only, which we should convert to proper cross-platform APIs.
+
+4) Convert to be a platform driver.
+
+Right now when the module probes, it tries to initialize VCHI and
+errors out if it wasn't ready yet.  If bcm2835-v4l2 was built in, then
+VCHI generally isn't ready because it depends on both the firmware and
+mailbox drivers having already loaded.
+
+We should have VCHI create a platform device once it's initialized,
+and have this driver bind to it, so that we automatically load the
+v4l2 module after VCHI loads.
+
+5) Drop the gstreamer workaround.
+
+This was a temporary workaround for a bug that was fixed mid-2014, and
+we should remove it before stabilizing the driver.
+
-- 
2.11.0

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

[PATCH 3/6] staging: bcm2835-v4l2: Add a build system for the module.

[Eric Anholt]

This is derived from the downstream tree's build system, but with just
a single Kconfig option.

For now the driver only builds on 32-bit arm -- the aarch64 build
breaks due to the driver using arm-specific cache flushing functions.

Signed-off-by: Eric Anholt 
---
 drivers/staging/media/Kconfig   |  2 ++
 drivers/staging/media/Makefile  |  1 +
 drivers/staging/media/platform/bcm2835/Kconfig  | 10 ++
 drivers/staging/media/platform/bcm2835/Makefile | 11 +++
 4 files changed, 24 insertions(+)
 create mode 100644 drivers/staging/media/platform/bcm2835/Kconfig
 create mode 100644 drivers/staging/media/platform/bcm2835/Makefile

diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index ffb8fa72c3da..abd0e2d57c20 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -27,6 +27,8 @@ source "drivers/staging/media/davinci_vpfe/Kconfig"
 
 source "drivers/staging/media/omap4iss/Kconfig"
 
+source "drivers/staging/media/platform/bcm2835/Kconfig"
+
 source "drivers/staging/media/s5p-cec/Kconfig"
 
 # Keep LIRC at the end, as it has sub-menus
diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
index a28e82cf6447..dc89325c463d 100644
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_I2C_BCM2048)   += bcm2048/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC) += s5p-cec/
 obj-$(CONFIG_DVB_CXD2099)  += cxd2099/
 obj-$(CONFIG_LIRC_STAGING) += lirc/
+obj-$(CONFIG_VIDEO_BCM2835)+= platform/bcm2835/
 obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci_vpfe/
 obj-$(CONFIG_VIDEO_OMAP4)  += omap4iss/
 obj-$(CONFIG_VIDEO_STI_HDMI_CEC) += st-cec/
diff --git a/drivers/staging/media/platform/bcm2835/Kconfig 
b/drivers/staging/media/platform/bcm2835/Kconfig
new file mode 100644
index ..7c5245dc3225
--- /dev/null
+++ b/drivers/staging/media/platform/bcm2835/Kconfig
@@ -0,0 +1,10 @@
+config VIDEO_BCM2835
+   tristate "Broadcom BCM2835 camera driver"
+   depends on VIDEO_V4L2 && (ARCH_BCM2835 || COMPILE_TEST)
+   depends on BCM2835_VCHIQ
+   depends on ARM
+   select VIDEOBUF2_VMALLOC
+   help
+ Say Y here to enable camera host interface devices for
+ Broadcom BCM2835 SoC. This operates over the VCHIQ interface
+ to a service running on VideoCore.
diff --git a/drivers/staging/media/platform/bcm2835/Makefile 
b/drivers/staging/media/platform/bcm2835/Makefile
new file mode 100644
index ..d7900a5951a8
--- /dev/null
+++ b/drivers/staging/media/platform/bcm2835/Makefile
@@ -0,0 +1,11 @@
+bcm2835-v4l2-$(CONFIG_VIDEO_BCM2835) := \
+   bcm2835-camera.o \
+   controls.o \
+   mmal-vchiq.o
+
+obj-$(CONFIG_VIDEO_BCM2835) += bcm2835-v4l2.o
+
+ccflags-y += \
+   -Idrivers/staging/vc04_services \
+   -Idrivers/staging/vc04_services/interface/vcos/linuxkernel \
+   -D__VCCOREVER__=0x0400
-- 
2.11.0

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

[PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

[Eric Anholt]

Here's my first pass at importing the camera driver.  There's a bunch
of TODO left to it, most of which is documented, and the rest being
standard checkpatch fare.

Unfortunately, when I try modprobing it on my pi3, the USB network
device dies, consistently.  I'm not sure what's going on here yet, but
I'm going to keep working on some debug of it.  I've unfortunately
changed a lot of variables (pi3 vs pi2, upstream vs downstream, vchi's
updates while in staging, 4.9 vs 4.4), so I probably won't figure it
out today.

Note that the "Update the driver to the current VCHI API" patch will
conflict with the outstanding "Add vchi_queue_kernel_message and
vchi_queue_user_message" series, but the fix should be pretty obvious
when that lands.

I built this against 4.10-rc1, but a merge with staging-next was clean
and still built fine.

Eric Anholt (6):
  staging: Import the BCM2835 MMAL-based V4L2 camera driver.
  staging: bcm2835-v4l2: Update the driver to the current VCHI API.
  staging: bcm2835-v4l2: Add a build system for the module.
  staging: bcm2835-v4l2: Add a TODO file for improvements we need.
  staging: bcm2835-v4l2: Apply many whitespace fixes from checkpatch.
  staging: bcm2835-v4l2: Apply spelling fixes from checkpatch.

 drivers/staging/media/Kconfig  |2 +
 drivers/staging/media/Makefile |1 +
 drivers/staging/media/platform/bcm2835/Kconfig |   10 +
 drivers/staging/media/platform/bcm2835/Makefile|   11 +
 drivers/staging/media/platform/bcm2835/TODO|   39 +
 .../media/platform/bcm2835/bcm2835-camera.c| 2024 
 .../media/platform/bcm2835/bcm2835-camera.h|  145 ++
 drivers/staging/media/platform/bcm2835/controls.c  | 1335 +
 .../staging/media/platform/bcm2835/mmal-common.h   |   53 +
 .../media/platform/bcm2835/mmal-encodings.h|  127 ++
 .../media/platform/bcm2835/mmal-msg-common.h   |   50 +
 .../media/platform/bcm2835/mmal-msg-format.h   |   81 +
 .../staging/media/platform/bcm2835/mmal-msg-port.h |  107 ++
 drivers/staging/media/platform/bcm2835/mmal-msg.h  |  404 
 .../media/platform/bcm2835/mmal-parameters.h   |  689 +++
 .../staging/media/platform/bcm2835/mmal-vchiq.c| 1920 +++
 .../staging/media/platform/bcm2835/mmal-vchiq.h|  178 ++
 17 files changed, 7176 insertions(+)
 create mode 100644 drivers/staging/media/platform/bcm2835/Kconfig
 create mode 100644 drivers/staging/media/platform/bcm2835/Makefile
 create mode 100644 drivers/staging/media/platform/bcm2835/TODO
 create mode 100644 drivers/staging/media/platform/bcm2835/bcm2835-camera.c
 create mode 100644 drivers/staging/media/platform/bcm2835/bcm2835-camera.h
 create mode 100644 drivers/staging/media/platform/bcm2835/controls.c
 create mode 100644 drivers/staging/media/platform/bcm2835/mmal-common.h
 create mode 100644 drivers/staging/media/platform/bcm2835/mmal-encodings.h
 create mode 100644 drivers/staging/media/platform/bcm2835/mmal-msg-common.h
 create mode 100644 drivers/staging/media/platform/bcm2835/mmal-msg-format.h
 create mode 100644 drivers/staging/media/platform/bcm2835/mmal-msg-port.h
 create mode 100644 drivers/staging/media/platform/bcm2835/mmal-msg.h
 create mode 100644 drivers/staging/media/platform/bcm2835/mmal-parameters.h
 create mode 100644 drivers/staging/media/platform/bcm2835/mmal-vchiq.c
 create mode 100644 drivers/staging/media/platform/bcm2835/mmal-vchiq.h

-- 
2.11.0

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

[PATCH 2/6] staging: bcm2835-v4l2: Update the driver to the current VCHI API.

[Eric Anholt]

49bec49fd7f2 ("staging: vc04_services: remove vchiq_copy_from_user")
removed the flags/msg_handle arguments, which were unused, and pushed
the implementation of copying using memcpy vs copy_from_user to the
caller.

Signed-off-by: Eric Anholt 
---
 drivers/staging/media/platform/bcm2835/mmal-vchiq.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/platform/bcm2835/mmal-vchiq.c 
b/drivers/staging/media/platform/bcm2835/mmal-vchiq.c
index 781322542d5a..24bd2948136c 100644
--- a/drivers/staging/media/platform/bcm2835/mmal-vchiq.c
+++ b/drivers/staging/media/platform/bcm2835/mmal-vchiq.c
@@ -378,6 +378,14 @@ static int inline_receive(struct vchiq_mmal_instance 
*instance,
return 0;
 }
 
+static ssize_t mmal_memcpy_wrapper(void *src, void *dst,
+  size_t offset, size_t size)
+{
+   memcpy(dst + offset, src + offset, size);
+
+   return size;
+}
+
 /* queue the buffer availability with MMAL_MSG_TYPE_BUFFER_FROM_HOST */
 static int
 buffer_from_host(struct vchiq_mmal_instance *instance,
@@ -442,10 +450,9 @@ buffer_from_host(struct vchiq_mmal_instance *instance,
 
vchi_service_use(instance->handle);
 
-   ret = vchi_msg_queue(instance->handle, ,
+   ret = vchi_msg_queue(instance->handle, mmal_memcpy_wrapper, ,
 sizeof(struct mmal_msg_header) +
-sizeof(m.u.buffer_from_host),
-VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL);
+sizeof(m.u.buffer_from_host));
 
if (ret != 0) {
release_msg_context(msg_context);
@@ -731,9 +738,9 @@ static int send_synchronous_mmal_msg(struct 
vchiq_mmal_instance *instance,
vchi_service_use(instance->handle);
 
ret = vchi_msg_queue(instance->handle,
+mmal_memcpy_wrapper,
 msg,
-sizeof(struct mmal_msg_header) + payload_len,
-VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL);
+sizeof(struct mmal_msg_header) + payload_len);
 
vchi_service_release(instance->handle);
 
-- 
2.11.0

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

[GIT PULL 4.11] si2168 ber and ucb statistics

[Antti Palosaari]

The following changes since commit d183e4efcae8d88a2f252e546978658ca6d273cc:

  [media] v4l: tvp5150: Add missing break in set control handler 
(2016-12-12 07:49:58 -0200)


are available in the git repository at:

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

for you to fetch changes up to 7a6d7b07e36a8161b56924d7e18a00f1b7e2436a:

  si2168: implement ucb statistics (2016-12-19 19:55:15 +0200)


Antti Palosaari (2):
  si2168: implement ber statistics
  si2168: implement ucb statistics

 drivers/media/dvb-frontends/si2168.c  | 70 
--

 drivers/media/dvb-frontends/si2168_priv.h |  1 +
 2 files changed, 69 insertions(+), 2 deletions(-)

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

[PATCH 1/2] MAINTAINERS: remove hd29l2

[Antti Palosaari]

Drop unused driver.

Signed-off-by: Antti Palosaari 
---
 MAINTAINERS | 10 --
 1 file changed, 10 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 52cc077..761a3cc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5595,16 +5595,6 @@ L:   linux-par...@vger.kernel.org
 S: Maintained
 F: sound/parisc/harmony.*
 
-HD29L2 MEDIA DRIVER
-M: Antti Palosaari 
-L: linux-media@vger.kernel.org
-W: https://linuxtv.org
-W: http://palosaari.fi/linux/
-Q: http://patchwork.linuxtv.org/project/linux-media/list/
-T: git git://linuxtv.org/anttip/media_tree.git
-S: Maintained
-F: drivers/media/dvb-frontends/hd29l2*
-
 HEWLETT PACKARD ENTERPRISE ILO NMI WATCHDOG DRIVER
 M: Brian Boylston 
 S: Supported
-- 
http://palosaari.fi/

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

[PATCH 2/2] hd29l2: remove unused driver

[Antti Palosaari]

Remove unused demod driver. Device that used it never went public.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-frontends/Kconfig   |   7 -
 drivers/media/dvb-frontends/Makefile  |   1 -
 drivers/media/dvb-frontends/hd29l2.c  | 870 --
 drivers/media/dvb-frontends/hd29l2.h  |  65 ---
 drivers/media/dvb-frontends/hd29l2_priv.h | 301 ---
 5 files changed, 1244 deletions(-)
 delete mode 100644 drivers/media/dvb-frontends/hd29l2.c
 delete mode 100644 drivers/media/dvb-frontends/hd29l2.h
 delete mode 100644 drivers/media/dvb-frontends/hd29l2_priv.h

diff --git a/drivers/media/dvb-frontends/Kconfig 
b/drivers/media/dvb-frontends/Kconfig
index c841fa1..1221e2a 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -447,13 +447,6 @@ config DVB_EC100
help
  Say Y when you want to support this frontend.
 
-config DVB_HD29L2
-   tristate "HDIC HD29L2"
-   depends on DVB_CORE && I2C
-   default m if !MEDIA_SUBDRV_AUTOSELECT
-   help
- Say Y when you want to support this frontend.
-
 config DVB_STV0367
tristate "ST STV0367 based"
depends on DVB_CORE && I2C
diff --git a/drivers/media/dvb-frontends/Makefile 
b/drivers/media/dvb-frontends/Makefile
index 93921a4..bfed0f63 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -99,7 +99,6 @@ obj-$(CONFIG_DVB_MN88472) += mn88472.o
 obj-$(CONFIG_DVB_MN88473) += mn88473.o
 obj-$(CONFIG_DVB_ISL6423) += isl6423.o
 obj-$(CONFIG_DVB_EC100) += ec100.o
-obj-$(CONFIG_DVB_HD29L2) += hd29l2.o
 obj-$(CONFIG_DVB_DS3000) += ds3000.o
 obj-$(CONFIG_DVB_TS2020) += ts2020.o
 obj-$(CONFIG_DVB_MB86A16) += mb86a16.o
diff --git a/drivers/media/dvb-frontends/hd29l2.c 
b/drivers/media/dvb-frontends/hd29l2.c
deleted file mode 100644
index 8b53633..000
--- a/drivers/media/dvb-frontends/hd29l2.c
+++ /dev/null
@@ -1,870 +0,0 @@
-/*
- * HDIC HD29L2 DMB-TH demodulator driver
- *
- * Copyright (C) 2011 Metropolia University of Applied Sciences, Electria R
- *
- * Author: Antti Palosaari 
- *
- *This program is free software; you can redistribute it and/or modify
- *it under the terms of the GNU General Public License as published by
- *the Free Software Foundation; either version 2 of the License, or
- *(at your option) any later version.
- *
- *This program is distributed in the hope that it will be useful,
- *but WITHOUT ANY WARRANTY; without even the implied warranty of
- *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *GNU General Public License for more details.
- *
- *You should have received a copy of the GNU General Public License
- *along with this program; if not, write to the Free Software
- *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#include "hd29l2_priv.h"
-
-#define HD29L2_MAX_LEN (3)
-
-/* write multiple registers */
-static int hd29l2_wr_regs(struct hd29l2_priv *priv, u8 reg, u8 *val, int len)
-{
-   int ret;
-   u8 buf[2 + HD29L2_MAX_LEN];
-   struct i2c_msg msg[1] = {
-   {
-   .addr = priv->cfg.i2c_addr,
-   .flags = 0,
-   .len = 2 + len,
-   .buf = buf,
-   }
-   };
-
-   if (len > HD29L2_MAX_LEN)
-   return -EINVAL;
-   buf[0] = 0x00;
-   buf[1] = reg;
-   memcpy([2], val, len);
-
-   ret = i2c_transfer(priv->i2c, msg, 1);
-   if (ret == 1) {
-   ret = 0;
-   } else {
-   dev_warn(>i2c->dev,
-   "%s: i2c wr failed=%d reg=%02x len=%d\n",
-   KBUILD_MODNAME, ret, reg, len);
-   ret = -EREMOTEIO;
-   }
-
-   return ret;
-}
-
-/* read multiple registers */
-static int hd29l2_rd_regs(struct hd29l2_priv *priv, u8 reg, u8 *val, int len)
-{
-   int ret;
-   u8 buf[2] = { 0x00, reg };
-   struct i2c_msg msg[2] = {
-   {
-   .addr = priv->cfg.i2c_addr,
-   .flags = 0,
-   .len = 2,
-   .buf = buf,
-   }, {
-   .addr = priv->cfg.i2c_addr,
-   .flags = I2C_M_RD,
-   .len = len,
-   .buf = val,
-   }
-   };
-
-   ret = i2c_transfer(priv->i2c, msg, 2);
-   if (ret == 2) {
-   ret = 0;
-   } else {
-   dev_warn(>i2c->dev,
-   "%s: i2c rd failed=%d reg=%02x len=%d\n",
-   KBUILD_MODNAME, ret, reg, len);
-   ret = -EREMOTEIO;
-   }
-
-   return ret;
-}
-
-/* write single register */
-static int hd29l2_wr_reg(struct hd29l2_priv *priv, u8 reg, u8 val)
-{
-   return hd29l2_wr_regs(priv, reg, , 1);
-}
-
-/* read 

[PATCH v3 3/7] zd1301_demod: ZyDAS ZD1301 DVB-T demodulator driver

[Antti Palosaari]

ZyDAS ZD1301 is chip having USB interface and DVB-T demodulator
integrated. This driver is for demodulator part.
Driver is very reduced, just basic demodulator functionality, no
statistics at all. It registers as a platform driver to driver core.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-frontends/Kconfig|   7 +
 drivers/media/dvb-frontends/Makefile   |   1 +
 drivers/media/dvb-frontends/zd1301_demod.c | 551 +
 drivers/media/dvb-frontends/zd1301_demod.h |  55 +++
 4 files changed, 614 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/zd1301_demod.c
 create mode 100644 drivers/media/dvb-frontends/zd1301_demod.h

diff --git a/drivers/media/dvb-frontends/Kconfig 
b/drivers/media/dvb-frontends/Kconfig
index c841fa1..043b089 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -513,6 +513,13 @@ config DVB_AS102_FE
depends on DVB_CORE
default DVB_AS102
 
+config DVB_ZD1301_DEMOD
+   tristate "ZyDAS ZD1301"
+   depends on DVB_CORE && I2C
+   default m if !MEDIA_SUBDRV_AUTOSELECT
+   help
+ Say Y when you want to support this frontend.
+
 config DVB_GP8PSK_FE
tristate
depends on DVB_CORE
diff --git a/drivers/media/dvb-frontends/Makefile 
b/drivers/media/dvb-frontends/Makefile
index 93921a4..1ccdf5d 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -126,3 +126,4 @@ obj-$(CONFIG_DVB_TC90522) += tc90522.o
 obj-$(CONFIG_DVB_HORUS3A) += horus3a.o
 obj-$(CONFIG_DVB_ASCOT2E) += ascot2e.o
 obj-$(CONFIG_DVB_HELENE) += helene.o
+obj-$(CONFIG_DVB_ZD1301_DEMOD) += zd1301_demod.o
diff --git a/drivers/media/dvb-frontends/zd1301_demod.c 
b/drivers/media/dvb-frontends/zd1301_demod.c
new file mode 100644
index 000..fcf5f69
--- /dev/null
+++ b/drivers/media/dvb-frontends/zd1301_demod.c
@@ -0,0 +1,551 @@
+/*
+ * ZyDAS ZD1301 driver (demodulator)
+ *
+ * Copyright (C) 2015 Antti Palosaari 
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *GNU General Public License for more details.
+ */
+
+#include "zd1301_demod.h"
+
+static u8 zd1301_demod_gain = 0x38;
+module_param_named(gain, zd1301_demod_gain, byte, 0644);
+MODULE_PARM_DESC(gain, "gain (value: 0x00 - 0x70, default: 0x38)");
+
+struct zd1301_demod_dev {
+   struct platform_device *pdev;
+   struct dvb_frontend frontend;
+   struct i2c_adapter adapter;
+   u8 gain;
+};
+
+static int zd1301_demod_wreg(struct zd1301_demod_dev *dev, u16 reg, u8 val)
+{
+   struct platform_device *pdev = dev->pdev;
+   struct zd1301_demod_platform_data *pdata = pdev->dev.platform_data;
+
+   return pdata->reg_write(pdata->reg_priv, reg, val);
+}
+
+static int zd1301_demod_rreg(struct zd1301_demod_dev *dev, u16 reg, u8 *val)
+{
+   struct platform_device *pdev = dev->pdev;
+   struct zd1301_demod_platform_data *pdata = pdev->dev.platform_data;
+
+   return pdata->reg_read(pdata->reg_priv, reg, val);
+}
+
+static int zd1301_demod_set_frontend(struct dvb_frontend *fe)
+{
+   struct zd1301_demod_dev *dev = fe->demodulator_priv;
+   struct platform_device *pdev = dev->pdev;
+   struct dtv_frontend_properties *c = >dtv_property_cache;
+   int ret;
+   u32 if_frequency;
+   u8 r6a50_val;
+
+   dev_dbg(>dev, "frequency=%u bandwidth_hz=%u\n",
+   c->frequency, c->bandwidth_hz);
+
+   /* Program tuner */
+   if (fe->ops.tuner_ops.set_params &&
+   fe->ops.tuner_ops.get_if_frequency) {
+   ret = fe->ops.tuner_ops.set_params(fe);
+   if (ret)
+   goto err;
+   ret = fe->ops.tuner_ops.get_if_frequency(fe, _frequency);
+   if (ret)
+   goto err;
+   } else {
+   ret = -EINVAL;
+   goto err;
+   }
+
+   dev_dbg(>dev, "if_frequency=%u\n", if_frequency);
+   if (if_frequency != 3615) {
+   ret = -EINVAL;
+   goto err;
+   }
+
+   switch (c->bandwidth_hz) {
+   case 600:
+   r6a50_val = 0x78;
+   break;
+   case 700:
+   r6a50_val = 0x68;
+   break;
+   case 800:
+   r6a50_val = 0x58;
+   break;
+   default:
+   ret = -EINVAL;
+   goto err;
+   }
+
+   ret = zd1301_demod_wreg(dev, 0x6a60, 0x11);
+   if (ret)
+   goto err;
+   ret = 

[PATCH v3 6/7] MAINTAINERS: add zd1301 DVB USB interface driver

[Antti Palosaari]

DVB USB interface driver for ZyDAS ZD1301 chip.

Signed-off-by: Antti Palosaari 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 26ae0ac..101be59 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13389,6 +13389,15 @@ Q: 
https://patchwork.linuxtv.org/project/linux-media/list/
 S: Maintained
 F: drivers/media/dvb-frontends/zd1301_demod*
 
+ZD1301 MEDIA DRIVER
+M: Antti Palosaari 
+L: linux-media@vger.kernel.org
+W: https://linuxtv.org/
+W: http://palosaari.fi/linux/
+Q: https://patchwork.linuxtv.org/project/linux-media/list/
+S: Maintained
+F: drivers/media/usb/dvb-usb-v2/zd1301*
+
 ZPOOL COMPRESSED PAGE STORAGE API
 M: Dan Streetman 
 L: linux...@kvack.org
-- 
http://palosaari.fi/

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

[PATCH v3 7/7] mt2060: implement sleep

[Antti Palosaari]

I saw from ZyDAS ZD1301 sniffs it sets chip sleeping by using
REG_MISC_CTRL. That has very huge effect for power management, around
0.9W. Sleep is still disabled for all the old hardware just to avoid
possible regression as meaning of register bits are unknown.

I tested it also with some other devices and it seems to be working,
but I still consider it to be too risky to change it default.

Signed-off-by: Antti Palosaari 
---
 drivers/media/tuners/mt2060.c  | 25 +++--
 drivers/media/tuners/mt2060_priv.h |  8 
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/mt2060.c b/drivers/media/tuners/mt2060.c
index 9775ded..6d404d5 100644
--- a/drivers/media/tuners/mt2060.c
+++ b/drivers/media/tuners/mt2060.c
@@ -317,9 +317,16 @@ static int mt2060_init(struct dvb_frontend *fe)
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1); /* open i2c_gate */
 
+   if (priv->sleep) {
+   ret = mt2060_writereg(priv, REG_MISC_CTRL, 0x20);
+   if (ret)
+   goto err_i2c_gate_ctrl;
+   }
+
ret = mt2060_writereg(priv, REG_VGAG,
  (priv->cfg->clock_out << 6) | 0x33);
 
+err_i2c_gate_ctrl:
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0); /* close i2c_gate */
 
@@ -336,7 +343,13 @@ static int mt2060_sleep(struct dvb_frontend *fe)
 
ret = mt2060_writereg(priv, REG_VGAG,
  (priv->cfg->clock_out << 6) | 0x30);
+   if (ret)
+   goto err_i2c_gate_ctrl;
+
+   if (priv->sleep)
+   ret = mt2060_writereg(priv, REG_MISC_CTRL, 0xe8);
 
+err_i2c_gate_ctrl:
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0); /* close i2c_gate */
 
@@ -439,6 +452,7 @@ static int mt2060_probe(struct i2c_client *client,
dev->if1_freq = pdata->if1 ? pdata->if1 : 1220;
dev->client = client;
dev->i2c_max_regs = pdata->i2c_write_max ? pdata->i2c_write_max - 1 : 
~0;
+   dev->sleep = true;
 
ret = mt2060_readreg(dev, REG_PART_REV, _id);
if (ret) {
@@ -453,14 +467,21 @@ static int mt2060_probe(struct i2c_client *client,
goto err;
}
 
+   /* Power on, calibrate, sleep */
+   ret = mt2060_writereg(dev, REG_MISC_CTRL, 0x20);
+   if (ret)
+   goto err;
+   mt2060_calibrate(dev);
+   ret = mt2060_writereg(dev, REG_MISC_CTRL, 0xe8);
+   if (ret)
+   goto err;
+
dev_info(>dev, "Microtune MT2060 successfully identified\n");
memcpy(>ops.tuner_ops, _tuner_ops, 
sizeof(fe->ops.tuner_ops));
fe->ops.tuner_ops.release = NULL;
fe->tuner_priv = dev;
i2c_set_clientdata(client, dev);
 
-   mt2060_calibrate(dev);
-
return 0;
 err:
dev_dbg(>dev, "failed=%d\n", ret);
diff --git a/drivers/media/tuners/mt2060_priv.h 
b/drivers/media/tuners/mt2060_priv.h
index f0fdb83..c0dac80 100644
--- a/drivers/media/tuners/mt2060_priv.h
+++ b/drivers/media/tuners/mt2060_priv.h
@@ -102,6 +102,14 @@ struct mt2060_priv {
u32 frequency;
u16 if1_freq;
u8  fmfreq;
+
+   /*
+* Use REG_MISC_CTRL register for sleep. That drops sleep power usage
+* about 0.9W (huge!). Register bit meanings are unknown, so let it be
+* disabled by default to avoid possible regression. Convert driver to
+* i2c model in order to enable it.
+*/
+   bool sleep;
 };
 
 #endif
-- 
http://palosaari.fi/

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

[PATCH v3 5/7] zd1301: ZyDAS ZD1301 DVB USB interface driver

[Antti Palosaari]

ZyDAS ZD1301 is chip having USB interface and DVB-T demodulator
integrated. This driver is for USB interface part.

Device has USB ID 0ace:13a1. Used tuner is MT2060.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-core/dvb-usb-ids.h  |   1 +
 drivers/media/usb/dvb-usb-v2/Kconfig  |   8 +
 drivers/media/usb/dvb-usb-v2/Makefile |   3 +
 drivers/media/usb/dvb-usb-v2/zd1301.c | 294 ++
 4 files changed, 306 insertions(+)
 create mode 100644 drivers/media/usb/dvb-usb-v2/zd1301.c

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index 779f422..55acd11 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -73,6 +73,7 @@
 #define USB_VID_GIGABYTE   0x1044
 #define USB_VID_YUAN   0x1164
 #define USB_VID_XTENSIONS  0x1ae7
+#define USB_VID_ZYDAS  0x0ace
 #define USB_VID_HUMAX_COEX 0x10b9
 #define USB_VID_7740x7a69
 #define USB_VID_EVOLUTEPC  0x1e59
diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
b/drivers/media/usb/dvb-usb-v2/Kconfig
index 524533d..0e4944b 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -156,3 +156,11 @@ config DVB_USB_DVBSKY
select DVB_SP2 if MEDIA_SUBDRV_AUTOSELECT
help
  Say Y here to support the USB receivers from DVBSky.
+
+config DVB_USB_ZD1301
+   tristate "ZyDAS ZD1301"
+   depends on DVB_USB_V2
+   select DVB_ZD1301_DEMOD if MEDIA_SUBDRV_AUTOSELECT
+   select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
+   help
+ Say Y here to support the ZyDAS ZD1301 DVB USB receiver.
diff --git a/drivers/media/usb/dvb-usb-v2/Makefile 
b/drivers/media/usb/dvb-usb-v2/Makefile
index f10d4df..969f68e 100644
--- a/drivers/media/usb/dvb-usb-v2/Makefile
+++ b/drivers/media/usb/dvb-usb-v2/Makefile
@@ -40,6 +40,9 @@ obj-$(CONFIG_DVB_USB_RTL28XXU) += dvb-usb-rtl28xxu.o
 dvb-usb-dvbsky-objs := dvbsky.o
 obj-$(CONFIG_DVB_USB_DVBSKY) += dvb-usb-dvbsky.o
 
+dvb-usb-zd1301-objs := zd1301.o
+obj-$(CONFIG_DVB_USB_ZD1301) += zd1301.o
+
 ccflags-y += -I$(srctree)/drivers/media/dvb-core
 ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
 ccflags-y += -I$(srctree)/drivers/media/tuners
diff --git a/drivers/media/usb/dvb-usb-v2/zd1301.c 
b/drivers/media/usb/dvb-usb-v2/zd1301.c
new file mode 100644
index 000..563e50c
--- /dev/null
+++ b/drivers/media/usb/dvb-usb-v2/zd1301.c
@@ -0,0 +1,294 @@
+/*
+ * ZyDAS ZD1301 driver (USB interface)
+ *
+ * Copyright (C) 2015 Antti Palosaari 
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *GNU General Public License for more details.
+ */
+
+#include "dvb_usb.h"
+#include "zd1301_demod.h"
+#include "mt2060.h"
+#include 
+#include 
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+struct zd1301_dev {
+   #define BUF_LEN 8
+   u8 buf[BUF_LEN]; /* bulk USB control message */
+   struct zd1301_demod_platform_data demod_pdata;
+   struct mt2060_platform_data mt2060_pdata;
+   struct platform_device *platform_device_demod;
+   struct i2c_client *i2c_client_tuner;
+};
+
+static int zd1301_ctrl_msg(struct dvb_usb_device *d, const u8 *wbuf,
+  unsigned int wlen, u8 *rbuf, unsigned int rlen)
+{
+   struct zd1301_dev *dev = d_to_priv(d);
+   struct usb_interface *intf = d->intf;
+   int ret, actual_length;
+
+   mutex_lock(>usb_mutex);
+
+   memcpy(>buf, wbuf, wlen);
+
+   dev_dbg(>dev, ">>> %*ph\n", wlen, dev->buf);
+
+   ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev, 0x04), dev->buf,
+  wlen, _length, 1000);
+   if (ret) {
+   dev_err(>dev, "1st usb_bulk_msg() failed %d\n", ret);
+   goto err_mutex_unlock;
+   }
+
+   if (rlen) {
+   ret = usb_bulk_msg(d->udev, usb_rcvbulkpipe(d->udev, 0x83),
+  dev->buf, rlen, _length, 1000);
+   if (ret) {
+   dev_err(>dev,
+   "2nd usb_bulk_msg() failed %d\n", ret);
+   goto err_mutex_unlock;
+   }
+
+   dev_dbg(>dev, "<<< %*ph\n", actual_length, dev->buf);
+
+   if (actual_length != rlen) {
+   /*
+* Chip replies often with 3 byte len stub. On that case
+

[PATCH v3 4/7] MAINTAINERS: add zd1301_demod driver

[Antti Palosaari]

DVB-T demodulator driver for ZyDAS ZD1301 chip.

Signed-off-by: Antti Palosaari 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 52cc077..26ae0ac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13380,6 +13380,15 @@ L: zd1211-d...@lists.sourceforge.net 
(subscribers-only)
 S: Maintained
 F: drivers/net/wireless/zydas/zd1211rw/
 
+ZD1301_DEMOD MEDIA DRIVER
+M: Antti Palosaari 
+L: linux-media@vger.kernel.org
+W: https://linuxtv.org/
+W: http://palosaari.fi/linux/
+Q: https://patchwork.linuxtv.org/project/linux-media/list/
+S: Maintained
+F: drivers/media/dvb-frontends/zd1301_demod*
+
 ZPOOL COMPRESSED PAGE STORAGE API
 M: Dan Streetman 
 L: linux...@kvack.org
-- 
http://palosaari.fi/

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

[PATCH v3 1/7] mt2060: add i2c bindings

[Antti Palosaari]

Add proper i2c driver model bindings.

Signed-off-by: Antti Palosaari 
---
 drivers/media/tuners/mt2060.c  | 83 ++
 drivers/media/tuners/mt2060.h  | 20 +
 drivers/media/tuners/mt2060_priv.h |  2 +
 3 files changed, 105 insertions(+)

diff --git a/drivers/media/tuners/mt2060.c b/drivers/media/tuners/mt2060.c
index 94077ea..dc4f9a9 100644
--- a/drivers/media/tuners/mt2060.c
+++ b/drivers/media/tuners/mt2060.c
@@ -396,6 +396,89 @@ struct dvb_frontend * mt2060_attach(struct dvb_frontend 
*fe, struct i2c_adapter
 }
 EXPORT_SYMBOL(mt2060_attach);
 
+static int mt2060_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct mt2060_platform_data *pdata = client->dev.platform_data;
+   struct dvb_frontend *fe;
+   struct mt2060_priv *dev;
+   int ret;
+   u8 chip_id;
+
+   dev_dbg(>dev, "\n");
+
+   if (!pdata) {
+   dev_err(>dev, "Cannot proceed without platform data\n");
+   ret = -EINVAL;
+   goto err;
+   }
+
+   dev = devm_kzalloc(>dev, sizeof(*dev), GFP_KERNEL);
+   if (!dev) {
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   fe = pdata->dvb_frontend;
+   dev->config.i2c_address = client->addr;
+   dev->config.clock_out = pdata->clock_out;
+   dev->cfg = >config;
+   dev->i2c = client->adapter;
+   dev->if1_freq = pdata->if1 ? pdata->if1 : 1220;
+   dev->client = client;
+
+   ret = mt2060_readreg(dev, REG_PART_REV, _id);
+   if (ret) {
+   ret = -ENODEV;
+   goto err;
+   }
+
+   dev_dbg(>dev, "chip id=%02x\n", chip_id);
+
+   if (chip_id != PART_REV) {
+   ret = -ENODEV;
+   goto err;
+   }
+
+   dev_info(>dev, "Microtune MT2060 successfully identified\n");
+   memcpy(>ops.tuner_ops, _tuner_ops, 
sizeof(fe->ops.tuner_ops));
+   fe->ops.tuner_ops.release = NULL;
+   fe->tuner_priv = dev;
+   i2c_set_clientdata(client, dev);
+
+   mt2060_calibrate(dev);
+
+   return 0;
+err:
+   dev_dbg(>dev, "failed=%d\n", ret);
+   return ret;
+}
+
+static int mt2060_remove(struct i2c_client *client)
+{
+   dev_dbg(>dev, "\n");
+
+   return 0;
+}
+
+static const struct i2c_device_id mt2060_id_table[] = {
+   {"mt2060", 0},
+   {}
+};
+MODULE_DEVICE_TABLE(i2c, mt2060_id_table);
+
+static struct i2c_driver mt2060_driver = {
+   .driver = {
+   .name = "mt2060",
+   .suppress_bind_attrs = true,
+   },
+   .probe  = mt2060_probe,
+   .remove = mt2060_remove,
+   .id_table   = mt2060_id_table,
+};
+
+module_i2c_driver(mt2060_driver);
+
 MODULE_AUTHOR("Olivier DANET");
 MODULE_DESCRIPTION("Microtune MT2060 silicon tuner driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/media/tuners/mt2060.h b/drivers/media/tuners/mt2060.h
index 6efed35..05c0d55 100644
--- a/drivers/media/tuners/mt2060.h
+++ b/drivers/media/tuners/mt2060.h
@@ -25,6 +25,26 @@
 struct dvb_frontend;
 struct i2c_adapter;
 
+/*
+ * I2C address
+ * 0x60, ...
+ */
+
+/**
+ * struct mt2060_platform_data - Platform data for the mt2060 driver
+ * @clock_out: Clock output setting. 0 = off, 1 = CLK/4, 2 = CLK/2, 3 = CLK/1.
+ * @if1: First IF used [MHz]. 0 defaults to 1220.
+ * @dvb_frontend: DVB frontend.
+ */
+
+struct mt2060_platform_data {
+   u8 clock_out;
+   u16 if1;
+   struct dvb_frontend *dvb_frontend;
+};
+
+
+/* configuration struct for mt2060_attach() */
 struct mt2060_config {
u8 i2c_address;
u8 clock_out; /* 0 = off, 1 = CLK/4, 2 = CLK/2, 3 = CLK/1 */
diff --git a/drivers/media/tuners/mt2060_priv.h 
b/drivers/media/tuners/mt2060_priv.h
index 2b60de6..dfc4a06 100644
--- a/drivers/media/tuners/mt2060_priv.h
+++ b/drivers/media/tuners/mt2060_priv.h
@@ -95,6 +95,8 @@
 struct mt2060_priv {
struct mt2060_config *cfg;
struct i2c_adapter   *i2c;
+   struct i2c_client *client;
+   struct mt2060_config config;
 
u32 frequency;
u16 if1_freq;
-- 
http://palosaari.fi/

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

[PATCH v3 2/7] mt2060: add param to split long i2c writes

[Antti Palosaari]

Add configuration parameter to split long i2c writes as some I2C
adapters cannot write 10 bytes used as a one go.

Signed-off-by: Antti Palosaari 
---
 drivers/media/tuners/mt2060.c  | 21 +
 drivers/media/tuners/mt2060.h  |  3 +++
 drivers/media/tuners/mt2060_priv.h |  1 +
 3 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/media/tuners/mt2060.c b/drivers/media/tuners/mt2060.c
index dc4f9a9..9775ded 100644
--- a/drivers/media/tuners/mt2060.c
+++ b/drivers/media/tuners/mt2060.c
@@ -71,13 +71,24 @@ static int mt2060_writereg(struct mt2060_priv *priv, u8 
reg, u8 val)
 // Writes a set of consecutive registers
 static int mt2060_writeregs(struct mt2060_priv *priv,u8 *buf, u8 len)
 {
+   int rem, val_len;
+   u8 xfer_buf[16];
struct i2c_msg msg = {
-   .addr = priv->cfg->i2c_address, .flags = 0, .buf = buf, .len = 
len
+   .addr = priv->cfg->i2c_address, .flags = 0, .buf = xfer_buf
};
-   if (i2c_transfer(priv->i2c, , 1) != 1) {
-   printk(KERN_WARNING "mt2060 I2C write failed 
(len=%i)\n",(int)len);
-   return -EREMOTEIO;
+
+   for (rem = len - 1; rem > 0; rem -= priv->i2c_max_regs) {
+   val_len = min_t(int, rem, priv->i2c_max_regs);
+   msg.len = 1 + val_len;
+   xfer_buf[0] = buf[0] + len - 1 - rem;
+   memcpy(_buf[1], [1 + len - 1 - rem], val_len);
+
+   if (i2c_transfer(priv->i2c, , 1) != 1) {
+   printk(KERN_WARNING "mt2060 I2C write failed 
(len=%i)\n", val_len);
+   return -EREMOTEIO;
+   }
}
+
return 0;
 }
 
@@ -369,6 +380,7 @@ struct dvb_frontend * mt2060_attach(struct dvb_frontend 
*fe, struct i2c_adapter
priv->cfg  = cfg;
priv->i2c  = i2c;
priv->if1_freq = if1;
+   priv->i2c_max_regs = ~0;
 
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1); /* open i2c_gate */
@@ -426,6 +438,7 @@ static int mt2060_probe(struct i2c_client *client,
dev->i2c = client->adapter;
dev->if1_freq = pdata->if1 ? pdata->if1 : 1220;
dev->client = client;
+   dev->i2c_max_regs = pdata->i2c_write_max ? pdata->i2c_write_max - 1 : 
~0;
 
ret = mt2060_readreg(dev, REG_PART_REV, _id);
if (ret) {
diff --git a/drivers/media/tuners/mt2060.h b/drivers/media/tuners/mt2060.h
index 05c0d55..f0572ac 100644
--- a/drivers/media/tuners/mt2060.h
+++ b/drivers/media/tuners/mt2060.h
@@ -34,12 +34,15 @@ struct i2c_adapter;
  * struct mt2060_platform_data - Platform data for the mt2060 driver
  * @clock_out: Clock output setting. 0 = off, 1 = CLK/4, 2 = CLK/2, 3 = CLK/1.
  * @if1: First IF used [MHz]. 0 defaults to 1220.
+ * @i2c_write_max: Maximum number of bytes I2C adapter can write at once.
+ *  0 defaults to maximum.
  * @dvb_frontend: DVB frontend.
  */
 
 struct mt2060_platform_data {
u8 clock_out;
u16 if1;
+   unsigned int i2c_write_max:5;
struct dvb_frontend *dvb_frontend;
 };
 
diff --git a/drivers/media/tuners/mt2060_priv.h 
b/drivers/media/tuners/mt2060_priv.h
index dfc4a06..f0fdb83 100644
--- a/drivers/media/tuners/mt2060_priv.h
+++ b/drivers/media/tuners/mt2060_priv.h
@@ -98,6 +98,7 @@ struct mt2060_priv {
struct i2c_client *client;
struct mt2060_config config;
 
+   u8 i2c_max_regs;
u32 frequency;
u16 if1_freq;
u8  fmfreq;
-- 
http://palosaari.fi/

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

[patch] [media] add device IDs to ngene

[vdr]

Author: Helmut Auer 
Date:   Fri Jan 27 09:09:35 2017 +0100

Adding 2 device ID's to ngene driver.

Signed-off-by: Helmut Auer 

diff --git a/drivers/media/pci/ngene/ngene-cards.c
b/drivers/media/pci/ngene/ngene-cards.c
index 423e8c8..88815bd 100644
--- a/drivers/media/pci/ngene/ngene-cards.c
+++ b/drivers/media/pci/ngene/ngene-cards.c
@@ -753,6 +753,8 @@ static const struct ngene_info ngene_info_terratec = {
 //

 static const struct pci_device_id ngene_id_tbl[] = {
+   NGENE_ID(0x18c3, 0xab04, ngene_info_cineS2),
+   NGENE_ID(0x18c3, 0xab05, ngene_info_cineS2v5),
NGENE_ID(0x18c3, 0xabc3, ngene_info_cineS2),
NGENE_ID(0x18c3, 0xabc4, ngene_info_cineS2),
NGENE_ID(0x18c3, 0xdb01, ngene_info_satixS2),


--
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 0/5] davinci: VPIF: add DT support

[Kevin Hilman]

On Fri, Dec 16, 2016 at 4:49 PM, Kevin Hilman  wrote:
> Hans Verkuil  writes:
>
>> On 07/12/16 19:30, Kevin Hilman wrote:
>>> Prepare the groundwork for adding DT support for davinci VPIF drivers.
>>> This series does some fixups/cleanups and then adds the DT binding and
>>> DT compatible string matching for DT probing.
>>>
>>> The controversial part from previous versions around async subdev
>>> parsing, and specifically hard-coding the input/output routing of
>>> subdevs, has been left out of this series.  That part can be done as a
>>> follow-on step after agreement has been reached on the path forward.
>>> With this version, platforms can still use the VPIF capture/display
>>> drivers, but must provide platform_data for the subdevs and subdev
>>> routing.
>>>
>>> Tested video capture to memory on da850-lcdk board using composite
>>> input.
>>
>> Other than the comment for the first patch this series looks good.
>>
>> So once that's addressed I'll queue it up for 4.11.
>
> I've fixed that issue, and sent an update for just that patch in reply
> to the original.
>
> Thanks for the review,

Gentle ping on this series.

I'm still not seeing this series yet in linux-next, so am worried it
might not make it for v4.11.

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

Upside down webcam

[Hamidreza Jafari]

Hello,

https://linuxtv.org/wiki/index.php/Libv4l_Upside_Down_Webcams

The webcam is upside down and the solution does not work (as it did in
a previous Ubuntu version). On Kubuntu 16.10 with 4.8.0-34 kernel I
installed an app called Webcamoid to test and ran the following
commands:

$export LIBV4LCONTROL_FLAGS=3 &&
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libv4l/v4l1compat.so webcamoid &
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/TextField.qml:635:5:
QML TextInputWithHandles: Binding loop detected for property "text"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/TextField.qml:635:5:
QML TextInputWithHandles: Binding loop detected for property "text"
libv4l2: error setting pixformat: Device or resource busy
libv4l2: error setting pixformat: Device or resource busy
VideoCapture: No streams available.

$ v4l2-ctl -d /dev/video0 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Index : 0
Type : Video Capture
Pixel Format: 'YUYV'
Name : YUYV 4:2:2
Size: Discrete 640x480
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Size: Discrete 352x288
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Size: Discrete 320x240
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Size: Discrete 176x144
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.067s (15.000 fps)
Size: Discrete 160x120
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.067s (15.000 fps)

$v4l2-ctl --device=/dev/video0 --list-inputs
ioctl: VIDIOC_ENUMINPUT
Input : 0
Name : Camera 1
Type : 0x0002
Audioset : 0x
Tuner : 0x
Standard : 0x ()
Status : 0x (ok)
Capabilities: 0x (not defined)

How to fix the problem?

Hamid
با سپاس،
حمیدرضا جعفری
--
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

DRM Atomic property for color-space conversion

[Brian Starkey]

Hi,

We're looking to enable the per-plane color management hardware in
Mali-DP with atomic properties, which has sparked some conversation
around how to handle YCbCr formats.

As it stands today, it's assumed that a driver will implicitly "do the
right thing" to display a YCbCr buffer.

YCbCr data often uses different gamma curves and signal ranges (e.g.
BT.609, BT.701, BT.2020, studio range, full-range), so its desirable
to be able to explicitly control the YCbCr to RGB conversion process
from userspace.

We're proposing adding a "CSC" (color-space conversion) property to
control this - primarily per-plane for framebuffer->pipeline CSC, but
perhaps one per CRTC too for devices which have an RGB pipeline and
want to output in YUV to the display:

Name: "CSC"
Type: ENUM | ATOMIC;
Enum values (representative):
"default":
Same behaviour as now. "Some kind" of YCbCr->RGB conversion
for YCbCr buffers, bypass for RGB buffers
"disable":
Explicitly disable all colorspace conversion (i.e. use an
identity matrix).
"YCbCr to RGB: BT.709":
Only valid for YCbCr formats. CSC in accordance with BT.709
using [16..235] for (8-bit) luma values, and [16..240] for
8-bit chroma values. For 10-bit formats, the range limits are
multiplied by 4.
"YCbCr to RGB: BT.709 full-swing":
Only valid for YCbCr formats. CSC in accordance with BT.709,
but using the full range of each channel.
"YCbCr to RGB: Use CTM":*
Only valid for YCbCr formats. Use the matrix applied via the
plane's CTM property
"RGB to RGB: Use CTM":*
Only valid for RGB formats. Use the matrix applied via the
plane's CTM property
"Use CTM":*
Valid for any format. Use the matrix applied via the plane's
CTM property
... any other values for BT.601, BT.2020, RGB to YCbCr etc. etc. as
they are required.

*This assumes color-management is enabled per-plane. We're currently
working on patches to add this mostly to be able to use per-plane
degamma, but it would be analogous to the CRTC color-management code
and so also be able to expose a per-plane CTM property.

Our hardware implements the color-space conversion as a 3x3 matrix, so
we can implement a helper to convert a CSC enum value to a CTM matrix
for use by any hardware which has a programmable CSC matrix. For any
other hardware, the driver simply needs to map the enum value to
whatever selector bits are available.

It's expected that the "Use CTM" value(s) are *not* the common case,
and most of the time userspace will use one of the provided "standard"
enum values. The three different flavours of "Use CTM" allow us to
support hardware whose CSC hardware can only be used on e.g. YCbCr
data.

Drivers can of course filter the enum list to expose whichever subset
the hardware can support.

Having thrashed this out a bit on IRC with Ville, I think the above
approach is flexible enough to support at least Mali-DP and i915,
without burdening userspace any more than necessary. It also provides
the "default" behaviour which is backwards compatible, and allows for
fully custom CSC matrices where that is supported.

We can obviously implement this as a Mali-DP driver private property,
but it would be good to come up with something to go into the core if
possible.

I'd be happy to hear any feedback,

Thanks,
Brian
--
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: musb: isoc pkt loss with pwc

[Matwey V. Kornilov]

2016-11-01 23:33 GMT+03:00 Bin Liu :
> On Sat, Oct 15, 2016 at 10:25:42PM +0300, Matwey V. Kornilov wrote:
>
> [snip]
>
>> >>> > Which means without this commit your camera has been working without
>> >>> > issues, and this is a regression with this commit, right?
>> >>> >
>> >>>
>> >>> Right
>> >>
>> >> Okay, thanks for confirming.
>> >>
>> >> But we cannot just simply add this flag, as it breaks many other use
>> >> cases. I will continue work on this to find a solution which works on
>> >> all use cases.
>> >>
>> >
>> > Ok, thank you.
>> >
>>
>> Excuse me. Any news?
>
> Not solved yet. I used uvc class to exam the issue. uvc_video driver
> takes longer time to execute urb complete() on my platform. Using HCD_BH
> flag doesn't help, because urb->complete() was running with irq disabled
> because of the local_irq. Removing the local_irq as in [1] causes the
> system to lockup - uart and network stop responsing, so hard to debug
> for now.
>
> Right now, I added a workqueue in musb_host to handle urb->complete()
> with local_irq removed. It seems working fine in my test, but it is
> still a long way find the proper fix for upstream. I didn't have much
> time on this issue.
>
> Once I have a proper solution, I will post it to the mailing list.
>

Maybe I could help somehow?

> [1] http://marc.info/?l=linux-usb=147560701431267=2
>
> Regards,
> -Bin.
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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

[Ramesh Shanmugasundaram]

Hi Hans,

Many thanks for the response & comments.

> Subject: Re: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF
> binding
> 
> On 01/10/2017 10:31 AM, Ramesh Shanmugasundaram wrote:
> > Hi Laurent,
> >
> >> 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.
> 
> Are these properties actually going to be used by anyone? Just curious.

Yes. Each of this property should be set appropriately based on the master 
device it interfaces with. 

> 
> >>
> >> 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.
> >
> > Thanks for the clarifications. I have some questions.
> >
> > - Assuming two devices are interfaced with DRIF and they are represented
> using two endpoints, the control signal related properties of DRIF might
> still need to be same for both endpoints? For e.g. syncac-active cannot be
> different in both endpoints?
> 
> Usually that's the case, but HW designers are weird :-)
> 
> >
> > - I suppose "lsb-first", "dtdl" & "syncdl" may be defined per endpoint.
> However, h/w manual says same register values needs to be programmed for
> both the internal channels of a channel. Same with "syncmd" property.
> >
> > We could still define them as per endpoint property with a note that
> they need to be same. But I am not sure if that is what you intended?
> >
> >  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).
> >
> > OK. I will call it "sync-active".
> 
> That's better, yes.

Thanks.

> 
> >
> >  For the syncmd and lsb-first properties, it could also
> >> make sense to query them from the connected subdev 

[PATCH] [MEDIA] add device IDs to ngene

[vdr]

Author: Helmut Auer 
Date:   Fri Jan 27 09:09:35 2017 +0100

Adding 2 device ID's to ngene driver.

Signed-off-by: Helmut Auer 

diff --git a/drivers/media/pci/ngene/ngene-cards.c
b/drivers/media/pci/ngene/ngene-cards.c
index 423e8c8..88815bd 100644
--- a/drivers/media/pci/ngene/ngene-cards.c
+++ b/drivers/media/pci/ngene/ngene-cards.c
@@ -753,6 +753,8 @@ static const struct ngene_info ngene_info_terratec = {
 //

 static const struct pci_device_id ngene_id_tbl[] = {
+   NGENE_ID(0x18c3, 0xab04, ngene_info_cineS2),
+   NGENE_ID(0x18c3, 0xab05, ngene_info_cineS2v5),
NGENE_ID(0x18c3, 0xabc3, ngene_info_cineS2),
NGENE_ID(0x18c3, 0xabc4, ngene_info_cineS2),
NGENE_ID(0x18c3, 0xdb01, ngene_info_satixS2),


--
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] v4l: of: check for unique lanes in data-lanes and clock-lanes

[Sakari Ailus]

Hi Niklas,

On Thu, Jan 26, 2017 at 02:12:59PM +0100, Niklas Söderlund wrote:
> All lines in data-lanes and clock-lanes properties must be unique.
> Instead of drivers checking for this add it to the generic parser.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/v4l2-core/v4l2-of.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-of.c 
> b/drivers/media/v4l2-core/v4l2-of.c
> index 93b33681776c..1042db6bb996 100644
> --- a/drivers/media/v4l2-core/v4l2-of.c
> +++ b/drivers/media/v4l2-core/v4l2-of.c
> @@ -32,12 +32,19 @@ static int v4l2_of_parse_csi_bus(const struct device_node 
> *node,
>   prop = of_find_property(node, "data-lanes", NULL);
>   if (prop) {
>   const __be32 *lane = NULL;
> - unsigned int i;
> + unsigned int i, n;
>  
>   for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
>   lane = of_prop_next_u32(prop, lane, );
>   if (!lane)
>   break;
> + for (n = 0; n < i; n++) {
> + if (bus->data_lanes[n] == v) {
> + pr_warn("%s: duplicated lane %u in 
> data-lanes\n",
> + node->full_name, v);
> + return -EINVAL;
> + }
> + }

In some cases it's just the number of lanes that matter, not their order, as
the hardware cannot reorder them. I might still just print a warning but not
return an error. Same below.

Although then hardware that actually can reorder the lanes might have issues
if such a bug exists in DTB. Presumably the DTB would have been tested at
some point though.

>   bus->data_lanes[i] = v;
>   }
>   bus->num_data_lanes = i;
> @@ -63,6 +70,15 @@ static int v4l2_of_parse_csi_bus(const struct device_node 
> *node,
>   }
>  
>   if (!of_property_read_u32(node, "clock-lanes", )) {
> + unsigned int n;
> +
> + for (n = 0; n < bus->num_data_lanes; n++) {
> + if (bus->data_lanes[n] == v) {
> + pr_warn("%s: duplicated lane %u in 
> clock-lanes\n",
> + node->full_name, v);
> + return -EINVAL;
> + }
> + }
>   bus->clock_lane = v;
>   have_clk_lane = true;
>   }

-- 
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: [ANN] Media object lifetime management meeting report from Oslo

[Mauro Carvalho Chehab]

Hi Sakari/Hans/Laurent,

First of all, thanks for looking into those issues. Unfortunately, I was in
vacations, and were not able to be with you there for such discussions.

While I have a somewhat different view on some of the introductory points of 
this RFC, what really matters is the "proposal" part of it. So, based on the
experiments I did when I addressed the hotplug issues with the media
controller on USB drivers, I'm adding a few comments below.


Em Fri, 27 Jan 2017 12:08:22 +0200
Sakari Ailus  escreveu:

> Allocating struct media_devnode separately from struct media_device
> ---
> 
> The current codebase allocates struct media_devnode dynamically. This was
> done in order to reduce the time window during which unallocated kernel
> memory could be accessed. However, there is no specific need for such a
> separation as the entire data structure, including the media device which
> used to contain struct media_devnode, will have the same lifetime. Thus the
> struct media_devnode should be allocated as part of struct media_device.
> Later on, struct media_devnode may be merged with struct media_device if so
> decided.

There is one issue merging struct media_devnode at struct media_device.
The problem is that, if the same struct device is used for two different
APIs (like V4L2 and media_controller) , e. g. if the cdev parent points
to the same struct device, you may end by having a double free when the
device is unregistered on the second core. That's basically why 
currently struct cdev is at struct media_devnode: this way, it has its own
struct device.

IMHO, it also makes sense to embeed struct cdev at the V4L2 side, as I
detected some race issues at the V4L2 side when I ran the bind/unbind
race tests, when we tried to merge the snd-usb-audio MC support patch.
I remember Shuah reported something similar on that time.

> Allocating struct media_device dynamically
> --
> 
> Traditionally the media device has been allocated as part of drivers' own
> structures. This is certainly fine as such, but many drivers have allocated
> the driver private struct using the devm_() family of functions. This causes
> such memory to be released at the time of device removal rather than at the
> time when the memory is no longer accessible by e.g. user space processes or
> interrupt handlers. Besides the media device, the driver's own data
> structure is very likely to have the precisely same lifetime issue: it may
> also be accessed through IOCTLs after the device has been removed from the
> system.
> 
> Instead, the memory needs to be released as part of the release() callback
> of the media device which is called when the last reference to the media
> device is gone. Still, allocating the media device outside another
> containing driver specific struct will be required in some cases: sharing
> the media device mandates that. Implementing this can certainly be postponed
> until sharing the media device is otherwise supported as well.

The patches adding MC support for snd-usb-audio, pending since Kernel
4.7 (I guess) require such functionatilty. Last year, on the audio
summit, they asked about its status, as they're needing MC suppor there.

So, whatever solution taken, this should be part of the solution.

(c/c Shuah, as she is the one working on it)

> Lifetime of the media entities and related framework or driver objects
> ==
> 
> The media graph data structure is a complex data structure consisting of
> media graph objects that themselves may be either entities, links or pads.
> The media graph objects are allocated by various drivers and currently have
> a lifetime related to binding and unbinding of the related hardware. The
> current rules (i.e. acquiring the media graph lock for graph traversal) are
> not enough to properly support removing entities.
> 
> Instead, reference counting needs to be introduced for media entities and
> other objects that contain media entities. References must be acquired (or
> in some cases, borrowed) whenever a reference is held to an object. A
> release callback is used to release the memory allocation that contains an
> object when the last reference to the object has been put. For instance:
> 
>   struct media_entity {
>   ...
>   struct kref kref;
>   void (*release)(struct media_entity *entity);
>   };

The similar rationale is valid also for media interfaces and, on a
lesser extent, to pads and links.

So, instead, IMHO, the kref should be implemented at struct media_gobj,
with is inherited by all graph elements. I guess that handling it
there will avoid us to duplicate the same logic on different
places (e. g. interface and entity logic handling; links handling).

Btw, as you want to use OMAP3 as a reference driver, you should
implement 

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

[Hans Verkuil]

On 01/10/2017 10:31 AM, Ramesh Shanmugasundaram wrote:
> Hi Laurent,
> 
>> 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.

Are these properties actually going to be used by anyone? Just curious.

>>
>> 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.
> 
> Thanks for the clarifications. I have some questions.
> 
> - Assuming two devices are interfaced with DRIF and they are represented 
> using two endpoints, the control signal related properties of DRIF might 
> still need to be same for both endpoints? For e.g. syncac-active cannot be 
> different in both endpoints?

Usually that's the case, but HW designers are weird :-)

> 
> - I suppose "lsb-first", "dtdl" & "syncdl" may be defined per endpoint. 
> However, h/w manual says same register values needs to be programmed for both 
> the internal channels of a channel. Same with "syncmd" property.
> 
> We could still define them as per endpoint property with a note that they 
> need to be same. But I am not sure if that is what you intended?
> 
>  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).
> 
> OK. I will call it "sync-active".

That's better, yes.

> 
>  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 consider this unlikely. I wouldn't spend time on that as this can always be
done later.

> May I know in bit more detail about what you had in mind? Please correct me 
> if my understanding is wrong here but when I looked at the code
> 
> 1) mbus_config is part of subdev_video_ops only. I assume we don't want to 
> support this as part of tuner subdev. The next closest is 

Re: [ANN] Media object lifetime management meeting report from Oslo

[Sakari Ailus]

On Fri, Jan 27, 2017 at 12:08:22PM +0200, Sakari Ailus wrote:
> 2016-01-13

As the most attentive of you have noticed, this should have been 2017-01-13.
The New Year just doesn't always take effect immediately. :-)

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

[PATCH] [media] v4l2-async: failing functions shouldn't have side effects

[Tuukka Toivonen]

v4l2-async had several functions doing some operations and then
not undoing the operations in a failure situation. For example,
v4l2_async_test_notify() moved a subdev into notifier's done list
even if registering the subdev (v4l2_device_register_subdev) failed.
If the subdev was allocated and v4l2_async_register_subdev() called
from the driver's probe() function, as usually, the probe()
function freed the allocated subdev and returned a failure.
Nevertheless, the subdev was still left into the notifier's done
list, causing an access to already freed memory when the notifier
was later unregistered.

A hand-edited call trace leaving freed subdevs into the notifier:

v4l2_async_register_notifier(notifier, asd)
cameradrv_probe
 sd = devm_kzalloc()
 v4l2_async_register_subdev(sd)
  v4l2_async_test_notify(notifier, sd, asd)
   list_move(sd, >done)
   v4l2_device_register_subdev(notifier->v4l2_dev, sd)
cameradrv_registered(sd) -> fails
->v4l2_async_register_subdev returns failure
->cameradrv_probe returns failure
->devres frees the allocated sd
->sd was freed but it still remains in the notifier's list.

This patch fixes this and several other cases where a failing
function could leave nodes into a linked list while the caller
might free the node due to a failure.

Signed-off-by: Tuukka Toivonen 
---
 drivers/media/v4l2-core/v4l2-async.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 5bada20..82d7530 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -99,18 +99,11 @@ static int v4l2_async_test_notify(struct 
v4l2_async_notifier *notifier,
 {
int ret;
 
-   /* Remove from the waiting list */
-   list_del(>list);
-   sd->asd = asd;
-   sd->notifier = notifier;
-
if (notifier->bound) {
ret = notifier->bound(notifier, sd, asd);
if (ret < 0)
return ret;
}
-   /* Move from the global subdevice list to notifier's done */
-   list_move(>async_list, >done);
 
ret = v4l2_device_register_subdev(notifier->v4l2_dev, sd);
if (ret < 0) {
@@ -119,6 +112,14 @@ static int v4l2_async_test_notify(struct 
v4l2_async_notifier *notifier,
return ret;
}
 
+   /* Remove from the waiting list */
+   list_del(>list);
+   sd->asd = asd;
+   sd->notifier = notifier;
+
+   /* Move from the global subdevice list to notifier's done */
+   list_move(>async_list, >done);
+
if (list_empty(>waiting) && notifier->complete)
return notifier->complete(notifier);
 
@@ -168,9 +169,6 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
 
mutex_lock(_lock);
 
-   /* Keep also completed notifiers on the list */
-   list_add(>list, _list);
-
list_for_each_entry_safe(sd, tmp, _list, async_list) {
int ret;
 
@@ -185,6 +183,9 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
}
}
 
+   /* Keep also completed notifiers on the list */
+   list_add(>list, _list);
+
mutex_unlock(_lock);
 
return 0;
-- 
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

[GIT PULL for v4.10-rc6] media fixes

[Mauro Carvalho Chehab]

Hi Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.10-2

For some fixes for -rc6:
  - fix a regression on tvp5150 causing failures at input selection
and image glitches;
  - CEC was moved out of staging for v4.10. Fix some bugs on it while
not too late;
  - fix a regression on pctv452e caused by VM stack changes;
  - fix suspend issued with smiapp;
  - fix a regression on cobalt driver;
  - fix some warnings and Kconfig issues with some random configs.

The following changes since commit 65390ea01ce678379da32b01f39fcfac4903f256:

  Merge branch 'patchwork' into v4l_for_linus (2016-12-15 08:38:35 -0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.10-2

for you to fetch changes up to 0e0694ff1a7791274946b7f51bae692da0001a08:

  Merge branch 'patchwork' into v4l_for_linus (2016-12-26 14:09:28 -0200)


media fixes for v4.10-rc6


Arnd Bergmann (2):
  [media] dvb: avoid warning in dvb_net
  [media] s5k4ecgx: select CRC32 helper

Christoph Hellwig (1):
  [media] media/cobalt: use pci_irq_allocate_vectors

Hans Verkuil (7):
  [media] cec: fix report_current_latency
  [media] cec: when canceling a message, don't overwrite old status info
  [media] cec: CEC_MSG_GIVE_FEATURES should abort for CEC version < 2
  [media] cec: update log_addr[] before finishing configuration
  [media] cec: replace cec_report_features by cec_fill_msg_report_features
  [media] cec: move cec_report_phys_addr into cec_config_thread_func
  [media] cec: fix race between configuring and unconfiguring

Laurent Pinchart (3):
  [media] v4l: tvp5150: Reset device at probe time, not in get/set format 
handlers
  [media] v4l: tvp5150: Fix comment regarding output pin muxing
  [media] v4l: tvp5150: Don't override output pinmuxing at stream on/off 
time

Mauro Carvalho Chehab (1):
  Merge branch 'patchwork' into v4l_for_linus

Max Kellermann (1):
  [media] pctv452e: move buffer to heap, no mutex

Sakari Ailus (2):
  [media] smiapp: Implement power-on and power-off sequences without 
runtime PM
  [media] smiapp: Make suspend and resume functions __maybe_unused

 drivers/media/cec/cec-adap.c | 103 
 drivers/media/dvb-core/dvb_net.c |  15 ++--
 drivers/media/i2c/Kconfig|   1 +
 drivers/media/i2c/smiapp/smiapp-core.c   |  33 +++-
 drivers/media/i2c/tvp5150.c  |  56 -
 drivers/media/i2c/tvp5150_reg.h  |   9 +++
 drivers/media/pci/cobalt/cobalt-driver.c |   8 +-
 drivers/media/pci/cobalt/cobalt-driver.h |   2 -
 drivers/media/usb/dvb-usb/pctv452e.c | 133 +--
 include/uapi/linux/cec-funcs.h   |  10 ++-
 10 files changed, 195 insertions(+), 175 deletions(-)

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

[ANN] Media object lifetime management meeting report from Oslo

[Sakari Ailus]

Hello everyone,

Please read below my report on resolving object lifetime issues in V4L2 and
Media controller frameworks. The document is rather long but worth reading if
you're interested in the topic.


Sakari Ailus, Laurent Pinchart and Hans Verkuil present
2016-01-13


Introduction to the problem domain
==

The Media controller framework was first used for complex devices with
internal data processing pipelines. The problem domain that got most of the
attention as how the pipeline configuration would work and how V4L2
sub-device format would be propagated or how the pipeline validation would
work. As none of the devices that were supported in the beginning were
hot-pluggable, little attention was paid in making it possible to remove
them.

The media graph is a complex, highly interconnected data structure with
object allocated by different drivers and with different lifetimes. The data
structure can be navigated by the Media controller framework and by drivers,
including parts that those drivers did not create themselves. While some
rules exist on how this could be done, for instance the graph traversal,
these rules are not enough to support new use cases such as hot-pluggable
devices (or safely unbinding devices in general).

In the original (and also the current) implementation of the Media
controller framework tearing down a Media device was centered in the ability
of removing devices without crashing the kernel while the said devices were
not in use by a user application. In order to prevent unbinding drivers,
module use counts are increased whilst the devices are in use. This
obviously does not guarantee that: hot-pluggable devices may be removed
without the user application even knowing it, as well as non-hotpluggable
devices may also be unbound even if the module stays loaded (of which the
latter is certainly a lesser concern).


Current and future issues
=

* Media device lifetime management. There is no serialisation between
  issuing system calls to the media device driver and removing the struct
  media_device from the system, typically through unbinding a device from
  the driver. This leaves a time window in which released kernel memory may
  be accessed.

* Media entity lifetime management (including driver allocated objects that
  can be reached through media graph objects). Media entities (and objects
  that embed media graph objects) may be looked up by drivers and
  referenced. Such references may be kept for an extended period of time.
  Sub-device drivers may call other sub-devices' operations as well as they
  may be accessed from the user space through file handles. Media entity
  lifetime management is required for safely removing them.

* Sharing a struct media_device between drivers. This is not a problem right
  now but will need to be addressed before a struct media_device may be
  shared between multiple drivers. Currently, the struct media_device has
  multiple fields that are specific to a single driver which inherently
  makes a media device non-shareable:

- dev: struct device of the bridge/ISP driver
- ops: ops structure that contains e.g. link_setup used for managing
  power across the pipelines found in a media device. In the future,
  this would include routing configuration as well.

  The functionality supported by these fields has to be implemented by means
  supporting multiple drivers before sharing the struct media_device is
  possible. In that solution, these fields may not continue to exist in the
  form they do now.


General rules for accessing data and running code
=

These rules must be followed in accessing data and executing code in all
cases:

code) While there is a chance to execute code, the containing module
  reference count must be incremented.

data) Every memory allocation must be reference counted if a pointer to
  that memory is being shared. Each user obtains a reference and puts it
  using a related put function which will release the memory if it was the
  last reference.


Object reference counting golden rules
==

1. When a pointer to a reference-counted object is stored for later use, a
   reference to that object must exist.

2. A reference exists if it is taken or borrowed.

3. A borrowed reference is a reference taken elsewhere that can be proven to
   exist for the complete lifetime of the pointer.

4. When in doubt about whether a reference can be borrowed, it can be taken
   without any adverse impact.

5. A reference taken must be put at some point.

6. No access to a pointer can occur after the corresponding reference has
   been put.

6.1. The point when the reference is put must be proven to occur
 later than all other possible accesses to the reference.

6.2. At the location where the reference is put, care must be taken
 

Re: [patch] [media] mantis_dvb: fix some error codes in mantis_dvb_init()

[Dan Carpenter]

You're, of course, correct that this code could be cleaned up...

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] [media] mantis_dvb: fix some error codes in mantis_dvb_init()

[walter harms]

Am 27.01.2017 09:06, schrieb Dan Carpenter:
> We should be returning negative error codes here or it leads to a crash.
> This also silences a static checker warning.
> 
>   drivers/media/pci/mantis/mantis_cards.c:250 mantis_pci_probe()
>   warn: 'mantis->dmxdev.dvbdev->fops' double freed
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/media/pci/mantis/mantis_dvb.c 
> b/drivers/media/pci/mantis/mantis_dvb.c
> index 5a71e1791cf5..0db4de3a2285 100644
> --- a/drivers/media/pci/mantis/mantis_dvb.c
> +++ b/drivers/media/pci/mantis/mantis_dvb.c
> @@ -226,11 +226,12 @@ int mantis_dvb_init(struct mantis_pci *mantis)
>   goto err5;
>   } else {
>   if (mantis->fe == NULL) {
> + result = -ENOMEM;
>   dprintk(MANTIS_ERROR, 1, "FE ");
>   goto err5;
>   }
> -
> - if (dvb_register_frontend(>dvb_adapter, 
> mantis->fe)) {
> + result = dvb_register_frontend(>dvb_adapter, 
> mantis->fe);
> + if (result) {
>   dprintk(MANTIS_ERROR, 1, "ERROR: Frontend 
> registration failed");
>  
>   if (mantis->fe->ops.release)


hi,
just one remark:
the indent level is deep.
using  if ( !mantis->hwconfig) return 0;
and killing the "else" would help with readability.

just my 2 cents
re,
 wh

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

[patch] [media] mantis_dvb: fix some error codes in mantis_dvb_init()

[Dan Carpenter]

We should be returning negative error codes here or it leads to a crash.
This also silences a static checker warning.

drivers/media/pci/mantis/mantis_cards.c:250 mantis_pci_probe()
warn: 'mantis->dmxdev.dvbdev->fops' double freed

Signed-off-by: Dan Carpenter 

diff --git a/drivers/media/pci/mantis/mantis_dvb.c 
b/drivers/media/pci/mantis/mantis_dvb.c
index 5a71e1791cf5..0db4de3a2285 100644
--- a/drivers/media/pci/mantis/mantis_dvb.c
+++ b/drivers/media/pci/mantis/mantis_dvb.c
@@ -226,11 +226,12 @@ int mantis_dvb_init(struct mantis_pci *mantis)
goto err5;
} else {
if (mantis->fe == NULL) {
+   result = -ENOMEM;
dprintk(MANTIS_ERROR, 1, "FE ");
goto err5;
}
-
-   if (dvb_register_frontend(>dvb_adapter, 
mantis->fe)) {
+   result = dvb_register_frontend(>dvb_adapter, 
mantis->fe);
+   if (result) {
dprintk(MANTIS_ERROR, 1, "ERROR: Frontend 
registration failed");
 
if (mantis->fe->ops.release)
--
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