date:20160621

cron job: media_tree daily build: OK

2016-06-21 Thread Hans Verkuil

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

Results of the daily build of media_tree:

date:   Wed Jun 22 04:00:15 CEST 2016
git branch: test
git hash:   59f0bc11848f8f3242bc1fefae670e745929cd7b
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mtk: OK
linux-git-arm-mx: OK
linux-git-arm-omap: 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: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: OK
linux-4.7-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
linux-4.7-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

[PATCH 2/2] [media] v4l: subdev: move s_stream from v4l2_subdev_video_ops to v4l2_subdev_pad_ops

2016-06-21 Thread Niklas Söderlund

Some devices (adv7482 for example) supports running two video pipelines
in parallel. To be able to stop and start streams on a pad basis the
s_stream operation needs to be extended with a 'pad' argument specifying
which pad to start or stop the stream for.

This patch moves the s_stream operation from struct
v4l2_subdev_video_ops to struct v4l2_subdev_pad_ops. It also updates all
users of s_stream to use the new function with pad number 0.

Suggested-by: Laurent Pinchart 
Signed-off-by: Niklas Söderlund 
---
 drivers/media/dvb-frontends/au8522_decoder.c   |   9 +-
 drivers/media/i2c/ad9389b.c|   7 +-
 drivers/media/i2c/adv7180.c|   5 +-
 drivers/media/i2c/adv7183.c|   5 +-
 drivers/media/i2c/adv7511.c|   7 +-
 drivers/media/i2c/ak881x.c |   5 +-
 drivers/media/i2c/bt819.c  |   9 +-
 drivers/media/i2c/cx25840/cx25840-core.c   |   5 +-
 drivers/media/i2c/ks0127.c |   9 +-
 drivers/media/i2c/m5mols/m5mols_core.c |  19 +--
 drivers/media/i2c/mt9m032.c|   5 +-
 drivers/media/i2c/mt9p031.c|   9 +-
 drivers/media/i2c/mt9t001.c|   9 +-
 drivers/media/i2c/mt9v032.c|   9 +-
 drivers/media/i2c/noon010pc30.c|   6 +-
 drivers/media/i2c/ov2659.c |   8 +-
 drivers/media/i2c/ov9650.c |   4 +-
 drivers/media/i2c/s5c73m3/s5c73m3-core.c   |   5 +-
 drivers/media/i2c/s5k4ecgx.c   | 180 ++---
 drivers/media/i2c/s5k5baf.c|   4 +-
 drivers/media/i2c/s5k6aa.c |   4 +-
 drivers/media/i2c/saa7110.c|   9 +-
 drivers/media/i2c/saa7115.c|   5 +-
 drivers/media/i2c/saa7127.c|   9 +-
 drivers/media/i2c/saa717x.c|   5 +-
 drivers/media/i2c/smiapp/smiapp-core.c |   9 +-
 drivers/media/i2c/soc_camera/imx074.c  |   5 +-
 drivers/media/i2c/soc_camera/mt9m001.c |   5 +-
 drivers/media/i2c/soc_camera/mt9t031.c |   5 +-
 drivers/media/i2c/soc_camera/mt9t112.c |   5 +-
 drivers/media/i2c/soc_camera/mt9v022.c |   5 +-
 drivers/media/i2c/soc_camera/ov2640.c  |   5 +-
 drivers/media/i2c/soc_camera/ov6650.c  |   5 +-
 drivers/media/i2c/soc_camera/ov772x.c  |   5 +-
 drivers/media/i2c/soc_camera/ov9640.c  |   5 +-
 drivers/media/i2c/soc_camera/ov9740.c  |   9 +-
 drivers/media/i2c/soc_camera/rj54n1cb0c.c  |   5 +-
 drivers/media/i2c/soc_camera/tw9910.c  |   5 +-
 drivers/media/i2c/tc358743.c   |   5 +-
 drivers/media/i2c/ths7303.c|  10 +-
 drivers/media/i2c/ths8200.c|   9 +-
 drivers/media/i2c/tvp514x.c|  10 +-
 drivers/media/i2c/tvp5150.c|   5 +-
 drivers/media/i2c/tvp7002.c|   5 +-
 drivers/media/i2c/vpx3220.c|   9 +-
 drivers/media/i2c/vs6624.c |   5 +-
 drivers/media/pci/cobalt/cobalt-driver.c   |   2 +-
 drivers/media/pci/cx18/cx18-av-core.c  |   5 +-
 drivers/media/pci/ivtv/ivtv-driver.c   |   7 +-
 drivers/media/pci/ivtv/ivtv-streams.c  |   4 +-
 drivers/media/pci/ivtv/ivtvfb.c|   6 +-
 drivers/media/pci/zoran/zoran_card.c   |   2 +-
 drivers/media/pci/zoran/zoran_device.c |   6 +-
 drivers/media/pci/zoran/zoran_driver.c |   2 +-
 drivers/media/platform/am437x/am437x-vpfe.c|   4 +-
 drivers/media/platform/blackfin/bfin_capture.c |   4 +-
 drivers/media/platform/davinci/vpfe_capture.c  |   8 +-
 drivers/media/platform/davinci/vpif_capture.c  |   4 +-
 drivers/media/platform/exynos4-is/fimc-isp.c   |   7 +-
 drivers/media/platform/exynos4-is/fimc-lite.c  |   7 +-
 drivers/media/platform/exynos4-is/media-dev.c  |   4 +-
 drivers/media/platform/exynos4-is/mipi-csis.c  |   5 +-
 drivers/media/platform/omap3isp/isp.c  |  28 ++--
 drivers/media/platform/omap3isp/ispccdc.c  |  10 +-
 drivers/media/platform/omap3isp/ispccp2.c  |   9 +-
 drivers/media/platform/omap3isp/ispcsi2.c  |  10 +-
 drivers/media/platform/omap3isp/isph3a_aewb.c  |   4 +-
 drivers/media/platform/omap3isp/isph3a_af.c|   4 +-
 drivers/media/platform/omap3isp/isphist.c  |   4 +-
 drivers/media/platform/omap3isp/isppreview.c   |  10 +-
 drivers/media/platform/omap3isp/ispresizer.c   |  10 +-
 drivers/media/platform/omap3isp/ispstat.c  |   3

[PATCH 0/2] move s_stream from v4l2_subdev_video_ops to move s_stream from v4l2_subdev_pad_ops

2016-06-21 Thread Niklas Söderlund

Hi all,

This series moves s_stream from struct v4l2_subdev_video_ops to struct
v4l2_subdev_pad_ops. The reason for this is that there are devices 
(adv7482 for example) which can support more then one video pipeline 
connected to two different output pads to run simultaneously. In order 
to be able to be able to start and stop streams on a pad level the 
s_stream operation needs to be extended with a pad argument.

The series is based on the master branch of the media_tree.

It have been suggested by both Laurent Pinchart and Hans Verkuil that if 
a pad aware s_stream is needed the operation should be moved from the 
video struct to the pad ops struct and not just add a s_stream to the 
pad ops struct.

The change to v4l framework is trivial and only moves s_stream between 
the two structs and adds a 'pad' argument. The majority of the changes 
is updating all users of the s_stream operation to use the one from 
v4l2_subdev_pad_ops.

Patch 1/2 is a preparation of the vsp1 driver where the 
v4l2_subdev_video_ops struct was shared by two devices which no longer 
can be shared since only one of them implements s_stream.

Patch 2/2 moves the s_stream operation between the struct and updates 
all users. The callers have primarily been updated using Coccinelle 
patch which is attached to this cover letter.

After the spatch run all changes have been manually reviewed and struct 
v4l2_subdev_pad_ops have been added to drivers which previously did not 
have one. Likewise struct v4l2_subdev_video_ops which became 'empty' 
after removing s_stream have been removed. A few drivers needed some 
code to me moved around (most notably s5k4ecgx) for ordering but nothing 
in the code itself have changed while moving it except to update calls 
to s_stream to use the pad version.

I have tested this series to the best of my ability by building 
allyesconfig configurations for arm, arm64 and x86_64. I have also 
tested on a R-Car Koelsch board (rcar-vin and adv7180).

cut
@ rule1 @
identifier fn, s;
@@

 struct v4l2_subdev_video_ops s = { .s_stream = fn, };

@@
identifier rule1.fn, rule1.s;
@@

 struct v4l2_subdev_video_ops s = {
-.s_stream = fn,
 };

@@
identifier rule1.fn, s;
@@

 struct v4l2_subdev_pad_ops s = {
+.s_stream = fn,
 };

@@
identifier rule1.fn, a, b;
symbol pad;
@@

-fn(struct v4l2_subdev *a, int b)
+fn(struct v4l2_subdev *a, unsigned int pad, int b)
 {
 ...
 }

@@
identifier rule1.fn;
expression e1, e2;
@@

-fn(e1, e2);
+fn(e1, 0, e2);

@@
expression e1, e2;
symbol video, pad, s_stream;
@@

-v4l2_subdev_call(e1, video, s_stream, e2);
+v4l2_subdev_call(e1, pad, s_stream, 0, e2);

@@
expression e1, e2, e3;
symbol video, pad, s_stream;
@@

-e3 = v4l2_subdev_call(e1, video, s_stream, e2);
+e3 = v4l2_subdev_call(e1, pad, s_stream, 0, e2);

@@
expression e1, e2;
@@

-call_all(e1, video, s_stream, e2);
+call_all(e1, pad, s_stream, 0, e2);

@@
expression e1, e2, e3;
symbol video, pad, s_stream;
@@

-ivtv_call_hw(e1, e2, video, s_stream, e3);
+ivtv_call_hw(e1, e2, pad, s_stream, 0, e3);

@@
expression e1, e2, e3, e4;
symbol video, pad, s_stream;
@@

-e1 = v4l2_device_call_until_err(e2, e3, video, s_stream, e4);
+e1 = v4l2_device_call_until_err(e2, e3, pad, s_stream, 0, e4);

@@
expression e2, e3, e4;
symbol video, pad, s_stream;
@@

-v4l2_device_call_until_err(e2, e3, video, s_stream, e4);
+v4l2_device_call_until_err(e2, e3, pad, s_stream, 0, e4);

@@
expression e1, e2, e3;
symbol video, pad, s_stream;
@@

-v4l2_device_call_all(e1, e2, video, s_stream, e3);
+v4l2_device_call_all(e1, e2, pad, s_stream, 0, e3);

@@
expression e1, e2;
symbol video, pad, s_stream;
@@

-cx25840_call(e1, video, s_stream, e2);
+cx25840_call(e1, pad, s_stream, 0, e2);
cut

Niklas Söderlund (2):
  [media] v4l: vsp1: Split pad operations between rpf and wpf
  [media] v4l: subdev: move s_stream from v4l2_subdev_video_ops to
v4l2_subdev_pad_ops

 drivers/media/dvb-frontends/au8522_decoder.c   |   9 +-
 drivers/media/i2c/ad9389b.c|   7 +-
 drivers/media/i2c/adv7180.c|   5 +-
 drivers/media/i2c/adv7183.c|   5 +-
 drivers/media/i2c/adv7511.c|   7 +-
 drivers/media/i2c/ak881x.c |   5 +-
 drivers/media/i2c/bt819.c  |   9 +-
 drivers/media/i2c/cx25840/cx25840-core.c   |   5 +-
 drivers/media/i2c/ks0127.c |   9 +-
 drivers/media/i2c/m5mols/m5mols_core.c |  19 +--
 drivers/media/i2c/mt9m032.c|   5 +-
 drivers/media/i2c/mt9p031.c|   9 +-
 drivers/media/i2c/mt9t001.c|   9 +-
 drivers/media/i2c/mt9v032.c|   9 +-
 drivers/media/i2c/noon010pc30.c|   6 +-
 drivers/media/i2c/ov2659.c |   8 +-
 drivers/media/i2c/ov9650.c |   4 +-
 drivers/media/i2c/s5c73m3/s5c73m3-core.c   |   5 +-

[PATCH 1/2] [media] v4l: vsp1: Split pad operations between rpf and wpf

2016-06-21 Thread Niklas Söderlund

This is done in preparation to move s_stream from v4l2_subdev_video_ops
to v4l2_subdev_pad_ops. Only wpf implements s_stream so it will no
longer be possible to share the v4l2_subdev_pad_ops once s_stream is
moved.

Suggested-by: Laurent Pinchart 
Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/vsp1/vsp1_rpf.c  | 12 +-
 drivers/media/platform/vsp1/vsp1_rwpf.c | 40 +
 drivers/media/platform/vsp1/vsp1_rwpf.h | 20 +
 drivers/media/platform/vsp1/vsp1_wpf.c  | 12 +-
 4 files changed, 57 insertions(+), 27 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c 
b/drivers/media/platform/vsp1/vsp1_rpf.c
index 49168db..fabe8b2 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -38,8 +38,18 @@ static inline void vsp1_rpf_write(struct vsp1_rwpf *rpf,
  * V4L2 Subdevice Operations
  */
 
+const struct v4l2_subdev_pad_ops vsp1_rpf_pad_ops = {
+   .init_cfg = vsp1_entity_init_cfg,
+   .enum_mbus_code = vsp1_rwpf_enum_mbus_code,
+   .enum_frame_size = vsp1_rwpf_enum_frame_size,
+   .get_fmt = vsp1_subdev_get_pad_format,
+   .set_fmt = vsp1_rwpf_set_format,
+   .get_selection = vsp1_rwpf_get_selection,
+   .set_selection = vsp1_rwpf_set_selection,
+};
+
 static struct v4l2_subdev_ops rpf_ops = {
-   .pad= _rwpf_pad_ops,
+   .pad= _rpf_pad_ops,
 };
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.c 
b/drivers/media/platform/vsp1/vsp1_rwpf.c
index 3b6e032..ff03b9c 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.c
@@ -31,9 +31,9 @@ struct v4l2_rect *vsp1_rwpf_get_crop(struct vsp1_rwpf *rwpf,
  * V4L2 Subdevice Pad Operations
  */
 
-static int vsp1_rwpf_enum_mbus_code(struct v4l2_subdev *subdev,
-   struct v4l2_subdev_pad_config *cfg,
-   struct v4l2_subdev_mbus_code_enum *code)
+int vsp1_rwpf_enum_mbus_code(struct v4l2_subdev *subdev,
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_mbus_code_enum *code)
 {
static const unsigned int codes[] = {
MEDIA_BUS_FMT_ARGB_1X32,
@@ -48,9 +48,9 @@ static int vsp1_rwpf_enum_mbus_code(struct v4l2_subdev 
*subdev,
return 0;
 }
 
-static int vsp1_rwpf_enum_frame_size(struct v4l2_subdev *subdev,
-struct v4l2_subdev_pad_config *cfg,
-struct v4l2_subdev_frame_size_enum *fse)
+int vsp1_rwpf_enum_frame_size(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_size_enum *fse)
 {
struct vsp1_rwpf *rwpf = to_rwpf(subdev);
 
@@ -59,9 +59,9 @@ static int vsp1_rwpf_enum_frame_size(struct v4l2_subdev 
*subdev,
   rwpf->max_height);
 }
 
-static int vsp1_rwpf_set_format(struct v4l2_subdev *subdev,
-   struct v4l2_subdev_pad_config *cfg,
-   struct v4l2_subdev_format *fmt)
+int vsp1_rwpf_set_format(struct v4l2_subdev *subdev,
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_format *fmt)
 {
struct vsp1_rwpf *rwpf = to_rwpf(subdev);
struct v4l2_subdev_pad_config *config;
@@ -113,9 +113,9 @@ static int vsp1_rwpf_set_format(struct v4l2_subdev *subdev,
return 0;
 }
 
-static int vsp1_rwpf_get_selection(struct v4l2_subdev *subdev,
-  struct v4l2_subdev_pad_config *cfg,
-  struct v4l2_subdev_selection *sel)
+int vsp1_rwpf_get_selection(struct v4l2_subdev *subdev,
+   struct v4l2_subdev_pad_config *cfg,
+   struct v4l2_subdev_selection *sel)
 {
struct vsp1_rwpf *rwpf = to_rwpf(subdev);
struct v4l2_subdev_pad_config *config;
@@ -150,9 +150,9 @@ static int vsp1_rwpf_get_selection(struct v4l2_subdev 
*subdev,
return 0;
 }
 
-static int vsp1_rwpf_set_selection(struct v4l2_subdev *subdev,
-  struct v4l2_subdev_pad_config *cfg,
-  struct v4l2_subdev_selection *sel)
+int vsp1_rwpf_set_selection(struct v4l2_subdev *subdev,
+   struct v4l2_subdev_pad_config *cfg,
+   struct v4l2_subdev_selection *sel)
 {
struct vsp1_rwpf *rwpf = to_rwpf(subdev);
struct v4l2_subdev_pad_config *config;
@@ -209,16 +209,6 @@ static int vsp1_rwpf_set_selection(struct v4l2_subdev 
*subdev,
return 0;
 }
 
-const struct v4l2_subdev_pad_ops vsp1_rwpf_pad_ops = {
-   .init_cfg =

[PATCH] media: s5p-mfc fix null pointer deference in clk_core_enable()

2016-06-21 Thread Shuah Khan

Fix null pointer deference in clk_core_enable() when driver unbind is run
when there is an application has an active pipeline playing. At this point,
system hangs and needs to be power cycled.

s5p_mfc_release() gets called after s5p_mfc_final_pm() disables and does
clk_put() and s5p_mfc_release() attempts to enable clock and runs into
null pointer deference accessing invalid pointer. With this fix, null
pointer dereference is fixed and there is no hang.

Run unbind while the following pipeline is playing:
gst-launch-1.0 filesrc location=/home/odroid/GH3_MOV_HD.mp4 ! qtdemux !
h264parse ! v4l2video4dec ! videoconvert ! autovideosink

[ 4869.434709] Unable to handle kernel NULL pointer dereference at virtual addr0
[ 4869.441312] pgd = e91ac000
[ 4869.443996] [0010] *pgd=ba4f7835
[ 4869.447552] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 4869.452921] Modules linked in: cpufreq_userspace cpufreq_powersave cpufreq_ca
[ 4869.471728] CPU: 4 PID: 2965 Comm: lt-gst-launch-1 Not tainted 4.7.0-rc2-nex0
[ 4869.481778] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 4869.487844] task: e91f1e00 ti: ed65 task.ti: ed65
[ 4869.493227] PC is at clk_core_enable+0x4c/0x98
[ 4869.497637] LR is at clk_core_enable+0x40/0x98
[ 4869.502056] pc : []lr : []psr: 60060093
[ 4869.502056] sp : ed651f18  ip :   fp : 002641b4
[ 4869.513493] r10: e9088c08  r9 : 0008  r8 : ed676d68
[ 4869.518692] r7 : ee3ac000  r6 : bf16b3c0  r5 : a0060013  r4 : ee37a8c0
[ 4869.525191] r3 :   r2 : 0001  r1 : 0004  r0 : 
[ 4869.531692] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment noe
[ 4869.538883] Control: 10c5387d  Table: 691ac06a  DAC: 0051
[ 4869.544603] Process lt-gst-launch-1 (pid: 2965, stack limit = 0xed650210)
[ 4869.551361] Stack: (0xed651f18 to 0xed652000)
[ 4869.555694] 1f00:   ee373
[ 4869.563841] 1f20: bf16b3c0 c055a0e0 ee3ac004 ed676c10 bf16b3c0 bf1558e0 e9080
[ 4869.571986] 1f40:  ee98a510 ee502e40 bf047344 e9088c00 ee986938 4
[ 4869.580132] 1f60:   e91f2204  c0b4658c e91f1e00 c0100
[ 4869.588277] 1f80:  c0135c58 ed65 c0107904 ed651fb0 0006 c0104
[ 4869.596423] 1fa0: 00229500 b6581000 b6f7b544 c0107794  0002 b6f90
[ 4869.604568] 1fc0: 00229500 b6581000 b6f7b544 0006 0017b600 0002c038 00264
[ 4869.612714] 1fe0:  bee56ef0  b6d49612 00060030 0006 0
[ 4869.620865] [] (clk_core_enable) from [] (clk_enable+0x2)
[ 4869.628509] [] (clk_enable) from [] (s5p_mfc_release+0x3)
[ 4869.637111] [] (s5p_mfc_release [s5p_mfc]) from [] (v4l2)
[ 4869.646706] [] (v4l2_release [videodev]) from [] (__fput)
[ 4869.654745] [] (__fput) from [] (task_work_run+0x94/0xc8)
[ 4869.661852] [] (task_work_run) from [] (do_work_pending+)
[ 4869.669735] [] (do_work_pending) from [] (slow_work_pend)
[ 4869.677878] Code: ebef e350 18bd8070 e5943004 (e5933010)

Signed-off-by: Shuah Khan 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
index d011f30..d88f1ba 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
@@ -76,8 +76,10 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
 
 err_s_clk:
clk_put(pm->clock);
+   pm->clock = NULL;
 err_p_ip_clk:
clk_put(pm->clock_gate);
+   pm->clock_gate = NULL;
 err_g_ip_clk:
return ret;
 }
@@ -88,9 +90,11 @@ void s5p_mfc_final_pm(struct s5p_mfc_dev *dev)
!IS_ERR_OR_NULL(pm->clock)) {
clk_disable_unprepare(pm->clock);
clk_put(pm->clock);
+   pm->clock = NULL;
}
clk_unprepare(pm->clock_gate);
clk_put(pm->clock_gate);
+   pm->clock_gate = NULL;
 #ifdef CONFIG_PM
pm_runtime_disable(pm->device);
 #endif
@@ -98,12 +102,13 @@ void s5p_mfc_final_pm(struct s5p_mfc_dev *dev)
 
 int s5p_mfc_clock_on(void)
 {
-   int ret;
+   int ret = 0;
 #ifdef CLK_DEBUG
atomic_inc(_ref);
mfc_debug(3, "+ %d\n", atomic_read(_ref));
 #endif
-   ret = clk_enable(pm->clock_gate);
+   if (!IS_ERR_OR_NULL(pm->clock_gate))
+   ret = clk_enable(pm->clock_gate);
return ret;
 }
 
@@ -113,7 +118,8 @@ void s5p_mfc_clock_off(void)
atomic_dec(_ref);
mfc_debug(3, "- %d\n", atomic_read(_ref));
 #endif
-   clk_disable(pm->clock_gate);
+   if (!IS_ERR_OR_NULL(pm->clock_gate))
+   clk_disable(pm->clock_gate);
 }
 
 int s5p_mfc_power_on(void)
-- 
2.7.4

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

Re: camera application for testing (was Re: v4l subdevs without big device)

2016-06-21 Thread Laurent Pinchart

Hi Sakari,

On Sunday 01 May 2016 17:08:31 Sakari Ailus wrote:
> On Sat, Apr 30, 2016 at 12:13:59AM +0200, Pavel Machek wrote:
> > Hi!
> > 
> > What is reasonable camera application for testing?
> > 
> > N900 looks like a low-end digital camera. I have now have the hardware
> > working (can set focus to X cm using command line), but that's not
> > going to be useful for taking photos.
> 
> I guess you already knew about omap3camd; it's proprietary but from purely
> practical point of view it'd be an option to support taking photos on the
> N900. That would not be extensible any way, the best possible functionality
> is limited what the daemon implements.
> 
> I'm just mentioning the option of implementing wrapper for the omap3camd so
> that it can work with upsteam APIs, I don't propose that however.
> 
> > In particular, who is going to do computation neccessary for
> > autofocus, whitebalance and exposure/gain?
> 
> I think libv4l itself has algorithms to control at least some of these. It
> relies on the image data so the CPU time consumption will be high.
> 
> AFAIR Laurent has also worked on implementing some algorithms that use the
> histogram and some of the statistics. Add him to cc list.

http://git.ideasonboard.org/omap3-isp-live.git

That's outdated and might not run or compile anymore. The code is more of a 
proof of concept implementation, but it could be used as a starting point. 
With an infinite amount of free time I'd love to work on an open-source 
project for computational cameras, integrating it with libv4l.

> > There's http://fcam.garage.maemo.org/gettingStarted.html that should
> > work on maemo, but a) it is not in Debian, b) it has non-trivial
> > dependencies and c) will be a lot of fun to get working...
> > (and d), will not be too useful, anyway, due to 1sec shutter lag:
>
> I believe this will be shorter nowadays. I don't remember the exact
> technical solution which the text below refers to but I'm pretty sure it'll
> be better with the current upstream. API-wise, there's work to be done there
> (to port FCAM to upsteram APIs) but it's a possibility.
> 
> > Fast resolution switching (less shutter lag)
> > FCam is built on top of V4L2, which doesn't handle rapidly varying
> > resolutions. When a Shot with a different resolution to the previous
> > one comes down the pipeline, FCam currently flushes the entire V4L2
> > pipeline, shuts down and restarts the whole camera subsystem, then
> > starts streaming at the new resolution. This takes a long time (nearly
> > a second), and is the cause of the horrible shutter lag on the N900. A
> > brave kernel hacker may be able to reduce this time by fiddling with
> > the FCam ISP kernel modules and the guts of the FCam library source
> > (primarily Daemon.cpp).
> > Anyone who solves this one will have our undying gratitude. An ideal
> > solution would be able to insert a 5MP capture into a stream of
> > 640x480 frames running at 30fps, without skipping more than the frame
> > time of the 5MP capture. That is, the viewfinder would effectively
> > stay live while taking a photograph.
> > 
> > )
> > 
> > Any other application I should look at? Thanks,

-- 
Regards,

Laurent Pinchart

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

Re: camera application for testing (was Re: v4l subdevs without big device)

2016-06-21 Thread Pavel Machek

Hi!

> > What is reasonable camera application for testing?
> > 
> > N900 looks like a low-end digital camera. I have now have the hardware
> > working (can set focus to X cm using command line), but that's not
> > going to be useful for taking photos.
> 
> I guess you already knew about omap3camd; it's proprietary but from purely
> practical point of view it'd be an option to support taking photos on the
> N900. That would not be extensible any way, the best possible functionality
> is limited what the daemon implements.
> 
> I'm just mentioning the option of implementing wrapper for the omap3camd so
> that it can work with upsteam APIs, I don't propose that however.
> 
> > 
> > In particular, who is going to do computation neccessary for
> > autofocus, whitebalance and exposure/gain?
> 
> I think libv4l itself has algorithms to control at least some of these. It
> relies on the image data so the CPU time consumption will be high.
> 
> AFAIR Laurent has also worked on implementing some algorithms that use the
> histogram and some of the statistics. Add him to cc list.

Ok, so I played a bit... and have something working. I modified
fcam-dev to work with the current kernel, and removed most
functionality in the process. Then I re-did sharpness and autogain
computations in software, and it seems to work somehow... but its
rather slow. (But good news is that's because code is stupid; the
computations should be fast enough.)

In particular, it takes cca 10 seconds to take a picture. I guess
there's a room for improvement :-).

> > There's http://fcam.garage.maemo.org/gettingStarted.html that should
> > work on maemo, but a) it is not in Debian, b) it has non-trivial
> > dependencies and c) will be a lot of fun to get working...
> > 
> > (and d), will not be too useful, anyway, due to 1sec shutter lag:
> 
> I believe this will be shorter nowadays. I don't remember the exact
> technical solution which the text below refers to but I'm pretty sure it'll
> be better with the current upstream. API-wise, there's work to be done there
> (to port FCAM to upsteram APIs) but it's a possibility.

So far I have really horrible hacks.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 9/9] Input: synaptics-rmi4 - add support for F54 diagnostics

2016-06-21 Thread Nick Dyer

On 20/06/2016 17:20, Hans Verkuil wrote:
> On 06/17/2016 04:16 PM, Nick Dyer wrote:
>> +static int rmi_f54_vidioc_enum_input(struct file *file, void *priv,
>> + struct v4l2_input *i)
>> +{
>> +struct f54_data *f54 = video_drvdata(file);
>> +enum f54_report_type reptype;
>> +
>> +reptype = rmi_f54_get_reptype(f54, i->index);
>> +if (reptype == F54_REPORT_NONE)
>> +return -EINVAL;
>> +
>> +i->type = V4L2_INPUT_TYPE_TOUCH_SENSOR;
>> +strlcpy(i->name, rmi_f54_reptype_str(reptype), sizeof(i->name));
> 
> Hmm, this doesn't feel right, but I don't have enough knowledge to decide if
> using inputs for this is the right approach.
> 
> One thing that strikes me as odd is that both F54_8BIT_IMAGE and 
> F54_16BIT_IMAGE
> both seem to return signed 16 bit samples. I would expect this to result in
> different pixel formats.

Yes, you're right. I've had a look at this area now and fixed it up. I've
added pixel formats for the various types of touch data so we will never
emit anything that's not under V4L2_TCH_FMT.

I've also worked on adding the DocBook documentation that was missing,
cribbing from SDR as you suggested. I think I've found all the places it
was needed now.

> I have no idea what all these inputs mean. Are they all actually needed?
> Would this perhaps be better implemented through a menu control?

These are the various types of tuning or fault finding data that users
expect to be able to access via the RMI4 F54 diagnostics function. Although
I would have to do some digging to give an detailed use case for each one.
Due to the way that F54 is implemented, only one data source can be
selected at once. So it seemed fairly reasonable to me to map it to inputs.

> I generally go by the philosophy that if I can't understand it, then it is
> likely that others won't either :-)

No problem.
--
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: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

2016-06-21 Thread Richard Cochran

On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote:
> You can experiment with the 'dma' and 'link' timestamps today on any
> HDaudio-based device. Like I said the synchronized part has not been
> upstreamed yet (delays + dependency on ART-to-TSC conversions that made it
> in the kernel recently)

Can you point me to any open source apps using the dma/link
timestamps?

Thanks,
Richard
--
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: Nokia N900 cameras -- pipeline setup in python (was Re: [RFC PATCH 00/24] Make Nokia N900 cameras working)

2016-06-21 Thread Pavel Machek

Hi!

> > > First, I re-did pipeline setup in python, it seems slightly less hacky
> > > then in shell.
> > > 
> > > I tried to modify fcam-dev to work with the new interface, but was not
> > > successful so far. I can post patches if someone is interested
> > > (mplayer works for me, but that's not too suitable for taking photos).
> > > 
> > > I tried to get gstreamer to work, with something like:
> > 
> > While trying to debug gstreamer, I ran v4l2-compliance, and it seems
> > to suggest that QUERYCAP is required... but it is not present on
> > /dev/video2 or video6.
> 
> It's not saying that it wouldn't be present, but the content appears wrong.
> It should have the real bus information there rather than just "media".
> 
> See e.g. drivers/media/platform/vsp1/vsp1_drv.c . I suppose that should be
> right.
> 
> Feel free to submit a patch. :-)

For now I'd not know what to change, sorry :-(. Perhaps we can debug
it after the support is merged into mainline.

Another weirdness:

yavta, on v4l-subdev12 :

control 0x00a40906 `Sensivity' min 0 max 0 step 1 default 0 current 65536.

Min and max being the same, I don't think I can control the
sensitivity. I guess I'll have to provid  more light for the tests for
now...

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

2016-06-21 Thread Pierre-Louis Bossart


On 6/20/16 5:18 AM, Richard Cochran wrote:

On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote:

The ALSA API provides support for 'audio' timestamps (playback/capture rate
defined by audio subsystem) and 'system' timestamps (typically linked to
TSC/ART) with one option to take synchronized timestamps should the hardware
support them.


Thanks for the info.  I just skimmed Documentation/sound/alsa/timestamping.txt.

That is fairly new, only since v4.1.  Are then any apps in the wild
that I can look at?  AFAICT, OpenAVB, gstreamer, etc, don't use the
new API.


The ALSA API supports a generic .get_time_info callback, its 
implementation is for now limited to a regular 'DMA' or 'link' timestamp 
for HDaudio - the difference being which counters are used and how close 
they are to the link serializer. The synchronized part is still WIP but 
should come 'soon'





The intent was that the 'audio' timestamps are translated to a shared time
reference managed in userspace by gPTP, which in turn would define if
(adaptive) audio sample rate conversion is needed. There is no support at
the moment for a 'play_at' function in ALSA, only means to control a
feedback loop.


Documentation/sound/alsa/timestamping.txt says:

  If supported in hardware, the absolute link time could also be used
  to define a precise start time (patches WIP)

Two questions:

1. Where are the patches?  (If some are coming, I would appreciate
   being on CC!)

2. Can you mention specific HW that would support this?


You can experiment with the 'dma' and 'link' timestamps today on any 
HDaudio-based device. Like I said the synchronized part has not been 
upstreamed yet (delays + dependency on ART-to-TSC conversions that made 
it in the kernel recently)


--
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: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

2016-06-21 Thread Pierre-Louis Bossart


On 6/20/16 5:31 AM, Richard Cochran wrote:

On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote:

Documentation/sound/alsa/timestamping.txt says:


   Examples of typestamping with HDaudio:

   1. DMA timestamp, no compensation for DMA+analog delay
   $ ./audio_time  -p --ts_type=1

Where is this "audio_time" program of which you speak?


alsa-lib/test

--
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: [19/38] ARM: dts: imx6-sabrelite: add video capture ports and connections

2016-06-21 Thread Steve Longerbeam

On 06/20/2016 03:44 AM, Jack Mitchell wrote:
>
>
> On 20/06/16 11:16, Gary Bisson wrote:
>> Jack, All,
>>
>> On Mon, Jun 20, 2016 at 10:44:44AM +0100, Jack Mitchell wrote:
>>> 
 I've tried that patch have a some comments:
 - When applied, no capture shows up any more, instead I have two m2m
   v4l2 devices [1].
 - OV5640 Mipi is assigned the same address as OV5642, therefore both
>>>
>>> Yes, I only have one device attached in my scenario.
>>
>> Thanks for confirming.
>>
   can't work at the same time right now. There's a register in the
   camera that allows to modify its I2C address, see this patch [2].
 - How is the mclk working in this patch? It should be using the PWM3
>>>
>>> As mentioned I have an eCon sensor board [1] which generates it's own clock
>>> on the board and as such I don't need the PWM signal, just the two GPIOs.
>>
>> Oh ok, thanks I didn't this sensor board was different than ours [1].
>>
>> But in your patch, you specifically disable pwm3, what's the reason for
>> it?
>
> Yes, it uses the GPIO on the PWM3 pin (beats me why...) so I had to 
> specifically disable it to stop the pin muxing clash.
>

Hi Jack, in your patch, the PWM3 pin (which is SD1_DAT1 operating as GPIO1_IO17)
is being used as the power-down pin for your OV5640 board.

Anyway, I didn't realize this was a different camera from the boundary-devices
module (https://boundarydevices.com/product/nit6x_5mp_mipi/).

I would like to add support in the DT for the BD module, but I am unable to 
test/debug
as I don't have one. I'm wondering if someone could lend me one, along with the
schematics. I have the OV5642 parallel interface module for the SabreLite, so 
I'd love
to get my hands on the OV5640 mipi module as that would allow testing of 
multiple
camera capture which I've never been able to do before.

In the meantime I am going to omit support for this module in the sabrelite DT 
(there's
also the problem of the i2c bus address conflict on the same i2c2 bus with the 
ov5642).

Or if someone can add support for the BD module later that would be great.


Steve

>>
   output to generate a ~22MHz clock. I would expect the use of a
   pwm-clock node [3].

 Also another remark on both OV5642 and OV5640 patches, is it recommended
 to use 0x8000 pin muxing value? This leaves it to the bootloader to
>>>
>>> I also wondered about this, but didn't know if the pinmux driver did this
>>> based on the define name? I tried it both ways and it worked so I just left
>>> it as it was.
>>
>> Actually my phrasing is wrong, the muxing is ok. Yes depending on the
>> name a pin will be muxed to one function or another. The problem is the
>> pad configuration (pull-up, pull-down etc..). I am not surprised that it
>> works, because the bootloader should properly set those. But it would be
>> safer IMO not to rely on it.
>
> Ah ok, makes sense.
>
>>
>> Regards,
>> Gary
>>
>> [1] https://boundarydevices.com/product/nit6x_5mp_mipi/
>>

--
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 22/24 v1.1] v4l: vsp1: wpf: Add flipping support

2016-06-21 Thread Laurent Pinchart

Vertical flipping is available on both Gen2 and Gen3, while horizontal
flipping is only available on Gen3.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Initialize the wpf.flip.lock spinlock

Geert, I've updated the for/renesas-drivers branch with this patch. Could you
please include it in renesas-drivers ?

diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index f5e58cea36cc..a9b1d251f71a 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -50,6 +50,8 @@ struct vsp1_uds;
 #define VSP1_HAS_BRU   (1 << 3)
 #define VSP1_HAS_HGO   (1 << 4)
 #define VSP1_HAS_CLU   (1 << 5)
+#define VSP1_HAS_WPF_VFLIP (1 << 6)
+#define VSP1_HAS_WPF_HFLIP (1 << 7)
 
 struct vsp1_device_info {
u32 version;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 7e5bd48db2d6..dae1fa47acd7 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -585,7 +585,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPS_H2,
.gen = 2,
.features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO
- | VSP1_HAS_LUT | VSP1_HAS_SRU,
+ | VSP1_HAS_LUT | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.uds_count = 3,
.wpf_count = 4,
@@ -594,7 +594,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
}, {
.version = VI6_IP_VERSION_MODEL_VSPR_H2,
.gen = 2,
-   .features = VSP1_HAS_BRU | VSP1_HAS_SRU,
+   .features = VSP1_HAS_BRU | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.uds_count = 3,
.wpf_count = 4,
@@ -614,7 +614,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPS_M2,
.gen = 2,
.features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO
- | VSP1_HAS_LUT | VSP1_HAS_SRU,
+ | VSP1_HAS_LUT | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.uds_count = 1,
.wpf_count = 4,
@@ -624,7 +624,8 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPI_GEN3,
.gen = 3,
.features = VSP1_HAS_CLU | VSP1_HAS_HGO | VSP1_HAS_LUT
- | VSP1_HAS_SRU,
+ | VSP1_HAS_SRU | VSP1_HAS_WPF_HFLIP
+ | VSP1_HAS_WPF_VFLIP,
.rpf_count = 1,
.uds_count = 1,
.wpf_count = 1,
@@ -632,7 +633,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
}, {
.version = VI6_IP_VERSION_MODEL_VSPBD_GEN3,
.gen = 3,
-   .features = VSP1_HAS_BRU,
+   .features = VSP1_HAS_BRU | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.wpf_count = 1,
.num_bru_inputs = 5,
@@ -641,7 +642,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPBC_GEN3,
.gen = 3,
.features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO
- | VSP1_HAS_LUT,
+ | VSP1_HAS_LUT | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.wpf_count = 1,
.num_bru_inputs = 5,
@@ -649,7 +650,7 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
}, {
.version = VI6_IP_VERSION_MODEL_VSPD_GEN3,
.gen = 3,
-   .features = VSP1_HAS_BRU | VSP1_HAS_LIF,
+   .features = VSP1_HAS_BRU | VSP1_HAS_LIF | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
.wpf_count = 2,
.num_bru_inputs = 5,
diff --git a/drivers/media/platform/vsp1/vsp1_regs.h 
b/drivers/media/platform/vsp1/vsp1_regs.h
index 517a2a6606a3..d8213481edbe 100644
--- a/drivers/media/platform/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -255,6 +255,8 @@
 #define VI6_WPF_OUTFMT_PDV_MASK(0xff << 24)
 #define VI6_WPF_OUTFMT_PDV_SHIFT   24
 #define VI6_WPF_OUTFMT_PXA (1 << 23)
+#define VI6_WPF_OUTFMT_ROT (1 << 18)
+#define VI6_WPF_OUTFMT_HFLP(1 << 17)
 #define VI6_WPF_OUTFMT_FLP (1 << 16)
 #define VI6_WPF_OUTFMT_SPYCS   (1 << 15)
 #define VI6_WPF_OUTFMT_SPUVS   (1 << 14)
@@ -289,6 +291,11 @@
 #define VI6_WPF_RNDCTRL_CLMD_EXT   (2 << 12)
 #define VI6_WPF_RNDCTRL_CLMD_MASK  (3 << 12)
 
+#define VI6_WPF_ROT_CTRL   0x1018
+#define

Re: [PATCH] leds: Add no-op gpio_led_register_device when LED subsystem is disabled

2016-06-21 Thread Jacek Anaszewski


On 06/21/2016 01:48 PM, Andrew F. Davis wrote:

On 06/21/2016 02:09 AM, Jacek Anaszewski wrote:

Hi Andrew,

This patch doesn't apply, please rebase onto recent LED tree.

On 06/21/2016 12:13 AM, Andrew F. Davis wrote:

Some systems use 'gpio_led_register_device' to make an in-memory copy of
their LED device table so the original can be removed as .init.rodata.
When the LED subsystem is not enabled source in the led directory is not
built and so this function may be undefined. Fix this here.

Signed-off-by: Andrew F. Davis 
---
   include/linux/leds.h | 8 
   1 file changed, 8 insertions(+)

diff --git a/include/linux/leds.h b/include/linux/leds.h
index d2b1306..a4a3da6 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -386,8 +386,16 @@ struct gpio_led_platform_data {
  unsigned long *delay_off);


Currently there is some stuff here, and in fact it has been for
a long time.

Patch "[PATCH 12/12] leds: Only descend into leds directory when
CONFIG_NEW_LEDS is set" also doesn't apply.
What repository are you using?



v4.7-rc4, it may not apply due to the surrounding lines being changed in
the other patches which may not be applied to your tree. It is a single
line change per patch so hopefully the merge conflict resolutions will
be trivial.

A better solution could have been getting an ack from each maintainer
and having someone pull the whole series into one tree, but parts have
already been picked so it may be a little late for that.


OK, I resolved the issues and applied, thanks.


   };

+#ifdef CONFIG_NEW_LEDS
   struct platform_device *gpio_led_register_device(
  int id, const struct gpio_led_platform_data *pdata);
+#else
+static inline struct platform_device *gpio_led_register_device(
+   int id, const struct gpio_led_platform_data *pdata)
+{
+   return 0;
+}
+#endif

   enum cpu_led_event {
  CPU_LED_IDLE_START, /* CPU enters idle */










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

Re: [PATCH] leds: Add no-op gpio_led_register_device when LED subsystem is disabled

2016-06-21 Thread Andrew F. Davis

On 06/21/2016 02:09 AM, Jacek Anaszewski wrote:
> Hi Andrew,
> 
> This patch doesn't apply, please rebase onto recent LED tree.
> 
> On 06/21/2016 12:13 AM, Andrew F. Davis wrote:
>> Some systems use 'gpio_led_register_device' to make an in-memory copy of
>> their LED device table so the original can be removed as .init.rodata.
>> When the LED subsystem is not enabled source in the led directory is not
>> built and so this function may be undefined. Fix this here.
>>
>> Signed-off-by: Andrew F. Davis 
>> ---
>>   include/linux/leds.h | 8 
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/include/linux/leds.h b/include/linux/leds.h
>> index d2b1306..a4a3da6 100644
>> --- a/include/linux/leds.h
>> +++ b/include/linux/leds.h
>> @@ -386,8 +386,16 @@ struct gpio_led_platform_data {
>>  unsigned long *delay_off);
> 
> Currently there is some stuff here, and in fact it has been for
> a long time.
> 
> Patch "[PATCH 12/12] leds: Only descend into leds directory when
> CONFIG_NEW_LEDS is set" also doesn't apply.
> What repository are you using?
> 

v4.7-rc4, it may not apply due to the surrounding lines being changed in
the other patches which may not be applied to your tree. It is a single
line change per patch so hopefully the merge conflict resolutions will
be trivial.

A better solution could have been getting an ack from each maintainer
and having someone pull the whole series into one tree, but parts have
already been picked so it may be a little late for that.

>>   };
>>
>> +#ifdef CONFIG_NEW_LEDS
>>   struct platform_device *gpio_led_register_device(
>>  int id, const struct gpio_led_platform_data *pdata);
>> +#else
>> +static inline struct platform_device *gpio_led_register_device(
>> +   int id, const struct gpio_led_platform_data *pdata)
>> +{
>> +   return 0;
>> +}
>> +#endif
>>
>>   enum cpu_led_event {
>>  CPU_LED_IDLE_START, /* CPU enters idle */
>>
> 
> 
--
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 22/24] v4l: vsp1: wpf: Add flipping support

2016-06-21 Thread Geert Uytterhoeven

Hi Laurent,

On Mon, Jun 20, 2016 at 9:10 PM, Laurent Pinchart
 wrote:
> Vertical flipping is available on both Gen2 and Gen3, while horizontal
> flipping is only available on Gen3.
>
> Signed-off-by: Laurent Pinchart 

> --- a/drivers/media/platform/vsp1/vsp1_wpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_wpf.c
> @@ -37,6 +37,95 @@ static inline void vsp1_wpf_write(struct vsp1_rwpf *wpf,
>  }
>
>  /* 
> -
> + * Controls
> + */
> +
> +enum wpf_flip_ctrl {
> +   WPF_CTRL_VFLIP = 0,
> +   WPF_CTRL_HFLIP = 1,
> +   WPF_CTRL_MAX,
> +};
> +
> +static int vsp1_wpf_s_ctrl(struct v4l2_ctrl *ctrl)
> +{
> +   struct vsp1_rwpf *wpf =
> +   container_of(ctrl->handler, struct vsp1_rwpf, ctrls);
> +   unsigned int i;
> +   u32 flip = 0;
> +
> +   switch (ctrl->id) {
> +   case V4L2_CID_HFLIP:
> +   case V4L2_CID_VFLIP:
> +   for (i = 0; i < WPF_CTRL_MAX; ++i) {
> +   if (wpf->flip.ctrls[i])
> +   flip |= wpf->flip.ctrls[i]->val ? BIT(i) : 0;
> +   }
> +
> +   spin_lock_irq(>flip.lock);

This spinlock doesn't seem to be initialized, or has been corrupted since
initialization:

+BUG: spinlock bad magic on CPU#1, swapper/0/1
+ lock: 0xeefa5a40, .magic: , .owner: /-1, .owner_cpu: 0
+CPU: 1 PID: 1 Comm: swapper/0 Not tainted
4.7.0-rc4-koelsch-03172-gb64ace16149cf394 #2802
+Hardware name: Generic R8A7791 (Flattened Device Tree)
+[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
+[] (show_stack) from [] (dump_stack+0x7c/0x9c)
+[] (dump_stack) from [] (do_raw_spin_lock+0x20/0x190)
+[] (do_raw_spin_lock) from [] (vsp1_wpf_s_ctrl+0x60/0x80)
+[] (vsp1_wpf_s_ctrl) from []
(v4l2_ctrl_handler_setup+0xe0/0x104)
+[] (v4l2_ctrl_handler_setup) from []
(vsp1_wpf_create+0x1b8/0x1f4)
+[] (vsp1_wpf_create) from [] (vsp1_probe+0x4dc/0x854)
+[] (vsp1_probe) from [] (platform_drv_probe+0x50/0xa0)
+[] (platform_drv_probe) from []
(driver_probe_device+0x134/0x29c)
+[] (driver_probe_device) from []
(__driver_attach+0x80/0xa4)
+[] (__driver_attach) from [] (bus_for_each_dev+0x6c/0x90)
+[] (bus_for_each_dev) from [] (bus_add_driver+0xc8/0x1e4)
+[] (bus_add_driver) from [] (driver_register+0x9c/0xe0)
+[] (driver_register) from [] (do_one_initcall+0xac/0x150)
+[] (do_one_initcall) from []
(kernel_init_freeable+0x124/0x1ec)
+[] (kernel_init_freeable) from [] (kernel_init+0x8/0x110)
+[] (kernel_init) from [] (ret_from_fork+0x14/0x2c)

Also seen on Salvator-X.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma-buf: Wait on the reservation object when sync'ing before CPU access

2016-06-21 Thread Daniel Vetter

On Tue, Jun 21, 2016 at 08:04:00AM +0100, Chris Wilson wrote:
> Rendering operations to the dma-buf are tracked implicitly via the
> reservation_object (dmabuf->resv). This is used to allow poll() to
> wait upon outstanding rendering (or just query the current status of
> rendering). The dma-buf sync ioctl allows userspace to prepare the
> dma-buf for CPU access, which should include waiting upon rendering.
> (Some drivers may need to do more work to ensure that the dma-buf mmap
> is coherent as well as complete.)
>
> Signed-off-by: Chris Wilson 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> Cc: linux-media@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-ker...@vger.kernel.org
> ---
>
> I'm wondering whether it makes sense just to always do the wait first.
> It is one of the first operations every driver has to make. A driver
> that wants to implement it differently (e.g. they can special case
> native waits) will still require a wait on the reservation object to
> finish external rendering.

Worst case (if the driver uses reservation objects also internally) we'll
end up calling this twice. It should be cheap enough to do that. I'll add
a few folks who might want to chip in with an opinion ...
-Daniel

> -Chris
>
> ---
>  drivers/dma-buf/dma-buf.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index ddaee60ae52a..123f14b8e882 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -586,6 +586,22 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
> *attach,
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>
> +static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
> +  enum dma_data_direction direction)
> +{
> + bool write = (direction == DMA_BIDIRECTIONAL ||
> +  direction == DMA_TO_DEVICE);
> + struct reservation_object *resv = dma_buf->resv;
> + long ret;
> +
> + /* Wait on any implicit rendering fences */
> + ret = reservation_object_wait_timeout_rcu(resv, write, true,
> +  MAX_SCHEDULE_TIMEOUT);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
>
>  /**
>   * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from 
> the
> @@ -607,6 +623,8 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>
>   if (dmabuf->ops->begin_cpu_access)
>   ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
> + else
> + ret = __dma_buf_begin_cpu_access(dmabuf, direction);
>
>   return ret;
>  }
> --
> 2.8.1
>

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thread dvb-t

2016-06-21 Thread W.Pelser


At  2015-12-17  I sent this to you:

https://bugzilla.kernel.org/show_bug.cgi?id=109521 > > Bug ID: 109521 > 
Summary: kernel 4.4-RCx does not connect DVB-T USB Stick during > resume 
from hibernate This is a regression, because the earlier desktop-kernel 
did not have this bug. It came up with default-kernel. Is there any 
chance for me to get it fixed, or can I forget it?



--
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] dma-buf: Wait on the reservation object when sync'ing before CPU access

2016-06-21 Thread Chris Wilson

Rendering operations to the dma-buf are tracked implicitly via the
reservation_object (dmabuf->resv). This is used to allow poll() to
wait upon outstanding rendering (or just query the current status of
rendering). The dma-buf sync ioctl allows userspace to prepare the
dma-buf for CPU access, which should include waiting upon rendering.
(Some drivers may need to do more work to ensure that the dma-buf mmap
is coherent as well as complete.)

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
Cc: linux-media@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-ker...@vger.kernel.org
---

I'm wondering whether it makes sense just to always do the wait first.
It is one of the first operations every driver has to make. A driver
that wants to implement it differently (e.g. they can special case
native waits) will still require a wait on the reservation object to
finish external rendering.
-Chris

---
 drivers/dma-buf/dma-buf.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ddaee60ae52a..123f14b8e882 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -586,6 +586,22 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
*attach,
 }
 EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
 
+static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+ enum dma_data_direction direction)
+{
+   bool write = (direction == DMA_BIDIRECTIONAL ||
+ direction == DMA_TO_DEVICE);
+   struct reservation_object *resv = dma_buf->resv;
+   long ret;
+
+   /* Wait on any implicit rendering fences */
+   ret = reservation_object_wait_timeout_rcu(resv, write, true,
+ MAX_SCHEDULE_TIMEOUT);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
 
 /**
  * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from 
the
@@ -607,6 +623,8 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
 
if (dmabuf->ops->begin_cpu_access)
ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
+   else
+   ret = __dma_buf_begin_cpu_access(dmabuf, direction);
 
return ret;
 }
-- 
2.8.1

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

Re: ERROR: "bad_dma_ops" [sound/core/snd-pcm.ko] undefined!

2016-06-21 Thread Fengguang Wu

> > config: m32r-allmodconfig (attached as .config)
> > compiler: m32r-linux-gcc (GCC) 4.9.0
> 
> You are using 4.9.0 ? If you want you can get 5.3.0 from:
> http://chat.vectorindia.net/crosstool/x86_64/5.3.0/m32r-linux.tar.xz

Glad to know that! Philip will help pull the new version.

Thanks,
Fengguang
--
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] leds: Add no-op gpio_led_register_device when LED subsystem is disabled

2016-06-21 Thread Jacek Anaszewski


Hi Andrew,

This patch doesn't apply, please rebase onto recent LED tree.

On 06/21/2016 12:13 AM, Andrew F. Davis wrote:

Some systems use 'gpio_led_register_device' to make an in-memory copy of
their LED device table so the original can be removed as .init.rodata.
When the LED subsystem is not enabled source in the led directory is not
built and so this function may be undefined. Fix this here.

Signed-off-by: Andrew F. Davis 
---
  include/linux/leds.h | 8 
  1 file changed, 8 insertions(+)

diff --git a/include/linux/leds.h b/include/linux/leds.h
index d2b1306..a4a3da6 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -386,8 +386,16 @@ struct gpio_led_platform_data {
 unsigned long *delay_off);


Currently there is some stuff here, and in fact it has been for
a long time.

Patch "[PATCH 12/12] leds: Only descend into leds directory when
CONFIG_NEW_LEDS is set" also doesn't apply.
What repository are you using?


  };

+#ifdef CONFIG_NEW_LEDS
  struct platform_device *gpio_led_register_device(
 int id, const struct gpio_led_platform_data *pdata);
+#else
+static inline struct platform_device *gpio_led_register_device(
+   int id, const struct gpio_led_platform_data *pdata)
+{
+   return 0;
+}
+#endif

  enum cpu_led_event {
 CPU_LED_IDLE_START, /* CPU enters idle */




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

Re: ERROR: "bad_dma_ops" [sound/core/snd-pcm.ko] undefined!

2016-06-21 Thread Sudip Mukherjee


On Sunday 19 June 2016 05:15 AM, kbuild test robot wrote:

Hi,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   c141afd1a28793c08c88325aa64b773be6f79ccf
commit: 420520766a796d3607639ba1e4fb1aadeadd [media] media: Kconfig: add 
dependency of HAS_DMA
date:   5 months ago
config: m32r-allmodconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 4.9.0


You are using 4.9.0 ? If you want you can get 5.3.0 from: 
http://chat.vectorindia.net/crosstool/x86_64/5.3.0/m32r-linux.tar.xz




reproduce:
 wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
 chmod +x ~/bin/make.cross
 git checkout 420520766a796d3607639ba1e4fb1aadeadd
 # save the attached .config to linux build tree
 make.cross ARCH=m32r

All errors (new ones prefixed by >>):


These are not new errors, old errors which now appears because the 
previous error was solved.




ERROR: "bad_dma_ops" [sound/soc/qcom/snd-soc-lpass-platform.ko] undefined!
ERROR: "dma_common_mmap" [sound/soc/qcom/snd-soc-lpass-platform.ko] 
undefined!
ERROR: "bad_dma_ops" [sound/soc/kirkwood/snd-soc-kirkwood.ko] undefined!
ERROR: "bad_dma_ops" [sound/soc/fsl/snd-soc-fsl-asrc.ko] undefined!
ERROR: "bad_dma_ops" [sound/soc/atmel/snd-soc-atmel-pcm-pdc.ko] undefined!

ERROR: "bad_dma_ops" [sound/core/snd-pcm.ko] undefined!
ERROR: "dma_common_mmap" [sound/core/snd-pcm.ko] undefined!


These are still there and I need to do something about them.


ERROR: "__ucmpdi2" [lib/842/842_decompress.ko] undefined!
ERROR: "__ucmpdi2" [fs/btrfs/btrfs.ko] undefined!


Patch for these is submitted and should be in Andrew's tree now. But i 
dont see them in linux-next. I think I will ping Andrew asking him.



ERROR: "bad_dma_ops" [drivers/usb/host/xhci-plat-hcd.ko] undefined!



ERROR: "dma_pool_create" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "smp_flush_cache_all" [drivers/misc/lkdtm.ko] undefined!

ERROR: "__ucmpdi2" [drivers/media/i2c/adv7842.ko] undefined!
ERROR: "__ucmpdi2" [drivers/md/bcache/bcache.ko] undefined!
ERROR: "__ucmpdi2" [drivers/iio/imu/inv_mpu6050/inv-mpu6050.ko] undefined!


same reply as above.


ERROR: "bad_dma_ops" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined!
ERROR: "bad_dma_ops" [drivers/hwtracing/intel_th/intel_th.ko] undefined!

ERROR: "bad_dma_ops" [drivers/fpga/zynq-fpga.ko] undefined!


iirc, it is fixed now.

regards
sudip
--
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: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

2016-06-21 Thread Takashi Iwai

On Tue, 21 Jun 2016 08:38:57 +0200,
Richard Cochran wrote:
> 
> On Tue, Jun 21, 2016 at 07:54:32AM +0200, Takashi Iwai wrote:
> > > I still would appreciate an answer to my other questions, though...
> > 
> > Currently HD-audio (both ASoC and legacy ones) are the only drivers
> > providing the link timestamp.  In the recent code, it's PCM
> > get_time_info ops, so you can easily grep it.
> 
> Yes, I found that myself, thanks.
>  
> > HTH,
> 
> No it doesn't help me, because I asked three questions, and none were
> about the link timestamp.

??  The extended audio timpestamp is essentially to return the link
timestamp.  Just the term has changed along time...


Takashi
--
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: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

2016-06-21 Thread Richard Cochran

On Tue, Jun 21, 2016 at 07:54:32AM +0200, Takashi Iwai wrote:
> > I still would appreciate an answer to my other questions, though...
> 
> Currently HD-audio (both ASoC and legacy ones) are the only drivers
> providing the link timestamp.  In the recent code, it's PCM
> get_time_info ops, so you can easily grep it.

Yes, I found that myself, thanks.
 
> HTH,

No it doesn't help me, because I asked three questions, and none were
about the link timestamp.

Thanks,
Richard
--
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 1/7] v4l: Correct the ordering of LSBs of the 10-bit raw packed formats

2016-06-21 Thread Hans Verkuil

On 06/20/2016 10:38 PM, Dave Stevenson wrote:
> Hi Hans.
> 
> On 20/06/16 18:03, Hans Verkuil wrote:
>> On 06/20/2016 06:20 PM, Sakari Ailus wrote:
>>> The 10-bit packed raw bayer format documented that the data of the first
>>> pixel of a four-pixel group was found in the first byte and the two
>>> highest bits of the fifth byte. This was not entirely correct. The two
>>> bits in the fifth byte are the two lowest bits. The second pixel occupies
>>> the second byte and third and fourth least significant bits and so on.
>>>
>>> Signed-off-by: Sakari Ailus 
>> As mentioned, this needs confirmation. I wonder, isn't this specified in the 
>> UVC
>> spec?

I can't find anything in the uvc spec. This format was apparently added for an
Intel R200 3D camera, so I suspect it followed the SMIA/CSI standard and that
the doc is indeed wrong.

So:

Acked-by: Hans Verkuil 

Regards,

Hans

>>
>> Regards,
>>
>>  Hans
> I'm assuming this is intended to be the same format as generated by many 
> Bayer sensors.
> Those are defined in both the SMIA CCP2 (section 7.9), and MIPI CSI2 
> (section 11.4.4) specs. Whilst nominally restricted, they are both 
> available via unofficial websites if you Google for them (I'm happy to 
> send links, but didn't want to break mailing list rules by just posting 
> them).
> CSI2 draft spec Figure 98 "RAW10 Data Transmission on CSI-2 Bus Bitwise 
> Illustration" is probably the clearest confirmation of the bit ordering.
> 
> dcraw from http://www.cybercom.net/~dcoffin/dcraw/ can consume Raw10 via 
> nokia_load_raw
>  for (dp=data, col=0; col < raw_width; dp+=5, col+=4)
>FORC4 RAW(row,col+c) = (dp[c] << 2) | (dp[4] >> (c << 1) & 3);
> 
> And checking against the Raspberry Pi hardware simulator, the RAW10 
> parser code has
>  for (i = 0; i < width; i++) {
> switch ((i + tile_x) & 3) {
>case 0:  val = (buf[0] << 2) | (buf[4] & 3); break;
>case 1:  val = (buf[1] << 2) | ((buf[4] >> 2) & 3); 
> break;
>case 2:  val = (buf[2] << 2) | ((buf[4] >> 4) & 3); 
> break;
>default: val = (buf[3] << 2) | ((buf[4] >> 6) & 3);
> 
> 
> All of those agree with Sakari's update that the first pixel's LSBits 
> are in bits 1..0 of byte 5, 2nd pixel in bits 3..2, etc.
> 
> Regards,
>Dave
> (working on the Pi CSI2 receiver V4L2 driver as there is now sufficient 
> data in the public domain to do it. I'll be wanting these formats!)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: OK

[PATCH 2/2] [media] v4l: subdev: move s_stream from v4l2_subdev_video_ops to v4l2_subdev_pad_ops

[PATCH 0/2] move s_stream from v4l2_subdev_video_ops to move s_stream from v4l2_subdev_pad_ops

[PATCH 1/2] [media] v4l: vsp1: Split pad operations between rpf and wpf

[PATCH] media: s5p-mfc fix null pointer deference in clk_core_enable()

Re: camera application for testing (was Re: v4l subdevs without big device)

Re: camera application for testing (was Re: v4l subdevs without big device)

Re: [PATCH v4 9/9] Input: synaptics-rmi4 - add support for F54 diagnostics

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

Re: Nokia N900 cameras -- pipeline setup in python (was Re: [RFC PATCH 00/24] Make Nokia N900 cameras working)

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

Re: [19/38] ARM: dts: imx6-sabrelite: add video capture ports and connections

[PATCH 22/24 v1.1] v4l: vsp1: wpf: Add flipping support

Re: [PATCH] leds: Add no-op gpio_led_register_device when LED subsystem is disabled

Re: [PATCH] leds: Add no-op gpio_led_register_device when LED subsystem is disabled

Re: [PATCH 22/24] v4l: vsp1: wpf: Add flipping support

Re: [PATCH] dma-buf: Wait on the reservation object when sync'ing before CPU access

Thread dvb-t

[PATCH] dma-buf: Wait on the reservation object when sync'ing before CPU access

Re: ERROR: "bad_dma_ops" [sound/core/snd-pcm.ko] undefined!

Re: [PATCH] leds: Add no-op gpio_led_register_device when LED subsystem is disabled

Re: ERROR: "bad_dma_ops" [sound/core/snd-pcm.ko] undefined!

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

Re: [PATCH v2 1/7] v4l: Correct the ordering of LSBs of the 10-bit raw packed formats

26 matches

Site Navigation

Mail list logo

Footer information