[PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

[Joe Perches]

There are ~4300 uses of pr_warn and ~250 uses of the older
pr_warning in the kernel source tree.

Make the use of pr_warn consistent across all kernel files.

This excludes all files in tools/ as there is a separate
define pr_warning for that directory tree and pr_warn is
not used in tools/.

Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.

Miscellanea:

o Coalesce formats and realign arguments

Some files not compiled - no cross-compilers

Joe Perches (35):
  alpha: Convert remaining uses of pr_warning to pr_warn
  ARM: ep93xx: Convert remaining uses of pr_warning to pr_warn
  arm64: Convert remaining uses of pr_warning to pr_warn
  arch/blackfin: Convert remaining uses of pr_warning to pr_warn
  ia64: Convert remaining use of pr_warning to pr_warn
  powerpc: Convert remaining uses of pr_warning to pr_warn
  sh: Convert remaining uses of pr_warning to pr_warn
  sparc: Convert remaining use of pr_warning to pr_warn
  x86: Convert remaining uses of pr_warning to pr_warn
  drivers/acpi: Convert remaining uses of pr_warning to pr_warn
  block/drbd: Convert remaining uses of pr_warning to pr_warn
  gdrom: Convert remaining uses of pr_warning to pr_warn
  drivers/char: Convert remaining use of pr_warning to pr_warn
  clocksource: Convert remaining use of pr_warning to pr_warn
  drivers/crypto: Convert remaining uses of pr_warning to pr_warn
  fmc: Convert remaining use of pr_warning to pr_warn
  drivers/gpu: Convert remaining uses of pr_warning to pr_warn
  drivers/ide: Convert remaining uses of pr_warning to pr_warn
  drivers/input: Convert remaining uses of pr_warning to pr_warn
  drivers/isdn: Convert remaining uses of pr_warning to pr_warn
  drivers/macintosh: Convert remaining uses of pr_warning to pr_warn
  drivers/media: Convert remaining use of pr_warning to pr_warn
  drivers/mfd: Convert remaining uses of pr_warning to pr_warn
  drivers/mtd: Convert remaining uses of pr_warning to pr_warn
  drivers/of: Convert remaining uses of pr_warning to pr_warn
  drivers/oprofile: Convert remaining uses of pr_warning to pr_warn
  drivers/platform: Convert remaining uses of pr_warning to pr_warn
  drivers/rapidio: Convert remaining use of pr_warning to pr_warn
  drivers/scsi: Convert remaining use of pr_warning to pr_warn
  drivers/sh: Convert remaining use of pr_warning to pr_warn
  drivers/tty: Convert remaining uses of pr_warning to pr_warn
  drivers/video: Convert remaining uses of pr_warning to pr_warn
  kernel/trace: Convert remaining uses of pr_warning to pr_warn
  lib: Convert remaining uses of pr_warning to pr_warn
  sound/soc: Convert remaining uses of pr_warning to pr_warn

 arch/alpha/kernel/perf_event.c |  4 +-
 arch/arm/mach-ep93xx/core.c|  4 +-
 arch/arm64/include/asm/syscall.h   |  8 ++--
 arch/arm64/kernel/hw_breakpoint.c  |  8 ++--
 arch/arm64/kernel/smp.c|  4 +-
 arch/blackfin/kernel/nmi.c |  2 +-
 arch/blackfin/kernel/ptrace.c  |  2 +-
 arch/blackfin/mach-bf533/boards/stamp.c|  2 +-
 arch/blackfin/mach-bf537/boards/cm_bf537e.c|  2 +-
 arch/blackfin/mach-bf537/boards/cm_bf537u.c|  2 +-
 arch/blackfin/mach-bf537/boards/stamp.c|  2 +-
 arch/blackfin/mach-bf537/boards/tcm_bf537.c|  2 +-
 arch/blackfin/mach-bf561/boards/cm_bf561.c |  2 +-
 arch/blackfin/mach-bf561/boards/ezkit.c|  2 +-
 arch/blackfin/mm/isram-driver.c|  4 +-
 arch/ia64/kernel/setup.c   |  6 +--
 arch/powerpc/kernel/pci-common.c   |  4 +-
 arch/powerpc/mm/init_64.c  |  5 +--
 arch/powerpc/mm/mem.c  |  3 +-
 arch/powerpc/platforms/512x/mpc512x_shared.c   |  4 +-
 arch/powerpc/platforms/85xx/socrates_fpga_pic.c|  7 ++--
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |  2 +-
 arch/powerpc/platforms/pasemi/dma_lib.c|  4 +-
 arch/powerpc/platforms/powernv/opal.c  |  8 ++--
 arch/powerpc/platforms/powernv/pci-ioda.c  | 10 ++---
 arch/powerpc/platforms/ps3/device-init.c   | 14 +++
 arch/powerpc/platforms/ps3/mm.c|  4 +-
 arch/powerpc/platforms/ps3/os-area.c   |  2 +-
 arch/powerpc/platforms/pseries/iommu.c |  8 ++--
 arch/powerpc/platforms/pseries/setup.c |  4 +-
 arch/powerpc/sysdev/fsl_pci.c  |  9 ++---
 arch/powerpc/sysdev/mpic.c | 10 ++---
 arch/powerpc/sysdev/xics/icp-native.c  | 10 ++---
 arch/powerpc/sysdev/xics/ics-opal.c|  4 +-
 arch/powerpc/sysdev/xics/ics-rtas.c|  4 +-
 arch/powerpc/sysdev/xics/xics-common.c |  8 ++--
 arch/sh/boards/mach-sdk7786/nmi.c  |  2 +-
 arch/sh/drivers/pci/fixups-sdk7786.c   |  2 +-
 arch/sh/kernel/io_trapped.c

[PATCH 22/35] drivers/media: Convert remaining use of pr_warning to pr_warn

[Joe Perches]

To enable eventual removal of pr_warning

This makes pr_warn use consistent for drivers/media

Prior to this patch, there was 1 use of pr_warning and
310 uses of pr_warn in drivers/media

Signed-off-by: Joe Perches 
---
 drivers/media/platform/sh_vou.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c
index ef2a519bcd4c..992d61a8b961 100644
--- a/drivers/media/platform/sh_vou.c
+++ b/drivers/media/platform/sh_vou.c
@@ -813,8 +813,8 @@ static u32 sh_vou_ntsc_mode(enum sh_vou_bus_fmt bus_fmt)
 {
switch (bus_fmt) {
default:
-   pr_warning("%s(): Invalid bus-format code %d, using default 
8-bit\n",
-  __func__, bus_fmt);
+   pr_warn("%s(): Invalid bus-format code %d, using default 
8-bit\n",
+   __func__, bus_fmt);
case SH_VOU_BUS_8BIT:
return 1;
case SH_VOU_BUS_16BIT:
-- 
2.10.0.rc2.1.g053435c

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:   Fri Feb 17 05:00:18 CET 2017
media-tree git hash:9eeb0ed0f30938f31a3d9135a88b9502192c18dd
media_build git hash:   785cdf7f0798964681b33aad44fc2ff4d734733d
v4l-utils git hash: 1edd6920bed585d0ea70a2d400182ba17ee2e7fc
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: WARNINGS
linux-3.12.67-i686: WARNINGS
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: WARNINGS
linux-3.12.67-x86_64: WARNINGS
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/Friday.log

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Dead code in v4l2-mem2mem.c?

[Shaobo]

Hi there,

My name is Shaobo He and I am a graduate student at University of Utah. 
I am applying a static analysis tool to the Linux device drivers, 
looking for NULL pointer dereference and accidentally found a plausible 
dead code location in v4l2-mem2mem.c due to undefined behavior.


The following is the problematic code segment 
(drivers/media/v4l2-core/v4l2-mem2mem.c),


70 static struct v4l2_m2m_queue_ctx *get_queue_ctx(struct v4l2_m2m_ctx 
*m2m_ctx,
71 enum v4l2_buf_type 
type)

72 {
73 if (V4L2_TYPE_IS_OUTPUT(type))
74 return _ctx->out_q_ctx;
75 else
76 return _ctx->cap_q_ctx;
77 }
78
79 struct vb2_queue *v4l2_m2m_get_vq(struct v4l2_m2m_ctx *m2m_ctx,
80enum v4l2_buf_type type)
81 {
82 struct v4l2_m2m_queue_ctx *q_ctx;
83
84 q_ctx = get_queue_ctx(m2m_ctx, type);
85 if (!q_ctx)
86 return NULL;
87
88 return _ctx->q;
89 }


`get_queue_ctx` returns a pointer value that is an addition of the base 
pointer address (`m2m_ctx`) to a non-zero offset. The following is the 
definition of struct v4l2_m2m_ctx (include/media/v4l2-mem2mem.h),



94 struct v4l2_m2m_ctx {
95 /* optional cap/out vb2 queues lock */
96 struct mutex*q_lock;
97
98 /* internal use only */
99 struct v4l2_m2m_dev *m2m_dev;
100
101 struct v4l2_m2m_queue_ctx   cap_q_ctx;
102
103 struct v4l2_m2m_queue_ctx   out_q_ctx;
104
105 /* For device job queue */
106 struct list_headqueue;
107 unsigned long   job_flags;
108 wait_queue_head_t   finished;
109
110 void*priv;
111 };


There is a NULL test in a caller of `get_queue_ctx` (line 85), which 
appears problematic to me. I’m not sure if it is defined or feasible 
under the context of Linux kernel. This blog 
(https://wdtz.org/undefined-behavior-in-binutils-causes-segfault.html) 
suggests that the NULL check can be optimized away because the only case 
that the return value can be NULL triggers pointer overflow, which is 
undefined.


Please let me know if it makes sense or not. Thanks for your time and I 
am looking forward to your reply.


Best,
Shaobo

Re: [PATCH 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Nicolas Dufresne]

Le mardi 14 février 2017 à 08:51 +0100, Marek Szyprowski a écrit :
> Dear All,
> 
> This patchset is a result of my work on enabling full support for MFC device
> (multimedia codec) on Exynos 5433 on ARM64 architecture. Initially I thought
> that to let it working on ARM64 architecture with IOMMU, I would need to
> solve the issue related to the fact that s5p-mfc driver was depending on the
> first-fit allocation method in the DMA-mapping / IOMMU glue code (ARM64 use
> different algorithm). It turned out, that there is a much simpler way.
> 
> During my research I found that some of the requirements for the memory
> buffers for MFC v6+ devices were blindly copied from the previous
> hardware (v5) version and simply turned out to be excessive. It turned out
> that there is no strict requirement for ALL buffers to be allocated on
> the higher addresses than the firmware base. This requirement is true only
> for the device and per-context buffers. All video data buffers can be
> allocated anywhere for all MFC v6+ versions. This heavily simplifies
> memory management in the driver.
> 
> Such relaxed requirements for the memory buffers can be easily fulfilled
> by allocating firmware, device and per-context buffers from the probe-time
> preallocated larger buffer. There is no need to create special reserved
> memory regions. The only case, when those memory regions are needed is an
> oldest Exynos series - Exynos4210 or Exyno4412, which both have MFC v5
> hardware, and only when IOMMU is disabled.
> 
> This patchset has been tested on Odroid U3 (Exynos4412 with MFC v5), Google
> Snow (Exynos5250 with MFC v6), Odroid XU3 (Exynos5422 with MFC v8) and
> TM2 (Exynos5433 with MFC v8, ARM64) boards.
> 
> To get it working on TM2/Exynos5433 with IOMMU enabled, the 'architectural
> clock gating' in SYSMMU has to be disabled. Fixing this will be handled
> separately. As a temporary solution, one need to clear CFG_ACGEN bit in
> REG_MMU_CFG of the SYSMMU, see __sysmmu_init_config function in
> drivers/iommu/exynos-iommu.c.
> 
> Patches are based on linux-next from 9th February 2017 with "media:
> s5p-mfc: Fix initialization of internal structures" patch applied:
> https://patchwork.linuxtv.org/patch/39198/
> 
> I've tried to split changes into small pieces to make it easier to review
> the code. I've also did a bit of cleanup while touching the driver.
> 
> Best regards
> Marek Szyprowski
> Samsung R Institute Poland
> 
> 
> Patch summary:
> 
> Marek Szyprowski (15):
>   media: s5p-mfc: Remove unused structures and dead code
>   media: s5p-mfc: Use generic of_device_get_match_data helper
>   media: s5p-mfc: Replace mem_dev_* entries with an array
>   media: s5p-mfc: Replace bank1/bank2 entries with an array
>   media: s5p-mfc: Simplify alloc/release private buffer functions
>   media: s5p-mfc: Move setting DMA max segmetn size to DMA configure
> function

Just notice this small typo "segmetn", associated patch will need
update too.

>   media: s5p-mfc: Put firmware to private buffer structure
>   media: s5p-mfc: Move firmware allocation to DMA configure function
>   media: s5p-mfc: Allocate firmware with internal private buffer alloc
> function
>   media: s5p-mfc: Reduce firmware buffer size for MFC v6+ variants
>   media: s5p-mfc: Split variant DMA memory configuration into separate
> functions
>   media: s5p-mfc: Add support for probe-time preallocated block based
> allocator
>   media: s5p-mfc: Remove special configuration of IOMMU domain
>   media: s5p-mfc: Use preallocated block allocator always for MFC v6+
>   ARM: dts: exynos: Remove MFC reserved buffers
> 
>  .../devicetree/bindings/media/s5p-mfc.txt  |   2 +-
>  arch/arm/boot/dts/exynos5250-arndale.dts   |   1 -
>  arch/arm/boot/dts/exynos5250-smdk5250.dts  |   1 -
>  arch/arm/boot/dts/exynos5250-spring.dts|   1 -
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts  |   1 -
>  arch/arm/boot/dts/exynos5420-peach-pit.dts |   1 -
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  |   1 -
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |   1 -
>  arch/arm/boot/dts/exynos5800-peach-pi.dts  |   1 -
>  drivers/media/platform/s5p-mfc/regs-mfc-v6.h   |   2 +-
>  drivers/media/platform/s5p-mfc/regs-mfc-v7.h   |   2 +-
>  drivers/media/platform/s5p-mfc/regs-mfc-v8.h   |   2 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc.c   | 210 
> +
>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c|   2 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h|  43 ++---
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |  71 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h  |   1 -
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |   8 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   |  10 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h |  51 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.c   |  65 +--
>  

Re: [PATCH v4 18/36] media: Add i.MX media core driver

[Steve Longerbeam]

On 02/16/2017 05:02 AM, Philipp Zabel wrote:

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:



+
+- Clean up and move the ov5642 subdev driver to drivers/media/i2c, and
+  create the binding docs for it.


This is done already, right?



I cleaned up ov5640 and moved it to drivers/media/i2c with binding docs,
but not the ov5642 yet.





+- The Frame Interval Monitor could be exported to v4l2-core for
+  general use.
+
+- The subdev that is the original source of video data (referred to as
+  the "sensor" in the code), is called from various subdevs in the
+  pipeline in order to set/query the video standard ({g|s|enum}_std)
+  and to get/set the original frame interval from the capture interface
+  ([gs]_parm). Instead, the entities that need this info should call its
+  direct neighbor, and the neighbor should propagate the call to its
+  neighbor in turn if necessary.


Especially the [gs]_parm fix is necessary to present userspace with the
correct frame interval in case of frame skipping in the CSI.



Right, understood. I've added this to list of fixes for version 5.

What a pain though! It means propagating every call to g_frame_interval
upstream until a subdev "that cares" returns ret == 0 or
ret != -ENOIOCTLCMD. And that goes for any other chained subdev call
as well.

I've thought of writing something like a v4l2_chained_subdev_call()
macro to do this, but it would be a big macro.








+- At driver load time, the device-tree node that is the original source
+  (the "sensor"), is parsed to record its media bus configuration, and
+  this info is required in various subdevs to setup the pipeline.
+  Laurent Pinchart argues that instead the subdev should call its
+  neighbor's g_mbus_config op (which should be propagated if necessary)
+  to get this info. However Hans Verkuil is planning to remove the
+  g_mbus_config op. For now this driver uses the parsed DT mbus config
+  method until this issue is resolved.
+
diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
new file mode 100644
index 000..e2041ad
--- /dev/null
+++ b/drivers/staging/media/imx/imx-media-dev.c

[...]

+static inline u32 pixfmt_to_colorspace(const struct imx_media_pixfmt *fmt)
+{
+   return (fmt->cs == IPUV3_COLORSPACE_RGB) ?
+   V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
+}


This ...

[...]

+int imx_media_mbus_fmt_to_pix_fmt(struct v4l2_pix_format *pix,
+ struct v4l2_mbus_framefmt *mbus,
+ const struct imx_media_pixfmt *cc)
+{
+   u32 stride;
+
+   if (!cc) {
+   cc = imx_media_find_format(0, mbus->code, true, false);
+   if (!cc)
+   return -EINVAL;
+   }
+
+   stride = cc->planar ? mbus->width : (mbus->width * cc->bpp) >> 3;
+
+   pix->width = mbus->width;
+   pix->height = mbus->height;
+   pix->pixelformat = cc->fourcc;
+   pix->colorspace = pixfmt_to_colorspace(cc);


... is not right. The colorspace should be taken from the input pad
colorspace everywhere (except for the IC output pad in the future, once
that supports changing YCbCr encoding and quantization), not guessed
based on the media bus format.


Ok, will fix this to assign pix->colorspace to mbus->colorspace, after
all the subdevs assign colorspace values to their pads.


Steve

Re: [PATCH v4 07/36] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors

[Steve Longerbeam]

On 02/16/2017 04:51 PM, Fabio Estevam wrote:

Hi Steve,

On Thu, Feb 16, 2017 at 12:19 AM, Steve Longerbeam
 wrote:

Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.

The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.

The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi.

Until the OV5652 sensor module compatible with the SabreSD becomes
available for testing, the ov5642 node is currently disabled.


You missed your Signed-off-by.


Thanks, fixed.

Steve

[PATCH v3 1/3] [media] si2157: Add support for Si2141-A10

[Stefan Brüns]

The Si2141 needs two distinct commands for powerup/reset, otherwise it
will not respond to chip revision requests. It also needs a firmware
to run properly.

Signed-off-by: Stefan Brüns 
---
 drivers/media/tuners/si2157.c  | 23 +--
 drivers/media/tuners/si2157_priv.h |  2 ++
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 57b250847cd3..e35b1faf0ddc 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -106,6 +106,9 @@ static int si2157_init(struct dvb_frontend *fe)
if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
cmd.wlen = 9;
+   } else if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x00\x0d\x0e\x00\x01\x01\x01\x01\x03", 
10);
+   cmd.wlen = 10;
} else {
memcpy(cmd.args, 
"\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01", 15);
cmd.wlen = 15;
@@ -115,6 +118,15 @@ static int si2157_init(struct dvb_frontend *fe)
if (ret)
goto err;
 
+   /* Si2141 needs a second command before it answers the revision query */
+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x08\x01\x02\x00\x00\x01", 7);
+   cmd.wlen = 7;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+   }
+
/* query chip revision */
memcpy(cmd.args, "\x02", 1);
cmd.wlen = 1;
@@ -131,12 +143,16 @@ static int si2157_init(struct dvb_frontend *fe)
#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
#define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
+   #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
 
switch (chip_id) {
case SI2158_A20:
case SI2148_A20:
fw_name = SI2158_A20_FIRMWARE;
break;
+   case SI2141_A10:
+   fw_name = SI2141_A10_FIRMWARE;
+   break;
case SI2157_A30:
case SI2147_A30:
case SI2146_A10:
@@ -371,7 +387,7 @@ static int si2157_get_if_frequency(struct dvb_frontend *fe, 
u32 *frequency)
 
 static const struct dvb_tuner_ops si2157_ops = {
.info = {
-   .name   = "Silicon Labs Si2146/2147/2148/2157/2158",
+   .name   = "Silicon Labs 
Si2141/Si2146/2147/2148/2157/2158",
.frequency_min  = 4200,
.frequency_max  = 87000,
},
@@ -471,6 +487,7 @@ static int si2157_probe(struct i2c_client *client,
 #endif
 
dev_info(>dev, "Silicon Labs %s successfully attached\n",
+   dev->chiptype == SI2157_CHIPTYPE_SI2141 ?  "Si2141" :
dev->chiptype == SI2157_CHIPTYPE_SI2146 ?
"Si2146" : "Si2147/2148/2157/2158");
 
@@ -508,6 +525,7 @@ static int si2157_remove(struct i2c_client *client)
 static const struct i2c_device_id si2157_id_table[] = {
{"si2157", SI2157_CHIPTYPE_SI2157},
{"si2146", SI2157_CHIPTYPE_SI2146},
+   {"si2141", SI2157_CHIPTYPE_SI2141},
{}
 };
 MODULE_DEVICE_TABLE(i2c, si2157_id_table);
@@ -524,7 +542,8 @@ static struct i2c_driver si2157_driver = {
 
 module_i2c_driver(si2157_driver);
 
-MODULE_DESCRIPTION("Silicon Labs Si2146/2147/2148/2157/2158 silicon tuner 
driver");
+MODULE_DESCRIPTION("Silicon Labs Si2141/Si2146/2147/2148/2157/2158 silicon 
tuner driver");
 MODULE_AUTHOR("Antti Palosaari ");
 MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2158_A20_FIRMWARE);
+MODULE_FIRMWARE(SI2141_A10_FIRMWARE);
diff --git a/drivers/media/tuners/si2157_priv.h 
b/drivers/media/tuners/si2157_priv.h
index d6b2c7b44053..e6436f74abaa 100644
--- a/drivers/media/tuners/si2157_priv.h
+++ b/drivers/media/tuners/si2157_priv.h
@@ -42,6 +42,7 @@ struct si2157_dev {
 
 #define SI2157_CHIPTYPE_SI2157 0
 #define SI2157_CHIPTYPE_SI2146 1
+#define SI2157_CHIPTYPE_SI2141 2
 
 /* firmware command struct */
 #define SI2157_ARGLEN  30
@@ -52,5 +53,6 @@ struct si2157_cmd {
 };
 
 #define SI2158_A20_FIRMWARE "dvb-tuner-si2158-a20-01.fw"
+#define SI2141_A10_FIRMWARE "dvb-tuner-si2141-a10-01.fw"
 
 #endif
-- 
2.11.0

[PATCH v3 3/3] [media] dvbsky: MyGica T230C support

[Stefan Brüns]

Mygica T230 DVB-T/T2/C USB stick support. It uses the same FX2/Si2168
bridge/demodulator combo as the other devices supported by the driver,
but uses the Si2141 tuner.
Several DVB-T (MPEG2) and DVB-T2 (H.265) channels were tested, as well as
the included remote control.

Signed-off-by: Stefan Brüns 
---
v2: add support to the dvbsky driver instead of cxusb, correct RC
model
v3: fixed coding style issues, use name as printed on box for id table
---
 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 88 +++
 2 files changed, 89 insertions(+)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index a7a4674ccc40..ce4a3d574dd7 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -380,6 +380,7 @@
 #define USB_PID_SONY_PLAYTV0x0003
 #define USB_PID_MYGICA_D6890xd811
 #define USB_PID_MYGICA_T2300xc688
+#define USB_PID_MYGICA_T230C   0xc689
 #define USB_PID_ELGATO_EYETV_DIVERSITY 0x0011
 #define USB_PID_ELGATO_EYETV_DTT   0x0021
 #define USB_PID_ELGATO_EYETV_DTT_2 0x003f
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index 02dbc6c45423..f98225767712 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -665,6 +665,65 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter *adap)
return ret;
 }
 
+static int dvbsky_mygica_t230c_attach(struct dvb_usb_adapter *adap)
+{
+   struct dvbsky_state *state = adap_to_priv(adap);
+   struct dvb_usb_device *d = adap_to_d(adap);
+   struct i2c_adapter *i2c_adapter;
+   struct i2c_client *client_demod, *client_tuner;
+   struct i2c_board_info info;
+   struct si2168_config si2168_config;
+   struct si2157_config si2157_config;
+
+   /* attach demod */
+   memset(_config, 0, sizeof(si2168_config));
+   si2168_config.i2c_adapter = _adapter;
+   si2168_config.fe = >fe[0];
+   si2168_config.ts_mode = SI2168_TS_PARALLEL;
+   si2168_config.ts_clock_inv = 1;
+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2168", sizeof(info.type));
+   info.addr = 0x64;
+   info.platform_data = _config;
+
+   request_module("si2168");
+   client_demod = i2c_new_device(>i2c_adap, );
+   if (!client_demod || !client_demod->dev.driver)
+   goto fail_demod_device;
+   if (!try_module_get(client_demod->dev.driver->owner))
+   goto fail_demod_module;
+
+   /* attach tuner */
+   memset(_config, 0, sizeof(si2157_config));
+   si2157_config.fe = adap->fe[0];
+   si2157_config.if_port = 0;
+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2141", sizeof(info.type));
+   info.addr = 0x60;
+   info.platform_data = _config;
+
+   request_module("si2157");
+   client_tuner = i2c_new_device(i2c_adapter, );
+   if (!client_tuner || !client_tuner->dev.driver)
+   goto fail_tuner_device;
+   if (!try_module_get(client_tuner->dev.driver->owner))
+   goto fail_tuner_module;
+
+   state->i2c_client_demod = client_demod;
+   state->i2c_client_tuner = client_tuner;
+   return 0;
+
+fail_tuner_module:
+   i2c_unregister_device(client_tuner);
+fail_tuner_device:
+   module_put(client_demod->dev.driver->owner);
+fail_demod_module:
+   i2c_unregister_device(client_demod);
+fail_demod_device:
+   return -ENODEV;
+}
+
+
 static int dvbsky_identify_state(struct dvb_usb_device *d, const char **name)
 {
dvbsky_gpio_ctrl(d, 0x04, 1);
@@ -830,6 +889,32 @@ static struct dvb_usb_device_properties dvbsky_t330_props 
= {
}
 };
 
+static struct dvb_usb_device_properties mygica_t230c_props = {
+   .driver_name = KBUILD_MODNAME,
+   .owner = THIS_MODULE,
+   .adapter_nr = adapter_nr,
+   .size_of_priv = sizeof(struct dvbsky_state),
+
+   .generic_bulk_ctrl_endpoint = 0x01,
+   .generic_bulk_ctrl_endpoint_response = 0x81,
+   .generic_bulk_ctrl_delay = DVBSKY_MSG_DELAY,
+
+   .i2c_algo = _i2c_algo,
+   .frontend_attach  = dvbsky_mygica_t230c_attach,
+   .init = dvbsky_init,
+   .get_rc_config= dvbsky_get_rc_config,
+   .streaming_ctrl   = dvbsky_streaming_ctrl,
+   .identify_state   = dvbsky_identify_state,
+   .exit = dvbsky_exit,
+
+   .num_adapters = 1,
+   .adapter = {
+   {
+   .stream = DVB_USB_STREAM_BULK(0x82, 8, 4096),
+   }
+   }
+};
+
 static const struct usb_device_id dvbsky_id_table[] = {
{ DVB_USB_DEVICE(0x0572, 0x6831,
_s960_props, "DVBSky S960/S860", 

[PATCH v3 0/3] Add support for MyGica T230C DVB-T2 stick

[Stefan Brüns]

The required command sequence for the new tuner (Si2141) was traced from the
current Windows driver and verified with a small python script/libusb.
The changes to the Si2168 and dvbsky driver are mostly additions of the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] dvbsky: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 +++-
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 88 +++
 6 files changed, 118 insertions(+), 2 deletions(-)

-- 
2.11.0

[PATCH v3 2/3] [media] si2168: add support for Si2168-D60

[Stefan Brüns]

Add handling for new revision, requiring new firmware.

Signed-off-by: Stefan Brüns 
---
 drivers/media/dvb-frontends/si2168.c  | 4 
 drivers/media/dvb-frontends/si2168_priv.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 20b4a659e2e4..28f3bbe0af25 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -674,6 +674,9 @@ static int si2168_probe(struct i2c_client *client,
case SI2168_CHIP_ID_B40:
dev->firmware_name = SI2168_B40_FIRMWARE;
break;
+   case SI2168_CHIP_ID_D60:
+   dev->firmware_name = SI2168_D60_FIRMWARE;
+   break;
default:
dev_dbg(>dev, "unknown chip version Si21%d-%c%c%c\n",
cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
@@ -761,3 +764,4 @@ MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2168_A20_FIRMWARE);
 MODULE_FIRMWARE(SI2168_A30_FIRMWARE);
 MODULE_FIRMWARE(SI2168_B40_FIRMWARE);
+MODULE_FIRMWARE(SI2168_D60_FIRMWARE);
diff --git a/drivers/media/dvb-frontends/si2168_priv.h 
b/drivers/media/dvb-frontends/si2168_priv.h
index 7843ccb448a0..4baa95b7d648 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -25,6 +25,7 @@
 #define SI2168_A20_FIRMWARE "dvb-demod-si2168-a20-01.fw"
 #define SI2168_A30_FIRMWARE "dvb-demod-si2168-a30-01.fw"
 #define SI2168_B40_FIRMWARE "dvb-demod-si2168-b40-01.fw"
+#define SI2168_D60_FIRMWARE "dvb-demod-si2168-d60-01.fw"
 #define SI2168_B40_FIRMWARE_FALLBACK "dvb-demod-si2168-02.fw"
 
 /* state struct */
@@ -37,6 +38,7 @@ struct si2168_dev {
#define SI2168_CHIP_ID_A20 ('A' << 24 | 68 << 16 | '2' << 8 | '0' << 0)
#define SI2168_CHIP_ID_A30 ('A' << 24 | 68 << 16 | '3' << 8 | '0' << 0)
#define SI2168_CHIP_ID_B40 ('B' << 24 | 68 << 16 | '4' << 8 | '0' << 0)
+   #define SI2168_CHIP_ID_D60 ('D' << 24 | 68 << 16 | '6' << 8 | '0' << 0)
unsigned int chip_id;
unsigned int version;
const char *firmware_name;
-- 
2.11.0

Re: [PATCH v4 07/36] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors

[Fabio Estevam]

Hi Steve,

On Thu, Feb 16, 2017 at 12:19 AM, Steve Longerbeam
 wrote:
> Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
>
> The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
>
> The OV5640 connects to the input port on the MIPI CSI-2 receiver on
> mipi_csi.
>
> Until the OV5652 sensor module compatible with the SabreSD becomes
> available for testing, the ov5642 node is currently disabled.

You missed your Signed-off-by.

Re: [PATCH v4 00/36] i.MX Media Driver

[Russell King - ARM Linux]

On Thu, Feb 16, 2017 at 02:27:41PM -0800, Steve Longerbeam wrote:
> 
> 
> On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote:
> >On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote:
> >>In version 4:
> >
> >With this version, I get:
> >
> >[28762.892053] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x
> >[28762.899409] ipu1_csi0: pipeline_set_stream failed with -110
> >
> 
> Right, in the imx219, on exit from s_power(), the clock and data lanes
> must be placed in the LP-11 state. This has been done in the ov5640 and
> tc358743 subdevs.

The only way to do that is to enable streaming from the sensor, wait
an initialisation time, and then disable streaming, and wait for the
current line to finish.  There is _no_ other way to get the sensor to
place its clock and data lines into LP-11 state.

For that to happen, we need to program the sensor a bit more than we
currently do at power on (to a minimal resolution, and setting up the
PLLs), and introduce another 4ms on top of the 8ms or so that the
runtime resume function already takes.

Looking at the SMIA driver, things are worse, and I suspect that it also
will not work with the current setup - the SMIA spec shows that the CSI
clock and data lines are tristated while the sensor is not streaming,
which means they aren't held at a guaranteed LP-11 state, even if that
driver momentarily enabled streaming.  Hence, Freescale's (or is it
Synopsis') requirement may actually be difficult to satisfy.

However, I regard runtime PM broken with the current imx-capture setup.
At the moment, power is controlled at the sensor by whether the media
links are enabled.  So, if you have an enabled link coming off the
sensor, the sensor will be powered up, whether you're using it or not.

Given that the number of applications out there that know about the
media subdevs is really quite small, this combination makes having
runtime PM in sensor devices completely pointless - they can't sleep
as long as they have an enabled link, which could be persistent over
many days or weeks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v4 00/36] i.MX Media Driver

[Steve Longerbeam]

On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote:

On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote:

In version 4:


With this version, I get:

[28762.892053] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x
[28762.899409] ipu1_csi0: pipeline_set_stream failed with -110



Right, in the imx219, on exit from s_power(), the clock and data lanes
must be placed in the LP-11 state. This has been done in the ov5640 and
tc358743 subdevs.

If we want to bring in the patch that adds a .prepare_stream() op,
the csi-2 bus would need to be placed in LP-11 in that op instead.

Philipp, should I go ahead and add your .prepare_stream() patch?

Steve

Re: [PATCH v4 00/36] i.MX Media Driver

[Russell King - ARM Linux]

On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote:
> In version 4:

With this version, I get:

[28762.892053] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x
[28762.899409] ipu1_csi0: pipeline_set_stream failed with -110

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 2/4] [media] em28xx: reduce stack usage in probe functions

[Frank Schäfer]

Hi Arnd,

Am 13.02.2017 um 15:00 schrieb Hans Verkuil:

Hi Arnd,

I'll take the others of this patch series, but will postpone this one until it 
has
been tested.

I've asked Frank to see if he can test it, if not, then it will have to wait 
until
March when I have access to an omnivision-em28xx device.

Regards,

Hans

On 02/02/2017 03:53 PM, Arnd Bergmann wrote:

The two i2c probe functions use a lot of stack since they put
an i2c_client structure in a local variable:

drivers/media/usb/em28xx/em28xx-camera.c: In function 
'em28xx_probe_sensor_micron':
drivers/media/usb/em28xx/em28xx-camera.c:205:1: error: the frame size of 1256 
bytes is larger than 1152 bytes [-Werror=frame-larger-than=]
drivers/media/usb/em28xx/em28xx-camera.c: In function 
'em28xx_probe_sensor_omnivision':
drivers/media/usb/em28xx/em28xx-camera.c:317:1: error: the frame size of 1248 
bytes is larger than 1152 bytes [-Werror=frame-larger-than=]

This cleans up both of the above by removing the need for those
structures, calling the lower-level i2c function directly.


in the past, it was necessary to keep dev->i2c_client[dev->def_i2c_bus] 
unmodified, otherwise bad things could have happened after sensor probing.
In the meantime many things have been refactored/fixed and this seems to 
be no longer true.
So we can go the simple way and just use a pointer to 
dev->i2c_client[dev->def_i2c_bus] instead.

But let me test that with another device this weekend to be 100% sure.

Regards,
Frank



Signed-off-by: Arnd Bergmann 
---
  drivers/media/usb/em28xx/em28xx-camera.c | 87 ++--
  1 file changed, 50 insertions(+), 37 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
b/drivers/media/usb/em28xx/em28xx-camera.c
index 89c890ba7dd6..e64940f95a91 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -99,6 +99,25 @@ static int em28xx_initialize_mt9m001(struct em28xx *dev)
return 0;
  }
  
+/* NOTE: i2c_smbus_read_word_data() doesn't work with BE data */

+static int em28xx_i2c_read_chip_id(struct em28xx *dev, u16 addr, u8 reg, void 
*buf)
+{
+   struct i2c_client *client = >i2c_client[dev->def_i2c_bus];
+   struct i2c_msg msg[2];
+
+   msg[0].addr = addr;
+   msg[0].flags = client->flags & I2C_M_TEN;
+   msg[0].len = 1;
+   msg[0].buf = 
+   msg[1].addr = addr;
+   msg[1].flags = client->flags & I2C_M_TEN;
+   msg[1].flags |= I2C_M_RD;
+   msg[1].len = 2;
+   msg[1].buf = buf;
+
+   return i2c_transfer(client->adapter, msg, 2);
+}
+
  /*
   * Probes Micron sensors with 8 bit address and 16 bit register width
   */
@@ -106,48 +125,29 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
  {
int ret, i;
char *name;
-   u8 reg;
__be16 id_be;
+   u16 addr;
u16 id;
  
-	struct i2c_client client = dev->i2c_client[dev->def_i2c_bus];

-
dev->em28xx_sensor = EM28XX_NOSENSOR;
for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END; i++) {
-   client.addr = micron_sensor_addrs[i];
-   /* NOTE: i2c_smbus_read_word_data() doesn't work with BE data */
+   addr = micron_sensor_addrs[i];
/* Read chip ID from register 0x00 */
-   reg = 0x00;
-   ret = i2c_master_send(, , 1);
+   ret = em28xx_i2c_read_chip_id(dev, addr, 0x00, _be);
if (ret < 0) {
if (ret != -ENXIO)
dev_err(>intf->dev,
"couldn't read from i2c device 0x%02x: error 
%i\n",
-  client.addr << 1, ret);
-   continue;
-   }
-   ret = i2c_master_recv(, (u8 *)_be, 2);
-   if (ret < 0) {
-   dev_err(>intf->dev,
-   "couldn't read from i2c device 0x%02x: error 
%i\n",
-   client.addr << 1, ret);
+  addr << 1, ret);
continue;
}
id = be16_to_cpu(id_be);
/* Read chip ID from register 0xff */
-   reg = 0xff;
-   ret = i2c_master_send(, , 1);
+   ret = em28xx_i2c_read_chip_id(dev, addr, 0xff, _be);
if (ret < 0) {
dev_err(>intf->dev,
"couldn't read from i2c device 0x%02x: error 
%i\n",
-   client.addr << 1, ret);
-   continue;
-   }
-   ret = i2c_master_recv(, (u8 *)_be, 2);
-   if (ret < 0) {
-   dev_err(>intf->dev,
-   "couldn't read from i2c device 0x%02x: error 
%i\n",
-   client.addr << 1, ret);
+   addr << 1, ret);
   

Re: [PATCH v4 01/36] [media] dt-bindings: Add bindings for i.MX media driver

[Steve Longerbeam]

On 02/16/2017 03:54 AM, Philipp Zabel wrote:

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:

Add bindings documentation for the i.MX media driver.

Signed-off-by: Steve Longerbeam 
---
 Documentation/devicetree/bindings/media/imx.txt | 66 +
 1 file changed, 66 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/imx.txt

diff --git a/Documentation/devicetree/bindings/media/imx.txt 
b/Documentation/devicetree/bindings/media/imx.txt
new file mode 100644
index 000..fd5af50
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx.txt
@@ -0,0 +1,66 @@
+Freescale i.MX Media Video Device
+=
+
+Video Media Controller node
+---
+
+This is the media controller node for video capture support. It is a
+virtual device that lists the camera serial interface nodes that the
+media device will control.
+
+Required properties:
+- compatible : "fsl,imx-capture-subsystem";
+- ports  : Should contain a list of phandles pointing to camera
+   sensor interface ports of IPU devices
+
+example:
+
+capture-subsystem {
+   compatible = "fsl,capture-subsystem";


"fsl,imx-capture-subsystem"



Fixed.

Steve

Re: [PATCH v4 20/36] media: imx: Add CSI subdev driver

[Russell King - ARM Linux]

On Thu, Feb 16, 2017 at 10:44:16AM -0800, Steve Longerbeam wrote:
> On 02/16/2017 04:40 AM, Russell King - ARM Linux wrote:
> >[8.012191] imx_media_common: module is from the staging directory, the 
> >quality is unknown, you have been warned.
> >[8.018175] imx_media: module is from the staging directory, the quality 
> >is unknown, you have been warned.
> >[8.748345] imx-media: Registered subdev ipu1_csi0_mux
> >[8.753451] imx-media: Registered subdev ipu2_csi1_mux
> >[9.055196] imx219 0-0010: detected IMX219 sensor
> >[9.090733] imx6_mipi_csi2: module is from the staging directory, the 
> >quality is unknown, you have been warned.
> >[9.092247] imx-media: Registered subdev imx219 0-0010
> >[9.334338] imx-media: Registered subdev imx6-mipi-csi2
> >[9.372452] imx_media_capture: module is from the staging directory, the 
> >quality is unknown, you have been warned.
> >[9.378163] imx_media_capture: module is from the staging directory, the 
> >quality is unknown, you have been warned.
> >[9.390033] imx_media_csi: module is from the staging directory, the 
> >quality is unknown, you have been warned.
> >[9.394362] imx-media: Received unknown subdev ipu1_csi0
> 
> The root problem is here. I don't know why the CSI entities are not
> being recognized. Can you share the changes you made?

No, it's not the root problem that's causing the BUG/etc, but it is
_a_ problem.  Nevertheless, it's something I fixed - disconnecting
the of_node from the struct device needed one other change in the
imx-media code that was missing at this time.

However, that's no excuse what so ever for the BUG_ON() and lack of
error cleanup (causing use-after-free, which is just another way of
saying "data corruption waiting to happen") that I identified.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v4 20/36] media: imx: Add CSI subdev driver

[Steve Longerbeam]

On 02/16/2017 06:20 AM, Russell King - ARM Linux wrote:

On Thu, Feb 16, 2017 at 01:09:35PM +, Russell King - ARM Linux wrote:



More crap.

If the "complete" method fails (or, in fact, anything in
v4l2_async_test_notify() fails) then all hell breaks loose, because
of the total lack of clean up (and no, this isn't anything to do with
some stupid justification of those BUG_ON()s above.)

v4l2_async_notifier_register() gets called, it adds the notifier to
the global notifier list.  v4l2_async_test_notify() gets called.  It
returns an error, which is propagated out of
v4l2_async_notifier_register().

So the caller thinks that v4l2_async_notifier_register() failed, which
will cause imx_media_probe() to fail, causing imxmd->subdev_notifier
to be kfree()'d.  We now have a use-after free bug.

Second case.  v4l2_async_register_subdev().  Almost exactly the same,
except in this case adding sd->async_list to the notifier->done list
may have succeeded, and failure after that, again, results in an
in-use list_head being kfree()'d.


And here's a patch which, combined with the fixes for ipuv3, results in
everything appearing to work properly.  Feel free to tear out the bits
for your area and turn them into proper patches.

 drivers/gpu/ipu-v3/ipu-common.c   |  6 ---
 drivers/media/media-entity.c  |  7 +--
 drivers/media/v4l2-core/v4l2-async.c  | 71 +++
 drivers/staging/media/imx/imx-media-csi.c |  1 +
 drivers/staging/media/imx/imx-media-dev.c |  2 +-
 5 files changed, 59 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 97218af4fe75..8368e6f766ee 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1238,12 +1238,6 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
platform_device_put(pdev);
goto err_register;
}
-
-   /*
-* Set of_node only after calling platform_device_add. Otherwise
-* the platform:imx-ipuv3-crtc modalias won't be used.
-*/
-   pdev->dev.of_node = of_node;
}



Ah, never mind my question earlier, I see now why the CSI's were likely
not recognized, probably because of this. Anyway I agree with this 
change and I made the accompanying requisite change to imx-media-csi.c

and imx-media-dev.c below.

Steve






return 0;
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index f9f723f5e4f0..154593a168df 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -625,9 +625,10 @@ media_create_pad_link(struct media_entity *source, u16 
source_pad,
struct media_link *link;
struct media_link *backlink;

-   BUG_ON(source == NULL || sink == NULL);
-   BUG_ON(source_pad >= source->num_pads);
-   BUG_ON(sink_pad >= sink->num_pads);
+   if (WARN_ON(source == NULL || sink == NULL) ||
+   WARN_ON(source_pad >= source->num_pads) ||
+   WARN_ON(sink_pad >= sink->num_pads))
+   return -EINVAL;

link = media_add_link(>links);
if (link == NULL)
diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 5bada202b2d3..09934fb96a8d 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -94,7 +94,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct 
v4l2_async_notifier *
 }

 static int v4l2_async_test_notify(struct v4l2_async_notifier *notifier,
- struct v4l2_subdev *sd,
+ struct list_head *new, struct v4l2_subdev *sd,
  struct v4l2_async_subdev *asd)
 {
int ret;
@@ -107,22 +107,36 @@ static int v4l2_async_test_notify(struct 
v4l2_async_notifier *notifier,
if (notifier->bound) {
ret = notifier->bound(notifier, sd, asd);
if (ret < 0)
-   return ret;
+   goto err_bind;
}
+
/* Move from the global subdevice list to notifier's done */
-   list_move(>async_list, >done);
+   list_move(>async_list, new);

ret = v4l2_device_register_subdev(notifier->v4l2_dev, sd);
-   if (ret < 0) {
-   if (notifier->unbind)
-   notifier->unbind(notifier, sd, asd);
-   return ret;
-   }
+   if (ret < 0)
+   goto err_register;

-   if (list_empty(>waiting) && notifier->complete)
-   return notifier->complete(notifier);
+   if (list_empty(>waiting) && notifier->complete) {
+   ret = notifier->complete(notifier);
+   if (ret < 0)
+   goto err_complete;
+   }

return 0;
+
+err_complete:
+   v4l2_device_unregister_subdev(sd);
+err_register:
+   

Re: [PATCH v4 20/36] media: imx: Add CSI subdev driver

[Steve Longerbeam]

On 02/16/2017 04:40 AM, Russell King - ARM Linux wrote:

On Thu, Feb 16, 2017 at 11:52:06AM +, Russell King - ARM Linux wrote:

On Wed, Feb 15, 2017 at 06:19:22PM -0800, Steve Longerbeam wrote:

+static const struct platform_device_id imx_csi_ids[] = {
+   { .name = "imx-ipuv3-csi" },
+   { },
+};
+MODULE_DEVICE_TABLE(platform, imx_csi_ids);
+
+static struct platform_driver imx_csi_driver = {
+   .probe = imx_csi_probe,
+   .remove = imx_csi_remove,
+   .id_table = imx_csi_ids,
+   .driver = {
+   .name = "imx-ipuv3-csi",
+   },
+};
+module_platform_driver(imx_csi_driver);
+
+MODULE_DESCRIPTION("i.MX CSI subdev driver");
+MODULE_AUTHOR("Steve Longerbeam ");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:imx-ipuv3-csi");


Just a reminder that automatic module loading of this is completely
broken right now (not your problem) due to this stupid idea in the
IPUv3 code:

if (!ret)
ret = platform_device_add(pdev);
if (ret) {
platform_device_put(pdev);
goto err_register;
}

/*
 * Set of_node only after calling platform_device_add. Otherwise
 * the platform:imx-ipuv3-crtc modalias won't be used.
 */
pdev->dev.of_node = of_node;

setting pdev->dev.of_node changes the modalias exported to userspace,
so udev sees a DT based modalias, which causes it to totally miss any
driver using a non-DT based modalias.

The IPUv3 code needs fixing, not only for imx-media-csi, but also for
imx-ipuv3-crtc too, because that module will also suffer the same
issue.

The only solution is... don't fsck with dev->of_node assignment.  In
this case, it's probably much better to pass it in via platform data.
If you then absolutely must have dev->of_node, doing it in the driver
means that you avoid the modalias mess before the appropriate driver
is loaded.  However, that's still not a nice solution because the
modalias file still ends up randomly changing its contents.

As I say, not _your_ problem, but it's still a problem that needs
solving, and I don't want it forgotten about.


I've just hacked up a solution to this, and unfortunately it reveals a
problem with Steve's code.  Picking out the imx & media-related messages:

[8.012191] imx_media_common: module is from the staging directory, the 
quality is unknown, you have been warned.
[8.018175] imx_media: module is from the staging directory, the quality is 
unknown, you have been warned.
[8.748345] imx-media: Registered subdev ipu1_csi0_mux
[8.753451] imx-media: Registered subdev ipu2_csi1_mux
[9.055196] imx219 0-0010: detected IMX219 sensor
[9.090733] imx6_mipi_csi2: module is from the staging directory, the 
quality is unknown, you have been warned.
[9.092247] imx-media: Registered subdev imx219 0-0010
[9.334338] imx-media: Registered subdev imx6-mipi-csi2
[9.372452] imx_media_capture: module is from the staging directory, the 
quality is unknown, you have been warned.
[9.378163] imx_media_capture: module is from the staging directory, the 
quality is unknown, you have been warned.
[9.390033] imx_media_csi: module is from the staging directory, the quality 
is unknown, you have been warned.
[9.394362] imx-media: Received unknown subdev ipu1_csi0


The root problem is here. I don't know why the CSI entities are not
being recognized. Can you share the changes you made?

So imx_media_subdev_bound() returns error because it didn't recognize
the subdev that was bound.

And for some reason, even though some of the subdev bound ops return
error, v4l2-core still calls the async completion notifier
(imx_media_probe_complete()).

I'll add some checks to imx_media_probe_complete() to try and detect
when not all subdevs were bound correctly to get around this issue.
That should prevent the kernel BUG() below.

Steve



[9.394699] imx-ipuv3-csi: probe of imx-ipuv3-csi.0 failed with error -22
[9.394840] imx-media: Received unknown subdev ipu1_csi1
[9.394887] imx-ipuv3-csi: probe of imx-ipuv3-csi.1 failed with error -22
[9.394992] imx-media: Received unknown subdev ipu2_csi0
[9.395026] imx-ipuv3-csi: probe of imx-ipuv3-csi.4 failed with error -22
[9.395119] imx-media: Received unknown subdev ipu2_csi1
[9.395159] imx-ipuv3-csi: probe of imx-ipuv3-csi.5 failed with error -22
[9.411722] imx_media_vdic: module is from the staging directory, the 
quality is unknown, you have been warned.
[9.412820] imx-media: Registered subdev ipu1_vdic
[9.424687] imx-media: Registered subdev ipu2_vdic
[9.436074] imx_media_ic: module is from the staging directory, the quality 
is unknown, you have been warned.
[9.437455] imx-media: Registered subdev ipu1_ic_prp
[9.437788] imx_media_ic: module is from the staging directory, the quality 
is unknown, 

Re: [PATCH v4 00/36] i.MX Media Driver

[Steve Longerbeam]

On 02/16/2017 03:37 AM, Russell King - ARM Linux wrote:

Two problems.

On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote:

  media: imx: propagate sink pad formats to source pads


1) It looks like all cases aren't being caught:

- entity 74: ipu1_csi0 (3 pads, 4 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev13
pad0: Sink
[fmt:SRGGB8/816x616 field:none]
<- "ipu1_csi0_mux":2 [ENABLED]
pad1: Source
[fmt:AYUV32/816x616 field:none
 crop.bounds:(0,0)/816x616
 crop:(0,0)/816x616]
-> "ipu1_ic_prp":0 []
-> "ipu1_vdic":0 []
pad2: Source
[fmt:SRGGB8/816x616 field:none
 crop.bounds:(0,0)/816x616
 crop:(0,0)/816x616]
-> "ipu1_csi0 capture":0 [ENABLED]

While the size has been propagated to pad1, the format has not.


Right, Philipp also caught this. I need to finish propagating all
params from sink to source pads (mbus code and field, and colorimetry
eventually).



2) /dev/video* device node assignment

I've no idea at the moment how the correct /dev/video* node should be
chosen - initially with Philipp and your previous code, it was
/dev/video3 after initial boot.  Philipp's was consistently /dev/video3.
Yours changed to /dev/video7 when removing and re-inserting the modules
(having fixed that locally.)  This version makes CSI0 be /dev/video7,
but after a remove+reinsert, it becomes (eg) /dev/video8.

/dev/v4l/by-path/platform-capture-subsystem-video-index4 also is not a
stable path - the digit changes (it's supposed to be a stable path.)
After a remove+reinsert, it becomes (eg)
/dev/v4l/by-path/platform-capture-subsystem-video-index5.
/dev/v4l/by-id doesn't contain a symlink for this either.

What this means is that it's very hard to script the setup, because
there's no easy way to know what device is the capture device.  While
it may be possible to do:

media-ctl -d /dev/media1 -p | \
grep -A2 ': ipu1_csi0 capture' | \
sed -n 's|.*\(/dev/video[0-9]*\).*|\1|p'

that's hardly a nice solution - while it fixes the setup script, it
doesn't stop the pain of having to delve around to find the correct
device to use for gstreamer to test with.



I'll try to nail down the main capture node numbers, even after module
reload.

Steve

Re: [PATCH v4 36/36] media: imx: propagate sink pad formats to source pads

[Steve Longerbeam]

On 02/16/2017 03:29 AM, Philipp Zabel wrote:

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
[...]

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index dd9d499..c43f85f 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -806,16 +806,22 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
cfg->try_fmt = sdformat->format;
} else {
-   priv->format_mbus[sdformat->pad] = sdformat->format;
+   struct v4l2_mbus_framefmt *f =
+   >format_mbus[sdformat->pad];
+   struct v4l2_mbus_framefmt *outf =
+   >format_mbus[PRPENCVF_SRC_PAD];
+
+   *f = sdformat->format;
priv->cc[sdformat->pad] = cc;
-   if (sdformat->pad == PRPENCVF_SRC_PAD) {
-   /*
-* update the capture device format if this is
-* the IDMAC output pad
-*/
-   imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix,
- >format, cc);
+
+   /* propagate format to source pad */
+   if (sdformat->pad == PRPENCVF_SINK_PAD) {
+   outf->width = f->width;
+   outf->height = f->height;


What about media bus format, field, and colorimetry?


Right, I need to propagate a default media bus format and field
that works.

As for colorimtery, I did see the work you are doing in your
branch, but was not sure if you were finished with that support.
Can you send me a patch?




}
+
+   /* update the capture device format from output pad */
+   imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix, outf, cc);
}

return 0;
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 3e6b607..9d9ec03 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1161,19 +1161,27 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
cfg->try_fmt = sdformat->format;
} else {
+   struct v4l2_mbus_framefmt *f_direct, *f_idmac;
+
priv->format_mbus[sdformat->pad] = sdformat->format;
priv->cc[sdformat->pad] = cc;
-   /* Reset the crop window if this is the input pad */
-   if (sdformat->pad == CSI_SINK_PAD)
+
+   f_direct = >format_mbus[CSI_SRC_PAD_DIRECT];
+   f_idmac = >format_mbus[CSI_SRC_PAD_IDMAC];
+
+   if (sdformat->pad == CSI_SINK_PAD) {
+   /* reset the crop window */
priv->crop = crop;
-   else if (sdformat->pad == CSI_SRC_PAD_IDMAC) {
-   /*
-* update the capture device format if this is
-* the IDMAC output pad
-*/
-   imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix,
- >format, cc);
+
+   /* propagate format to source pads */
+   f_direct->width = crop.width;
+   f_direct->height = crop.height;
+   f_idmac->width = crop.width;
+   f_idmac->height = crop.height;


This is missing also media bus format, field and colorimetry
propagation.


Yep, will add that.

Steve




}
+
+   /* update the capture device format from IDMAC output pad */
+   imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix, f_idmac, cc);
}

return 0;
diff --git a/drivers/staging/media/imx/imx-media-vdic.c 
b/drivers/staging/media/imx/imx-media-vdic.c
index 61e6017..55fb522 100644
--- a/drivers/staging/media/imx/imx-media-vdic.c
+++ b/drivers/staging/media/imx/imx-media-vdic.c
@@ -649,8 +649,21 @@ static int vdic_set_fmt(struct v4l2_subdev *sd,
if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
cfg->try_fmt = sdformat->format;
} else {
-   priv->format_mbus[sdformat->pad] = sdformat->format;
+   struct v4l2_mbus_framefmt *f =
+   >format_mbus[sdformat->pad];
+   struct v4l2_mbus_framefmt *outf =
+   >format_mbus[VDIC_SRC_PAD_DIRECT];
+
+   *f = sdformat->format;
priv->cc[sdformat->pad] = cc;
+
+   /* propagate format to source pad */
+   if (sdformat->pad == VDIC_SINK_PAD_DIRECT ||
+   sdformat->pad == VDIC_SINK_PAD_IDMAC) {
+   outf->width = f->width;
+   outf->height = f->height;
+

Re: [PATCH v4 28/36] media: imx: csi: fix crop rectangle changes in set_fmt

[Steve Longerbeam]

On 02/16/2017 03:05 AM, Russell King - ARM Linux wrote:

On Wed, Feb 15, 2017 at 06:19:30PM -0800, Steve Longerbeam wrote:

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index ae24b42..3cb97e2 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -531,6 +531,10 @@ static int csi_setup(struct csi_priv *priv)

ipu_csi_set_window(priv->csi, >crop);

+   ipu_csi_set_downsize(priv->csi,
+priv->crop.width == 2 * outfmt->width,
+priv->crop.height == 2 * outfmt->height);
+


This fails to build:

ERROR: "ipu_csi_set_downsize" [drivers/staging/media/imx/imx-media-csi.ko] 
undefined!

ipu_csi_set_downsize needs to be exported if we're going to use it in
a module:



Yes I encountered the missing export too, forgot to mention it.
Philipp submitted a patch to dri-devel separately.

Steve

Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver

[Steve Longerbeam]

On 02/16/2017 02:28 AM, Russell King - ARM Linux wrote:

On Wed, Feb 15, 2017 at 06:19:25PM -0800, Steve Longerbeam wrote:

Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
for sensors with a MIPI CSI2 interface.

Signed-off-by: Steve Longerbeam 


Just like I reported on the 30th January:

.git/rebase-apply/patch:236: trailing whitespace.
 *
warning: 1 line adds whitespace errors.

This needs fixing.



Fixed.

[PATCH] media: vpif: use a configurable i2c_adapter_id for vpif display

[Bartosz Golaszewski]

The vpif display driver uses a static i2c adapter ID of 1 but on the
da850-evm board in DT boot mode the i2c adapter ID is actually 0.

Make the adapter ID configurable like it already is for vpif capture.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Kevin Hilman 
---
 arch/arm/mach-davinci/board-da850-evm.c   | 1 +
 drivers/media/platform/davinci/vpif_display.c | 2 +-
 include/media/davinci/vpif_types.h| 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index df3ca38..6f1e129 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1290,6 +1290,7 @@ static struct vpif_display_config 
da850_vpif_display_config = {
.output_count = ARRAY_SIZE(da850_ch0_outputs),
},
.card_name= "DA850/OMAP-L138 Video Display",
+   .i2c_adapter_id = 1,
 };
 
 static __init void da850_vpif_init(void)
diff --git a/drivers/media/platform/davinci/vpif_display.c 
b/drivers/media/platform/davinci/vpif_display.c
index 50c3073..7e5cf99 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1287,7 +1287,7 @@ static __init int vpif_probe(struct platform_device *pdev)
}
 
if (!vpif_obj.config->asd_sizes) {
-   i2c_adap = i2c_get_adapter(1);
+   i2c_adap = i2c_get_adapter(vpif_obj.config->i2c_adapter_id);
for (i = 0; i < subdev_count; i++) {
vpif_obj.sd[i] =
v4l2_i2c_new_subdev_board(_obj.v4l2_dev,
diff --git a/include/media/davinci/vpif_types.h 
b/include/media/davinci/vpif_types.h
index 4282a7d..0c72b46 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -57,6 +57,7 @@ struct vpif_display_config {
int (*set_clock)(int, int);
struct vpif_subdev_info *subdevinfo;
int subdev_count;
+   int i2c_adapter_id;
struct vpif_display_chan_config chan_config[VPIF_DISPLAY_MAX_CHANNELS];
const char *card_name;
struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
-- 
2.9.3

[GIT PULL for v4.10] 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-5

>From a regression fix that makes the Siano driver to work again after the
CONFIG_VMAP_STACK change.

Regards,
Mauro

The following changes since commit 42980da2eb7eb9695d8efc0c0ef145cbbb993b2c:

  [media] cec: initiator should be the same as the destination for, poll 
(2017-02-13 14:34:11 -0200)

are available in the git repository at:

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

for you to fetch changes up to f9c85ee67164b37f9296eab3b754e543e4e96a1c:

  [media] siano: make it work again with CONFIG_VMAP_STACK (2017-02-14 18:13:49 
-0200)


media fixes for v4.10-rc9


Mauro Carvalho Chehab (1):
  [media] siano: make it work again with CONFIG_VMAP_STACK

 drivers/media/usb/siano/smsusb.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

Re: [PATCH v4 18/36] media: Add i.MX media core driver

[Steve Longerbeam]

On 02/16/2017 02:27 AM, Russell King - ARM Linux wrote:

On Wed, Feb 15, 2017 at 06:19:20PM -0800, Steve Longerbeam wrote:

Add the core media driver for i.MX SOC.

Signed-off-by: Steve Longerbeam 

Just as I reported on the 30th January:

Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:614: new blank line at EOF.
+
.git/rebase-apply/patch:626: new blank line at EOF.
+
.git/rebase-apply/patch:668: new blank line at EOF.
+

These need fixing.


Missed these obviously, fixed.

Steve

Re: [PATCH 00/10] ARM: davinci: add vpif display support

[Bartosz Golaszewski]

2017-02-13 10:22 GMT+01:00 Sekhar Nori :
> Hi Bartosz,
>
> On Tuesday 07 February 2017 10:11 PM, Bartosz Golaszewski wrote:
>> The following series adds support for v4l2 display on da850-evm with
>> a UI board in device tree boot mode.
>>
>> Patches 1/10 - 5/10 deal with the device tree: we fix whitespace
>> errors in dts files and bindings, extend the example and the dts for
>> da850-evm with the output port and address the pinmuxing.
>>
>> Patch 6/10 enables the relevant modules in the defconfig file.
>>
>> Patches 7/10 and 8/10 fix two already existing bugs encountered
>> during development.
>>
>> Patch 9/10 make it possible to use a different i2c adapter in the
>> vpif display driver.
>>
>> The last patch adds the pdata quirks necessary to enable v4l2 display.
>>
>> Tested with a modified version of yavta[1] as gstreamer support for
>> v4l2 seems to be broken and results in picture artifacts.
>>
>> [1] https://github.com/brgl/yavta davinci/vpif-display
>
> Can you also share the command line you used ?
>
> Thanks,
> Sekhar

Will do. I'll also send separate sets of patches for your different
branches as advised by Kevin.

Thanks,
Bartosz

Re: [PATCH 03/10] media: dt-bindings: vpif: extend the example with an output port

[Bartosz Golaszewski]

2017-02-15 23:08 GMT+01:00 Rob Herring :
> On Tue, Feb 07, 2017 at 05:41:16PM +0100, Bartosz Golaszewski wrote:
>> This makes the example more or less correspond with the da850-evm
>> hardware setup.
>>
>> Signed-off-by: Bartosz Golaszewski 
>> ---
>>  .../devicetree/bindings/media/ti,da850-vpif.txt| 35 
>> ++
>>  1 file changed, 29 insertions(+), 6 deletions(-)
>
> Spoke too soon...
>
>>
>> diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt 
>> b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
>> index 9c7510b..543f6f3 100644
>> --- a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
>> +++ b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
>> @@ -28,19 +28,27 @@ I2C-connected TVP5147 decoder:
>>   reg = <0x217000 0x1000>;
>>   interrupts = <92>;
>>
>> - port {
>> - vpif_ch0: endpoint@0 {
>> + port@0 {
>> + vpif_input_ch0: endpoint@0 {
>>   reg = <0>;
>>   bus-width = <8>;
>> - remote-endpoint = <>;
>> + remote-endpoint = <_in>;
>>   };
>>
>> - vpif_ch1: endpoint@1 {
>> + vpif_input_ch1: endpoint@1 {
>>   reg = <1>;
>>   bus-width = <8>;
>>   data-shift = <8>;
>>   };
>>   };
>> +
>> + port@1 {
>
> The binding doc says nothing about supporting a 2nd port.
>

I assumed that "It should contain at least one port child node" means
there can be more than one.

Thanks,
Bartosz

>
>> + vpif_output_ch0: endpoint@0 {
>> + reg = <0>;
>
> Don't need reg here.
>
>> + bus-width = <8>;
>> + remote-endpoint = <_out>;
>> + };
>> + };
>>   };

Re: [PATCH v4 20/36] media: imx: Add CSI subdev driver

[Russell King - ARM Linux]

On Thu, Feb 16, 2017 at 01:09:35PM +, Russell King - ARM Linux wrote:
> On Thu, Feb 16, 2017 at 12:40:27PM +, Russell King - ARM Linux wrote:
> > However, the following is primerily directed at Laurent as the one who
> > introduced the BUG_ON() in question...
> > 
> > NEVER EVER USE BUG_ON() IN A PATH THAT CAN RETURN AN ERROR.
> > 
> > It's possible to find Linus rants about this, eg,
> > https://www.spinics.net/lists/stable/msg146439.html
> > 
> >  I should have reacted to the damn added BUG_ON() lines. I suspect I
> >  will have to finally just remove the idiotic BUG_ON() concept once and
> >  for all, because there is NO F*CKING EXCUSE to knowingly kill the
> >  kernel.
> > 
> > Also: http://yarchive.net/comp/linux/BUG.html
> > 
> >  Rule of thumb: BUG() is only good for something that never happens and
> >  that we really have no other option for (ie state is so corrupt that
> >  continuing is deadly).
> > 
> > So, _unless_ people want to see BUG_ON() removed from the kernel, I
> > strongly suggest to _STOP_ using it as "we didn't like the function
> > arguments, let's use it as an assert() statement instead of returning
> > an error."
> > 
> > There's no excuse what so ever to be killing the machine in
> > media_create_pad_link().  If it doesn't like a NULL pointer, it's damn
> > well got an error path to report that fact.  Use that mechanism and
> > stop needlessly killing the kernel.
> > 
> > BUG_ON() IS NOT ASSERT().  DO NOT USE IT AS SUCH.
> > 
> > Linus is absolutely right about BUG_ON() - it hurts debuggability,
> > because now the only way to do further tests is to reboot the damned
> > machine after removing those fscking BUG_ON()s that should *never*
> > have been there in the first place.
> > 
> > As Linus went on to say:
> > 
> >  And dammit, if anybody else feels that they had done "debugging
> >  messages with BUG_ON()", I would suggest you
> > 
> >   (a) rethink your approach to programming
> > 
> >   (b) send me patches to remove the crap entirely, or make them real
> >  *DEBUGGING* messages, not "kill the whole machine" messages.
> > 
> >  I've ranted against people using BUG_ON() for debugging in the past.
> >  Why the f*ck does this still happen? And Andrew - please stop taking
> >  those kinds of patches! Lookie here:
> > 
> >  https://lwn.net/Articles/13183/
> > 
> >  so excuse me for being upset that people still do this shit almost 15
> >  years later.
> > 
> > So I suggest people heed that advice and start fixing these stupid
> > BUG_ON()s that they've created.
> 
> More crap.
> 
> If the "complete" method fails (or, in fact, anything in
> v4l2_async_test_notify() fails) then all hell breaks loose, because
> of the total lack of clean up (and no, this isn't anything to do with
> some stupid justification of those BUG_ON()s above.)
> 
> v4l2_async_notifier_register() gets called, it adds the notifier to
> the global notifier list.  v4l2_async_test_notify() gets called.  It
> returns an error, which is propagated out of
> v4l2_async_notifier_register().
> 
> So the caller thinks that v4l2_async_notifier_register() failed, which
> will cause imx_media_probe() to fail, causing imxmd->subdev_notifier
> to be kfree()'d.  We now have a use-after free bug.
> 
> Second case.  v4l2_async_register_subdev().  Almost exactly the same,
> except in this case adding sd->async_list to the notifier->done list
> may have succeeded, and failure after that, again, results in an
> in-use list_head being kfree()'d.

And here's a patch which, combined with the fixes for ipuv3, results in
everything appearing to work properly.  Feel free to tear out the bits
for your area and turn them into proper patches.

 drivers/gpu/ipu-v3/ipu-common.c   |  6 ---
 drivers/media/media-entity.c  |  7 +--
 drivers/media/v4l2-core/v4l2-async.c  | 71 +++
 drivers/staging/media/imx/imx-media-csi.c |  1 +
 drivers/staging/media/imx/imx-media-dev.c |  2 +-
 5 files changed, 59 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 97218af4fe75..8368e6f766ee 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1238,12 +1238,6 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
platform_device_put(pdev);
goto err_register;
}
-
-   /*
-* Set of_node only after calling platform_device_add. Otherwise
-* the platform:imx-ipuv3-crtc modalias won't be used.
-*/
-   pdev->dev.of_node = of_node;
}
 
return 0;
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index f9f723f5e4f0..154593a168df 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -625,9 +625,10 @@ media_create_pad_link(struct media_entity *source, u16 
source_pad,
struct 

Re: [PATCH v4 18/36] media: Add i.MX media core driver

[Russell King - ARM Linux]

On Thu, Feb 16, 2017 at 02:02:03PM +0100, Philipp Zabel wrote:
> On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> > +- imx-csi subdev is not being autoloaded as a kernel module, probably
> > +  because ipu_add_client_devices() does not register the IPU client
> > +  platform devices, but only allocates those devices.
> 
> As Russell points out, this is an issue with the ipu-v3 driver, which
> needs to be fixed to stop setting the ipu client devices' dev->of_node
> field.

>From my local testing (albiet the shambles that is bits of v4l2) setting
dev->of_node is not necessary for imx-drm - imx-drm comes up fine without.

Fixing _this_ code for that is not too difficult - it's a matter of:

priv->sd.of_node = pdata->of_node;

in imx_csi_probe().  However, the difficult bit is the poor state of
code in v4l2, particularly the v4l2-async crap.  Right now, fixing the
module autoloading will oops the kernel, so it's best that module
autoloading remains broken for the time being.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v4 20/36] media: imx: Add CSI subdev driver

[Russell King - ARM Linux]

On Thu, Feb 16, 2017 at 12:40:27PM +, Russell King - ARM Linux wrote:
> However, the following is primerily directed at Laurent as the one who
> introduced the BUG_ON() in question...
> 
> NEVER EVER USE BUG_ON() IN A PATH THAT CAN RETURN AN ERROR.
> 
> It's possible to find Linus rants about this, eg,
> https://www.spinics.net/lists/stable/msg146439.html
> 
>  I should have reacted to the damn added BUG_ON() lines. I suspect I
>  will have to finally just remove the idiotic BUG_ON() concept once and
>  for all, because there is NO F*CKING EXCUSE to knowingly kill the
>  kernel.
> 
> Also: http://yarchive.net/comp/linux/BUG.html
> 
>  Rule of thumb: BUG() is only good for something that never happens and
>  that we really have no other option for (ie state is so corrupt that
>  continuing is deadly).
> 
> So, _unless_ people want to see BUG_ON() removed from the kernel, I
> strongly suggest to _STOP_ using it as "we didn't like the function
> arguments, let's use it as an assert() statement instead of returning
> an error."
> 
> There's no excuse what so ever to be killing the machine in
> media_create_pad_link().  If it doesn't like a NULL pointer, it's damn
> well got an error path to report that fact.  Use that mechanism and
> stop needlessly killing the kernel.
> 
> BUG_ON() IS NOT ASSERT().  DO NOT USE IT AS SUCH.
> 
> Linus is absolutely right about BUG_ON() - it hurts debuggability,
> because now the only way to do further tests is to reboot the damned
> machine after removing those fscking BUG_ON()s that should *never*
> have been there in the first place.
> 
> As Linus went on to say:
> 
>  And dammit, if anybody else feels that they had done "debugging
>  messages with BUG_ON()", I would suggest you
> 
>   (a) rethink your approach to programming
> 
>   (b) send me patches to remove the crap entirely, or make them real
>  *DEBUGGING* messages, not "kill the whole machine" messages.
> 
>  I've ranted against people using BUG_ON() for debugging in the past.
>  Why the f*ck does this still happen? And Andrew - please stop taking
>  those kinds of patches! Lookie here:
> 
>  https://lwn.net/Articles/13183/
> 
>  so excuse me for being upset that people still do this shit almost 15
>  years later.
> 
> So I suggest people heed that advice and start fixing these stupid
> BUG_ON()s that they've created.

More crap.

If the "complete" method fails (or, in fact, anything in
v4l2_async_test_notify() fails) then all hell breaks loose, because
of the total lack of clean up (and no, this isn't anything to do with
some stupid justification of those BUG_ON()s above.)

v4l2_async_notifier_register() gets called, it adds the notifier to
the global notifier list.  v4l2_async_test_notify() gets called.  It
returns an error, which is propagated out of
v4l2_async_notifier_register().

So the caller thinks that v4l2_async_notifier_register() failed, which
will cause imx_media_probe() to fail, causing imxmd->subdev_notifier
to be kfree()'d.  We now have a use-after free bug.

Second case.  v4l2_async_register_subdev().  Almost exactly the same,
except in this case adding sd->async_list to the notifier->done list
may have succeeded, and failure after that, again, results in an
in-use list_head being kfree()'d.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Fwd: [regression] dvb_usb_cxusb (was Re: ir-keytable: infinite loops, segfaults)

[Vincent McIntyre]

Hi list

I missed you in the cc: field...

-- Forwarded message --
From: Vincent McIntyre 
Date: Thu, 16 Feb 2017 23:51:05 +1100
Subject: Re: [regression] dvb_usb_cxusb (was Re: ir-keytable: infinite
loops, segfaults)
To: Sean Young 

On 2/16/17, Sean Young  wrote:
>
> The problem is that DVB_USB_CXUSB Kconfig has this line:
> select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
> The make_kconfig.pl script transforms this into a dependency, but
> DVB_SI2168 is only available when compiling against kernel 4.7 or later.
> I think only one select line needs to match, so I created this patch.
>
> Please apply this patch against media_build, you might need to do make
> clean before building again.

Awsome - build is working again, thank you. See the other thread for
my progress report.

> Thanks,
>
> Sean
>
>
> From: Sean Young 
> Date: Wed, 15 Feb 2017 14:58:00 +
> Subject: [PATCH] only one select Kconfig needs to match

Tested-by: vincent.mcint...@gmail.com

> ---
>  v4l/scripts/make_kconfig.pl | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/v4l/scripts/make_kconfig.pl b/v4l/scripts/make_kconfig.pl
> index ba8c134..a11f820 100755
> --- a/v4l/scripts/make_kconfig.pl
> +++ b/v4l/scripts/make_kconfig.pl
> @@ -169,6 +169,7 @@ sub depends($$)
>   push @{$depends{$key}}, $deps;
>  }
>
> +my %selectdepends = ();
>  sub selects($$$)
>  {
>   my $key = shift;
> @@ -181,7 +182,7 @@ sub selects($$$)
>   # Transform "select X if Y" into "depends on !Y || X"
>   $select = "!($if) || ($select)";
>   }
> - push @{$depends{$key}}, $select;
> + push @{$selectdepends{$key}}, $select;
>  }
>
>  # Needs:
> @@ -228,6 +229,23 @@ sub checkdeps()
>   return 0;
>   }
>   }
> + my $selectdeps = $selectdepends{$key};
> + if ($selectdeps) {
> + my $found = 0;
> + foreach (@$selectdeps) {
> + next if($_ eq '');
> + if (eval(toperl($_))) {
> + $found = 1;
> + last;
> + }
> + }
> + if ($found == 0) {
> + print "Disabling $key, select dependency '$_' 
> not met\n" if $debug;
> + $allconfig{$key} = 0;
> + return 0;
> + }
> + }
> +
>   return 1;
>   }
>
> --
> 2.7.4

Vince

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

The dmesg...


dmesg.txt.gz
Description: GNU Zip compressed data

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

Hi again

after you kindly fixed media_build for me I applied the nec protocol
patch and tried again.

$ sudo ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6
Enabled protocols: rc-6
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event11) with:
Driver dvb_usb_cxusb, table rc-dvico-mce
Supported protocols: nec
Enabled protocols:
Name: IR-receiver inside an USB DVB re
bus: 3, vendor/product: 0fe9:db78, version: 0x827b
Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc2/ (/dev/input/event16) with:
Driver dvb_usb_af9035, table rc-empty
Supported protocols: nec
Enabled protocols:
Name: Leadtek WinFast DTV Dongle Dual
bus: 3, vendor/product: 0413:6a05, version: 0x0200
Repeat delay = 500 ms, repeat period = 125 ms

$ sudo ir-keytable -v --sysdev rc1
Found device /sys/class/rc/rc0/
Found device /sys/class/rc/rc1/
Found device /sys/class/rc/rc2/
Input sysfs node is /sys/class/rc/rc0/input8/
Event sysfs node is /sys/class/rc/rc0/input8/event5/
Parsing uevent /sys/class/rc/rc0/input8/event5/uevent
/sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13
/sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69
/sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5
Parsing uevent /sys/class/rc/rc0/uevent
/sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce
/sys/class/rc/rc0/uevent uevent DRV_NAME=imon
input device is /dev/input/event5
/sys/class/rc/rc0/protocols protocol rc-6 (enabled)
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6
Enabled protocols: rc-6
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Input sysfs node is /sys/class/rc/rc1/input17/
Event sysfs node is /sys/class/rc/rc1/input17/event11/
Parsing uevent /sys/class/rc/rc1/input17/event11/uevent
/sys/class/rc/rc1/input17/event11/uevent uevent MAJOR=13
/sys/class/rc/rc1/input17/event11/uevent uevent MINOR=75
/sys/class/rc/rc1/input17/event11/uevent uevent DEVNAME=input/event11
Parsing uevent /sys/class/rc/rc1/uevent
/sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
/sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb
input device is /dev/input/event11
/sys/class/rc/rc1/protocols protocol nec (disabled)
Found /sys/class/rc/rc1/ (/dev/input/event11) with:
Driver dvb_usb_cxusb, table rc-dvico-mce
Supported protocols: nec
Enabled protocols:
Name: IR-receiver inside an USB DVB re
bus: 3, vendor/product: 0fe9:db78, version: 0x827b
Repeat delay = 500 ms, repeat period = 125 ms
Input sysfs node is /sys/class/rc/rc2/input19/
Event sysfs node is /sys/class/rc/rc2/input19/event16/
Parsing uevent /sys/class/rc/rc2/input19/event16/uevent
/sys/class/rc/rc2/input19/event16/uevent uevent MAJOR=13
/sys/class/rc/rc2/input19/event16/uevent uevent MINOR=80
/sys/class/rc/rc2/input19/event16/uevent uevent DEVNAME=input/event16
Parsing uevent /sys/class/rc/rc2/uevent
/sys/class/rc/rc2/uevent uevent NAME=rc-empty
/sys/class/rc/rc2/uevent uevent DRV_NAME=dvb_usb_af9035
input device is /dev/input/event16
/sys/class/rc/rc2/protocols protocol nec (disabled)
Found /sys/class/rc/rc2/ (/dev/input/event16) with:
Driver dvb_usb_af9035, table rc-empty
Supported protocols: nec
Enabled protocols:
Name: Leadtek WinFast DTV Dongle Dual
bus: 3, vendor/product: 0413:6a05, version: 0x0200
Repeat delay = 500 ms, repeat period = 125 ms

So only rc0 has any protocols enabled. Let's try to enable nec on rc1

$ sudo /usr/bin/ir-keytable -s rc1 -c
Old keytable cleared
$ sudo /usr/bin/ir-keytable -s rc1 -w /etc/rc_keymaps/dvico-remote
Read dvico_mce table
Wrote 45 keycode(s) to driver
Invalid protocols selected
Couldn't change the IR protocols
$ sudo /usr/bin/ir-keytable -s rc1 -p nec -v
Found device /sys/class/rc/rc0/
Found device /sys/class/rc/rc1/
Found device /sys/class/rc/rc2/
Input sysfs node is /sys/class/rc/rc1/input17/
Event sysfs node is /sys/class/rc/rc1/input17/event11/
Parsing uevent /sys/class/rc/rc1/input17/event11/uevent
/sys/class/rc/rc1/input17/event11/uevent uevent MAJOR=13
/sys/class/rc/rc1/input17/event11/uevent uevent MINOR=75
/sys/class/rc/rc1/input17/event11/uevent uevent DEVNAME=input/event11
Parsing uevent /sys/class/rc/rc1/uevent
/sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
/sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb
input device is /dev/input/event11
/sys/class/rc/rc1/protocols protocol nec (disabled)
Opening /dev/input/event11
Input Protocol version: 0x00010001
/sys/class/rc/rc1//protocols: Invalid argument
Couldn't change the IR 

Re: [PATCH v4 18/36] media: Add i.MX media core driver

[Philipp Zabel]

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  Documentation/media/v4l-drivers/imx.rst   | 542 +
>  drivers/staging/media/Kconfig |   2 +
>  drivers/staging/media/Makefile|   1 +
>  drivers/staging/media/imx/Kconfig |   7 +
>  drivers/staging/media/imx/Makefile|   6 +
>  drivers/staging/media/imx/TODO|  36 ++
>  drivers/staging/media/imx/imx-media-dev.c | 487 +++
>  drivers/staging/media/imx/imx-media-fim.c | 471 +++
>  drivers/staging/media/imx/imx-media-internal-sd.c | 349 +++
>  drivers/staging/media/imx/imx-media-of.c  | 267 
>  drivers/staging/media/imx/imx-media-utils.c   | 701 
> ++
>  drivers/staging/media/imx/imx-media.h | 297 +
>  include/media/imx.h   |  15 +
>  include/uapi/linux/v4l2-controls.h|   4 +
>  14 files changed, 3185 insertions(+)
>  create mode 100644 Documentation/media/v4l-drivers/imx.rst
>  create mode 100644 drivers/staging/media/imx/Kconfig
>  create mode 100644 drivers/staging/media/imx/Makefile
>  create mode 100644 drivers/staging/media/imx/TODO
>  create mode 100644 drivers/staging/media/imx/imx-media-dev.c
>  create mode 100644 drivers/staging/media/imx/imx-media-fim.c
>  create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
>  create mode 100644 drivers/staging/media/imx/imx-media-of.c
>  create mode 100644 drivers/staging/media/imx/imx-media-utils.c
>  create mode 100644 drivers/staging/media/imx/imx-media.h
>  create mode 100644 include/media/imx.h
> 
> diff --git a/Documentation/media/v4l-drivers/imx.rst 
> b/Documentation/media/v4l-drivers/imx.rst
> new file mode 100644
> index 000..f085e43
> --- /dev/null
> +++ b/Documentation/media/v4l-drivers/imx.rst
> @@ -0,0 +1,542 @@
> +i.MX Video Capture Driver
> +=
> +
> +Introduction
> +
> +
> +The Freescale i.MX5/6 contains an Image Processing Unit (IPU), which
> +handles the flow of image frames to and from capture devices and
> +display devices.
> +
> +For image capture, the IPU contains the following internal subunits:
> +
> +- Image DMA Controller (IDMAC)
> +- Camera Serial Interface (CSI)
> +- Image Converter (IC)
> +- Sensor Multi-FIFO Controller (SMFC)
> +- Image Rotator (IRT)
> +- Video De-Interlacing or Combining Block (VDIC)
> +
> +The IDMAC is the DMA controller for transfer of image frames to and from
> +memory. Various dedicated DMA channels exist for both video capture and
> +display paths. During transfer, the IDMAC is also capable of vertical
> +image flip, 8x8 block transfer (see IRT description), pixel component
> +re-ordering (for example UYVY to YUYV) within the same colorspace, and
> +even packed <--> planar conversion. It can also perform a simple
> +de-interlacing by interleaving even and odd lines during transfer
> +(without motion compensation which requires the VDIC).
> +
> +The CSI is the backend capture unit that interfaces directly with
> +camera sensors over Parallel, BT.656/1120, and MIPI CSI-2 busses.
> +
> +The IC handles color-space conversion, resizing (downscaling and
> +upscaling), horizontal flip, and 90/270 degree rotation operations.
> +
> +There are three independent "tasks" within the IC that can carry out
> +conversions concurrently: pre-process encoding, pre-process viewfinder,
> +and post-processing. Within each task, conversions are split into three
> +sections: downsizing section, main section (upsizing, flip, colorspace
> +conversion, and graphics plane combining), and rotation section.
> +
> +The IPU time-shares the IC task operations. The time-slice granularity
> +is one burst of eight pixels in the downsizing section, one image line
> +in the main processing section, one image frame in the rotation section.
> +
> +The SMFC is composed of four independent FIFOs that each can transfer
> +captured frames from sensors directly to memory concurrently via four
> +IDMAC channels.
> +
> +The IRT carries out 90 and 270 degree image rotation operations. The
> +rotation operation is carried out on 8x8 pixel blocks at a time. This
> +operation is supported by the IDMAC which handles the 8x8 block transfer
> +along with block reordering, in coordination with vertical flip.
> +
> +The VDIC handles the conversion of interlaced video to progressive, with
> +support for different motion compensation modes (low, medium, and high
> +motion). The deinterlaced output frames from the VDIC can be sent to the
> +IC pre-process viewfinder task for further conversions. The VDIC also
> +contains a Combiner that combines two image planes, with alpha blending
> +and color keying.
> +
> +In addition to the IPU internal subunits, there are also two units
> 

Re: [PATCH v4 20/36] media: imx: Add CSI subdev driver

[Russell King - ARM Linux]

On Thu, Feb 16, 2017 at 11:52:06AM +, Russell King - ARM Linux wrote:
> On Wed, Feb 15, 2017 at 06:19:22PM -0800, Steve Longerbeam wrote:
> > +static const struct platform_device_id imx_csi_ids[] = {
> > +   { .name = "imx-ipuv3-csi" },
> > +   { },
> > +};
> > +MODULE_DEVICE_TABLE(platform, imx_csi_ids);
> > +
> > +static struct platform_driver imx_csi_driver = {
> > +   .probe = imx_csi_probe,
> > +   .remove = imx_csi_remove,
> > +   .id_table = imx_csi_ids,
> > +   .driver = {
> > +   .name = "imx-ipuv3-csi",
> > +   },
> > +};
> > +module_platform_driver(imx_csi_driver);
> > +
> > +MODULE_DESCRIPTION("i.MX CSI subdev driver");
> > +MODULE_AUTHOR("Steve Longerbeam ");
> > +MODULE_LICENSE("GPL");
> > +MODULE_ALIAS("platform:imx-ipuv3-csi");
> 
> Just a reminder that automatic module loading of this is completely
> broken right now (not your problem) due to this stupid idea in the
> IPUv3 code:
> 
>   if (!ret)
>   ret = platform_device_add(pdev);
>   if (ret) {
>   platform_device_put(pdev);
>   goto err_register;
>   }
> 
>   /*
>* Set of_node only after calling platform_device_add. Otherwise
>* the platform:imx-ipuv3-crtc modalias won't be used.
>*/
>   pdev->dev.of_node = of_node;
> 
> setting pdev->dev.of_node changes the modalias exported to userspace,
> so udev sees a DT based modalias, which causes it to totally miss any
> driver using a non-DT based modalias.
> 
> The IPUv3 code needs fixing, not only for imx-media-csi, but also for
> imx-ipuv3-crtc too, because that module will also suffer the same
> issue.
> 
> The only solution is... don't fsck with dev->of_node assignment.  In
> this case, it's probably much better to pass it in via platform data.
> If you then absolutely must have dev->of_node, doing it in the driver
> means that you avoid the modalias mess before the appropriate driver
> is loaded.  However, that's still not a nice solution because the
> modalias file still ends up randomly changing its contents.
> 
> As I say, not _your_ problem, but it's still a problem that needs
> solving, and I don't want it forgotten about.

I've just hacked up a solution to this, and unfortunately it reveals a
problem with Steve's code.  Picking out the imx & media-related messages:

[8.012191] imx_media_common: module is from the staging directory, the 
quality is unknown, you have been warned.
[8.018175] imx_media: module is from the staging directory, the quality is 
unknown, you have been warned.
[8.748345] imx-media: Registered subdev ipu1_csi0_mux
[8.753451] imx-media: Registered subdev ipu2_csi1_mux
[9.055196] imx219 0-0010: detected IMX219 sensor
[9.090733] imx6_mipi_csi2: module is from the staging directory, the 
quality is unknown, you have been warned.
[9.092247] imx-media: Registered subdev imx219 0-0010
[9.334338] imx-media: Registered subdev imx6-mipi-csi2
[9.372452] imx_media_capture: module is from the staging directory, the 
quality is unknown, you have been warned.
[9.378163] imx_media_capture: module is from the staging directory, the 
quality is unknown, you have been warned.
[9.390033] imx_media_csi: module is from the staging directory, the quality 
is unknown, you have been warned.
[9.394362] imx-media: Received unknown subdev ipu1_csi0
[9.394699] imx-ipuv3-csi: probe of imx-ipuv3-csi.0 failed with error -22
[9.394840] imx-media: Received unknown subdev ipu1_csi1
[9.394887] imx-ipuv3-csi: probe of imx-ipuv3-csi.1 failed with error -22
[9.394992] imx-media: Received unknown subdev ipu2_csi0
[9.395026] imx-ipuv3-csi: probe of imx-ipuv3-csi.4 failed with error -22
[9.395119] imx-media: Received unknown subdev ipu2_csi1
[9.395159] imx-ipuv3-csi: probe of imx-ipuv3-csi.5 failed with error -22
[9.411722] imx_media_vdic: module is from the staging directory, the 
quality is unknown, you have been warned.
[9.412820] imx-media: Registered subdev ipu1_vdic
[9.424687] imx-media: Registered subdev ipu2_vdic
[9.436074] imx_media_ic: module is from the staging directory, the quality 
is unknown, you have been warned.
[9.437455] imx-media: Registered subdev ipu1_ic_prp
[9.437788] imx_media_ic: module is from the staging directory, the quality 
is unknown, you have been warned.
[9.447542] imx-media: Registered subdev ipu1_ic_prpenc
[9.455225] ipu1_ic_prpenc: Registered ipu1_ic_prpenc capture as /dev/video3
[9.459203] imx-media: Registered subdev ipu1_ic_prpvf
[9.460484] imx_media_ic: module is from the staging directory, the quality 
is unknown, you have been warned.
[9.460726] ipu1_ic_prpvf: Registered ipu1_ic_prpvf capture as /dev/video4
[9.460983] imx-media: Registered subdev ipu2_ic_prp
[9.461161] imx-media: Registered subdev ipu2_ic_prpenc
[9.461737] 

Re:[報價]19V,4A 電源適配器(變壓器) 大量需求

[GME]

來信已收到，
早安~
採購人員你好：

我司專門生產交換式電源供應器、USB充電器、POE供電，
全球眾多知名公司都是我們長期合作的客戶，
例如PHILIPS、HP、TOSHIBA、LITEON…等，
我們擁有各國眾多安規認證，
還有提供專業 ODM、OEM 服務

我們公司位於台中，歡迎來坐坐，
誠摯的希望與您合作。
期待你的回覆，將不勝感激。

吉密科技
林榮宗
0422587996
gme.po...@msa.hinet.net

如寄錯請轉交，謝謝

Re: [patch] staging: bcm2835-camera: free first element in array

[Dan Carpenter]

On Wed, Feb 15, 2017 at 01:47:55PM +0100, walter harms wrote:
> 
> 
> Am 15.02.2017 13:25, schrieb Dan Carpenter:
> > We should free gdev[0] so the > should be >=.
> > 
> > Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera 
> > driver.")
> > Signed-off-by: Dan Carpenter 
> > 
> > diff --git a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c 
> > b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
> > index ca15a698e018..9bcd8e546a14 100644
> > --- a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
> > +++ b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
> > @@ -1998,7 +1998,7 @@ static int __init bm2835_mmal_init(void)
> >  free_dev:
> > kfree(dev);
> >  
> > -   for ( ; camera > 0; camera--) {
> > +   for ( ; camera >= 0; camera--) {
> > bcm2835_cleanup_instance(gdev[camera]);
> > gdev[camera] = NULL;
> > }
> 
> since we already know that programmers are bad in counting backwards ...
> 
> is is possible to change that into std. loop like:
> 
>  for(i=0, i< camera; i++ {
>   bcm2835_cleanup_instance(gdev[i]);
>   gdev[i] = NULL;
>   }
> 
> this is way a much more common pattern.

Hm...  My patch is buggy.  It frees the wong thing on the first
iteration through the loop.  I'll resend.

regards,
dan carpenter

Re: [PATCH v4 01/36] [media] dt-bindings: Add bindings for i.MX media driver

[Philipp Zabel]

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> Add bindings documentation for the i.MX media driver.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  Documentation/devicetree/bindings/media/imx.txt | 66 
> +
>  1 file changed, 66 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/imx.txt 
> b/Documentation/devicetree/bindings/media/imx.txt
> new file mode 100644
> index 000..fd5af50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx.txt
> @@ -0,0 +1,66 @@
> +Freescale i.MX Media Video Device
> +=
> +
> +Video Media Controller node
> +---
> +
> +This is the media controller node for video capture support. It is a
> +virtual device that lists the camera serial interface nodes that the
> +media device will control.
> +
> +Required properties:
> +- compatible : "fsl,imx-capture-subsystem";
> +- ports  : Should contain a list of phandles pointing to camera
> + sensor interface ports of IPU devices
> +
> +example:
> +
> +capture-subsystem {
> + compatible = "fsl,capture-subsystem";

"fsl,imx-capture-subsystem"

regards
Philipp

Re: [PATCH v4 20/36] media: imx: Add CSI subdev driver

[Russell King - ARM Linux]

On Wed, Feb 15, 2017 at 06:19:22PM -0800, Steve Longerbeam wrote:
> +static const struct platform_device_id imx_csi_ids[] = {
> + { .name = "imx-ipuv3-csi" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(platform, imx_csi_ids);
> +
> +static struct platform_driver imx_csi_driver = {
> + .probe = imx_csi_probe,
> + .remove = imx_csi_remove,
> + .id_table = imx_csi_ids,
> + .driver = {
> + .name = "imx-ipuv3-csi",
> + },
> +};
> +module_platform_driver(imx_csi_driver);
> +
> +MODULE_DESCRIPTION("i.MX CSI subdev driver");
> +MODULE_AUTHOR("Steve Longerbeam ");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:imx-ipuv3-csi");

Just a reminder that automatic module loading of this is completely
broken right now (not your problem) due to this stupid idea in the
IPUv3 code:

if (!ret)
ret = platform_device_add(pdev);
if (ret) {
platform_device_put(pdev);
goto err_register;
}

/*
 * Set of_node only after calling platform_device_add. Otherwise
 * the platform:imx-ipuv3-crtc modalias won't be used.
 */
pdev->dev.of_node = of_node;

setting pdev->dev.of_node changes the modalias exported to userspace,
so udev sees a DT based modalias, which causes it to totally miss any
driver using a non-DT based modalias.

The IPUv3 code needs fixing, not only for imx-media-csi, but also for
imx-ipuv3-crtc too, because that module will also suffer the same
issue.

The only solution is... don't fsck with dev->of_node assignment.  In
this case, it's probably much better to pass it in via platform data.
If you then absolutely must have dev->of_node, doing it in the driver
means that you avoid the modalias mess before the appropriate driver
is loaded.  However, that's still not a nice solution because the
modalias file still ends up randomly changing its contents.

As I say, not _your_ problem, but it's still a problem that needs
solving, and I don't want it forgotten about.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v4 00/36] i.MX Media Driver

[Russell King - ARM Linux]

Two problems.

On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote:
>   media: imx: propagate sink pad formats to source pads

1) It looks like all cases aren't being caught:

- entity 74: ipu1_csi0 (3 pads, 4 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev13
pad0: Sink
[fmt:SRGGB8/816x616 field:none]
<- "ipu1_csi0_mux":2 [ENABLED]
pad1: Source
[fmt:AYUV32/816x616 field:none
 crop.bounds:(0,0)/816x616
 crop:(0,0)/816x616]
-> "ipu1_ic_prp":0 []
-> "ipu1_vdic":0 []
pad2: Source
[fmt:SRGGB8/816x616 field:none
 crop.bounds:(0,0)/816x616
 crop:(0,0)/816x616]
-> "ipu1_csi0 capture":0 [ENABLED]

While the size has been propagated to pad1, the format has not.

2) /dev/video* device node assignment

I've no idea at the moment how the correct /dev/video* node should be
chosen - initially with Philipp and your previous code, it was
/dev/video3 after initial boot.  Philipp's was consistently /dev/video3.
Yours changed to /dev/video7 when removing and re-inserting the modules
(having fixed that locally.)  This version makes CSI0 be /dev/video7,
but after a remove+reinsert, it becomes (eg) /dev/video8.

/dev/v4l/by-path/platform-capture-subsystem-video-index4 also is not a
stable path - the digit changes (it's supposed to be a stable path.)
After a remove+reinsert, it becomes (eg)
/dev/v4l/by-path/platform-capture-subsystem-video-index5.
/dev/v4l/by-id doesn't contain a symlink for this either.

What this means is that it's very hard to script the setup, because
there's no easy way to know what device is the capture device.  While
it may be possible to do:

media-ctl -d /dev/media1 -p | \
grep -A2 ': ipu1_csi0 capture' | \
sed -n 's|.*\(/dev/video[0-9]*\).*|\1|p'

that's hardly a nice solution - while it fixes the setup script, it
doesn't stop the pain of having to delve around to find the correct
device to use for gstreamer to test with.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v4 17/36] media: Add userspace header file for i.MX

[Philipp Zabel]

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> This adds a header file for use by userspace programs wanting to interact
> with the i.MX media driver. It defines custom v4l2 controls and events
> generated by the i.MX v4l2 subdevices.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  include/uapi/media/Kbuild |  1 +
>  include/uapi/media/imx.h  | 29 +
>  2 files changed, 30 insertions(+)
>  create mode 100644 include/uapi/media/imx.h
> 
> diff --git a/include/uapi/media/Kbuild b/include/uapi/media/Kbuild
> index aafaa5a..fa78958 100644
> --- a/include/uapi/media/Kbuild
> +++ b/include/uapi/media/Kbuild
> @@ -1 +1,2 @@
>  # UAPI Header export list
> +header-y += imx.h
> diff --git a/include/uapi/media/imx.h b/include/uapi/media/imx.h
> new file mode 100644
> index 000..1fdd1c1
> --- /dev/null
> +++ b/include/uapi/media/imx.h
> @@ -0,0 +1,29 @@
> +/*
> + * Copyright (c) 2014-2015 Mentor Graphics Inc.
> + *
> + * 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
> + */
> +
> +#ifndef __UAPI_MEDIA_IMX_H__
> +#define __UAPI_MEDIA_IMX_H__
> +
> +/*
> + * events from the subdevs
> + */
> +#define V4L2_EVENT_IMX_CLASS  V4L2_EVENT_PRIVATE_START
> +#define V4L2_EVENT_IMX_NFB4EOF(V4L2_EVENT_IMX_CLASS + 1)
> +#define V4L2_EVENT_IMX_FRAME_INTERVAL (V4L2_EVENT_IMX_CLASS + 2)

These events are still i.MX specific. I think they shouldn't be.

> +enum imx_ctrl_id {
> + V4L2_CID_IMX_MOTION = (V4L2_CID_USER_IMX_BASE + 0),
> + V4L2_CID_IMX_FIM_ENABLE,
> + V4L2_CID_IMX_FIM_NUM,
> + V4L2_CID_IMX_FIM_TOLERANCE_MIN,
> + V4L2_CID_IMX_FIM_TOLERANCE_MAX,
> + V4L2_CID_IMX_FIM_NUM_SKIP,
> +};
> +
> +#endif

regards
Philipp

Re: [PATCH v4 33/36] media: imx: redo pixel format enumeration and negotiation

[Philipp Zabel]

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> The previous API and negotiation of mbus codes and pixel formats
> was broken, and has been completely redone.
> 
> The negotiation of media bus codes should be as follows:
> 
> CSI:
> 
> sink pad direct src pad  IDMAC src pad
>  -
> RGB (any)IPU RGB   RGB (any)
> YUV (any)IPU YUV   YUV (any)
> Bayer  N/A must be same bayer code as sink

The IDMAC src pad should also use the internal 32-bit RGB / YUV format,
except if bayer/raw mode is selected, in which case the attached capture
video device should only allow a single mode corresponding to the output
pad media bus format.

regards
Philipp

Re: [PATCH v4 30/36] media: imx: update capture dev format on IDMAC output pad set_fmt

[Philipp Zabel]

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> When configuring the IDMAC output pad formats (in ipu_csi,
> ipu_ic_prpenc, and ipu_ic_prpvf subdevs), the attached capture
> device format must also be updated.
> 
> Signed-off-by: Steve Longerbeam 
> Suggested-by: Philipp Zabel 
> ---
>  drivers/staging/media/imx/imx-ic-prpencvf.c | 9 +
>  drivers/staging/media/imx/imx-media-csi.c   | 9 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
> b/drivers/staging/media/imx/imx-ic-prpencvf.c
> index 2be8845..6e45975 100644
> --- a/drivers/staging/media/imx/imx-ic-prpencvf.c
> +++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
> @@ -739,6 +739,7 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
>  struct v4l2_subdev_format *sdformat)
>  {
>   struct prp_priv *priv = sd_to_priv(sd);
> + struct imx_media_video_dev *vdev = priv->vdev;
>   const struct imx_media_pixfmt *cc;
>   struct v4l2_mbus_framefmt *infmt;
>   u32 code;
> @@ -800,6 +801,14 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
>   } else {
>   priv->format_mbus[sdformat->pad] = sdformat->format;
>   priv->cc[sdformat->pad] = cc;
> + if (sdformat->pad == PRPENCVF_SRC_PAD) {
> + /*
> +  * update the capture device format if this is
> +  * the IDMAC output pad
> +  */
> + imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix,
> +   >format, cc);
> + }

This is replaced again by patch 36. These should probably be squashed
together.

regards
Philipp

Re: [PATCH v4 36/36] media: imx: propagate sink pad formats to source pads

[Philipp Zabel]

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
[...]
> diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
> b/drivers/staging/media/imx/imx-ic-prpencvf.c
> index dd9d499..c43f85f 100644
> --- a/drivers/staging/media/imx/imx-ic-prpencvf.c
> +++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
> @@ -806,16 +806,22 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
>   if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
>   cfg->try_fmt = sdformat->format;
>   } else {
> - priv->format_mbus[sdformat->pad] = sdformat->format;
> + struct v4l2_mbus_framefmt *f =
> + >format_mbus[sdformat->pad];
> + struct v4l2_mbus_framefmt *outf =
> + >format_mbus[PRPENCVF_SRC_PAD];
> +
> + *f = sdformat->format;
>   priv->cc[sdformat->pad] = cc;
> - if (sdformat->pad == PRPENCVF_SRC_PAD) {
> - /*
> -  * update the capture device format if this is
> -  * the IDMAC output pad
> -  */
> - imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix,
> -   >format, cc);
> +
> + /* propagate format to source pad */
> + if (sdformat->pad == PRPENCVF_SINK_PAD) {
> + outf->width = f->width;
> + outf->height = f->height;

What about media bus format, field, and colorimetry?

>   }
> +
> + /* update the capture device format from output pad */
> + imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix, outf, cc);
>   }
>  
>   return 0;
> diff --git a/drivers/staging/media/imx/imx-media-csi.c 
> b/drivers/staging/media/imx/imx-media-csi.c
> index 3e6b607..9d9ec03 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -1161,19 +1161,27 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
>   if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
>   cfg->try_fmt = sdformat->format;
>   } else {
> + struct v4l2_mbus_framefmt *f_direct, *f_idmac;
> +
>   priv->format_mbus[sdformat->pad] = sdformat->format;
>   priv->cc[sdformat->pad] = cc;
> - /* Reset the crop window if this is the input pad */
> - if (sdformat->pad == CSI_SINK_PAD)
> +
> + f_direct = >format_mbus[CSI_SRC_PAD_DIRECT];
> + f_idmac = >format_mbus[CSI_SRC_PAD_IDMAC];
> +
> + if (sdformat->pad == CSI_SINK_PAD) {
> + /* reset the crop window */
>   priv->crop = crop;
> - else if (sdformat->pad == CSI_SRC_PAD_IDMAC) {
> - /*
> -  * update the capture device format if this is
> -  * the IDMAC output pad
> -  */
> - imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix,
> -   >format, cc);
> +
> + /* propagate format to source pads */
> + f_direct->width = crop.width;
> + f_direct->height = crop.height;
> + f_idmac->width = crop.width;
> + f_idmac->height = crop.height;

This is missing also media bus format, field and colorimetry
propagation.

>   }
> +
> + /* update the capture device format from IDMAC output pad */
> + imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix, f_idmac, cc);
>   }
>  
>   return 0;
> diff --git a/drivers/staging/media/imx/imx-media-vdic.c 
> b/drivers/staging/media/imx/imx-media-vdic.c
> index 61e6017..55fb522 100644
> --- a/drivers/staging/media/imx/imx-media-vdic.c
> +++ b/drivers/staging/media/imx/imx-media-vdic.c
> @@ -649,8 +649,21 @@ static int vdic_set_fmt(struct v4l2_subdev *sd,
>   if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
>   cfg->try_fmt = sdformat->format;
>   } else {
> - priv->format_mbus[sdformat->pad] = sdformat->format;
> + struct v4l2_mbus_framefmt *f =
> + >format_mbus[sdformat->pad];
> + struct v4l2_mbus_framefmt *outf =
> + >format_mbus[VDIC_SRC_PAD_DIRECT];
> +
> + *f = sdformat->format;
>   priv->cc[sdformat->pad] = cc;
> +
> + /* propagate format to source pad */
> + if (sdformat->pad == VDIC_SINK_PAD_DIRECT ||
> + sdformat->pad == VDIC_SINK_PAD_IDMAC) {
> + outf->width = f->width;
> + outf->height = f->height;
> + outf->field = V4L2_FIELD_NONE;

This is missing colorimetry, too.

regards
Philipp

Re: [PATCH v4 28/36] media: imx: csi: fix crop rectangle changes in set_fmt

[Russell King - ARM Linux]

On Wed, Feb 15, 2017 at 06:19:30PM -0800, Steve Longerbeam wrote:
> diff --git a/drivers/staging/media/imx/imx-media-csi.c 
> b/drivers/staging/media/imx/imx-media-csi.c
> index ae24b42..3cb97e2 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -531,6 +531,10 @@ static int csi_setup(struct csi_priv *priv)
>  
>   ipu_csi_set_window(priv->csi, >crop);
>  
> + ipu_csi_set_downsize(priv->csi,
> +  priv->crop.width == 2 * outfmt->width,
> +  priv->crop.height == 2 * outfmt->height);
> +

This fails to build:

ERROR: "ipu_csi_set_downsize" [drivers/staging/media/imx/imx-media-csi.ko] 
undefined!

ipu_csi_set_downsize needs to be exported if we're going to use it in
a module:

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

[Ramesh Shanmugasundaram]

Hi Rob,

Thank you for the review comments.

> Subject: Re: [PATCH v3 6/7] dt-bindings: media: Add Renesas R-Car DRIF
> binding
> 
> On Tue, Feb 07, 2017 at 03:02:36PM +, 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 | 186
> +
> >  1 file changed, 186 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..6315609
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,186 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +
> > +
> > +R-Car Gen3 DRIF is a SPI like receive only slave device. A general
> > +representation of DRIF interfacing with a master device is shown below.
> > +
> > ++-++-+
> > +| |-SCK--->|CLK  |
> > +|   Master|-SS>|SYNC  DRIFn (slave)  |
> > +| |-SD0--->|D0   |
> > +| |-SD1--->|D1   |
> > ++-++-+
> > +
> > +As per the datasheet, each DRIF channel (drifn) is made up of two
> > +internal channels (drifn0 & drifn1). These two internal channels
> > +share the common CLK & SYNC. Each internal channel has its own
> > +dedicated resources like irq, dma channels, address space & clock.
> > +This internal split is not visible to the external master device.
> > +
> > +The device tree model represents each internal channel as a separate
> node.
> > +The internal channels sharing the CLK & SYNC are tied together by
> > +their phandles using a new property called "renesas,bonding". For the
> > +rest of the documentation, unless explicitly stated, the word channel
> > +implies an internal channel.
> > +
> > +When both internal channels are enabled they need to be managed
> > +together as one (i.e.) they cannot operate alone as independent
> > +devices. Out of the two, one of them needs to act as a primary device
> > +that accepts common properties of both the internal channels. This
> > +channel is identified by a new property called "renesas,primary-bond".
> > +
> > +To summarize,
> > +   - When both the internal channels that are bonded together are
> enabled,
> > + the zeroth channel is selected as primary-bond. This channels
> accepts
> > + properties common to all the members of the bond.
> > +   - When only one of the bonded channels need to be enabled, the
> property
> > + "renesas,bonding" or "renesas,primary-bond" will have no effect.
> That
> > + enabled channel can act alone as any other independent device.
> > +
> > +Required properties of an internal channel:
> > +---
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that channel.
> > +- interrupts: associated with that channel.
> > +- clocks: phandle and clock specifier of that channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channels.
> > +- dma-names: names of the DMA channel: "rx".
> > +- renesas,bonding: phandle to the other channel.
> > +
> > +Optional properties of an internal channel:
> > +---
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of an internal channel when:
> > +   - It is the only enabled channel of the bond (or)
> > +   - If it acts as primary among enabled bonds
> > +
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- renesas,primary-bond: empty property indicating the channel acts as
> primary
> > +   among the bonded channels.
> > +- port: child port node of a channel that defines the local and remote
> > +   endpoints. The remote endpoint is assumed to be a third party tuner
> > +   device endpoint.
> > +
> > +Optional endpoint property:
> > +---
> > +- renesas,sync-active  : Indicates sync signal polarity, 0/1 for
> low/high
> > +

Re: [GIT PULL FOR v4.11] MediaTek JPEG encoder

[Matthias Brugger]

On 13/02/17 13:00, Mauro Carvalho Chehab wrote:

Em Mon, 13 Feb 2017 11:52:07 +0100
Hans Verkuil  escreveu:


Hi Mauro,

This adds the MediaTek JPEG encoder to the media subsystem.

This patch https://patchwork.linuxtv.org/patch/38645/ needs to go through
Matthias Brugger,


Why? It seems easier to just merge it via media tree, as it doesn't
seem to be dependent of anything else.

IMHO, the better would be if Matthias would ack to merge it via
the media tree. On the other hand, it is just a documentation path.
It wouldn't hurt if merged for 4.11, even if the remaining patches
go for 4.12.



Sorry for the late answer:
I'm fine with merging it through your tree. Any patches on dts/dtsi 
files should go through mine, but for the bindings it's fine (and make 
sense) to take them through the driver subsystem maintainers tree.


Regards,
Matthias


so you need to coordinate with him for which kernel this
driver will be merged. This pull request is for 4.11, but since it is so
late in the cycle I can understand if this slips to 4.12.

In any case, this should be coordinated.


It is too late for 4.11. We close our merge window by -rc6, in
order to give janitors some time to check if everything is ok.

Also, unfortunately I won't have any time this week to review
this patchset.

So, let's not rush it and merge it after 4.11-rc1, for 4.12.

Regards,
Mauro



Regards,

Hans

The following changes since commit 9eeb0ed0f30938f31a3d9135a88b9502192c18dd:

  [media] mtk-vcodec: fix build warnings without DEBUG (2017-02-08 12:08:20 
-0200)

are available in the git repository at:

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

for you to fetch changes up to 0f492f30d15aec43248fbdd4d6ceea8f495f4457:

  vcodec: mediatek: Add Maintainers entry for Mediatek JPEG driver (2017-02-13 
11:35:29 +0100)


Rick Chang (3):
  dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder
  vcodec: mediatek: Add Mediatek JPEG Decoder Driver
  vcodec: mediatek: Add Maintainers entry for Mediatek JPEG driver

 Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt |   37 +
 MAINTAINERS   |7 +
 drivers/media/platform/Kconfig|   15 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/mtk-jpeg/Makefile  |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c   | 1306 
+
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h   |  139 
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c |  417 
+++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h |   91 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c  |  160 
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h  |   25 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h|   58 ++
 12 files changed, 2259 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
 create mode 100644 drivers/media/platform/mtk-jpeg/Makefile
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h




Thanks,
Mauro

Re: [PATCH v4 18/36] media: Add i.MX media core driver

[Russell King - ARM Linux]

On Wed, Feb 15, 2017 at 06:19:20PM -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
> 
> Signed-off-by: Steve Longerbeam 

Just as I reported on the 30th January:

Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:614: new blank line at EOF.
+
.git/rebase-apply/patch:626: new blank line at EOF.
+
.git/rebase-apply/patch:668: new blank line at EOF.
+

These need fixing.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver

[Russell King - ARM Linux]

On Wed, Feb 15, 2017 at 06:19:25PM -0800, Steve Longerbeam wrote:
> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> for sensors with a MIPI CSI2 interface.
> 
> Signed-off-by: Steve Longerbeam 

Just like I reported on the 30th January:

.git/rebase-apply/patch:236: trailing whitespace.
 *
warning: 1 line adds whitespace errors.

This needs fixing.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] staging: media: use octal permissions

[Sean Young]

On Wed, Feb 15, 2017 at 04:27:01PM -0600, d...@cako.io wrote:
> Replace all instances of permission macros with octal permissions
> 
> Signed-off-by: David Cako 
> ---
>  drivers/staging/media/lirc/lirc_parallel.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/media/lirc/lirc_parallel.c

lirc_parallel has been dropped, I'm afraid so the patch no longer applies.

Thanks
Sean

Re: [PATCH v2 3/3] [media] dvbsky: MyGica T230C support

[Antti Palosaari]

On 02/16/2017 10:48 AM, Antti Palosaari wrote:

On 02/16/2017 01:31 AM, Stefan Bruens wrote:



+/* attach demod */
+memset(_config, 0, sizeof(si2168_config));


prefer sizeof dst


You mean sizeof(struct si2168_config) ?


yeah. See chapter 14 from kernel coding style documentation, it handles
issue slightly.


argh, I looked wrong! It is *correct*, do not change it. It is just as 
it should. Sorry about noise.


regards
Antti




--
http://palosaari.fi/

Re: [PATCH v2 3/3] [media] dvbsky: MyGica T230C support

[Antti Palosaari]

Hello

On 02/16/2017 01:31 AM, Stefan Bruens wrote:

Hi Antti,

first thanks for for the review. Note the t230c_attach is mostly a copy of the
t330_attach (which is very similar to the t680c_attach), so any of your
comments should probably applied to the other attach functions to have a
common coding style.


Old code could be bad, but imho you could make new code better even it 
makes existing diver coding style slightly inconsistent.




On Mittwoch, 15. Februar 2017 10:27:09 CET Antti Palosaari wrote:

On 02/15/2017 03:51 AM, Stefan Brüns wrote:

[...]

diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c
b/drivers/media/usb/dvb-usb-v2/dvbsky.c index 02dbc6c45423..729496e5a52e
100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -665,6 +665,68 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter
*adap)>
return ret;

 }

+static int dvbsky_mygica_t230c_attach(struct dvb_usb_adapter *adap)
+{
+   struct dvbsky_state *state = adap_to_priv(adap);
+   struct dvb_usb_device *d = adap_to_d(adap);
+   int ret = 0;


you could return ret completely as you don't assign its value runtime


Sure, so something like:

  ...
  return 0;
fail_foo:
  xxx;
fail bar:
  yyy;
  return -ENODEV;

Some of the other attach functions assign ret = -ENODEV and then goto one of
the fail_foo: labels.



+   struct i2c_adapter *i2c_adapter;
+   struct i2c_client *client_demod, *client_tuner;
+   struct i2c_board_info info;
+   struct si2168_config si2168_config;
+   struct si2157_config si2157_config;
+
+   /* attach demod */
+   memset(_config, 0, sizeof(si2168_config));


prefer sizeof dst


You mean sizeof(struct si2168_config) ?


yeah. See chapter 14 from kernel coding style documentation, it handles 
issue slightly.





+   si2168_config.i2c_adapter = _adapter;
+   si2168_config.fe = >fe[0];
+   si2168_config.ts_mode = SI2168_TS_PARALLEL;
+   si2168_config.ts_clock_inv = 1;


it has boolean type


Sure


+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2168", I2C_NAME_SIZE);


I would prefer sizeof dst here too.


Most occurences of similar code in media/usb/ use I2C_NAME_SIZE, found two
occurences of "strlcpy(buf, ..., sizeof(buf)), but of course I can change
this.


+   info.addr = 0x64;
+   info.platform_data = _config;
+
+   request_module(info.type);


Use module name here. Even it is same than device id on that case, it is
not always the case.


While si2157 driver has several supported chip types, si2168 only supports
si2168 (several revisions). Both request_module("foobar") and
request_module(info.type) are common in media/usb/. Change nevertheless?


+   client_demod = i2c_new_device(>i2c_adap, );
+   if (client_demod == NULL ||
+   client_demod->dev.driver == NULL)


You did not ran checkpatch.pl for that patch? or doesn't it complain
anymore about these?


Checkpatch did not complain.


Indentation seem seems to be wrong (see again coding style doc). Also 
those might fit into single line. And not sure comparing even to NULL, 
at least some point preferred style was !foo, but personally I don't mind.




[...]

@@ -858,6 +946,9 @@ static const struct usb_device_id dvbsky_id_table[] =
{

{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_S2_R4,

_s960_props, "Terratec Cinergy S2 Rev.4",
RC_MAP_DVBSKY) },

+   { DVB_USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230C,
+   _t230c_props, "Mygica T230C DVB-T/T2/C",


Drop supported DTV standard names from device name. Also it is MyGica
not Mygica.


The print on the stick says: "MyGica(R) DVB-T2", label on the backside says
"T230C". According to the USB descriptors it is a "Geniatech"
"EyeTV Stick". According to the box it is a "MyGica(R)" "Mini DVB-T2 USB Stick
T230C"

Would "MyGica DVB-T2 T230C" be ok?


I would just use device commercial name, which one seems to be most 
official. Geniatech is manufacturer, but commercial brand they sell 
these is MyGica so at least it is not Geniatech EyeTV Stick which is 
something like design name.


regards
Antti

--
http://palosaari.fi/