cron job: media_tree daily build: OK

2018-06-02 Thread Hans Verkuil
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Sun Jun  3 05:00:14 CEST 2018
media-tree git hash:a00031c159748f322f771f3c1d5ed944cba4bd30
media_build git hash:   464ef972618cc9f845f07c1a4e8957ce2270cf91
v4l-utils git hash: 034fdb4bc2dd380a3c77c0b82c03c99c222ddef4
gcc version:i686-linux-gcc (GCC) 8.1.0
sparse version: 0.5.2
smatch version: 0.5.1
host hardware:  x86_64
host os:4.16.0-1-amd64

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-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-i686: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-i686: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-i686: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.101-i686: OK
linux-3.0.101-x86_64: OK
linux-3.1.10-i686: OK
linux-3.1.10-x86_64: OK
linux-3.2.101-i686: OK
linux-3.2.101-x86_64: OK
linux-3.3.8-i686: OK
linux-3.3.8-x86_64: OK
linux-3.4.113-i686: OK
linux-3.4.113-x86_64: OK
linux-3.5.7-i686: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-i686: OK
linux-3.6.11-x86_64: OK
linux-3.7.10-i686: OK
linux-3.7.10-x86_64: OK
linux-3.8.13-i686: OK
linux-3.8.13-x86_64: OK
linux-3.9.11-i686: OK
linux-3.9.11-x86_64: OK
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.56-i686: OK
linux-3.16.56-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.102-i686: OK
linux-3.18.102-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.51-i686: OK
linux-4.1.51-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.109-i686: OK
linux-4.4.109-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.91-i686: OK
linux-4.9.91-x86_64: OK
linux-4.10.17-i686: OK
linux-4.10.17-x86_64: OK
linux-4.11.12-i686: OK
linux-4.11.12-x86_64: OK
linux-4.12.14-i686: OK
linux-4.12.14-x86_64: OK
linux-4.13.16-i686: OK
linux-4.13.16-x86_64: OK
linux-4.14.42-i686: OK
linux-4.14.42-x86_64: OK
linux-4.15.14-i686: OK
linux-4.15.14-x86_64: OK
linux-4.16.8-i686: OK
linux-4.16.8-x86_64: OK
linux-4.17-rc4-i686: OK
linux-4.17-rc4-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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


Re: [RFC, libv4l]: Make libv4l2 usable on devices with complex pipeline

2018-06-02 Thread Pavel Machek
Hi!

Ok, can I get any comments on this one?
v4l2_open_complex("/file/with/descriptor", 0) can be used to open
whole pipeline at once, and work if it as if it was one device.

Thanks,
Pavel

diff --git a/lib/include/libv4l2.h b/lib/include/libv4l2.h
index ea1870d..f170c3d 100644
--- a/lib/include/libv4l2.h
+++ b/lib/include/libv4l2.h
@@ -109,6 +109,12 @@ LIBV4L_PUBLIC int v4l2_get_control(int fd, int cid);
(note the fd is left open in this case). */
 LIBV4L_PUBLIC int v4l2_fd_open(int fd, int v4l2_flags);
 
+/* v4l2_open_complex: open complex pipeline. Name of pipeline descriptor
+   is passed to v4l2_open_complex(). It opens devices described there and
+   handles mapping controls between devices. 
+ */  
+LIBV4L_PUBLIC int v4l2_open_complex(char *name, int v4l2_flags);
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/lib/libv4l2/libv4l2-priv.h b/lib/libv4l2/libv4l2-priv.h
index 1924c91..1ee697a 100644
--- a/lib/libv4l2/libv4l2-priv.h
+++ b/lib/libv4l2/libv4l2-priv.h
@@ -104,6 +104,7 @@ struct v4l2_dev_info {
void *plugin_library;
void *dev_ops_priv;
const struct libv4l_dev_ops *dev_ops;
+   struct v4l2_controls_map *map;
 };
 
 /* From v4l2-plugin.c */
@@ -130,4 +131,20 @@ static inline void v4l2_plugin_cleanup(void *plugin_lib, 
void *plugin_priv,
 extern const char *v4l2_ioctls[];
 void v4l2_log_ioctl(unsigned long int request, void *arg, int result);
 
+
+struct v4l2_control_map {
+   unsigned long control;
+   int fd;
+};
+
+struct v4l2_controls_map {
+   int main_fd;
+   int num_fds;
+   int num_controls;
+   struct v4l2_control_map map[];
+};
+
+int v4l2_open_pipeline(struct v4l2_controls_map *map, int v4l2_flags);
+LIBV4L_PUBLIC int v4l2_get_fd_for_control(int fd, unsigned long control);
+
 #endif
diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index 2db25d1..39f69db 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -70,6 +70,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include "libv4l2.h"
 #include "libv4l2-priv.h"
 #include "libv4l-plugin.h"
@@ -787,6 +789,8 @@ no_capture:
if (index >= devices_used)
devices_used = index + 1;
 
+   devices[index].map = NULL;
+
/* Note we always tell v4lconvert to optimize src fmt selection for
   our default fps, the only exception is the app explicitly selecting
   a frame rate using the S_PARM ioctl after a S_FMT */
@@ -1056,12 +1060,47 @@ static int v4l2_s_fmt(int index, struct v4l2_format 
*dest_fmt)
return 0;
 }
 
+int v4l2_get_fd_for_control(int fd, unsigned long control)
+{
+   int index = v4l2_get_index(fd);
+   struct v4l2_controls_map *map;
+   int lo = 0;
+   int hi;
+
+   if (index < 0)
+   return fd;
+
+   map = devices[index].map;
+   if (!map)
+   return fd;
+   hi = map->num_controls;
+
+   while (lo < hi) {
+   int i = (lo + hi) / 2;
+   if (map->map[i].control == control) {
+   return map->map[i].fd;
+   }
+   if (map->map[i].control > control) {
+   hi = i;
+   continue;
+   }
+   if (map->map[i].control < control) {
+   lo = i+1;
+   continue;
+   }
+   printf("Bad: impossible condition in binary search\n");
+   exit(1);
+   }
+   return fd;
+}
+
 int v4l2_ioctl(int fd, unsigned long int request, ...)
 {
void *arg;
va_list ap;
int result, index, saved_err;
-   int is_capture_request = 0, stream_needs_locking = 0;
+   int is_capture_request = 0, stream_needs_locking = 0, 
+   is_subdev_request = 0;
 
va_start(ap, request);
arg = va_arg(ap, void *);
@@ -1076,18 +1115,20 @@ int v4l2_ioctl(int fd, unsigned long int request, ...)
   ioctl, causing it to get sign extended, depending upon this behavior 
*/
request = (unsigned int)request;
 
+   /* FIXME */
if (devices[index].convert == NULL)
goto no_capture_request;
 
/* Is this a capture request and do we need to take the stream lock? */
switch (request) {
-   case VIDIOC_QUERYCAP:
case VIDIOC_QUERYCTRL:
case VIDIOC_G_CTRL:
case VIDIOC_S_CTRL:
case VIDIOC_G_EXT_CTRLS:
-   case VIDIOC_TRY_EXT_CTRLS:
case VIDIOC_S_EXT_CTRLS:
+   is_subdev_request = 1;
+   case VIDIOC_QUERYCAP:
+   case VIDIOC_TRY_EXT_CTRLS:
case VIDIOC_ENUM_FRAMESIZES:
case VIDIOC_ENUM_FRAMEINTERVALS:
is_capture_request = 1;
@@ -1151,10 +1192,15 @@ int v4l2_ioctl(int fd, unsigned long int request, ...)
}
 
if (!is_capture_request) {
+ int sub_fd;
 no_capture_request:
+ sub_fd = fd;
+

Re: [PATCH v2 10/10] media: imx.rst: Update doc to reflect fixes to interlaced capture

2018-06-02 Thread Steve Longerbeam




On 06/01/2018 06:44 AM, Philipp Zabel wrote:

On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:


+
+.. code-block:: none
+
+   # Setup links
+   media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]"
+   media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]"
+   media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
+   # Configure pads
+   media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
+   media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]"
+   media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480 field:interlaced]"

Could the example suggest using interlaced-bt to be explicit here?
Actually, I don't think we should allow interlaced on the CSI src pads
at all in this case. Technically it always writes either seq-tb or seq-
bt into the smfc, never interlaced (unless the input is already
interlaced).



Hmm, if the sink is 'alternate', and the requested source is
'interlaced*', perhaps we should allow the source to be
'interlaced*' and not override it. For example, if requested
is 'interlaced-tb', let it be that. IOW assume user knows something
we don't about the original field order, or is experimenting
with finding the correct field order.

Steve



Re: [PATCH v2 10/10] media: imx.rst: Update doc to reflect fixes to interlaced capture

2018-06-02 Thread Steve Longerbeam




On 06/01/2018 06:44 AM, Philipp Zabel wrote:

On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:

Also add an example pipeline for unconverted capture with interweave
on SabreAuto.

Signed-off-by: Steve Longerbeam 
---
  Documentation/media/v4l-drivers/imx.rst | 51 -
  1 file changed, 37 insertions(+), 14 deletions(-)

diff --git a/Documentation/media/v4l-drivers/imx.rst 
b/Documentation/media/v4l-drivers/imx.rst
index 65d3d15..4149b76 100644
--- a/Documentation/media/v4l-drivers/imx.rst
+++ b/Documentation/media/v4l-drivers/imx.rst
@@ -179,9 +179,10 @@ sink pad can take UYVY2X8, but the IDMAC source pad can 
output YUYV2X8.
  If the sink pad is receiving YUV, the output at the capture device can
  also be converted to a planar YUV format such as YUV420.
  
-It will also perform simple de-interlace without motion compensation,

-which is activated if the sink pad's field type is an interlaced type,
-and the IDMAC source pad field type is set to none.
+It will also perform simple interweave without motion compensation,
+which is activated if the sink pad's field type is sequential top-bottom
+or bottom-top or alternate, and the IDMAC source pad field type is
+interlaced (t-b, b-t, or unqualified interlaced).

I think sink pad alternate behaviour should be equal to sink pad top-
bottom for PAL and sink pad bottom-top for NTSC. If we agree on this, we
should mention that here.


Agreed.




  This subdev can generate the following event when enabling the second
  IDMAC source pad:
@@ -383,13 +384,13 @@ and CSC operations and flip/rotation controls. It will 
receive and
  process de-interlaced frames from the ipuX_vdic if ipuX_ic_prp is
  receiving from ipuX_vdic.
  
-Like the ipuX_csiY IDMAC source, it can perform simple de-interlace

+Like the ipuX_csiY IDMAC source, it can perform simple interweaving
  without motion compensation. However, note that if the ipuX_vdic is
  included in the pipeline (ipuX_ic_prp is receiving from ipuX_vdic),
-it's not possible to use simple de-interlace in ipuX_ic_prpvf, since
-the ipuX_vdic has already carried out de-interlacing (with motion
-compensation) and therefore the field type output from ipuX_ic_prp can
-only be none.
+it's not possible to use interweave in ipuX_ic_prpvf, since the
+ipuX_vdic has already carried out de-interlacing (with motion
+compensation) and therefore the field type output from ipuX_vdic
+can only be none (progressive).
  
  Capture Pipelines

  -
@@ -514,10 +515,32 @@ On the SabreAuto, an on-board ADV7180 SD decoder is 
connected to the
  parallel bus input on the internal video mux to IPU1 CSI0.
  
  The following example configures a pipeline to capture from the ADV7180

+video decoder, assuming NTSC 720x480 input signals, using simple
+interweave (unconverted and without motion compensation). The adv7180
+must output sequential or alternating fields (field type 'seq-tb',
+'seq-bt', or 'alternate'):
+
+.. code-block:: none
+
+   # Setup links
+   media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]"
+   media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]"
+   media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
+   # Configure pads
+   media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
+   media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]"
+   media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480 field:interlaced]"

Could the example suggest using interlaced-bt to be explicit here?
Actually, I don't think we should allow interlaced on the CSI src pads
at all in this case. Technically it always writes either seq-tb or seq-
bt into the smfc, never interlaced (unless the input is already
interlaced).


Agreed, I'll make that change in v3 and update the doc.

Steve


+Streaming can then begin on the capture device node at
+"ipu1_csi0 capture". The v4l2-ctl tool can be used to select any
+supported YUV pixelformat on the capture device node.
+
+This example configures a pipeline to capture from the ADV7180
  video decoder, assuming NTSC 720x480 input signals, with Motion
-Compensated de-interlacing. Pad field types assume the adv7180 outputs
-"interlaced". $outputfmt can be any format supported by the ipu1_ic_prpvf
-entity at its output pad:
+Compensated de-interlacing. The adv7180 must output sequential or
+alternating fields (field type 'seq-tb', 'seq-bt', or 'alternate').
+$outputfmt can be any format supported by the ipu1_ic_prpvf entity
+at its output pad:
  
  .. code-block:: none
  
@@ -529,9 +552,9 @@ entity at its output pad:

 media-ctl -l "'ipu1_ic_prp':2 -> 'ipu1_ic_prpvf':0[1]"
 media-ctl -l "'ipu1_ic_prpvf':1 -> 'ipu1_ic_prpvf capture':0[1]"
 # Configure pads
-   media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480]"
-   media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]"
-   media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x480 field:interlaced]"
+   media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
+   med

Re: i.MX6 IPU CSI analog video input on Ventana

2018-06-02 Thread Steve Longerbeam




On 06/01/2018 06:13 AM, Philipp Zabel wrote:

Hi Krzysztof,

On Fri, 2018-06-01 at 12:02 +0200, Krzysztof Hałasa wrote:

Steve Longerbeam  writes:


I tend to agree, I've found conflicting info out there regarding
PAL vs. NTSC field order. And I've never liked having to guess
at input analog standard based on input # lines. I will go ahead
and remove the field order override code.

I've merged your current fix-csi-interlaced.2 branch (2018-06-01
00:06:45 UTC 22ad9f30454b6e46979edf6f8122243591910a3e) along with
"media: adv7180: fix field type" commit and NTSC camera:

media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:alternate]"
media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480]"
media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x480 field:interlaced/-bt/-tb]"

correctly sets:

"adv7180 2-0020":0 [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1_mux":1  [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1_mux":2  [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1":0  [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1":2  [fmt:AYUV32/720x480 field:interlaced/-bt/-tb]

but all 3 cases seem to produce top-first interlaced frames.
The CCIR_CODE_* register dump shows no differences:
2a38014: 010D07DF 00040596 00FF

...it's because the code in drivers/gpu/ipu-v3/ipu-csi.c still sets the
registers depending on the height of the image.

Exactly.


  Hovewer, I'm using 480
lines here, so it should be B-T instead.

My understanding is that the CCIR codes for height == 480 (NTSC)
currently capture the second field (top) first, assuming that for NTSC
the EAV/SAV codes are bottom-field-first.

So the CSI captures SEQ_TB for both PAL and NTSC: The three-bit values
in CCIR_CODE_2/3 are in H,V,F order, and the NTSC case has F=1 for the
field that is captured first, where F=1 is the field that is marked as
second field on the wire, so top. Which means that the captured frame
has two fields captured across frame boundaries, which might be
problematic if the source data was originally progressive.


I agree, for NTSC the CSI will drop the first B field and start capturing
at the T field, and then capture fields across frame boundaries. At
least, that is if we understand how these CCIR registers work: the
CSI will look for H-S-V codes for the start and end of active and blanking
lines, that match the codes written to CCIR_CODE_1/2 for fields 0/1.

I think this must be legacy code from a Freescale BSP requirement
that the CSI must always capture in T-B order. We should remove this
code, so that the CSI always captures field 0 followed by field 1, 
irrespective

of field affinity, as in:

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index 5450a2d..b8b9b6d 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -398,41 +398,20 @@ int ipu_csi_init_interface(struct ipu_csi *csi,
    break;
    case IPU_CSI_CLK_MODE_CCIR656_INTERLACED:
    if (mbus_fmt->width == 720 && mbus_fmt->height == 576) {
-   /*
-    * PAL case
-    *
-    * Field0BlankEnd = 0x6, Field0BlankStart = 0x2,
-    * Field0ActiveEnd = 0x4, Field0ActiveStart = 0
-    * Field1BlankEnd = 0x7, Field1BlankStart = 0x3,
-    * Field1ActiveEnd = 0x5, Field1ActiveStart = 0x1
-    */
    height = 625; /* framelines for PAL */
-
-   ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
- CSI_CCIR_CODE_1);
-   ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
-   ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
    } else if (mbus_fmt->width == 720 && mbus_fmt->height 
== 480) {

-   /*
-    * NTSC case
-    *
-    * Field0BlankEnd = 0x7, Field0BlankStart = 0x3,
-    * Field0ActiveEnd = 0x5, Field0ActiveStart = 0x1
-    * Field1BlankEnd = 0x6, Field1BlankStart = 0x2,
-    * Field1ActiveEnd = 0x4, Field1ActiveStart = 0
-    */
    height = 525; /* framelines for NTSC */
-
-   ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
- CSI_CCIR_CODE_1);
-   ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
-   ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
    } else {
    dev_err(csi->ipu->dev,
    "Unsupported CCIR656 interlaced video 
mode\n");

    spin_unlock_irqrestore(&csi->lock, flags);
    return -EINVAL;
    }
+
+   ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+

Re: i.MX6 IPU CSI analog video input on Ventana

2018-06-02 Thread Steve Longerbeam




On 05/30/2018 11:29 PM, Philipp Zabel wrote:

On Wed, May 30, 2018 at 01:56:34PM -0700, Steve Longerbeam wrote:


On 05/30/2018 11:46 AM, Krzysztof Hałasa wrote:

Steve Longerbeam  writes:


but it should be possible for the user to explicitly request the field
order on CSI output (I can make a patch I guess).

If you think that is the correct behavior, I will remove the override
code. I suppose it makes sense to allow user to select field order even
if that order does not make sense given the input standard. I'm fine
either way, Philipp what is your opinion? I'll go with the popular vote :)

I think it should be up to the user.
Actually, PAL and NTSC aren't valid names in the digital world. Their
meaning ends in the ADV7180 (or equivalent). I don't know if PAL and/or
NTSC specify the field order in the analog frame (meaningful when
someone hooks a camera with progressive sensor and analog, interlaced
output), but the digital YUV422 from ADV to CSI isn't NTSC/PAL anymore.
It's just WxH @ framerate + possible interlacing, sequential fields,
top-bottom or otherwise, etc. The analog standard names could be used
here but just as defaults.

If we were strict (and we don't want to force it), then we should set
NTSC/PAL thing on ADV7180 input, 720x480@29.97i (or 720x576@50i, or
704x... etc) on the input parts of the CSI/IPU (where there are no video
frames yet), and 720x480@29.97i B-T or T-B (or default, or separate
fields - whatever suits the user) on the output from CSI.

I remember the reversed field order was sometimes needed - for example,
PAL DV (the casette camcorder thing) produced B-T frames (same as NTSC),
and to avoid (slight) additional quality loss one had to process it
(up to e.g. .MP4, DVD, and then to HDMI, SCART etc) as B-T.
It wasn't a problem in otherwise-PAL-centric environment.

I tend to agree, I've found conflicting info out there regarding
PAL vs. NTSC field order. And I've never liked having to guess
at input analog standard based on input # lines. I will go ahead
and remove the field order override code.

Note that the code in ipu_csi_init_interface currently hard-codes field
order depending on frame size. It could be that selecting opposite field
order is as easy as switching the relevant parts of writes to registers
CCIR_CODE_2 and _3, but we'd have to pass the desired output field order
to this function. I'd welcome if somebody would verify that this works.


As I said in the other thread, I think we should put this off to some
other time, and remove the code in ipu_csi_init_interface() that
inverts field order according to frame size. This way, CSI will not
be lying to userspace when we tell it the order is BT but the CSI
has actually inverted that to TB.

Also I have concerns about the CSI capturing field 1 _before_ field
0 for NTSC. Doesn't that mean the CSI will drop the B-field in the
first captured frame on stream on, and thereafter mix fields from
different adjacent frames?

Steve



Re: [PATCH v2 06/10] media: imx: Fix field setting logic in try_fmt

2018-06-02 Thread Steve Longerbeam




On 06/01/2018 06:34 AM, Philipp Zabel wrote:

On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:

The logic for setting field type in try_fmt at CSI and PRPENCVF
entities wasn't quite right. The behavior should be:

- No restrictions on field type at sink pads (except ANY, which is filled
   with current sink pad field by imx_media_fill_default_mbus_fields()).

- At IDMAC output pads, if the caller asks for an interlaced output, and
   the input is sequential fields, the IDMAC output channel can accommodate
   by interweaving. The CSI can also interweave if input is alternate
   fields.

- If final source pad field type is alternate, translate to seq_bt or
   seq_tb. But the field order translation was backwards, SD NTSC is BT
   order, SD PAL is TB.

Move this logic to new functions csi_try_field() and prp_try_field().

Signed-off-by: Steve Longerbeam 
---
  drivers/staging/media/imx/imx-ic-prpencvf.c | 22 +++--
  drivers/staging/media/imx/imx-media-csi.c   | 50 +
  2 files changed, 56 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 7e1e0c3..1002eb1 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -833,6 +833,21 @@ static int prp_get_fmt(struct v4l2_subdev *sd,
return ret;
  }
  
+static void prp_try_field(struct prp_priv *priv,

+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat)
+{
+   struct v4l2_mbus_framefmt *infmt =
+   __prp_get_fmt(priv, cfg, PRPENCVF_SINK_PAD, sdformat->which);
+
+   /* no restrictions on sink pad field type */
+   if (sdformat->pad == PRPENCVF_SINK_PAD)
+   return;
+
+   if (!idmac_interweave(sdformat->format.field, infmt->field))
+   sdformat->format.field = infmt->field;

This is not strict enough. As I wrote in reply to patch 4, we can only
do SEQ_TB -> INTERLACED_TB and SEQ_BT -> INTERLACED_BT interweaving.


Agreed.

Steve



Re: [PATCH v2 04/10] media: imx: interweave only for sequential input/interlaced output fields

2018-06-02 Thread Steve Longerbeam




On 06/01/2018 06:33 AM, Philipp Zabel wrote:

Hi Steve,

On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:

IDMAC interlaced scan, a.k.a. interweave, should be enabled at the
IDMAC output pads only if the input field type is 'seq-bt' or 'seq-tb',
and the IDMAC output pad field type is 'interlaced*'. Move this
determination to a new macro idmac_interweave().

V4L2_FIELD_HAS_BOTH() macro should not be used on the input to determine
enabling interlaced/interweave scan. That macro includes the 'interlaced'
field types, and in those cases the data is already interweaved with
top/bottom field lines.

The CSI will capture whole frames when the source specifies alternate
field mode. So the CSI also enables interweave at the IDMAC output pad
for alternate input field type.

Signed-off-by: Steve Longerbeam 
---
  drivers/staging/media/imx/imx-ic-prpencvf.c | 22 ++
  drivers/staging/media/imx/imx-media-csi.c   | 22 ++
  2 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index ae453fd..894db21 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -132,6 +132,18 @@ static inline struct prp_priv *sd_to_priv(struct 
v4l2_subdev *sd)
return ic_priv->task_priv;
  }
  
+/*

+ * If the field type at IDMAC output pad is interlaced, and
+ * the input is sequential fields, the IDMAC output channel
+ * can accommodate by interweaving.
+ */
+static inline bool idmac_interweave(enum v4l2_field outfield,
+   enum v4l2_field infield)
+{
+   return V4L2_FIELD_IS_INTERLACED(outfield) &&
+   V4L2_FIELD_IS_SEQUENTIAL(infield);
+}

This is ok in this patch, but we can't use this check in the following
TRY_FMT patch as there is no way to interweave
SEQ_TB -> INTERLACED_BT (because in SEQ_TB the B field is newer than T,
but in INTERLACED_BT it has to be older) or SEQ_BT -> INTERLACED_TB (the
other way around).


Agreed, let's enforce userspace field order to same order from
the originating source.

Steve





+
  static void prp_put_ipu_resources(struct prp_priv *priv)
  {
if (priv->ic)
@@ -353,6 +365,7 @@ static int prp_setup_channel(struct prp_priv *priv,
struct v4l2_mbus_framefmt *infmt;
unsigned int burst_size;
struct ipu_image image;
+   bool interweave;
int ret;
  
  	infmt = &priv->format_mbus[PRPENCVF_SINK_PAD];

@@ -365,6 +378,9 @@ static int prp_setup_channel(struct prp_priv *priv,
image.rect.width = image.pix.width;
image.rect.height = image.pix.height;
  
+	interweave = (idmac_interweave(image.pix.field, infmt->field) &&

+ channel == priv->out_ch);
+
if (rot_swap_width_height) {
swap(image.pix.width, image.pix.height);
swap(image.rect.width, image.rect.height);
@@ -405,9 +421,7 @@ static int prp_setup_channel(struct prp_priv *priv,
if (rot_mode)
ipu_cpmem_set_rotation(channel, rot_mode);
  
-	if (image.pix.field == V4L2_FIELD_NONE &&

-   V4L2_FIELD_HAS_BOTH(infmt->field) &&
-   channel == priv->out_ch)
+   if (interweave)
ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline);

This only works for SEQ_TB -> INTERLACED_TB interweave.
For SEQ_BT -> INTERLACED_BT we have to start at +1 line offset and set
ipu_cpmem_interlaced_scan to -image.pix.bytesperline.

regards
Philipp




Re: [PATCH v2 01/10] media: imx-csi: Pass sink pad field to ipu_csi_init_interface

2018-06-02 Thread Steve Longerbeam




On 06/01/2018 06:22 AM, Philipp Zabel wrote:

On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:

The output pad's field type was being passed to ipu_csi_init_interface(),
in order to deal with field type 'alternate' at the sink pad, which
is not understood by ipu_csi_init_interface().

Remove that code and pass the sink pad field to ipu_csi_init_interface().
The latter function will have to explicity deal with field type 'alternate'
when setting up the CSI interface for BT.656 busses.

I fear this won't be enough. If we want to capture
sink:ALTERNATE/SEQ_TB/SEQ_BT -> src:SEQ_TB we have to configure the CSI
differently than if we want to capture
ALTERNATE/SEQ_TB/SEQ_BT -> src:SEQ_BT. (And differently for NTSC and
PAL). For NTSC sink:ALTERNATE should behave like sink:SEQ_BT, and for
PAL sink:ALTERNATE should behave like sink:SEQ_TB.


I think we should return to enforcing field order to userspace that
matches field order from the source, which is what I had implemented
previously. I agree with you that we should put off allowing inverting
field order.



Interweaving SEQ_TB to INTERLACED_TB should work right now, but to
interweave SEQ_BT to INTERLACED_BT, we need to add one line offset to
the frame start and use a negative interlaced scanline offset.


Is that because ipu_csi_init_interface() is inverting the F-bit for
NTSC? I think we should remove that code, I will comment on
that in another thread.

Steve







Reported-by: Krzysztof Hałasa 
Signed-off-by: Steve Longerbeam 
---
  drivers/staging/media/imx/imx-media-csi.c | 13 ++---
  1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 95d7805..9bc555c 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -629,12 +629,10 @@ static void csi_idmac_stop(struct csi_priv *priv)
  /* Update the CSI whole sensor and active windows */
  static int csi_setup(struct csi_priv *priv)
  {
-   struct v4l2_mbus_framefmt *infmt, *outfmt;
+   struct v4l2_mbus_framefmt *infmt;
struct v4l2_mbus_config mbus_cfg;
-   struct v4l2_mbus_framefmt if_fmt;
  
  	infmt = &priv->format_mbus[CSI_SINK_PAD];

-   outfmt = &priv->format_mbus[priv->active_output_pad];
  
  	/* compose mbus_config from the upstream endpoint */

mbus_cfg.type = priv->upstream_ep.bus_type;
@@ -642,20 +640,13 @@ static int csi_setup(struct csi_priv *priv)
priv->upstream_ep.bus.mipi_csi2.flags :
priv->upstream_ep.bus.parallel.flags;
  
-	/*

-* we need to pass input frame to CSI interface, but
-* with translated field type from output format
-*/
-   if_fmt = *infmt;
-   if_fmt.field = outfmt->field;
-
ipu_csi_set_window(priv->csi, &priv->crop);
  
  	ipu_csi_set_downsize(priv->csi,

 priv->crop.width == 2 * priv->compose.width,
 priv->crop.height == 2 * priv->compose.height);
  
-	ipu_csi_init_interface(priv->csi, &mbus_cfg, &if_fmt);

+   ipu_csi_init_interface(priv->csi, &mbus_cfg, infmt);
  
  	ipu_csi_set_dest(priv->csi, priv->dest);
  




Re: [RFC PATCH v1 0/4] Add BPF decoders to ir-keytable

2018-06-02 Thread Sean Young
On Sat, Jun 02, 2018 at 01:37:54PM +0100, Sean Young wrote:
> This is not ready for merging yet, however while I finish this work I would
> like some feedback and ideas.
> 
> The idea is that IR decoders can be written in C, compiled to BPF relocatable
> object file. Any global variables can overriden, so we can supports lots
> of variants of similiar protocols (just like in the lircd.conf file).
> 
> The existing rc_keymap file format can't be used for variables, so I've
> converted the format to toml. An alternative would be to use the existing
> lircd.conf file format, but it's a very awkward file to parse in C and it
> contains many features which are irrelevant to us.
> 
> We use libelf to load the bpf relocatable object file.
> 
> After loading our example grundig keymap with bpf decoder, the output of
> ir-keytable is:
> 
> Found /sys/class/rc/rc0/ (/dev/input/event8) with:
>   Name: Winbond CIR
>   Driver: winbond-cir, table: rc-rc6-mce
>   lirc device: /dev/lirc0
>   Attached bpf protocols: grundig
>   Supported protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 
> sharp xmp imon 
>   Enabled protocols: lirc
>   bus: 25, vendor/product: 10ad:00f1, version: 0x0004
>   Repeat delay = 500 ms, repeat period = 125 ms
> 
> 
> Steps to complete this work:
>  - Write more IR decoders
>  - More rc_keymaps
>  - More testing
>  - lircd.conf to toml converter script (python/perl?)
> 
> Sean Young (4):
>   keytable: add toml keymap reader
>   keytable: convert keymaps to new toml format

This commit has not made it to the list yet, I guess because it is so large.

Here it is:

https://git.linuxtv.org/syoung/v4l-utils.git/commit/?id=8e0522c73d832f086958e6cd7774a3e37bbab6bf


>   keytable: add support for BPF based decoders
>   keytable: add bpf protocols
> 
>  Makefile.am   |4 +-
>  configure.ac  |   16 +
>  include/linux/bpf.h   | 2644 +
>  utils/keytable/Makefile.am|   13 +-
>  utils/keytable/bpf.c  |  515 
>  utils/keytable/bpf.h  |  110 +
>  utils/keytable/bpf_load.c |  457 +++
>  utils/keytable/bpf_load.h |   41 +
>  utils/keytable/bpf_protocols/Makefile.am  |   14 +
>  utils/keytable/bpf_protocols/bpf_helpers.h|  302 ++
>  utils/keytable/bpf_protocols/grundig.c|  113 +
>  utils/keytable/gen_keytables.pl   |   33 +-
>  utils/keytable/ir-keytable.1.in   |4 +-
>  utils/keytable/keytable.c |  370 ++-
>  utils/keytable/rc_keymaps/adstech_dvb_t_pci   |   45 -
>  .../rc_keymaps/adstech_dvb_t_pci.toml |   47 +
>  utils/keytable/rc_keymaps/af9005  |   37 -
>  utils/keytable/rc_keymaps/af9005.toml |   39 +
>  utils/keytable/rc_keymaps/alink_dtu_m |   19 -
>  utils/keytable/rc_keymaps/alink_dtu_m.toml|   23 +
>  .../keytable/rc_keymaps/allwinner_ba10_tv_box |   15 -
>  .../rc_keymaps/allwinner_i12_a20_tv_box   |   28 -
>  utils/keytable/rc_keymaps/anysee  |   45 -
>  utils/keytable/rc_keymaps/anysee.toml |   49 +
>  utils/keytable/rc_keymaps/apac_viewcomp   |   32 -
>  utils/keytable/rc_keymaps/apac_viewcomp.toml  |   34 +
>  utils/keytable/rc_keymaps/astrometa_t2hybrid  |   22 -
>  .../rc_keymaps/astrometa_t2hybrid.toml|   26 +
>  utils/keytable/rc_keymaps/asus_pc39   |   40 -
>  utils/keytable/rc_keymaps/asus_pc39.toml  |   44 +
>  utils/keytable/rc_keymaps/asus_ps3_100|   42 -
>  utils/keytable/rc_keymaps/asus_ps3_100.toml   |   46 +
>  .../keytable/rc_keymaps/ati_tv_wonder_hd_600  |   25 -
>  .../rc_keymaps/ati_tv_wonder_hd_600.toml  |   27 +
>  utils/keytable/rc_keymaps/ati_x10 |   49 -
>  utils/keytable/rc_keymaps/ati_x10.toml|   51 +
>  utils/keytable/rc_keymaps/avermedia   |   37 -
>  utils/keytable/rc_keymaps/avermedia.toml  |   39 +
>  utils/keytable/rc_keymaps/avermedia_a16d  |   35 -
>  utils/keytable/rc_keymaps/avermedia_a16d.toml |   37 +
>  utils/keytable/rc_keymaps/avermedia_cardbus   |   55 -
>  .../rc_keymaps/avermedia_cardbus.toml |   57 +
>  utils/keytable/rc_keymaps/avermedia_dvbt  |   35 -
>  utils/keytable/rc_keymaps/avermedia_dvbt.toml |   37 +
>  utils/keytable/rc_keymaps/avermedia_m135a |   81 -
>  .../keytable/rc_keymaps/avermedia_m135a.toml  |   85 +
>  .../keytable/rc_keymaps/avermedia_m733a_rm_k6 |   45 -
>  .../rc_keymaps/avermedia_m733a_rm_k6.toml |   49 +
>  utils/keytable/rc_keymaps/avermedia_rm_ks |   28 -
>  .../keytable/rc_keymaps/avermedia_rm_ks.toml  |   32 +
>  utils/keytable/rc_keymaps/avertv_303  |   37 -
>  utils/keytable/rc_keymaps/avertv_303.toml |   39 +
>  utils/keytable/rc_keymaps/az6027  |3 -
>  utils/keytable/rc_keymaps/az6027.toml |5 +
>  utils/keyta

[RFC PATCH v1 0/4] Add BPF decoders to ir-keytable

2018-06-02 Thread Sean Young
This is not ready for merging yet, however while I finish this work I would
like some feedback and ideas.

The idea is that IR decoders can be written in C, compiled to BPF relocatable
object file. Any global variables can overriden, so we can supports lots
of variants of similiar protocols (just like in the lircd.conf file).

The existing rc_keymap file format can't be used for variables, so I've
converted the format to toml. An alternative would be to use the existing
lircd.conf file format, but it's a very awkward file to parse in C and it
contains many features which are irrelevant to us.

We use libelf to load the bpf relocatable object file.

After loading our example grundig keymap with bpf decoder, the output of
ir-keytable is:

Found /sys/class/rc/rc0/ (/dev/input/event8) with:
Name: Winbond CIR
Driver: winbond-cir, table: rc-rc6-mce
lirc device: /dev/lirc0
Attached bpf protocols: grundig
Supported protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 
sharp xmp imon 
Enabled protocols: lirc
bus: 25, vendor/product: 10ad:00f1, version: 0x0004
Repeat delay = 500 ms, repeat period = 125 ms


Steps to complete this work:
 - Write more IR decoders
 - More rc_keymaps
 - More testing
 - lircd.conf to toml converter script (python/perl?)

Sean Young (4):
  keytable: add toml keymap reader
  keytable: convert keymaps to new toml format
  keytable: add support for BPF based decoders
  keytable: add bpf protocols

 Makefile.am   |4 +-
 configure.ac  |   16 +
 include/linux/bpf.h   | 2644 +
 utils/keytable/Makefile.am|   13 +-
 utils/keytable/bpf.c  |  515 
 utils/keytable/bpf.h  |  110 +
 utils/keytable/bpf_load.c |  457 +++
 utils/keytable/bpf_load.h |   41 +
 utils/keytable/bpf_protocols/Makefile.am  |   14 +
 utils/keytable/bpf_protocols/bpf_helpers.h|  302 ++
 utils/keytable/bpf_protocols/grundig.c|  113 +
 utils/keytable/gen_keytables.pl   |   33 +-
 utils/keytable/ir-keytable.1.in   |4 +-
 utils/keytable/keytable.c |  370 ++-
 utils/keytable/rc_keymaps/adstech_dvb_t_pci   |   45 -
 .../rc_keymaps/adstech_dvb_t_pci.toml |   47 +
 utils/keytable/rc_keymaps/af9005  |   37 -
 utils/keytable/rc_keymaps/af9005.toml |   39 +
 utils/keytable/rc_keymaps/alink_dtu_m |   19 -
 utils/keytable/rc_keymaps/alink_dtu_m.toml|   23 +
 .../keytable/rc_keymaps/allwinner_ba10_tv_box |   15 -
 .../rc_keymaps/allwinner_i12_a20_tv_box   |   28 -
 utils/keytable/rc_keymaps/anysee  |   45 -
 utils/keytable/rc_keymaps/anysee.toml |   49 +
 utils/keytable/rc_keymaps/apac_viewcomp   |   32 -
 utils/keytable/rc_keymaps/apac_viewcomp.toml  |   34 +
 utils/keytable/rc_keymaps/astrometa_t2hybrid  |   22 -
 .../rc_keymaps/astrometa_t2hybrid.toml|   26 +
 utils/keytable/rc_keymaps/asus_pc39   |   40 -
 utils/keytable/rc_keymaps/asus_pc39.toml  |   44 +
 utils/keytable/rc_keymaps/asus_ps3_100|   42 -
 utils/keytable/rc_keymaps/asus_ps3_100.toml   |   46 +
 .../keytable/rc_keymaps/ati_tv_wonder_hd_600  |   25 -
 .../rc_keymaps/ati_tv_wonder_hd_600.toml  |   27 +
 utils/keytable/rc_keymaps/ati_x10 |   49 -
 utils/keytable/rc_keymaps/ati_x10.toml|   51 +
 utils/keytable/rc_keymaps/avermedia   |   37 -
 utils/keytable/rc_keymaps/avermedia.toml  |   39 +
 utils/keytable/rc_keymaps/avermedia_a16d  |   35 -
 utils/keytable/rc_keymaps/avermedia_a16d.toml |   37 +
 utils/keytable/rc_keymaps/avermedia_cardbus   |   55 -
 .../rc_keymaps/avermedia_cardbus.toml |   57 +
 utils/keytable/rc_keymaps/avermedia_dvbt  |   35 -
 utils/keytable/rc_keymaps/avermedia_dvbt.toml |   37 +
 utils/keytable/rc_keymaps/avermedia_m135a |   81 -
 .../keytable/rc_keymaps/avermedia_m135a.toml  |   85 +
 .../keytable/rc_keymaps/avermedia_m733a_rm_k6 |   45 -
 .../rc_keymaps/avermedia_m733a_rm_k6.toml |   49 +
 utils/keytable/rc_keymaps/avermedia_rm_ks |   28 -
 .../keytable/rc_keymaps/avermedia_rm_ks.toml  |   32 +
 utils/keytable/rc_keymaps/avertv_303  |   37 -
 utils/keytable/rc_keymaps/avertv_303.toml |   39 +
 utils/keytable/rc_keymaps/az6027  |3 -
 utils/keytable/rc_keymaps/az6027.toml |5 +
 utils/keytable/rc_keymaps/azurewave_ad_tu700  |   54 -
 .../rc_keymaps/azurewave_ad_tu700.toml|   58 +
 utils/keytable/rc_keymaps/behold  |   35 -
 utils/keytable/rc_keymaps/behold.toml |   39 +
 utils/keytable/rc_keymaps/behold_columbus |   29 -
 .../keytable/rc_keymaps/behold_columbus.toml  |   31 +
 utils/keytable/rc_keymaps/budget_ci_old   |   46 -
 utils/keytable/rc_keymaps/budget_ci_old.toml  

[RFC PATCH v1 3/4] keytable: add support for BPF based decoders

2018-06-02 Thread Sean Young
We use a modified version of samples/bpf/bpf_load.c from linux kernel
tree to load elf based BPF decoders, clear them on '-c' and show the
program ids when no commands are given.

Any global int variables can be overrided from toml. They are patched to
be immediate loads.

Signed-off-by: Sean Young 
---
 Makefile.am|4 +-
 configure.ac   |   11 +
 include/linux/bpf.h| 2644 
 utils/keytable/Makefile.am |7 +-
 utils/keytable/bpf.c   |  515 +++
 utils/keytable/bpf.h   |  110 ++
 utils/keytable/bpf_load.c  |  457 +++
 utils/keytable/bpf_load.h  |   41 +
 utils/keytable/keytable.c  |  208 ++-
 v4l-utils.spec.in  |2 +-
 10 files changed, 3989 insertions(+), 10 deletions(-)
 create mode 100644 include/linux/bpf.h
 create mode 100644 utils/keytable/bpf.c
 create mode 100644 utils/keytable/bpf.h
 create mode 100644 utils/keytable/bpf_load.c
 create mode 100644 utils/keytable/bpf_load.h

diff --git a/Makefile.am b/Makefile.am
index fc8f2f34..38e17bab 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -25,7 +25,8 @@ sync-with-kernel:
  ! -f $(KERNEL_DIR)/usr/include/linux/ivtv.h -o \
  ! -f $(KERNEL_DIR)/usr/include/linux/dvb/frontend.h -o \
  ! -f $(KERNEL_DIR)/usr/include/linux/dvb/dmx.h -o \
- ! -f $(KERNEL_DIR)/usr/include/linux/lirc.h ]; then \
+ ! -f $(KERNEL_DIR)/usr/include/linux/lirc.h -o \
+ ! -f $(KERNEL_DIR)/usr/include/linux/bpf.h ]; then \
  echo "Error you must set KERNEL_DIR to point to an extracted kernel 
source dir"; \
  echo "and run 'make headers_install' in \$$KERNEL_DIR."; \
  exit 1; \
@@ -43,6 +44,7 @@ sync-with-kernel:
cp $(top_srcdir)/include/linux/dvb/frontend.h 
$(top_srcdir)/lib/include/libdvbv5/dvb-frontend.h
cp -a $(KERNEL_DIR)/usr/include/linux/dvb/dmx.h 
$(top_srcdir)/include/linux/dvb
cp -a $(KERNEL_DIR)/usr/include/linux/lirc.h $(top_srcdir)/include/linux
+   cp -a $(KERNEL_DIR)/usr/include/linux/bpf.h $(top_srcdir)/include/linux
cp -a $(KERNEL_DIR)/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
$(top_srcdir)/utils/common
cp -a $(KERNEL_DIR)/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c 
$(top_srcdir)/utils/common
cp -a $(KERNEL_DIR)/include/media/tpg/v4l2-tpg* 
$(top_srcdir)/utils/common
diff --git a/configure.ac b/configure.ac
index dc1e9cbf..1f48913c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -167,6 +167,16 @@ AC_SUBST([X11_CFLAGS])
 AC_SUBST([X11_LIBS])
 AM_CONDITIONAL([HAVE_X11], [test x$x11_pkgconfig = xyes])
 
+PKG_CHECK_MODULES([LIBELF], [libelf], [libelf_pkgconfig=yes], 
[libelf_pkgconfig=no])
+AC_SUBST([LIBELF_CFLAGS])
+AC_SUBST([LIBELF_LIBS])
+AM_CONDITIONAL([HAVE_LIBELF], [test x$libelf_pkgconfig = xyes])
+if test "x$libelf_pkgconfig" = "xyes"; then
+   AC_DEFINE([HAVE_LIBELF], [1], [libelf library is present])
+else
+   AC_MSG_WARN(libelf library not available)
+fi
+
 AS_IF([test "x$x11_pkgconfig" = xyes],
   [PKG_CHECK_MODULES(GL, [gl], [gl_pkgconfig=yes], [gl_pkgconfig=no])], 
[gl_pkgconfig=no])
 AC_SUBST([GL_CFLAGS])
@@ -497,6 +507,7 @@ compile time options summary
 X11: $x11_pkgconfig
 GL : $gl_pkgconfig
 glu: $glu_pkgconfig
+libelf: $libelf_pkgconfig
 libjpeg: $have_jpeg
 libudev: $have_libudev
 pthread: $have_pthread
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
new file mode 100644
index ..64ac0f7a
--- /dev/null
+++ b/include/linux/bpf.h
@@ -0,0 +1,2644 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/* Copyright (c) 2011-2014 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#ifndef _UAPI__LINUX_BPF_H__
+#define _UAPI__LINUX_BPF_H__
+
+#include 
+#include 
+
+/* Extended instruction set based on top of classic BPF */
+
+/* instruction classes */
+#define BPF_ALU64  0x07/* alu mode in double word width */
+
+/* ld/ldx fields */
+#define BPF_DW 0x18/* double word (64-bit) */
+#define BPF_XADD   0xc0/* exclusive add */
+
+/* alu/jmp fields */
+#define BPF_MOV0xb0/* mov reg to reg */
+#define BPF_ARSH   0xc0/* sign extending arithmetic shift right */
+
+/* change endianness of a register */
+#define BPF_END0xd0/* flags for endianness conversion: */
+#define BPF_TO_LE  0x00/* convert to little-endian */
+#define BPF_TO_BE  0x08/* convert to big-endian */
+#define BPF_FROM_LEBPF_TO_LE
+#define BPF_FROM_BEBPF_TO_BE
+
+/* jmp encodings */
+#define BPF_JNE0x50/* jump != */
+#define BPF_JLT   

[RFC PATCH v1 4/4] keytable: add bpf protocols

2018-06-02 Thread Sean Young
Add grundig decoder and infrastructure for build bpf protocols.

Signed-off-by: Sean Young 
---
 configure.ac|   5 +
 utils/keytable/Makefile.am  |   4 +
 utils/keytable/bpf_protocols/Makefile.am|  14 +
 utils/keytable/bpf_protocols/bpf_helpers.h  | 302 
 utils/keytable/bpf_protocols/grundig.c  | 113 
 utils/keytable/rc_keymaps_bpf/RP75_LCD.toml |  45 +++
 v4l-utils.spec.in   |   2 +-
 7 files changed, 484 insertions(+), 1 deletion(-)
 create mode 100644 utils/keytable/bpf_protocols/Makefile.am
 create mode 100644 utils/keytable/bpf_protocols/bpf_helpers.h
 create mode 100644 utils/keytable/bpf_protocols/grundig.c
 create mode 100644 utils/keytable/rc_keymaps_bpf/RP75_LCD.toml

diff --git a/configure.ac b/configure.ac
index 1f48913c..8872a483 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,6 +23,7 @@ AC_CONFIG_FILES([Makefile
utils/libmedia_dev/Makefile
utils/dvb/Makefile
utils/keytable/Makefile
+   utils/keytable/bpf_protocols/Makefile
utils/ir-ctl/Makefile
utils/cx18-ctl/Makefile
utils/ivtv-ctl/Makefile
@@ -172,11 +173,15 @@ AC_SUBST([LIBELF_CFLAGS])
 AC_SUBST([LIBELF_LIBS])
 AM_CONDITIONAL([HAVE_LIBELF], [test x$libelf_pkgconfig = xyes])
 if test "x$libelf_pkgconfig" = "xyes"; then
+   AC_CHECK_PROG([CLANG], clang, clang)
+   AC_CHECK_PROG([LLC], llc, llc)
AC_DEFINE([HAVE_LIBELF], [1], [libelf library is present])
 else
AC_MSG_WARN(libelf library not available)
 fi
 
+AM_CONDITIONAL([BPF_PROTOCOLS], [test x$CLANG = xclang -a x$LLC = xllc])
+
 AS_IF([test "x$x11_pkgconfig" = xyes],
   [PKG_CHECK_MODULES(GL, [gl], [gl_pkgconfig=yes], [gl_pkgconfig=no])], 
[gl_pkgconfig=no])
 AC_SUBST([GL_CFLAGS])
diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
index df2b2231..90e4c8c8 100644
--- a/utils/keytable/Makefile.am
+++ b/utils/keytable/Makefile.am
@@ -13,6 +13,10 @@ endif
 ir_keytable_LDADD = @LIBINTL@
 ir_keytable_LDFLAGS = $(ARGP_LIBS) $(LIBELF_LIBS)
 
+if BPF_PROTOCOLS
+SUBDIRS = bpf_protocols
+endif
+
 EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace 
gen_keytables.pl ir-keytable.1 rc_maps.cfg
 
 # custom target
diff --git a/utils/keytable/bpf_protocols/Makefile.am 
b/utils/keytable/bpf_protocols/Makefile.am
new file mode 100644
index ..aa748900
--- /dev/null
+++ b/utils/keytable/bpf_protocols/Makefile.am
@@ -0,0 +1,14 @@
+
+NOSTDINC=-nostdinc -isystem $(shell $(CLANG) -print-file-name=include)
+
+%.o: %.c
+   $(CLANG) -I../../../include $(NOSTDINC) -I/usr/include -target bpf -O2 
-emit-llvm -c $< -o - | $(LLC) -march=bpf -filetype=obj -o $@
+
+PROTOCOLS = grundig.o
+
+all: $(PROTOCOLS)
+
+# custom target
+install-data-local:
+   $(install_sh) -d "$(DESTDIR)$(keytableuserdir)/protocols"
+   $(install_sh) $(PROTOCOLS) "$(DESTDIR)$(keytableuserdir)/protocols"
diff --git a/utils/keytable/bpf_protocols/bpf_helpers.h 
b/utils/keytable/bpf_protocols/bpf_helpers.h
new file mode 100644
index ..a6864827
--- /dev/null
+++ b/utils/keytable/bpf_protocols/bpf_helpers.h
@@ -0,0 +1,302 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __BPF_HELPERS_H
+#define __BPF_HELPERS_H
+
+/* helper macro to place programs, maps, license in
+ * different sections in elf_bpf file. Section names
+ * are interpreted by elf_bpf loader
+ */
+#define SEC(NAME) __attribute__((section(NAME), used))
+
+/* helper functions called from eBPF programs written in C */
+static void *(*bpf_map_lookup_elem)(void *map, void *key) =
+   (void *) BPF_FUNC_map_lookup_elem;
+static int (*bpf_map_update_elem)(void *map, void *key, void *value,
+ unsigned long long flags) =
+   (void *) BPF_FUNC_map_update_elem;
+static int (*bpf_map_delete_elem)(void *map, void *key) =
+   (void *) BPF_FUNC_map_delete_elem;
+static int (*bpf_probe_read)(void *dst, int size, void *unsafe_ptr) =
+   (void *) BPF_FUNC_probe_read;
+static unsigned long long (*bpf_ktime_get_ns)(void) =
+   (void *) BPF_FUNC_ktime_get_ns;
+static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) =
+   (void *) BPF_FUNC_trace_printk;
+static void (*bpf_tail_call)(void *ctx, void *map, int index) =
+   (void *) BPF_FUNC_tail_call;
+static unsigned long long (*bpf_get_smp_processor_id)(void) =
+   (void *) BPF_FUNC_get_smp_processor_id;
+static unsigned long long (*bpf_get_current_pid_tgid)(void) =
+   (void *) BPF_FUNC_get_current_pid_tgid;
+static unsigned long long (*bpf_get_current_uid_gid)(void) =
+   (void *) BPF_FUNC_get_current_uid_gid;
+static int (*bpf_get_current_comm)(void *buf, int buf_size) =
+   (void *) BPF_FUNC_get_current_comm;
+static unsigned long long (*bpf_perf_event_read)(void *map,
+unsigned long long flags) =
+   (void *) BPF_FUNC_perf_event_read;
+static int (*bpf_clone_redirect)(void *ctx, int ifindex,

[RFC PATCH v1 1/4] keytable: add toml keymap reader

2018-06-02 Thread Sean Young
We would like to add BPF based IR decoding in a later commit. BPF
based IR decoding will have per-protocol parameters, so we need a more
flexible format.

At some point in the future it would nice to change rc-core keycode
mapping to protocol + 64 bit scancode -> keycode, rather the existing
32 bit scancode -> keycode. In order to make this possible, we want
the scancodes to be specified for their protocol, in case multiple
protocols are selected.

Signed-off-by: Sean Young 
---
 utils/keytable/Makefile.am |2 +-
 utils/keytable/keytable.c  |  174 +++-
 utils/keytable/toml.c  | 1903 
 utils/keytable/toml.h  |  110 +++
 4 files changed, 2185 insertions(+), 4 deletions(-)
 create mode 100644 utils/keytable/toml.c
 create mode 100644 utils/keytable/toml.h

diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
index 904aa96b..0bd7045f 100644
--- a/utils/keytable/Makefile.am
+++ b/utils/keytable/Makefile.am
@@ -4,7 +4,7 @@ sysconf_DATA = rc_maps.cfg
 keytablesystem_DATA = $(srcdir)/rc_keymaps/*
 udevrules_DATA = 70-infrared.rules
 
-ir_keytable_SOURCES = keytable.c parse.h ir-encode.c ir-encode.h
+ir_keytable_SOURCES = keytable.c parse.h ir-encode.c ir-encode.h toml.c toml.h
 ir_keytable_LDADD = @LIBINTL@
 ir_keytable_LDFLAGS = $(ARGP_LIBS)
 
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 482fcf86..c6304b04 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -33,6 +33,7 @@
 
 #include "ir-encode.h"
 #include "parse.h"
+#include "toml.h"
 
 #ifdef ENABLE_NLS
 # define _(string) gettext(string)
@@ -200,7 +201,7 @@ static void write_sysfs_protocols(enum sysfs_protocols 
protocols, FILE *fp, cons
}
 }
 
-static int parse_code(char *string)
+static int parse_code(const char *string)
 {
struct parse_event *p;
 
@@ -291,7 +292,7 @@ struct rc_device {
enum sysfs_protocols supported, current; /* Current and supported IR 
protocols */
 };
 
-static error_t parse_keyfile(char *fname, char **table)
+static error_t parse_plain_keyfile(char *fname, char **table)
 {
FILE *fin;
int value, line = 0;
@@ -301,7 +302,7 @@ static error_t parse_keyfile(char *fname, char **table)
*table = NULL;
 
if (debug)
-   fprintf(stderr, _("Parsing %s keycode file\n"), fname);
+   fprintf(stderr, _("Parsing %s keycode file as plain text\n"), 
fname);
 
fin = fopen(fname, "r");
if (!fin) {
@@ -397,7 +398,174 @@ err_einval:
fprintf(stderr, _("Invalid parameter on line %d of %s\n"),
line, fname);
return EINVAL;
+}
+
+static error_t parse_toml_protocol(struct toml_table_t *root, const char *p)
+{
+   struct toml_table_t *proot, *scancodes;
+   enum sysfs_protocols protocol;
+   const char *raw;
+   int i = 0;
+
+   protocol = parse_sysfs_protocol(p, false);
+   if (protocol == SYSFS_INVALID) {
+   fprintf(stderr, _("Protocol `%s' not known\n"), p);
+   return EINVAL;
+   }
+
+   ch_proto |= protocol;
+
+   proot = toml_table_in(root, p);
+   if (!proot) {
+   if (debug)
+   fprintf(stderr, _("No [%s] section"), p);
+   return 0;
+   }
+
+   scancodes = toml_table_in(proot, "scancodes");
+   if (!proot) {
+   if (debug)
+   fprintf(stderr, _("No [%s.scancodes] section"), p);
+   return 0;
+   }
+
+   for (;;) {
+   struct keytable_entry *ke;
+   const char *scancode;
+   char *keycode;
+   int value;
+
+   scancode = toml_key_in(scancodes, i++);
+   if (!scancode)
+   break;
+
+   raw = toml_raw_in(scancodes, scancode);
+   if (!raw) {
+   fprintf(stderr, _("Invalid value `%s'\n"), scancode);
+   return EINVAL;
+   }
+
+   if (toml_rtos(raw, &keycode)) {
+   fprintf(stderr, _("Bad value `%s' for keycode\n"),
+   keycode);
+   return EINVAL;
+   }
+
+   if (debug)
+   fprintf(stderr, _("parsing %s=%s:"), scancode, keycode);
+
+   value = parse_code(keycode);
+   if (debug)
+   fprintf(stderr, _("\tvalue=%d\n"), value);
+
+   if (value == -1) {
+   value = strtol(keycode, NULL, 0);
+   if (errno)
+   perror(_("value"));
+   }
+   free(keycode);
+
+   ke = calloc(1, sizeof(*ke));
+   if (!ke) {
+   perror("parse_keyfile");
+   return ENOMEM;
+   }
+
+   ke->scancode= strtoul(scancode, NULL, 0);
+   ke->keycode =