Re: Enabling peer to peer device transactions for PCIe devices

[Petrosyan, Ludwig]

Yes I agree it has to be started with the write transaction, according of PCIe 
standard all write transaction are address routed, and I agree with Logan:
if in write transaction TLP the endpoint address written in header the TLP 
should not touch CPU, the PCIe Switch has to route it to endpoint.
The idea was: in MTCA system there is PCIe Switch on MCH (MTCA crate HUB) this 
switch connects CPU to other Crate Slots, so one port is Upstream and others 
are Downstream  ports, DMA read from CPU is usual write on endpoint side, 
Xilinx DMA core has two registers Destination Address and Source Address,
device driver to make DMA has to set up these registers,
usually device driver to start DMA read from Board sets Source address as FPGA 
memory address and Destination address is DMA prepared system address,
in case of testing p2p I set Destination address as physical address of other 
endpoint.
More detailed:
we have so called pcie universal driver: the idea behind is
1. all pcie configuration staff, find enabled BARs, mapping BARs, usual 
read/write and common ioctl (get slot number, get driver version ...) 
implemented in universal driver and EXPORTed.
2. if some system function in new kernel are changed we change it only in 
universal parts (easy support a big number of drivers )
so the universal driver something like PCIe Driver API
3. the universal driver provides read/writ functions so we have the same device 
access API for any PCIe device, we could use the same user application with any 
PCIe device

now. during BARs finding and mapping universal driver keeps pcie endpoint 
physical address in some internal structures, any top driver may get physical 
address
of other pcie endpoint by slot number.
in may case during get_resorce the physical address is 0xB200, I check 
lspci -H1 - -s psie switch port bus address (the endpoint connected to this 
port, checked by lspci -H1 -t) the same address (0xB20) is the memory 
behind bridge, 
I want to make p2p writes to offset 0x4, so I set DMA destination address 
0xB240
is something wrong?

thanks for help
regards

Ludwig

- Original Message -
From: "Logan Gunthorpe" 
To: "David Laight" , "Petrosyan, Ludwig" 

Cc: "Alexander Deucher" , "linux-kernel" 
, "linux-rdma" , 
"linux-nvdimm" , "Linux-media" 
, "dri-devel" , 
"linux-pci" , "John Bridgman" 
, "Felix Kuehling" , "Serguei 
Sagalovitch" , "Paul Blinzer" 
, "Christian Koenig" , "Suravee 
Suthikulpanit" , "Ben Sander" 

Sent: Tuesday, 24 October, 2017 00:04:26
Subject: Re: Enabling peer to peer device transactions for PCIe devices

On 23/10/17 10:08 AM, David Laight wrote:
> It is also worth checking that the hardware actually supports p2p transfers.
> Writes are more likely to be supported then reads.
> ISTR that some intel cpus support some p2p writes, but there could easily
> be errata against them.

Ludwig mentioned a PCIe switch. The few switches I'm aware of support 
P2P transfers. So if everything is setup correctly, the TLPs shouldn't 
even touch the CPU.

But, yes, generally it's a good idea to start with writes and see if 
they work first.

Logan

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:   Tue Oct 24 05:00:15 CEST 2017
media-tree git hash:61065fc3e32002ba48aa6bc3816c1f6f9f8daf55
media_build git hash:   c93534951f5d66bef7f17f16293acf2be346b726
v4l-utils git hash: 482c52f946af4c6b16efa63a35790d92fb65326c
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.12.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: WARNINGS
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.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12.1-i686: OK
linux-4.13-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: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: OK
apps: OK
spec-git: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

RE: [PATCH v4 12/12] intel-ipu3: imgu top level pci device

[Zhi, Yong]

Hi, Sakari,

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sakari Ailus
> Sent: Friday, October 20, 2017 4:15 AM
> To: Zhi, Yong 
> Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian
> Xu ; Mani, Rajmohan
> ; Toivonen, Tuukka
> ; Hu, Jerry W ;
> a...@arndb.de; h...@lst.de; robin.mur...@arm.com; iommu@lists.linux-
> foundation.org; Tomasz Figa 
> Subject: Re: [PATCH v4 12/12] intel-ipu3: imgu top level pci device
> 
> On Tue, Oct 17, 2017 at 10:55:59PM -0500, Yong Zhi wrote:
> > This patch adds support for the Intel IPU v3 as found on Skylake and
> > Kaby Lake SoCs. The driver has a dependency on the firmware binary to
> > function properly.
> >
> > Signed-off-by: Yong Zhi 
> > Signed-off-by: Tomasz Figa 
> > ---
> >  drivers/media/pci/intel/ipu3/Kconfig  |  17 +
> >  drivers/media/pci/intel/ipu3/Makefile |   6 +
> >  drivers/media/pci/intel/ipu3/ipu3.c   | 882
> ++
> >  drivers/media/pci/intel/ipu3/ipu3.h   | 186 +++
> >  4 files changed, 1091 insertions(+)
> >  create mode 100644 drivers/media/pci/intel/ipu3/ipu3.c
> >  create mode 100644 drivers/media/pci/intel/ipu3/ipu3.h
> >
(snip)
> > +/*
> > + * imgu_mem2mem2_ops - used by v4l2 and vb2  */ static const struct
> > +ipu3_mem2mem2_ops imgu_mem2mem2_ops = {
> > +   .s_stream = imgu_mem2mem2_s_stream,
> 
> You have a single instance of this. How about just using
> imgu_mem2mem2_s_stream instead?
> 

Yes, we can remove another level of indirectness.

(snip)
> > +++ b/drivers/media/pci/intel/ipu3/ipu3.h
> > @@ -0,0 +1,186 @@
> > +/*
> > + * Copyright (c) 2017 Intel Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > +version
> > + * 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + */
> > +
> > +#ifndef __IPU3_H
> > +#define __IPU3_H
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "ipu3-css.h"
> > +
> > +/*
> > + * The semantics of the driver is that whenever there is a buffer
> > +available in
> > + * master queue, the driver queues a buffer also to all other active nodes.
> > + * If user space hasn't provided a buffer to all other video nodes
> > +first,
> > + * the driver gets an internal dummy buffer and queues it.
> > + */
> > +#define IMGU_QUEUE_MASTER  IPU3_CSS_QUEUE_IN
> > +#define IMGU_QUEUE_FIRST_INPUT IPU3_CSS_QUEUE_OUT
> > +#define IMGU_MAX_QUEUE_DEPTH   (2 + 2)
> > +
> > +#define IMGU_NODE_IN   0 /* Input RAW image */
> > +#define IMGU_NODE_PARAMS   1 /* Input parameters */
> > +#define IMGU_NODE_OUT  2 /* Main output for still or
> video */
> > +#define IMGU_NODE_VF   3 /* Preview */
> > +#define IMGU_NODE_PV   4 /* Postview for still capture
> */
> > +#define IMGU_NODE_STAT_3A  5 /* 3A statistics */
> > +#define IMGU_NODE_STAT_DVS 6 /* DVS statistics */
> > +#define IMGU_NODE_STAT_LACE7 /* Lace statistics */
> > +#define IMGU_NODE_NUM  8
> > +
> > +#define file_to_intel_ipu3_node(__file) \
> > +   container_of(video_devdata(__file), struct imgu_video_device, vdev)
> > +
> > +#define IPU3_INPUT_MIN_WIDTH   0U
> > +#define IPU3_INPUT_MIN_HEIGHT  0U
> > +#define IPU3_INPUT_MAX_WIDTH   5120U
> > +#define IPU3_INPUT_MAX_HEIGHT  38404U
> > +#define IPU3_OUTPUT_MIN_WIDTH  2U
> > +#define IPU3_OUTPUT_MIN_HEIGHT 2U
> > +#define IPU3_OUTPUT_MAX_WIDTH  4480U
> > +#define IPU3_OUTPUT_MAX_HEIGHT 34004U
> > +
> > +struct ipu3_mem2mem2_buffer {
> > +   /* Public fields */
> > +   struct vb2_v4l2_buffer vbb; /* Must be the first field */
> > +
> > +   /* Private fields */
> > +   struct list_head list;
> > +};
> > +
> > +struct imgu_buffer {
> > +   struct ipu3_mem2mem2_buffer m2m2_buf;   /* Must be the first
> field */
> > +   struct ipu3_css_buffer css_buf;
> > +   struct ipu3_css_map map;
> > +};
> > +
> > +struct imgu_node_mapping {
> > +   int css_queue;
> > +   const char *name;
> > +};
> > +
> > +/**
> > + * struct imgu_video_device
> > + * each node registers as video device and maintains its
> > + * own vb2_queue.
> > + */
> > +struct imgu_video_device {
> > +   const char *name;
> > +   bool output;/* Frames to the driver? */
> > + 

RE: [PATCH v4 11/12] intel-ipu3: Add imgu v4l2 driver

[Zhi, Yong]

Hi, Sakari,

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sakari Ailus
> Sent: Friday, October 20, 2017 4:30 AM
> To: Zhi, Yong 
> Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian
> Xu ; Mani, Rajmohan
> ; Toivonen, Tuukka
> ; Hu, Jerry W ;
> Vijaykumar, Ramya 
> Subject: Re: [PATCH v4 11/12] intel-ipu3: Add imgu v4l2 driver
> 
> Hi Yong,
> 
> On Tue, Oct 17, 2017 at 10:54:56PM -0500, Yong Zhi wrote:
> > ipu3 imgu video device based on v4l2, vb2 and media controller
> > framework.
> >
> > Signed-off-by: Yong Zhi 
> > Signed-off-by: Ramya Vijaykumar 
> > ---
> >  drivers/media/pci/intel/ipu3/ipu3-v4l2.c | 1150
> > ++
> >  1 file changed, 1150 insertions(+)
> >  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-v4l2.c
> >
> > diff --git a/drivers/media/pci/intel/ipu3/ipu3-v4l2.c
> > b/drivers/media/pci/intel/ipu3/ipu3-v4l2.c
> > new file mode 100644
> > index ..4618880b8675
> > --- /dev/null
> > +++ b/drivers/media/pci/intel/ipu3/ipu3-v4l2.c
> > @@ -0,0 +1,1150 @@
(snip)
> > +static int mem2mem2_g_selection(struct ipu3_mem2mem2_device
> *m2m2_dev,
> > +   int node, struct v4l2_selection *s) {
> > +   struct imgu_device *const imgu =
> > +   container_of(m2m2_dev, struct imgu_device, mem2mem2);
> > +
> > +   if (node != IPU3_CSS_QUEUE_IN)
> > +   return -ENOIOCTLCMD;
> > +
> > +   switch (s->target) {
> > +   case V4L2_SEL_TGT_CROP:
> > +   s->r = imgu->rect.eff;
> > +   break;
> > +   case V4L2_SEL_TGT_CROP_BOUNDS:
> > +   break;
> > +   case V4L2_SEL_TGT_CROP_DEFAULT:
> > +   break;
> > +   case V4L2_SEL_TGT_COMPOSE_PADDED:
> > +   break;
> > +   case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> > +   break;
> > +   case V4L2_SEL_TGT_COMPOSE:
> > +   s->r = imgu->rect.bds;
> > +   break;
> > +   case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> > +   break;
> > +
> 
> As the driver uses the V4L2 sub-device interface, the selection API belongsis
> implemented in the sub-device node, not the video nodes.
> 

Ok, will study how to make necessary changes to use sub-dev interface for above.

> > +   default:
> > +   return -EINVAL;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int ipu3_try_fmt(struct file *file, void *fh, struct
> > +v4l2_format *f) {
> > +   struct v4l2_pix_format_mplane *pixm = >fmt.pix_mp;
> > +   const struct ipu3_fmt *fmt;
> > +
> > +   if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
> > +   fmt = find_format(f, M2M_CAPTURE);
> > +   else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> > +   fmt = find_format(f, M2M_OUTPUT);
> > +   else
> > +   return -EINVAL;
> > +
> > +   pixm->pixelformat = fmt->fourcc;
> > +
> > +   memset(pixm->plane_fmt[0].reserved, 0,
> > +  sizeof(pixm->plane_fmt[0].reserved));
> 
> No need for the memset here, the framework handles this.
> 
> Are there limits on the image size?
> 

The memset is added to fix v4l2-compliance failure here.

The image size limit is checked in ipu3-css.c/ipu3_css_queue_init().

(snip)
> > +int ipu3_v4l2_register(struct imgu_device *dev) {
> > +   struct ipu3_mem2mem2_device *m2m2 = >mem2mem2;
> > +   struct v4l2_mbus_framefmt def_bus_fmt;
> > +   struct v4l2_pix_format_mplane def_pix_fmt;
> > +
> > +   int i, r;
> > +
> > +   /* Initialize miscellaneous variables */
> > +   m2m2->streaming = false;
> > +   m2m2->v4l2_file_ops = ipu3_v4l2_fops;
> > +
> > +   /* Set up media device */
> > +   m2m2->media_dev.dev = m2m2->dev;
> > +   strlcpy(m2m2->media_dev.model, m2m2->model,
> > +   sizeof(m2m2->media_dev.model));
> > +   snprintf(m2m2->media_dev.bus_info, sizeof(m2m2-
> >media_dev.bus_info),
> > +"%s", dev_name(m2m2->dev));
> > +   m2m2->media_dev.hw_revision = 0;
> > +   media_device_init(>media_dev);
> > +   r = media_device_register(>media_dev);
> > +   if (r) {
> > +   dev_err(m2m2->dev, "failed to register media device (%d)\n",
> r);
> > +   goto fail_media_dev;
> 
> If there's nothing to clean up you can simply return the error here.

Ack, quite obvious indeed.

> 
> > +   }
> > +
> > +   /* Set up v4l2 device */
> > +   m2m2->v4l2_dev.mdev = >media_dev;
> > +   m2m2->v4l2_dev.ctrl_handler = m2m2->ctrl_handler;
> > +   r = v4l2_device_register(m2m2->dev, >v4l2_dev);
> > +   if (r) {
> > +   dev_err(m2m2->dev, "failed to register V4L2 device (%d)\n",
> r);
> > +   goto fail_v4l2_dev;
> > +   }
> > +
> > +   /* Initialize subdev media entity */
> > +   m2m2->subdev_pads = kzalloc(sizeof(*m2m2->subdev_pads) *
> > +   m2m2->num_nodes, GFP_KERNEL);
> > +   if 

Re: [PATCH v2 2/4] media: dt-bindings: Add bindings for TDA1997X

[Rob Herring]

On Wed, Oct 11, 2017 at 09:45:04PM -0700, Tim Harvey wrote:
> Cc: Rob Herring 
> Signed-off-by: Tim Harvey 
> ---
> v2:
>  - add vendor prefix and remove _ from vidout-portcfg
>  - remove _ from labels
>  - remove max-pixel-rate property
>  - describe and provide example for single output port
>  - use new audio port bindings
> 
> ---
>  .../devicetree/bindings/media/i2c/tda1997x.txt | 179 
> +
>  1 file changed, 179 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt 
> b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> new file mode 100644
> index 000..269d7f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> @@ -0,0 +1,179 @@
> +Device-Tree bindings for the NXP TDA1997x HDMI receiver
> +
> +The TDA19971/73 are HDMI video receivers.
> +
> +The TDA19971 Video port output pins can be used as follows:
> + - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
> + - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
> + - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
> + - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
> + - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] 
> CbCr[11:0]
> + - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
> + - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
> +
> +The TDA19973 Video port output pins can be used as follows:
> + - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
> + - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
> + - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
> +
> +The Video port output pins are mapped via 4-bit 'pin groups' allowing
> +for a variety fo connection possibilities including swapping pin order within

s/fo /of /

> +pin groups. The video_portcfg device-tree property consists of register 
> mapping
> +pairs which map a chip-specific VP output register to a 4-bit pin group. If
> +the pin group needs to be bit-swapped you can use the *_S pin-group defines.

The rest of the binding looks fine, but I have some reservations about 
this. I think this should be common probably. There's been a few 
bindings for display recently that deal with the interface format. Maybe 
some vendor property is needed here to map a standard interface format 
back to pin configuration.

Rob

Re: Enabling peer to peer device transactions for PCIe devices

[Logan Gunthorpe]

On 23/10/17 10:08 AM, David Laight wrote:

It is also worth checking that the hardware actually supports p2p transfers.
Writes are more likely to be supported then reads.
ISTR that some intel cpus support some p2p writes, but there could easily
be errata against them.


Ludwig mentioned a PCIe switch. The few switches I'm aware of support 
P2P transfers. So if everything is setup correctly, the TLPs shouldn't 
even touch the CPU.


But, yes, generally it's a good idea to start with writes and see if 
they work first.


Logan

RE: [PATCH v4 00/12] Intel IPU3 ImgU patchset

[Zhi, Yong]

Hi, Sakari,

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sakari Ailus
> Sent: Friday, October 20, 2017 2:10 AM
> To: Zhi, Yong 
> Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian
> Xu ; Mani, Rajmohan
> ; Toivonen, Tuukka
> ; Hu, Jerry W ;
> a...@arndb.de; h...@lst.de; robin.mur...@arm.com; iommu@lists.linux-
> foundation.org
> Subject: Re: [PATCH v4 00/12] Intel IPU3 ImgU patchset
> 
> Hi Yong,
> 
> On Tue, Oct 17, 2017 at 10:46:48PM -0500, Yong Zhi wrote:
> > This patchset adds support for the Intel IPU3 (Image Processing Unit)
> > ImgU which is essentially a modern memory-to-memory ISP. It implements
> > raw Bayer to YUV image format conversion as well as a large number of
> > other pixel processing algorithms for improving the image quality.
> >
> > Meta data formats are defined for image statistics (3A, i.e. automatic
> > white balance, exposure and focus, histogram and local area contrast
> > enhancement) as well as for the pixel processing algorithm parameters.
> > The documentation for these formats is currently not included in the
> > patchset but will be added in a future version of this set.
> >
> > The algorithm parameters need to be considered specific to a given
> > frame and typically a large number of these parameters change on frame
> > to frame basis. Additionally, the parameters are highly structured
> > (and not a flat space of independent configuration primitives). They
> > also reflect the data structures used by the firmware and the
> > hardware. On top of that, the algorithms require highly specialized
> > user space to make meaningful use of them. For these reasons it has
> > been chosen video buffers to pass
> 
> Do you have a to-do list for this patchset? I think it would be useful to
> maintain one, in case not all the comments have been addressed.
> 

Sure, will add in next update.

> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi

Re: Camera support, Prague next week, sdlcam

[Mauro Carvalho Chehab]

Em Mon, 23 Oct 2017 23:15:57 +0300
Sakari Ailus  escreveu:

> On Mon, Oct 23, 2017 at 09:24:24PM +0200, Hans Verkuil wrote:
> > Sounds good. That's the elevators on level LL by the way.  
> 
> I'll be there, too!
> 

I'll try to join you there too.


Cheers,
Mauro

Re: Camera support, Prague next week, sdlcam

[Sakari Ailus]

On Mon, Oct 23, 2017 at 09:24:24PM +0200, Hans Verkuil wrote:
> Sounds good. That's the elevators on level LL by the way.

I'll be there, too!

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: Camera support, Prague next week, sdlcam

[Hans Verkuil]

Sounds good. That's the elevators on level LL by the way.

Regards,

Hans

On October 23, 2017 8:54:49 PM GMT+02:00, Pavel Machek  wrote:
>Hi!
>
>> > I'll talk about the issues at ELCE in few days:
>> > 
>> >
>https://osseu17.sched.com/event/ByYH/cheap-complex-cameras-pavel-machek-denx-software-engineering-gmbh
>> > 
>> > Will someone else be there? Is there some place where v4l people
>meet?
>> 
>> Why don't we discuss this Tuesday morning at 9am? I have no interest
>in the
>> keynotes on that day, so those who are interested can get together.
>
>Ok, what about 9:30am? The place near the elevators where we were
>talking last time?
>
>And sorry for late reply.
>   Pavel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [RFC PATCH 0/9] V4L2 Jobs API WIP

[Gustavo Padovan]

2017-10-16 Hans Verkuil :

> Hi Alexandre,
> 
> Thank you very much for working on this. Much appreciated!
> 
> I only did a very high-level review of the patch series: there is not much
> point IMHO of doing a detailed review given the upcoming discussions in
> Prague. It's better to wait until we agree with the high-level API.
> 
> Regarding the public API: the ioctls seem sane. It's all very similar to the
> other implementations we've seen.
> 
> I'm still not sure about the name 'job', but this is 'just' a naming issue.
> 
> The part where I have more doubts is the need to create a new device node.
> 
> For the upcoming meeting I would like to discuss whether this cannot be added
> to the media API.
> 
> Originally the plan was that the media API would be subsystem-agnostic and 
> could
> also be used by ALSA/DRM/etc. This never happened and I also am not aware of 
> any
> movement in that area.
> 
> I am wondering whether we should just be realistic and abandon the 'subsystem
> agnostic' part and be willing to add e.g. the job support to the media API.

Stupid question here: is there any techinically possible way to support
it through the media API while being subsystem agnostic?

Gustavo

Re: usb/media/dtt200u: use-after-free in __dvb_frontend_free

[Matthias Schwarzott]

Am 23.10.2017 um 16:41 schrieb Andrey Konovalov:
> Hi!
> 
> I've got the following report while fuzzing the kernel with syzkaller.
> 
> On commit 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (4.14-rc5+).
> 
> dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)'
> in warm state.
> dvb-usb: bulk message failed: -22 (2/1102416563)
> dvb-usb: will use the device's hardware PID filter (table count: 15).
> dvbdev: DVB: registering new adapter (WideView WT-220U PenType
> Receiver (based on ZL353))
> usb 1-1: media controller created
> dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
> usb 1-1: DVB: registering adapter 0 frontend 0 (WideView USB DVB-T)...
> dvbdev: dvb_create_media_entity: media entity 'WideView USB DVB-T' registered.
> Registered IR keymap rc-dtt200u
> rc rc1: IR-receiver inside an USB DVB receiver as
> /devices/platform/dummy_hcd.0/usb1/1-1/rc/rc1
> input: IR-receiver inside an USB DVB receiver as
> /devices/platform/dummy_hcd.0/usb1/1-1/rc/rc1/input9
> dvb-usb: schedule remote query interval to 300 msecs.
> dvb-usb: WideView WT-220U PenType Receiver (based on ZL353)
> successfully initialized and connected.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> usb 1-1: USB disconnect, device number 2
> ==
> BUG: KASAN: use-after-free in __dvb_frontend_free+0x113/0x120
> Write of size 8 at addr 880067d45a00 by task kworker/0:1/24
> 
> CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc5-43687-g06ab8a23e0e6 
> #545
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> Call Trace:
>  __dump_stack lib/dump_stack.c:16
>  dump_stack+0x292/0x395 lib/dump_stack.c:52
>  print_address_description+0x78/0x280 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351
>  kasan_report+0x23d/0x350 mm/kasan/report.c:409
>  __asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435
>  __dvb_frontend_free+0x113/0x120 drivers/media/dvb-core/dvb_frontend.c:156
>  dvb_frontend_put+0x59/0x70 drivers/media/dvb-core/dvb_frontend.c:176
>  dvb_frontend_detach+0x120/0x150 drivers/media/dvb-core/dvb_frontend.c:2803
>  dvb_usb_adapter_frontend_exit+0xd6/0x160
> drivers/media/usb/dvb-usb/dvb-usb-dvb.c:340
>  dvb_usb_adapter_exit drivers/media/usb/dvb-usb/dvb-usb-init.c:116
>  dvb_usb_exit+0x9b/0x200 drivers/media/usb/dvb-usb/dvb-usb-init.c:132
>  dvb_usb_device_exit+0xa5/0xf0 drivers/media/usb/dvb-usb/dvb-usb-init.c:295
>  usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
>  __device_release_driver drivers/base/dd.c:861
>  device_release_driver_internal+0x4f1/0x5c0 drivers/base/dd.c:893
>  device_release_driver+0x1e/0x30 drivers/base/dd.c:918
>  bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
>  device_del+0x5c4/0xab0 drivers/base/core.c:1985
>  usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
>  usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
>  hub_port_connect drivers/usb/core/hub.c:4754
>  hub_port_connect_change drivers/usb/core/hub.c:5009
>  port_event drivers/usb/core/hub.c:5115
>  hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
>  process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
>  worker_thread+0x221/0x1850 kernel/workqueue.c:2253
>  kthread+0x363/0x440 kernel/kthread.c:231
>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
> 
It looks like this is caused by commit
ead666000a5fe34bdc82d61838e4df2d416ea15e ("media: dvb_frontend: only use
kref after initialized").

The writing to "fe->frontend_priv" in dvb_frontend.c:156 is a
use-after-free in case the object dvb_frontend *fe is already freed by
the release callback called in line 153.
Only if the demod driver is based on new style i2c_client the memory is
still accessible.

There are two possible solutions:
1. Clear fe->frontend_priv earlier (before line 153).
2. Do not clear fe->frontend_priv

Can you try if the following patch (solution 1) fixes the issue?

Regards
Matthias

diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index daaf969719e4..f552acdb7d8c 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -150,10 +150,11 @@ static void __dvb_frontend_free(struct
dvb_frontend *fe)

Re: 'LITE-ON USB2.0 DVB-T Tune' driver crash with kernel 4.13 / ubuntu 17.10

[Sean Young]

Hi Laurent,

Please reply to the list.

On Mon, Oct 23, 2017 at 08:48:14PM +0200, Laurent Caumont wrote:
> I'm sorry, the log has been cut when I copy-past it.
> Here is the rest:
> (The crash of the intel driver doesn't seem to make issue to my display.)
> 
> [   12.013019] dvb-usb: found a 'LITE-ON USB2.0 DVB-T Tuner' in warm state.
> [   12.013086] dvb-usb: will pass the complete MPEG2 transport stream
> to the software demuxer.
> [   12.017153] dvbdev: DVB: registering new adapter (LITE-ON USB2.0 DVB-T 
> Tuner)
> [   12.576681] r8169 :03:00.0 enp3s0: link up
> [   12.576687] IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready
> [   12.680633] FS-Cache: Loaded
> [   12.702899] FS-Cache: Netfs 'cifs' registered for caching
> [   12.702965] Key type cifs.spnego registered
> [   12.702967] Key type cifs.idmap registered
> [   12.703119] No dialect specified on mount. Default has changed to a
> more secure dialect, SMB3 (vers=3.0), from CIFS (SMB1). To use the
> less secure SMB1 dialect to access old servers which do not support
> SMB3 specify vers=1.0 on mount. For somewhat newer servers such as
> Windows 7 try vers=2.1.
> [   12.713840] CIFS VFS: cifs_mount failed w/return code = -112
> [   12.762481] vboxdrv: loading out-of-tree module taints kernel.
> [   12.762607] vboxdrv: module verification failed: signature and/or
> required key missing - tainting kernel
> [   12.767368] vboxdrv: Found 4 processor cores
> [   12.785129] vboxdrv: TSC mode is Invariant, tentative frequency 331156 
> Hz
> [   12.785130] vboxdrv: Successfully loaded version 5.1.30_Ubuntu
> (interface 0x002a)
> [   12.790471] VBoxNetFlt: Successfully started.
> [   12.797915] VBoxNetAdp: Successfully started.
> [   12.801981] VBoxPciLinuxInit
> [   12.805804] vboxpci: IOMMU not found (not registered)
> [   13.056044] transfer buffer not dma capable

This issue is fixed in commit b47567071527 ("media: dvb: i2c transfers over
usb cannot be done from stack").

> [   13.056053] [ cut here ]
> [   13.056057] WARNING: CPU: 2 PID: 23 at
> /build/linux-XO_uEE/linux-4.13.0/drivers/usb/core/hcd.c:1595
> usb_hcd_map_urb_for_dma+0x41d/0x620
> [   13.056058] Modules linked in: pci_stub vboxpci(OE) vboxnetadp(OE)
> vboxnetflt(OE) vboxdrv(OE) nls_utf8 cifs ccm fscache binfmt_misc
> intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel
> kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc
> snd_hda_codec_hdmi aesni_intel snd_hda_codec_realtek
> snd_hda_codec_generic aes_x86_64 crypto_simd glue_helper cryptd
> intel_cstate intel_rapl_perf snd_hda_intel eeepc_wmi asus_wmi
> serio_raw sparse_keymap wmi_bmof snd_hda_codec snd_hda_core
> dvb_usb_dibusb_mc dvb_usb_dibusb_mc_common gspca_zc3xx
> dvb_usb_dibusb_common gspca_main snd_usb_audio v4l2_common
> snd_usbmidi_lib snd_hwdep videodev snd_seq_midi snd_seq_midi_event
> media snd_rawmidi dib3000mc dibx000_common dvb_usb snd_pcm dvb_core
> rc_core input_leds joydev snd_seq snd_seq_device snd_timer
> [   13.056077]  snd soundcore shpchp mei_me mei hci_uart btbcm serdev
> btqca btintel bluetooth ecdh_generic acpi_als mac_hid intel_lpss_acpi
> intel_lpss kfifo_buf industrialio acpi_pad cuse parport_pc ppdev lp
> parport ip_tables x_tables autofs4 btrfs xor raid6_pq dm_mirror
> dm_region_hash dm_log hid_generic usbhid uas usb_storage mxm_wmi i915
> i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt r8169
> fb_sys_fops drm mii ahci libahci wmi video pinctrl_sunrisepoint
> i2c_hid pinctrl_intel hid
> [   13.056096] CPU: 2 PID: 23 Comm: kworker/2:0 Tainted: GW
> OE   4.13.0-16-generic #19-Ubuntu
> [   13.056097] Hardware name: System manufacturer System Product
> Name/H110I-PLUS, BIOS 0406 11/16/2015
> [   13.056099] Workqueue: usb_hub_wq hub_event
> [   13.056100] task: 9968b23c17c0 task.stack: aecc40d5
> [   13.056101] RIP: 0010:usb_hcd_map_urb_for_dma+0x41d/0x620
> [   13.056102] RSP: 0018:aecc40d53380 EFLAGS: 00010282
> [   13.056103] RAX: 001f RBX: 9968af39c540 RCX: 
> 
> [   13.056103] RDX:  RSI: 9968bbd0dc78 RDI: 
> 9968bbd0dc78
> [   13.056104] RBP: aecc40d533c0 R08: 0001 R09: 
> 03da
> [   13.056104] R10: 0001 R11:  R12: 
> fff5
> [   13.056105] R13: 0140 R14: 0002 R15: 
> 9968b2382000
> [   13.056106] FS:  () GS:9968bbd0()
> knlGS:
> [   13.056106] CS:  0010 DS:  ES:  CR0: 80050033
> [   13.056107] CR2: 0127 CR3: 0002301ab000 CR4: 
> 003406e0
> [   13.056107] Call Trace:
> [   13.056110]  usb_hcd_submit_urb+0x4ab/0xb70
> [   13.056112]  ? del_timer_sync+0x39/0x40
> [   13.056113]  ? schedule_timeout+0x18a/0x350
> [   13.056114]  ? call_timer_fn+0x130/0x130
> [   13.056115]  usb_submit_urb+0x22d/0x560
> [   13.056117]  ? wake_up_q+0x80/0x80
> [   13.056118]  

Re: Camera support, Prague next week, sdlcam

[Pavel Machek]

Hi!

> > I'll talk about the issues at ELCE in few days:
> > 
> > https://osseu17.sched.com/event/ByYH/cheap-complex-cameras-pavel-machek-denx-software-engineering-gmbh
> > 
> > Will someone else be there? Is there some place where v4l people meet?
> 
> Why don't we discuss this Tuesday morning at 9am? I have no interest in the
> keynotes on that day, so those who are interested can get together.

Ok, what about 9:30am? The place near the elevators where we were
talking last time?

And sorry for late reply.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] media: ov9650: remove unnecessary terminated entry in menu items array

[Akinobu Mita]

The test_pattern_menu[] array has two valid items and a null terminated
item.  So the control's maximum value which is passed to
v4l2_ctrl_new_std_menu_items() should be one.  However,
'ARRAY_SIZE(test_pattern_menu) - 1' is actually passed and it's not
correct.

Fix it by removing unnecessary terminated entry and let the correct
control's maximum value be passed to v4l2_ctrl_new_std_menu_items().

Cc: Sylwester Nawrocki 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Akinobu Mita 
---
 drivers/media/i2c/ov9650.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 6ffb460..69433e1 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -985,7 +985,6 @@ static const struct v4l2_ctrl_ops ov965x_ctrl_ops = {
 static const char * const test_pattern_menu[] = {
"Disabled",
"Color bars",
-   NULL
 };
 
 static int ov965x_initialize_controls(struct ov965x *ov965x)
-- 
2.7.4

Re: [PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver

[Tim Harvey]

On Fri, Oct 20, 2017 at 9:23 AM, Hans Verkuil  wrote:

>>
>> I see the AVI infoframe has hdmi_quantization_range and
>> hdmi_ycc_quantization_range along with vid_code.
>>
>> I'm not at all clear what to do with this information. Is there
>> anything you see in the datasheet [1] that points to something I need
>> to be doing?
>
> You can ignore hdmi_ycc_quantization_range, it is the hdmi_quantization_range
> that you need to read out.
>
> The TDA can receive the following formats:
>
> RGB Full Range
> RGB Limited Range
> YUV Bt.601 (aka SMPTE 170M)
> YUV Rec.709
>
> The YUV formats are always limited range.
>
> The TDA can transmit RGB and YUV to the SoC. You want RGB to be full range and
> YUV to be limited range. YUV can be either 601 or 709.
>
> So if the TDA transmits RGB then you need to support the following 
> conversions:
>
> RGB Full -> RGB Full
> RGB Limited -> RGB Full
> YUV 601 -> RGB Full
> YUV 709 -> RGB Full
>
> And if the TDA transmits YUV then you need these conversions:
>
> RGB Full -> YUV601 or YUV709
> RGB Limited -> YUV601 or YUV709
> YUV601 -> YUV601
> YUV709 -> YUV709
>
> For the RGB to YUV conversion you have a choice of converting to YUV601 or 
> 709.
> I recommend to either always convert to YUV601 or to let it depend on the 
> resolution
> (SDTV YUV601, HDTV YUV709).
>

Ok - this is a good explanation that I should be able to follow. I
will make sure to take into account hdmi_quantization_range when I
setup the colorspace conversion matrix for v3.

> Ideally the application should specify what it wants, but we don't have any 
> API
> support for that.
>

>>
>> The TDA1997x provides only the vertical/horizontal periods and the
>> horizontal pulse
>> width (section 8.3.4 of datasheet [1]).
>>
>> Can you point me to a good primer on the relationship between these
>> values and the h/v back/front porch?
>
> The blanking consists of a front porch width, a sync width and a back porch 
> width.
> 'Width' is normally measured in pixels. Vertical blanking is the same, except 
> that
> is measured in lines. All these values are defined in the standards that 
> define these
> timings (e.g. VESA DMT, CTA-861).
>
> So for 1080p60 the active video is 1920x1080. After each line of 1920 pixels 
> you
> have 88 'pixels' of front porch, a sync pulse of 44 'pixels' and a back porch 
> of
> 148 pixels. Total frame width is 2200. Similar for the vertical.
>
> A good HDMI receiver will give you the exact values for these blanking sizes.
> Especially the sync width/height is important since that can provide 
> additional
> format information when receiving VESA formats.
>
> It looks as if the TDA does not measure in exact pixels but in 27 MHz clock
> periods. Which is an approximation only.
>
> So it appears that what you do is the best you can do.
>
> Although I wonder about the hsper: the datasheet suggests that this is the 
> width,
> not a period. What is the value you read out when you receive 1080p60? If that
> would be an exact width, then that would help a lot since you can compare that
> against bt->hsync.

Here's a list of source modes and the vertical/horizontal period and
horizontal pulse width returned from the TDA:
00: VESA640x480P_60HZ 450427 856 101
01: VESA800x600P_60HZ 447620 711 85
02: VESA1024x768P_60HZ 449952 557 55
03: VESA1280x768P_60HZ 450021 568 11
04: VESA1360x768P_60HZ 449867 564 34
05: VESA1280x960P_60HZ 449981 448 55
06: VESA1280x1024P_60HZ 449833 420 27
07: VESA1400x1050P_60HZ 450372 416 7
08: VESA1600x1200P_60HZ 449981 358 27
09: VESA1920x1200P_60HZ 450355 363 4
10: CEAVIC1440x480I_60HZ 450430 1714 123
11: CEAVIC720x480P_60HZ 450430 856 61
12: CEAVIC1280x720P_60HZ 449981 598 13
13: CEAVIC1280x720P_59.94 450431 599 13
14: CEAVIC1920x1080I_60HZ 449981 798 15
15: CEAVIC1920x1080I_59.95HZ 450431 799 15
16: CEAVIC1920x1080P_30HZ 899962 798 15
17: CEAVIC1920x1080P_29.95HZ 900862 799 15
18: CEAVIC1920x1080P_24HZ 1124953 998 15
19: CEAVIC1920x1080P_23.976HZ 1126077 999 15
20: CEAVIC1920x1080P_60HZ 449981 398 7
21: CEAVIC1920x1080P_59.94HZ 450431 399 7
22: CEAVIC1440x576I_50HZ 539976 1726 127
23: CEAVIC720x576P_50HZ 539976 862 63
24: CEAVIC1280x720P_50HZ 539977 718 13
25: CEAVIC1920x1080I_50HZ 539977 958 15
26: CEAVIC1920x1080P_25HZ 1079954 958 15
27: CEAVIC1920x1080P_50HZ 539977 478 7

so 1080p60 gives a hswidth=7

Tim

RE: Enabling peer to peer device transactions for PCIe devices

[David Laight]

From: Petrosyan Ludwig
> Sent: 22 October 2017 07:14
> Could be I have done is stupid...
> But at first sight it has to be simple:
> The PCIe Write transactions are address routed, so if in the packet header 
> the other endpoint address
> is written the TLP has to be routed (by PCIe Switch to the endpoint), the DMA 
> reading from the end
> point is really write transactions from the endpoint, usually (Xilinx core) 
> to start DMA one has to
> write to the DMA control register of the endpoint the destination address. So 
> I have change the device
> driver to set in this register the physical address of the other endpoint 
> (get_resource start called
> to other endpoint, and it is the same address which I could see in lspci 
> - -s bus-address of the
> switch port, memories behind bridge), so now the endpoint has to start send 
> writes TLP with the other
> endpoint address in the TLP header.
> But this is not working (I want to understand why ...), but I could see the 
> first address of the
> destination endpoint is changed (with the wrong value 0xFF),
> now I want to try prepare in the driver of one endpoint the DMA buffer , but 
> using physical address of
> the other endpoint,
> Could be it will never work, but I want to understand why, there is my error 
> ...

It is also worth checking that the hardware actually supports p2p transfers.
Writes are more likely to be supported then reads.
ISTR that some intel cpus support some p2p writes, but there could easily
be errata against them.

I'd certainly test a single word write to read/write memory location.
First verify against kernel memory, then against a 'slave' board.

I don't know about Xilinx fpga, but we've had 'fun' getting Altera fpga
to do sensible PCIe cycles (I ended up writing a simple dma controller 
that would generate long TLP).
We also found a bug in the Altera logic that processed interleaved
read completions.

David

usb/media/au0828: use-after-free in au0828_rc_unregister

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (4.14-rc5+).

au0828: recv_control_msg() Failed receiving control message, error -71.
au0828: recv_control_msg() Failed receiving control message, error -71.
au0828: recv_control_msg() Failed receiving control message, error -71.
au8522_writereg: writereg error (reg == 0x106, val == 0x0001, ret == -5)
usb 1-1: selecting invalid altsetting 5
au0828: Failure setting usb interface0 to as5
au0828: au0828_usb_probe() au0282_dev_register failed to register on V4L2
==
BUG: KASAN: use-after-free in au0828_rc_unregister+0xaa/0xc0
Read of size 8 at addr 8800626e2b90 by task kworker/1:1/1491

CPU: 1 PID: 1491 Comm: kworker/1:1 Not tainted
4.14.0-rc5-43687-g06ab8a23e0e6 #545
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
 au0828_rc_unregister+0xaa/0xc0 drivers/media/usb/au0828/au0828-input.c:367
 au0828_usb_disconnect+0x63/0x130 drivers/media/usb/au0828/au0828-core.c:189
 au0828_usb_probe+0xb3e/0xf20 drivers/media/usb/au0828/au0828-core.c:660
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26b/0x3c0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26b/0x3c0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x363/0x440 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

The buggy address belongs to the page:
page:ea000189b880 count:0 mapcount:0 mapping:  (null) index:0x0
flags: 0x100()
raw: 0100   
raw:  dead0200 88006c00d980 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 8800626e2a80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 8800626e2b00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>8800626e2b80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ^
 8800626e2c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 8800626e2c80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==

usb/media/mxl111sf: trying to register non-static key in mxl111sf_ctrl_msg

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (4.14-rc5+).

usb 1-1: New USB device found, idVendor=2040, idProduct=c602
usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-1: Product: a
usb 1-1: dvb_usb_v2: found a 'HCW 126xxx' in warm state
usb 1-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to
the software demuxer
dvbdev: DVB: registering new adapter (HCW 126xxx)
usb 1-1: media controller created
dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
usb 1-1: selecting invalid altsetting 1
set interface failed
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc5-43687-g06ab8a23e0e6 #545
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
 __lock_acquire+0x244/0x3610 kernel/locking/lockdep.c:3377
 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:3994
 __mutex_lock_common kernel/locking/mutex.c:756
 __mutex_lock+0x18e/0x1a60 kernel/locking/mutex.c:893
 mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:908
 mxl111sf_ctrl_msg+0x93/0x1f0 drivers/media/usb/dvb-usb-v2/mxl111sf.c:69
 mxl111sf_write_reg+0xc9/0x170 drivers/media/usb/dvb-usb-v2/mxl111sf.c:126
 mxl1x1sf_soft_reset+0x69/0x1a0 drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c:56
 mxl111sf_lg2160_frontend_attach+0x27b/0x9e0
drivers/media/usb/dvb-usb-v2/mxl111sf.c:521
 mxl111sf_frontend_attach_mh+0x1c/0x20
drivers/media/usb/dvb-usb-v2/mxl111sf.c:977
 dvb_usbv2_adapter_frontend_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:655
 dvb_usbv2_adapter_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:818
 dvb_usbv2_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:881
 dvb_usbv2_probe+0x143d/0x32f0 drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:992
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26b/0x3c0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26b/0x3c0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x363/0x440 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
usb 1-1: dvb_usb_v2: usb_bulk_msg() failed=-22
error writing reg: 0xff, val: 0x00
dvb_usb_mxl111sf: probe of 1-1:1.0 failed with error -22

usb/media/dtt200u: use-after-free in __dvb_frontend_free

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (4.14-rc5+).

dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)'
in warm state.
dvb-usb: bulk message failed: -22 (2/1102416563)
dvb-usb: will use the device's hardware PID filter (table count: 15).
dvbdev: DVB: registering new adapter (WideView WT-220U PenType
Receiver (based on ZL353))
usb 1-1: media controller created
dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
usb 1-1: DVB: registering adapter 0 frontend 0 (WideView USB DVB-T)...
dvbdev: dvb_create_media_entity: media entity 'WideView USB DVB-T' registered.
Registered IR keymap rc-dtt200u
rc rc1: IR-receiver inside an USB DVB receiver as
/devices/platform/dummy_hcd.0/usb1/1-1/rc/rc1
input: IR-receiver inside an USB DVB receiver as
/devices/platform/dummy_hcd.0/usb1/1-1/rc/rc1/input9
dvb-usb: schedule remote query interval to 300 msecs.
dvb-usb: WideView WT-220U PenType Receiver (based on ZL353)
successfully initialized and connected.
dvb-usb: bulk message failed: -22 (1/1807119384)
dvb-usb: error -22 while querying for an remote control event.
dvb-usb: bulk message failed: -22 (1/1807119384)
dvb-usb: error -22 while querying for an remote control event.
dvb-usb: bulk message failed: -22 (1/1807119384)
dvb-usb: error -22 while querying for an remote control event.
dvb-usb: bulk message failed: -22 (1/1807119384)
dvb-usb: error -22 while querying for an remote control event.
dvb-usb: bulk message failed: -22 (1/1807119384)
dvb-usb: error -22 while querying for an remote control event.
dvb-usb: bulk message failed: -22 (1/1807119384)
dvb-usb: error -22 while querying for an remote control event.
usb 1-1: USB disconnect, device number 2
==
BUG: KASAN: use-after-free in __dvb_frontend_free+0x113/0x120
Write of size 8 at addr 880067d45a00 by task kworker/0:1/24

CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc5-43687-g06ab8a23e0e6 #545
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435
 __dvb_frontend_free+0x113/0x120 drivers/media/dvb-core/dvb_frontend.c:156
 dvb_frontend_put+0x59/0x70 drivers/media/dvb-core/dvb_frontend.c:176
 dvb_frontend_detach+0x120/0x150 drivers/media/dvb-core/dvb_frontend.c:2803
 dvb_usb_adapter_frontend_exit+0xd6/0x160
drivers/media/usb/dvb-usb/dvb-usb-dvb.c:340
 dvb_usb_adapter_exit drivers/media/usb/dvb-usb/dvb-usb-init.c:116
 dvb_usb_exit+0x9b/0x200 drivers/media/usb/dvb-usb/dvb-usb-init.c:132
 dvb_usb_device_exit+0xa5/0xf0 drivers/media/usb/dvb-usb/dvb-usb-init.c:295
 usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:861
 device_release_driver_internal+0x4f1/0x5c0 drivers/base/dd.c:893
 device_release_driver+0x1e/0x30 drivers/base/dd.c:918
 bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
 device_del+0x5c4/0xab0 drivers/base/core.c:1985
 usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
 usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
 hub_port_connect drivers/usb/core/hub.c:4754
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x363/0x440 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 24:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
 kmalloc ./include/linux/slab.h:493
 kzalloc ./include/linux/slab.h:666
 dtt200u_fe_attach+0x4c/0x110 drivers/media/usb/dvb-usb/dtt200u-fe.c:212
 dtt200u_frontend_attach+0x35/0x80 drivers/media/usb/dvb-usb/dtt200u.c:136
 dvb_usb_adapter_frontend_init+0x32b/0x660
drivers/media/usb/dvb-usb/dvb-usb-dvb.c:286
 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:86
 dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:162
 dvb_usb_device_init+0xf73/0x17f0 drivers/media/usb/dvb-usb/dvb-usb-init.c:277
 dtt200u_usb_probe+0xa1/0xe0 drivers/media/usb/dvb-usb/dtt200u.c:155
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26b/0x3c0 drivers/base/dd.c:710
 

Re: cx231xx IR remote control protocol

[Devin Heitmueller]

Hi Oleh,

On Mon, Oct 23, 2017 at 5:37 AM, Sean Young  wrote:
> Hi Oleh,
>
> On Sun, Oct 22, 2017 at 05:01:05PM +0300, Oleh Kravchenko wrote:
>> Hi,
>>
>> I'm trying add support remote control for tuners:
>> - EvroMedia Full Hybrid Full HD
>> - Astrometa T2hybrid
>>
>> But I'm stuck. Can anybody recognize this protocol?
>

Is there anything to indicate that there actually a separate IR
receiver on the board?  Most cx231xx devices have an MCEUSB compliant
IR RX/TX built into the chip, and thus they don't use a separate part.

Also, IIRC, address 0x30 is the I2C address of the onboard analog
frontend for the cx23102, and I suspect you're just reading the values
out of the AFE.  I suspect you've grabbed a dump from the initial
device plug-in, which would coincide with the initial register
programming of the AFE.

I suspect if you connect the device, let it device settle, *then*
start the I2C capture and hit a key on the remote, you'll see traffic
on a totally different endpoint which would be the IR traffic being
sent back over the IR interface/endpoint.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: 'LITE-ON USB2.0 DVB-T Tune' driver crash with kernel 4.13 / ubuntu 17.10

[Sean Young]

On Sun, Oct 22, 2017 at 07:49:01PM +0200, Laurent Caumont wrote:
> Hello,
> 
> My LITE-ON DVB-T receiver doesn't work anymore with new ubuntu version.
> uname -a
> Linux bureau 4.13.0-16-generic #19-Ubuntu SMP Wed Oct 11 18:35:14 UTC
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> 
> Could you fix the Kernel crash, please ?
> 
> Thanks.
> 
> dmesg

-snip-

> [2.886723] WARN_ON(crtc->config->scaler_state.scaler_id < 0)
> [2.886735] [ cut here ]
> [2.886761] WARNING: CPU: 0 PID: 262 at
> /build/linux-XO_uEE/linux-4.13.0/drivers/gpu/drm/i915/intel_display.c:4755
> skylake_pfit_enable+0xe6/0xf0 [i915]
> [2.886761] Modules linked in: dm_mirror dm_region_hash dm_log
> hid_generic usbhid uas usb_storage i915 mxm_wmi i2c_algo_bit
> drm_kms_helper r8169 syscopyarea sysfillrect mii sysimgblt fb_sys_fops
> drm ahci libahci wmi video pinctrl_sunrisepoint pinctrl_intel i2c_hid
> hid
> [2.886771] CPU: 0 PID: 262 Comm: plymouthd Not tainted
> 4.13.0-16-generic #19-Ubuntu
> [2.886771] Hardware name: System manufacturer System Product
> Name/H110I-PLUS, BIOS 0406 11/16/2015
> [2.886772] task: 8e6e276dc740 task.stack: 9de64132c000
> [2.886788] RIP: 0010:skylake_pfit_enable+0xe6/0xf0 [i915]
> [2.886789] RSP: 0018:9de64132f910 EFLAGS: 00010282
> [2.886790] RAX: 0031 RBX: 8e6e31d5d000 RCX: 
> ba05fcc8
> [2.886790] RDX:  RSI: 0086 RDI: 
> 0247
> [2.886791] RBP: 9de64132f930 R08: 0031 R09: 
> 02e8
> [2.886791] R10: 8e6e26d8a988 R11:  R12: 
> 8e6e26d88000
> [2.886792] R13: 8e6e26d88000 R14: fffd R15: 
> 8e6e323ee800
> [2.886793] FS:  7ff22e6a6b80() GS:8e6e3bc0()
> knlGS:
> [2.886793] CS:  0010 DS:  ES:  CR0: 80050033
> [2.886794] CR2: 555d9ef9d290 CR3: 000227bfc000 CR4: 
> 003406f0
> [2.886794] Call Trace:
> [2.886811]  haswell_crtc_enable+0x1d9/0x820 [i915]
> [2.886825]  intel_update_crtc+0x4b/0xe0 [i915]
> [2.886838]  skl_update_crtcs+0x1ca/0x290 [i915]
> [2.886850]  intel_atomic_commit_tail+0x254/0xf90 [i915]
> [2.886852]  ? __schedule+0x293/0x890
> [2.886864]  intel_atomic_commit+0x3d5/0x490 [i915]
> [2.886873]  ? drm_atomic_check_only+0x37b/0x540 [drm]
> [2.886879]  drm_atomic_commit+0x4b/0x50 [drm]
> [2.886884]  drm_atomic_helper_set_config+0x68/0x90 [drm_kms_helper]
> [2.886890]  __drm_mode_set_config_internal+0x65/0x110 [drm]
> [2.886895]  drm_mode_setcrtc+0x479/0x630 [drm]
> [2.886897]  ? ww_mutex_unlock+0x26/0x30
> [2.886901]  ? drm_mode_getcrtc+0x180/0x180 [drm]
> [2.886906]  drm_ioctl_kernel+0x5d/0xb0 [drm]
> [2.886910]  drm_ioctl+0x31b/0x3d0 [drm]
> [2.886914]  ? drm_mode_getcrtc+0x180/0x180 [drm]
> [2.886916]  ? new_sync_read+0xde/0x130
> [2.886918]  do_vfs_ioctl+0xa5/0x610
> [2.886919]  ? vfs_read+0x115/0x130
> [2.886920]  SyS_ioctl+0x79/0x90
> [2.886922]  entry_SYSCALL_64_fastpath+0x1e/0xa9
> [2.886922] RIP: 0033:0x7ff22dd82ea7
> [2.886923] RSP: 002b:7ffe7cf09a18 EFLAGS: 0246 ORIG_RAX:
> 0010
> [2.886924] RAX: ffda RBX: 55f7852f73a0 RCX: 
> 7ff22dd82ea7
> [2.886924] RDX: 7ffe7cf09a50 RSI: c06864a2 RDI: 
> 0009
> [2.886925] RBP: 0002 R08:  R09: 
> 55f785303500
> [2.886925] R10: 55f785302fc0 R11: 0246 R12: 
> 7ffe7cf09e30
> [2.886925] R13:  R14:  R15: 
> 7ff22e4872d0
> [2.886926] Code: 06 74 81 06 00 41 ff 94 24 f8 06 00 00 5b 41 5c
> 41 5d 41 5e 5d c3 f3 c3 48 c7 c6 a8 34 3e c0 48 c7 c7 db 05 3d c0 e8
> 2b c6 fd f8 <0f> ff eb de 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 83 8f
> 30 37
> [2.886942] ---[ end trace 5721f5dfb92a50e9 ]---
> [2.908604] [drm:pipe_config_err [i915]] *ERROR* mismatch in
> output_types (expected 0x0400, found 0x0080)
> [2.908624] [drm:pipe_config_err [i915]] *ERROR* mismatch in
> pch_pfit.enabled (expected 1, found 0)
> [2.908640] [drm:pipe_config_err [i915]] *ERROR* mismatch in
> pch_pfit.size (expected 0x07800438, found 0x)
> [2.908654] [drm:pipe_config_err [i915]] *ERROR* mismatch in
> pixel_rate (expected 27, found 148499)
> [2.908668] [drm:pipe_config_err [i915]] *ERROR* mismatch in
> base.adjusted_mode.crtc_clock (expected 27, found 148499)
> [2.908669] pipe state doesn't match!
> [2.908676] [ cut here ]

This crash is your intel graphics, nothing to do with dvb.

> [2.908692] WARNING: CPU: 2 PID: 262 at
> /build/linux-XO_uEE/linux-4.13.0/drivers/gpu/drm/i915/intel_display.c:12273
> intel_atomic_commit_tail+0xdb1/0xf90 [i915]
> [2.908692] Modules linked in: dm_mirror dm_region_hash dm_log
> hid_generic usbhid uas usb_storage i915 mxm_wmi 

Re: cx231xx IR remote control protocol

[Sean Young]

Hi Oleh,

On Sun, Oct 22, 2017 at 05:01:05PM +0300, Oleh Kravchenko wrote:
> Hi,
> 
> I'm trying add support remote control for tuners:
> - EvroMedia Full Hybrid Full HD
> - Astrometa T2hybrid
> 
> But I'm stuck. Can anybody recognize this protocol?

I would first figure out what scancodes the remote is sending. Using
a raw IR receiver, e.g. mceusb device, execute:

ir-keytable -s rcN -p all -t

Now you can get the scancodes the remote sends. Next, try to find
the same scancodes in the i2c dump.

It's also possible that the i2c device reports raw IR pulse/space
timings. If this is the case, it might be easiest to use an IR
transmitter and then use a tool like ir-ctl to send a single pulse
and see how that is reported, and build from there.

Then again,  I have no idea about these devices, maybe someone else
recognises this data and might be able to help you more.

Thanks
Sean

> $ i2cdump -y 5 0x30 b
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f0123456789abcdef
> 00: 42 3c 2d 0f 3f 4f 67 13 18 00 72 02 55 05 55 00B<-??Og??.r?U?U.
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 04 02 10 00 46 05 03 07 10 f0 02 00 00 00 00 00???.F??.
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 04 02 10 00 46 05 03 07 00 f0 02 00 00 00 00 00???.F???.??.
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 05 02 10 40 46 05 03 07 00 f0 02 00 00 00 00 00???@F???.??.
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> $ i2cdump -y 18 0x30 b
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f0123456789abcdef
> 00: 42 3c 2c 0f 3f 4f 67 13 18 00 72 02 55 05 55 00B<,??Og??.r?U?U.
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 04 02 10 00 46 05 03 07 00 f0 02 00 00 00 00 00???.F???.??.
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 04 02 10 00 46 05 03 07 00 f0 02 00 00 00 00 00???.F???.??.
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 04 02 10 00 46 05 03 07 00 f0 02 00 00 00 00 00???.F???.??.
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> Here dump of i2c transactions of Windows driver converted to i2c-tools:
> i2cset -y 5 0x30 0x0001 0x10 b
> i2cset -y 5 0x30 0x 0x42 b
> i2cset -y 5 0x30 0x0005 0x0f b
> i2cset -y 5 0x30 0x0008 0x18 b
> i2cget -y 5 0x30 0x0008 b # should be 0x18
> i2cset -y 5 0x30 0x0002 0x40 b
> i2cset -y 5 0x30 0x0002 0x00 b
> i2cset -y 5 0x30 0x000a 0x52 b
> i2cset -y 5 0x30 0x0023 0x00 b
> i2cset -y 5 0x30 0x0043 0x00 b
> i2cset -y 5 0x30 0x0063 0x00 b
> i2cset -y 5 0x30 0x000b 0x02 b
> i2cset -y 5 0x30 0x0027 0x17 b
> i2cset -y 5 0x30 0x0047 0x17 b
> i2cset -y 5 0x30 0x0067 0x17 b
> i2cset -y 5 0x30 0x0022 0x10 b
> i2cset -y 5 0x30 0x0042 0x10 b
> i2cset -y 5 0x30 0x0062 0x10 b
> i2cset -y 5 0x30 0x0027 0x07 b
> i2cset -y 5 0x30 0x0047 0x07 b
> i2cset -y 5 0x30 0x0067 0x07 b
> i2cset -y 5 0x30 0x0029 0xf0 b
> i2cset -y 5 0x30 0x0049 0xf0 b
> i2cset -y 5 0x30 0x0069 0xf0 b
> i2cget -y 5 0x30 0x002a b # should be 0xfa
> i2cset -y 5 0x30 0x002a 0x02 b
> i2cget -y 5 0x30 0x004a b # should be 0xfa
> i2cset -y 5 0x30 0x004a 0x02 b
> i2cget -y 5 0x30 0x006a b # should be 0xfa
> i2cset -y 5 0x30 0x006a 0x02 b
> i2cset -y 5 0x30 0x0026 0x03 b
> i2cset -y 5 0x30 0x0046 0x03 b
> i2cset -y 5 0x30 0x0066 0x03 b
> i2cget -y 5 0x30 0x0028 b # should be 0x00
> i2cget -y 5 0x30 0x0029 b # should be 0xf0
> i2cset -y 5 0x30 0x0001 0x10 b
> i2cset -y 5 0x30 0x 0x42 b
> i2cset -y 5 0x30 0x0005 0x0f b
> i2cset -y 5 0x30 0x0008 0x18 b
> i2cget -y 5 0x30 0x0008 b # should be 0x18
> i2cset -y 5 0x30 0x0002 0x40 b
> i2cset -y 5 0x30 

Re: [RFC PATCH 0/9] V4L2 Jobs API WIP

[Alexandre Courbot]

Hi Sakari, thanks for the feedback!

On Thu, Oct 19, 2017 at 11:43 PM, Sakari Ailus  wrote:
> Hi Alexandre,
>
> On Thu, Sep 28, 2017 at 06:50:18PM +0900, Alexandre Courbot wrote:
>> Hi everyone,
>>
>> Here is a new attempt at the "request" (which I propose to rename "jobs") API
>> for V4L2, hopefully in a manner that can converge to something that will be
>> merged. The core ideas should be easy to grasp for those familiar with the
>> previous attemps, yet there are a few important differences.
>>
>> Most notably, user-space does not need to explicitly allocate and manage
>> requests/jobs (but still can if this makes sense). We noticed that only 
>> specific
>> use-cases require such an explicit management, and opted for a jobs queue 
>> that
>> controls the flow of work over a set of opened devices. This should simplify
>> user-space code quite a bit, while still retaining the ability to manage 
>> states
>> explicitly like the previous request API proposals allowed to do.
>>
>> The jobs API defines a few new concepts that user-space can use to control 
>> the
>> workflow on a set of opened V4L2 devices:
>>
>> A JOB QUEUE can be created from a set of opened FDs that are part of a 
>> pipeline
>> and need to cooperate (be it capture, m2m, or media controller devices).
>>
>> A JOB can then be set up with regular (if slightly modified) V4L2 ioctls, and
>> then submitted to the job queue. Once the job queue schedules the job, its
>> parameters (controls, etc) are applied to the devices of the queue, and itsd
>> buffers are processed. Immediately after a job is submitted, the next job is
>> ready to be set up without further user action.
>>
>> Once a job completes, it must be dequeued and user-space can then read back 
>> its
>> properties (notably controls) at completion time.
>>
>> Internally, the state of jobs is managed through STATE HANDLERS. Each driver
>> supporting the jobs API needs to specify an implementation of a state 
>> handler.
>> Fortunately, most drivers can rely on the generic state handler 
>> implementation
>> that simply records and replays a job's parameter using standard V4L2 
>> functions.
>> Thanks to this, adding jobs API support to a driver relying on the control
>> framework and vb2 only requires a dozen lines of codes.
>>
>> Drivers with specific needs or opportunities for optimization can however
>> provide their own implementation of a state handler. This may in particular 
>> be
>> beneficial for hardware that supports configuration or command buffers 
>> (thinking
>> about VSP1 here).
>>
>> This is still very early work, and focus has been on the following points:
>>
>> * Provide something that anybody can test (currently using vim2m and vivid),
>> * Reuse the current V4L2 APIs as much as possible,
>> * Remain flexible enough to accomodate the inevitable changes that will be
>>   requested,
>> * Keep line count low, even if functionality is missing at the moment.
>>
>> Please keep this in mind while going through the patches. In particular, at 
>> the
>> moment the parameters of a job are limited to integer controls. I know that 
>> much
>> more is expected, but V4L2 has quite a learning curve and I preferred to 
>> focus
>> on the general concepts for now. More is coming though! :)
>>
>> I have written two small example programs that demonstrate the use of this 
>> API:
>>
>> - With a codec device (vim2m): 
>> https://gist.github.com/Gnurou/34c35f1f8e278dad454b51578d239a42
>>
>> - With a capture device (vivid): 
>> https://gist.github.com/Gnurou/5052e6ab41e7c55164b75d2970bc5a04
>>
>> Considering the history with the request API, I don't expect everything 
>> proposed
>> here to be welcome or understood immediately. In particular I apologize for 
>> not
>> reusing any of the previous attempts - I was just more comfortable laying 
>> down
>> my ideas from scratch.
>>
>> If this proposal is not dismissed as complete garbage I will also be happy to
>> discuss it in-person at the mini-summit in Prague. :)
>
> Thank you for the initiative and the patchset.
>
> While reviewing this patchset, I'm concentrating primarily on the approach
> taken and the design, not so much in the actual implementation which I
> don't think matters much at this moment.

Thanks, that is exactly how I hoped things would go for the moment.

>
> It's difficult to avoid seeing many similarities with the Request API
> patches posted earlier on. And not only that, rather you have to start
> looking for the differences in what I could call details, while important
> design decisions could sometimes be only visible in what appear details at
> this point.

I was not quite sure whether I should base this work on one of the
existing patchsets (and in this case, which one) or start from
scratch. This being my first contribution to a new area of the kernel
for me, I decided to start from scratch as it would yield more
educative value.

>
> Both request and jobs APIs have the concept of a 

Re: [RFC PATCH 0/9] V4L2 Jobs API WIP

[Alexandre Courbot]

Hi Hans,

On Mon, Oct 16, 2017 at 8:06 PM, Hans Verkuil  wrote:
> Hi Alexandre,
>
> Thank you very much for working on this. Much appreciated!

Thanks! I feel like there is still a long way before we get this right
though, so your guidance is highly appreciated! :)

> I only did a very high-level review of the patch series: there is not much
> point IMHO of doing a detailed review given the upcoming discussions in
> Prague. It's better to wait until we agree with the high-level API.

Agree on this.

> Regarding the public API: the ioctls seem sane. It's all very similar to the
> other implementations we've seen.
>
> I'm still not sure about the name 'job', but this is 'just' a naming issue.
>
> The part where I have more doubts is the need to create a new device node.
>
> For the upcoming meeting I would like to discuss whether this cannot be added
> to the media API.

Yeah, this device node is not exactly well-received. Although I wanted
to see what people would think about it (and am taking note of
everyone's doubts), its main purpose for now is to make my life easier
and the job API available no matter which driver I am working on. If
we move this to the media API, we need said media API activated, and
of course a media node, which is not a guarantee on every setup.

My point here is that although the current patchset does not reflect
this, the jobs API is also supposed to control media devices. In fact
it is supposed to allow control on a whole range of V4L2 features,
which is why I am hesitating tying it to an existing subsystem at the
moment. Also device and media nodes are currently created by
individual drivers. Jobs allow to control said devices together, thus
in my (maybe flawed!) logic it made more sense if they came from a
global node created by the framework.

Note that I am willing to be flexible on that, and the current setup
is mostly for my convenience as I develop this.

>
> Originally the plan was that the media API would be subsystem-agnostic and 
> could
> also be used by ALSA/DRM/etc. This never happened and I also am not aware of 
> any
> movement in that area.
>
> I am wondering whether we should just be realistic and abandon the 'subsystem
> agnostic' part and be willing to add e.g. the job support to the media API.
>
> We can also consider controlling sub-devices via the media device node instead
> of creating separate v4l-subdev device nodes.
>
> This does not necessarily preclude the use of the media device by other
> subsystems, but it certainly ties it much closer to the media subsystem. On 
> the
> other hand, it does make life easier for us (and I like easy!).
>
> This is just a brainstorm at the moment, but I am interested what others think
> of making /dev/mediaX specific to the media subsystem (at least we chose the
> right name for that device node!).

V4L2 is still fairly new to me, so I am probably still confused, but
aren't /dev/mediaX nodes created by the media subsystem currently?

Cheers,
Alex.

>
> Obviously, if we go into that direction, then that will have an obvious impact
> on the jobs API, especially if we want to be able to control subdevs through 
> the
> media device instead of through the v4l-subdev devices.
>
> Regards,
>
> Hans
>
> On 09/28/2017 11:50 AM, Alexandre Courbot wrote:
>> Hi everyone,
>>
>> Here is a new attempt at the "request" (which I propose to rename "jobs") API
>> for V4L2, hopefully in a manner that can converge to something that will be
>> merged. The core ideas should be easy to grasp for those familiar with the
>> previous attemps, yet there are a few important differences.
>>
>> Most notably, user-space does not need to explicitly allocate and manage
>> requests/jobs (but still can if this makes sense). We noticed that only 
>> specific
>> use-cases require such an explicit management, and opted for a jobs queue 
>> that
>> controls the flow of work over a set of opened devices. This should simplify
>> user-space code quite a bit, while still retaining the ability to manage 
>> states
>> explicitly like the previous request API proposals allowed to do.
>>
>> The jobs API defines a few new concepts that user-space can use to control 
>> the
>> workflow on a set of opened V4L2 devices:
>>
>> A JOB QUEUE can be created from a set of opened FDs that are part of a 
>> pipeline
>> and need to cooperate (be it capture, m2m, or media controller devices).
>>
>> A JOB can then be set up with regular (if slightly modified) V4L2 ioctls, and
>> then submitted to the job queue. Once the job queue schedules the job, its
>> parameters (controls, etc) are applied to the devices of the queue, and itsd
>> buffers are processed. Immediately after a job is submitted, the next job is
>> ready to be set up without further user action.
>>
>> Once a job completes, it must be dequeued and user-space can then read back 
>> its
>> properties (notably controls) at completion time.
>>
>> Internally, the state of jobs is managed 

Re: [RFC PATCH 2/9] [media] v4l2-core: add core jobs API support

[Alexandre Courbot]

Hi Hans,

On Mon, Oct 16, 2017 at 7:01 PM, Hans Verkuil  wrote:
>> +static long v4l2_jobqueue_device_do_ioctl(struct file *filp, unsigned int 
>> cmd,
>> +   void *arg)
>> +{
>> + switch (cmd) {
>> + case VIDIOC_JOBQUEUE_INIT:
>> + return v4l2_jobqueue_ioctl_init(filp, arg);
>> +
>> + case VIDIOC_JOBQUEUE_QJOB:
>> + return v4l2_jobqueue_device_ioctl_qjob(filp, arg);
>> +
>> + case VIDIOC_JOBQUEUE_DQJOB:
>> + return v4l2_jobqueue_device_ioctl_dqjob(filp, arg);
>> +
>> + case VIDIOC_JOBQUEUE_EXPORT_JOB:
>> + return v4l2_jobqueue_device_ioctl_export_job(filp, 
>> arg);
>> +
>> + case VIDIOC_JOBQUEUE_IMPORT_JOB:
>> + return v4l2_jobqueue_device_ioctl_import_job(filp, 
>> arg);
>
> There really is no need for these stub functions, just inline them for each
> case.

Indeed!

>> diff --git a/drivers/media/v4l2-core/v4l2-jobqueue.c 
>> b/drivers/media/v4l2-core/v4l2-jobqueue.c
>> new file mode 100644
>> index ..36d2dd48b086
>> --- /dev/null
>> +++ b/drivers/media/v4l2-core/v4l2-jobqueue.c
>> @@ -0,0 +1,764 @@
>> +/*
>> +V4L2 job queue implementation
>> +
>> +Copyright (C) 2017  The Chromium project
>> +
>> +This program is free software; you can redistribute it and/or modify
>> +it under the terms of the GNU General Public License as published by
>> +the Free Software Foundation; either version 2 of the License, or
>> +(at your option) any later version.
>> +
>> +This program is distributed in the hope that it will be useful,
>> +but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +GNU General Public License for more details.
>> +
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* Limited by the size of atomic_t to track devices that completed a job */
>> +#define V4L2_JOBQUEUE_MAX_DEVICES sizeof(atomic_t)
>> +
>> +/*
>> + * State of all managed devices for a given job
>> + */
>> +struct v4l2_job {
>> + struct kref refcount;
>> + struct v4l2_jobqueue *jq;
>> + /* node in v4l2_jobqueue's queued_jobs or completed_jobs */
>> + struct list_head node;
>> + /* global list of existing jobs for this queue */
>> + struct list_head jobs_list;
>> + /* mask of devices that completed this job */
>> + atomic_t completed;
>> + /* fd exported to user-space */
>> + int fd;
>> + enum v4l2_job_status status;
>> +
>> + /* per-device states */
>> + struct v4l2_job_state *state[0];
>> +};
>> +
>> +/*
>> + * A job queue manages the job flow for a given set of devices, applies 
>> their
>> + * state, and activates them in lockstep.
>> + *
>> + * A job goes through the following stages through its life:
>> + *
>> + * * current_job: the job has been created and is waiting to be queued. 
>> S_CTRL
>> + *   will apply to it. Once queued, it is pushed into
>> + * * queued_jobs: a queue of jobs to be processed in sequential order. The 
>> head
>> + *   of this list becomes the
>> + * * active_job: the job currently being processed by the hardware. Once
>> + *   completed, the next job in queued_job becomes active, and the previous
>> + *   active job goes into
>> + * * completed_jobs: a list of completed jobs waiting to be dequeued by
>> + *   user-space. As user-space called the DQJOB ioctl, the head becomes the
>> + * * dequeued_job: the job on which G_CTRL will be performed on. A job stays
>> + *   in this state until another one is dequeued, at which point it is 
>> deleted.
>> + */
>> +struct v4l2_jobqueue {
>> + /* List of all jobs created for this queue, regardless of state */
>> + struct list_head jobs_list;
>> + /*
>> +  * Job that user-space is currently preparing, to be added to
>> +  * queued_jobs upon QJOB ioctl.
>> +  */
>> + struct v4l2_job *current_job;
>> +
>> + /* List of jobs that are ready to be processed */
>> + struct list_head queued_jobs;
>> +
>> + /* Job that is currently processed by the devices */
>> + struct v4l2_job *active_job;
>
> Shouldn't this be a list as well? I interpret 'active job' as being a
> job that is passed to the various drivers that need to process it.
>
> Just as with video buffers where the hardware may need a minimum of
> buffers before it can start the DMA (min_buffers_needed), so the same
> is true for jobs. E.g. a driver may have to look ahead by a few frames
> to see what changes are requested. Some changes (esp. sensor related)
> can take a few frames before they take effect and the hardware has to
> be programmed ahead of time.

Regarding the number of