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:   Wed Feb 22 05:00:25 CET 2017
media-tree git hash:9eeb0ed0f30938f31a3d9135a88b9502192c18dd
media_build git hash:   785cdf7f0798964681b33aad44fc2ff4d734733d
v4l-utils git hash: 1edd6920bed585d0ea70a2d400182ba17ee2e7fc
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10-rc3-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: OK
linux-4.9-x86_64: OK
linux-4.10-rc3-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH v2 17/19] [media] lirc: implement reading scancode

[kbuild test robot]

Hi Sean,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on next-20170221]
[cannot apply to v4.10]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sean-Young/Teach-lirc-how-to-send-and-receive-scancodes/20170222-073718
base:   git://linuxtv.org/media_tree.git master
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
   include/linux/init.h:1: warning: no structured comments found
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/drm/drm_drv.h:409: warning: No description found for parameter 'load'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'firstopen'
   include/drm/drm_drv.h:409: warning: No description found for parameter 'open'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'preclose'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'postclose'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'lastclose'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'unload'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'dma_ioctl'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'dma_quiescent'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'context_dtor'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'debugfs_cleanup'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'vgaarb_irq'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:409: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:409: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:409: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'dev_priv_size'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:409: warning: No description found for parameter 'fops'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'legacy_dev_list'
   drivers/media/dvb-core/dvb_frontend.h:677: warning: No description found for 
parameter 'refcount'
>> i

Re: [PATCH v5 1/3] [media] exynos-gsc: Use user configured colorspace if provided

[Hans Verkuil]

On 02/21/2017 11:20 AM, Thibault Saunier wrote:
> Use colorspace provided by the user as we are only doing scaling and
> color encoding conversion, we won't be able to transform the colorspace
> itself and the colorspace won't mater in that operation.
> 
> Also always use output colorspace on the capture side.
> 
> Start using 576p as a threashold to compute the colorspace.
> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
> don't agree on the display resolution that should be used as a threshold.
> 
> From EIA CEA 861B about colorimetry for various resolutions:
> 
>   - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
> The color space used by the 480-line, 576-line, 240-line, and 288-line
> formats will likely be based on SMPTE 170M [1].
>   - 5.2 1080i, 1080p, and 720p
> The color space used by the high definition formats will likely be
> based on ITU-R BT.709-4
> 
> This indicates that in the case that userspace does not specify what
> colorspace should be used, we should use 576p  as a threshold to set
> V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_SMPTE170M. Even if it is
> only 'likely' and not a requirement it is the best guess we can make.
> 
> The stream should have been encoded with the information and userspace
> has to pass it to the driver if it is not the case, otherwise we won't be
> able to handle it properly anyhow.
> 
> Also, check for the resolution in G_FMT instead unconditionally setting
> the V4L2_COLORSPACE_REC709 colorspace.
> 
> Signed-off-by: Javier Martinez Canillas 
> Signed-off-by: Thibault Saunier 
> Reviewed-by: Andrzej Hajda 
> 
> ---
> 
> Changes in v5:
> - Squash commit to always use output colorspace on the capture side
>   inside this one
> - Fix typo in commit message
> 
> Changes in v4:
> - Reword commit message to better back our assumptions on specifications
> 
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous 
> review
> - Added 'Reviewed-by: Andrzej Hajda '
> 
> Changes in v2: None
> 
>  drivers/media/platform/exynos-gsc/gsc-core.c | 20 +++-
>  drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
>  2 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 59a634201830..772599de8c13 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   } else {
>   min_w = variant->pix_min->target_rot_dis_w;
>   min_h = variant->pix_min->target_rot_dis_h;
> + pix_mp->colorspace = ctx->out_colorspace;
>   }
>  
>   pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d",
> @@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>  
>   pix_mp->num_planes = fmt->num_planes;
>  
> - if (pix_mp->width >= 1280) /* HD */
> - pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> - else /* SD */
> - pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> + if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */

I'd use || instead of && here. Ditto for the next patch.

> + pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> + else /* SD */
> + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> + }

Are you sure this is in fact how it is used? If the source of the video
is the sensor (camera), then the colorspace is typically SRGB. I'm not
really sure you should guess here. All a mem2mem driver should do is to
pass the colorspace etc. information from the output to the capture side,
and not invent things. That simply makes no sense.

We may have to update the documentation or v4l2-compliance test if this
is an issue. The more I think about this, the more I think we shouldn't
do this guessing game.

Regards,

Hans

> +
> + if (V4L2_TYPE_IS_OUTPUT(f->type))
> + ctx->out_colorspace = pix_mp->colorspace;
>  
>   for (i = 0; i < pix_mp->num_planes; ++i) {
>   struct v4l2_plane_pix_format *plane_fmt = _mp->plane_fmt[i];
> @@ -519,9 +525,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   pix_mp->height  = frame->f_height;
>   pix_mp->field   = V4L2_FIELD_NONE;
>   pix_mp->pixelformat = frame->fmt->pixelformat;
> - pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
>   pix_mp->num_planes  = frame->fmt->num_planes;
>  
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> + pix_mp->colorspace = 

Re: [PATCH v2 17/19] [media] lirc: implement reading scancode

[kbuild test robot]

Hi Sean,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on next-20170221]
[cannot apply to v4.10]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sean-Young/Teach-lirc-how-to-send-and-receive-scancodes/20170222-073718
base:   git://linuxtv.org/media_tree.git master
config: i386-randconfig-x015-201708 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

Note: the 
linux-review/Sean-Young/Teach-lirc-how-to-send-and-receive-scancodes/20170222-073718
 HEAD 9a4d3444d507190ad7996731c8c7e4ef80979de4 builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   drivers/media/rc/ir-lirc-codec.c: In function 'ir_lirc_poll':
>> drivers/media/rc/ir-lirc-codec.c:393:7: error: 'drv' undeclared (first use 
>> in this function)
 if (!drv->attached) {
  ^~~
   drivers/media/rc/ir-lirc-codec.c:393:7: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/media/rc/ir-lirc-codec.c:395:13: error: 'dev' undeclared (first use 
>> in this function)
 } else if (dev->rec_mode == LIRC_MODE_SCANCODE) {
^~~
   In file included from include/media/lirc_dev.h:23:0,
from drivers/media/rc/ir-lirc-codec.c:18:
>> include/linux/kfifo.h:259:8: error: invalid type argument of '->' (have 
>> 'int')
 __tmpq->kfifo.in == __tmpq->kfifo.out; \
   ^
>> drivers/media/rc/ir-lirc-codec.c:396:8: note: in expansion of macro 
>> 'kfifo_is_empty'
  if (!kfifo_is_empty(>kfifo))
   ^~
   include/linux/kfifo.h:259:28: error: invalid type argument of '->' (have 
'int')
 __tmpq->kfifo.in == __tmpq->kfifo.out; \
   ^
>> drivers/media/rc/ir-lirc-codec.c:396:8: note: in expansion of macro 
>> 'kfifo_is_empty'
  if (!kfifo_is_empty(>kfifo))
   ^~
>> include/linux/kfifo.h:259:8: error: invalid type argument of '->' (have 
>> 'int')
 __tmpq->kfifo.in == __tmpq->kfifo.out; \
   ^
   drivers/media/rc/ir-lirc-codec.c:399:8: note: in expansion of macro 
'kfifo_is_empty'
  if (!kfifo_is_empty(>raw->lirc.kfifo))
   ^~
   include/linux/kfifo.h:259:28: error: invalid type argument of '->' (have 
'int')
 __tmpq->kfifo.in == __tmpq->kfifo.out; \
   ^
   drivers/media/rc/ir-lirc-codec.c:399:8: note: in expansion of macro 
'kfifo_is_empty'
  if (!kfifo_is_empty(>raw->lirc.kfifo))
   ^~

vim +/drv +393 drivers/media/rc/ir-lirc-codec.c

   387  {
   388  struct lirc_codec *lirc = lirc_get_pdata(filep);
   389  unsigned int events = 0;
   390  
   391  poll_wait(filep, >wait_poll, wait);
   392  
 > 393  if (!drv->attached) {
   394  events = POLLERR;
 > 395  } else if (dev->rec_mode == LIRC_MODE_SCANCODE) {
 > 396  if (!kfifo_is_empty(>kfifo))
   397  events = POLLIN | POLLRDNORM;
   398  } else if (dev->rec_mode == LIRC_MODE_MODE2) {
   399  if (!kfifo_is_empty(>raw->lirc.kfifo))

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v6 2/9] doc: DT: venus: binding document for Qualcomm video driver

[Rob Herring]

On Tue, Feb 07, 2017 at 03:10:17PM +0200, Stanimir Varbanov wrote:
> Add binding document for Venus video encoder/decoder driver
> 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Stanimir Varbanov 
> ---
> Changes since previous v5:
>  * dropped rproc phandle (remoteproc is not used anymore)
>  * added subnodes paragraph with descrition of three subnodes:
> - video-decoder and video-encoder - describes decoder (core0) and
> encoder (core1) power-domains and clocks (applicable for msm8996
> Venus core).
> - video-firmware - needed to get reserved memory region where the
> firmware is stored.
> 
>  .../devicetree/bindings/media/qcom,venus.txt   | 112 
> +
>  1 file changed, 112 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt 
> b/Documentation/devicetree/bindings/media/qcom,venus.txt
> new file mode 100644
> index ..4427af3ca5a5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
> @@ -0,0 +1,112 @@

[...]

> +* Subnodes
> +The Venus node must contain three subnodes representing video-decoder,
> +video-encoder and video-firmware.

[...]

> +The video-firmware subnode should contain:
> +
> +- memory-region:
> + Usage: required
> + Value type: 
> + Definition: reference to the reserved-memory for the memory region
> +
> +* An Example
> + video-codec@1d0 {
> + compatible = "qcom,msm8916-venus";
> + reg = <0x01d0 0xff000>;
> + interrupts = ;
> + clocks = < GCC_VENUS0_VCODEC0_CLK>,
> +  < GCC_VENUS0_AHB_CLK>,
> +  < GCC_VENUS0_AXI_CLK>;
> + clock-names = "core", "iface", "bus";
> + power-domains = < VENUS_GDSC>;
> + iommus = <_iommu 5>;
> +
> + video-decoder {
> + compatible = "venus-decoder";
> + clocks = < VIDEO_SUBCORE0_CLK>;
> + clock-names = "core";
> + power-domains = < VENUS_CORE0_GDSC>;
> + };
> +
> + video-encoder {
> + compatible = "venus-encoder";
> + clocks = < VIDEO_SUBCORE1_CLK>;
> + clock-names = "core";
> + power-domains = < VENUS_CORE1_GDSC>;
> + };
> +
> + video-firmware {
> + memory-region = <_mem>;

Why does this need to be a sub node?

Rob

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Steve Longerbeam]

On 02/21/2017 02:21 PM, Steve Longerbeam wrote:



On 02/21/2017 04:15 AM, Sakari Ailus wrote:

Hi Steve,

On Mon, Feb 20, 2017 at 02:56:15PM -0800, Steve Longerbeam wrote:



On 02/20/2017 02:04 PM, Sakari Ailus wrote:

Hi Steve,

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

From: Russell King 

Setting and getting frame rates is part of the negotiation mechanism
between subdevs.  The lack of support means that a frame rate at the
sensor can't be negotiated through the subdev path.


Just wondering --- what do you need this for?



Hi Sakari,

i.MX does need the ability to negotiate the frame rates in the
pipelines. The CSI has the ability to skip frames at the output,
which is something Philipp added to the CSI subdev. That affects
frame interval at the CSI output.

But as Russell pointed out, the lack of [gs]_frame_interval op
causes media-ctl to fail:

media-ctl -v -d /dev/media1 --set-v4l2
'"imx6-mipi-csi2":1[fmt:SGBRG8/512x512@1/30]'

Opening media device /dev/media1
Enumerating entities
Found 29 entities
Enumerating pads and links
Setting up format SGBRG8 512x512 on pad imx6-mipi-csi2/1
Format set: SGBRG8 512x512
Setting up frame interval 1/30 on entity imx6-mipi-csi2
Unable to set frame interval: Inappropriate ioctl for device
(-25)Unable to
setup formats: Inappropriate ioctl for device (25)


So i.MX needs to implement this op in every subdev in the
pipeline, otherwise it's not possible to configure the
pipeline with media-ctl.


The frame rate is only set on the sub-device which you explicitly set it.
I.e. setting the frame rate fails if it's not supported on a pad.

Philipp recently posted patches that add frame rate propagation to
media-ctl.

Frame rate is typically settable (and gettable) only on sensor
sub-device's
source pad,  which means it normally would not be propagated by the
kernel
but with Philipp's patches, on the sink pad of the bus receiver.
Receivers
don't have a way to control it nor they implement the IOCTLs, so that
would
indeed result in an error.



Frame rate is really an essential piece of information. The spatial
dimensions and data type provided by set_fmt are really only half the
equation, the other is temporal, i.e. the data rate.

It's true that subdevices have no control over the frame rate at their
sink pads, but the same argument applies to set_fmt. Even if it has
no control over the data format it receives, it still needs that
information in order to determine the correct format at the source.
The same argument applies to frame rate.

So in my opinion, the behavior of [gs]_frame_interval should be, if a
subdevice is capable of modifying the frame rate, then it should
implement [gs]_frame_interval at _all_ of its pads, similar to set_fmt.
And frame rate should really be part of link validation the same as
set_fmt is.



Actually, if frame rate were added to link validation then
[gs]_frame_interval would have to be mandatory, even if the
subdev has no control over frame rate, again this is like
set_fmt. Otherwise, if a subdev has not implemented
[gs]_frame_interval, then frame rate validation across
the whole pipeline is broken. Because, if we have

A -> B -> C

and B has not implemented [gs]_frame_interval, and C is expecting
30 fps, then pipeline validation would succeed even though A is 
outputting 60 fps.


Steve

Re: Bug: decoders referenced in kernel rc-keymaps not loaded on boot

[Matthias Reichl]

On Tue, Feb 21, 2017 at 07:34:39PM +, Sean Young wrote:
> On Tue, Feb 21, 2017 at 07:49:29PM +0100, Matthias Reichl wrote:
> > There seems to be a bug in on-demand loading of IR protocol decoders.
> > 
> > After bootup the protocol referenced in the in-kernel rc keymap shows
> > up as enabled (in sysfs and ir-keytable) but the protocol decoder
> > is not loaded and thus no rc input events will be generated.
> > 
> > For example, RPi3 with kernel 4.10 and gpio-ir-recv configured to use
> > the rc-hauppauge keymap in devicetree:
> > 
> > # lsmod | grep '^\(ir\|rc_\)'
> > ir_lirc_codec   5590  0
> > rc_hauppauge2422  0
> > rc_core24320  5 
> > rc_hauppauge,ir_lirc_codec,lirc_dev,gpio_ir_recv
> > 
> > # cat /sys/class/rc/rc0/protocols
> > other unknown [rc-5] nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp cec 
> > [lirc]
> > 
> > # dmesg | grep "IR "
> > [4.506728] Registered IR keymap rc-hauppauge
> > [4.554651] lirc_dev: IR Remote Control driver registered, major 242
> > [4.576490] IR LIRC bridge handler initialized
> > 
> > The same happens with other IR receivers, eg the streamzap receiver,
> > which uses the rc-5-sz protocol / ir_rc5_decoder, on x86.
> > 
> > Reverting the on-demand-loading patches
> > 
> > [media] media: rc: remove unneeded code
> > commit c1500ba0b61e9abf95e0e7ecd3c4ad877f019abe
> > 
> > [media] media: rc: move check whether a protocol is enabled to the core
> > commit d80ca8bd71f0b01b2b12459189927cb3299cfab9
> > 
> > [media] media: rc: load decoder modules on-demand
> > commit acc1c3c688ed8cc862ddc007eab0dcef839f4ec8
> > 
> > restores the previous behaviour, all decoders are enabled and IR
> > events can be generated immediately after boot without having to
> > manually trigger loading of a protocol decoder.
> 
> Hmm this seems to be working fine for me. If you write to the protocols
> file, eg. "echo +nec > /sys/class/rc/rc0/protocols", is ir-nec-decoder
> loaded and do you get any messages in dmesg (you should).
> 
> What's your config?

When I do an "echo +nec > /sys/class/rc/rc0/protocols" it triggers
the load of both rc5 and nec decoder modules:

root@rpi3:~# cat /sys/class/rc/rc0/protocols
other unknown [rc-5] nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp cec 
[lirc]
root@rpi3:~# echo +nec > /sys/class/rc/rc0/protocols
root@rpi3:~# cat /sys/class/rc/rc0/protocols
other unknown [rc-5] [nec] rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp cec 
[lirc]
root@rpi3:~# dmesg | grep "IR "
[3.565061] Registered IR keymap rc-hauppauge
[3.613031] lirc_dev: IR Remote Control driver registered, major 242
[3.641423] IR LIRC bridge handler initialized
[   41.877263] IR RC5(x/sz) protocol handler initialized
[   41.931575] IR NEC protocol handler initialized

I'm currently testing with downstream RPi kernel 4.9 on Raspbian Jessie
(a Debian derivate).

Kernel config is here:
https://github.com/raspberrypi/linux/blob/rpi-4.9.y/arch/arm/configs/bcm2709_defconfig

To reproduce the issue it's important to disable the udev rule that
runs ir-keytable -a as that can trigger a load of the kernel keytable
via the userspace keymap/protocol.

We ran accross the issue via a bugreport from a LibreELEC user,
his streamzap remote wasn't working anymore on x86 in the beta
releases:
https://forum.libreelec.tv/thread-4873.html

Kernel-config for LibreELEC x86 is here:
https://github.com/LibreELEC/LibreELEC.tv/blob/libreelec-8.0/projects/Generic/linux/linux.x86_64.conf

Our analysis (I hope it's not completely off) is about this:

In the previous version (with kernel 4.4) it worked because
the kernel loaded the keymap and protocol decoders. The udev
rule probably failed as ir-keytable -a couldn't cope with the RC5_SZ
protocol - but that went unnoticed as everything was setup fine
by the kernel.

In current beta (with kernel 4.9) the kernel only loaded the
keymap but didn't enable the decoder. Since ir-keytable -a again
failed to setup the protocol the user was left with a non-functioning
remote.

I then could reproduce this on RPi with Raspbian and LibreELEC
using gpio-ir-recv. With udev/ir-keytable -a working the protocol
decoder is loaded, without that it isn't.

so long,

Hias

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Vladimir Zapolskiy]

Hi Sakari,

On 02/21/2017 11:48 PM, Sakari Ailus wrote:
> Hi, Vladimir!
> 
> How do you do? :-)

deferring execution of boring tasks by doing code review :)

> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
>>> Hi Vladimir,
>>>
>>> Thank you for your feedback
>>>
>>> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
 Hi Ramiro,

 On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> Create device tree bindings documentation.
>
> Signed-off-by: Ramiro Oliveira 
> Acked-by: Rob Herring 
> ---
>  .../devicetree/bindings/media/i2c/ov5647.txt   | 35 
> ++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt 
> b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> new file mode 100644
> index ..31956426d3b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> @@ -0,0 +1,35 @@
> +Omnivision OV5647 raw image sensor
> +-
> +
> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data 
> interfaces
> +and CCI (I2C compatible) control bus.
> +
> +Required properties:
> +
> +- compatible : "ovti,ov5647".
> +- reg: I2C slave address of the sensor.
> +- clocks : Reference to the xclk clock.

 Is "xclk" clock a pixel clock or something else?

>>>
>>> It's an external oscillator.
>>
>> hmm, I suppose a clock of any type could serve as a clock for the sensor.
>> It can be an external oscillator on a particular board, or it can be
>> something else on another board.
> 
> Any clock source could be used I presume.
> 

That's exactly my point, and it is a reason to rename "xclk" to something
more generic.

>>
>> Can you please describe what for does ov5647 sensor need this clock, what
>> is its function?
> 
> Camera modules (sensors) quite commonly require an external clock as they do
> not have an oscillator on their own. A lot of devices under
> Documentation/devicetree/bindings/media/i2c/ have similar properties.
> 

So, what should be a better replacement of "xclk" in the description above?

E.g.

- clocks: Phandle to a device supply clock.

>>
>>>
> +- clock-names: Should be "xclk".

We got an agreement that "clock-names" property is removed, nevertheless
if it is added back, is should not be "xclk".


 You can remove this property, because there is only one source clock.

>>>
>>> Ok.
>>>
> +- clock-frequency: Frequency of the xclk clock.

 And after the last updates in the driver this property can be removed as 
 well.

>>>
>>> But I'm still using clk_get_rate in the driver, if I remove the frequency 
>>> here
>>> the probing will fail.
>>>
>>
>> I doubt it, there should be no connection between a custom "clock-frequency"
>> device tree property in a clock consumer device node and clk_get_rate() 
>> function
>> from the CCF, which takes a clock provider as its argument.
> 
> The purpose is to make sure the clock frequency is really usable for the
> device, in this particular case the driver can work with one particular
> frequency.
> 
> That said, the driver does not appear to use the property at the moment. It
> should.
> 
> It'd be good to verify that the rate matches: clk_set_rate() is not
> guaranteed to produce the requested clock rate, and the driver could
> conceivably be updated with support for more frequencies. There are
> typically a few frequencies that a SoC such a sensor is connected can
> support, and 25 MHz is not one of the common frequencies. With this
> property, the frequency would be always there explicitly.
> 

I can provide my arguments given at v8 review time again, since I don't
see a contradiction with my older comments.

Briefly "clock-frequency" as a device tree property on a consumer side
can be considered as redundant, because there is a mechanism to specify
a wanted clock frequency on a clock provider side right in a board DTB.

So, the clock frequency set up is delegated to CCF, and when any other
than 25 MHz frequencies are got supported, that's only the matter of
driver updates, DTBs won't be touched.

--
With best wishes,
Vladimir

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Steve Longerbeam]

On 02/21/2017 04:15 AM, Sakari Ailus wrote:

Hi Steve,

On Mon, Feb 20, 2017 at 02:56:15PM -0800, Steve Longerbeam wrote:



On 02/20/2017 02:04 PM, Sakari Ailus wrote:

Hi Steve,

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

From: Russell King 

Setting and getting frame rates is part of the negotiation mechanism
between subdevs.  The lack of support means that a frame rate at the
sensor can't be negotiated through the subdev path.


Just wondering --- what do you need this for?



Hi Sakari,

i.MX does need the ability to negotiate the frame rates in the
pipelines. The CSI has the ability to skip frames at the output,
which is something Philipp added to the CSI subdev. That affects
frame interval at the CSI output.

But as Russell pointed out, the lack of [gs]_frame_interval op
causes media-ctl to fail:

media-ctl -v -d /dev/media1 --set-v4l2
'"imx6-mipi-csi2":1[fmt:SGBRG8/512x512@1/30]'

Opening media device /dev/media1
Enumerating entities
Found 29 entities
Enumerating pads and links
Setting up format SGBRG8 512x512 on pad imx6-mipi-csi2/1
Format set: SGBRG8 512x512
Setting up frame interval 1/30 on entity imx6-mipi-csi2
Unable to set frame interval: Inappropriate ioctl for device (-25)Unable to
setup formats: Inappropriate ioctl for device (25)


So i.MX needs to implement this op in every subdev in the
pipeline, otherwise it's not possible to configure the
pipeline with media-ctl.


The frame rate is only set on the sub-device which you explicitly set it.
I.e. setting the frame rate fails if it's not supported on a pad.

Philipp recently posted patches that add frame rate propagation to
media-ctl.

Frame rate is typically settable (and gettable) only on sensor sub-device's
source pad,  which means it normally would not be propagated by the kernel
but with Philipp's patches, on the sink pad of the bus receiver. Receivers
don't have a way to control it nor they implement the IOCTLs, so that would
indeed result in an error.



Frame rate is really an essential piece of information. The spatial
dimensions and data type provided by set_fmt are really only half the
equation, the other is temporal, i.e. the data rate.

It's true that subdevices have no control over the frame rate at their
sink pads, but the same argument applies to set_fmt. Even if it has
no control over the data format it receives, it still needs that
information in order to determine the correct format at the source.
The same argument applies to frame rate.

So in my opinion, the behavior of [gs]_frame_interval should be, if a
subdevice is capable of modifying the frame rate, then it should
implement [gs]_frame_interval at _all_ of its pads, similar to set_fmt.
And frame rate should really be part of link validation the same as
set_fmt is.

Steve

Re: [PATCH 1/2] media: pci: saa7164: remove unnecessary code

[Peter Senna Tschudin]

On Mon, Feb 20, 2017 at 09:46:58PM -0600, Gustavo A. R. Silva wrote:
> Remove unnecessary variable 'loop'.
> 
Reviewed-by: Peter Senna Tschudin 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/media/pci/saa7164/saa7164-cmd.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/media/pci/saa7164/saa7164-cmd.c 
> b/drivers/media/pci/saa7164/saa7164-cmd.c
> index 45951b3..169c90a 100644
> --- a/drivers/media/pci/saa7164/saa7164-cmd.c
> +++ b/drivers/media/pci/saa7164/saa7164-cmd.c
> @@ -134,14 +134,13 @@ int saa7164_irq_dequeue(struct saa7164_dev *dev)
>   * -bus/c running buffer. */
>  static int saa7164_cmd_dequeue(struct saa7164_dev *dev)
>  {
> - int loop = 1;
>   int ret;
>   u32 timeout;
>   wait_queue_head_t *q = NULL;
>   u8 tmp[512];
>   dprintk(DBGLVL_CMD, "%s()\n", __func__);
>  
> - while (loop) {
> + while (true) {
>  
>   struct tmComResInfo tRsp = { 0, 0, 0, 0, 0, 0 };
>   ret = saa7164_bus_get(dev, , NULL, 1);
> -- 
> 2.5.0
> 

Re: [PATCH 2/2] media: pci: saa7164: remove dead code

[Peter Senna Tschudin]

On Mon, Feb 20, 2017 at 09:49:59PM -0600, Gustavo A. R. Silva wrote:
> Remove dead code. The following line of code is never reached:
> return SAA_OK;
> 
> Addresses-Coverity-ID: 114283
Reviewed-by: Peter Senna Tschudin 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/media/pci/saa7164/saa7164-cmd.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/media/pci/saa7164/saa7164-cmd.c 
> b/drivers/media/pci/saa7164/saa7164-cmd.c
> index 169c90a..fb19498 100644
> --- a/drivers/media/pci/saa7164/saa7164-cmd.c
> +++ b/drivers/media/pci/saa7164/saa7164-cmd.c
> @@ -181,8 +181,6 @@ static int saa7164_cmd_dequeue(struct saa7164_dev *dev)
>   wake_up(q);
>   return SAA_OK;
>   }
> -
> - return SAA_OK;
>  }
>  
>  static int saa7164_cmd_set(struct saa7164_dev *dev, struct tmComResInfo *msg,
> -- 
> 2.5.0
> 

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi, Vladimir!

How do you do? :-)

On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
> > Hi Vladimir,
> > 
> > Thank you for your feedback
> > 
> > On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
> >> Hi Ramiro,
> >>
> >> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> >>> Create device tree bindings documentation.
> >>>
> >>> Signed-off-by: Ramiro Oliveira 
> >>> Acked-by: Rob Herring 
> >>> ---
> >>>  .../devicetree/bindings/media/i2c/ov5647.txt   | 35 
> >>> ++
> >>>  1 file changed, 35 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt 
> >>> b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>> new file mode 100644
> >>> index ..31956426d3b9
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>> @@ -0,0 +1,35 @@
> >>> +Omnivision OV5647 raw image sensor
> >>> +-
> >>> +
> >>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data 
> >>> interfaces
> >>> +and CCI (I2C compatible) control bus.
> >>> +
> >>> +Required properties:
> >>> +
> >>> +- compatible : "ovti,ov5647".
> >>> +- reg: I2C slave address of the sensor.
> >>> +- clocks : Reference to the xclk clock.
> >>
> >> Is "xclk" clock a pixel clock or something else?
> >>
> > 
> > It's an external oscillator.
> 
> hmm, I suppose a clock of any type could serve as a clock for the sensor.
> It can be an external oscillator on a particular board, or it can be
> something else on another board.

Any clock source could be used I presume.

> 
> Can you please describe what for does ov5647 sensor need this clock, what
> is its function?

Camera modules (sensors) quite commonly require an external clock as they do
not have an oscillator on their own. A lot of devices under
Documentation/devicetree/bindings/media/i2c/ have similar properties.

> 
> > 
> >>> +- clock-names: Should be "xclk".
> >>
> >> You can remove this property, because there is only one source clock.
> >>
> > 
> > Ok.
> > 
> >>> +- clock-frequency: Frequency of the xclk clock.
> >>
> >> And after the last updates in the driver this property can be removed as 
> >> well.
> >>
> > 
> > But I'm still using clk_get_rate in the driver, if I remove the frequency 
> > here
> > the probing will fail.
> > 
> 
> I doubt it, there should be no connection between a custom "clock-frequency"
> device tree property in a clock consumer device node and clk_get_rate() 
> function
> from the CCF, which takes a clock provider as its argument.

The purpose is to make sure the clock frequency is really usable for the
device, in this particular case the driver can work with one particular
frequency.

That said, the driver does not appear to use the property at the moment. It
should.

It'd be good to verify that the rate matches: clk_set_rate() is not
guaranteed to produce the requested clock rate, and the driver could
conceivably be updated with support for more frequencies. There are
typically a few frequencies that a SoC such a sensor is connected can
support, and 25 MHz is not one of the common frequencies. With this
property, the frequency would be always there explicitly.

> 
> >>> +
> >>> +The common video interfaces bindings (see video-interfaces.txt) should be
> >>> +used to specify link to the image data receiver. The OV5647 device
> >>> +node should contain one 'port' child node with an 'endpoint' subnode.
> >>> +
> >>> +Example:
> >>> +
> >>> + i2c@2000 {
> >>> + ...
> >>> + ov: camera@36 {
> >>> + compatible = "ovti,ov5647";
> >>> + reg = <0x36>;
> >>> + clocks = <_clk>;
> >>> + clock-names = "xclk";
> >>> + clock-frequency = <2500>;
> >>
> >> When you remove two unused properties, please don't forget to update the
> >> example.
> >>
> > 
> > Ok.
> > 
> >>> + port {
> >>> + camera_1: endpoint {
> >>> + remote-endpoint = <_ep1>;
> >>> + };
> >>> + };
> >>> + };
> >>> + };
> >>>
> >>
> 
> --
^
There's a space missing here.

> With best wishes,
> Vladimir

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Vladimir Zapolskiy]

Hi Ramiro,

On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
> Hi Vladimir,
> 
> Thank you for your feedback
> 
> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>> Create device tree bindings documentation.
>>>
>>> Signed-off-by: Ramiro Oliveira 
>>> Acked-by: Rob Herring 
>>> ---
>>>  .../devicetree/bindings/media/i2c/ov5647.txt   | 35 
>>> ++
>>>  1 file changed, 35 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt 
>>> b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>> new file mode 100644
>>> index ..31956426d3b9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>> @@ -0,0 +1,35 @@
>>> +Omnivision OV5647 raw image sensor
>>> +-
>>> +
>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>> +and CCI (I2C compatible) control bus.
>>> +
>>> +Required properties:
>>> +
>>> +- compatible   : "ovti,ov5647".
>>> +- reg  : I2C slave address of the sensor.
>>> +- clocks   : Reference to the xclk clock.
>>
>> Is "xclk" clock a pixel clock or something else?
>>
> 
> It's an external oscillator.

hmm, I suppose a clock of any type could serve as a clock for the sensor.
It can be an external oscillator on a particular board, or it can be
something else on another board.

Can you please describe what for does ov5647 sensor need this clock, what
is its function?

> 
>>> +- clock-names  : Should be "xclk".
>>
>> You can remove this property, because there is only one source clock.
>>
> 
> Ok.
> 
>>> +- clock-frequency  : Frequency of the xclk clock.
>>
>> And after the last updates in the driver this property can be removed as 
>> well.
>>
> 
> But I'm still using clk_get_rate in the driver, if I remove the frequency here
> the probing will fail.
> 

I doubt it, there should be no connection between a custom "clock-frequency"
device tree property in a clock consumer device node and clk_get_rate() function
from the CCF, which takes a clock provider as its argument.

>>> +
>>> +The common video interfaces bindings (see video-interfaces.txt) should be
>>> +used to specify link to the image data receiver. The OV5647 device
>>> +node should contain one 'port' child node with an 'endpoint' subnode.
>>> +
>>> +Example:
>>> +
>>> +   i2c@2000 {
>>> +   ...
>>> +   ov: camera@36 {
>>> +   compatible = "ovti,ov5647";
>>> +   reg = <0x36>;
>>> +   clocks = <_clk>;
>>> +   clock-names = "xclk";
>>> +   clock-frequency = <2500>;
>>
>> When you remove two unused properties, please don't forget to update the
>> example.
>>
> 
> Ok.
> 
>>> +   port {
>>> +   camera_1: endpoint {
>>> +   remote-endpoint = <_ep1>;
>>> +   };
>>> +   };
>>> +   };
>>> +   };
>>>
>>

--
With best wishes,
Vladimir

[PATCH v2 09/19] [media] mce_kbd: add encoder

[Sean Young]

Split the protocol into two variants, one for keyboard and one for mouse
data.

Note that the mce_kbd protocol cannot be used on the igorplugusb, since
the IR is too long.

Signed-off-by: Sean Young 
---
 drivers/media/rc/igorplugusb.c|  2 +-
 drivers/media/rc/ir-mce_kbd-decoder.c | 49 +-
 drivers/media/rc/rc-core-priv.h   |  2 +-
 drivers/media/rc/rc-ir-raw.c  |  6 +--
 drivers/media/rc/rc-main.c|  8 +++-
 include/media/rc-map.h| 78 ++-
 6 files changed, 99 insertions(+), 46 deletions(-)

diff --git a/drivers/media/rc/igorplugusb.c b/drivers/media/rc/igorplugusb.c
index 0f0ed4e..cb6d4f1 100644
--- a/drivers/media/rc/igorplugusb.c
+++ b/drivers/media/rc/igorplugusb.c
@@ -205,7 +205,7 @@ static int igorplugusb_probe(struct usb_interface *intf,
rc->allowed_protocols = RC_BIT_ALL_IR_DECODER & ~(RC_BIT_NEC |
RC_BIT_NECX | RC_BIT_NEC32 | RC_BIT_RC6_6A_20 |
RC_BIT_RC6_6A_24 | RC_BIT_RC6_6A_32 | RC_BIT_RC6_MCE |
-   RC_BIT_SONY20 | RC_BIT_MCE_KBD | RC_BIT_SANYO);
+   RC_BIT_SONY20 | RC_BIT_SANYO);
 
rc->priv = ir;
rc->driver_name = DRIVER_NAME;
diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c 
b/drivers/media/rc/ir-mce_kbd-decoder.c
index 5226d51..6a4d58b 100644
--- a/drivers/media/rc/ir-mce_kbd-decoder.c
+++ b/drivers/media/rc/ir-mce_kbd-decoder.c
@@ -23,7 +23,7 @@
  * - MCIR-2 29-bit IR signals used for mouse movement and buttons
  * - MCIR-2 32-bit IR signals used for standard keyboard keys
  *
- * The media keys on the keyboard send RC-6 signals that are inditinguishable
+ * The media keys on the keyboard send RC-6 signals that are indistinguishable
  * from the keys of the same name on the stock MCE remote, and will be handled
  * by the standard RC-6 decoder, and be made available to the system via the
  * input device for the remote, rather than the keyboard/mouse one.
@@ -339,6 +339,7 @@ static int ir_mce_kbd_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
}
 
data->state = STATE_INACTIVE;
+   input_event(data->idev, EV_MSC, MSC_SCAN, scancode);
input_sync(data->idev);
return 0;
}
@@ -418,9 +419,53 @@ static int ir_mce_kbd_unregister(struct rc_dev *dev)
return 0;
 }
 
+static const struct ir_raw_timings_manchester ir_mce_kbd_timings = {
+   .leader = MCIR2_PREFIX_PULSE,
+   .invert = 1,
+   .clock  = MCIR2_UNIT,
+   .trailer_space  = MCIR2_UNIT * 10,
+};
+
+/**
+ * ir_mce_kbd_encode() - Encode a scancode as a stream of raw events
+ *
+ * @protocol:   protocol to encode
+ * @scancode:   scancode to encode
+ * @events: array of raw ir events to write into
+ * @max:maximum size of @events
+ *
+ * Returns: The number of events written.
+ *  -ENOBUFS if there isn't enough space in the array to fit the
+ *  encoding. In this case all @max events will have been written.
+ */
+static int ir_mce_kbd_encode(enum rc_type protocol, u32 scancode,
+struct ir_raw_event *events, unsigned int max)
+{
+   struct ir_raw_event *e = events;
+   int len, ret;
+   u64 raw;
+
+   if (protocol == RC_TYPE_MCIR2_KBD) {
+   raw = scancode |
+ ((u64)MCIR2_KEYBOARD_HEADER << MCIR2_KEYBOARD_NBITS);
+   len = MCIR2_KEYBOARD_NBITS + MCIR2_HEADER_NBITS + 1;
+   } else {
+   raw = scancode |
+ ((u64)MCIR2_MOUSE_HEADER << MCIR2_MOUSE_NBITS);
+   len = MCIR2_MOUSE_NBITS + MCIR2_HEADER_NBITS + 1;
+   }
+
+   ret = ir_raw_gen_manchester(, max, _mce_kbd_timings, len, raw);
+   if (ret < 0)
+   return ret;
+
+   return e - events;
+}
+
 static struct ir_raw_handler mce_kbd_handler = {
-   .protocols  = RC_BIT_MCE_KBD,
+   .protocols  = RC_BIT_MCIR2_KBD | RC_BIT_MCIR2_MSE,
.decode = ir_mce_kbd_decode,
+   .encode = ir_mce_kbd_encode,
.raw_register   = ir_mce_kbd_register,
.raw_unregister = ir_mce_kbd_unregister,
 };
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index a70a5c55..0455b27 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -185,7 +185,7 @@ struct ir_raw_timings_manchester {
 
 int ir_raw_gen_manchester(struct ir_raw_event **ev, unsigned int max,
  const struct ir_raw_timings_manchester *timings,
- unsigned int n, unsigned int data);
+ unsigned int n, u64 data);
 
 /**
  * ir_raw_gen_pulse_space() - generate pulse and space raw events.
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 7fa84b6..90f66dc 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ 

[PATCH v2 17/19] [media] lirc: implement reading scancode

[Sean Young]

This implements LIRC_MODE_SCANCODE reading from the lirc device. The
scancode can be read from the input device too, but with this interface
you get the rc protocol, toggle and repeat status in addition too just
the scancode.

int main()
{
int fd, mode, rc;
fd = open("/dev/lirc0", O_RDWR);

mode = LIRC_MODE_SCANCODE;
if (ioctl(fd, LIRC_SET_REC_MODE, )) {
// kernel too old or lirc does not support transmit
}
struct lirc_scancode scancode;
while (read(fd, , sizeof(scancode)) == sizeof(scancode)) {
printf("protocol:%d scancode:0x%x toggle:%d repeat:%d\n",
scancode.rc_type, scancode.scancode,
!!(scancode.flags & LIRC_SCANCODE_FLAG_TOGGLE),
!!(scancode.flags & LIRC_SCANCODE_FLAG_REPEAT));
}
close(fd);
}

Note that the translated KEY_* is not included, that information is
published to the input device.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c  | 107 +++---
 drivers/media/rc/ir-mce_kbd-decoder.c |   7 +++
 drivers/media/rc/rc-core-priv.h   |  11 
 drivers/media/rc/rc-main.c|  17 ++
 include/media/rc-core.h   |   4 +-
 5 files changed, 123 insertions(+), 23 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 2189321..1847f5f 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -231,8 +231,31 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
}
 
switch (cmd) {
+   case LIRC_GET_REC_MODE:
+   if (dev->driver_type == RC_DRIVER_IR_RAW_TX)
+   return -ENOTTY;
+
+   val = lirc->rec_mode;
+   break;
+
+   case LIRC_SET_REC_MODE:
+   switch (dev->driver_type) {
+   case RC_DRIVER_SCANCODE:
+   if (val != LIRC_MODE_SCANCODE)
+   return -EINVAL;
+   break;
+   case RC_DRIVER_IR_RAW:
+   if (!(val == LIRC_MODE_SCANCODE ||
+ val == LIRC_MODE_MODE2))
+   return -EINVAL;
+   break;
+   default:
+   return -ENOTTY;
+   }
+
+   lirc->rec_mode = val;
+   return 0;
 
-   /* legacy support */
case LIRC_GET_SEND_MODE:
if (!dev->tx_ir)
return -ENOTTY;
@@ -367,10 +390,15 @@ static unsigned int ir_lirc_poll(struct file *filep,
 
poll_wait(filep, >wait_poll, wait);
 
-   if (!lirc->drv->attached)
+   if (!drv->attached) {
events = POLLERR;
-   else if (!kfifo_is_empty(>kfifo))
-   events = POLLIN | POLLRDNORM;
+   } else if (dev->rec_mode == LIRC_MODE_SCANCODE) {
+   if (!kfifo_is_empty(>kfifo))
+   events = POLLIN | POLLRDNORM;
+   } else if (dev->rec_mode == LIRC_MODE_MODE2) {
+   if (!kfifo_is_empty(>raw->lirc.kfifo))
+   events = POLLIN | POLLRDNORM;
+   }
 
return events;
 }
@@ -382,31 +410,60 @@ static ssize_t ir_lirc_read(struct file *filep, char 
__user *buffer,
unsigned int copied;
int ret;
 
-   if (length % sizeof(unsigned int))
-   return -EINVAL;
-
if (!lirc->drv->attached)
return -ENODEV;
 
-   do {
-   if (kfifo_is_empty(>kfifo)) {
-   if (filep->f_flags & O_NONBLOCK)
-   return -EAGAIN;
+   if (lirc->rec_mode == LIRC_MODE_SCANCODE) {
+   struct rc_dev *rcdev = lirc->dev;
 
-   ret = wait_event_interruptible(lirc->wait_poll,
-   !kfifo_is_empty(>kfifo) ||
+   if (length % sizeof(struct lirc_scancode))
+   return -EINVAL;
+
+   do {
+   if (kfifo_is_empty(>kfifo)) {
+   if (filep->f_flags & O_NONBLOCK)
+   return -EAGAIN;
+
+   ret = wait_event_interruptible(lirc->wait_poll,
+   !kfifo_is_empty(>kfifo) ||
!lirc->drv->attached);
+   if (ret)
+   return ret;
+   }
+
+   if (!lirc->drv->attached)
+   return -ENODEV;
+
+   ret = kfifo_to_user(>kfifo, buffer, length,
+   );
if (ret)
return ret;
-   }
+   } while (copied == 0);
+   } else {
+ 

[PATCH v2 15/19] [media] rc: use the correct carrier for scancode transmit

[Sean Young]

If the lirc device supports it, set the carrier for the protocol.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-jvc-decoder.c |  1 +
 drivers/media/rc/ir-lirc-codec.c  | 28 
 drivers/media/rc/ir-mce_kbd-decoder.c |  1 +
 drivers/media/rc/ir-nec-decoder.c |  1 +
 drivers/media/rc/ir-rc5-decoder.c |  1 +
 drivers/media/rc/ir-rc6-decoder.c |  1 +
 drivers/media/rc/ir-sanyo-decoder.c   |  1 +
 drivers/media/rc/ir-sharp-decoder.c   |  1 +
 drivers/media/rc/ir-sony-decoder.c|  1 +
 drivers/media/rc/rc-core-priv.h   |  1 +
 drivers/media/rc/rc-ir-raw.c  | 30 ++
 include/media/rc-core.h   |  1 +
 12 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/drivers/media/rc/ir-jvc-decoder.c 
b/drivers/media/rc/ir-jvc-decoder.c
index 674bf15..f3a1f6e 100644
--- a/drivers/media/rc/ir-jvc-decoder.c
+++ b/drivers/media/rc/ir-jvc-decoder.c
@@ -212,6 +212,7 @@ static struct ir_raw_handler jvc_handler = {
.protocols  = RC_BIT_JVC,
.decode = ir_jvc_decode,
.encode = ir_jvc_encode,
+   .carrier= 38000,
 };
 
 static int __init ir_jvc_decode_init(void)
diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 762fa5e..2189321 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -95,7 +95,7 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, const 
char __user *buf,
 {
struct lirc_codec *lirc;
struct rc_dev *dev;
-   unsigned int *txbuf; /* buffer with values to transmit */
+   unsigned int *txbuf = NULL; /* buffer with values to transmit */
struct ir_raw_event *raw = NULL;
ssize_t ret = -EINVAL;
size_t count;
@@ -110,6 +110,13 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
if (!lirc)
return -EFAULT;
 
+   dev = lirc->dev;
+   if (!dev)
+   return -EFAULT;
+
+   if (!dev->tx_ir)
+   return -EINVAL;
+
if (lirc->send_mode == LIRC_MODE_SCANCODE) {
struct lirc_scancode scan;
 
@@ -140,7 +147,15 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
}
 
for (i = 0; i < count; i++)
+   /* Convert from NS to US */
txbuf[i] = DIV_ROUND_UP(raw[i].duration, 1000);
+
+   if (dev->s_tx_carrier) {
+   int carrier = ir_raw_encode_carrier(scan.rc_type);
+
+   if (carrier > 0)
+   dev->s_tx_carrier(dev, carrier);
+   }
} else {
if (n < sizeof(unsigned int) || n % sizeof(unsigned int))
return -EINVAL;
@@ -154,17 +169,6 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
return PTR_ERR(txbuf);
}
 
-   dev = lirc->dev;
-   if (!dev) {
-   ret = -EFAULT;
-   goto out;
-   }
-
-   if (!dev->tx_ir) {
-   ret = -EINVAL;
-   goto out;
-   }
-
for (i = 0; i < count; i++) {
if (txbuf[i] > IR_MAX_DURATION / 1000 - duration || !txbuf[i]) {
ret = -EINVAL;
diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c 
b/drivers/media/rc/ir-mce_kbd-decoder.c
index 6a4d58b..79c8f40 100644
--- a/drivers/media/rc/ir-mce_kbd-decoder.c
+++ b/drivers/media/rc/ir-mce_kbd-decoder.c
@@ -468,6 +468,7 @@ static struct ir_raw_handler mce_kbd_handler = {
.encode = ir_mce_kbd_encode,
.raw_register   = ir_mce_kbd_register,
.raw_unregister = ir_mce_kbd_unregister,
+   .carrier= 36000,
 };
 
 static int __init ir_mce_kbd_decode_init(void)
diff --git a/drivers/media/rc/ir-nec-decoder.c 
b/drivers/media/rc/ir-nec-decoder.c
index 3ce8503..8f9ca71 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -288,6 +288,7 @@ static struct ir_raw_handler nec_handler = {
.protocols  = RC_BIT_NEC | RC_BIT_NECX | RC_BIT_NEC32,
.decode = ir_nec_decode,
.encode = ir_nec_encode,
+   .carrier= 38000,
 };
 
 static int __init ir_nec_decode_init(void)
diff --git a/drivers/media/rc/ir-rc5-decoder.c 
b/drivers/media/rc/ir-rc5-decoder.c
index fcfedf9..d92e49b 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -281,6 +281,7 @@ static struct ir_raw_handler rc5_handler = {
.protocols  = RC_BIT_RC5 | RC_BIT_RC5X_20 | RC_BIT_RC5_SZ,
.decode = ir_rc5_decode,
.encode = ir_rc5_encode,
+   .carrier= 36000,
 };
 
 static int __init ir_rc5_decode_init(void)
diff --git a/drivers/media/rc/ir-rc6-decoder.c 
b/drivers/media/rc/ir-rc6-decoder.c
index 6fe2268..83a36f4 

[PATCH v2 18/19] [media] lirc: scancode rc devices should have a lirc device too

[Sean Young]

Now that the lirc interface supports scancodes, RC scancode devices
can also have a lirc device, except for cec devices which have their
own /dev/cecN interface.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c  | 106 ++
 drivers/media/rc/ir-mce_kbd-decoder.c |   2 +-
 drivers/media/rc/rc-core-priv.h   |  15 -
 drivers/media/rc/rc-main.c|   9 +--
 include/media/rc-core.h   |  10 
 5 files changed, 60 insertions(+), 82 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 1847f5f..d0dc9b4 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -85,7 +85,7 @@ int ir_lirc_raw_event(struct rc_dev *dev, struct ir_raw_event 
ev)
}
 
kfifo_put(>kfifo, sample);
-   wake_up_poll(>wait_poll, POLLIN);
+   wake_up_poll(>wait_poll, POLLIN);
 
return 0;
 }
@@ -93,8 +93,7 @@ int ir_lirc_raw_event(struct rc_dev *dev, struct ir_raw_event 
ev)
 static ssize_t ir_lirc_transmit_ir(struct file *file, const char __user *buf,
   size_t n, loff_t *ppos)
 {
-   struct lirc_codec *lirc;
-   struct rc_dev *dev;
+   struct rc_dev *dev = lirc_get_pdata(file);
unsigned int *txbuf = NULL; /* buffer with values to transmit */
struct ir_raw_event *raw = NULL;
ssize_t ret = -EINVAL;
@@ -106,18 +105,10 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
 
start = ktime_get();
 
-   lirc = lirc_get_pdata(file);
-   if (!lirc)
-   return -EFAULT;
-
-   dev = lirc->dev;
-   if (!dev)
-   return -EFAULT;
-
if (!dev->tx_ir)
return -EINVAL;
 
-   if (lirc->send_mode == LIRC_MODE_SCANCODE) {
+   if (dev->send_mode == LIRC_MODE_SCANCODE) {
struct lirc_scancode scan;
 
if (n != sizeof(scan))
@@ -185,7 +176,7 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, const 
char __user *buf,
for (duration = i = 0; i < ret; i++)
duration += txbuf[i];
 
-   if (lirc->send_mode == LIRC_MODE_SCANCODE)
+   if (dev->send_mode == LIRC_MODE_SCANCODE)
ret = n;
else
ret *= sizeof(unsigned int);
@@ -210,20 +201,11 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
 static long ir_lirc_ioctl(struct file *filep, unsigned int cmd,
unsigned long arg)
 {
-   struct lirc_codec *lirc;
-   struct rc_dev *dev;
+   struct rc_dev *dev = lirc_get_pdata(filep);
u32 __user *argp = (u32 __user *)(arg);
int ret = 0;
__u32 val = 0, tmp;
 
-   lirc = lirc_get_pdata(filep);
-   if (!lirc)
-   return -EFAULT;
-
-   dev = lirc->dev;
-   if (!dev)
-   return -EFAULT;
-
if (_IOC_DIR(cmd) & _IOC_WRITE) {
ret = get_user(val, argp);
if (ret)
@@ -235,7 +217,7 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
if (dev->driver_type == RC_DRIVER_IR_RAW_TX)
return -ENOTTY;
 
-   val = lirc->rec_mode;
+   val = dev->rec_mode;
break;
 
case LIRC_SET_REC_MODE:
@@ -253,14 +235,14 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
int cmd,
return -ENOTTY;
}
 
-   lirc->rec_mode = val;
+   dev->rec_mode = val;
return 0;
 
case LIRC_GET_SEND_MODE:
if (!dev->tx_ir)
return -ENOTTY;
 
-   val = lirc->send_mode;
+   val = dev->send_mode;
break;
 
case LIRC_SET_SEND_MODE:
@@ -270,7 +252,7 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
if (!(val == LIRC_MODE_PULSE || val == LIRC_MODE_SCANCODE))
return -EINVAL;
 
-   lirc->send_mode = val;
+   dev->send_mode = val;
return 0;
 
/* TX settings */
@@ -297,7 +279,7 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
 
/* RX settings */
case LIRC_SET_REC_CARRIER:
-   if (!dev->s_rx_carrier_range)
+   if (!dev->s_rx_carrier_range || !dev->raw)
return -ENOTTY;
 
if (val <= 0)
@@ -308,7 +290,7 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
   val);
 
case LIRC_SET_REC_CARRIER_RANGE:
-   if (!dev->s_rx_carrier_range)
+   if (!dev->s_rx_carrier_range || !dev->raw)
return -ENOTTY;
 
if (val <= 0)
@@ -366,10 +348,10 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
int cmd,

[PATCH v2 11/19] [media] lirc: lirc interface should not be a raw decoder

[Sean Young]

The lirc bridge exists as a raw decoder. We would like to make the bridge
to also work for scancode drivers in further commits, so it cannot be
a raw decoder.

Note that rc-code, lirc_dev, ir-lirc-codec are now calling functions of
each other, so they've been merged into one module rc-core to avoid
circular dependencies.

Since ir-lirc-codec no longer exists as separate codec module, there is no
need for RC_DRIVER_IR_RAW_TX type drivers to call ir_raw_event_register().

Signed-off-by: Sean Young 
---
 drivers/media/rc/Kconfig | 15 ++--
 drivers/media/rc/Makefile|  6 ++---
 drivers/media/rc/ir-lirc-codec.c | 41 -
 drivers/media/rc/lirc_dev.c  | 19 +++-
 drivers/media/rc/rc-core-priv.h  | 24 +++-
 drivers/media/rc/rc-ir-raw.c | 17 +-
 drivers/media/rc/rc-main.c   | 49 
 7 files changed, 71 insertions(+), 100 deletions(-)

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index d1d3fd0..8787bf1 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -6,14 +6,8 @@ config RC_CORE
 
 source "drivers/media/rc/keymaps/Kconfig"
 
-menuconfig RC_DECODERS
-bool "Remote controller decoders"
-   depends on RC_CORE
-   default y
-
-if RC_DECODERS
 config LIRC
-   tristate "LIRC interface driver"
+   bool "LIRC interface driver"
depends on RC_CORE
 
---help---
@@ -24,7 +18,7 @@ config LIRC
   encoding for IR transmitting (aka "blasting").
 
 config IR_LIRC_CODEC
-   tristate "Enable IR to LIRC bridge"
+   bool "Enable IR to LIRC bridge"
depends on RC_CORE
depends on LIRC
default y
@@ -33,7 +27,12 @@ config IR_LIRC_CODEC
   Enable this option to pass raw IR to and from userspace via
   the LIRC interface.
 
+menuconfig RC_DECODERS
+   bool "Remote controller decoders"
+   depends on RC_CORE
+   default y
 
+if RC_DECODERS
 config IR_NEC_DECODER
tristate "Enable IR raw decoder for the NEC protocol"
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 679aa0a..f9dee1c 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -1,9 +1,10 @@
-rc-core-objs   := rc-main.o rc-ir-raw.o
 
 obj-y += keymaps/
 
 obj-$(CONFIG_RC_CORE) += rc-core.o
-obj-$(CONFIG_LIRC) += lirc_dev.o
+rc-core-y := rc-main.o rc-ir-raw.o
+rc-core-$(CONFIG_LIRC) += lirc_dev.o
+rc-core-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
 obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
 obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
 obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
@@ -12,7 +13,6 @@ obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o
 obj-$(CONFIG_IR_SANYO_DECODER) += ir-sanyo-decoder.o
 obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
 obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
-obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
 obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
 
 # stand-alone IR receivers/transmitters
diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index de85f1d..16ac65a 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -14,7 +14,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -23,14 +22,14 @@
 #define LIRCBUF_SIZE 256
 
 /**
- * ir_lirc_decode() - Send raw IR data to lirc_dev to be relayed to the
- *   lircd userspace daemon for decoding.
+ * ir_lirc_raw_event() - Send raw IR data to lirc to be relayed to userspace
+ *
  * @input_dev: the struct rc_dev descriptor of the device
  * @duration:  the struct ir_raw_event descriptor of the pulse/space
  *
  * This function returns -EINVAL if the lirc interfaces aren't wired up.
  */
-static int ir_lirc_decode(struct rc_dev *dev, struct ir_raw_event ev)
+int ir_lirc_raw_event(struct rc_dev *dev, struct ir_raw_event ev)
 {
struct lirc_codec *lirc = >raw->lirc;
int sample;
@@ -351,7 +350,7 @@ static const struct file_operations lirc_fops = {
.llseek = no_llseek,
 };
 
-static int ir_lirc_register(struct rc_dev *dev)
+int ir_lirc_register(struct rc_dev *dev)
 {
struct lirc_driver *drv;
struct lirc_buffer *rbuf;
@@ -431,7 +430,7 @@ static int ir_lirc_register(struct rc_dev *dev)
return rc;
 }
 
-static int ir_lirc_unregister(struct rc_dev *dev)
+void ir_lirc_unregister(struct rc_dev *dev)
 {
struct lirc_codec *lirc = >raw->lirc;
 
@@ -439,34 +438,4 @@ static int ir_lirc_unregister(struct rc_dev *dev)
lirc_buffer_free(lirc->drv->rbuf);
kfree(lirc->drv->rbuf);
kfree(lirc->drv);
-
-   return 0;
 }
-
-static struct ir_raw_handler lirc_handler = {
-   .protocols  = 0,
-   .decode = ir_lirc_decode,
-   .raw_register   = ir_lirc_register,
-   .raw_unregister = ir_lirc_unregister,
-};
-

[PATCH v2 12/19] [media] lirc: exorcise struct irctl

[Sean Young]

lirc_register_driver() takes a struct lirc_driver argument, it then
allocates a new struct irctl which contains another struct lirc_driver
and then copies it over.

By moving the members of struct irctl to struct lirc_driver, we avoid the
extra allocation and we can remove struct irctl completely. We also
remove the duplicate chunk_size member.

In addition, the members of irctl are now visible elsewhere.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c|   3 +-
 drivers/media/rc/lirc_dev.c | 353 +++-
 drivers/staging/media/lirc/lirc_sasem.c |   3 +-
 drivers/staging/media/lirc/lirc_zilog.c | 109 +-
 include/media/lirc_dev.h|  29 ++-
 5 files changed, 253 insertions(+), 244 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 16ac65a..78f354a 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -407,7 +407,7 @@ int ir_lirc_register(struct rc_dev *dev)
drv->set_use_dec = _lirc_close;
drv->code_length = sizeof(struct ir_raw_event) * 8;
drv->fops = _fops;
-   drv->dev = >dev;
+   drv->dev.parent = >dev;
drv->rdev = dev;
drv->owner = THIS_MODULE;
 
@@ -437,5 +437,4 @@ void ir_lirc_unregister(struct rc_dev *dev)
lirc_unregister_driver(lirc->drv->minor);
lirc_buffer_free(lirc->drv->rbuf);
kfree(lirc->drv->rbuf);
-   kfree(lirc->drv);
 }
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 26e1983..44650e4 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -43,25 +43,9 @@
 
 static dev_t lirc_base_dev;
 
-struct irctl {
-   struct lirc_driver d;
-   int attached;
-   int open;
-
-   struct mutex irctl_lock;
-   struct lirc_buffer *buf;
-   unsigned int chunk_size;
-
-   struct device dev;
-   struct cdev cdev;
-
-   struct task_struct *task;
-   long jiffies_to_wait;
-};
-
 static DEFINE_MUTEX(lirc_dev_lock);
 
-static struct irctl *irctls[MAX_IRCTL_DEVICES];
+static struct lirc_driver *irctls[MAX_IRCTL_DEVICES];
 
 /* Only used for sysfs but defined to void otherwise */
 static struct class *lirc_class;
@@ -69,39 +53,39 @@ static struct class *lirc_class;
 /*  helper function
  *  initializes the irctl structure
  */
-static void lirc_irctl_init(struct irctl *ir)
+static void lirc_irctl_init(struct lirc_driver *d)
 {
-   mutex_init(>irctl_lock);
-   ir->d.minor = NOPLUG;
+   mutex_init(>irctl_lock);
+   d->minor = NOPLUG;
 }
 
 static void lirc_release(struct device *ld)
 {
-   struct irctl *ir = container_of(ld, struct irctl, dev);
+   struct lirc_driver *d = container_of(ld, struct lirc_driver, dev);
 
-   put_device(ir->dev.parent);
+   put_device(d->dev.parent);
 
-   if (ir->buf != ir->d.rbuf) {
-   lirc_buffer_free(ir->buf);
-   kfree(ir->buf);
+   if (d->buf != d->rbuf) {
+   lirc_buffer_free(d->buf);
+   kfree(d->buf);
}
 
mutex_lock(_dev_lock);
-   irctls[ir->d.minor] = NULL;
+   irctls[d->minor] = NULL;
mutex_unlock(_dev_lock);
-   kfree(ir);
+   kfree(d);
 }
 
 /*  helper function
  *  reads key codes from driver and puts them into buffer
  *  returns 0 on success
  */
-static int lirc_add_to_buf(struct irctl *ir)
+static int lirc_add_to_buf(struct lirc_driver *d)
 {
int res;
int got_data = -1;
 
-   if (!ir->d.add_to_buf)
+   if (!d->add_to_buf)
return 0;
 
/*
@@ -110,31 +94,31 @@ static int lirc_add_to_buf(struct irctl *ir)
 */
do {
got_data++;
-   res = ir->d.add_to_buf(ir->d.data, ir->buf);
+   res = d->add_to_buf(d->data, d->buf);
} while (!res);
 
if (res == -ENODEV)
-   kthread_stop(ir->task);
+   kthread_stop(d->task);
 
return got_data ? 0 : res;
 }
 
 /* main function of the polling thread
  */
-static int lirc_thread(void *irctl)
+static int lirc_thread(void *lirc_driver)
 {
-   struct irctl *ir = irctl;
+   struct lirc_driver *d = lirc_driver;
 
do {
-   if (ir->open) {
-   if (ir->jiffies_to_wait) {
+   if (d->open) {
+   if (d->jiffies_to_wait) {
set_current_state(TASK_INTERRUPTIBLE);
-   schedule_timeout(ir->jiffies_to_wait);
+   schedule_timeout(d->jiffies_to_wait);
}
if (kthread_should_stop())
break;
-   if (!lirc_add_to_buf(ir))
-   wake_up_interruptible(>buf->wait_poll);
+   if (!lirc_add_to_buf(d))
+   

[PATCH v2 16/19] [media] rc: auto load encoder if necessary

[Sean Young]

When sending scancodes, load the encoder if we need it.

Signed-off-by: Sean Young 
---
 drivers/media/rc/rc-core-priv.h | 1 +
 drivers/media/rc/rc-ir-raw.c| 2 ++
 drivers/media/rc/rc-main.c  | 2 +-
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index 1b53409..db0d2e0 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -294,6 +294,7 @@ int ir_raw_event_register(struct rc_dev *dev);
 void ir_raw_event_unregister(struct rc_dev *dev);
 int ir_raw_handler_register(struct ir_raw_handler *ir_raw_handler);
 void ir_raw_handler_unregister(struct ir_raw_handler *ir_raw_handler);
+void ir_raw_load_modules(u64 *protocols);
 void ir_raw_init(void);
 
 /*
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 9ffa5a9..65531c5 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -470,6 +470,8 @@ int ir_raw_encode_scancode(enum rc_type protocol, u32 
scancode,
int ret = -EINVAL;
u64 mask = 1ULL << protocol;
 
+   ir_raw_load_modules();
+
mutex_lock(_raw_handler_lock);
list_for_each_entry(handler, _raw_handler_list, list) {
if (handler->protocols & mask && handler->encode) {
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index de533b5..6f3 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1039,7 +1039,7 @@ static int parse_protocol_change(u64 *protocols, const 
char *buf)
return count;
 }
 
-static void ir_raw_load_modules(u64 *protocols)
+void ir_raw_load_modules(u64 *protocols)
 {
u64 available;
int i, ret;
-- 
2.9.3

[PATCH v2 07/19] [media] lirc: advertise LIRC_CAN_GET_REC_RESOLUTION and improve

[Sean Young]

This feature was never set. The ioctl should fail if no resolution
is set.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 235d74a..de85f1d 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -263,6 +263,9 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
return 0;
 
case LIRC_GET_REC_RESOLUTION:
+   if (!dev->rx_resolution)
+   return -ENOTTY;
+
val = dev->rx_resolution;
break;
 
@@ -367,8 +370,11 @@ static int ir_lirc_register(struct rc_dev *dev)
if (rc)
goto rbuf_init_failed;
 
-   if (dev->driver_type != RC_DRIVER_IR_RAW_TX)
+   if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
features |= LIRC_CAN_REC_MODE2;
+   if (dev->rx_resolution)
+   features |= LIRC_CAN_GET_REC_RESOLUTION;
+   }
if (dev->tx_ir) {
features |= LIRC_CAN_SEND_PULSE;
if (dev->s_tx_mask)
-- 
2.9.3

[PATCH v2 08/19] [media] lirc: use refcounting for lirc devices

[Sean Young]

If a lirc device is unplugged, the struct rc_dev is freed even though
userspace can still have a file descriptor open on the lirc chardev. The
rc_dev structure can be used in a subsequent, or even currently executing
ioctl, read or write.

Signed-off-by: Sean Young 
---
 drivers/media/rc/lirc_dev.c | 120 +++-
 1 file changed, 51 insertions(+), 69 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index ccbdce0..988758b 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -54,7 +54,8 @@ struct irctl {
struct lirc_buffer *buf;
unsigned int chunk_size;
 
-   struct cdev *cdev;
+   struct device dev;
+   struct cdev cdev;
 
struct task_struct *task;
long jiffies_to_wait;
@@ -76,15 +77,21 @@ static void lirc_irctl_init(struct irctl *ir)
ir->d.minor = NOPLUG;
 }
 
-static void lirc_irctl_cleanup(struct irctl *ir)
+static void lirc_release(struct device *ld)
 {
-   device_destroy(lirc_class, MKDEV(MAJOR(lirc_base_dev), ir->d.minor));
+   struct irctl *ir = container_of(ld, struct irctl, dev);
+
+   put_device(ir->dev.parent);
 
if (ir->buf != ir->d.rbuf) {
lirc_buffer_free(ir->buf);
kfree(ir->buf);
}
-   ir->buf = NULL;
+
+   mutex_lock(_dev_lock);
+   irctls[ir->d.minor] = NULL;
+   mutex_unlock(_dev_lock);
+   kfree(ir);
 }
 
 /*  helper function
@@ -157,32 +164,21 @@ static int lirc_cdev_add(struct irctl *ir)
struct cdev *cdev;
int retval;
 
-   cdev = cdev_alloc();
-   if (!cdev)
-   return -ENOMEM;
+   cdev = >cdev;
 
if (d->fops) {
-   cdev->ops = d->fops;
+   cdev_init(cdev, d->fops);
cdev->owner = d->owner;
} else {
-   cdev->ops = _dev_fops;
+   cdev_init(cdev, _dev_fops);
cdev->owner = THIS_MODULE;
}
retval = kobject_set_name(>kobj, "lirc%d", d->minor);
if (retval)
-   goto err_out;
-
-   retval = cdev_add(cdev, MKDEV(MAJOR(lirc_base_dev), d->minor), 1);
-   if (retval)
-   goto err_out;
-
-   ir->cdev = cdev;
-
-   return 0;
+   return retval;
 
-err_out:
-   cdev_del(cdev);
-   return retval;
+   cdev->kobj.parent = >dev.kobj;
+   return cdev_add(cdev, ir->dev.devt, 1);
 }
 
 static int lirc_allocate_buffer(struct irctl *ir)
@@ -304,9 +300,12 @@ static int lirc_allocate_driver(struct lirc_driver *d)
 
ir->d = *d;
 
-   device_create(lirc_class, ir->d.dev,
- MKDEV(MAJOR(lirc_base_dev), ir->d.minor), NULL,
- "lirc%u", ir->d.minor);
+   ir->dev.devt = MKDEV(MAJOR(lirc_base_dev), ir->d.minor);
+   ir->dev.class = lirc_class;
+   ir->dev.parent = d->dev;
+   ir->dev.release = lirc_release;
+   dev_set_name(>dev, "lirc%d", ir->d.minor);
+   device_initialize(>dev);
 
if (d->sample_rate) {
ir->jiffies_to_wait = HZ / d->sample_rate;
@@ -329,14 +328,22 @@ static int lirc_allocate_driver(struct lirc_driver *d)
goto out_sysfs;
 
ir->attached = 1;
+
+   err = device_add(>dev);
+   if (err)
+   goto out_cdev;
+
mutex_unlock(_dev_lock);
 
+   get_device(ir->dev.parent);
+
dev_info(ir->d.dev, "lirc_dev: driver %s registered at minor = %d\n",
 ir->d.name, ir->d.minor);
return minor;
-
+out_cdev:
+   cdev_del(>cdev);
 out_sysfs:
-   device_destroy(lirc_class, MKDEV(MAJOR(lirc_base_dev), ir->d.minor));
+   put_device(>dev);
 out_lock:
mutex_unlock(_dev_lock);
 
@@ -364,7 +371,6 @@ EXPORT_SYMBOL(lirc_register_driver);
 int lirc_unregister_driver(int minor)
 {
struct irctl *ir;
-   struct cdev *cdev;
 
if (minor < 0 || minor >= MAX_IRCTL_DEVICES) {
pr_err("minor (%d) must be between 0 and %d!\n",
@@ -378,8 +384,6 @@ int lirc_unregister_driver(int minor)
return -ENOENT;
}
 
-   cdev = ir->cdev;
-
mutex_lock(_dev_lock);
 
if (ir->d.minor != minor) {
@@ -401,22 +405,20 @@ int lirc_unregister_driver(int minor)
dev_dbg(ir->d.dev, LOGHEAD "releasing opened driver\n",
ir->d.name, ir->d.minor);
wake_up_interruptible(>buf->wait_poll);
-   mutex_lock(>irctl_lock);
+   }
 
-   if (ir->d.set_use_dec)
-   ir->d.set_use_dec(ir->d.data);
+   mutex_lock(>irctl_lock);
 
-   module_put(cdev->owner);
-   mutex_unlock(>irctl_lock);
-   } else {
-   lirc_irctl_cleanup(ir);
-   cdev_del(cdev);
-   kfree(ir);
-   irctls[minor] = NULL;
-   }
+   if (ir->d.set_use_dec)
+   

[PATCH v2 14/19] [media] lirc: implement scancode sending

[Sean Young]

This introduces a new lirc mode: scancode. Any device which can send raw IR
can also send scancodes.

int main()
{
int fd, mode, rc;
fd = open("/dev/lirc0", O_RDWR);

mode = LIRC_MODE_SCANCODE;
if (ioctl(fd, LIRC_SET_SEND_MODE, )) {
// kernel too old or lirc does not support transmit
}
struct lirc_scancode scancode {
.scancode = 0x1e3d,
.rc_type = RC_TYPE_RC5,
.flags = 0
};
write(fd, , sizeof(scancode));
close(fd);
}

Note that toggle (rc5, rc6) and repeats (nec) are not implemented. Nor is
there a method for holding down a key for a period.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 64 ++---
 drivers/media/rc/rc-core-priv.h  |  2 +-
 include/media/rc-map.h   | 54 +--
 include/uapi/linux/lirc.h| 68 
 4 files changed, 122 insertions(+), 66 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index d5d408c..762fa5e 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -96,6 +96,7 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, const 
char __user *buf,
struct lirc_codec *lirc;
struct rc_dev *dev;
unsigned int *txbuf; /* buffer with values to transmit */
+   struct ir_raw_event *raw = NULL;
ssize_t ret = -EINVAL;
size_t count;
ktime_t start;
@@ -109,16 +110,49 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
if (!lirc)
return -EFAULT;
 
-   if (n < sizeof(unsigned) || n % sizeof(unsigned))
-   return -EINVAL;
+   if (lirc->send_mode == LIRC_MODE_SCANCODE) {
+   struct lirc_scancode scan;
 
-   count = n / sizeof(unsigned);
-   if (count > LIRCBUF_SIZE || count % 2 == 0)
-   return -EINVAL;
+   if (n != sizeof(scan))
+   return -EINVAL;
+
+   if (copy_from_user(, buf, sizeof(scan)))
+   return -EFAULT;
+
+   if (scan.flags)
+   return -EINVAL;
+
+   raw = kmalloc_array(LIRCBUF_SIZE, sizeof(*raw), GFP_KERNEL);
+   if (!raw)
+   return -ENOMEM;
+
+   ret = ir_raw_encode_scancode(scan.rc_type, scan.scancode,
+raw, LIRCBUF_SIZE);
+   if (ret < 0)
+   goto out;
+
+   count = ret;
 
-   txbuf = memdup_user(buf, n);
-   if (IS_ERR(txbuf))
-   return PTR_ERR(txbuf);
+   txbuf = kmalloc_array(count, sizeof(unsigned int), GFP_KERNEL);
+   if (!txbuf) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   for (i = 0; i < count; i++)
+   txbuf[i] = DIV_ROUND_UP(raw[i].duration, 1000);
+   } else {
+   if (n < sizeof(unsigned int) || n % sizeof(unsigned int))
+   return -EINVAL;
+
+   count = n / sizeof(unsigned int);
+   if (count > LIRCBUF_SIZE || count % 2 == 0)
+   return -EINVAL;
+
+   txbuf = memdup_user(buf, n);
+   if (IS_ERR(txbuf))
+   return PTR_ERR(txbuf);
+   }
 
dev = lirc->dev;
if (!dev) {
@@ -147,7 +181,10 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
for (duration = i = 0; i < ret; i++)
duration += txbuf[i];
 
-   ret *= sizeof(unsigned int);
+   if (lirc->send_mode == LIRC_MODE_SCANCODE)
+   ret = n;
+   else
+   ret *= sizeof(unsigned int);
 
/*
 * The lircd gap calculation expects the write function to
@@ -162,6 +199,7 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, const 
char __user *buf,
 
 out:
kfree(txbuf);
+   kfree(raw);
return ret;
 }
 
@@ -195,15 +233,17 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
int cmd,
if (!dev->tx_ir)
return -ENOTTY;
 
-   val = LIRC_MODE_PULSE;
+   val = lirc->send_mode;
break;
 
case LIRC_SET_SEND_MODE:
if (!dev->tx_ir)
return -ENOTTY;
 
-   if (val != LIRC_MODE_PULSE)
+   if (!(val == LIRC_MODE_PULSE || val == LIRC_MODE_SCANCODE))
return -EINVAL;
+
+   lirc->send_mode = val;
return 0;
 
/* TX settings */
@@ -411,7 +451,7 @@ int ir_lirc_register(struct rc_dev *dev)
features |= LIRC_CAN_GET_REC_RESOLUTION;
}
if (dev->tx_ir) {
-   features 

[PATCH v2 10/19] [media] serial_ir: iommap is a memory address, not bool

[Sean Young]

This has been broken for a long time, so presumably it is not used. I
have no hardware to test this on.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=61401

Fixes: 90ab5ee ("module_param: make bool parameters really bool")

Signed-off-by: Sean Young 
---
 drivers/media/rc/serial_ir.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
index 923fb22..7b3a3b5 100644
--- a/drivers/media/rc/serial_ir.c
+++ b/drivers/media/rc/serial_ir.c
@@ -56,7 +56,7 @@ struct serial_ir_hw {
 static int type;
 static int io;
 static int irq;
-static bool iommap;
+static ulong iommap;
 static int ioshift;
 static bool softcarrier = true;
 static bool share_irq;
@@ -836,7 +836,7 @@ module_param(io, int, 0444);
 MODULE_PARM_DESC(io, "I/O address base (0x3f8 or 0x2f8)");
 
 /* some architectures (e.g. intel xscale) have memory mapped registers */
-module_param(iommap, bool, 0444);
+module_param(iommap, ulong, 0444);
 MODULE_PARM_DESC(iommap, "physical base for memory mapped I/O (0 = no memory 
mapped io)");
 
 /*
-- 
2.9.3

[PATCH v2 13/19] [media] lirc: use plain kfifo rather than lirc_buffer

[Sean Young]

Since a lirc char device can only be opened once, there can only be one
reader. By using a plain kfifo we don't need a spinlock and we can use
kfifo_to_user. The code is much simplified.

Unfortunately we cannot eliminate lirc_buffer from the tree yet, as there
are still some staging lirc drivers which use it.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 102 +--
 drivers/media/rc/lirc_dev.c  |   5 +-
 drivers/media/rc/rc-core-priv.h  |  26 ++
 3 files changed, 96 insertions(+), 37 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 78f354a..d5d408c 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -19,8 +19,6 @@
 #include 
 #include "rc-core-priv.h"
 
-#define LIRCBUF_SIZE 256
-
 /**
  * ir_lirc_raw_event() - Send raw IR data to lirc to be relayed to userspace
  *
@@ -32,10 +30,7 @@
 int ir_lirc_raw_event(struct rc_dev *dev, struct ir_raw_event ev)
 {
struct lirc_codec *lirc = >raw->lirc;
-   int sample;
-
-   if (!dev->raw->lirc.drv || !dev->raw->lirc.drv->rbuf)
-   return -EINVAL;
+   unsigned int sample;
 
/* Packet start */
if (ev.reset) {
@@ -70,10 +65,7 @@ int ir_lirc_raw_event(struct rc_dev *dev, struct 
ir_raw_event ev)
 
/* Normal sample */
} else {
-
if (lirc->gap) {
-   int gap_sample;
-
lirc->gap_duration += ktime_to_ns(ktime_sub(ktime_get(),
lirc->gap_start));
 
@@ -82,9 +74,7 @@ int ir_lirc_raw_event(struct rc_dev *dev, struct ir_raw_event 
ev)
lirc->gap_duration = min(lirc->gap_duration,
(u64)LIRC_VALUE_MASK);
 
-   gap_sample = LIRC_SPACE(lirc->gap_duration);
-   lirc_buffer_write(dev->raw->lirc.drv->rbuf,
-   (unsigned char *) _sample);
+   kfifo_put(>kfifo, LIRC_SPACE(lirc->gap_duration));
lirc->gap = false;
}
 
@@ -94,9 +84,8 @@ int ir_lirc_raw_event(struct rc_dev *dev, struct ir_raw_event 
ev)
   TO_US(ev.duration), TO_STR(ev.pulse));
}
 
-   lirc_buffer_write(dev->raw->lirc.drv->rbuf,
- (unsigned char *) );
-   wake_up(>raw->lirc.drv->rbuf->wait_poll);
+   kfifo_put(>kfifo, sample);
+   wake_up_poll(>wait_poll, POLLIN);
 
return 0;
 }
@@ -326,8 +315,64 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
return ret;
 }
 
+static unsigned int ir_lirc_poll(struct file *filep,
+struct poll_table_struct *wait)
+{
+   struct lirc_codec *lirc = lirc_get_pdata(filep);
+   unsigned int events = 0;
+
+   poll_wait(filep, >wait_poll, wait);
+
+   if (!lirc->drv->attached)
+   events = POLLERR;
+   else if (!kfifo_is_empty(>kfifo))
+   events = POLLIN | POLLRDNORM;
+
+   return events;
+}
+
+static ssize_t ir_lirc_read(struct file *filep, char __user *buffer,
+   size_t length, loff_t *ppos)
+{
+   struct lirc_codec *lirc = lirc_get_pdata(filep);
+   unsigned int copied;
+   int ret;
+
+   if (length % sizeof(unsigned int))
+   return -EINVAL;
+
+   if (!lirc->drv->attached)
+   return -ENODEV;
+
+   do {
+   if (kfifo_is_empty(>kfifo)) {
+   if (filep->f_flags & O_NONBLOCK)
+   return -EAGAIN;
+
+   ret = wait_event_interruptible(lirc->wait_poll,
+   !kfifo_is_empty(>kfifo) ||
+   !lirc->drv->attached);
+   if (ret)
+   return ret;
+   }
+
+   if (!lirc->drv->attached)
+   return -ENODEV;
+
+   ret = kfifo_to_user(>kfifo, buffer, length, );
+   if (ret)
+   return ret;
+   } while (copied == 0);
+
+   return copied;
+}
+
 static int ir_lirc_open(void *data)
 {
+   struct lirc_codec *lirc = data;
+
+   kfifo_reset_out(>kfifo);
+
return 0;
 }
 
@@ -343,8 +388,8 @@ static const struct file_operations lirc_fops = {
 #ifdef CONFIG_COMPAT
.compat_ioctl   = ir_lirc_ioctl,
 #endif
-   .read   = lirc_dev_fop_read,
-   .poll   = lirc_dev_fop_poll,
+   .read   = ir_lirc_read,
+   .poll   = ir_lirc_poll,
.open   = lirc_dev_fop_open,
.release= lirc_dev_fop_close,
.llseek = no_llseek,
@@ -353,21 +398,12 @@ static const struct file_operations lirc_fops = {
 int ir_lirc_register(struct rc_dev *dev)
 {

[PATCH v2 19/19] [media] lirc: document LIRC_MODE_SCANCODE

[Sean Young]

Lirc supports a new mode which requires documentation.

Signed-off-by: Sean Young 
---
 Documentation/media/uapi/rc/lirc-dev-intro.rst | 20 
 Documentation/media/uapi/rc/lirc-get-features.rst  | 15 +++
 Documentation/media/uapi/rc/lirc-get-rec-mode.rst  |  8 
 Documentation/media/uapi/rc/lirc-get-send-mode.rst |  5 +++--
 Documentation/media/uapi/rc/lirc-read.rst  |  6 ++
 Documentation/media/uapi/rc/lirc-write.rst |  8 
 6 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst 
b/Documentation/media/uapi/rc/lirc-dev-intro.rst
index 1250d4c..ed0706b 100644
--- a/Documentation/media/uapi/rc/lirc-dev-intro.rst
+++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst
@@ -36,6 +36,26 @@ LIRC modes
 LIRC supports some modes of receiving and sending IR codes, as shown
 on the following table.
 
+.. _lirc-mode-scancode:
+
+``LIRC_MODE_SCANCODE``
+
+This mode is for both sending and receiving IR.
+
+For transmitting (aka sending), create a ``struct lirc_scancode`` with
+the desired scancode set in the ``scancode`` member, ``rc_type`` set
+the IR protocol, and ``flags`` set to 0. Write this to the lirc device.
+
+For receiving, you read ``struct lirc_scancode`` from the lirc device,
+with ``scancode`` set to the received scancode in the IR protocol
+``rc_type``. The ``flags`` can have ``LIRC_SCANCODE_FLAG_TOGGLE`` set
+if the toggle bit is set in protocols that support it (e.g. rc-5 and rc-6),
+or ``LIRC_SCANCODE_FLAG_REPEAT`` for when a repeat is received for 
protocols
+that support it (e.g. nec).
+
+An ``enum rc_type`` in the :ref:`lirc_header` lists all the supported
+IR protocols.
+
 .. _lirc-mode-mode2:
 
 ``LIRC_MODE_MODE2``
diff --git a/Documentation/media/uapi/rc/lirc-get-features.rst 
b/Documentation/media/uapi/rc/lirc-get-features.rst
index 64f89a4..76bc99a 100644
--- a/Documentation/media/uapi/rc/lirc-get-features.rst
+++ b/Documentation/media/uapi/rc/lirc-get-features.rst
@@ -65,6 +65,14 @@ LIRC features
 The driver is capable of receiving using
 :ref:`LIRC_MODE_LIRCCODE `.
 
+.. _LIRC-CAN-REC-SCANCODE:
+
+``LIRC_CAN_REC_SCANCODE``
+
+The driver is capable of receiving using
+:ref:`LIRC_MODE_SCANCODE `.
+
+
 .. _LIRC-CAN-SET-SEND-CARRIER:
 
 ``LIRC_CAN_SET_SEND_CARRIER``
@@ -173,6 +181,13 @@ LIRC features
 The driver supports sending (also called as IR blasting or IR TX) using
 :ref:`LIRC_MODE_LIRCCODE `.
 
+.. _LIRC-CAN-SEND-SCANCODE:
+
+``LIRC_CAN_SEND_SCANCODE``
+
+The driver supports sending (also called as IR blasting or IR TX) using
+:ref:`LIRC_MODE_SCANCODE `.
+
 
 Return Value
 
diff --git a/Documentation/media/uapi/rc/lirc-get-rec-mode.rst 
b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
index a4eb6c0..221f093d 100644
--- a/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
+++ b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
@@ -33,10 +33,10 @@ Arguments
 Description
 ===
 
-Get/set supported receive modes. Only :ref:`LIRC_MODE_MODE2 `
-and :ref:`LIRC_MODE_LIRCCODE ` are supported for IR
-receive. Use :ref:`lirc_get_features` to find out which modes the driver
-supports.
+Get/set supported receive modes. Only :ref:`LIRC_MODE_MODE2 `,
+:ref:`LIRC_MODE_LIRCCODE ` and
+:ref:`LIRC_MODE_SCANCODE ` are supported for IR
+Use :ref:`lirc_get_features` to find out which modes the driver supports.
 
 Return Value
 
diff --git a/Documentation/media/uapi/rc/lirc-get-send-mode.rst 
b/Documentation/media/uapi/rc/lirc-get-send-mode.rst
index a169b23..be0992e 100644
--- a/Documentation/media/uapi/rc/lirc-get-send-mode.rst
+++ b/Documentation/media/uapi/rc/lirc-get-send-mode.rst
@@ -36,8 +36,9 @@ Description
 
 Get/set current transmit mode.
 
-Only :ref:`LIRC_MODE_PULSE ` and
-:ref:`LIRC_MODE_LIRCCODE ` is supported by for IR send,
+Only :ref:`LIRC_MODE_PULSE `,
+:ref:`LIRC_MODE_LIRCCODE ` and
+:ref:`LIRC_MODE_SCANCODE ` is supported by for IR send,
 depending on the driver. Use :ref:`lirc_get_features` to find out which
 modes the driver supports.
 
diff --git a/Documentation/media/uapi/rc/lirc-read.rst 
b/Documentation/media/uapi/rc/lirc-read.rst
index ffa2830..b4e5a56 100644
--- a/Documentation/media/uapi/rc/lirc-read.rst
+++ b/Documentation/media/uapi/rc/lirc-read.rst
@@ -54,6 +54,12 @@ The generally preferred mode for receive is
 in which packets containing an int value describing an IR signal are
 read from the chardev.
 
+Alternatively, :ref:`LIRC_MODE_SCANCODE ` might be 
available.
+Some hardware only produces scancodes so this might be the only available mode.
+In this mode, full decoded scancodes read from the chardev with their protocol
+information.
+
+
 Return Value
 
 
diff --git a/Documentation/media/uapi/rc/lirc-write.rst 
b/Documentation/media/uapi/rc/lirc-write.rst
index 6b44e0d..d3bb974 100644
--- 

[PATCH v2 02/19] [media] lirc: return ENOTTY when ioctl is not supported

[Sean Young]

We shouldn't be using ENOSYS when a feature is not available. I've tested
lirc; nothing is broken as far as I can make out.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 20 ++--
 drivers/media/rc/lirc_dev.c  |  2 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 8517d51..637b583 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -139,7 +139,7 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, const 
char __user *buf,
}
 
if (!dev->tx_ir) {
-   ret = -ENOSYS;
+   ret = -EINVAL;
goto out;
}
 
@@ -221,19 +221,19 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
int cmd,
/* TX settings */
case LIRC_SET_TRANSMITTER_MASK:
if (!dev->s_tx_mask)
-   return -ENOSYS;
+   return -ENOTTY;
 
return dev->s_tx_mask(dev, val);
 
case LIRC_SET_SEND_CARRIER:
if (!dev->s_tx_carrier)
-   return -ENOSYS;
+   return -ENOTTY;
 
return dev->s_tx_carrier(dev, val);
 
case LIRC_SET_SEND_DUTY_CYCLE:
if (!dev->s_tx_duty_cycle)
-   return -ENOSYS;
+   return -ENOTTY;
 
if (val <= 0 || val >= 100)
return -EINVAL;
@@ -243,7 +243,7 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
/* RX settings */
case LIRC_SET_REC_CARRIER:
if (!dev->s_rx_carrier_range)
-   return -ENOSYS;
+   return -ENOTTY;
 
if (val <= 0)
return -EINVAL;
@@ -265,32 +265,32 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
int cmd,
 
case LIRC_SET_WIDEBAND_RECEIVER:
if (!dev->s_learning_mode)
-   return -ENOSYS;
+   return -ENOTTY;
 
return dev->s_learning_mode(dev, !!val);
 
case LIRC_SET_MEASURE_CARRIER_MODE:
if (!dev->s_carrier_report)
-   return -ENOSYS;
+   return -ENOTTY;
 
return dev->s_carrier_report(dev, !!val);
 
/* Generic timeout support */
case LIRC_GET_MIN_TIMEOUT:
if (!dev->max_timeout)
-   return -ENOSYS;
+   return -ENOTTY;
val = DIV_ROUND_UP(dev->min_timeout, 1000);
break;
 
case LIRC_GET_MAX_TIMEOUT:
if (!dev->max_timeout)
-   return -ENOSYS;
+   return -ENOTTY;
val = dev->max_timeout / 1000;
break;
 
case LIRC_SET_REC_TIMEOUT:
if (!dev->max_timeout)
-   return -ENOSYS;
+   return -ENOTTY;
 
tmp = val * 1000;
 
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index a54ca53..ccbdce0 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -623,7 +623,7 @@ long lirc_dev_fop_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
result = put_user(ir->d.max_timeout, (__u32 __user *)arg);
break;
default:
-   result = -EINVAL;
+   result = -ENOTTY;
}
 
mutex_unlock(>irctl_lock);
-- 
2.9.3

[PATCH v2 00/19] Teach lirc how to send and receive scancodes

[Sean Young]

This patch series has some general cleanup work, then the lirc scancode
interface (v2) and lirc documentation fixes. The cleanups are needed for
the new scancode interface.

lirc already supports LIRC_MODE_LIRCCODE, but that mode is entirely
driver dependant and makes no provision for protocol information.

Receiving LIRC_MODE_SCANCODE

If a lirc device has the LIRC_CAN_REC_SCANCODE feature, LIRC_MODE_SCANCODE
can be set set using LIRC_SET_REC_MODE ioctl. Now when you read from the
device you receive struct lirc_scancode. In this structure you have
the scancode, rc_type, and flags. RC_TYPE_* is now in uapi, so now you
can see exactly which protocol variant was used. flags might contain
LIRC_SCANCODE_FLAGS_TOGGLE (rc5, rc6) or LIRC_SCANCODE_FLAGS_REPEAT (nec).

Using this interface, you can see what IR protocol a remote is using. This
was not easy to do before.

Sending LIRC_MODE_SCANCODE
--
If a lirc device has the LIRC_CAN_SEND_SCANCODE features, LIRC_MODE_SCANCODE
can be set using the LIRC_SET_SEND_MODE ioctl. Now you can write
struct lirc_scancode. flags should be 0, rc_type to the RC_TYPE_* and
the scancode must be set. You can only tranmsit one lirc_scancode at a time.

This interface uses the in-kernel IR encoders to work. Using this interface
it will be possible to port lirc_zilog to rc-core. This device cannot send
raw IR, so it will not use the IR encoders but provide the same userspace
interface.

Other user-visible changes
--
Now all RC devices will have a lirc char device, including devices which
do not produce raw IR. They will be fixed in mode LIRC_MODE_SCANCODE.

Changes v1 -> v2:
 - changed the scancode to 64 bit. There are many IR protocols which encode
   more than 32 bits; we don't support any at the moment but might as 
   well future-proof it
   http://www.hifi-remote.com/wiki/index.php?title=DecodeIR
 - Various small fixes.
 - Added documentation

Sean Young (19):
  [media] lirc: document lirc modes better
  [media] lirc: return ENOTTY when ioctl is not supported
  [media] lirc: return ENOTTY when device does support ioctl
  [media] winbond: allow timeout to be set
  [media] gpio-ir: do not allow a timeout of 0
  [media] rc: lirc keymap no longer makes any sense
  [media] lirc: advertise LIRC_CAN_GET_REC_RESOLUTION and improve
  [media] lirc: use refcounting for lirc devices
  [media] mce_kbd: add encoder
  [media] serial_ir: iommap is a memory address, not bool
  [media] lirc: lirc interface should not be a raw decoder
  [media] lirc: exorcise struct irctl
  [media] lirc: use plain kfifo rather than lirc_buffer
  [media] lirc: implement scancode sending
  [media] rc: use the correct carrier for scancode transmit
  [media] rc: auto load encoder if necessary
  [media] lirc: implement reading scancode
  [media] lirc: scancode rc devices should have a lirc device too
  [media] lirc: document LIRC_MODE_SCANCODE

 Documentation/media/uapi/rc/lirc-dev-intro.rst |  73 +++-
 Documentation/media/uapi/rc/lirc-get-features.rst  |  28 +-
 Documentation/media/uapi/rc/lirc-get-length.rst|   3 +-
 Documentation/media/uapi/rc/lirc-get-rec-mode.rst  |   8 +-
 Documentation/media/uapi/rc/lirc-get-send-mode.rst |   8 +-
 Documentation/media/uapi/rc/lirc-read.rst  |  22 +-
 .../media/uapi/rc/lirc-set-rec-carrier-range.rst   |   2 +-
 Documentation/media/uapi/rc/lirc-write.rst |  25 +-
 drivers/media/rc/Kconfig   |  15 +-
 drivers/media/rc/Makefile  |   6 +-
 drivers/media/rc/gpio-ir-recv.c|   2 +-
 drivers/media/rc/igorplugusb.c |   2 +-
 drivers/media/rc/ir-jvc-decoder.c  |   1 +
 drivers/media/rc/ir-lirc-codec.c   | 361 ++---
 drivers/media/rc/ir-mce_kbd-decoder.c  |  57 ++-
 drivers/media/rc/ir-nec-decoder.c  |   1 +
 drivers/media/rc/ir-rc5-decoder.c  |   1 +
 drivers/media/rc/ir-rc6-decoder.c  |   1 +
 drivers/media/rc/ir-sanyo-decoder.c|   1 +
 drivers/media/rc/ir-sharp-decoder.c|   1 +
 drivers/media/rc/ir-sony-decoder.c |   1 +
 drivers/media/rc/keymaps/Makefile  |   1 -
 drivers/media/rc/keymaps/rc-lirc.c |  42 --
 drivers/media/rc/lirc_dev.c| 431 +
 drivers/media/rc/rc-core-priv.h|  56 ++-
 drivers/media/rc/rc-ir-raw.c   |  55 ++-
 drivers/media/rc/rc-main.c |  77 ++--
 drivers/media/rc/serial_ir.c   |   4 +-
 drivers/media/rc/st_rc.c   |   2 +-
 drivers/media/rc/winbond-cir.c |   4 +-
 drivers/staging/media/lirc/lirc_sasem.c|   3 +-
 drivers/staging/media/lirc/lirc_zilog.c| 109 +++---
 include/media/lirc_dev.h   

[PATCH v2 03/19] [media] lirc: return ENOTTY when device does support ioctl

[Sean Young]

If timeouts or carrier range is not supported, return proper error.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 637b583..235d74a 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -253,6 +253,9 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
   val);
 
case LIRC_SET_REC_CARRIER_RANGE:
+   if (!dev->s_rx_carrier_range)
+   return -ENOTTY;
+
if (val <= 0)
return -EINVAL;
 
@@ -305,6 +308,9 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
break;
 
case LIRC_SET_REC_TIMEOUT_REPORTS:
+   if (!dev->timeout)
+   return -ENOTTY;
+
lirc->send_timeout_reports = !!val;
break;
 
-- 
2.9.3

[PATCH v2 04/19] [media] winbond: allow timeout to be set

[Sean Young]

The drivers sets the hardware to idle when a timeout occurs. This can
be any reasonable value.

Signed-off-by: Sean Young 
---
 drivers/media/rc/winbond-cir.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index dc1c830..5a4d4a6 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1082,7 +1082,9 @@ wbcir_probe(struct pnp_dev *device, const struct 
pnp_device_id *dev_id)
data->dev->tx_ir = wbcir_tx;
data->dev->priv = data;
data->dev->dev.parent = >dev;
-   data->dev->timeout = MS_TO_NS(100);
+   data->dev->min_timeout = 1;
+   data->dev->timeout = IR_DEFAULT_TIMEOUT;
+   data->dev->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
data->dev->rx_resolution = US_TO_NS(2);
data->dev->allowed_protocols = RC_BIT_ALL_IR_DECODER;
data->dev->allowed_wakeup_protocols = RC_BIT_NEC | RC_BIT_NECX |
-- 
2.9.3

[PATCH v2 05/19] [media] gpio-ir: do not allow a timeout of 0

[Sean Young]

According to the documentation, a timeout of 0 turns off timeouts,
which is not the case.

Signed-off-by: Sean Young 
---
 drivers/media/rc/gpio-ir-recv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 4a4895e..b4f773b 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -158,7 +158,7 @@ static int gpio_ir_recv_probe(struct platform_device *pdev)
rcdev->input_id.version = 0x0100;
rcdev->dev.parent = >dev;
rcdev->driver_name = GPIO_IR_DRIVER_NAME;
-   rcdev->min_timeout = 0;
+   rcdev->min_timeout = 1;
rcdev->timeout = IR_DEFAULT_TIMEOUT;
rcdev->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
if (pdata->allowed_protos)
-- 
2.9.3

[PATCH v2 06/19] [media] rc: lirc keymap no longer makes any sense

[Sean Young]

The lirc keymap existed once upon a time to select the lirc protocol.
Since '275ddb4 [media] rc-core: remove the LIRC "protocol"', IR is
always passed to the lirc decoder so this keymap is no longer needed.

Signed-off-by: Sean Young 
---
 drivers/media/rc/keymaps/Makefile  |  1 -
 drivers/media/rc/keymaps/rc-lirc.c | 42 --
 drivers/media/rc/st_rc.c   |  2 +-
 include/media/rc-map.h |  1 -
 4 files changed, 1 insertion(+), 45 deletions(-)
 delete mode 100644 drivers/media/rc/keymaps/rc-lirc.c

diff --git a/drivers/media/rc/keymaps/Makefile 
b/drivers/media/rc/keymaps/Makefile
index ffe9e61..2945f99 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -57,7 +57,6 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-kworld-pc150u.o \
rc-kworld-plus-tv-analog.o \
rc-leadtek-y04g0051.o \
-   rc-lirc.o \
rc-lme2510.o \
rc-manli.o \
rc-medion-x10.o \
diff --git a/drivers/media/rc/keymaps/rc-lirc.c 
b/drivers/media/rc/keymaps/rc-lirc.c
deleted file mode 100644
index e172f5d..000
--- a/drivers/media/rc/keymaps/rc-lirc.c
+++ /dev/null
@@ -1,42 +0,0 @@
-/* rc-lirc.c - Empty dummy keytable, for use when its preferred to pass
- * all raw IR data to the lirc userspace decoder.
- *
- * Copyright (c) 2010 by Jarod Wilson 
- *
- * 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.
- */
-
-#include 
-#include 
-
-static struct rc_map_table lirc[] = {
-   { },
-};
-
-static struct rc_map_list lirc_map = {
-   .map = {
-   .scan= lirc,
-   .size= ARRAY_SIZE(lirc),
-   .rc_type = RC_TYPE_OTHER,
-   .name= RC_MAP_LIRC,
-   }
-};
-
-static int __init init_rc_map_lirc(void)
-{
-   return rc_map_register(_map);
-}
-
-static void __exit exit_rc_map_lirc(void)
-{
-   rc_map_unregister(_map);
-}
-
-module_init(init_rc_map_lirc)
-module_exit(exit_rc_map_lirc)
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Jarod Wilson ");
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index f0d7190..6228d93 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -298,7 +298,7 @@ static int st_rc_probe(struct platform_device *pdev)
rdev->open = st_rc_open;
rdev->close = st_rc_close;
rdev->driver_name = IR_ST_NAME;
-   rdev->map_name = RC_MAP_LIRC;
+   rdev->map_name = RC_MAP_EMPTY;
rdev->input_name = "ST Remote Control Receiver";
 
ret = rc_register_device(rdev);
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index a704749..878d852 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -255,7 +255,6 @@ struct rc_map *rc_map_get(const char *name);
 #define RC_MAP_KWORLD_PC150U "rc-kworld-pc150u"
 #define RC_MAP_KWORLD_PLUS_TV_ANALOG "rc-kworld-plus-tv-analog"
 #define RC_MAP_LEADTEK_Y04G0051  "rc-leadtek-y04g0051"
-#define RC_MAP_LIRC  "rc-lirc"
 #define RC_MAP_LME2510   "rc-lme2510"
 #define RC_MAP_MANLI "rc-manli"
 #define RC_MAP_MEDION_X10"rc-medion-x10"
-- 
2.9.3

[PATCH v2 01/19] [media] lirc: document lirc modes better

[Sean Young]

LIRC_MODE_MODE2 and LIRC_MODE_LIRCCODE were not covered at all.

Signed-off-by: Sean Young 
---
 Documentation/media/uapi/rc/lirc-dev-intro.rst | 53 +++---
 Documentation/media/uapi/rc/lirc-get-features.rst  | 13 --
 Documentation/media/uapi/rc/lirc-get-length.rst|  3 +-
 Documentation/media/uapi/rc/lirc-get-rec-mode.rst  |  4 +-
 Documentation/media/uapi/rc/lirc-get-send-mode.rst |  7 ++-
 Documentation/media/uapi/rc/lirc-read.rst  | 18 
 .../media/uapi/rc/lirc-set-rec-carrier-range.rst   |  2 +-
 Documentation/media/uapi/rc/lirc-write.rst | 19 +---
 8 files changed, 84 insertions(+), 35 deletions(-)

diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst 
b/Documentation/media/uapi/rc/lirc-dev-intro.rst
index ef97e40..1250d4c 100644
--- a/Documentation/media/uapi/rc/lirc-dev-intro.rst
+++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst
@@ -27,6 +27,8 @@ What you should see for a chardev:
 $ ls -l /dev/lirc*
 crw-rw 1 root root 248, 0 Jul 2 22:20 /dev/lirc0
 
+.. _lirc_modes:
+
 **
 LIRC modes
 **
@@ -38,25 +40,62 @@ on the following table.
 
 ``LIRC_MODE_MODE2``
 
-The driver returns a sequence of pulse and space codes to userspace.
+The driver returns a sequence of pulse and space codes to userspace,
+as a series of u32 values.
 
 This mode is used only for IR receive.
 
+The upper 8 bits determine the packet type, and the lower 24 bits
+the payload. Use ``LIRC_VALUE()`` macro to get the payload, and
+the macro ``LIRC_MODE2()`` will give you the type, which
+is one of:
+
+``LIRC_MODE2_PULSE``
+
+Signifies the presence of IR in microseconds.
+
+``LIRC_MODE2_SPACE``
+
+Signifies absence of IR in microseconds.
+
+``LIRC_MODE2_FREQUENCY``
+
+If measurement of the carrier frequency was enabled with
+:ref:`lirc_set_measure_carrier_mode` then this packet gives you
+the carrier frequency in Hertz.
+
+``LIRC_MODE2_TIMEOUT``
+
+If timeout reports are enabled with
+:ref:`lirc_set_rec_timeout_reports`, when the timeout set with
+:ref:`lirc_set_timeout` expires due to no IR being detected,
+this packet will be sent, with the number of microseconds with
+no IR.
+
 .. _lirc-mode-lirccode:
 
 ``LIRC_MODE_LIRCCODE``
 
-The IR signal is decoded internally by the receiver. The LIRC interface
-returns the scancode as an integer value. This is the usual mode used
-by several TV media cards.
+This mode can be used for IR receive and send.
 
-This mode is used only for IR receive.
+The IR signal is decoded internally by the receiver, or encoded by the
+transmitter. The LIRC interface represents the scancode as byte string,
+which might not be a u32, it can be any length. The value is entirely
+driver dependent. This mode is used by some older lirc drivers.
+
+The length of each code depends on the driver, which can be retrieved
+with :ref:`lirc_get_length`. This length is used both
+for transmitting and receiving IR.
 
 .. _lirc-mode-pulse:
 
 ``LIRC_MODE_PULSE``
 
-On puse mode, a sequence of pulse/space integer values are written to the
-lirc device using :Ref:`lirc-write`.
+In pulse mode, a sequence of pulse/space integer values are written to the
+lirc device using :ref:`lirc-write`.
+
+The values are alternating pulse and space lengths, in microseconds. The
+first and last entry must be a pulse, so there must be an odd number
+of entries.
 
 This mode is used only for IR send.
diff --git a/Documentation/media/uapi/rc/lirc-get-features.rst 
b/Documentation/media/uapi/rc/lirc-get-features.rst
index 79e07b4..64f89a4 100644
--- a/Documentation/media/uapi/rc/lirc-get-features.rst
+++ b/Documentation/media/uapi/rc/lirc-get-features.rst
@@ -48,8 +48,8 @@ LIRC features
 
 ``LIRC_CAN_REC_PULSE``
 
-The driver is capable of receiving using
-:ref:`LIRC_MODE_PULSE `.
+Unused. Kept just to avoid breaking uAPI.
+:ref:`LIRC_MODE_PULSE ` can only be used for transmitting.
 
 .. _LIRC-CAN-REC-MODE2:
 
@@ -156,19 +156,22 @@ LIRC features
 
 ``LIRC_CAN_SEND_PULSE``
 
-The driver supports sending using :ref:`LIRC_MODE_PULSE `.
+The driver supports sending (also called as IR blasting or IR TX) using
+:ref:`LIRC_MODE_PULSE `.
 
 .. _LIRC-CAN-SEND-MODE2:
 
 ``LIRC_CAN_SEND_MODE2``
 
-The driver supports sending using :ref:`LIRC_MODE_MODE2 `.
+Unused. Kept just to avoid breaking uAPI.
+:ref:`LIRC_MODE_MODE2 ` can only be used for receiving.
 
 .. _LIRC-CAN-SEND-LIRCCODE:
 
 ``LIRC_CAN_SEND_LIRCCODE``
 
-The driver supports sending codes (also called as IR blasting or IR TX).
+The driver supports sending (also called as IR blasting or IR TX) using
+:ref:`LIRC_MODE_LIRCCODE `.
 
 
 Return Value
diff --git a/Documentation/media/uapi/rc/lirc-get-length.rst 

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Vladimir Zapolskiy]

Hi Ramiro,

On 02/21/2017 06:42 PM, Ramiro Oliveira wrote:
> Hi Vladimir,
> 
> Thank you for your feedback
> 
> On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> please find some review comments below.
>>
>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>>
>>> The driver adds support for 640x480 RAW 8.
>>>
>>> Signed-off-by: Ramiro Oliveira 
>>> ---
>>
>> [snip]
>>
>>> +
>>> +struct ov5647 {
>>> +   struct v4l2_subdev  sd;
>>> +   struct media_padpad;
>>> +   struct mutexlock;
>>> +   struct v4l2_mbus_framefmt   format;
>>> +   unsigned intwidth;
>>> +   unsigned intheight;
>>> +   int power_count;
>>> +   struct clk  *xclk;
>>> +   /* External clock frequency currently supported is 30MHz */
>>> +   u32 xclk_freq;
>>
>> See a comment about 25MHz vs 30MHz below.
>>
>> Also I assume you can remove 'xclk_freq' from the struct fields,
>> it can be replaced by a local variable.
>>
> 
> I'll do that.
> 
>>> +};
>>
>> [snip]
>>
>>> +
>>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>>> +{
>>> +   int ret;
>>> +   unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>>> +   struct i2c_client *client = v4l2_get_subdevdata(sd);
>>> +
>>> +   ret = i2c_master_send(client, data_w, 2);
>>> +   if (ret < 0) {
>>> +   dev_dbg(>dev, "%s: i2c read error, reg: %x\n",
>>
>> s/i2c read error/i2c write error/
>>
> 
> I'm not sure I understand what you mean.

That's a sed expression for string substitution. Here you do i2c_master_send()
but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to 
fix.

>>> +   __func__, reg);
>>> +   return ret;
>>> +   }
>>> +

[snip]

>>> +
>>> +static int sensor_power(struct v4l2_subdev *sd, int on)

On the caller's side (functions ov5647_open() and ov5647_close()) the second
argument of the function is of 'bool' type, however .s_power callback from
struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as
'int'.

It's just a nitpicking, please feel free to ignore the comment above or
please consider to change the arguments on callers' side to integers.

Also you may consider to add 'ov5647_' prefix to the function name to
distinguish it from a potentially added in future sensor_power() function,
the original name sounds too generic.

>>> +{
>>> +   int ret;
>>> +   struct ov5647 *ov5647 = to_state(sd);
>>> +   struct i2c_client *client = v4l2_get_subdevdata(sd);
>>> +
>>> +   ret = 0;
>>> +   mutex_lock(>lock);
>>> +
>>> +   if (on && !ov5647->power_count) {
>>> +   dev_dbg(>dev, "OV5647 power on\n");
>>> +
>>> +   clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
>>
>> Now clk_set_rate() is redundant, please remove it.
>>
>> If once it is needed again, please move it to the .probe function, so
>> it is called only once in the runtime.
>>
> 
> Ok. I'll remove it for now.
> 
>>> +
>>> +   ret = clk_prepare_enable(ov5647->xclk);
>>
>> I wonder would it be possible to unload the driver or to unbind the device
>> and leave the clock unintentionally enabled? If yes, then this is a bug.
>>
> 
> You're saying that if the driver was unloaded and the clock was left enabled
> when the driver was loaded again this line would cause an error?

Not exactly, here I saw a potential resource leak, namely a potentially left
prepared/enabled clock.

> 
> Should I disable the clock when the driver is removed?
> 

The driver (and framework) shall guarantee that when it is detached from
device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device),
all acquired resources are released.

But in this particular case most probably I've been overly alert, I believe
that V4L2 framework correcly handles device power states, so please ignore my
comment.

To add something valuable to the review, could you please confirm that
ov5647_subdev_internal_ops data is in use by the driver?

E.g. shouldn't it be registered by

  sd->internal_ops = _subdev_internal_ops;

before calling v4l2_async_register_subdev(sd) ?

--
With best wishes,
Vladimir

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Vladimir,

Thank you for your feedback

On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>> Create device tree bindings documentation.
>>
>> Signed-off-by: Ramiro Oliveira 
>> Acked-by: Rob Herring 
>> ---
>>  .../devicetree/bindings/media/i2c/ov5647.txt   | 35 
>> ++
>>  1 file changed, 35 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt 
>> b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> new file mode 100644
>> index ..31956426d3b9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> @@ -0,0 +1,35 @@
>> +Omnivision OV5647 raw image sensor
>> +-
>> +
>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>> +and CCI (I2C compatible) control bus.
>> +
>> +Required properties:
>> +
>> +- compatible: "ovti,ov5647".
>> +- reg   : I2C slave address of the sensor.
>> +- clocks: Reference to the xclk clock.
> 
> Is "xclk" clock a pixel clock or something else?
> 

It's an external oscillator.

>> +- clock-names   : Should be "xclk".
> 
> You can remove this property, because there is only one source clock.
> 

Ok.

>> +- clock-frequency   : Frequency of the xclk clock.
> 
> And after the last updates in the driver this property can be removed as well.
> 

But I'm still using clk_get_rate in the driver, if I remove the frequency here
the probing will fail.

>> +
>> +The common video interfaces bindings (see video-interfaces.txt) should be
>> +used to specify link to the image data receiver. The OV5647 device
>> +node should contain one 'port' child node with an 'endpoint' subnode.
>> +
>> +Example:
>> +
>> +i2c@2000 {
>> +...
>> +ov: camera@36 {
>> +compatible = "ovti,ov5647";
>> +reg = <0x36>;
>> +clocks = <_clk>;
>> +clock-names = "xclk";
>> +clock-frequency = <2500>;
> 
> When you remove two unused properties, please don't forget to update the
> example.
> 

Ok.

>> +port {
>> +camera_1: endpoint {
>> +remote-endpoint = <_ep1>;
>> +};
>> +};
>> +};
>> +};
>>
> 
> --
> With best wishes,
> Vladimir
> 

-- 
Best Regards

Ramiro Oliveira
ramiro.olive...@synopsys.com

Re: Bug: decoders referenced in kernel rc-keymaps not loaded on boot

[Sean Young]

On Tue, Feb 21, 2017 at 07:49:29PM +0100, Matthias Reichl wrote:
> There seems to be a bug in on-demand loading of IR protocol decoders.
> 
> After bootup the protocol referenced in the in-kernel rc keymap shows
> up as enabled (in sysfs and ir-keytable) but the protocol decoder
> is not loaded and thus no rc input events will be generated.
> 
> For example, RPi3 with kernel 4.10 and gpio-ir-recv configured to use
> the rc-hauppauge keymap in devicetree:
> 
> # lsmod | grep '^\(ir\|rc_\)'
> ir_lirc_codec   5590  0
> rc_hauppauge2422  0
> rc_core24320  5 
> rc_hauppauge,ir_lirc_codec,lirc_dev,gpio_ir_recv
> 
> # cat /sys/class/rc/rc0/protocols
> other unknown [rc-5] nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp cec 
> [lirc]
> 
> # dmesg | grep "IR "
> [4.506728] Registered IR keymap rc-hauppauge
> [4.554651] lirc_dev: IR Remote Control driver registered, major 242
> [4.576490] IR LIRC bridge handler initialized
> 
> The same happens with other IR receivers, eg the streamzap receiver,
> which uses the rc-5-sz protocol / ir_rc5_decoder, on x86.
> 
> Reverting the on-demand-loading patches
> 
> [media] media: rc: remove unneeded code
> commit c1500ba0b61e9abf95e0e7ecd3c4ad877f019abe
> 
> [media] media: rc: move check whether a protocol is enabled to the core
> commit d80ca8bd71f0b01b2b12459189927cb3299cfab9
> 
> [media] media: rc: load decoder modules on-demand
> commit acc1c3c688ed8cc862ddc007eab0dcef839f4ec8
> 
> restores the previous behaviour, all decoders are enabled and IR
> events can be generated immediately after boot without having to
> manually trigger loading of a protocol decoder.

Hmm this seems to be working fine for me. If you write to the protocols
file, eg. "echo +nec > /sys/class/rc/rc0/protocols", is ir-nec-decoder
loaded and do you get any messages in dmesg (you should).

What's your config?

Thanks,
Sean

Re: Cine CT V6.1 code change request

[Martin Herrman]

2017-02-19 14:27 GMT+01:00 Daniel Scheller :
>
> Hi Martin,
>
> For someone who has some knowledge on the stv0367 demods, it's probably
> not very hard.
>
> While I don't have that knowledge, I've started tackling
> the "in-kernel" stv0367 module to work as a replacement for DD's
> stv0367dd anyway, and while I didn't get very far yet, this is what I
> found out so far:
>
> - stv0367dd always provides multiple delivery systems (DVB-C, DVB-T)
>   when attached, where stv0367 needs multiple frontends for each
>   delivery systems, e.g. you need to attach the -T and -C
>   frontends separately. Basically, this is also the case in the
>   stv0367dd, but it has some sort of "wrapper" ontop which does the
>   QAM/OFDM operation mode switch transparently.
> - When attaching only one of the two -T/-C code paths, there's still
>   something more that needs to be done. With the QAM path, I got the
>   demod to somewhat do some work (it reported signal statistics when
>   tuned to a frequency) but didn't properly send the transport stream
>   to the bridge.
> - stv0367dd runs at 58MHz IC speed for the QAM mode, but this is rather
>   easy to add since (what I could find out so far) it just requires
>   different values poked into the PLLxDIV regs.
> - The i2c_gate_ctrl() in stv0367 must not be called from inside the
>   demod driver (thinking of a config flag to toggle this) since
>   ddbridge remaps the function pointers to a mutex_lock'ed variant,
>   which in turn will cause a deadlock when the demod driver triggers
>   the i2c_gate itself.
>
> The biggest problem at the moment is 2., e.g. get the transport to the
> bridge working. 1. should be fairly easy to do, 3. and 4. are done. See
> [1] for my attempt on this. But generally speaking, the stv0367 driver
> should work even with DD cards with a few additions.
>
> The TDA18212 "in-tree" tuner frontend works perfectly with the STV and
> also the CXD28xx-based tuners. The work on this was done in around 2013
> or so by Antti Palosaari (see [2]), and it worked out so nicely when I
> first started tackling things I never cared to pick up the
> tda18212DD :-)
>
> Best regards,
> Daniel Scheller
>
> [1]
> https://github.com/herrnst/dddvb-linux-kernel/compare/attic/old-0_9_23-0_9_28-mediatree/master-ddbridge-cttesting-cxd...attic/old-0_9_23-0_9_28-mediatree/master-ddbridge-cttesting-stv
> [2]
> https://github.com/herrnst/dddvb-linux-kernel/commit/905c999f69e58e2c54be24bd7ec6c86ec2ef1e65

Hi Daniel,

Thanks for starting this investigation! If I'm understanding
correctly, there is some work to do, but it can be done and is not a
huge amount of work. (But it is more than just moving something from
the old repo and fixing some errors/warnings.)

I'm not familiar with the linux-media way of organizing the work, or
how priorities are set (on the backlog?). What should be the next step
and what can I do to have this feature/enhancement picked up? I'm not
a developer, but I own the hardware and thus I am able to test any new
code. If there might anything else I can do, please let me know.

Thanks,

Martin

[PATCH v5 3/3] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

[Thibault Saunier]

It is required by the standard that the field order is set by the
driver.

Signed-off-by: Thibault Saunier 

---

Changes in v5:
- Just adapt the field and never error out.

Changes in v4: None
Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 0976c3e0a5ce..44ed2afe0780 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -386,6 +386,9 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
 
+   if (f->fmt.pix.field == V4L2_FIELD_ANY)
+   f->fmt.pix.field = V4L2_FIELD_NONE;
+
mfc_debug(2, "Type is %d\n", f->type);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
fmt = find_format(f, MFC_FMT_DEC);
-- 
2.11.1

[PATCH v5 2/3] [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT if DEFAULT provided

[Thibault Saunier]

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver
didn't set the colorimetry when userspace provided
V4L2_COLORSPACE_DEFAULT.

Use 576p display resolution as a threshold to set this as suggested by
EIA CEA 861B.

Signed-off-by: Thibault Saunier 

---

Changes in v5: None
Changes in v4:
- Set the colorspace only if the user passed V4L2_COLORSPACE_DEFAULT, in
  all other cases just use what userspace provided.

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in

Changes in v2: None

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 367ef8e8dbf0..0976c3e0a5ce 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -354,6 +354,11 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
pix_mp->plane_fmt[0].sizeimage = ctx->luma_size;
pix_mp->plane_fmt[1].bytesperline = ctx->buf_width;
pix_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
+
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
/* This is run on OUTPUT
   The buffer contains compressed image
@@ -378,6 +383,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
 static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 {
struct s5p_mfc_dev *dev = video_drvdata(file);
+   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct s5p_mfc_fmt *fmt;
 
mfc_debug(2, "Type is %d\n", f->type);
@@ -405,6 +411,14 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
mfc_err("Unsupported format by this MFC version.\n");
return -EINVAL;
}
+
+   if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
+   if (pix_mp->width > 720 &&
+   pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
}
 
return 0;
-- 
2.11.1

[PATCH v5 1/3] [media] exynos-gsc: Use user configured colorspace if provided

[Thibault Saunier]

Use colorspace provided by the user as we are only doing scaling and
color encoding conversion, we won't be able to transform the colorspace
itself and the colorspace won't mater in that operation.

Also always use output colorspace on the capture side.

Start using 576p as a threashold to compute the colorspace.
The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

>From EIA CEA 861B about colorimetry for various resolutions:

  - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
The color space used by the 480-line, 576-line, 240-line, and 288-line
formats will likely be based on SMPTE 170M [1].
  - 5.2 1080i, 1080p, and 720p
The color space used by the high definition formats will likely be
based on ITU-R BT.709-4

This indicates that in the case that userspace does not specify what
colorspace should be used, we should use 576p  as a threshold to set
V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_SMPTE170M. Even if it is
only 'likely' and not a requirement it is the best guess we can make.

The stream should have been encoded with the information and userspace
has to pass it to the driver if it is not the case, otherwise we won't be
able to handle it properly anyhow.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Thibault Saunier 
Reviewed-by: Andrzej Hajda 

---

Changes in v5:
- Squash commit to always use output colorspace on the capture side
  inside this one
- Fix typo in commit message

Changes in v4:
- Reword commit message to better back our assumptions on specifications

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda '

Changes in v2: None

 drivers/media/platform/exynos-gsc/gsc-core.c | 20 +++-
 drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..772599de8c13 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
} else {
min_w = variant->pix_min->target_rot_dis_w;
min_h = variant->pix_min->target_rot_dis_h;
+   pix_mp->colorspace = ctx->out_colorspace;
}
 
pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d",
@@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
 
pix_mp->num_planes = fmt->num_planes;
 
-   if (pix_mp->width >= 1280) /* HD */
-   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-   else /* SD */
-   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+   }
+
+   if (V4L2_TYPE_IS_OUTPUT(f->type))
+   ctx->out_colorspace = pix_mp->colorspace;
 
for (i = 0; i < pix_mp->num_planes; ++i) {
struct v4l2_plane_pix_format *plane_fmt = _mp->plane_fmt[i];
@@ -519,9 +525,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height  = frame->f_height;
pix_mp->field   = V4L2_FIELD_NONE;
pix_mp->pixelformat = frame->fmt->pixelformat;
-   pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
pix_mp->num_planes  = frame->fmt->num_planes;
 
+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+
for (i = 0; i < pix_mp->num_planes; ++i) {
pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
frame->fmt->depth[i]) / 8;
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h 
b/drivers/media/platform/exynos-gsc/gsc-core.h
index 696217e9af66..715d9c9d8d30 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -376,6 +376,7 @@ struct gsc_ctx {
struct v4l2_ctrl_handler ctrl_handler;
struct gsc_ctrlsgsc_ctrls;
boolctrls_rdy;
+   enum v4l2_colorspace out_colorspace;
 };
 
 void gsc_set_prefbuf(struct gsc_dev 

[PATCH v5 0/3] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers

[Thibault Saunier]

Hello,

This patchset fixes a few issues on the colorspace logic for the exynos-gsc
and s5p-mfc drivers.

We now handle the colorspace in those drivers, and make sure to respect user 
setting if
possible.

We also now set the 'v4l2_pix_format:field' if userspace passed ANY, avoiding 
GStreamer
spamming error at us about the driver not following the standard.

This is the fifth version of the patch serie.

Best regards,

Thibault Saunier

Changes in v5:
- Squash commit to always use output colorspace on the capture side
  inside this one
- Fix typo in commit message
- Just adapt the field and never error out.

Changes in v4:
- Reword commit message to better back our assumptions on specifications
- Set the colorspace only if the user passed V4L2_COLORSPACE_DEFAULT, in
  all other cases just use what userspace provided.

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda '
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

Thibault Saunier (3):
  [media] exynos-gsc: Use user configured colorspace if provided
  [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT if DEFAULT
provided
  [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in
try_fmt

 drivers/media/platform/exynos-gsc/gsc-core.c | 20 +++-
 drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 17 +
 3 files changed, 33 insertions(+), 5 deletions(-)

-- 
2.11.1

Re: [PATCH v4 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Thibault Saunier]

Hello Andrzej,

On 02/21/2017 06:56 AM, Andrzej Hajda wrote:

On 13.02.2017 20:08, Thibault Saunier wrote:

From: Javier Martinez Canillas 

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

>From EIA CEA 861B about colorimetry for various resolutions:

   - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
 The color space used by the 480-line, 576-line, 240-line, and 288-line
 formats will likely be based on SMPTE 170M [1].
   - 5.2 1080i, 1080p, and 720p
 The color space used by the high definition formats will likely be
 based on ITU-R BT.709-4

This indicates that in the case that userspace does not specify what
colorspace should be used, we should use 576p  as a threshold to set
V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_REC709. Even if it is
only 'likely' and not a requirement it is the best guess we can make.

The stream should have been encoded with the information and userspace
has to pass it to the driver if it is not the case, otherwise we won't be
able to handle it properly anyhow.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Thibault Saunier 
Reviewed-by: Andrzej Hajda 

Hi Thibault,

Have you analyzed Hans response for the previous patchset [1] ?
I am not an expert in the subject but it seems he is right. GSCALER
datasheet uses term 'color space conversion' to describe conversions
between RGB and YCbCr, not for describe colorspaces as in V4L2.
GSC_(IN|OUT)_RGB_(HD|SD)_(WIDE|NARROW) macros used to set IN_CON and
OUT_CON registers of GSCALER are probably used incorrectly, they should
not be set according to pix_mp->colorspace but rather according to
pix_mp->ycbcr_enc and pix_mp->quantization. pix_mp->colorspace should be
just copied from output to capture side.

Please fix the patch accordingly, and if you are interested you can
prepare another patch to fix register setting.


OK, so what you describe here for the colorspace  is exactly what I am 
doing in my next patch right?

I am going to fixup them up as suggested in your other review.

I will also have a look at fixing register setting and figure out what 
you explained.


Thanks for the review.

Regards,

Thibault Saunier


[1]: https://lkml.org/lkml/2017/2/10/473

Regards
Andrzej


---

Changes in v4:
- Reword commit message to better back our assumptions on specifications

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous 
review
- Added 'Reviewed-by: Andrzej Hajda '

Changes in v2: None

  drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..db7d9883861b 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
  
  	pix_mp->num_planes = fmt->num_planes;
  
-	if (pix_mp->width >= 1280) /* HD */

+   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
pix_mp->colorspace = V4L2_COLORSPACE_REC709;
else /* SD */
pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
@@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
v4l2_format *f)
pix_mp->height   = frame->f_height;
pix_mp->field= V4L2_FIELD_NONE;
pix_mp->pixelformat  = frame->fmt->pixelformat;
-   pix_mp->colorspace   = V4L2_COLORSPACE_REC709;
pix_mp->num_planes   = frame->fmt->num_planes;
  
+	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */

+   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+   else /* SD */
+   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+
for (i = 0; i < pix_mp->num_planes; ++i) {
pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
frame->fmt->depth[i]) / 8;

Bug: decoders referenced in kernel rc-keymaps not loaded on boot

[Matthias Reichl]

There seems to be a bug in on-demand loading of IR protocol decoders.

After bootup the protocol referenced in the in-kernel rc keymap shows
up as enabled (in sysfs and ir-keytable) but the protocol decoder
is not loaded and thus no rc input events will be generated.

For example, RPi3 with kernel 4.10 and gpio-ir-recv configured to use
the rc-hauppauge keymap in devicetree:

# lsmod | grep '^\(ir\|rc_\)'
ir_lirc_codec   5590  0
rc_hauppauge2422  0
rc_core24320  5 rc_hauppauge,ir_lirc_codec,lirc_dev,gpio_ir_recv

# cat /sys/class/rc/rc0/protocols
other unknown [rc-5] nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp cec 
[lirc]

# dmesg | grep "IR "
[4.506728] Registered IR keymap rc-hauppauge
[4.554651] lirc_dev: IR Remote Control driver registered, major 242
[4.576490] IR LIRC bridge handler initialized

The same happens with other IR receivers, eg the streamzap receiver,
which uses the rc-5-sz protocol / ir_rc5_decoder, on x86.

Reverting the on-demand-loading patches

[media] media: rc: remove unneeded code
commit c1500ba0b61e9abf95e0e7ecd3c4ad877f019abe

[media] media: rc: move check whether a protocol is enabled to the core
commit d80ca8bd71f0b01b2b12459189927cb3299cfab9

[media] media: rc: load decoder modules on-demand
commit acc1c3c688ed8cc862ddc007eab0dcef839f4ec8

restores the previous behaviour, all decoders are enabled and IR
events can be generated immediately after boot without having to
manually trigger loading of a protocol decoder.

so long,

Hias

Re: ir-keytable: infinite loops, segfaults

[Sean Young]

On Wed, Feb 22, 2017 at 12:07:07AM +1100, Vincent McIntyre wrote:
> On 2/21/17, Sean Young  wrote:
> >> $ sudo cat /sys/class/rc/rc1/protocols
> >> nec
> >> $ sudo sh
> >> # echo "+rc-5 +nec +rc-6 +jvc +sony +rc-5-sz +sanyo +sharp +xmp" >
> >> /sys/class/rc/rc1/protocols
> >> bash: echo: write error: Invalid argument
> >> # cat  /sys/class/rc/rc1/protocols
> >> nec
> >> In kern.log I got:
> >> kernel: [ 2293.491534] rc_core: Normal protocol change requested
> >> kernel: [ 2293.491538] rc_core: Protocol switching not supported
> >>
> >> # echo "+nec" > /sys/class/rc/rc1/protocols
> >> bash: echo: write error: Invalid argument
> >> kernel: [ 2390.832476] rc_core: Normal protocol change requested
> >> kernel: [ 2390.832481] rc_core: Protocol switching not supported
> >
> > That is expected. Does the the keymap actually work?
> >
> > ir-keytable -r -t
> 
> Kind of important information, yes. Answer: not sure. I can see it
> receiving something but none of the keys I pressed caused any reaction
> on the application (mythtv)
> 
> # ir-keytable
> Found /sys/class/rc/rc0/ (/dev/input/event5) with:
> Driver imon, table rc-imon-mce
> Supported protocols: rc-6
> Enabled protocols: rc-6
> Name: iMON Remote (15c2:ffdc)
> bus: 3, vendor/product: 15c2:ffdc, version: 0x
> Repeat delay = 500 ms, repeat period = 125 ms
> Found /sys/class/rc/rc1/ (/dev/input/event11) with:
> Driver dvb_usb_cxusb, table rc-dvico-mce
> Supported protocols: nec
> Enabled protocols:
> Name: IR-receiver inside an USB DVB re
> bus: 3, vendor/product: 0fe9:db78, version: 0x827b
> Repeat delay = 500 ms, repeat period = 125 ms
> Found /sys/class/rc/rc2/ (/dev/input/event16) with:
> Driver dvb_usb_af9035, table rc-empty
> Supported protocols: nec
> Enabled protocols:
> Name: Leadtek WinFast DTV Dongle Dual
> bus: 3, vendor/product: 0413:6a05, version: 0x0200
> Repeat delay = 500 ms, repeat period = 125 ms
> 
> # ir-keytable -r -t -d /dev/input/event11
> scancode 0xfe01 = KEY_R (0x13)
> scancode 0xfe02 = KEY_TV (0x179)
> scancode 0xfe03 = KEY_0 (0x0b)
> scancode 0xfe05 = KEY_VOLUMEDOWN (0x72)
> scancode 0xfe07 = KEY_4 (0x05)
> scancode 0xfe09 = KEY_CHANNELDOWN (0x193)
> scancode 0xfe0a = KEY_EPG (0x16d)
> scancode 0xfe0b = KEY_1 (0x02)
> scancode 0xfe0d = KEY_ESC (0x01)
> scancode 0xfe0e = KEY_MP3 (0x187)
> scancode 0xfe0f = KEY_PREVIOUSSONG (0xa5)
> scancode 0xfe11 = KEY_CHANNELUP (0x192)
> scancode 0xfe12 = KEY_NEXTSONG (0xa3)
> scancode 0xfe13 = KEY_ANGLE (0x173)
> scancode 0xfe15 = KEY_VOLUMEUP (0x73)
> scancode 0xfe16 = KEY_SETUP (0x8d)
> scancode 0xfe17 = KEY_2 (0x03)
> scancode 0xfe19 = KEY_OPEN (0x86)
> scancode 0xfe1a = KEY_DVD (0x185)
> scancode 0xfe1b = KEY_3 (0x04)
> scancode 0xfe1e = KEY_FAVORITES (0x16c)
> scancode 0xfe1f = KEY_ZOOM (0x174)
> scancode 0xfe42 = KEY_ENTER (0x1c)
> scancode 0xfe43 = KEY_REWIND (0xa8)
> scancode 0xfe46 = KEY_POWER2 (0x164)
> scancode 0xfe47 = KEY_P (0x19)
> scancode 0xfe48 = KEY_7 (0x08)
> scancode 0xfe49 = KEY_ESC (0x01)
> scancode 0xfe4c = KEY_8 (0x09)
> scancode 0xfe4d = KEY_M (0x32)
> scancode 0xfe4e = KEY_POWER (0x74)
> scancode 0xfe4f = KEY_FASTFORWARD (0xd0)
> scancode 0xfe50 = KEY_5 (0x06)
> scancode 0xfe51 = KEY_UP (0x67)
> scancode 0xfe52 = KEY_CAMERA (0xd4)
> scancode 0xfe53 = KEY_DOWN (0x6c)
> scancode 0xfe54 = KEY_6 (0x07)
> scancode 0xfe55 = KEY_TAB (0x0f)
> scancode 0xfe57 = KEY_MUTE (0x71)
> scancode 0xfe58 = KEY_9 (0x0a)
> scancode 0xfe59 = KEY_INFO (0x166)
> scancode 0xfe5a = KEY_TUNER (0x182)
> scancode 0xfe5b = KEY_LEFT (0x69)
> scancode 0xfe5e = KEY_ENTER (0x1c)
> scancode 0xfe5f = KEY_RIGHT (0x6a)

So it's still using the old keymap. I've attached a new one.

> Enabled protocols: other sony nec sanyo mce-kbd rc-6 sharp xmp
> Testing events. Please, press CTRL-C to abort.
>   # pressed '1' key
> 1487676458.742329: event type EV_MSC(0x04): scancode = 0x010b
> 1487676458.742329: event type EV_SYN(0x00).
>   # '2'
> 1487676481.742284: event type EV_MSC(0x04): scancode = 0x0117
> 1487676481.742284: event type EV_SYN(0x00).
>   # '8'
> 1487676504.842250: event type EV_MSC(0x04): scancode = 0x014c
> 1487676504.842250: event type EV_SYN(0x00).
>   # '9'
> 1487676506.542243: event type EV_MSC(0x04): scancode = 0x0158
> 1487676506.542243: event type EV_SYN(0x00).
>   # right-arrow
> 1487676551.942312: event type EV_MSC(0x04): scancode = 0x015f
> 1487676551.942312: event type EV_SYN(0x00).
>   # vol down
> 1487676637.746348: event type EV_MSC(0x04): scancode = 0x0105
> 1487676637.746348: event type EV_SYN(0x00).
>   # vol up
> 1487676642.746321: event type EV_MSC(0x04): scancode = 0x0115
> 1487676642.746321: event type EV_SYN(0x00).

Oops, that's a bug. 0x should be 0x. I've attached a new version of the
patch which should fix that.


Sean

From: Sean Young 
Subject: [PATCH] [media] 

[GIT PULL for v4.11-rc1] media updates

[Mauro Carvalho Chehab]

Hi Linus,

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

For:
  - New drivers:
i.MX6 Video Data Order Adapter's (VDOA)
Toshiba et8ek8 5MP sensor
STM DELTA multi-format video decoder V4L2 driver
SPI connected IR LED
Mediatek IR remote receiver
ZyDAS ZD1301 DVB USB interface driver

  - new RC keymaps;
  - Some very old LIRC drivers got removed from staging;
  - RC core gained support encoding IR scan codes;
  - DVB si2168 gained support for DVBv5 statistics;
  - lirc_sir driver ported to rc-core and promoted from staging;
  - other bug fixes, board additions and driver improvements.

Thanks!
Mauro



The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.11-1

for you to fetch changes up to 9eeb0ed0f30938f31a3d9135a88b9502192c18dd:

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


media updates for v4.11-rc1


Andi Shyti (6):
  [media] rc-main: assign driver type during allocation
  [media] rc-main: split setup and unregister functions
  [media] rc-core: add support for IR raw transmitters
  [media] rc-ir-raw: do not generate any receiving thread for raw 
transmitters
  [media] Documentation: bindings: add documentation for ir-spi device 
driver
  [media] rc: add support for IR LEDs driven through SPI

Andrzej Hajda (1):
  [media] v4l: s5c73m3: fix negation operator

Antti Palosaari (22):
  [media] mn88473: add DVB-T2 PLP support
  [media] cxd2820r: fix gpio null pointer dereference
  [media] si2168: implement ber statistics
  [media] si2168: implement ucb statistics
  [media] af9035: read and store whole eeprom
  [media] af9033: convert to regmap api
  [media] af9033: use 64-bit div macro where possible
  [media] af9033: style related and minor changes
  [media] af9033: return regmap for integrated IT913x tuner driver
  [media] it913x: change driver model from i2c to platform
  [media] af9035: register it9133 tuner using platform binding
  [media] it913x: add chip device ids for binding
  [media] af9035: correct demod i2c addresses
  [media] af9033: estimate cnr from formula
  [media] mt2060: add i2c bindings
  [media] mt2060: add param to split long i2c writes
  [media] zd1301_demod: ZyDAS ZD1301 DVB-T demodulator driver
  [media] MAINTAINERS: add zd1301_demod driver
  [media] zd1301: ZyDAS ZD1301 DVB USB interface driver
  [media] MAINTAINERS: add zd1301 DVB USB interface driver
  [media] mt2060: implement sleep
  [media] MAINTAINERS: remove hd29l2

Antti Seppälä (3):
  [media] rc: rc-ir-raw: Add Manchester encoder (phase encoder) helper
  [media] rc: ir-rc6-decoder: Add encode capability
  [media] rc: nuvoton-cir: Add support wakeup via sysfs filter callback

Arnd Bergmann (6):
  [media] dvb: avoid warning in dvb_net
  [media] s5k4ecgx: select CRC32 helper
  [media] b2c2: use IS_REACHABLE() instead of open-coding it
  [media] dvb-usb-v2: avoid use-after-free
  [media] ttpci: address stringop overflow warning
  [media] zd1301: fix building interface driver without demodulator

Arvind Yadav (1):
  [media] exynos4-is: fimc-is: Unmap region obtained by of_iomap()

Baruch Siach (4):
  [media] ov2659: remove NOP assignment
  [media] adv7170: drop redundant ret local
  [media] v4l2-subdev.h: fix v4l2_subdev_pad_config documentation
  [media] coda: add Freescale firmware compatibility location

Bhumika Goyal (10):
  [media] media: platform: soc_camera_platform : constify v4l2_subdev_* 
structures
  [media] exynos4-is: constify v4l2_subdev_* structures
  [media] media: platform: xilinx: xilinx-tpg: constify v4l2_subdev_* 
structures
  [media] drivers: media: i2c: constify v4l2_subdev_* structures
  [media] media: i2c: m5mols: m5mols_core: constify v4l2_subdev_pad_ops 
structures
  [media] drivers: media: i2c: ak881x: constify v4l2_subdev_* structures
  [media] drivers: media: i2c: ml86v7667: constify v4l2_subdev_* structures
  [media] media: platform: s3c-camif: constify v4l2_subdev_ops structures
  [media] media: pci: constify vb2_ops structure
  [media] media: dvb-frontends: constify vb2_ops structure

Cao jin (1):
  [media] ngene: drop ngene_link_reset()

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

Christophe JAILLET (2):
  [media] soc-camera: Fix a return value in case of error
  [media] exynos4-is: Add missing 'of_node_put'

Colin Ian King (6):
  [media] dvb-frontends: fix spelling 

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Ramiro Oliveira]

Hi Vladimir,

Thank you for your feedback

On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> please find some review comments below.
> 
> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>
>> The driver adds support for 640x480 RAW 8.
>>
>> Signed-off-by: Ramiro Oliveira 
>> ---
> 
> [snip]
> 
>> +
>> +struct ov5647 {
>> +struct v4l2_subdev  sd;
>> +struct media_padpad;
>> +struct mutexlock;
>> +struct v4l2_mbus_framefmt   format;
>> +unsigned intwidth;
>> +unsigned intheight;
>> +int power_count;
>> +struct clk  *xclk;
>> +/* External clock frequency currently supported is 30MHz */
>> +u32 xclk_freq;
> 
> See a comment about 25MHz vs 30MHz below.
> 
> Also I assume you can remove 'xclk_freq' from the struct fields,
> it can be replaced by a local variable.
> 

I'll do that.

>> +};
> 
> [snip]
> 
>> +
>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>> +{
>> +int ret;
>> +unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>> +struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +ret = i2c_master_send(client, data_w, 2);
>> +if (ret < 0) {
>> +dev_dbg(>dev, "%s: i2c read error, reg: %x\n",
> 
> s/i2c read error/i2c write error/
> 

I'm not sure I understand what you mean.

>> +__func__, reg);
>> +return ret;
>> +}
>> +
>> +ret = i2c_master_recv(client, val, 1);
>> +if (ret < 0)
>> +dev_dbg(>dev, "%s: i2c read error, reg: %x\n",
>> +__func__, reg);
>> +
>> +return ret;
>> +
> 
> Please remove the empty line above.
> 

Ok.

>> +}
>> +
>> +static int ov5647_write_array(struct v4l2_subdev *sd,
>> +struct regval_list *regs, int array_size)
>> +{
>> +int i = 0, ret;
> 
> Assignment of 'i' on declaration is not needed, please remove.
> 

Ok.

>> +
>> +for (i = 0; i < array_size; i++) {
>> +ret = ov5647_write(sd, regs[i].addr, regs[i].data);
>> +if (ret < 0)
>> +return ret;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel)
>> +{
>> +u8 channel_id;
>> +int ret;
>> +
>> +ret = ov5647_read(sd, 0x4814, _id);
>> +if (ret < 0)
>> +return ret;
>> +
>> +channel_id &= ~(3 << 6);
>> +return ov5647_write(sd, 0x4814, channel_id | (channel << 6));
>> +}
>> +
>> +static int ov5647_stream_on(struct v4l2_subdev *sd)
>> +{
>> +struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +ov5647_write(sd, 0x4202, 0x00);
> 
> Should you add a check of the returned value?
> 

I'll add it.

>> +
>> +dev_dbg(>dev, "Stream on");
> 
> I would suggest to remove dev_dbg(), because ftrace will report to a user,
> when this function is called.
> 
> Also dev_dbg() in the middle of two I2C transfers in a row looks as being
> placed improperly.
> 

I'll remove it.

>> +
>> +return ov5647_write(sd, 0x300D, 0x00);
>> +}
>> +
>> +static int ov5647_stream_off(struct v4l2_subdev *sd)
>> +{
>> +struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +ov5647_write(sd, 0x4202, 0x0f);
> 
> Should you add a check of the returned value?
> 

I'll add it.

>> +
>> +dev_dbg(>dev, "Stream off");
> 
> I would suggest to remove dev_dbg(), because ftrace will report to a user,
> when this function is called.
> 
> Also dev_dbg() in the middle of two I2C transfers in a row looks as being
> placed improperly.
> 

I'll remove it.

>> +
>> +return ov5647_write(sd, 0x300D, 0x01);
>> +}
>> +
>> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
>> +{
>> +int ret;
>> +u8 rdval;
>> +
>> +ret = ov5647_read(sd, 0x0100, );
>> +if (ret < 0)
>> +return ret;
>> +
>> +if (standby)
>> +rdval &= ~0x01;
>> +else
>> +rdval |= 0x01;
>> +
>> +return ov5647_write(sd, 0x0100, rdval);
>> +}
>> +
>> +static int __sensor_init(struct v4l2_subdev *sd)
>> +{
>> +int ret;
>> +u8 resetval;
>> +u8 rdval;
> 
> It could be possible to put declarations of 'resetval' and 'rdval' on the 
> same line.
> 

Sure.

>> +struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +dev_dbg(>dev, "sensor init\n");
>> +
>> +ret = ov5647_read(sd, 0x0100, );
>> +if (ret < 0)
>> +return ret;
>> +
>> +ret = ov5647_write_array(sd, ov5647_640x480,
>> +ARRAY_SIZE(ov5647_640x480));
>> +if (ret < 0) {
>> +dev_err(>dev, "write sensor default regs error\n");
>> +return ret;
>> +}
>> +
>> +  

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Sakari Ailus]

On Tue, Feb 21, 2017 at 04:03:32PM +, Russell King - ARM Linux wrote:
> On Tue, Feb 21, 2017 at 05:38:34PM +0200, Sakari Ailus wrote:
> > Hi Russell,
> > 
> > On Tue, Feb 21, 2017 at 01:21:32PM +, Russell King - ARM Linux wrote:
> > > On Tue, Feb 21, 2017 at 02:37:57PM +0200, Sakari Ailus wrote:
> > > > Hi Russell,
> > > > 
> > > > On Tue, Feb 21, 2017 at 12:13:32AM +, Russell King - ARM Linux 
> > > > wrote:
> > > > > On Tue, Feb 21, 2017 at 12:04:10AM +0200, Sakari Ailus wrote:
> > > > > > On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:
> > > > > > > From: Russell King 
> > > > > > > 
> > > > > > > Setting and getting frame rates is part of the negotiation 
> > > > > > > mechanism
> > > > > > > between subdevs.  The lack of support means that a frame rate at 
> > > > > > > the
> > > > > > > sensor can't be negotiated through the subdev path.
> > > > > > 
> > > > > > Just wondering --- what do you need this for?
> > > > > 
> > > > > The v4l2 documentation contradicts the media-ctl implementation.
> > > > > 
> > > > > While v4l2 documentation says:
> > > > > 
> > > > >   These ioctls are used to get and set the frame interval at specific
> > > > >   subdev pads in the image pipeline. The frame interval only makes 
> > > > > sense
> > > > >   for sub-devices that can control the frame period on their own. This
> > > > >   includes, for instance, image sensors and TV tuners. Sub-devices 
> > > > > that
> > > > >   don't support frame intervals must not implement these ioctls.
> > > > > 
> > > > > However, when trying to configure the pipeline using media-ctl, eg:
> > > > > 
> > > > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 pixel 
> > > > > 0-0010":0[crop:(0,0)/3264x2464]'
> > > > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> > > > > 0-0010":1[fmt:SRGGB10/3264x2464@1/30]'
> > > > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> > > > > 0-0010":0[fmt:SRGGB8/816x616@1/30]'
> > > > > media-ctl -d /dev/media1 --set-v4l2 
> > > > > '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
> > > > > Unable to setup formats: Inappropriate ioctl for device (25)
> > > > > media-ctl -d /dev/media1 --set-v4l2 
> > > > > '"ipu1_csi0_mux":2[fmt:SRGGB8/816x616@1/30]'
> > > > > media-ctl -d /dev/media1 --set-v4l2 
> > > > > '"ipu1_csi0":2[fmt:SRGGB8/816x616@1/30]'
> > > > > 
> > > > > The problem there is that the format setting for the csi2 does not get
> > > > > propagated forward:
> > > > 
> > > > The CSI-2 receivers typically do not implement frame interval IOCTLs as 
> > > > they
> > > > do not control the frame interval. Some sensors or TV tuners typically 
> > > > do,
> > > > so they implement these IOCTLs.
> > > 
> > > No, TV tuners do not.  The frame rate for a TV tuner is set by the
> > > broadcaster, not by the tuner.  The tuner can't change that frame rate.
> > > The tuner may opt to "skip" fields or frames.  That's no different from
> > > what the CSI block in my example below is capable of doing.
> > > 
> > > Treating a tuner differently from the CSI block is inconsistent and
> > > completely wrong.
> > 
> > I agree tuners in that sense are somewhat similar, and they are not treated
> > differently because they are tuners (and not CSI-2 receivers). Neither can
> > control the frame rate of the incoming video stream.
> > 
> > Conceivably a tuner could implement G_FRAME_INTERVAL IOCTL, but based on a
> > quick glance none appears to. Neither do CSI-2 receivers. Only sensor
> > drivers do currently.
> 
> Please look again.  I am being very careful with "CSI" vs "CSI-2" in my
> emails, you are conflating the two.
> 
> In all my emails so far, "CSI" refers to a block of hardware that is
> responsible for receiving an image stream from some kind of source.  It
> contains hardware that supports frame skipping.

Ah, I missed the difference. Thanks for pointing it out.

Still, that does not change how the skipping would work nor how I proposed
it would be configured from the user space.

> 
> "CSI-2" refers to a different block of hardware that is responsible for
> receiving a serially encoded stream from a MIPI-CSI-2 compliant source
> and providing it to the "CSI" block.
> 
> I would have thought my diagram that I drew would have made it clear that
> they were different blocks of hardware, but I guess in this case, the old
> saying "a picture is worth 1000 words" is simply not true.
> 
> > Images are transmitted as series of lines, with each line ending in a
> > horizontal blanking period, and each frame ending with a similar period of
> 
> I'm sorry, are you seriously teaching me to suck rocks?  I am insulted.
> 
> I've been involved in TV and video for many years, I don't need you to
> tell me how video is transmitted.
> 
> Sorry, you've just lost my interest in further discussion.

There's no need to feel insulted; that certainly was not the intention.

I've proposed you a solution, please comment on that.

-- 
Regards,

Sakari Ailus
e-mail: 

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Russell King - ARM Linux]

On Tue, Feb 21, 2017 at 05:38:34PM +0200, Sakari Ailus wrote:
> Hi Russell,
> 
> On Tue, Feb 21, 2017 at 01:21:32PM +, Russell King - ARM Linux wrote:
> > On Tue, Feb 21, 2017 at 02:37:57PM +0200, Sakari Ailus wrote:
> > > Hi Russell,
> > > 
> > > On Tue, Feb 21, 2017 at 12:13:32AM +, Russell King - ARM Linux wrote:
> > > > On Tue, Feb 21, 2017 at 12:04:10AM +0200, Sakari Ailus wrote:
> > > > > On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:
> > > > > > From: Russell King 
> > > > > > 
> > > > > > Setting and getting frame rates is part of the negotiation mechanism
> > > > > > between subdevs.  The lack of support means that a frame rate at the
> > > > > > sensor can't be negotiated through the subdev path.
> > > > > 
> > > > > Just wondering --- what do you need this for?
> > > > 
> > > > The v4l2 documentation contradicts the media-ctl implementation.
> > > > 
> > > > While v4l2 documentation says:
> > > > 
> > > >   These ioctls are used to get and set the frame interval at specific
> > > >   subdev pads in the image pipeline. The frame interval only makes sense
> > > >   for sub-devices that can control the frame period on their own. This
> > > >   includes, for instance, image sensors and TV tuners. Sub-devices that
> > > >   don't support frame intervals must not implement these ioctls.
> > > > 
> > > > However, when trying to configure the pipeline using media-ctl, eg:
> > > > 
> > > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 pixel 
> > > > 0-0010":0[crop:(0,0)/3264x2464]'
> > > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> > > > 0-0010":1[fmt:SRGGB10/3264x2464@1/30]'
> > > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> > > > 0-0010":0[fmt:SRGGB8/816x616@1/30]'
> > > > media-ctl -d /dev/media1 --set-v4l2 
> > > > '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
> > > > Unable to setup formats: Inappropriate ioctl for device (25)
> > > > media-ctl -d /dev/media1 --set-v4l2 
> > > > '"ipu1_csi0_mux":2[fmt:SRGGB8/816x616@1/30]'
> > > > media-ctl -d /dev/media1 --set-v4l2 
> > > > '"ipu1_csi0":2[fmt:SRGGB8/816x616@1/30]'
> > > > 
> > > > The problem there is that the format setting for the csi2 does not get
> > > > propagated forward:
> > > 
> > > The CSI-2 receivers typically do not implement frame interval IOCTLs as 
> > > they
> > > do not control the frame interval. Some sensors or TV tuners typically do,
> > > so they implement these IOCTLs.
> > 
> > No, TV tuners do not.  The frame rate for a TV tuner is set by the
> > broadcaster, not by the tuner.  The tuner can't change that frame rate.
> > The tuner may opt to "skip" fields or frames.  That's no different from
> > what the CSI block in my example below is capable of doing.
> > 
> > Treating a tuner differently from the CSI block is inconsistent and
> > completely wrong.
> 
> I agree tuners in that sense are somewhat similar, and they are not treated
> differently because they are tuners (and not CSI-2 receivers). Neither can
> control the frame rate of the incoming video stream.
> 
> Conceivably a tuner could implement G_FRAME_INTERVAL IOCTL, but based on a
> quick glance none appears to. Neither do CSI-2 receivers. Only sensor
> drivers do currently.

Please look again.  I am being very careful with "CSI" vs "CSI-2" in my
emails, you are conflating the two.

In all my emails so far, "CSI" refers to a block of hardware that is
responsible for receiving an image stream from some kind of source.  It
contains hardware that supports frame skipping.

"CSI-2" refers to a different block of hardware that is responsible for
receiving a serially encoded stream from a MIPI-CSI-2 compliant source
and providing it to the "CSI" block.

I would have thought my diagram that I drew would have made it clear that
they were different blocks of hardware, but I guess in this case, the old
saying "a picture is worth 1000 words" is simply not true.

> Images are transmitted as series of lines, with each line ending in a
> horizontal blanking period, and each frame ending with a similar period of

I'm sorry, are you seriously teaching me to suck rocks?  I am insulted.

I've been involved in TV and video for many years, I don't need you to
tell me how video is transmitted.

Sorry, you've just lost my interest in further discussion.

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

Re: Problem: saa7113 (saa7115) vs. "conrad usb grabber usb-472"

[Bodo Eggert]

On Tue, 21 Feb 2017, Devin Heitmueller wrote:

> > lsusb:
> > Bus 003 Device 002: ID 0573:0400 Zoran Co. Personal Media Division 
> > (Nogatech) D-Link V100
> 
> The Zoran usbvision driver has been a mess for years, and it's not
> going to get better anytime soon.  It's a *really* old design and
> there hasn't been any interest from any of the developers to work on
> it.
> 
> In this particular case, you're probably way better off just throwing
> it away and buying a new $25 capture device.

Thanks.

[PATCH 1/1] docs-rst: media: Explicitly refer to sub-sampling in scaling documentation

[Sakari Ailus]

Skipping, which is sometimes used in terminology related to sensors when
referring to sub-sampling is replaced by more suitable sub-sampling
instead. Skipping is retained in a note in parentheses.

Suggested-by: Russell King 
Signed-off-by: Sakari Ailus 
---
 Documentation/media/uapi/mediactl/media-types.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
b/Documentation/media/uapi/mediactl/media-types.rst
index 3e03dc2..2a5164a 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -284,7 +284,8 @@ Types and flags used to represent the media graph elements
  supported scaling ratios is entity-specific and can differ
  between the horizontal and vertical directions (in particular
  scaling can be supported in one direction only). Binning and
- skipping are considered as scaling.
+ sub-sampling (occasionally also referred to as skipping) are
+ considered as scaling.
 
 -  ..  row 28
 
-- 
2.7.4

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Vladimir Zapolskiy]

Hi Ramiro,

On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> Create device tree bindings documentation.
> 
> Signed-off-by: Ramiro Oliveira 
> Acked-by: Rob Herring 
> ---
>  .../devicetree/bindings/media/i2c/ov5647.txt   | 35 
> ++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt 
> b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> new file mode 100644
> index ..31956426d3b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> @@ -0,0 +1,35 @@
> +Omnivision OV5647 raw image sensor
> +-
> +
> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> +and CCI (I2C compatible) control bus.
> +
> +Required properties:
> +
> +- compatible : "ovti,ov5647".
> +- reg: I2C slave address of the sensor.
> +- clocks : Reference to the xclk clock.

Is "xclk" clock a pixel clock or something else?

> +- clock-names: Should be "xclk".

You can remove this property, because there is only one source clock.

> +- clock-frequency: Frequency of the xclk clock.

And after the last updates in the driver this property can be removed as well.

> +
> +The common video interfaces bindings (see video-interfaces.txt) should be
> +used to specify link to the image data receiver. The OV5647 device
> +node should contain one 'port' child node with an 'endpoint' subnode.
> +
> +Example:
> +
> + i2c@2000 {
> + ...
> + ov: camera@36 {
> + compatible = "ovti,ov5647";
> + reg = <0x36>;
> + clocks = <_clk>;
> + clock-names = "xclk";
> + clock-frequency = <2500>;

When you remove two unused properties, please don't forget to update the
example.

> + port {
> + camera_1: endpoint {
> + remote-endpoint = <_ep1>;
> + };
> + };
> + };
> + };
> 

--
With best wishes,
Vladimir

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Vladimir Zapolskiy]

Hi Ramiro,

please find some review comments below.

On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
> and RAW 10 output formats, and MIPI CSI-2 interface.
> 
> The driver adds support for 640x480 RAW 8.
> 
> Signed-off-by: Ramiro Oliveira 
> ---

[snip]

> +
> +struct ov5647 {
> + struct v4l2_subdev  sd;
> + struct media_padpad;
> + struct mutexlock;
> + struct v4l2_mbus_framefmt   format;
> + unsigned intwidth;
> + unsigned intheight;
> + int power_count;
> + struct clk  *xclk;
> + /* External clock frequency currently supported is 30MHz */
> + u32 xclk_freq;

See a comment about 25MHz vs 30MHz below.

Also I assume you can remove 'xclk_freq' from the struct fields,
it can be replaced by a local variable.

> +};

[snip]

> +
> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
> +{
> + int ret;
> + unsigned char data_w[2] = { reg >> 8, reg & 0xff };
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> + ret = i2c_master_send(client, data_w, 2);
> + if (ret < 0) {
> + dev_dbg(>dev, "%s: i2c read error, reg: %x\n",

s/i2c read error/i2c write error/

> + __func__, reg);
> + return ret;
> + }
> +
> + ret = i2c_master_recv(client, val, 1);
> + if (ret < 0)
> + dev_dbg(>dev, "%s: i2c read error, reg: %x\n",
> + __func__, reg);
> +
> + return ret;
> +

Please remove the empty line above.

> +}
> +
> +static int ov5647_write_array(struct v4l2_subdev *sd,
> + struct regval_list *regs, int array_size)
> +{
> + int i = 0, ret;

Assignment of 'i' on declaration is not needed, please remove.

> +
> + for (i = 0; i < array_size; i++) {
> + ret = ov5647_write(sd, regs[i].addr, regs[i].data);
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel)
> +{
> + u8 channel_id;
> + int ret;
> +
> + ret = ov5647_read(sd, 0x4814, _id);
> + if (ret < 0)
> + return ret;
> +
> + channel_id &= ~(3 << 6);
> + return ov5647_write(sd, 0x4814, channel_id | (channel << 6));
> +}
> +
> +static int ov5647_stream_on(struct v4l2_subdev *sd)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> + ov5647_write(sd, 0x4202, 0x00);

Should you add a check of the returned value?

> +
> + dev_dbg(>dev, "Stream on");

I would suggest to remove dev_dbg(), because ftrace will report to a user,
when this function is called.

Also dev_dbg() in the middle of two I2C transfers in a row looks as being
placed improperly.

> +
> + return ov5647_write(sd, 0x300D, 0x00);
> +}
> +
> +static int ov5647_stream_off(struct v4l2_subdev *sd)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> + ov5647_write(sd, 0x4202, 0x0f);

Should you add a check of the returned value?

> +
> + dev_dbg(>dev, "Stream off");

I would suggest to remove dev_dbg(), because ftrace will report to a user,
when this function is called.

Also dev_dbg() in the middle of two I2C transfers in a row looks as being
placed improperly.

> +
> + return ov5647_write(sd, 0x300D, 0x01);
> +}
> +
> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
> +{
> + int ret;
> + u8 rdval;
> +
> + ret = ov5647_read(sd, 0x0100, );
> + if (ret < 0)
> + return ret;
> +
> + if (standby)
> + rdval &= ~0x01;
> + else
> + rdval |= 0x01;
> +
> + return ov5647_write(sd, 0x0100, rdval);
> +}
> +
> +static int __sensor_init(struct v4l2_subdev *sd)
> +{
> + int ret;
> + u8 resetval;
> + u8 rdval;

It could be possible to put declarations of 'resetval' and 'rdval' on the same 
line.

> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> + dev_dbg(>dev, "sensor init\n");
> +
> + ret = ov5647_read(sd, 0x0100, );
> + if (ret < 0)
> + return ret;
> +
> + ret = ov5647_write_array(sd, ov5647_640x480,
> + ARRAY_SIZE(ov5647_640x480));
> + if (ret < 0) {
> + dev_err(>dev, "write sensor default regs error\n");
> + return ret;
> + }
> +
> + ret = ov5647_set_virtual_channel(sd, 0);
> + if (ret < 0)
> + return ret;
> +
> + ret = ov5647_read(sd, 0x0100, );
> + if (ret < 0)
> + return ret;
> +
> + if (!(resetval & 0x01)) {
> + dev_err(>dev, "Device was in SW standby");
> + ret = ov5647_write(sd, 0x0100, 0x01);
> + if (ret < 0)
> + 

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Sakari Ailus]

Hi Russell,

On Tue, Feb 21, 2017 at 01:21:32PM +, Russell King - ARM Linux wrote:
> On Tue, Feb 21, 2017 at 02:37:57PM +0200, Sakari Ailus wrote:
> > Hi Russell,
> > 
> > On Tue, Feb 21, 2017 at 12:13:32AM +, Russell King - ARM Linux wrote:
> > > On Tue, Feb 21, 2017 at 12:04:10AM +0200, Sakari Ailus wrote:
> > > > On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:
> > > > > From: Russell King 
> > > > > 
> > > > > Setting and getting frame rates is part of the negotiation mechanism
> > > > > between subdevs.  The lack of support means that a frame rate at the
> > > > > sensor can't be negotiated through the subdev path.
> > > > 
> > > > Just wondering --- what do you need this for?
> > > 
> > > The v4l2 documentation contradicts the media-ctl implementation.
> > > 
> > > While v4l2 documentation says:
> > > 
> > >   These ioctls are used to get and set the frame interval at specific
> > >   subdev pads in the image pipeline. The frame interval only makes sense
> > >   for sub-devices that can control the frame period on their own. This
> > >   includes, for instance, image sensors and TV tuners. Sub-devices that
> > >   don't support frame intervals must not implement these ioctls.
> > > 
> > > However, when trying to configure the pipeline using media-ctl, eg:
> > > 
> > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 pixel 
> > > 0-0010":0[crop:(0,0)/3264x2464]'
> > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> > > 0-0010":1[fmt:SRGGB10/3264x2464@1/30]'
> > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> > > 0-0010":0[fmt:SRGGB8/816x616@1/30]'
> > > media-ctl -d /dev/media1 --set-v4l2 
> > > '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
> > > Unable to setup formats: Inappropriate ioctl for device (25)
> > > media-ctl -d /dev/media1 --set-v4l2 
> > > '"ipu1_csi0_mux":2[fmt:SRGGB8/816x616@1/30]'
> > > media-ctl -d /dev/media1 --set-v4l2 
> > > '"ipu1_csi0":2[fmt:SRGGB8/816x616@1/30]'
> > > 
> > > The problem there is that the format setting for the csi2 does not get
> > > propagated forward:
> > 
> > The CSI-2 receivers typically do not implement frame interval IOCTLs as they
> > do not control the frame interval. Some sensors or TV tuners typically do,
> > so they implement these IOCTLs.
> 
> No, TV tuners do not.  The frame rate for a TV tuner is set by the
> broadcaster, not by the tuner.  The tuner can't change that frame rate.
> The tuner may opt to "skip" fields or frames.  That's no different from
> what the CSI block in my example below is capable of doing.
> 
> Treating a tuner differently from the CSI block is inconsistent and
> completely wrong.

I agree tuners in that sense are somewhat similar, and they are not treated
differently because they are tuners (and not CSI-2 receivers). Neither can
control the frame rate of the incoming video stream.

Conceivably a tuner could implement G_FRAME_INTERVAL IOCTL, but based on a
quick glance none appears to. Neither do CSI-2 receivers. Only sensor
drivers do currently.

> 
> > There are alternative ways to specify the frame rate.
> 
> Empty statements (or hand-waving type statements) I'm afraid don't
> contribute to the discussion, because they mean nothing to me.  Please
> give an example, or flesh out what you mean.

Images are transmitted as series of lines, with each line ending in a
horizontal blanking period, and each frame ending with a similar period of
vertical blanking. The blanking configuration in the units of pixels and
lines at their pixel clock is a native unit which sensors typically use, and
some drivers expose the blanking controls directly to the user.



> 
> > > $ strace media-ctl -d /dev/media1 --set-v4l2 
> > > '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
> > > ...
> > > open("/dev/v4l-subdev16", O_RDWR)   = 3
> > > ioctl(3, VIDIOC_SUBDEV_S_FMT, 0xbec16244) = 0
> > > ioctl(3, VIDIOC_SUBDEV_S_FRAME_INTERVAL, 0xbec162a4) = -1 ENOTTY 
> > > (Inappropriate
> > > ioctl for device)
> > > fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
> > > write(1, "Unable to setup formats: Inappro"..., 61) = 61
> > > Unable to setup formats: Inappropriate ioctl for device (25)
> > > close(3)= 0
> > > exit_group(1)   = ?
> > > +++ exited with 1 +++
> > > 
> > > because media-ctl exits as soon as it encouters the error while trying
> > > to set the frame rate.
> > > 
> > > This makes implementing setup of the media pipeline in shell scripts
> > > unnecessarily difficult - as you need to then know whether an entity
> > > is likely not to support the VIDIOC_SUBDEV_S_FRAME_INTERVAL call,
> > > and either avoid specifying a frame rate:
> > 
> > You should remove the frame interval setting from sub-devices that do not
> > support it.
> 
> That means we end up with horribly complex scripts.  This "solution" does
> not 

Re: [PATCH] dma-buf: add support for compat ioctl

[Christian König]

Am 21.02.2017 um 15:55 schrieb Marek Szyprowski:

Dear All,

On 2017-02-21 15:37, Marek Szyprowski wrote:

Hi Christian,

On 2017-02-21 14:59, Christian König wrote:

Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:
Add compat ioctl support to dma-buf. This lets one to use 
DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for 
both 32
and 64bit modes are same, so there is no need for additional 
translation

layer.


Well I might be wrong, but IIRC compat_ioctl was just optional and 
if not specified unlocked_ioctl was called instead.


If that is true your patch wouldn't have any effect at all.


Well, then why I got -ENOTTY in the 32bit test app for this ioctl on 
64bit ARM64 kernel without this patch?




I've checked in fs/compat_ioctl.c, I see no fallback in 
COMPAT_SYSCALL_DEFINE3,
so one has to provide compat_ioctl callback to have ioctl working with 
32bit

apps.


Then my memory cheated on me.

In this case the patch is Reviewed-by: Christian König 
.


Regards,
Christian.



Best regards

Re: Problem: saa7113 (saa7115) vs. "conrad usb grabber usb-472"

[Devin Heitmueller]

> lsusb:
> Bus 003 Device 002: ID 0573:0400 Zoran Co. Personal Media Division (Nogatech) 
> D-Link V100

The Zoran usbvision driver has been a mess for years, and it's not
going to get better anytime soon.  It's a *really* old design and
there hasn't been any interest from any of the developers to work on
it.

In this particular case, you're probably way better off just throwing
it away and buying a new $25 capture device.

Devin

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

Re: [PATCH] dma-buf: add support for compat ioctl

[Marek Szyprowski]

Dear All,

On 2017-02-21 15:37, Marek Szyprowski wrote:

Hi Christian,

On 2017-02-21 14:59, Christian König wrote:

Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:
Add compat ioctl support to dma-buf. This lets one to use 
DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for 
both 32
and 64bit modes are same, so there is no need for additional 
translation

layer.


Well I might be wrong, but IIRC compat_ioctl was just optional and if 
not specified unlocked_ioctl was called instead.


If that is true your patch wouldn't have any effect at all.


Well, then why I got -ENOTTY in the 32bit test app for this ioctl on 
64bit ARM64 kernel without this patch?




I've checked in fs/compat_ioctl.c, I see no fallback in 
COMPAT_SYSCALL_DEFINE3,

so one has to provide compat_ioctl callback to have ioctl working with 32bit
apps.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Sakari Ailus]

Hi Ramiro,

On Tue, Feb 21, 2017 at 02:49:12PM +, Ramiro Oliveira wrote:
> Hi Sakari,
> 
> Thank you for your feedback.

You're welcome.

An additional note as you don't implement any controls --- some CSI-2
receivers may need to know the link frequency to know how to program the
receiver; they'll simply fail to start streaming if you don't.



-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Ramiro Oliveira]

Hi Sakari,

Thank you for your feedback.

On 2/21/2017 12:09 PM, Sakari Ailus wrote:
> Hi Ramiro,
> 
> A few minor comments below.
> 
> On Fri, Feb 17, 2017 at 01:14:16PM +, Ramiro Oliveira wrote:
>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>
>> The driver adds support for 640x480 RAW 8.
>>
>> Signed-off-by: Ramiro Oliveira 
>> ---
>>  MAINTAINERS|   7 +
>>  drivers/media/i2c/Kconfig  |  11 +
>>  drivers/media/i2c/Makefile |   1 +
>>  drivers/media/i2c/ov5647.c | 638 
>> +
>>  4 files changed, 657 insertions(+)
>>  create mode 100644 drivers/media/i2c/ov5647.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 8e7e8d7855ee..7bbca271acc8 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -9109,6 +9109,13 @@ M:Harald Welte 
>>  S:  Maintained
>>  F:  drivers/char/pcmcia/cm4040_cs.*
>>  
>> +OMNIVISION OV5647 SENSOR DRIVER
>> +M:  Ramiro Oliveira 
>> +L:  linux-media@vger.kernel.org
>> +T:  git git://linuxtv.org/media_tree.git
>> +S:  Maintained
>> +F:  drivers/media/i2c/ov5647.c
>> +
>>  OMNIVISION OV7670 SENSOR DRIVER
>>  M:  Jonathan Corbet 
>>  L:  linux-media@vger.kernel.org
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index cee1dae6e014..8435b99f38bc 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -531,6 +531,17 @@ config VIDEO_OV2659
>>To compile this driver as a module, choose M here: the
>>module will be called ov2659.
>>  
>> +config VIDEO_OV5647
>> +tristate "OmniVision OV5647 sensor support"
>> +depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
>> +depends on MEDIA_CAMERA_SUPPORT
>> +---help---
>> +  This is a Video4Linux2 sensor-level driver for the OmniVision
>> +  OV5647 camera.
>> +
>> +  To compile this driver as a module, choose M here: the
>> +  module will be called ov5647.
>> +
>>  config VIDEO_OV7640
>>  tristate "OmniVision OV7640 sensor support"
>>  depends on I2C && VIDEO_V4L2
>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>> index 5bc7bbeb5499..ef2ccf65f94c 100644
>> --- a/drivers/media/i2c/Makefile
>> +++ b/drivers/media/i2c/Makefile
>> @@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
>>  obj-$(CONFIG_VIDEO_ML86V7667)   += ml86v7667.o
>>  obj-$(CONFIG_VIDEO_OV2659)  += ov2659.o
>>  obj-$(CONFIG_VIDEO_TC358743)+= tc358743.o
>> +obj-$(CONFIG_VIDEO_OV5647)  += ov5647.o
>> diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
>> new file mode 100644
>> index ..34e620fabbaf
>> --- /dev/null
>> +++ b/drivers/media/i2c/ov5647.c
>> @@ -0,0 +1,638 @@
>> +/*
>> + * A V4L2 driver for OmniVision OV5647 cameras.
>> + *
>> + * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver
>> + * Copyright (C) 2011 Sylwester Nawrocki 
>> + *
>> + * Based on Omnivision OV7670 Camera Driver
>> + * Copyright (C) 2006-7 Jonathan Corbet 
>> + *
>> + * Copyright (C) 2016, Synopsys, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation version 2.
>> + *
>> + * This program is distributed .as is. WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; 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 
> 
> You don't seem to implement any controls.
> 
> The sensor likely supports exposure time (and maybe also gain) the user
> might want to control. Is there an intent to add that? Otherwise the header
> should be removed.
> 

I plan to add them in the future but for now I think I'll just remove the 
header.

>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define SENSOR_NAME "ov5647"
>> +
>> +#define OV5647_SW_RESET 0x1003
>> +#define OV5647_REG_CHIPID_H 0x300A
>> +#define OV5647_REG_CHIPID_L 0x300B
>> +
>> +#define REG_TERM 0xfffe
>> +#define VAL_TERM 0xfe
>> +#define REG_DLY  0x
>> +
>> +#define OV5647_ROW_START0x01
>> +#define OV5647_ROW_START_MIN0
>> +#define OV5647_ROW_START_MAX2004
>> +#define OV5647_ROW_START_DEF54
>> +
>> +#define OV5647_COLUMN_START 0x02
>> +#define OV5647_COLUMN_START_MIN 0
>> +#define OV5647_COLUMN_START_MAX 2750
>> +#define OV5647_COLUMN_START_DEF 16
>> +
>> +#define OV5647_WINDOW_HEIGHT0x03
>> +#define OV5647_WINDOW_HEIGHT_MIN2
>> +#define 

Problem: saa7113 (saa7115) vs. "conrad usb grabber usb-472"

[Bodo Eggert]

System: Debian Jessie x64. (Using qv4l2).

I've got a USB video grabber called "conrad usb grabber usb-472", 
essentially it's a no-name-branding. It's recognized as saa7113 by the 
saa7115 driver.

The device has one video input (chinch, yellow) and a stereo input (red 
and white). The driver does recognize three video inputs 
(green/yellow/red), neither of them works: No frame recognized. I verified 
the camera to supply a correct signal.

Trying to use MMIO, qv4l2 will hang and needs to be killed.
Trying to use read(), I get a black screen.

(Sorry if this isn't the correct list.

I'm OK with just throwing the thing away, but if fixing it is an option, 
I'll help.)

uname -a
Linux be10 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1 (2016-12-30) x86_64 
GNU/Linux


lsusb:
Bus 003 Device 002: ID 0573:0400 Zoran Co. Personal Media Division (Nogatech) 
D-Link V100

dmesg:
[ 7518.194350] usb 3-2: new full-speed USB device number 2 using ohci-pci
[ 7518.371408] usb 3-2: New USB device found, idVendor=0573, idProduct=0400
[ 7518.371420] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 7519.217042] usbvision_probe: D-Link V100 found
[ 7519.217461] USBVision[0]: registered USBVision Video device video1 [v4l2]
[ 7519.217505] usbcore: registered new interface driver usbvision
[ 7519.217507] USBVision USB Video Device Driver for Linux : 0.9.11
[ 7519.902857] saa7115 5-0025: saa7113 found @ 0x4a (usbvision-3-2)

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Ramiro,

On Tue, Feb 21, 2017 at 02:30:16PM +, Ramiro Oliveira wrote:
> Hi Sakari,
> 
> Thank you for your feedback.
> 
> On 2/21/2017 11:57 AM, Sakari Ailus wrote:
> > Hi Ramiro,
> > 
> > On Fri, Feb 17, 2017 at 01:14:15PM +, Ramiro Oliveira wrote:
> >> Create device tree bindings documentation.
> >>
> >> Signed-off-by: Ramiro Oliveira 
> >> Acked-by: Rob Herring 
> >> ---
> >>  .../devicetree/bindings/media/i2c/ov5647.txt   | 35 
> >> ++
> >>  1 file changed, 35 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt 
> >> b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >> new file mode 100644
> >> index ..31956426d3b9
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >> @@ -0,0 +1,35 @@
> >> +Omnivision OV5647 raw image sensor
> >> +-
> >> +
> >> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data 
> >> interfaces
> >> +and CCI (I2C compatible) control bus.
> >> +
> >> +Required properties:
> >> +
> >> +- compatible  : "ovti,ov5647".
> >> +- reg : I2C slave address of the sensor.
> >> +- clocks  : Reference to the xclk clock.
> >> +- clock-names : Should be "xclk".
> >> +- clock-frequency : Frequency of the xclk clock.
> >> +
> >> +The common video interfaces bindings (see video-interfaces.txt) should be
> >> +used to specify link to the image data receiver. The OV5647 device
> >> +node should contain one 'port' child node with an 'endpoint' subnode.
> > 
> > The remote-endpoint property in endpoint nodes should be mandatory,
> > shouldn't it? Otherwise the sensor isn't connected to anything and hardly
> > useful as such. The list of optional endpoint properties is a long one and
> > it should be documented here which ones are recognised, either as optional
> > or mandatory.
> > 
> 
> I guess you're right, it should be mandatory, although at the moment I'm not
> checking for it's presence in the driver so I'll add it to the driver.
> 
> At the moment that's the only property I think it should be mandatory, and I
> don't believe I need any optional one.
> 
> Do you have a suggestion for any new property I should use?

As you don't need any in the driver for the driver to work, you can omit
them.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH] dma-buf: add support for compat ioctl

[Marek Szyprowski]

Hi Christian,

On 2017-02-21 14:59, Christian König wrote:

Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:
Add compat ioctl support to dma-buf. This lets one to use 
DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for 
both 32

and 64bit modes are same, so there is no need for additional translation
layer.


Well I might be wrong, but IIRC compat_ioctl was just optional and if 
not specified unlocked_ioctl was called instead.


If that is true your patch wouldn't have any effect at all.


Well, then why I got -ENOTTY in the 32bit test app for this ioctl on 
64bit ARM64 kernel without this patch?


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Sakari,

Thank you for your feedback.

On 2/21/2017 11:57 AM, Sakari Ailus wrote:
> Hi Ramiro,
> 
> On Fri, Feb 17, 2017 at 01:14:15PM +, Ramiro Oliveira wrote:
>> Create device tree bindings documentation.
>>
>> Signed-off-by: Ramiro Oliveira 
>> Acked-by: Rob Herring 
>> ---
>>  .../devicetree/bindings/media/i2c/ov5647.txt   | 35 
>> ++
>>  1 file changed, 35 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt 
>> b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> new file mode 100644
>> index ..31956426d3b9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> @@ -0,0 +1,35 @@
>> +Omnivision OV5647 raw image sensor
>> +-
>> +
>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>> +and CCI (I2C compatible) control bus.
>> +
>> +Required properties:
>> +
>> +- compatible: "ovti,ov5647".
>> +- reg   : I2C slave address of the sensor.
>> +- clocks: Reference to the xclk clock.
>> +- clock-names   : Should be "xclk".
>> +- clock-frequency   : Frequency of the xclk clock.
>> +
>> +The common video interfaces bindings (see video-interfaces.txt) should be
>> +used to specify link to the image data receiver. The OV5647 device
>> +node should contain one 'port' child node with an 'endpoint' subnode.
> 
> The remote-endpoint property in endpoint nodes should be mandatory,
> shouldn't it? Otherwise the sensor isn't connected to anything and hardly
> useful as such. The list of optional endpoint properties is a long one and
> it should be documented here which ones are recognised, either as optional
> or mandatory.
> 

I guess you're right, it should be mandatory, although at the moment I'm not
checking for it's presence in the driver so I'll add it to the driver.

At the moment that's the only property I think it should be mandatory, and I
don't believe I need any optional one.

Do you have a suggestion for any new property I should use?

>> +
>> +Example:
>> +
>> +i2c@2000 {
>> +...
>> +ov: camera@36 {
>> +compatible = "ovti,ov5647";
>> +reg = <0x36>;
>> +clocks = <_clk>;
>> +clock-names = "xclk";
>> +clock-frequency = <2500>;
>> +port {
>> +camera_1: endpoint {
>> +remote-endpoint = <_ep1>;
>> +};
>> +};
>> +};
>> +};
> 

-- 
Best Regards

Ramiro Oliveira
ramiro.olive...@synopsys.com

Re: Looking more details and reasons for using orig_add_limit.

[Sodagudi Prasad]

Hi mchehab/linux-media,

It is not clear why KERNEL_DS was set explicitly here. In this path 
video_usercopy() gets  called  and it

copies the “struct v4l2_buffer” struct to user space stack memory.

Can you please share reasons for setting to KERNEL_DS here?

static long do_video_ioctl(struct file *file, unsigned int cmd, unsigned 
long arg)

{
…
…

if (compatible_arg)
err = native_ioctl(file, cmd, (unsigned long)up);
else {
mm_segment_t old_fs = get_fs();

set_fs(KERNEL_DS);
err = native_ioctl(file, cmd, (unsigned long));
set_fs(old_fs);
}
…
}

On 2017-02-16 02:39, James Morse wrote:

Hi Prasad,

On 15/02/17 21:12, Sodagudi Prasad wrote:

On 2017-02-15 04:09, James Morse wrote:

On 15/02/17 05:52, Sodagudi Prasad wrote:
that driver is calling set_fs(KERNEL_DS) and  then copy_to_user() to 
user space

memory.


Don't do this, its exactly the case PAN+UAO and the code you pointed 
to are
designed to catch. Accessing userspace needs doing carefully, setting 
USER_DS
and using the put_user()/copy_to_user() accessors are the required 
steps.


Which driver is doing this? Is it in mainline?


Yes. It is mainline driver - 
drivers/media/v4l2-core/v4l2-compat-ioctl32.c



In some v4l2 use-case kernel panic is observed. Below part
of the code has set_fs to KERNEL_DS before calling native_ioctl().

static long do_video_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)

{
…
…
if (compatible_arg)
err = native_ioctl(file, cmd, (unsigned long)up);
else {
mm_segment_t old_fs = get_fs();

set_fs(KERNEL_DS);   > KERNEL_DS.
err = native_ioctl(file, cmd, (unsigned long));
set_fs(old_fs);
}

Here is the call stack which is resulting crash, because user space 
memory has

read only permissions.
[27249.920041] [] __arch_copy_to_user+0x110/0x180
[27249.920047] [] video_ioctl2+0x38/0x44
[27249.920054] [] v4l2_ioctl+0x78/0xb4
[27249.920059] [] do_video_ioctl+0x91c/0x1160
[27249.920064] [] v4l2_compat_ioctl32+0x60/0xcc
[27249.920071] [] compat_SyS_ioctl+0x124/0xd88
[27249.920077] [] el0_svc_naked+0x24/0x2


It's not totally clear to me what is going on here, but some 
observations:
the ioctl is trying to copy_to_user() to some read-only memory.  This 
would
normally fail gracefully with -EFAULT, but because KERNEL_DS has been 
set, the

kernel checks this before calling the fault handler and calls die() on
your ioctl().

The ioctl code is doing this deliberately as a compat mechanism, but 
the code
behind file->f_op->unlocked_ioctl() expects fs==USER_DS when it does 
its work.
That code needs to be made aware of this compat translation, or a 
compat_ioctl

call provided.




Which v4l driver is this? Which ioctl is being called? Does the driver 
using the

v4l framework have a compat_ioctl() call?
Yes. Same kernel crash is seen with both video and camera use cases. 
Yes. Driver have compact_ioctl().


What path does this call take through v4l2_compat_ioctl32()? It looks 
like
compat_ioctl will be skipped in certain cases, v4l2_compat_ioctl32() 
has:

if (_IOC_TYPE(cmd) == 'V' && _IOC_NR(cmd) < BASE_VIDIOC_PRIVATE)
ret = do_video_ioctl(file, cmd, arg);
else if (vdev->fops->compat_ioctl32)
ret = vdev->fops->compat_ioctl32(file, cmd, arg);


Is your ioctl matched by that top if()?

Yes.  Top if condition in true and do_video_ioctl() getting called.



If there is permission fault for user space address the above 
condition
is leading to kernel crash. Because orig_add_limit is having 
KERNEL_DS as set_fs

called before copy_to_user().

1)So I would like to understand that,  is that user space 
pointer leading to

permission fault not correct(condition_1) in this scenario?


The correct thing has happened here. To access user space 
set_fs(USER_DS) first.

(and set it back to whatever it was afterwards).



So, Any clean up needed to above call path similar to what was done in 
the below

commit?
commit a7f61e89af73e9bf760826b20dba4e637221fcb9 - compat_ioctl: don't 
call

do_ioctl under set_fs(KERNEL_DS)


That's clever. Is that code doing a conversion, or do you have a 
compat_ioctl()

in your driver?

It's possible that fs/compat_ioctl.c has done this work, but 
do_video_ioctl()
un-does it. Someone who knows about v4l and compat-ioctls should take a 
look...



This looks like a case of:
The accidental invocation of an unlocked_ioctl handler that 
unexpectedly

calls copy_to_user could be a severe security issue.


that Jann describes in the commit message. Fixing the code behind
file->f_op->unlocked_ioctl() to consider compat calls from 
do_video_ioctl() is

one way to solve this.



Thanks,

James


-Thanks, Prasad
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

Linux Foundation Collaborative Project

Re: [PATCH] dma-buf: add support for compat ioctl

[Christian König]

Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:

Add compat ioctl support to dma-buf. This lets one to use DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for both 32
and 64bit modes are same, so there is no need for additional translation
layer.


Well I might be wrong, but IIRC compat_ioctl was just optional and if 
not specified unlocked_ioctl was called instead.


If that is true your patch wouldn't have any effect at all.

Regards,
Christian.



Signed-off-by: Marek Szyprowski 
---
  drivers/dma-buf/dma-buf.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 718f832a5c71..0007b792827b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -325,6 +325,9 @@ static long dma_buf_ioctl(struct file *file,
.llseek = dma_buf_llseek,
.poll   = dma_buf_poll,
.unlocked_ioctl = dma_buf_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl   = dma_buf_ioctl,
+#endif
  };
  
  /*

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Russell King - ARM Linux]

On Tue, Feb 21, 2017 at 02:37:57PM +0200, Sakari Ailus wrote:
> Hi Russell,
> 
> On Tue, Feb 21, 2017 at 12:13:32AM +, Russell King - ARM Linux wrote:
> > On Tue, Feb 21, 2017 at 12:04:10AM +0200, Sakari Ailus wrote:
> > > On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:
> > > > From: Russell King 
> > > > 
> > > > Setting and getting frame rates is part of the negotiation mechanism
> > > > between subdevs.  The lack of support means that a frame rate at the
> > > > sensor can't be negotiated through the subdev path.
> > > 
> > > Just wondering --- what do you need this for?
> > 
> > The v4l2 documentation contradicts the media-ctl implementation.
> > 
> > While v4l2 documentation says:
> > 
> >   These ioctls are used to get and set the frame interval at specific
> >   subdev pads in the image pipeline. The frame interval only makes sense
> >   for sub-devices that can control the frame period on their own. This
> >   includes, for instance, image sensors and TV tuners. Sub-devices that
> >   don't support frame intervals must not implement these ioctls.
> > 
> > However, when trying to configure the pipeline using media-ctl, eg:
> > 
> > media-ctl -d /dev/media1 --set-v4l2 '"imx219 pixel 
> > 0-0010":0[crop:(0,0)/3264x2464]'
> > media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> > 0-0010":1[fmt:SRGGB10/3264x2464@1/30]'
> > media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> > 0-0010":0[fmt:SRGGB8/816x616@1/30]'
> > media-ctl -d /dev/media1 --set-v4l2 
> > '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
> > Unable to setup formats: Inappropriate ioctl for device (25)
> > media-ctl -d /dev/media1 --set-v4l2 
> > '"ipu1_csi0_mux":2[fmt:SRGGB8/816x616@1/30]'
> > media-ctl -d /dev/media1 --set-v4l2 '"ipu1_csi0":2[fmt:SRGGB8/816x616@1/30]'
> > 
> > The problem there is that the format setting for the csi2 does not get
> > propagated forward:
> 
> The CSI-2 receivers typically do not implement frame interval IOCTLs as they
> do not control the frame interval. Some sensors or TV tuners typically do,
> so they implement these IOCTLs.

No, TV tuners do not.  The frame rate for a TV tuner is set by the
broadcaster, not by the tuner.  The tuner can't change that frame rate.
The tuner may opt to "skip" fields or frames.  That's no different from
what the CSI block in my example below is capable of doing.

Treating a tuner differently from the CSI block is inconsistent and
completely wrong.

> There are alternative ways to specify the frame rate.

Empty statements (or hand-waving type statements) I'm afraid don't
contribute to the discussion, because they mean nothing to me.  Please
give an example, or flesh out what you mean.

> > $ strace media-ctl -d /dev/media1 --set-v4l2 
> > '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
> > ...
> > open("/dev/v4l-subdev16", O_RDWR)   = 3
> > ioctl(3, VIDIOC_SUBDEV_S_FMT, 0xbec16244) = 0
> > ioctl(3, VIDIOC_SUBDEV_S_FRAME_INTERVAL, 0xbec162a4) = -1 ENOTTY 
> > (Inappropriate
> > ioctl for device)
> > fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
> > write(1, "Unable to setup formats: Inappro"..., 61) = 61
> > Unable to setup formats: Inappropriate ioctl for device (25)
> > close(3)= 0
> > exit_group(1)   = ?
> > +++ exited with 1 +++
> > 
> > because media-ctl exits as soon as it encouters the error while trying
> > to set the frame rate.
> > 
> > This makes implementing setup of the media pipeline in shell scripts
> > unnecessarily difficult - as you need to then know whether an entity
> > is likely not to support the VIDIOC_SUBDEV_S_FRAME_INTERVAL call,
> > and either avoid specifying a frame rate:
> 
> You should remove the frame interval setting from sub-devices that do not
> support it.

That means we end up with horribly complex scripts.  This "solution" does
not scale.  Therefore, it is not a "solution".

It's fine if you want to write a script to setup the media pipeline using
media-ctl, listing _each_ media-ctl command individually, with arguments
specific to each step, but as I've already said, that does not scale.

I don't want to end up writing separate scripts to configure the pipeline
for different parameters or setups.  I don't want to teach users how to
do that either.

How are users supposed to cope with this craziness?  Are they expected to
write their own scripts and understand this stuff?

As far as I can see, there are no applications out there at the moment that
come close to understanding how to configure a media pipeline, so users
have to understand how to use media-ctl to configure the pipeline manually.
Are we really expecting users to write scripts to do this, and understand
all these nuances?

IMHO, this is completely crazy, and hasn't been fully thought out.

> > $ strace media-ctl -d /dev/media1 --set-v4l2 
> > '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616]'
> > ...
> > open("/dev/v4l-subdev16", O_RDWR)   = 3
> > ioctl(3, 

[PATCH] dma-buf: add support for compat ioctl

[Marek Szyprowski]

Add compat ioctl support to dma-buf. This lets one to use DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for both 32
and 64bit modes are same, so there is no need for additional translation
layer.

Signed-off-by: Marek Szyprowski 
---
 drivers/dma-buf/dma-buf.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 718f832a5c71..0007b792827b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -325,6 +325,9 @@ static long dma_buf_ioctl(struct file *file,
.llseek = dma_buf_llseek,
.poll   = dma_buf_poll,
.unlocked_ioctl = dma_buf_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl   = dma_buf_ioctl,
+#endif
 };
 
 /*
-- 
1.9.1

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

On 2/21/17, Sean Young  wrote:
> Hi Vincent,
>
...
>
> On the cxusb the protocol is now nec, and that is the only protocol it
> supports, you can't change it.
>

doh! ok well that's all good then.

>> $ sudo cat /sys/class/rc/rc1/protocols
>> nec
>> $ sudo sh
>> # echo "+rc-5 +nec +rc-6 +jvc +sony +rc-5-sz +sanyo +sharp +xmp" >
>> /sys/class/rc/rc1/protocols
>> bash: echo: write error: Invalid argument
>> # cat  /sys/class/rc/rc1/protocols
>> nec
>> In kern.log I got:
>> kernel: [ 2293.491534] rc_core: Normal protocol change requested
>> kernel: [ 2293.491538] rc_core: Protocol switching not supported
>>
>> # echo "+nec" > /sys/class/rc/rc1/protocols
>> bash: echo: write error: Invalid argument
>> kernel: [ 2390.832476] rc_core: Normal protocol change requested
>> kernel: [ 2390.832481] rc_core: Protocol switching not supported
>
> That is expected. Does the the keymap actually work?
>
> ir-keytable -r -t

Kind of important information, yes. Answer: not sure. I can see it
receiving something but none of the keys I pressed caused any reaction
on the application (mythtv)

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

# ir-keytable -r -t -d /dev/input/event11
scancode 0xfe01 = KEY_R (0x13)
scancode 0xfe02 = KEY_TV (0x179)
scancode 0xfe03 = KEY_0 (0x0b)
scancode 0xfe05 = KEY_VOLUMEDOWN (0x72)
scancode 0xfe07 = KEY_4 (0x05)
scancode 0xfe09 = KEY_CHANNELDOWN (0x193)
scancode 0xfe0a = KEY_EPG (0x16d)
scancode 0xfe0b = KEY_1 (0x02)
scancode 0xfe0d = KEY_ESC (0x01)
scancode 0xfe0e = KEY_MP3 (0x187)
scancode 0xfe0f = KEY_PREVIOUSSONG (0xa5)
scancode 0xfe11 = KEY_CHANNELUP (0x192)
scancode 0xfe12 = KEY_NEXTSONG (0xa3)
scancode 0xfe13 = KEY_ANGLE (0x173)
scancode 0xfe15 = KEY_VOLUMEUP (0x73)
scancode 0xfe16 = KEY_SETUP (0x8d)
scancode 0xfe17 = KEY_2 (0x03)
scancode 0xfe19 = KEY_OPEN (0x86)
scancode 0xfe1a = KEY_DVD (0x185)
scancode 0xfe1b = KEY_3 (0x04)
scancode 0xfe1e = KEY_FAVORITES (0x16c)
scancode 0xfe1f = KEY_ZOOM (0x174)
scancode 0xfe42 = KEY_ENTER (0x1c)
scancode 0xfe43 = KEY_REWIND (0xa8)
scancode 0xfe46 = KEY_POWER2 (0x164)
scancode 0xfe47 = KEY_P (0x19)
scancode 0xfe48 = KEY_7 (0x08)
scancode 0xfe49 = KEY_ESC (0x01)
scancode 0xfe4c = KEY_8 (0x09)
scancode 0xfe4d = KEY_M (0x32)
scancode 0xfe4e = KEY_POWER (0x74)
scancode 0xfe4f = KEY_FASTFORWARD (0xd0)
scancode 0xfe50 = KEY_5 (0x06)
scancode 0xfe51 = KEY_UP (0x67)
scancode 0xfe52 = KEY_CAMERA (0xd4)
scancode 0xfe53 = KEY_DOWN (0x6c)
scancode 0xfe54 = KEY_6 (0x07)
scancode 0xfe55 = KEY_TAB (0x0f)
scancode 0xfe57 = KEY_MUTE (0x71)
scancode 0xfe58 = KEY_9 (0x0a)
scancode 0xfe59 = KEY_INFO (0x166)
scancode 0xfe5a = KEY_TUNER (0x182)
scancode 0xfe5b = KEY_LEFT (0x69)
scancode 0xfe5e = KEY_ENTER (0x1c)
scancode 0xfe5f = KEY_RIGHT (0x6a)
Enabled protocols: other sony nec sanyo mce-kbd rc-6 sharp xmp
Testing events. Please, press CTRL-C to abort.
  # pressed '1' key
1487676458.742329: event type EV_MSC(0x04): scancode = 0x010b
1487676458.742329: event type EV_SYN(0x00).
  # '2'
1487676481.742284: event type EV_MSC(0x04): scancode = 0x0117
1487676481.742284: event type EV_SYN(0x00).
  # '8'
1487676504.842250: event type EV_MSC(0x04): scancode = 0x014c
1487676504.842250: event type EV_SYN(0x00).
  # '9'
1487676506.542243: event type EV_MSC(0x04): scancode = 0x0158
1487676506.542243: event type EV_SYN(0x00).
  # right-arrow
1487676551.942312: event type EV_MSC(0x04): scancode = 0x015f
1487676551.942312: event type EV_SYN(0x00).
  # vol down
1487676637.746348: event type EV_MSC(0x04): scancode = 0x0105
1487676637.746348: event type EV_SYN(0x00).
  # vol up
1487676642.746321: event type EV_MSC(0x04): scancode = 0x0115
1487676642.746321: event type EV_SYN(0x00).

# cat /sys/class/rc/rc1/protocols
nec

All the above was done with the system booted with this in /etc/rc.local
/usr/bin/ir-keytable -s rc1 -c
/usr/bin/ir-keytable -s rc1 -w /etc/rc_keymaps/dvico-remote

After I disabled the rc.local script and rebooted:
# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event10) with:
Driver imon, table rc-imon-mce
Supported 

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Sakari Ailus]

Hi Russell,

On Tue, Feb 21, 2017 at 12:13:32AM +, Russell King - ARM Linux wrote:
> On Tue, Feb 21, 2017 at 12:04:10AM +0200, Sakari Ailus wrote:
> > On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:
> > > From: Russell King 
> > > 
> > > Setting and getting frame rates is part of the negotiation mechanism
> > > between subdevs.  The lack of support means that a frame rate at the
> > > sensor can't be negotiated through the subdev path.
> > 
> > Just wondering --- what do you need this for?
> 
> The v4l2 documentation contradicts the media-ctl implementation.
> 
> While v4l2 documentation says:
> 
>   These ioctls are used to get and set the frame interval at specific
>   subdev pads in the image pipeline. The frame interval only makes sense
>   for sub-devices that can control the frame period on their own. This
>   includes, for instance, image sensors and TV tuners. Sub-devices that
>   don't support frame intervals must not implement these ioctls.
> 
> However, when trying to configure the pipeline using media-ctl, eg:
> 
> media-ctl -d /dev/media1 --set-v4l2 '"imx219 pixel 
> 0-0010":0[crop:(0,0)/3264x2464]'
> media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> 0-0010":1[fmt:SRGGB10/3264x2464@1/30]'
> media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> 0-0010":0[fmt:SRGGB8/816x616@1/30]'
> media-ctl -d /dev/media1 --set-v4l2 
> '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
> Unable to setup formats: Inappropriate ioctl for device (25)
> media-ctl -d /dev/media1 --set-v4l2 
> '"ipu1_csi0_mux":2[fmt:SRGGB8/816x616@1/30]'
> media-ctl -d /dev/media1 --set-v4l2 '"ipu1_csi0":2[fmt:SRGGB8/816x616@1/30]'
> 
> The problem there is that the format setting for the csi2 does not get
> propagated forward:

The CSI-2 receivers typically do not implement frame interval IOCTLs as they
do not control the frame interval. Some sensors or TV tuners typically do,
so they implement these IOCTLs.

There are alternative ways to specify the frame rate.

> 
> $ strace media-ctl -d /dev/media1 --set-v4l2 
> '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
> ...
> open("/dev/v4l-subdev16", O_RDWR)   = 3
> ioctl(3, VIDIOC_SUBDEV_S_FMT, 0xbec16244) = 0
> ioctl(3, VIDIOC_SUBDEV_S_FRAME_INTERVAL, 0xbec162a4) = -1 ENOTTY 
> (Inappropriate
> ioctl for device)
> fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
> write(1, "Unable to setup formats: Inappro"..., 61) = 61
> Unable to setup formats: Inappropriate ioctl for device (25)
> close(3)= 0
> exit_group(1)   = ?
> +++ exited with 1 +++
> 
> because media-ctl exits as soon as it encouters the error while trying
> to set the frame rate.
> 
> This makes implementing setup of the media pipeline in shell scripts
> unnecessarily difficult - as you need to then know whether an entity
> is likely not to support the VIDIOC_SUBDEV_S_FRAME_INTERVAL call,
> and either avoid specifying a frame rate:

You should remove the frame interval setting from sub-devices that do not
support it.

> 
> $ strace media-ctl -d /dev/media1 --set-v4l2 
> '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616]'
> ...
> open("/dev/v4l-subdev16", O_RDWR)   = 3
> ioctl(3, VIDIOC_SUBDEV_S_FMT, 0xbeb1a254) = 0
> open("/dev/v4l-subdev0", O_RDWR)= 4
> ioctl(4, VIDIOC_SUBDEV_S_FMT, 0xbeb1a254) = 0
> close(4)= 0
> close(3)= 0
> exit_group(0)   = ?
> +++ exited with 0 +++
> 
> or manually setting the format on the sink.
> 
> Allowing the S_FRAME_INTERVAL call seems to me to be more in keeping
> with the negotiation mechanism that is implemented in subdevs, and
> IMHO should be implemented inside the kernel as a pad operation along
> with the format negotiation, especially so as frame skipping is
> defined as scaling, in just the same way as the frame size is also
> scaling:

The origins of the S_FRAME_INTERVAL IOCTL for sub-devices are the S_PARM
IOCTL for video nodes. It is used to control the frame rate for more simple
devices that do not expose the Media controller interface. The similar
S_FRAME_INTERVAL was added for sub-devices as well, and it has been so far
used to control the frame interval for sensors (and G_FRAME_INTERVAL to
obtain the frame interval for TV tuners, for instance).

The pad argument was added there but media-ctl only supported setting the
frame interval on pad 0, which, coincidentally, worked well for sensor
devices.

The link validation is primarily done in order to ensure the validity of the
hardware configuration: streaming may not be started if the hardware
configuration is not valid.

Also, frame interval is not a static property during streaming: it may be
changed without the knowledge of the other sub-device drivers downstream. It
neither is a property of hardware receiving or processing images: if there
are limitations in processing pixels, then they in practice are related to
pixel rates or 

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Sakari Ailus]

Hi Steve,

On Mon, Feb 20, 2017 at 02:56:15PM -0800, Steve Longerbeam wrote:
> 
> 
> On 02/20/2017 02:04 PM, Sakari Ailus wrote:
> >Hi Steve,
> >
> >On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:
> >>From: Russell King 
> >>
> >>Setting and getting frame rates is part of the negotiation mechanism
> >>between subdevs.  The lack of support means that a frame rate at the
> >>sensor can't be negotiated through the subdev path.
> >
> >Just wondering --- what do you need this for?
> 
> 
> Hi Sakari,
> 
> i.MX does need the ability to negotiate the frame rates in the
> pipelines. The CSI has the ability to skip frames at the output,
> which is something Philipp added to the CSI subdev. That affects
> frame interval at the CSI output.
> 
> But as Russell pointed out, the lack of [gs]_frame_interval op
> causes media-ctl to fail:
> 
> media-ctl -v -d /dev/media1 --set-v4l2
> '"imx6-mipi-csi2":1[fmt:SGBRG8/512x512@1/30]'
> 
> Opening media device /dev/media1
> Enumerating entities
> Found 29 entities
> Enumerating pads and links
> Setting up format SGBRG8 512x512 on pad imx6-mipi-csi2/1
> Format set: SGBRG8 512x512
> Setting up frame interval 1/30 on entity imx6-mipi-csi2
> Unable to set frame interval: Inappropriate ioctl for device (-25)Unable to
> setup formats: Inappropriate ioctl for device (25)
> 
> 
> So i.MX needs to implement this op in every subdev in the
> pipeline, otherwise it's not possible to configure the
> pipeline with media-ctl.

The frame rate is only set on the sub-device which you explicitly set it.
I.e. setting the frame rate fails if it's not supported on a pad.

Philipp recently posted patches that add frame rate propagation to
media-ctl.

Frame rate is typically settable (and gettable) only on sensor sub-device's
source pad, which means it normally would not be propagated by the kernel
but with Philipp's patches, on the sink pad of the bus receiver. Receivers
don't have a way to control it nor they implement the IOCTLs, so that would
indeed result in an error.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Sakari Ailus]

Hi Ramiro,

A few minor comments below.

On Fri, Feb 17, 2017 at 01:14:16PM +, Ramiro Oliveira wrote:
> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
> and RAW 10 output formats, and MIPI CSI-2 interface.
> 
> The driver adds support for 640x480 RAW 8.
> 
> Signed-off-by: Ramiro Oliveira 
> ---
>  MAINTAINERS|   7 +
>  drivers/media/i2c/Kconfig  |  11 +
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/ov5647.c | 638 
> +
>  4 files changed, 657 insertions(+)
>  create mode 100644 drivers/media/i2c/ov5647.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8e7e8d7855ee..7bbca271acc8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9109,6 +9109,13 @@ M: Harald Welte 
>  S:   Maintained
>  F:   drivers/char/pcmcia/cm4040_cs.*
>  
> +OMNIVISION OV5647 SENSOR DRIVER
> +M:   Ramiro Oliveira 
> +L:   linux-media@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Maintained
> +F:   drivers/media/i2c/ov5647.c
> +
>  OMNIVISION OV7670 SENSOR DRIVER
>  M:   Jonathan Corbet 
>  L:   linux-media@vger.kernel.org
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index cee1dae6e014..8435b99f38bc 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -531,6 +531,17 @@ config VIDEO_OV2659
> To compile this driver as a module, choose M here: the
> module will be called ov2659.
>  
> +config VIDEO_OV5647
> + tristate "OmniVision OV5647 sensor support"
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CAMERA_SUPPORT
> + ---help---
> +   This is a Video4Linux2 sensor-level driver for the OmniVision
> +   OV5647 camera.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ov5647.
> +
>  config VIDEO_OV7640
>   tristate "OmniVision OV7640 sensor support"
>   depends on I2C && VIDEO_V4L2
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 5bc7bbeb5499..ef2ccf65f94c 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
>  obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
>  obj-$(CONFIG_VIDEO_OV2659)   += ov2659.o
>  obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
> +obj-$(CONFIG_VIDEO_OV5647)   += ov5647.o
> diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
> new file mode 100644
> index ..34e620fabbaf
> --- /dev/null
> +++ b/drivers/media/i2c/ov5647.c
> @@ -0,0 +1,638 @@
> +/*
> + * A V4L2 driver for OmniVision OV5647 cameras.
> + *
> + * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver
> + * Copyright (C) 2011 Sylwester Nawrocki 
> + *
> + * Based on Omnivision OV7670 Camera Driver
> + * Copyright (C) 2006-7 Jonathan Corbet 
> + *
> + * Copyright (C) 2016, Synopsys, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed .as is. WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; 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 

You don't seem to implement any controls.

The sensor likely supports exposure time (and maybe also gain) the user
might want to control. Is there an intent to add that? Otherwise the header
should be removed.

> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SENSOR_NAME "ov5647"
> +
> +#define OV5647_SW_RESET  0x1003
> +#define OV5647_REG_CHIPID_H  0x300A
> +#define OV5647_REG_CHIPID_L  0x300B
> +
> +#define REG_TERM 0xfffe
> +#define VAL_TERM 0xfe
> +#define REG_DLY  0x
> +
> +#define OV5647_ROW_START 0x01
> +#define OV5647_ROW_START_MIN 0
> +#define OV5647_ROW_START_MAX 2004
> +#define OV5647_ROW_START_DEF 54
> +
> +#define OV5647_COLUMN_START  0x02
> +#define OV5647_COLUMN_START_MIN  0
> +#define OV5647_COLUMN_START_MAX  2750
> +#define OV5647_COLUMN_START_DEF  16
> +
> +#define OV5647_WINDOW_HEIGHT 0x03
> +#define OV5647_WINDOW_HEIGHT_MIN 2
> +#define OV5647_WINDOW_HEIGHT_MAX 2006
> +#define OV5647_WINDOW_HEIGHT_DEF 1944
> +
> +#define OV5647_WINDOW_WIDTH  0x04
> +#define OV5647_WINDOW_WIDTH_MIN  2
> +#define OV5647_WINDOW_WIDTH_MAX  2752
> +#define OV5647_WINDOW_WIDTH_DEF  2592
> +
> +struct regval_list {
> + 

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Ramiro,

On Fri, Feb 17, 2017 at 01:14:15PM +, Ramiro Oliveira wrote:
> Create device tree bindings documentation.
> 
> Signed-off-by: Ramiro Oliveira 
> Acked-by: Rob Herring 
> ---
>  .../devicetree/bindings/media/i2c/ov5647.txt   | 35 
> ++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt 
> b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> new file mode 100644
> index ..31956426d3b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> @@ -0,0 +1,35 @@
> +Omnivision OV5647 raw image sensor
> +-
> +
> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> +and CCI (I2C compatible) control bus.
> +
> +Required properties:
> +
> +- compatible : "ovti,ov5647".
> +- reg: I2C slave address of the sensor.
> +- clocks : Reference to the xclk clock.
> +- clock-names: Should be "xclk".
> +- clock-frequency: Frequency of the xclk clock.
> +
> +The common video interfaces bindings (see video-interfaces.txt) should be
> +used to specify link to the image data receiver. The OV5647 device
> +node should contain one 'port' child node with an 'endpoint' subnode.

The remote-endpoint property in endpoint nodes should be mandatory,
shouldn't it? Otherwise the sensor isn't connected to anything and hardly
useful as such. The list of optional endpoint properties is a long one and
it should be documented here which ones are recognised, either as optional
or mandatory.

> +
> +Example:
> +
> + i2c@2000 {
> + ...
> + ov: camera@36 {
> + compatible = "ovti,ov5647";
> + reg = <0x36>;
> + clocks = <_clk>;
> + clock-names = "xclk";
> + clock-frequency = <2500>;
> + port {
> + camera_1: endpoint {
> + remote-endpoint = <_ep1>;
> + };
> + };
> + };
> + };

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH] omap3isp: avoid uninitialized memory

[Sakari Ailus]

Hi Pavel,

On Mon, Feb 20, 2017 at 01:06:47PM +0100, Pavel Machek wrote:
> 
> Code in ispcsiphy is quite confusing, and does not initialize phy1 in
> case of isp rev. 2. Set it to zero, to prevent confusion.
> 
> Signed-off-by: Pavel Machek 
> 
> index 8f73f6d..a2474b6 100644
> --- a/drivers/media/platform/omap3isp/ispcsiphy.c
> +++ b/drivers/media/platform/omap3isp/ispcsiphy.c
> @@ -362,14 +374,16 @@ int omap3isp_csiphy_init(struct isp_device *isp)
>   phy2->phy_regs = OMAP3_ISP_IOMEM_CSIPHY2;
>   mutex_init(>mutex);
>  
> - if (isp->revision == ISP_REVISION_15_0) {
> - phy1->isp = isp;
> - phy1->csi2 = >isp_csi2c;
> - phy1->num_data_lanes = ISP_CSIPHY1_NUM_DATA_LANES;
> - phy1->cfg_regs = OMAP3_ISP_IOMEM_CSI2C_REGS1;
> - phy1->phy_regs = OMAP3_ISP_IOMEM_CSIPHY1;
> - mutex_init(>mutex);
> + if (isp->revision != ISP_REVISION_15_0) {
> + memset(phy1, sizeof(*phy1), 0);
> + return 0;

Isn't the memory allocated using kzalloc(), meaning it's already zero?

>   }
>  
> + phy1->isp = isp;
> + phy1->csi2 = >isp_csi2c;
> + phy1->num_data_lanes = ISP_CSIPHY1_NUM_DATA_LANES;
> + phy1->cfg_regs = OMAP3_ISP_IOMEM_CSI2C_REGS1;
> + phy1->phy_regs = OMAP3_ISP_IOMEM_CSIPHY1;
> + mutex_init(>mutex);
>   return 0;
>  }
> 
> 

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v2 01/15] media: s5p-mfc: Remove unused structures and dead code

[Andrzej Hajda]

On 20.02.2017 14:38, Marek Szyprowski wrote:
> Remove unused structures, definitions and functions that are no longer
> called from the driver code.
>
> Signed-off-by: Marek Szyprowski 
> Reviewed-by: Javier Martinez Canillas 
> Tested-by: Javier Martinez Canillas 

For the whole patchset:

Acked-by: Andrzej Hajda 
--
Regards
Andrzej


> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc.c| 21 -
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 13 -
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h   |  1 -
>  3 files changed, 35 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index 05fe82be6584..3e1f22eb4339 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1422,16 +1422,11 @@ static int s5p_mfc_resume(struct device *dev)
>   .priv   = _buf_size_v5,
>  };
>  
> -static struct s5p_mfc_buf_align mfc_buf_align_v5 = {
> - .base = MFC_BASE_ALIGN_ORDER,
> -};
> -
>  static struct s5p_mfc_variant mfc_drvdata_v5 = {
>   .version= MFC_VERSION,
>   .version_bit= MFC_V5_BIT,
>   .port_num   = MFC_NUM_PORTS,
>   .buf_size   = _size_v5,
> - .buf_align  = _buf_align_v5,
>   .fw_name[0] = "s5p-mfc.fw",
>   .clk_names  = {"mfc", "sclk_mfc"},
>   .num_clocks = 2,
> @@ -1452,16 +1447,11 @@ static int s5p_mfc_resume(struct device *dev)
>   .priv   = _buf_size_v6,
>  };
>  
> -static struct s5p_mfc_buf_align mfc_buf_align_v6 = {
> - .base = 0,
> -};
> -
>  static struct s5p_mfc_variant mfc_drvdata_v6 = {
>   .version= MFC_VERSION_V6,
>   .version_bit= MFC_V6_BIT,
>   .port_num   = MFC_NUM_PORTS_V6,
>   .buf_size   = _size_v6,
> - .buf_align  = _buf_align_v6,
>   .fw_name[0] = "s5p-mfc-v6.fw",
>   /*
>* v6-v2 firmware contains bug fixes and interface change
> @@ -1486,16 +1476,11 @@ static int s5p_mfc_resume(struct device *dev)
>   .priv   = _buf_size_v7,
>  };
>  
> -static struct s5p_mfc_buf_align mfc_buf_align_v7 = {
> - .base = 0,
> -};
> -
>  static struct s5p_mfc_variant mfc_drvdata_v7 = {
>   .version= MFC_VERSION_V7,
>   .version_bit= MFC_V7_BIT,
>   .port_num   = MFC_NUM_PORTS_V7,
>   .buf_size   = _size_v7,
> - .buf_align  = _buf_align_v7,
>   .fw_name[0] = "s5p-mfc-v7.fw",
>   .clk_names  = {"mfc", "sclk_mfc"},
>   .num_clocks = 2,
> @@ -1515,16 +1500,11 @@ static int s5p_mfc_resume(struct device *dev)
>   .priv   = _buf_size_v8,
>  };
>  
> -static struct s5p_mfc_buf_align mfc_buf_align_v8 = {
> - .base = 0,
> -};
> -
>  static struct s5p_mfc_variant mfc_drvdata_v8 = {
>   .version= MFC_VERSION_V8,
>   .version_bit= MFC_V8_BIT,
>   .port_num   = MFC_NUM_PORTS_V8,
>   .buf_size   = _size_v8,
> - .buf_align  = _buf_align_v8,
>   .fw_name[0] = "s5p-mfc-v8.fw",
>   .clk_names  = {"mfc"},
>   .num_clocks = 1,
> @@ -1535,7 +1515,6 @@ static int s5p_mfc_resume(struct device *dev)
>   .version_bit= MFC_V8_BIT,
>   .port_num   = MFC_NUM_PORTS_V8,
>   .buf_size   = _size_v8,
> - .buf_align  = _buf_align_v8,
>   .fw_name[0] = "s5p-mfc-v8.fw",
>   .clk_names  = {"pclk", "aclk", "aclk_xiu"},
>   .num_clocks = 3,
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index ab23236aa942..3e0e8eaf8bfe 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -44,14 +44,6 @@
>  
>  #include 
>  
> -static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void *b)
> -{
> - /* Same functionality as the vb2_dma_contig_plane_paddr */
> - dma_addr_t *paddr = vb2_dma_contig_memops.cookie(b);
> -
> - return *paddr;
> -}
> -
>  /* MFC definitions */
>  #define MFC_MAX_EXTRA_DPB   5
>  #define MFC_MAX_BUFFERS  32
> @@ -229,16 +221,11 @@ struct s5p_mfc_buf_size {
>   void *priv;
>  };
>  
> -struct s5p_mfc_buf_align {
> - unsigned int base;
> -};
> -
>  struct s5p_mfc_variant {
>   unsigned int version;
>   unsigned int port_num;
>   u32 version_bit;
>   struct s5p_mfc_buf_size *buf_size;
> - struct s5p_mfc_buf_align *buf_align;
>   char*fw_name[MFC_FW_MAX_VERSIONS];
>   const char  *clk_names[MFC_MAX_CLOCKS];
>   int num_clocks;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h
> index 8e5df041edf7..45c807bf19cc 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h
> @@ -18,7 +18,6 @@
>  int 

Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times

[Sakari Ailus]

On Tue, Feb 21, 2017 at 12:07:21PM +0100, Pavel Machek wrote:
> On Mon 2017-02-20 15:56:36, Sakari Ailus wrote:
> > On Mon, Feb 20, 2017 at 03:09:13PM +0200, Sakari Ailus wrote:
> > > I've tested ACPI, will test DT soon...
> > 
> > DT case works, too (Nokia N9).
> 
> Hmm. Good to know. Now to figure out how to get N900 case to work...
> 
> AFAICT N9 has CSI2, not CSI1 support, right? Some of the core changes
> seem to be in, so I'll need to figure out which, and will still need
> omap3isp modifications...

Indeed, I've only tested for CSI-2 as I have no functional CSI-1 devices.

It's essentially the functionality in the four patches. The data-lane and
clock-name properties have been renamed as data-lanes and clock-lanes (i.e.
plural) to match the property documentation.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times

[Pavel Machek]

On Mon 2017-02-20 15:56:36, Sakari Ailus wrote:
> On Mon, Feb 20, 2017 at 03:09:13PM +0200, Sakari Ailus wrote:
> > I've tested ACPI, will test DT soon...
> 
> DT case works, too (Nokia N9).

Hmm. Good to know. Now to figure out how to get N900 case to work...

AFAICT N9 has CSI2, not CSI1 support, right? Some of the core changes
seem to be in, so I'll need to figure out which, and will still need
omap3isp modifications...

Best regards,
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

Re: [PATCH v4 4/4] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

[Andrzej Hajda]

On 13.02.2017 20:08, Thibault Saunier wrote:
> It is required by the standard that the field order is set by the
> driver.
>
> Signed-off-by: Thibault Saunier 
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous 
> review
>
> Changes in v2:
> - Fix a silly build error that slipped in while rebasing the patches
>
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 0976c3e0a5ce..c954b34cb988 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -385,6 +385,20 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>   struct s5p_mfc_dev *dev = video_drvdata(file);
>   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
>   struct s5p_mfc_fmt *fmt;
> + enum v4l2_field field;
> +
> + field = f->fmt.pix.field;
> + if (field == V4L2_FIELD_ANY) {
> + field = V4L2_FIELD_NONE;
> + } else if (field != V4L2_FIELD_NONE) {
> + mfc_debug(2, "Not supported field order(%d)\n", pix_mp->field);
> + return -EINVAL;
> + }
> +
> + /* V4L2 specification suggests the driver corrects the format struct
> +  * if any of the dimensions is unsupported
> +  */
> + f->fmt.pix.field = field;

It looks like you missed my previous comment.
--
Regards
Andrzej

>  
>   mfc_debug(2, "Type is %d\n", f->type);
>   if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {

Re: [PATCH v4 2/4] [media] exynos-gsc: Respect userspace colorspace setting in try_fmt

[Andrzej Hajda]

On 13.02.2017 20:08, Thibault Saunier wrote:
> User userspace provided by the user as we are only doing scaling and
> color encoding conversion, we won't be able to transform the colorspace
> itself and the colorspace won't mater in that operation.
>
> Also always use output colorspace on the capture side.
>
> Signed-off-by: Thibault Saunier 

This patch can be squashed with previous one as the only thing to do is
to set output colorspace the same as capture colorspace.

--
Regards
Andrzej

>
> ---
>
> Changes in v4:
> - Use any colorspace provided by the user as it won't affect the way we
>   handle our operations (guessing it if none is provided)
> - Always use output colorspace on the capture side
>
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous 
> review
> - Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in
>
> Changes in v2: None
>
>  drivers/media/platform/exynos-gsc/gsc-core.c | 14 ++
>  drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
>  2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index db7d9883861b..772599de8c13 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   } else {
>   min_w = variant->pix_min->target_rot_dis_w;
>   min_h = variant->pix_min->target_rot_dis_h;
> + pix_mp->colorspace = ctx->out_colorspace;
>   }
>  
>   pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d",
> @@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>  
>   pix_mp->num_planes = fmt->num_planes;
>  
> - if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> - pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> - else /* SD */
> - pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> + if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> + pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> + else /* SD */
> + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> + }
> +
> + if (V4L2_TYPE_IS_OUTPUT(f->type))
> + ctx->out_colorspace = pix_mp->colorspace;
>  
>   for (i = 0; i < pix_mp->num_planes; ++i) {
>   struct v4l2_plane_pix_format *plane_fmt = _mp->plane_fmt[i];
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h 
> b/drivers/media/platform/exynos-gsc/gsc-core.h
> index 696217e9af66..715d9c9d8d30 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.h
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.h
> @@ -376,6 +376,7 @@ struct gsc_ctx {
>   struct v4l2_ctrl_handler ctrl_handler;
>   struct gsc_ctrlsgsc_ctrls;
>   boolctrls_rdy;
> + enum v4l2_colorspace out_colorspace;
>  };
>  
>  void gsc_set_prefbuf(struct gsc_dev *gsc, struct gsc_frame *frm);

Re: [PATCH v4 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Andrzej Hajda]

On 13.02.2017 20:08, Thibault Saunier wrote:
> From: Javier Martinez Canillas 
>
> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
> don't agree on the display resolution that should be used as a threshold.
>
> >From EIA CEA 861B about colorimetry for various resolutions:
>
>   - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
> The color space used by the 480-line, 576-line, 240-line, and 288-line
> formats will likely be based on SMPTE 170M [1].
>   - 5.2 1080i, 1080p, and 720p
> The color space used by the high definition formats will likely be
> based on ITU-R BT.709-4
>
> This indicates that in the case that userspace does not specify what
> colorspace should be used, we should use 576p  as a threshold to set
> V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_REC709. Even if it is
> only 'likely' and not a requirement it is the best guess we can make.
>
> The stream should have been encoded with the information and userspace
> has to pass it to the driver if it is not the case, otherwise we won't be
> able to handle it properly anyhow.
>
> Also, check for the resolution in G_FMT instead unconditionally setting
> the V4L2_COLORSPACE_REC709 colorspace.
>
> Signed-off-by: Javier Martinez Canillas 
> Signed-off-by: Thibault Saunier 
> Reviewed-by: Andrzej Hajda 

Hi Thibault,

Have you analyzed Hans response for the previous patchset [1] ?
I am not an expert in the subject but it seems he is right. GSCALER
datasheet uses term 'color space conversion' to describe conversions
between RGB and YCbCr, not for describe colorspaces as in V4L2.
GSC_(IN|OUT)_RGB_(HD|SD)_(WIDE|NARROW) macros used to set IN_CON and
OUT_CON registers of GSCALER are probably used incorrectly, they should
not be set according to pix_mp->colorspace but rather according to
pix_mp->ycbcr_enc and pix_mp->quantization. pix_mp->colorspace should be
just copied from output to capture side.

Please fix the patch accordingly, and if you are interested you can
prepare another patch to fix register setting.

[1]: https://lkml.org/lkml/2017/2/10/473

Regards
Andrzej

>
> ---
>
> Changes in v4:
> - Reword commit message to better back our assumptions on specifications
>
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous 
> review
> - Added 'Reviewed-by: Andrzej Hajda '
>
> Changes in v2: None
>
>  drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 59a634201830..db7d9883861b 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>  
>   pix_mp->num_planes = fmt->num_planes;
>  
> - if (pix_mp->width >= 1280) /* HD */
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
>   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
>   else /* SD */
>   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> @@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   pix_mp->height  = frame->f_height;
>   pix_mp->field   = V4L2_FIELD_NONE;
>   pix_mp->pixelformat = frame->fmt->pixelformat;
> - pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
>   pix_mp->num_planes  = frame->fmt->num_planes;
>  
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> + pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> + else /* SD */
> + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> +
>   for (i = 0; i < pix_mp->num_planes; ++i) {
>   pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
>   frame->fmt->depth[i]) / 8;

Re: [bug report] [media] st-delta: add mjpeg support

[Hugues FRUCHET]

Thanks Dan,

Patch sent to fix warning:
https://www.spinics.net/lists/linux-media/msg111529.html

BR,
Hugues.

On 02/13/2017 08:07 PM, Dan Carpenter wrote:
> Hello Hugues Fruchet,
>
> The patch 433ff5b4a29b: "[media] st-delta: add mjpeg support" from
> Feb 2, 2017, leads to the following static checker warning:
>
>   drivers/media/platform/sti/delta/delta-mjpeg-dec.c:415 
> delta_mjpeg_decode()
>   error: uninitialized symbol 'data_offset'.
>
> drivers/media/platform/sti/delta/delta-mjpeg-dec.c
>378  unsigned int data_offset;
>  ^^^
>379  struct mjpeg_header *header = >header_struct;
>380
>381  if (!ctx->header) {
>382  ret = delta_mjpeg_read_header(pctx, au.vaddr, au.size,
>383header, _offset);
>^^^
> It's not immediately clear that "data_offset" must be set on the
> success path.
>
>384  if (ret) {
>385  pctx->stream_errors++;
>386  goto err;
>387  }
>388  if (header->frame_width * header->frame_height >
>389  DELTA_MJPEG_MAX_RESO) {
>390  dev_err(delta->dev,
>391  "%s  stream resolution too large: 
> %dx%d > %d pixels budget\n",
>392  pctx->name,
>393  header->frame_width,
>394  header->frame_height, 
> DELTA_MJPEG_MAX_RESO);
>395  ret = -EINVAL;
>396  goto err;
>397  }
>398  ctx->header = header;
>399  goto out;
>400  }
>401
>402  if (!ctx->ipc_hdl) {
>403  ret = delta_mjpeg_ipc_open(pctx);
>404  if (ret)
>405  goto err;
>406  }
>407
>408  ret = delta_mjpeg_read_header(pctx, au.vaddr, au.size,
>409ctx->header, _offset);
>410  if (ret) {
>411  pctx->stream_errors++;
>412  goto err;
>413  }
>414
>415  au.paddr += data_offset;
> ^^^
>416  au.vaddr += data_offset;
>
> regards,
> dan carpenter
>

Re: [PATCH v4 15/36] platform: add video-multiplexer subdevice driver

[Philipp Zabel]

On Sun, 2017-02-19 at 23:02 +0100, Pavel Machek wrote:
> Hi!
> 
> > From: Philipp Zabel 
> > 
> > This driver can handle SoC internal and external video bus multiplexers,
> > controlled either by register bit fields or by a GPIO. The subdevice
> > passes through frame interval and mbus configuration of the active input
> > to the output side.
> > 
> > Signed-off-by: Sascha Hauer 
> > Signed-off-by: Philipp Zabel 
> > --
> >
> 
> Again, this is slightly non-standard format. Normally changes from v1
> go below ---, but in your case it would cut off the signoff...
> 
> > diff --git a/Documentation/devicetree/bindings/media/video-multiplexer.txt 
> > b/Documentation/devicetree/bindings/media/video-multiplexer.txt
> > new file mode 100644
> > index 000..9d133d9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/video-multiplexer.txt
> > @@ -0,0 +1,59 @@
> > +Video Multiplexer
> > +=
> > +
> > +Video multiplexers allow to select between multiple input ports. Video 
> > received
> > +on the active input port is passed through to the output port. Muxes 
> > described
> > +by this binding may be controlled by a syscon register bitfield or by a 
> > GPIO.
> > +
> > +Required properties:
> > +- compatible : should be "video-multiplexer"
> > +- reg: should be register base of the register containing the control 
> > bitfield
> > +- bit-mask: bitmask of the control bitfield in the control register
> > +- bit-shift: bit offset of the control bitfield in the control register
> > +- gpios: alternatively to reg, bit-mask, and bit-shift, a single GPIO 
> > phandle
> > +  may be given to switch between two inputs
> > +- #address-cells: should be <1>
> > +- #size-cells: should be <0>
> > +- port@*: at least three port nodes containing endpoints connecting to the
> > +  source and sink devices according to of_graph bindings. The last port is
> > +  the output port, all others are inputs.
> 
> At least three? I guess it is exactly three with the gpio?

Yes. With the mmio bitfield muxes there can be more.

> Plus you might want to describe which port correspond to which gpio
> state/bitfield values...
> 
> > +struct vidsw {
> 
> I knew it: it is secretely a switch! :-).

This driver started as a two-input gpio controlled bus switch.
I changed the name when adding support for bitfield controlled
multiplexers with more than two inputs.

> > +static void vidsw_set_active(struct vidsw *vidsw, int active)
> > +{
> > +   vidsw->active = active;
> > +   if (active < 0)
> > +   return;
> > +
> > +   dev_dbg(vidsw->subdev.dev, "setting %d active\n", active);
> > +
> > +   if (vidsw->field)
> > +   regmap_field_write(vidsw->field, active);
> > +   else if (vidsw->gpio)
> > +   gpiod_set_value(vidsw->gpio, active);
> 
>  else dev_err()...?

If neither field nor gpio are set, probe will have failed and this will
never be called.

> > +static int vidsw_async_init(struct vidsw *vidsw, struct device_node *node)
> > +{
> > +   struct device_node *ep;
> > +   u32 portno;
> > +   int numports;
> 
> numbports is int, so I guess portno should be, too?

We could change both to unsigned int, as both vidsw->num_pads and
endpoint.base.port are unsigned int, and they are only compared/assigned
to those and each other.

> > +   portno = endpoint.base.port;
> > +   if (portno >= numports - 1)
> > +   continue;
> 
 I. 
> > +   if (!pad) {
> > +   /* Mirror the input side on the output side */
> > +   cfg->type = vidsw->endpoint[vidsw->active].bus_type;
> > +   if (cfg->type == V4L2_MBUS_PARALLEL ||
> > +   cfg->type == V4L2_MBUS_BT656)
> > +   cfg->flags = 
> > vidsw->endpoint[vidsw->active].bus.parallel.flags;
> > +   }
> 
> Will this need support for other V4L2_MBUS_ values?

To support CSI-2 multiplexers, yes.

> > +MODULE_AUTHOR("Sascha Hauer, Pengutronix");
> > +MODULE_AUTHOR("Philipp Zabel, Pengutronix");
> 
> Normally, MODULE_AUTHOR contains comma separated names of authors,
> perhaps with . Not sure two MODULE_AUTHORs per file
> will work.
> 
> Thanks,
>   Pavel

regards
Philipp

[PATCH v4 3/3] [media] st-delta: add mpeg2 support

[Hugues Fruchet]

Adds support of DELTA MPEG-2 video decoder back-end,
implemented by calling MPEG2_TRANSFORMER0 firmware
using RPMSG IPC communication layer.
MPEG-2 decoder back-end is a stateless decoder which
require specific parsing metadata in access unit
in order to complete decoding.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/Kconfig |   11 +-
 drivers/media/platform/sti/delta/Makefile  |3 +
 drivers/media/platform/sti/delta/delta-cfg.h   |5 +
 drivers/media/platform/sti/delta/delta-mpeg2-dec.c | 1401 
 drivers/media/platform/sti/delta/delta-mpeg2-fw.h  |  423 ++
 drivers/media/platform/sti/delta/delta-v4l2.c  |4 +
 6 files changed, 1845 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/platform/sti/delta/delta-mpeg2-dec.c
 create mode 100644 drivers/media/platform/sti/delta/delta-mpeg2-fw.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c9106e1..bf9695a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -340,15 +340,22 @@ config VIDEO_STI_DELTA_MJPEG
To compile this driver as a module, choose M here:
the module will be called st-delta.
 
+config VIDEO_STI_DELTA_MPEG2
+   bool "STMicroelectronics DELTA MPEG2/MPEG1 support"
+   default y
+   help
+   Enables DELTA MPEG2 hardware support.
+
 config VIDEO_STI_DELTA_DRIVER
tristate
depends on VIDEO_STI_DELTA
-   depends on VIDEO_STI_DELTA_MJPEG
-   default VIDEO_STI_DELTA_MJPEG
+   depends on VIDEO_STI_DELTA_MJPEG || VIDEO_STI_DELTA_MPEG2
+   default y
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
select RPMSG
 
+
 endif # VIDEO_STI_DELTA
 
 config VIDEO_SH_VEU
diff --git a/drivers/media/platform/sti/delta/Makefile 
b/drivers/media/platform/sti/delta/Makefile
index 8d032508..b18ed37 100644
--- a/drivers/media/platform/sti/delta/Makefile
+++ b/drivers/media/platform/sti/delta/Makefile
@@ -4,3 +4,6 @@ st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o delta-debug.o
 # MJPEG support
 st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-hdr.o
 st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-dec.o
+
+# MPEG2 support
+st-delta-$(CONFIG_VIDEO_STI_DELTA_MPEG2) += delta-mpeg2-dec.o
diff --git a/drivers/media/platform/sti/delta/delta-cfg.h 
b/drivers/media/platform/sti/delta/delta-cfg.h
index c6388f5..bce2c74 100644
--- a/drivers/media/platform/sti/delta/delta-cfg.h
+++ b/drivers/media/platform/sti/delta/delta-cfg.h
@@ -61,4 +61,9 @@
 extern const struct delta_dec mjpegdec;
 #endif
 
+#ifdef CONFIG_VIDEO_STI_DELTA_MPEG2
+extern const struct delta_dec mpeg2dec;
+extern const struct delta_dec mpeg1dec;
+#endif
+
 #endif /* DELTA_CFG_H */
diff --git a/drivers/media/platform/sti/delta/delta-mpeg2-dec.c 
b/drivers/media/platform/sti/delta/delta-mpeg2-dec.c
new file mode 100644
index 000..adb0300
--- /dev/null
+++ b/drivers/media/platform/sti/delta/delta-mpeg2-dec.c
@@ -0,0 +1,1401 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Authors: Hugues Fruchet 
+ *  Chetan Nanda 
+ *  Jean-Christophe Trotin 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+
+#include "delta.h"
+#include "delta-ipc.h"
+#include "delta-mem.h"
+#include "delta-mpeg2-fw.h"
+
+#define DELTA_MPEG2_MAX_RESO DELTA_MAX_RESO
+
+/* minimal number of frames for decoding = 1 dec + 2 refs frames */
+#define DELTA_MPEG2_DPB_FRAMES_NEEDED 3
+
+struct delta_mpeg2_ctx {
+   /* ipc */
+   void *ipc_hdl;
+   struct delta_buf *ipc_buf;
+
+   /* stream information */
+   struct delta_streaminfo streaminfo;
+
+   bool header_parsed;
+
+   /* reference frames mgt */
+   struct delta_mpeg2_frame *prev_ref;
+   struct delta_mpeg2_frame *next_ref;
+
+   /* output frames reordering management */
+   struct delta_frame *out_frame;
+   struct delta_frame *delayed_frame;
+
+   /* interlaced frame management */
+   struct delta_frame *last_frame;
+   enum mpeg2_picture_structure_t accumulated_picture_structure;
+
+   unsigned char str[3000];
+};
+
+/* codec specific frame struct */
+struct delta_mpeg2_frame {
+   struct delta_frame frame;
+   u32 tref;   /* temporal reference */
+   struct delta_buf omega_buf; /* 420mb buffer for decoding */
+};
+
+#define to_ctx(ctx) ((struct delta_mpeg2_ctx *)(ctx)->priv)
+#define to_mpeg2_frame(frame) ((struct delta_mpeg2_frame *)frame)
+#define to_frame(mpeg2_frame) ((struct delta_frame *)mpeg2_frame)
+
+/* default intra, zig-zag order */
+static u8 default_intra_matrix[] = {
+   8,
+   16, 16,
+   19, 16, 19,
+   22, 22, 22, 22,
+   22, 22, 26, 24, 26,
+   27, 27, 27, 26, 26, 26,
+   26, 27, 27, 27, 

[PATCH v4 2/3] [media] st-delta: add parsing metadata controls support

[Hugues Fruchet]

Install all metadata controls required by registered decoders.
Update the decoding context with the set of metadata received
from user through extended control.
Set the received metadata in access unit prior to call the
decoder decoding ops.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/sti/delta/delta-v4l2.c | 125 +-
 drivers/media/platform/sti/delta/delta.h  |  34 +++
 2 files changed, 158 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/delta/delta-v4l2.c 
b/drivers/media/platform/sti/delta/delta-v4l2.c
index c6f2e24..1d4436e 100644
--- a/drivers/media/platform/sti/delta/delta-v4l2.c
+++ b/drivers/media/platform/sti/delta/delta-v4l2.c
@@ -339,6 +339,30 @@ static void register_decoders(struct delta_dev *delta)
}
 }
 
+static void register_ctrls(struct delta_dev *delta)
+{
+   const struct delta_dec *dec;
+   unsigned int i, j;
+   u32 meta_cid;
+
+   /* decoders optional meta controls */
+   for (i = 0; i < delta->nb_of_decoders; i++) {
+   dec = delta->decoders[i];
+   if (!dec->meta_cids)
+   continue;
+
+   for (j = 0; j < dec->nb_of_metas; j++) {
+   meta_cid = dec->meta_cids[j];
+   if (!meta_cid)
+   continue;
+
+   delta->cids[delta->nb_of_ctrls++] = meta_cid;
+   }
+   }
+
+   /* add here additional controls if needed */
+}
+
 static void delta_lock(void *priv)
 {
struct delta_ctx *ctx = priv;
@@ -355,6 +379,79 @@ static void delta_unlock(void *priv)
mutex_unlock(>lock);
 }
 
+static int delta_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct delta_ctx *ctx =
+   container_of(ctrl->handler, struct delta_ctx, ctrl_handler);
+   struct delta_dev *delta = ctx->dev;
+
+   if (ctx->nb_of_metas >= DELTA_MAX_METAS) {
+   dev_err(delta->dev, "%s not enough room to set meta control\n",
+   ctx->name);
+   return -EINVAL;
+   }
+
+   dev_dbg(delta->dev, "%s set metas[%d] from control id=%d (%s)\n",
+   ctx->name, ctx->nb_of_metas, ctrl->id, ctrl->name);
+
+   ctx->metas[ctx->nb_of_metas].cid = ctrl->id;
+   ctx->metas[ctx->nb_of_metas].p = ctrl->p_new.p;
+   ctx->nb_of_metas++;
+
+   return 0;
+}
+
+static const struct v4l2_ctrl_ops delta_ctrl_ops = {
+   .s_ctrl = delta_s_ctrl,
+};
+
+static int delta_ctrls_setup(struct delta_ctx *ctx)
+{
+   struct delta_dev *delta = ctx->dev;
+   struct v4l2_ctrl_handler *hdl = >ctrl_handler;
+   unsigned int i;
+
+   v4l2_ctrl_handler_init(hdl, delta->nb_of_ctrls);
+
+   for (i = 0; i < delta->nb_of_ctrls; i++) {
+   struct v4l2_ctrl *ctrl;
+   u32 cid = delta->cids[i];
+   struct v4l2_ctrl_config cfg;
+
+   /* override static config to set delta_ctrl_ops */
+   memset(, 0, sizeof(cfg));
+   cfg.id = cid;
+   cfg.ops = _ctrl_ops;
+
+   ctrl = v4l2_ctrl_new_custom(hdl, , NULL);
+   if (hdl->error) {
+   int err = hdl->error;
+
+   dev_err(delta->dev, "%s failed to setup control '%s' 
(id=%d, size=%d, err=%d)\n",
+   ctx->name, cfg.name, cfg.id,
+   cfg.elem_size, err);
+   v4l2_ctrl_handler_free(hdl);
+   return err;
+   }
+
+   /* force unconditional execution of s_ctrl() by
+* disabling control value evaluation in case of
+* meta control (passed by pointer)
+*/
+   if (ctrl->is_ptr)
+   ctrl->flags |= V4L2_CTRL_FLAG_EXECUTE_ON_WRITE;
+   }
+
+   v4l2_ctrl_handler_setup(hdl);
+   ctx->fh.ctrl_handler = hdl;
+
+   ctx->nb_of_metas = 0;
+   memset(ctx->metas, 0, sizeof(ctx->metas));
+
+   dev_dbg(delta->dev, "%s controls setup done\n", ctx->name);
+   return 0;
+}
+
 static int delta_open_decoder(struct delta_ctx *ctx, u32 streamformat,
  u32 pixelformat, const struct delta_dec **pdec)
 {
@@ -964,6 +1061,12 @@ static void delta_run_work(struct work_struct *work)
au->size = vb2_get_plane_payload(>vb2_buf, 0);
au->dts = vbuf->vb2_buf.timestamp;
 
+   /* set access unit meta data in case of decoder requires it */
+   memcpy(au->metas, ctx->metas, ctx->nb_of_metas * sizeof(au->metas[0]));
+   au->nb_of_metas = ctx->nb_of_metas;
+   /* reset context metas for next decoding */
+   ctx->nb_of_metas = 0;
+
/* dump access unit */
dump_au(ctx, au);
 
@@ -1364,6 +1467,12 @@ static int delta_vb2_au_start_streaming(struct vb2_queue 
*q,
au->size = vb2_get_plane_payload(>vb2_buf, 0);
au->dts = 

[PATCH v4 1/3] [media] v4l: add parsed MPEG-2 support

[Hugues Fruchet]

Add "parsed MPEG-2" pixel format & related controls
needed by stateless video decoders.
In order to decode the video bitstream chunk provided
by user on output queue, stateless decoders require
also some extra data resulting from this video bitstream
chunk parsing.
Those parsed extra data have to be set by user through
control framework using the dedicated mpeg video extended
controls introduced in this patchset.

Signed-off-by: Hugues Fruchet 
---
 Documentation/media/uapi/v4l/extended-controls.rst | 363 +
 Documentation/media/uapi/v4l/pixfmt-013.rst|  10 +
 drivers/media/v4l2-core/v4l2-ctrls.c   |  53 +++
 drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
 include/uapi/linux/v4l2-controls.h |  94 ++
 include/uapi/linux/videodev2.h |   8 +
 6 files changed, 530 insertions(+)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index abb1057..cd1a8d6 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1827,6 +1827,369 @@ enum v4l2_mpeg_cx2341x_video_median_filter_type -
 not insert, 1 = insert packets.
 
 
+MPEG-2 Parsed Control Reference
+-
+
+The MPEG-2 parsed decoding controls are needed by stateless video decoders.
+Those decoders expose :ref:`Compressed formats ` 
:ref:`V4L2_PIX_FMT_MPEG1_PARSED` or 
:ref:`V4L2_PIX_FMT_MPEG2_PARSED`.
+In order to decode the video bitstream chunk provided by user on output queue,
+stateless decoders require also some extra data resulting from this video
+bitstream chunk parsing. Those parsed extra data have to be set by user
+through control framework using the mpeg video extended controls defined
+in this section. Those controls have been defined based on MPEG-2 standard
+ISO/IEC 13818-2, and so derive directly from the MPEG-2 video bitstream syntax
+including how it is coded inside bitstream (enumeration values for ex.).
+
+MPEG-2 Parsed Control IDs
+^^^
+
+.. _mpeg2-parsed-control-id:
+
+``V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_HDR``
+(enum)
+
+.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
+
+.. c:type:: v4l2_mpeg_video_mpeg2_seq_hdr
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_mpeg_video_mpeg2_seq_hdr
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u16
+  - ``width``
+  - Video width in pixels.
+* - __u16
+  - ``height``
+  - Video height in pixels.
+* - __u8
+  - ``aspect_ratio_info``
+  - Aspect ratio code as in the bitstream (1: 1:1 square pixels,
+2: 4:3 display, 3: 16:9 display, 4: 2.21:1 display)
+* - __u8
+  - ``framerate code``
+  - Framerate code as in the bitstream
+(1: 24000/1001.0 '23.976 fps, 2: 24.0, 3: 25.0,
+4: 3/1001.0 '29.97, 5: 30.0, 6: 50.0, 7: 6/1001.0,
+8: 60.0)
+* - __u32
+  - ``bitrate_value``
+  - Bitrate value as in the bitstream, expressed in 400bps unit
+* - __u16
+  - ``vbv_buffer_size``
+  -  Video Buffering Verifier size, expressed in 16KBytes unit.
+* - __u8
+  - ``constrained_parameters_flag``
+  - Set to 1 if this bitstream uses constrained parameters.
+* - __u8
+  - ``load_intra_quantiser_matrix``
+  - If set to 1, ``intra_quantiser_matrix`` table is to be used for
+decoding.
+* - __u8
+  - ``load_non_intra_quantiser_matrix``
+  - If set to 1, ``non_intra_quantiser_matrix`` table is to be used for
+decoding.
+* - __u8
+  - ``intra_quantiser_matrix[64]``
+  - Intra quantization table, in zig-zag scan order.
+* - __u8
+  - ``non_intra_quantiser_matrix[64]``
+  - Non-intra quantization table, in zig-zag scan order.
+* - __u32
+  - ``par_w``
+  - Pixel aspect ratio width in pixels.
+* - __u32
+  - ``par_h``
+  - Pixel aspect ratio height in pixels.
+* - __u32
+  - ``fps_n``
+  - Framerate nominator.
+* - __u32
+  - ``fps_d``
+  - Framerate denominator.
+* - __u32
+  - ``bitrate``
+  - Bitrate in bps if constant bitrate, 0 otherwise.
+* - :cspan:`2`
+
+
+``V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_EXT``
+(enum)
+
+.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
+
+.. c:type:: v4l2_mpeg_video_mpeg2_seq_ext
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_mpeg_video_mpeg2_seq_ext
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``profile``
+  - Encoding profile used to encode this bitstream.
+(1: High Profile, 2: Spatially Scalable Profile,
+3: SNR Scalable Profile, 4: Main Profile, 5: Simple Profile).
+* - __u8
+  - ``level``
+  - Encoding level used to encode this bitstream
+(4: High Level, 6: High 1440 Level, 8: Main Level, 10: Low Level).
+* - 

[PATCH v4 0/3] Add support for MPEG-2 in DELTA video decoder

[Hugues Fruchet]

The patchset implements the MPEG-2 part of V4L2 unified low-level decoder
API RFC [0] needed by stateless video decoders, ie decoders which requires
specific parsing metadata in addition to video bitstream chunk in order
to complete decoding.
A reference implementation using STMicroelectronics DELTA video decoder
is provided as initial support in this patchset.
In addition to this patchset, a libv4l plugin is also provided which convert
MPEG-2 video bitstream to "parsed MPEG-2" by parsing the user video bitstream
and filling accordingly the dedicated controls, doing so user code remains
unchanged whatever decoder is: stateless or not.

The first patch implements the MPEG-2 part of V4L2 unified low-level decoder
API RFC [0]. A dedicated "parsed MPEG-2" pixel format has been introduced with
its related extended controls in order that user provides both video bitstream
chunk and the associated extra data resulting from this video bitstream chunk
parsing.

The second patch adds the support of "parsed" pixel format inside DELTA video
decoder including handling of the dedicated controls and setting of parsing
metadata required by decoder layer.
Please note that the current implementation has a restriction regarding
the atomicity of S_EXT_CTRL/QBUF that must be guaranteed by user.
This restriction will be removed when V4L2 request API will be implemented [1].
Please also note the failure in v4l2-compliance in controls section, related
to complex compound controls handling, to be discussed to find the right way
to fix it in v4l2-compliance.

The third patch adds the support of DELTA MPEG-2 stateless video decoder 
back-end.


This driver depends on:
  [PATCH v7 00/10] Add support for DELTA video decoder of STMicroelectronics 
STiH4xx SoC series https://patchwork.linuxtv.org/patch/39186/

References:
  [0] [RFC] V4L2 unified low-level decoder API 
https://www.spinics.net/lists/linux-media/msg107150.html
  [1] [ANN] Report of the V4L2 Request API brainstorm meeting 
https://www.spinics.net/lists/linux-media/msg106699.html

===
= history =
===
version 4:
  - patchset 3 review from Nicolas Dufresne
- one attribute per line in structure
  - fix some multilines comments

version 3:
  - fix warning on parisc architecture

version 2:
  - rebase on top of DELTA v7, refer to [0]
  - change VIDEO_STI_DELTA_DRIVER to default=y as per Mauro recommendations

version 1:
  - Initial submission

===
= v4l2-compliance =
===
Below is the v4l2-compliance report, v4l2-compliance has been build from SHA1:
003f31e59f353b4aecc82e8fb1c7555964da7efa (v4l2-compliance: allow S_SELECTION to 
return ENOTTY)

root@sti-4:~# v4l2-compliance -d /dev/video3
v4l2-compliance SHA   : 003f31e59f353b4aecc82e8fb1c7555964da7efa


root@sti-lts:~# v4l2-compliance -d /dev/video3 
v4l2-compliance SHA   : not available

Driver Info:
Driver name   : st-delta
Card type : st-delta-21.1-3
Bus info  : platform:soc:delta0
Driver version: 4.9.0
Capabilities  : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format

Compliance test for device /dev/video3 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
fail: 

Re: [PATCH v3 1/3] [media] v4l: add parsed MPEG-2 support

[Hugues FRUCHET]

Thanks for review Nicolas, my comments thereafter.

On 02/10/2017 03:07 AM, Nicolas Dufresne wrote:
> Le jeudi 09 février 2017 à 18:07 +0100, Hugues Fruchet a écrit :
>> Add "parsed MPEG-2" pixel format & related controls
>> needed by stateless video decoders.
>> In order to decode the video bitstream chunk provided
>> by user on output queue, stateless decoders require
>> also some extra data resulting from this video bitstream
>> chunk parsing.
>> Those parsed extra data have to be set by user through
>> control framework using the dedicated mpeg video extended
>> controls introduced in this patchset.
>>
>> Signed-off-by: Hugues Fruchet 
>> ---
>>  Documentation/media/uapi/v4l/extended-controls.rst | 363
>> +
>>  Documentation/media/uapi/v4l/pixfmt-013.rst|  10 +
>>  drivers/media/v4l2-core/v4l2-ctrls.c   |  53 +++
>>  drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
>>  include/uapi/linux/v4l2-controls.h |  86 +
>>  include/uapi/linux/videodev2.h |   8 +
>>  6 files changed, 522 insertions(+)
>>
>> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst
>> b/Documentation/media/uapi/v4l/extended-controls.rst
>> index abb1057..cd1a8d6 100644
>> --- a/Documentation/media/uapi/v4l/extended-controls.rst
>> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
>> @@ -1827,6 +1827,369 @@ enum
>> v4l2_mpeg_cx2341x_video_median_filter_type -
>>  not insert, 1 = insert packets.
>>
>>
>> +MPEG-2 Parsed Control Reference
>> +-
>> +
>> +The MPEG-2 parsed decoding controls are needed by stateless video
>> decoders.
>> +Those decoders expose :ref:`Compressed formats `
>> :ref:`V4L2_PIX_FMT_MPEG1_PARSED` or
>> :ref:`V4L2_PIX_FMT_MPEG2_PARSED`.
>> +In order to decode the video bitstream chunk provided by user on
>> output queue,
>> +stateless decoders require also some extra data resulting from this
>> video
>> +bitstream chunk parsing. Those parsed extra data have to be set by
>> user
>> +through control framework using the mpeg video extended controls
>> defined
>> +in this section. Those controls have been defined based on MPEG-2
>> standard
>> +ISO/IEC 13818-2, and so derive directly from the MPEG-2 video
>> bitstream syntax
>> +including how it is coded inside bitstream (enumeration values for
>> ex.).
>> +
>> +MPEG-2 Parsed Control IDs
>> +^^^
>> +
>> +.. _mpeg2-parsed-control-id:
>> +
>> +``V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_HDR``
>> +(enum)
>> +
>> +.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
>> +
>> +.. c:type:: v4l2_mpeg_video_mpeg2_seq_hdr
>> +
>> +.. cssclass:: longtable
>> +
>> +.. flat-table:: struct v4l2_mpeg_video_mpeg2_seq_hdr
>> +:header-rows:  0
>> +:stub-columns: 0
>> +:widths:   1 1 2
>> +
>> +* - __u16
>> +  - ``width``
>> +  - Video width in pixels.
>> +* - __u16
>> +  - ``height``
>> +  - Video height in pixels.
>> +* - __u8
>> +  - ``aspect_ratio_info``
>> +  - Aspect ratio code as in the bitstream (1: 1:1 square pixels,
>> +2: 4:3 display, 3: 16:9 display, 4: 2.21:1 display)
>> +* - __u8
>> +  - ``framerate code``
>> +  - Framerate code as in the bitstream
>> +(1: 24000/1001.0 '23.976 fps, 2: 24.0, 3: 25.0,
>> +4: 3/1001.0 '29.97, 5: 30.0, 6: 50.0, 7: 6/1001.0,
>> +8: 60.0)
>> +* - __u32
>> +  - ``bitrate_value``
>> +  - Bitrate value as in the bitstream, expressed in 400bps unit
>> +* - __u16
>> +  - ``vbv_buffer_size``
>> +  -  Video Buffering Verifier size, expressed in 16KBytes unit.
>> +* - __u8
>> +  - ``constrained_parameters_flag``
>> +  - Set to 1 if this bitstream uses constrained parameters.
>> +* - __u8
>> +  - ``load_intra_quantiser_matrix``
>> +  - If set to 1, ``intra_quantiser_matrix`` table is to be used
>> for
>> +decoding.
>> +* - __u8
>> +  - ``load_non_intra_quantiser_matrix``
>> +  - If set to 1, ``non_intra_quantiser_matrix`` table is to be
>> used for
>> +decoding.
>> +* - __u8
>> +  - ``intra_quantiser_matrix[64]``
>> +  - Intra quantization table, in zig-zag scan order.
>> +* - __u8
>> +  - ``non_intra_quantiser_matrix[64]``
>> +  - Non-intra quantization table, in zig-zag scan order.
>> +* - __u32
>> +  - ``par_w``
>> +  - Pixel aspect ratio width in pixels.
>> +* - __u32
>> +  - ``par_h``
>> +  - Pixel aspect ratio height in pixels.
>> +* - __u32
>> +  - ``fps_n``
>> +  - Framerate nominator.
>> +* - __u32
>> +  - ``fps_d``
>> +  - Framerate denominator.
>> +* - __u32
>> +  - ``bitrate``
>> +  - Bitrate in bps if constant bitrate, 0 otherwise.
>> +* - :cspan:`2`
>> +
>> +
>> +``V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_EXT``
>> +(enum)
>> +
>> +.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
>> +
>> +.. c:type:: 

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Philipp Zabel]

On Mon, 2017-02-20 at 16:18 -0800, Steve Longerbeam wrote:
> 
> On 02/20/2017 04:13 PM, Russell King - ARM Linux wrote:
> > On Tue, Feb 21, 2017 at 12:04:10AM +0200, Sakari Ailus wrote:
> >> On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:
> >>> From: Russell King 
> >>>
> >>> Setting and getting frame rates is part of the negotiation mechanism
> >>> between subdevs.  The lack of support means that a frame rate at the
> >>> sensor can't be negotiated through the subdev path.
> >>
> >> Just wondering --- what do you need this for?
> >
> > The v4l2 documentation contradicts the media-ctl implementation.
> >
> > While v4l2 documentation says:
> >
> >   These ioctls are used to get and set the frame interval at specific
> >   subdev pads in the image pipeline. The frame interval only makes sense
> >   for sub-devices that can control the frame period on their own. This
> >   includes, for instance, image sensors and TV tuners. Sub-devices that
> >   don't support frame intervals must not implement these ioctls.
> >
> > However, when trying to configure the pipeline using media-ctl, eg:
> >
> > media-ctl -d /dev/media1 --set-v4l2 '"imx219 pixel 
> > 0-0010":0[crop:(0,0)/3264x2464]'
> > media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> > 0-0010":1[fmt:SRGGB10/3264x2464@1/30]'
> > media-ctl -d /dev/media1 --set-v4l2 '"imx219 
> > 0-0010":0[fmt:SRGGB8/816x616@1/30]'
> > media-ctl -d /dev/media1 --set-v4l2 
> > '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
> > Unable to setup formats: Inappropriate ioctl for device (25)
> > media-ctl -d /dev/media1 --set-v4l2 
> > '"ipu1_csi0_mux":2[fmt:SRGGB8/816x616@1/30]'
> > media-ctl -d /dev/media1 --set-v4l2 '"ipu1_csi0":2[fmt:SRGGB8/816x616@1/30]'
> >
> > The problem there is that the format setting for the csi2 does not get
> > propagated forward:
> >
> > $ strace media-ctl -d /dev/media1 --set-v4l2 
> > '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
> > ...
> > open("/dev/v4l-subdev16", O_RDWR)   = 3
> > ioctl(3, VIDIOC_SUBDEV_S_FMT, 0xbec16244) = 0
> > ioctl(3, VIDIOC_SUBDEV_S_FRAME_INTERVAL, 0xbec162a4) = -1 ENOTTY 
> > (Inappropriate
> > ioctl for device)
> > fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
> > write(1, "Unable to setup formats: Inappro"..., 61) = 61
> > Unable to setup formats: Inappropriate ioctl for device (25)
> > close(3)= 0
> > exit_group(1)   = ?
> > +++ exited with 1 +++
> >
> > because media-ctl exits as soon as it encouters the error while trying
> > to set the frame rate.
> >
> > This makes implementing setup of the media pipeline in shell scripts
> > unnecessarily difficult - as you need to then know whether an entity
> > is likely not to support the VIDIOC_SUBDEV_S_FRAME_INTERVAL call,
> > and either avoid specifying a frame rate:
> >
> > $ strace media-ctl -d /dev/media1 --set-v4l2 
> > '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616]'
> > ...
> > open("/dev/v4l-subdev16", O_RDWR)   = 3
> > ioctl(3, VIDIOC_SUBDEV_S_FMT, 0xbeb1a254) = 0
> > open("/dev/v4l-subdev0", O_RDWR)= 4
> > ioctl(4, VIDIOC_SUBDEV_S_FMT, 0xbeb1a254) = 0
> > close(4)= 0
> > close(3)= 0
> > exit_group(0)   = ?
> > +++ exited with 0 +++
> >
> > or manually setting the format on the sink.
> >
> > Allowing the S_FRAME_INTERVAL call seems to me to be more in keeping
> > with the negotiation mechanism that is implemented in subdevs, and
> > IMHO should be implemented inside the kernel as a pad operation along
> > with the format negotiation, especially so as frame skipping is
> > defined as scaling, in just the same way as the frame size is also
> > scaling:
> >
> >-  ``MEDIA_ENT_F_PROC_VIDEO_SCALER``
> >
> >-  Video scaler. An entity capable of video scaling must have
> >   at least one sink pad and one source pad, and scale the
> >   video frame(s) received on its sink pad(s) to a different
> >   resolution output on its source pad(s). The range of
> >   supported scaling ratios is entity-specific and can differ
> >   between the horizontal and vertical directions (in particular
> >   scaling can be supported in one direction only). Binning and
> >   skipping are considered as scaling.
> >
> > Although, this is vague, as it doesn't define what it means by "skipping",
> > whether that's skipping pixels (iow, sub-sampling) or whether that's
> > frame skipping.

I'd interpret this as meaning pixel skipping, not frame skipping.

> > Then there's the issue where, if you have this setup:
> >
> >  camera --> csi2 receiver --> csi --> capture
> >
> > and the "csi" subdev can skip frames, you need to know (a) at the CSI
> > sink pad what the frame rate is of the source (b) what the desired
> > source pad frame rate is, so you can configure the frame skipping.
> > So, does the csi subdev have to walk 

[PATCH] [media] st-delta: mjpeg: fix static checker warning

[Hugues Fruchet]

Initialize 'data_offset' local variable to 0.

drivers/media/platform/sti/delta/delta-mjpeg-dec.c:415 delta_mjpeg_decode()
error: uninitialized symbol 'data_offset'.

Fixes: 433ff5b4a29b: "[media] st-delta: add mjpeg support"
Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/sti/delta/delta-mjpeg-dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/delta/delta-mjpeg-dec.c 
b/drivers/media/platform/sti/delta/delta-mjpeg-dec.c
index e79bdc6..84ea43c 100644
--- a/drivers/media/platform/sti/delta/delta-mjpeg-dec.c
+++ b/drivers/media/platform/sti/delta/delta-mjpeg-dec.c
@@ -375,7 +375,7 @@ static int delta_mjpeg_decode(struct delta_ctx *pctx, 
struct delta_au *pau)
struct delta_mjpeg_ctx *ctx = to_ctx(pctx);
int ret;
struct delta_au au = *pau;
-   unsigned int data_offset;
+   unsigned int data_offset = 0;
struct mjpeg_header *header = >header_struct;
 
if (!ctx->header) {
-- 
1.9.1