date:20171020

On 14/10/17 17:39, Heiko Stuebner wrote:
> So far only the hdmi cec supports using one of two different pins
> as source, so add the route switching for it.
> 
> Signed-off-by: Heiko Stuebner 

Just tested this on my firefly reload and it works great!

Tested-by: Hans Verkuil 

I'll post some dts patches later today to fully bring up the first HDMI
output on the Firefly Reload.

Will you process this patch further to get it mainlined?

Regards,

Hans

> ---
> If I didn't mess up any numbering, the pinctrl change should look like
> the following patch.
> 
> Hope that helps
> Heiko
> 
>  drivers/pinctrl/pinctrl-rockchip.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
> b/drivers/pinctrl/pinctrl-rockchip.c
> index b5cb7858ffdc..8dd49e2e144b 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
> @@ -884,6 +884,24 @@ static struct rockchip_mux_route_data 
> rk3228_mux_route_data[] = {
>   },
>  };
>  
> +static struct rockchip_mux_route_data rk3288_mux_route_data[] = {
> + {
> + /* edphdmi_cecinoutt1 */
> + .bank_num = 7,
> + .pin = 16,
> + .func = 2,
> + .route_offset = 0x264,
> + .route_val = BIT(16 + 12) | BIT(12),
> + }, {
> + /* edphdmi_cecinout */
> + .bank_num = 7,
> + .pin = 23,
> + .func = 4,
> + .route_offset = 0x264,
> + .route_val = BIT(16 + 12),
> + },
> +};
> +
>  static struct rockchip_mux_route_data rk3328_mux_route_data[] = {
>   {
>   /* uart2dbg_rxm0 */
> @@ -3391,6 +3409,8 @@ static struct rockchip_pin_ctrl rk3288_pin_ctrl = {
>   .type   = RK3288,
>   .grf_mux_offset = 0x0,
>   .pmu_mux_offset = 0x84,
> + .iomux_routes   = rk3288_mux_route_data,
> + .niomux_routes  = ARRAY_SIZE(rk3288_mux_route_data),
>   .pull_calc_reg  = rk3288_calc_pull_reg_and_bit,
>   .drv_calc_reg   = rk3288_calc_drv_reg_and_bit,
>  };
>

Re: [PATCH 1/3] drm: bridge: synopsys/dw-hdmi: Enable cec clock

On 14/10/17 10:16, Hans Verkuil wrote:
> On 10/14/2017 12:53 AM, Pierre-Hugues Husson wrote:
>> The documentation already mentions "cec" optional clock, but
>> currently the driver doesn't enable it.
>>
>> Signed-off-by: Pierre-Hugues Husson 
> 
> Acked-by: Hans Verkuil 

Tested-by: Hans Verkuil 

> 
> Thanks!
> 
>   Hans
> 
>> ---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 +
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index bf14214fa464..5007cdf43131 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -138,6 +138,7 @@ struct dw_hdmi {
>>  struct device *dev;
>>  struct clk *isfr_clk;
>>  struct clk *iahb_clk;
>> +struct clk *cec_clk;
>>  struct dw_hdmi_i2c *i2c;
>>  
>>  struct hdmi_data_info hdmi_data;
>> @@ -2382,6 +2383,18 @@ __dw_hdmi_probe(struct platform_device *pdev,
>>  goto err_isfr;
>>  }
>>  
>> +hdmi->cec_clk = devm_clk_get(hdmi->dev, "cec");
>> +if (IS_ERR(hdmi->cec_clk)) {
>> +hdmi->cec_clk = NULL;
>> +} else {
>> +ret = clk_prepare_enable(hdmi->cec_clk);
>> +if (ret) {
>> +dev_err(hdmi->dev, "Cannot enable HDMI cec clock: %d\n",
>> +ret);
>> +goto err_res;
>> +}
>> +}
>> +
>>  /* Product and revision IDs */
>>  hdmi->version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
>>| (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
>> @@ -2518,6 +2531,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
>>  cec_notifier_put(hdmi->cec_notifier);
>>  
>>  clk_disable_unprepare(hdmi->iahb_clk);
>> +if (hdmi->cec_clk)
>> +clk_disable_unprepare(hdmi->cec_clk);
>>  err_isfr:
>>  clk_disable_unprepare(hdmi->isfr_clk);
>>  err_res:
>> @@ -2541,6 +2556,8 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
>>  
>>  clk_disable_unprepare(hdmi->iahb_clk);
>>  clk_disable_unprepare(hdmi->isfr_clk);
>> +if (hdmi->cec_clk)
>> +clk_disable_unprepare(hdmi->cec_clk);
>>  
>>  if (hdmi->i2c)
>>  i2c_del_adapter(&hdmi->i2c->adap);
>>
>

Re: [PATCH] pinctrl: rockchip: Add iomux-route switching support for rk3288

2017-10-20 Thread Heiko Stübner

Hi Hans,

Am Freitag, 20. Oktober 2017, 09:28:58 CEST schrieb Hans Verkuil:
> On 14/10/17 17:39, Heiko Stuebner wrote:
> > So far only the hdmi cec supports using one of two different pins
> > as source, so add the route switching for it.
> > 
> > Signed-off-by: Heiko Stuebner 
> 
> Just tested this on my firefly reload and it works great!
> 
> Tested-by: Hans Verkuil 

oh cool. I really only wrote this based on the soc manual,
so it actually surprises me, that it works on the first try :-)

> I'll post some dts patches later today to fully bring up the first HDMI
> output on the Firefly Reload.
> 
> Will you process this patch further to get it mainlined?

Yep, I'll do that.


Heiko

Re: [PATCH] pinctrl: rockchip: Add iomux-route switching support for rk3288

On 20/10/17 09:38, Heiko Stübner wrote:
> Hi Hans,
> 
> Am Freitag, 20. Oktober 2017, 09:28:58 CEST schrieb Hans Verkuil:
>> On 14/10/17 17:39, Heiko Stuebner wrote:
>>> So far only the hdmi cec supports using one of two different pins
>>> as source, so add the route switching for it.
>>>
>>> Signed-off-by: Heiko Stuebner 
>>
>> Just tested this on my firefly reload and it works great!
>>
>> Tested-by: Hans Verkuil 
> 
> oh cool. I really only wrote this based on the soc manual,
> so it actually surprises me, that it works on the first try :-)

One note though: I've only tested it on my Firefly Reload. I don't have a
regular Firefly, so I can't be certain it works there. Just covering my ass
here :-)

> 
>> I'll post some dts patches later today to fully bring up the first HDMI
>> output on the Firefly Reload.
>>
>> Will you process this patch further to get it mainlined?
> 
> Yep, I'll do that.

Thanks!

Regards,

Hans

Re: [PATCH 1/3] drm: bridge: synopsys/dw-hdmi: Enable cec clock

2017-10-20 Thread Russell King - ARM Linux

On Sat, Oct 14, 2017 at 12:53:35AM +0200, Pierre-Hugues Husson wrote:
> @@ -2382,6 +2383,18 @@ __dw_hdmi_probe(struct platform_device *pdev,
>   goto err_isfr;
>   }
>  
> + hdmi->cec_clk = devm_clk_get(hdmi->dev, "cec");
> + if (IS_ERR(hdmi->cec_clk)) {
> + hdmi->cec_clk = NULL;

What if devm_clk_get() returns EPROBE_DEFER?  Does that really mean the
clock does not exist?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

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

Hi Yong,

On Tue, Oct 17, 2017 at 10:46:48PM -0500, Yong Zhi wrote:
> This patchset adds support for the Intel IPU3 (Image Processing Unit)
> ImgU which is essentially a modern memory-to-memory ISP. It implements
> raw Bayer to YUV image format conversion as well as a large number of
> other pixel processing algorithms for improving the image quality.
> 
> Meta data formats are defined for image statistics (3A, i.e. automatic
> white balance, exposure and focus, histogram and local area contrast
> enhancement) as well as for the pixel processing algorithm parameters.
> The documentation for these formats is currently not included in the
> patchset but will be added in a future version of this set.
> 
> The algorithm parameters need to be considered specific to a given frame
> and typically a large number of these parameters change on frame to frame
> basis. Additionally, the parameters are highly structured (and not a flat
> space of independent configuration primitives). They also reflect the
> data structures used by the firmware and the hardware. On top of that,
> the algorithms require highly specialized user space to make meaningful
> use of them. For these reasons it has been chosen video buffers to pass

Do you have a to-do list for this patchset? I think it would be useful to
maintain one, in case not all the comments have been addressed.

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

Re: [PATCH v4 03/12] intel-ipu3: Add IOMMU based dmamap support

Hi Yong,

On Tue, Oct 17, 2017 at 10:48:59PM -0500, Yong Zhi wrote:
> From: Tomasz Figa 
> 
> This patch adds driver to support IPU3-specific
> MMU-aware memory alloc/free and sg mapping functions.
> 
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Yong Zhi 
> ---
>  drivers/media/pci/intel/ipu3/Kconfig   |   7 +
>  drivers/media/pci/intel/ipu3/Makefile  |   2 +-
>  drivers/media/pci/intel/ipu3/ipu3-dmamap.c | 342 
> +
>  drivers/media/pci/intel/ipu3/ipu3-dmamap.h |  33 +++
>  4 files changed, 383 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-dmamap.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-dmamap.h
> 
> diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
> b/drivers/media/pci/intel/ipu3/Kconfig
> index 46ff138f3e50..d7dab52dc881 100644
> --- a/drivers/media/pci/intel/ipu3/Kconfig
> +++ b/drivers/media/pci/intel/ipu3/Kconfig
> @@ -26,3 +26,10 @@ config INTEL_IPU3_MMU
>   ---help---
> For IPU3, this option enables its MMU driver to translate its internal
> virtual address to 39 bits wide physical address for 64GBytes space 
> access.
> +
> +config INTEL_IPU3_DMAMAP
> + tristate
> + default n
> + select IOMMU_IOVA
> + ---help---
> +   This is IPU3 IOMMU domain specific DMA driver.
> diff --git a/drivers/media/pci/intel/ipu3/Makefile 
> b/drivers/media/pci/intel/ipu3/Makefile
> index 91cac9cb7401..651773231496 100644
> --- a/drivers/media/pci/intel/ipu3/Makefile
> +++ b/drivers/media/pci/intel/ipu3/Makefile
> @@ -13,4 +13,4 @@
>  
>  obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
>  obj-$(CONFIG_INTEL_IPU3_MMU) += ipu3-mmu.o
> -
> +obj-$(CONFIG_INTEL_IPU3_DMAMAP) += ipu3-dmamap.o
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-dmamap.c 
> b/drivers/media/pci/intel/ipu3/ipu3-dmamap.c
> new file mode 100644
> index ..e54bd9dfa302
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3-dmamap.c
> @@ -0,0 +1,342 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + * Copyright (C) 2017 Google, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Do you need this for something?

> +#include 
> +
> +#include "ipu3-css-pool.h"
> +#include "ipu3.h"
> +
> +/*
> + * Based on arch/arm64/mm/dma-mapping.c, with simplifications possible due
> + * to driver-specific character of this file.
> + */
> +
> +static int dma_direction_to_prot(enum dma_data_direction dir, bool coherent)
> +{
> + int prot = coherent ? IOMMU_CACHE : 0;
> +
> + switch (dir) {
> + case DMA_BIDIRECTIONAL:
> + return prot | IOMMU_READ | IOMMU_WRITE;
> + case DMA_TO_DEVICE:
> + return prot | IOMMU_READ;
> + case DMA_FROM_DEVICE:
> + return prot | IOMMU_WRITE;
> + default:
> + return 0;
> + }
> +}
> +
> +/*
> + * Free a buffer allocated by ipu3_dmamap_alloc_buffer()
> + */
> +static void ipu3_dmamap_free_buffer(struct page **pages,
> + size_t size)
> +{
> + int count = size >> PAGE_SHIFT;
> +
> + while (count--)
> + __free_page(pages[count]);
> + kvfree(pages);
> +}
> +
> +/*
> + * Based on the implementation of __iommu_dma_alloc_pages()
> + * defined in drivers/iommu/dma-iommu.c
> + */
> +static struct page **ipu3_dmamap_alloc_buffer(size_t size,
> +   unsigned long order_mask,
> +   gfp_t gfp)
> +{
> + struct page **pages;
> + unsigned int i = 0, count = size >> PAGE_SHIFT;
> + const gfp_t high_order_gfp = __GFP_NOWARN | __GFP_NORETRY;
> +
> + /* Allocate mem for array of page ptrs */
> + pages = kvmalloc_array(count, sizeof(struct page *), GFP_KERNEL);
> +
> + if (!pages)
> + return NULL;
> +
> + order_mask &= (2U << MAX_ORDER) - 1;
> + if (!order_mask)
> + return NULL;
> +
> + gfp |= __GFP_NOWARN | __GFP_HIGHMEM | __GFP_ZERO;
> +
> + while (count) {
> + struct page *page = NULL;
> + unsigned int order_size;
> +
> + for (order_mask &= (2U << __fls(count)) - 1;
> +  order_mask; order_mask &= ~order_size) {
> + unsigned int order = __fls(order_mask);
> +
> + order_size = 1U << order;
> + page = alloc_pages((order_mask - order_size) ?
> +gfp | high_order_gfp : gfp,

Investment proposa

2017-10-20 Thread Douglas

Dear Friend, 

I am interested in establishing and operating a very viable business as a means 
of investment. I do not know too well on how this is done in your country, so I 
will need you to help me in this regard. 

My preference is any good profit yielding business and I would appreciate any 
viable ideas you could come up with. I will also need you to help me look for 
properties like house and lands for sale as I am proposing to invest the sum of 
Ten Million Great British Pounds (£10,000,000 GBP) for this. I do not know if 
you can and will be of help to me. 

For a brief on my personality;  

My need for this business proposition and to acquire these properties is very 
urgent as I am planning to retire from my position as the chairman of HSBC 
bank. 
As business inclined man, I want you to come up with your individual business/ 
investment ideas as I will welcome it from the bottom of my heart.


Please I expect your good and prompt reply so that we can proceed swiftly on 
how the fund can be sent to you.  

Best Regards
Douglas J Flint

Re: [PATCH v4 02/12] intel-ipu3: Add mmu driver

Hi Yong,

On Tue, Oct 17, 2017 at 10:48:34PM -0500, Yong Zhi wrote:
> From: Tomasz Figa 
> 
> IPU3 is capable to deal with a virtual address space with
> a dedicated MMU. The driver supports address translation
> from virtual(IPU3 internal) to 39 bit wide physical(system).
> 
> Build has dependency on exported symbols from:
> 
> https://patchwork.kernel.org/patch/9825939/>
> 
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Yong Zhi 
> ---
>  drivers/media/pci/intel/ipu3/Kconfig|   9 +
>  drivers/media/pci/intel/ipu3/Makefile   |  15 +
>  drivers/media/pci/intel/ipu3/ipu3-mmu.c | 580 
> 
>  drivers/media/pci/intel/ipu3/ipu3-mmu.h |  26 ++
>  4 files changed, 630 insertions(+)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.h
> 
> diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
> b/drivers/media/pci/intel/ipu3/Kconfig
> index 0861077a4dae..46ff138f3e50 100644
> --- a/drivers/media/pci/intel/ipu3/Kconfig
> +++ b/drivers/media/pci/intel/ipu3/Kconfig
> @@ -17,3 +17,12 @@ config VIDEO_IPU3_CIO2
>   Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
>   connected camera.
>   The module will be called ipu3-cio2.
> +
> +config INTEL_IPU3_MMU
> + tristate
> + default n
> + select IOMMU_API
> + select IOMMU_IOVA
> + ---help---
> +   For IPU3, this option enables its MMU driver to translate its internal
> +   virtual address to 39 bits wide physical address for 64GBytes space 
> access.
> diff --git a/drivers/media/pci/intel/ipu3/Makefile 
> b/drivers/media/pci/intel/ipu3/Makefile
> index 20186e3ff2ae..91cac9cb7401 100644
> --- a/drivers/media/pci/intel/ipu3/Makefile
> +++ b/drivers/media/pci/intel/ipu3/Makefile
> @@ -1 +1,16 @@
> +#
> +#  Copyright (c) 2017, Intel Corporation.
> +#
> +#  This program is free software; you can redistribute it and/or modify it
> +#  under the terms and conditions of the GNU General Public License,
> +#  version 2, as published by the Free Software Foundation.
> +#
> +#  This program is distributed in the hope it will be useful, but WITHOUT
> +#  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +#  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> +#  more details.

No need for such a header in a Makefile.

> +#
> +
>  obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
> +obj-$(CONFIG_INTEL_IPU3_MMU) += ipu3-mmu.o
> +
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-mmu.c 
> b/drivers/media/pci/intel/ipu3/ipu3-mmu.c
> new file mode 100644
> index ..05d001319aca
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3-mmu.c
> @@ -0,0 +1,580 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + * Copyright (C) 2017 Google, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "ipu3-mmu.h"
> +
> +#define IMGU_DMA_NAME"ipu3-imgu-dma"
> +#define IMGU_DMA_BUS_NAME"ipu3-imgu-bus"
> +
> +#define IPU3_PAGE_SHIFT  12
> +#define IPU3_PAGE_SIZE   (1UL << IPU3_PAGE_SHIFT)
> +
> +#define IPU3_PT_BITS 10
> +#define IPU3_PT_PTES (1UL << IPU3_PT_BITS)
> +#define IPU3_PT_SIZE (IPU3_PT_PTES << 2)
> +#define IPU3_PT_ORDER(IPU3_PT_SIZE >> PAGE_SHIFT)
> +
> +#define IPU3_ADDR2PTE(addr)  ((addr) >> IPU3_PAGE_SHIFT)
> +#define IPU3_PTE2ADDR(pte)   ((phys_addr_t)(pte) << IPU3_PAGE_SHIFT)
> +
> +#define IPU3_L2PT_SHIFT  IPU3_PT_BITS
> +#define IPU3_L2PT_MASK   ((1UL << IPU3_L2PT_SHIFT) - 1)
> +
> +#define IPU3_L1PT_SHIFT  IPU3_PT_BITS
> +#define IPU3_L1PT_MASK   ((1UL << IPU3_L1PT_SHIFT) - 1)
> +
> +#define IPU3_MMU_ADDRESS_BITS(IPU3_PAGE_SHIFT + \
> +  IPU3_L2PT_SHIFT + \
> +  IPU3_L1PT_SHIFT)
> +
> +#define IMGU_REG_BASE0x4000
> +#define REG_TLB_INVALIDATE   (IMGU_REG_BASE + 0x300)
> +#define TLB_INVALIDATE   1
> +#define REG_L1_PHYS  (IMGU_REG_BASE + 0x304) /* 27-bit pfn */
> +#define REG_GP_HALT  (IMGU_REG_BASE + 0x5dc)
> +#define REG_GP_HALTED(IMGU_REG_BASE + 0x5e0)
> +
> +struct ipu3_mmu_domain {
> + struct iommu_domain domain;
> + struct ipu3_mmu *mmu;
> +};
> +
> +struct ipu3_mmu {
> + struct bus_type bus;
> + struct device *dev;
> + struct device dma_dev;
> +

Re: [PATCH v4 04/12] intel-ipu3: Add user space ABI definitions

Hi Yong,

On Tue, Oct 17, 2017 at 10:54:49PM -0500, Yong Zhi wrote:
> The UAPI header defines the structures and macros
> to be used by user space.
> 
> Signed-off-by: Rajmohan Mani 
> Signed-off-by: Yong Zhi 
> ---
>  include/uapi/linux/intel-ipu3.h | 2199 
> +++
>  1 file changed, 2199 insertions(+)
>  create mode 100644 include/uapi/linux/intel-ipu3.h
> 
> diff --git a/include/uapi/linux/intel-ipu3.h b/include/uapi/linux/intel-ipu3.h
> new file mode 100644
> index ..e27a449b4ec1
> --- /dev/null
> +++ b/include/uapi/linux/intel-ipu3.h
> @@ -0,0 +1,2199 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __IPU3_UAPI_H
> +#define __IPU3_UAPI_H
> +
> +#include 
> +
> +#define IPU3_UAPI_ISP_VEC_ELEMS  64
> +
> +#define IMGU_ABI_PAD __aligned(IPU3_UAPI_ISP_WORD_BYTES)
> +#define IPU3_ALIGN   __attribute__((aligned(IPU3_UAPI_ISP_WORD_BYTES)))
> +
> +#define IPU3_UAPI_ISP_WORD_BYTES 32
> +#define IPU3_UAPI_MAX_STRIPES2
> +
> +/*** ipu3_uapi_stats_3a ***/
> +
> +#define IPU3_UAPI_MAX_BUBBLE_SIZE10
> +
> +#define IPU3_UAPI_AE_COLORS  4
> +#define IPU3_UAPI_AE_BINS256
> +
> +#define IPU3_UAPI_AWB_MD_ITEM_SIZE   8
> +#define IPU3_UAPI_AWB_MAX_SETS   60
> +#define IPU3_UAPI_AWB_SET_SIZE   0x500
> +#define IPU3_UAPI_AWB_SPARE_FOR_BUBBLES \
> + (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \
> +  IPU3_UAPI_AWB_MD_ITEM_SIZE)
> +#define IPU3_UAPI_AWB_MAX_BUFFER_SIZE \
> + (IPU3_UAPI_AWB_MAX_SETS * \
> +  (IPU3_UAPI_AWB_SET_SIZE + IPU3_UAPI_AWB_SPARE_FOR_BUBBLES))
> +
> +#define IPU3_UAPI_AF_MAX_SETS24
> +#define IPU3_UAPI_AF_MD_ITEM_SIZE4
> +#define IPU3_UAPI_AF_SPARE_FOR_BUBBLES \
> + (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \
> +  IPU3_UAPI_AF_MD_ITEM_SIZE)
> +#define IPU3_UAPI_AF_Y_TABLE_SET_SIZE0x80
> +#define IPU3_UAPI_AF_Y_TABLE_MAX_SIZE \
> + (IPU3_UAPI_AF_MAX_SETS * \
> +  (IPU3_UAPI_AF_Y_TABLE_SET_SIZE + IPU3_UAPI_AF_SPARE_FOR_BUBBLES) * \
> +  IPU3_UAPI_MAX_STRIPES)
> +
> +#define IPU3_UAPI_AWB_FR_MAX_SETS24
> +#define IPU3_UAPI_AWB_FR_MD_ITEM_SIZE8
> +#define IPU3_UAPI_AWB_FR_BAYER_TBL_SIZE  0x100
> +#define IPU3_UAPI_AWB_FR_SPARE_FOR_BUBBLES \
> + (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \
> + IPU3_UAPI_AWB_FR_MD_ITEM_SIZE)
> +#define IPU3_UAPI_AWB_FR_BAYER_TABLE_MAX_SIZE \
> + (IPU3_UAPI_AWB_FR_MAX_SETS * \
> + (IPU3_UAPI_AWB_FR_BAYER_TBL_SIZE + \
> +  IPU3_UAPI_AWB_FR_SPARE_FOR_BUBBLES) * \
> + IPU3_UAPI_MAX_STRIPES)
> +
> +struct ipu3_uapi_grid_config {
> + __u8 width; /* 6 or 7 (rgbs_grd_cfg) bits */
> + __u8 height;
> + __u16 block_width_log2:3;
> + __u16 block_height_log2:3;
> + __u16 height_per_slice:8;   /* default value 1 */
> + __u16 x_start;  /* 12 bits */
> + __u16 y_start;
> +#define IPU3_UAPI_GRID_START_MASK((1 << 12) - 1)
> +#define IPU3_UAPI_GRID_Y_START_EN(1 << 15)
> + __u16 x_end;/* 12 bits */
> + __u16 y_end;
> +} __packed;
> +
> +struct ipu3_uapi_awb_meta_data {
> + __u8 meta_data_buffer[IPU3_UAPI_AWB_MAX_BUFFER_SIZE];
> +} __packed;
> +
> +struct ipu3_uapi_awb_raw_buffer {
> + struct ipu3_uapi_awb_meta_data meta_data;
> +} __packed;
> +
> +struct IPU3_ALIGN ipu3_uapi_awb_config_s {
> + __u16 rgbs_thr_gr;
> + __u16 rgbs_thr_r;
> + __u16 rgbs_thr_gb;
> + __u16 rgbs_thr_b;
> +/* controls generation of meta_data (like FF enable/disable) */
> +#define IPU3_UAPI_AWB_RGBS_THR_B_EN  (1 << 14)
> +#define IPU3_UAPI_AWB_RGBS_THR_B_INCL_SAT(1 << 15)
> +
> + struct ipu3_uapi_grid_config grid;
> +} __packed;
> +
> +struct ipu3_uapi_ae_raw_buffer {
> + __u32 vals[IPU3_UAPI_AE_BINS * IPU3_UAPI_AE_COLORS];
> +} __packed;
> +
> +struct ipu3_uapi_ae_raw_buffer_aligned {
> + struct ipu3_uapi_ae_raw_buffer buff IPU3_ALIGN;
> +} __packed;
> +
> +struct ipu3_uapi_ae_grid_config {
> + __u8 width;
> +

Re: [PATCH v3 08/12] intel-ipu3: params: compute and program ccs

Hi Yong,

On Tue, Jul 18, 2017 at 10:13:40PM -0500, Yong Zhi wrote:
> A collection of routines that are mainly responsible
> to calculate the acc parameters.
> 
> Signed-off-by: Yong Zhi 
> ---
>  drivers/media/pci/intel/ipu3/ipu3-css-params.c | 3114 
> 
>  drivers/media/pci/intel/ipu3/ipu3-css-params.h |  105 +
>  drivers/media/pci/intel/ipu3/ipu3-css.h|   92 +
>  3 files changed, 3311 insertions(+)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-params.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-params.h
> 
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-css-params.c 
> b/drivers/media/pci/intel/ipu3/ipu3-css-params.c
> new file mode 100644
> index 000..4b600bc
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3-css-params.c
> @@ -0,0 +1,3114 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +
> +#include "ipu3-abi.h"
> +#include "ipu3-css.h"
> +#include "ipu3-css-fw.h"
> +#include "ipu3-css-params.h"
> +#include "ipu3-tables.h"
> +
> +static unsigned int ipu3_css_scaler_get_exp(unsigned int counter,
> + unsigned int divider)
> +{
> + int i = fls(divider) - fls(counter);
> +
> + if (i <= 0)
> + return 0;
> +
> + if (divider >> i < counter)
> + i = i - 1;

i--;

> +
> + return i;
> +}
> +
> +/* Set up the CSS scaler look up table */
> +static void ipu3_css_scaler_setup_lut(unsigned int taps,
> +   unsigned int input_width,
> +   unsigned int output_width,
> +   int phase_step_correction,
> +   const int *coeffs,
> +   unsigned int coeffs_size,
> +   s8 coeff_lut[IMGU_SCALER_PHASES *
> +IMGU_SCALER_FILTER_TAPS],
> +   struct ipu3_css_scaler_info *info)
> +{
> + int tap;
> + int phase;
> + int exponent = ipu3_css_scaler_get_exp(output_width, input_width);
> + int mantissa = (1 << exponent) * output_width;
> + unsigned int phase_step = 0;
> + int phase_sum_left = 0;
> + int phase_sum_right = 0;
> +
> + for (phase = 0; phase < IMGU_SCALER_PHASES; phase++) {
> + for (tap = 0; tap < taps; tap++) {
> + /* flip table to for convolution reverse indexing */
> + s64 coeff =  coeffs[coeffs_size -
> + ((tap * (coeffs_size / taps)) +
> + phase) - 1];
> + coeff *= mantissa;
> + coeff /= input_width;

Please use do_div() so this will compile on 32-bit machines.

> +
> + /* Add +"0.5" */
> + coeff += 1 << (IMGU_SCALER_COEFF_BITS - 1);
> + coeff >>= IMGU_SCALER_COEFF_BITS;
> +
> + coeff_lut[phase * IMGU_SCALER_FILTER_TAPS + tap] =
> + coeff;
> + }
> + }
> +
> + phase_step = IMGU_SCALER_PHASES *
> + (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF)
> + * output_width / input_width;
> + phase_step += phase_step_correction;
> + phase_sum_left = (taps / 2 * IMGU_SCALER_PHASES *
> + (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF))
> + - (1 << (IMGU_SCALER_PHASE_COUNTER_PREC_REF - 1));
> + phase_sum_right = (taps / 2 * IMGU_SCALER_PHASES *
> + (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF))
> + + (1 << (IMGU_SCALER_PHASE_COUNTER_PREC_REF - 1));
> +
> + info->exp_shift = IMGU_SCALER_MAX_EXPONENT_SHIFT - exponent;
> + info->pad_left = (phase_sum_left % phase_step == 0) ?
> + phase_sum_left / phase_step - 1 : phase_sum_left / phase_step;
> + info->pad_right = (phase_sum_right % phase_step == 0) ?
> + phase_sum_right / phase_step - 1 : phase_sum_right / phase_step;
> + info->phase_init = phase_sum_left - phase_step * info->pad_left;
> + info->phase_step = phase_step;
> + info->crop_left = taps - 1;
> + info->crop_top = taps - 1;
> +}
> +
> +/*
> + * Calculates the exact output image width/height, based on phase_step 
> setting
> + * (must be perfectly aligned with hardware).
> + */
> +static unsigned int ipu3_css_scaler_ca

[PATCH 1/4] arm: dts: rockchip: add the cec clk for dw-hdmi on rk3288

From: Hans Verkuil 

The dw-hdmi block needs the cec clk for the rk3288. Add it.

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/rk3288.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 356ed1e62452..a48352aa1591 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1124,8 +1124,8 @@
reg-io-width = <4>;
rockchip,grf = <&grf>;
interrupts = ;
-   clocks = <&cru  PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
-   clock-names = "iahb", "isfr";
+   clocks = <&cru  PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>, <&cru 
SCLK_HDMI_CEC>;
+   clock-names = "iahb", "isfr", "cec";
power-domains = <&power RK3288_PD_VIO>;
status = "disabled";
 
-- 
2.14.1

[PATCH 3/4] arm: dts: rockchip: define the two possible CEC pins

From: Hans Verkuil 

The CEC line can be routed to two possible pins. Define those pins.

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/rk3288.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index a48352aa1591..2421913bc1fd 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1431,6 +1431,14 @@
rockchip,pins = <7 19 RK_FUNC_2 
&pcfg_pull_none>,
<7 20 RK_FUNC_2 
&pcfg_pull_none>;
};
+
+   hdmi_cec_c0: hdmi-cec-c0 {
+   rockchip,pins = <7 RK_PC0 RK_FUNC_2 
&pcfg_pull_none>;
+   };
+
+   hdmi_cec_c7: hdmi-cec-c7 {
+   rockchip,pins = <7 RK_PC7 RK_FUNC_4 
&pcfg_pull_none>;
+   };
};
 
pcfg_pull_up: pcfg-pull-up {
-- 
2.14.1

[PATCH 4/4] arm: dts: rockchip: select which CEC pin is used for the Firefly Reload

From: Hans Verkuil 

The Firefly Reload uses PC7.

Signed-off-by: Hans Verkuil 
Tested-by: Hans Verkuil 
---
 arch/arm/boot/dts/rk3288-firefly-reload.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-firefly-reload.dts 
b/arch/arm/boot/dts/rk3288-firefly-reload.dts
index 859938d8832e..eab176e3dfc3 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload.dts
+++ b/arch/arm/boot/dts/rk3288-firefly-reload.dts
@@ -228,6 +228,8 @@
 
 &hdmi {
ddc-i2c-bus = <&i2c5>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&hdmi_cec_c0>;
status = "okay";
 };
 
-- 
2.14.1

[PATCH 0/4] arm: dts: rockchip: enable HDMI+CEC on Firefly Reload

From: Hans Verkuil 

This patch series sits on top of these two patch series:

https://lkml.org/lkml/2017/10/13/971
https://lkml.org/lkml/2017/10/14/161

The first adds support for the cec clk in dw-hdmi, the second adds an
iomux-route for the CEC pin on the rk3288.

This patch series defines the cec clk for the rk3288, enables the
first HDMI output on the Firefly Reload. The second output isn't working,
I don't have enough knowledge to enable it. But I can test any patches
adding support for it!

The third patch defines the two possible CEC pins and the last selects
the correct pin for the Firefly Reload.

Likely the same thing can be done for the 'regular' Firefly, but I don't
have the hardware to test.

Regards,

Hans


Hans Verkuil (4):
  arm: dts: rockchip: add the cec clk for dw-hdmi on rk3288
  arm: dts: rockchip: enable the first hdmi output
  arm: dts: rockchip: define the two possible CEC pins
  arm: dts: rockchip: select which CEC pin is used for the Firefly
Reload

 arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi |  2 ++
 arch/arm/boot/dts/rk3288-firefly-reload.dts   | 11 +++
 arch/arm/boot/dts/rk3288.dtsi | 12 ++--
 3 files changed, 23 insertions(+), 2 deletions(-)

-- 
2.14.1

[PATCH 2/4] arm: dts: rockchip: enable the first hdmi output

From: Hans Verkuil 

The vdd10_lcd and vcc18_lcd regulators need to be enabled for HDMI output
to work, so add 'regulator-always-on', just as is done in rk3288-firefly.dtsi.

Also enable i2c5 and the hdmi block.

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 2 ++
 arch/arm/boot/dts/rk3288-firefly-reload.dts   | 9 +
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi 
b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
index 5f05815f47e0..5f1e336dbaac 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
@@ -184,6 +184,7 @@
regulator-name = "vdd10_lcd";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
+   regulator-always-on;
};
 
vcca_18: REG7  {
@@ -223,6 +224,7 @@
regulator-name = "vcc18_lcd";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-always-on;
};
};
};
diff --git a/arch/arm/boot/dts/rk3288-firefly-reload.dts 
b/arch/arm/boot/dts/rk3288-firefly-reload.dts
index 7da0947ababb..859938d8832e 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload.dts
+++ b/arch/arm/boot/dts/rk3288-firefly-reload.dts
@@ -226,6 +226,11 @@
};
 };
 
+&hdmi {
+   ddc-i2c-bus = <&i2c5>;
+   status = "okay";
+};
+
 &i2c0 {
hym8563: hym8563@51 {
compatible = "haoyu,hym8563";
@@ -255,6 +260,10 @@
};
 };
 
+&i2c5 {
+   status = "okay";
+};
+
 &i2s {
status = "okay";
 };
-- 
2.14.1

[PATCH] media: s5p-mfc: Add support for V4L2_MEMORY_DMABUF type

2017-10-20 Thread Marek Szyprowski

From: Seung-Woo Kim 

There is memory constraint for the buffers in V5 of the MFC hardware, but
when IOMMU is used, then this constraint is meaningless. Other version of
the MFC hardware don't have such limitations. So in such cases the driver
is able to use buffers placed anywhere in the system memory, thus USERPTR
and DMABUF operation modes can be also enabled.

This patch also removes USERPTR operation mode from encoder node, as it
doesn't work with v5 MFC hardware without IOMMU being enabled.

Signed-off-by: Seung-Woo Kim 
[mszyprow: adapted to v4.14 code base and updated commit message]
Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 14 --
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 73 
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 24 ++---
 3 files changed, 89 insertions(+), 22 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index cf68aed59e0d..f975523dc040 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -754,6 +754,7 @@ static int s5p_mfc_open(struct file *file)
struct s5p_mfc_dev *dev = video_drvdata(file);
struct s5p_mfc_ctx *ctx = NULL;
struct vb2_queue *q;
+   unsigned int io_modes;
int ret = 0;
 
mfc_debug_enter();
@@ -839,16 +840,21 @@ static int s5p_mfc_open(struct file *file)
if (ret)
goto err_init_hw;
}
+
+   io_modes = VB2_MMAP;
+   if (exynos_is_iommu_available(&dev->plat_dev->dev) || !IS_TWOPORT(dev))
+   io_modes |= VB2_USERPTR | VB2_DMABUF;
+
/* Init videobuf2 queue for CAPTURE */
q = &ctx->vq_dst;
q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
q->drv_priv = &ctx->fh;
q->lock = &dev->mfc_mutex;
if (vdev == dev->vfd_dec) {
-   q->io_modes = VB2_MMAP;
+   q->io_modes = io_modes;
q->ops = get_dec_queue_ops();
} else if (vdev == dev->vfd_enc) {
-   q->io_modes = VB2_MMAP | VB2_USERPTR;
+   q->io_modes = io_modes;
q->ops = get_enc_queue_ops();
} else {
ret = -ENOENT;
@@ -872,10 +878,10 @@ static int s5p_mfc_open(struct file *file)
q->drv_priv = &ctx->fh;
q->lock = &dev->mfc_mutex;
if (vdev == dev->vfd_dec) {
-   q->io_modes = VB2_MMAP;
+   q->io_modes = io_modes;
q->ops = get_dec_queue_ops();
} else if (vdev == dev->vfd_enc) {
-   q->io_modes = VB2_MMAP | VB2_USERPTR;
+   q->io_modes = io_modes;
q->ops = get_enc_queue_ops();
} else {
ret = -ENOENT;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 8937b0af7cb3..efe65fce4880 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -546,14 +546,27 @@ static int reqbufs_capture(struct s5p_mfc_dev *dev, 
struct s5p_mfc_ctx *ctx,
goto out;
}
 
-   WARN_ON(ctx->dst_bufs_cnt != ctx->total_dpb_count);
-   ctx->capture_state = QUEUE_BUFS_MMAPED;
+   if (reqbufs->memory == V4L2_MEMORY_MMAP) {
+   if (ctx->dst_bufs_cnt == ctx->total_dpb_count) {
+   ctx->capture_state = QUEUE_BUFS_MMAPED;
+   } else {
+   mfc_err("Not all buffers passed to buf_init\n");
+   reqbufs->count = 0;
+   ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
+   s5p_mfc_hw_call(dev->mfc_ops,
+   release_codec_buffers, ctx);
+   ret = -ENOMEM;
+   goto out;
+   }
+   }
 
if (s5p_mfc_ctx_ready(ctx))
set_work_bit_irqsave(ctx);
s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
-   s5p_mfc_wait_for_done_ctx(ctx, S5P_MFC_R2H_CMD_INIT_BUFFERS_RET,
- 0);
+   if (reqbufs->memory == V4L2_MEMORY_MMAP) {
+   s5p_mfc_wait_for_done_ctx(ctx,
+S5P_MFC_R2H_CMD_INIT_BUFFERS_RET, 0);
+   }
} else {
mfc_err("Buffers have already been requested\n");
ret = -EINVAL;
@@ -571,15 +584,19 @@ static int vidioc_reqbufs(struct file *file, void *priv,
 {
struct s5p_mfc_dev *dev = video_drvdata(file);
struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
-
-   if (reqbufs->memory != V4L2_MEMORY_MMAP) {
-   mfc_debug(2, "Only V4L2_MEMORY_MMAP is supported\n");
-   return -EIN

Re: [PATCH v4 06/12] intel-ipu3: css: imgu dma buff pool

On Tue, Oct 17, 2017 at 10:54:51PM -0500, Yong Zhi wrote:
> The pools are used to store previous parameters set by
> user with the parameter queue. Due to pipelining,
> there needs to be multiple sets (up to four)
> of parameters which are queued in a host-to-sp queue.
> 
> Signed-off-by: Yong Zhi 
> Signed-off-by: Tomasz Figa 
> ---
>  drivers/media/pci/intel/ipu3/ipu3-css-pool.c | 132 
> +++
>  drivers/media/pci/intel/ipu3/ipu3-css-pool.h |  54 +++
>  2 files changed, 186 insertions(+)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-pool.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-pool.h
> 
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-css-pool.c 
> b/drivers/media/pci/intel/ipu3/ipu3-css-pool.c
> new file mode 100644
> index ..d08e2a8b68ed
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3-css-pool.c
> @@ -0,0 +1,132 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "ipu3-css-pool.h"
> +#include "ipu3-dmamap.h"
> +
> +int ipu3_css_dma_alloc(struct device *dev,
> +struct ipu3_css_map *map, size_t size)
> +{
> + struct imgu_device *imgu = dev_get_drvdata(dev);
> +
> + if (size == 0) {
> + map->vaddr = NULL;
> + return 0;
> + }
> +
> + if (!ipu3_dmamap_alloc(imgu, map, size))
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +void ipu3_css_dma_free(struct device *dev, struct ipu3_css_map *map)
> +{
> + struct imgu_device *imgu = dev_get_drvdata(dev);
> +
> + ipu3_dmamap_free(imgu, map);
> +}
> +
> +void ipu3_css_pool_cleanup(struct device *dev, struct ipu3_css_pool *pool)
> +{
> + int i;
> +
> + for (i = 0; i < IPU3_CSS_POOL_SIZE; i++)
> + ipu3_css_dma_free(dev, &pool->entry[i].param);
> +}
> +
> +int ipu3_css_pool_init(struct device *dev, struct ipu3_css_pool *pool,
> +int size)
> +{
> + int i;
> +
> + for (i = 0; i < IPU3_CSS_POOL_SIZE; i++) {
> + pool->entry[i].framenum = INT_MIN;
> + if (ipu3_css_dma_alloc(dev, &pool->entry[i].param, size))
> + goto fail;
> + }
> +
> + pool->last = IPU3_CSS_POOL_SIZE;
> +
> + return 0;
> +
> +fail:
> + ipu3_css_pool_cleanup(dev, pool);
> + return -ENOMEM;
> +}
> +
> +/*
> + * Check that the following call to pool_get succeeds.
> + * Return negative on error.
> + */
> +static int ipu3_css_pool_check(struct ipu3_css_pool *pool, long framenum)
> +{
> + /* Get the oldest entry */
> + int n = (pool->last + 1) % IPU3_CSS_POOL_SIZE;
> +
> + /*
> +  * pool->entry[n].framenum stores the frame number where that
> +  * entry was allocated. If that was allocated more than POOL_SIZE
> +  * frames back, it is old enough that we know it is no more in
> +  * use by firmware.
> +  */
> + if (pool->entry[n].framenum + IPU3_CSS_POOL_SIZE > framenum)

This will wrap around and the comparison fails when pool->entry[n].framenum
+ IPU3_CSS_POOL_SIZE - 1 reaches LONG_MAX.

You could write this as:

if (framenum - pool->entry[n].franenum < IPU3_CSS_POOL_SIZE)

to avoid the problem.

You could use also int instead of long without any other changes to the
code, or change INT_MAX / INT_MIN assignments to LONG_MAX / LONG_MIN.

> + return -ENOSPC;
> +
> + return n;
> +}
> +
> +/*
> + * Allocate a new parameter from pool at frame number `framenum'.
> + * Release the oldest entry in the pool to make space for the new entry.
> + * Return negative on error.
> + */
> +int ipu3_css_pool_get(struct ipu3_css_pool *pool, long framenum)
> +{
> + int n = ipu3_css_pool_check(pool, framenum);
> +
> + if (n < 0)
> + return n;
> +
> + pool->entry[n].framenum = framenum;
> + pool->last = n;
> +
> + return n;
> +}
> +
> +/*
> + * Undo, for all practical purposes, the effect of pool_get().
> + */
> +void ipu3_css_pool_put(struct ipu3_css_pool *pool)
> +{
> + pool->entry[pool->last].framenum = INT_MIN;
> + pool->last = (pool->last + IPU3_CSS_POOL_SIZE - 1) % IPU3_CSS_POOL_SIZE;
> +}
> +
> +const struct ipu3_css_map *
> +ipu3_css_pool_last(struct ipu3_css_pool *pool, unsigned int n)
> +{
> + static const struct ipu3_css_map null_map = { 0 };
> + int i = (pool->last + IPU3_CSS_POOL_SIZE - n) % IPU3_CSS_POOL_SIZE;
> +
> + WARN_ON(n >= IPU3_CSS_POOL_SIZE);
> +
> + if (pool->entry[i].framenum < 0)
> + retu

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

On Tue, Oct 17, 2017 at 10:55:59PM -0500, Yong Zhi wrote:
> This patch adds support for the Intel IPU v3 as found
> on Skylake and Kaby Lake SoCs. The driver has a dependency
> on the firmware binary to function properly.
> 
> Signed-off-by: Yong Zhi 
> Signed-off-by: Tomasz Figa 
> ---
>  drivers/media/pci/intel/ipu3/Kconfig  |  17 +
>  drivers/media/pci/intel/ipu3/Makefile |   6 +
>  drivers/media/pci/intel/ipu3/ipu3.c   | 882 
> ++
>  drivers/media/pci/intel/ipu3/ipu3.h   | 186 +++
>  4 files changed, 1091 insertions(+)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3.h
> 
> diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
> b/drivers/media/pci/intel/ipu3/Kconfig
> index d7dab52dc881..344b57df2179 100644
> --- a/drivers/media/pci/intel/ipu3/Kconfig
> +++ b/drivers/media/pci/intel/ipu3/Kconfig
> @@ -33,3 +33,20 @@ config INTEL_IPU3_DMAMAP
>   select IOMMU_IOVA
>   ---help---
> This is IPU3 IOMMU domain specific DMA driver.
> +
> +config VIDEO_IPU3_IMGU
> + tristate "Intel ipu3-imgu driver"
> + depends on PCI && VIDEO_V4L2 && IOMMU_SUPPORT
> + depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
> + depends on X86 || COMPILE_TEST
> + select INTEL_IPU3_MMU
> + select INTEL_IPU3_DMAMAP
> + select VIDEOBUF2_DMA_SG
> +
> + ---help---
> + This is the video4linux2 driver for Intel IPU3 image processing unit,
> + found in Intel Skylake and Kaby Lake SoCs and used for processing
> + images and video.
> +
> + Say Y or M here if you have a Skylake/Kaby Lake SoC with a MIPI
> + camera. The module will be called ipu3-imgu.
> diff --git a/drivers/media/pci/intel/ipu3/Makefile 
> b/drivers/media/pci/intel/ipu3/Makefile
> index 651773231496..c613f508ffe4 100644
> --- a/drivers/media/pci/intel/ipu3/Makefile
> +++ b/drivers/media/pci/intel/ipu3/Makefile
> @@ -14,3 +14,9 @@
>  obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
>  obj-$(CONFIG_INTEL_IPU3_MMU) += ipu3-mmu.o
>  obj-$(CONFIG_INTEL_IPU3_DMAMAP) += ipu3-dmamap.o
> +ipu3-imgu-objs += \
> + ipu3-tables.o ipu3-css-pool.o \
> + ipu3-css-fw.o ipu3-css-params.o \
> + ipu3-css.o ipu3-v4l2.o ipu3.o
> +
> +obj-$(CONFIG_VIDEO_IPU3_IMGU) += ipu3-imgu.o
> diff --git a/drivers/media/pci/intel/ipu3/ipu3.c 
> b/drivers/media/pci/intel/ipu3/ipu3.c
> new file mode 100644
> index ..5492af263ca0
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3.c
> @@ -0,0 +1,882 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + * Copyright (C) 2017 Google, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Based on Intel IPU4 driver.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ipu3.h"
> +#include "ipu3-mmu.h"
> +#include "ipu3-dmamap.h"
> +
> +#define IMGU_NAME"ipu3-imgu"
> +#define IMGU_PCI_ID  0x1919
> +#define IMGU_PCI_BAR 0
> +#define IMGU_DMA_MASKDMA_BIT_MASK(39)
> +#define IMGU_MAX_QUEUE_DEPTH (2 + 2)
> +
> +static const struct imgu_node_mapping imgu_node_map[IMGU_NODE_NUM] = {
> + [IMGU_NODE_IN] = {IPU3_CSS_QUEUE_IN, "input"},
> + [IMGU_NODE_PARAMS] = {IPU3_CSS_QUEUE_PARAMS, "parameters"},
> + [IMGU_NODE_OUT] = {IPU3_CSS_QUEUE_OUT, "output"},
> + [IMGU_NODE_VF] = {IPU3_CSS_QUEUE_VF, "viewfinder"},
> + [IMGU_NODE_PV] = {IPU3_CSS_QUEUE_VF, "postview"},
> + [IMGU_NODE_STAT_3A] = {IPU3_CSS_QUEUE_STAT_3A, "3a stat"},
> + [IMGU_NODE_STAT_DVS] = {IPU3_CSS_QUEUE_STAT_DVS, "dvs stat"},
> + [IMGU_NODE_STAT_LACE] = {IPU3_CSS_QUEUE_STAT_LACE, "lace stat"},
> +};
> +
> +int imgu_node_to_queue(int node)
> +{
> + return imgu_node_map[node].css_queue;
> +}
> +
> +int imgu_map_node(struct imgu_device *imgu, int css_queue)
> +{
> + unsigned int i;
> +
> + if (css_queue == IPU3_CSS_QUEUE_VF)
> + return imgu->mem2mem2.nodes[IMGU_NODE_VF].enabled ?
> + IMGU_NODE_VF : IMGU_NODE_PV;
> +
> + for (i = 0; i < IMGU_NODE_NUM; i++)
> + if (imgu_node_map[i].css_queue == css_queue)
> + return i;
> +
> + return -EINVAL;
> +}
> +
> +/ Dummy buffers /
> +
> +static void imgu_dummybufs_cleanup(struct imgu_device *imgu)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < IPU3_CSS_QUEUES; i++)
> + ipu3_dmamap_free(imgu, &imgu->queues[i].dmap);
> +}
> +
> +static int imgu_dummybufs

[ANN] Agenda (v2) for the media mini-summit on Friday Oct 27 in Prague

Hi all,

We are organizing a media mini-summit on Friday October 27 in Prague, co-located
with the ELCE conference:

http://events.linuxfoundation.org/events/embedded-linux-conference-europe

If you plan to attend, please let me know. It is open for all, but it is
nice if we know beforehand who we can expect.

You can register here:

http://events.linuxfoundation.org/events/open-source-summit-europe/extend-the-experience/co-located-events

Name of the room in the Hilton Prague: Athens

Currently known attendees:

Sakari Ailus
Mauro Carvalho Chehab
Alexandre Courbot
Michael Ira Krufky
Gustavo Padovan
Benoit Parrot
Laurent Pinchart
Ricardo Ribalda Delgado
Hans Verkuil

Agenda
==

General remarks: the given start/end times for the various topics are
approximate since it is always hard to predict how long a discussion will take.
The Request/Jobs API topic is placed last since I expect that that will take
most of our time.

Let me know asap if there are problems with this schedule, or if new topics
are requested.

8:00-9:00: Continental Breakfast served in the room

9:00-9:15: Introduction (Hans)

9:15-9:30: Status of the HDMI CEC kernel support (Hans)
Give a quick overview of the status: what has been merged, what is
still
pending, what is under development.

9:30-10:00: V4L2 Explicit Synchronization (Gustavo)
Quick overview and discussion of the API/direction we are going
with fences.

10:00-10:30 Media development process: what works, what doesn't (Hans)
In the past 6 months or so we tried to improve the media development
process. This is an overview of what we did and why we did it, what
works and what doesn't. Feedback is very much appreciated. It is
even
more appreciated if people/companies would be willing to assign
new developers to help improve the media subsystem!

10:30-11:00: Morning Break served in the room

11:00-12:00: Media kAPI and uAPI documentation (Mauro)
Give the current status of media API documentation and identify
possible
gaps and how to improve it.

12:00-13:30: Lunch

13:30-??:??: Request/jobs API (Alexandre)
Overview of the work based on the request API (proposed new name:
jobs API),
to hopefully converge to something that can be merged soon.

15:00-15:30: Afternoon Break served in the room

17:00-17:30 (or earlier if we're lucky): Wrap up (Hans)
Create action items (and who will take care of them) if needed.
Summarize and conclude the day.

Regards,

Hans

v2: updated room, attendee list, moved the last slot 30 minutes later

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

Hi Yong,

On Tue, Oct 17, 2017 at 10:54:56PM -0500, Yong Zhi wrote:
> ipu3 imgu video device based on v4l2, vb2 and
> media controller framework.
> 
> Signed-off-by: Yong Zhi 
> Signed-off-by: Ramya Vijaykumar 
> ---
>  drivers/media/pci/intel/ipu3/ipu3-v4l2.c | 1150 
> ++
>  1 file changed, 1150 insertions(+)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-v4l2.c
> 
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-v4l2.c 
> b/drivers/media/pci/intel/ipu3/ipu3-v4l2.c
> new file mode 100644
> index ..4618880b8675
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3-v4l2.c
> @@ -0,0 +1,1150 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ipu3.h"
> +#include "ipu3-dmamap.h"
> +
> +/ v4l2_subdev_ops /
> +
> +static int ipu3_subdev_s_stream(struct v4l2_subdev *sd, int enable)
> +{
> + struct ipu3_mem2mem2_device *m2m2 =
> + container_of(sd, struct ipu3_mem2mem2_device, subdev);
> + int r = 0;
> +
> + if (m2m2->ops && m2m2->ops->s_stream)
> + r = m2m2->ops->s_stream(m2m2, enable);
> +
> + if (!r)
> + m2m2->streaming = enable;
> +
> + return r;
> +}
> +
> +static int ipu3_subdev_get_fmt(struct v4l2_subdev *sd,
> +struct v4l2_subdev_pad_config *cfg,
> +struct v4l2_subdev_format *fmt)
> +{
> + struct ipu3_mem2mem2_device *m2m2 =
> + container_of(sd, struct ipu3_mem2mem2_device, subdev);
> + struct v4l2_mbus_framefmt *mf;
> + u32 pad = fmt->pad;
> +
> + if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
> + fmt->format = m2m2->nodes[pad].pad_fmt;
> + } else {
> + mf = v4l2_subdev_get_try_format(sd, cfg, pad);
> + fmt->format = *mf;
> + }
> +
> + return 0;
> +}
> +
> +static int ipu3_subdev_set_fmt(struct v4l2_subdev *sd,
> +struct v4l2_subdev_pad_config *cfg,
> +struct v4l2_subdev_format *fmt)
> +{
> + struct ipu3_mem2mem2_device *m2m2 =
> + container_of(sd, struct ipu3_mem2mem2_device, subdev);
> + struct v4l2_mbus_framefmt *mf;
> + u32 pad = fmt->pad;
> +
> + if (fmt->which == V4L2_SUBDEV_FORMAT_TRY)
> + mf = v4l2_subdev_get_try_format(sd, cfg, pad);
> + else
> + mf = &m2m2->nodes[pad].pad_fmt;
> +
> + /* Clamp the w and h based on the hardware capabilities */
> + if (m2m2->subdev_pads[pad].flags & MEDIA_PAD_FL_SOURCE) {
> + fmt->format.width = clamp(fmt->format.width,
> +   IPU3_OUTPUT_MIN_WIDTH,
> +   IPU3_OUTPUT_MAX_WIDTH);
> + fmt->format.height = clamp(fmt->format.height,
> +IPU3_OUTPUT_MIN_HEIGHT,
> +IPU3_OUTPUT_MAX_HEIGHT);
> + } else {
> + fmt->format.width = clamp(fmt->format.width,
> +   IPU3_INPUT_MIN_WIDTH,
> +   IPU3_INPUT_MAX_WIDTH);
> + fmt->format.height = clamp(fmt->format.height,
> +IPU3_INPUT_MIN_HEIGHT,
> +IPU3_INPUT_MAX_HEIGHT);
> + }
> +
> + *mf = fmt->format;
> +
> + return 0;
> +}
> +
> +/ media_entity_operations /
> +
> +static int ipu3_link_setup(struct media_entity *entity,
> +const struct media_pad *local,
> +const struct media_pad *remote, u32 flags)
> +{
> + struct ipu3_mem2mem2_device *m2m2 =
> + container_of(entity, struct ipu3_mem2mem2_device, subdev.entity);
> + u32 pad = local->index;
> +
> + WARN_ON(pad >= m2m2->num_nodes);
> +
> + m2m2->nodes[pad].enabled = !!(flags & MEDIA_LNK_FL_ENABLED);
> +
> + return 0;
> +}
> +
> +/ vb2_ops /
> +
> +static int ipu3_vb2_buf_init(struct vb2_buffer *vb)
> +{
> + struct sg_table *sg = vb2_dma_sg_plane_desc(vb, 0);
> + struct ipu3_mem2mem2_device *m2m2 = vb2_get_drv_priv(vb->vb2_queue);
> + struct imgu_device *imgu =
> + container_of(m2m2, struct imgu_device, mem2mem2);
> + struct imgu_buffer *buf = container_of(vb,
> + struct imgu_buffer, m2m2_buf.vbb.vb

Re: [PATCH v15.1 24/32] v4l: fwnode: Add a helper function to obtain device / integer references

Hi Hans,

On Thu, Oct 19, 2017 at 08:52:22AM +0200, Hans Verkuil wrote:
> On 10/18/2017 05:32 PM, Sakari Ailus wrote:
> > On Wed, Oct 18, 2017 at 04:56:56PM +0300, Sakari Ailus wrote:
> >> v4l2_fwnode_reference_parse_int_prop() will find an fwnode such that under
> >> the device's own fwnode, it will follow child fwnodes with the given
> >> property-value pair and return the resulting fwnode.
> >>
> >> Signed-off-by: Sakari Ailus 
> >> ---
> >> since v15:
> >>
> >> - Use a graph example instead of a LED one; this way nprops will be 2.
> >>
> >>  drivers/media/v4l2-core/v4l2-fwnode.c | 252 
> >> ++
> >>  1 file changed, 252 insertions(+)
> >>
> >> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> >> b/drivers/media/v4l2-core/v4l2-fwnode.c
> >> index edd2e8d983a1..989a6f8a09fa 100644
> >> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> >> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> >> @@ -578,6 +578,258 @@ static int v4l2_fwnode_reference_parse(
> >>return ret;
> >>  }
> >>  
> >> +/*
> >> + * v4l2_fwnode_reference_get_int_prop - parse a reference with integer
> >> + *arguments
> >> + * @fwnode: fwnode to read @prop from
> >> + * @notifier: notifier for @dev
> >> + * @prop: the name of the property
> >> + * @index: the index of the reference to get
> >> + * @props: the array of integer property names
> >> + * @nprops: the number of integer property names in @nprops
> >> + *
> >> + * First find an fwnode referred to by the reference at @index in @prop.
> >> + *
> >> + * Then under that fwnode, @nprops times, for each property in @props,
> >> + * iteratively follow child nodes starting from fwnode such that they 
> >> have the
> >> + * property in @props array at the index of the child node distance from 
> >> the
> >> + * root node and the value of that property matching with the integer 
> >> argument
> >> + * of the reference, at the same index.
> >> + *
> >> + * The child fwnode reched at the end of the iteration is then returned 
> >> to the
> >> + * caller.
> > 
> > An alternative to these three paragraphs could be:
> > 
> > First obtain an fwnode, with integer arguments, referred to by the reference
> > at @index in @prop. These shall be referred as "remote fwnode" and "remote
> > fwnode arguments".
> > 
> > Under the remote fwnode, perform the following steps iteratively @nprops
> > times. Let the number of iteration be "i", starting from 0.
> > 
> > 1. Designate the remote fwnode as the "current fwnode".
> > 
> > 2. Begin iterating child fwnodes under the current fwnode.
> > 
> > 3. Find next child fwnode under the current fwnode. If no node is found,
> >return NULL.
> > 
> > 4. From the child fwnode, read 32-bit unsigned integer property named as
> >the i'th element in @props array.
> > 
> > 5. Compare the value of that integer property with the i'th element in the
> >remote fwnode argument array. If the values do not match, go to (3).
> > 
> > 6. Increment i by one. If i matches with @nprops, return the child fwnode.
> > 
> > 7. Designate the child fwnode as the current fwnode and continue from (2).
> 
> This is definitely a better text.
> 
> However, this describes the mechanics of the function, not what its purpose
> actually is.
> 
> The core reason for this is that you cannot refer to just any node in ACPI.
> So to refer to an endpoint (easy in DT) you need to refer to a device, then
> provide a list of (property name, property value) tuples where each tuple
> uniquely identifies a child node. The first tuple identifies a child directly
> underneath the device fwnode, the next tuple identifies a child node 
> underneath
> the fwnode identified by the previous tuple, etc. until you reached the fwnode
> you need.
> 
> Does this make sense?

I'm fine with using the above text. The function will move out of V4L2
probably quite soon and the documentation in the ACPI framework will likely
be different from whatever we end up using here anyway.

> 
> > 
> >> + *
> >> + * An example with a graph, as defined in 
> >> Documentation/acpi/dsd/graph.txt:
> >> + *
> >> + *Scope (\_SB.PCI0.I2C2)
> >> + *{
> >> + *Device (CAM0)
> >> + *{
> >> + *Name (_DSD, Package () {
> >> + *
> >> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >> + *Package () {
> >> + *Package () {
> >> + *"compatible",
> >> + *Package () { 
> >> "nokia,smia" }
> >> + *},
> >> + *},
> >> + *
> >> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> >> + *Package () {
> >> + *Package () { "port0", "PRT0" },
> >>

Re: [PATCH 1/2] v4l-utils: do not query capabilities of sub-devices.

On 19/10/17 16:53, Sakari Ailus wrote:
> Hi Harald and Hans,
> 
> On Thu, Oct 19, 2017 at 03:09:15PM +0200, Harald Dankworth wrote:
>> Find the major and minor numbers of the device. Check if the
>> file /dev/dev/char/major:minor/uevent contains "DEVNAME=v4l-subdev".
>> If so, the device is a sub-device.
>>
>> Signed-off-by: Harald Dankworth 
>> Reviewed-by: Hans Verkuil 
> 
> I wonder if this is the best way to obtain the information. I thought there
> was an intent to add something to sysfs that wasn't based on device names.
> This also hardcodes the sysfs path.

This is what we discussed on irc some time ago. And if /sys is mounted somewhere
else, then you have bigger problems :-)

The device name in /sys comes from the driver and isn't changed by udev rules.
So we can use it to determine if it is a subdev or not.

> Would udev provide anything useful in this respect?

Not all embedded systems use udev. I'd rather not depend on it, at least not for
this utility.

The alternative to this is to add a QUERYCAP-like ioctl for subdevs, but my
proposal for that has been repeatedly shot down.

In the meantime we need *something* so you can use v4l2-ctl to query/get/set
controls and the EDID for HDMI receivers (Tim Harvey needs this).

I would like to merge this soon. It can always be changed if we switch to 
another
better method.

Regards,

Hans

> 
> yavta would likely benefit from something similar.
> 
>> ---
>>  utils/v4l2-ctl/v4l2-ctl.cpp | 56 
>> -
>>  1 file changed, 55 insertions(+), 1 deletion(-)
>>
>> diff --git a/utils/v4l2-ctl/v4l2-ctl.cpp b/utils/v4l2-ctl/v4l2-ctl.cpp
>> index 5c67bf0..e02dc75 100644
>> --- a/utils/v4l2-ctl/v4l2-ctl.cpp
>> +++ b/utils/v4l2-ctl/v4l2-ctl.cpp
>> @@ -46,6 +46,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  char options[OptLast];
>>  
>> @@ -1142,6 +1143,59 @@ __u32 find_pixel_format(int fd, unsigned index, bool 
>> output, bool mplane)
>>  return fmt.pixelformat;
>>  }
>>  
>> +static bool is_subdevice(int fd)
>> +{
>> +struct stat sb;
>> +if (fstat(fd, &sb) == -1) {
>> +fprintf(stderr, "failed to stat file\n");
>> +exit(1);
>> +}
>> +
>> +char uevent_path[100];
>> +if (snprintf(uevent_path, sizeof(uevent_path), 
>> "/sys/dev/char/%d:%d/uevent",
>> + major(sb.st_rdev), minor(sb.st_rdev)) == -1) {
>> +fprintf(stderr, "failed to create uevent file path\n");
>> +exit(1);
>> +}
>> +
>> +std::ifstream uevent_file(uevent_path);
>> +if (uevent_file.fail()) {
>> +fprintf(stderr, "failed to open %s\n", uevent_path);
>> +exit(1);
>> +}
>> +
>> +std::string line;
>> +
>> +while (std::getline(uevent_file, line)) {
>> +if (line.compare(0, 8, "DEVNAME="))
>> +continue;
>> +
>> +static const char * devnames[] = {
>> +"v4l-subdev",
>> +"video",
>> +"vbi",
>> +"radio",
>> +"swradio",
>> +"v4l-touch",
>> +NULL
>> +};
>> +
>> +for (size_t i = 0; devnames[i]; i++) {
>> +size_t len = strlen(devnames[i]);
>> +
>> +if (!line.compare(8, len, devnames[i]) && 
>> isdigit(line[8+len])) {
>> +uevent_file.close();
>> +return i == 0;
>> +}
>> +}
>> +}
>> +
>> +uevent_file.close();
>> +
>> +fprintf(stderr, "unknown device name\n");
>> +exit(1);
>> +}
>> +
>>  int main(int argc, char **argv)
>>  {
>>  int i;
>> @@ -1310,7 +1364,7 @@ int main(int argc, char **argv)
>>  }
>>  
>>  verbose = options[OptVerbose];
>> -if (doioctl(fd, VIDIOC_QUERYCAP, &vcap)) {
>> +if (!is_subdevice(fd) && doioctl(fd, VIDIOC_QUERYCAP, &vcap)) {
>>  fprintf(stderr, "%s: not a v4l2 node\n", device);
>>  exit(1);
>>  }
>> -- 
>> 2.7.4
>>
>

Re: [PATCH 1/2] v4l-utils: do not query capabilities of sub-devices.

Hi Hans,

On Fri, Oct 20, 2017 at 01:56:48PM +0200, Hans Verkuil wrote:
> On 19/10/17 16:53, Sakari Ailus wrote:
> > Hi Harald and Hans,
> > 
> > On Thu, Oct 19, 2017 at 03:09:15PM +0200, Harald Dankworth wrote:
> >> Find the major and minor numbers of the device. Check if the
> >> file /dev/dev/char/major:minor/uevent contains "DEVNAME=v4l-subdev".

/sys/dev/...

> >> If so, the device is a sub-device.
> >>
> >> Signed-off-by: Harald Dankworth 
> >> Reviewed-by: Hans Verkuil 
> > 
> > I wonder if this is the best way to obtain the information. I thought there
> > was an intent to add something to sysfs that wasn't based on device names.
> > This also hardcodes the sysfs path.
> 
> This is what we discussed on irc some time ago. And if /sys is mounted 
> somewhere
> else, then you have bigger problems :-)

I remember the discussion but my recollection of the conclusion is slightly
different. :-)

Besides, sysfs could be still mounted elsewhere.

> 
> The device name in /sys comes from the driver and isn't changed by udev rules.
> So we can use it to determine if it is a subdev or not.
> 
> > Would udev provide anything useful in this respect?
> 
> Not all embedded systems use udev. I'd rather not depend on it, at least not 
> for
> this utility.
> 
> The alternative to this is to add a QUERYCAP-like ioctl for subdevs, but my
> proposal for that has been repeatedly shot down.

Here's a new argument for that: in order to make sub-devices proper V4L2
devices there should be QUERYCAP support. It'd be the same IOCTL and the
same argument struct.

> 
> In the meantime we need *something* so you can use v4l2-ctl to query/get/set
> controls and the EDID for HDMI receivers (Tim Harvey needs this).
> 
> I would like to merge this soon. It can always be changed if we switch to 
> another
> better method.

I agree, this won't break anything and can be improved later on without
affecting anything else.

Acked-by: Sakari Ailus 

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

Re: Enabling peer to peer device transactions for PCIe devices

2017-10-20 Thread Ludwig Petrosyan


Dear Linux kernel group

my name is Ludwig Petrosyan I am working in DESY (Germany)

we are responsible for the control system of  all accelerators in DESY.

For a 7-8 years we have switched to MTCA.4 systems and using PCIe as a 
central Bus.


I am mostly responsible for the Linux drivers of the AMC Cards (PCIe 
endpoints).


The idea is start to use peer to peer transaction for PCIe endpoint (DMA 
and/or usual Read/Write)


Could You please advise me where to start, is there some Documentation 
how to do it.



with best regards


Ludwig


On 11/21/2016 09:36 PM, Deucher, Alexander wrote:

This is certainly not the first time this has been brought up, but I'd like to 
try and get some consensus on the best way to move this forward.  Allowing 
devices to talk directly improves performance and reduces latency by avoiding 
the use of staging buffers in system memory.  Also in cases where both devices 
are behind a switch, it avoids the CPU entirely.  Most current APIs (DirectGMA, 
PeerDirect, CUDA, HSA) that deal with this are pointer based.  Ideally we'd be 
able to take a CPU virtual address and be able to get to a physical address 
taking into account IOMMUs, etc.  Having struct pages for the memory would 
allow it to work more generally and wouldn't require as much explicit support 
in drivers that wanted to use it.
  
Some use cases:

1. Storage devices streaming directly to GPU device memory
2. GPU device memory to GPU device memory streaming
3. DVB/V4L/SDI devices streaming directly to GPU device memory
4. DVB/V4L/SDI devices streaming directly to storage devices
  
Here is a relatively simple example of how this could work for testing.  This is obviously not a complete solution.

- Device memory will be registered with Linux memory sub-system by created 
corresponding struct page structures for device memory
- get_user_pages_fast() will  return corresponding struct pages when CPU 
address points to the device memory
- put_page() will deal with struct pages for device memory
  
Previously proposed solutions and related proposals:

1.P2P DMA
DMA-API/PCI map_peer_resource support for peer-to-peer 
(http://www.spinics.net/lists/linux-pci/msg44560.html)
Pros: Low impact, already largely reviewed.
Cons: requires explicit support in all drivers that want to support it, doesn't 
handle S/G in device memory.
  
2. ZONE_DEVICE IO

Direct I/O and DMA for persistent memory (https://lwn.net/Articles/672457/)
Add support for ZONE_DEVICE IO memory with struct pages. 
(https://patchwork.kernel.org/patch/8583221/)
Pro: Doesn't waste system memory for ZONE metadata
Cons: CPU access to ZONE metadata slow, may be lost, corrupted on device reset.
  
3. DMA-BUF

RDMA subsystem DMA-BUF support 
(http://www.spinics.net/lists/linux-rdma/msg38748.html)
Pros: uses existing dma-buf interface
Cons: dma-buf is handle based, requires explicit dma-buf support in drivers.

4. iopmem
iopmem : A block device for PCIe memory (https://lwn.net/Articles/703895/)
  
5. HMM

Heterogeneous Memory Management 
(http://lkml.iu.edu/hypermail/linux/kernel/1611.2/02473.html)

6. Some new mmap-like interface that takes a userptr and a length and returns a 
dma-buf and offset?
  
Alex


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

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

2017-10-20 Thread Tim Harvey

On Thu, Oct 19, 2017 at 12:39 AM, Hans Verkuil  wrote:

>>> What I am missing here is handling of the RGB quantization range.
>>> An HDMI receiver will typically send full range RGB or limited range YUV
>>> to the SoC. The HDMI source can however send full or limited range RGB
>>> or limited range YUV (full range YUV is theoretically possible, but nobody
>>> does that).
>>>
>>
>> isn't this quantization range a function of the colorspace and
>> colorimetry dictated by the AVI infoframe? I'm taking these into
>> consideration when setting up the conversion matrix in
>> tda1997x_configure_conv().
>
> No, it's independent of that.

and from another reply:
> A small correction here: while ideally you should indeed check if the current
> EDID supports selectable RGB Quantization Range, in practice you don't need
> to. If the source explicitly sets the RGB quantization range, then just use
> that.
>
> Note: some hardware can do this automatically (adv7604) by detecting what is
> transmitted in the AVI InfoFrame. That's probably not the case here since you
> have to provide a conversion matrix.

I see the AVI infoframe has hdmi_quantization_range and
hdmi_ycc_quantization_range along with vid_code.

I'm not at all clear what to do with this information. Is there
anything you see in the datasheet [1] that points to something I need
to be doing?

>
>>
>>> For a Full HD receiver the rules when receiving RGB video are as follows:
>>>
>>> If the EDID supports selectable RGB Quantization Range, then check if the
>>> source explicitly sets the RGB quantization range in the AVI InfoFrame and
>>> use that value.
>>>
>>> Otherwise fall back to the default rules:
>>>
>>> if VIC == 0, then expect full range RGB, otherwise expect limited range RGB.
>>
>> Are you referring to the video_code field of the AVI infoframe or vic
>> from a vendor infoframe?
>
> AVI InfoFrame.
>
> The HDMI VIC codes in the vendor InfoFrame are only valid for 4k formats. And
> that's not supported by this device, right?

Right, the TDA1997x supports 1080p only.

>
>>
>>>
>>> It gets even more complicated with 4k video, but this is full HD only.
>>>
>>> In addition, you may also want to implement the V4L2_CID_DV_RX_RGB_RANGE 
>>> control
>>> to let userspace override the autodetection.
>>
>> I'll add that as an additional patch. Are there other V4L2_CID's that
>> I should be adding here?
>
> V4L2_CID_DV_RX_POWER_PRESENT (if possible) and optionally 
> V4L2_CID_DV_RX_IT_CONTENT_TYPE.
>

It looks like there is a register for 5V_HPD detect.

I assume the content type to return is the value reported from the AVI frame?


>>
>> Regarding video standard detection where this chip provides me with
>> vertical-period, horizontal-period, and horizontal-pulse-width I
>> should be able to detect the standard simply based off of
>> vertical-period (framerate) and horizontal-period (line width
>> including blanking) right? I wasn't sure if my method of matching
>> these within 14% tolerance made sense. I will be removing the hsmatch
>> logic from that as it seems the horizontal-pulse-width should be
>> irrelevant.
>
> For proper video detection you ideally need:
>
> h/v sync size
> h/v back/front porch size
> h/v polarity
> pixelclock (usually an approximation)
>
> The v4l2_find_dv_timings_cap() helper can help you find the corresponding
> timings, allowing for pixelclock variation.
>
> That function assumes that the sync/back/frontporch values are all known.
> But not all devices can actually discover those values. What can your
> hardware detect? Can it tell front and backporch apart? Can it determine
> the sync size?
>
> I've been considering for some time to improve that helper function to be
> able to handle hardware that isn't able separate sync/back/frontporch values.
>

The TDA1997x provides only the vertical/horizontal periods and the
horizontal pulse
width (section 8.3.4 of datasheet [1]).

Can you point me to a good primer on the relationship between these
values and the h/v back/front porch?

Currently I iterate over the list of known formats calculating hper
(bt->pixelclock / V4L2_DV_BT_FRAME_WIDTH(bt)) and vper (hper /
V4L2_DV_BT_FRAME_HEIGHT(bt)) (framerate) and find the closest match
within +/- 7% tolerance. The list of supported formats is sorted by
framerate then width.

/* look for matching timings */
for (i = 0; i < ARRAY_SIZE(tda1997x_hdmi_modes); i++) {
const struct tda1997x_video_std *std = &tda1997x_hdmi_modes[i];
const struct v4l2_bt_timings *bt = &std->timings.bt;
int _hper, _vper, _hsper;
int vmin, vmax, hmin, hmax, hsmin, hsmax;
int vmatch, hsmatch;

width = V4L2_DV_BT_FRAME_WIDTH(bt);
lines = V4L2_DV_BT_FRAME_HEIGHT(bt);

_hper = (int)bt->pixelclock / (int)width;
_vper = _hper / lines;
_hsper = (int)bt->pixelclock / (int)bt->hsync;
if (bt->interlace

Re: [PATCH] media: s5p-mfc: Add support for V4L2_MEMORY_DMABUF type

2017-10-20 Thread Tobias Jakobi

Hey Marek and others,

just wanted to point out that I've also played around with Seung-Woo' patch for
a while. However this patch alone is very much incomplete.

In particular this is missing:
- At least v5 MFC hw needs source buffers to be also writable, so dma mapping
needs to be setup bidirectional.
- Like with mmap, all buffers need to be setup before decoding can begin. This
is due to how MFC hw gets initialized. dmabufs that are added later are not
going to be used before MFC hw isn't reinitialized.
- Removing dmabufs, or replacing them seems to be impossible with the current
code architecture.

I had extended samsung-utils with some C++ app to test stuff when I was looking
into this. You can find the code here:
https://github.com/tobiasjakobi/samsung-utils/tree/devel/v4l2-mfc-drm-direct

Now here is what happens. I allocate N buffer objects in DRM land to be used as
destination for the MFC decoder. The BOs are exported, so that I can then use
them in V4L2 space. I have to queue n (with n < N) buffers before I can start
the MFC engine.

If I do start the engine at that point (n buffers queued), I soon get an IOMMU
pagefault. I need to queue all N buffers before anything works at all. Queueing
a buffer the first time also registers it, and this has to happen before the MFC
hw is initialized.

In particular I can't just allocate more buffers from DRM and use them here
_after_ decoding has started.

To me it looks like the MFC code was never written with dmabuf in mind. It's
centered around a static memory setup that is fixed before decoding begins.

Anyway, just my 2 cents :)

- Tobias


Marek Szyprowski wrote:
> From: Seung-Woo Kim 
> 
> There is memory constraint for the buffers in V5 of the MFC hardware, but
> when IOMMU is used, then this constraint is meaningless. Other version of
> the MFC hardware don't have such limitations. So in such cases the driver
> is able to use buffers placed anywhere in the system memory, thus USERPTR
> and DMABUF operation modes can be also enabled.
> 
> This patch also removes USERPTR operation mode from encoder node, as it
> doesn't work with v5 MFC hardware without IOMMU being enabled.
> 
> Signed-off-by: Seung-Woo Kim 
> [mszyprow: adapted to v4.14 code base and updated commit message]
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc.c | 14 --
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 73 
> 
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 24 ++---
>  3 files changed, 89 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index cf68aed59e0d..f975523dc040 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -754,6 +754,7 @@ static int s5p_mfc_open(struct file *file)
>   struct s5p_mfc_dev *dev = video_drvdata(file);
>   struct s5p_mfc_ctx *ctx = NULL;
>   struct vb2_queue *q;
> + unsigned int io_modes;
>   int ret = 0;
>  
>   mfc_debug_enter();
> @@ -839,16 +840,21 @@ static int s5p_mfc_open(struct file *file)
>   if (ret)
>   goto err_init_hw;
>   }
> +
> + io_modes = VB2_MMAP;
> + if (exynos_is_iommu_available(&dev->plat_dev->dev) || !IS_TWOPORT(dev))
> + io_modes |= VB2_USERPTR | VB2_DMABUF;
> +
>   /* Init videobuf2 queue for CAPTURE */
>   q = &ctx->vq_dst;
>   q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
>   q->drv_priv = &ctx->fh;
>   q->lock = &dev->mfc_mutex;
>   if (vdev == dev->vfd_dec) {
> - q->io_modes = VB2_MMAP;
> + q->io_modes = io_modes;
>   q->ops = get_dec_queue_ops();
>   } else if (vdev == dev->vfd_enc) {
> - q->io_modes = VB2_MMAP | VB2_USERPTR;
> + q->io_modes = io_modes;
>   q->ops = get_enc_queue_ops();
>   } else {
>   ret = -ENOENT;
> @@ -872,10 +878,10 @@ static int s5p_mfc_open(struct file *file)
>   q->drv_priv = &ctx->fh;
>   q->lock = &dev->mfc_mutex;
>   if (vdev == dev->vfd_dec) {
> - q->io_modes = VB2_MMAP;
> + q->io_modes = io_modes;
>   q->ops = get_dec_queue_ops();
>   } else if (vdev == dev->vfd_enc) {
> - q->io_modes = VB2_MMAP | VB2_USERPTR;
> + q->io_modes = io_modes;
>   q->ops = get_enc_queue_ops();
>   } else {
>   ret = -ENOENT;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 8937b0af7cb3..efe65fce4880 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -546,14 +546,27 @@ static int reqbufs_capture(struct s5p_mfc_dev *dev, 
> struct s5p_mfc_ctx *ctx,
>   goto out;
>   }
>  
> - WARN_ON(ctx->dst_bufs_cnt != ctx->total_dpb_cou

RE: [PATCH v3 08/12] intel-ipu3: params: compute and program ccs

2017-10-20 Thread Zhi, Yong

Hi, Sakari,

> -Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
> Sent: Friday, October 20, 2017 2:58 AM
> To: Zhi, Yong 
> Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian
> Xu ; Mani, Rajmohan
> ; Yang, Hyungwoo
> ; Hu, Jerry W 
> Subject: Re: [PATCH v3 08/12] intel-ipu3: params: compute and program ccs
> 
> Hi Yong,
> 
> On Tue, Jul 18, 2017 at 10:13:40PM -0500, Yong Zhi wrote:
> > A collection of routines that are mainly responsible to calculate the
> > acc parameters.
> >
> > Signed-off-by: Yong Zhi 
> > ---
> >  drivers/media/pci/intel/ipu3/ipu3-css-params.c | 3114
> >   drivers/media/pci/intel/ipu3/ipu3-css-
> params.h |  105 +
> >  drivers/media/pci/intel/ipu3/ipu3-css.h|   92 +
> >  3 files changed, 3311 insertions(+)
> >  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-params.c
> >  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-params.h
> >
> > diff --git a/drivers/media/pci/intel/ipu3/ipu3-css-params.c
> > b/drivers/media/pci/intel/ipu3/ipu3-css-params.c
> > new file mode 100644
> > index 000..4b600bc
> > --- /dev/null
> > +++ b/drivers/media/pci/intel/ipu3/ipu3-css-params.c
> > @@ -0,0 +1,3114 @@
> > +/*
> > + * Copyright (c) 2017 Intel Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > +version
> > + * 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include "ipu3-abi.h"
> > +#include "ipu3-css.h"
> > +#include "ipu3-css-fw.h"
> > +#include "ipu3-css-params.h"
> > +#include "ipu3-tables.h"
> > +
> > +static unsigned int ipu3_css_scaler_get_exp(unsigned int counter,
> > +   unsigned int divider)
> > +{
> > +   int i = fls(divider) - fls(counter);
> > +
> > +   if (i <= 0)
> > +   return 0;
> > +
> > +   if (divider >> i < counter)
> > +   i = i - 1;
> 
> i--;
> 
> > +
> > +   return i;
> > +}
> > +
> > +/* Set up the CSS scaler look up table */ static void
> > +ipu3_css_scaler_setup_lut(unsigned int taps,
> > + unsigned int input_width,
> > + unsigned int output_width,
> > + int phase_step_correction,
> > + const int *coeffs,
> > + unsigned int coeffs_size,
> > + s8 coeff_lut[IMGU_SCALER_PHASES *
> > +
> IMGU_SCALER_FILTER_TAPS],
> > + struct ipu3_css_scaler_info *info) {
> > +   int tap;
> > +   int phase;
> > +   int exponent = ipu3_css_scaler_get_exp(output_width, input_width);
> > +   int mantissa = (1 << exponent) * output_width;
> > +   unsigned int phase_step = 0;
> > +   int phase_sum_left = 0;
> > +   int phase_sum_right = 0;
> > +
> > +   for (phase = 0; phase < IMGU_SCALER_PHASES; phase++) {
> > +   for (tap = 0; tap < taps; tap++) {
> > +   /* flip table to for convolution reverse indexing */
> > +   s64 coeff =  coeffs[coeffs_size -
> > +   ((tap * (coeffs_size / taps)) +
> > +   phase) - 1];
> > +   coeff *= mantissa;
> > +   coeff /= input_width;
> 
> Please use do_div() so this will compile on 32-bit machines.
> 

Thanks, above was implemented in v4.

> > +
> > +   /* Add +"0.5" */
> > +   coeff += 1 << (IMGU_SCALER_COEFF_BITS - 1);
> > +   coeff >>= IMGU_SCALER_COEFF_BITS;
> > +
> > +   coeff_lut[phase * IMGU_SCALER_FILTER_TAPS + tap]
> =
> > +   coeff;
> > +   }
> > +   }
> > +
> > +   phase_step = IMGU_SCALER_PHASES *
> > +   (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF)
> > +   * output_width / input_width;
> > +   phase_step += phase_step_correction;
> > +   phase_sum_left = (taps / 2 * IMGU_SCALER_PHASES *
> > +   (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF))
> > +   - (1 << (IMGU_SCALER_PHASE_COUNTER_PREC_REF -
> 1));
> > +   phase_sum_right = (taps / 2 * IMGU_SCALER_PHASES *
> > +   (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF))
> > +   + (1 << (IMGU_SCALER_PHASE_COUNTER_PREC_REF -
> 1));
> > +
> > +   info->exp_shift = IMGU_SCALER_MAX_EXPONENT_SHIFT - exponent;
> > +   info->pad_left = (phase_sum_left % phase_step == 0) ?
> > +   phase_sum_left / phase_step - 1 : phase_sum_left /
> phase_step;
> > +   info->pad_right = (pha

Re: [PATCH v3 08/12] intel-ipu3: params: compute and program ccs

On Fri, Oct 20, 2017 at 02:51:07PM +, Zhi, Yong wrote:
> > > + /* flip table to for convolution reverse indexing */
> > > + s64 coeff =  coeffs[coeffs_size -
> > > + ((tap * (coeffs_size / taps)) +
> > > + phase) - 1];
> > > + coeff *= mantissa;
> > > + coeff /= input_width;
> > 
> > Please use do_div() so this will compile on 32-bit machines.
> > 
> 
> Thanks, above was implemented in v4.

Yeah, I noticed that later. I accidentally reviewed an older version. ;)

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

Re: Enabling peer to peer device transactions for PCIe devices

2017-10-20 Thread Logan Gunthorpe


Hi Ludwig,

P2P transactions are still *very* experimental at the moment and take a 
lot of expertise to get working in a general setup. It will definitely 
require changes to the kernel, including the drivers of all the devices 
you are trying to make talk to eachother. If you're up for it you can 
take a look at:


https://github.com/sbates130272/linux-p2pmem/

Which has our current rough work making NVMe fabrics use p2p transactions.

Logan

On 10/20/2017 6:36 AM, Ludwig Petrosyan wrote:

Dear Linux kernel group

my name is Ludwig Petrosyan I am working in DESY (Germany)

we are responsible for the control system of  all accelerators in DESY.

For a 7-8 years we have switched to MTCA.4 systems and using PCIe as a 
central Bus.


I am mostly responsible for the Linux drivers of the AMC Cards (PCIe 
endpoints).


The idea is start to use peer to peer transaction for PCIe endpoint (DMA 
and/or usual Read/Write)


Could You please advise me where to start, is there some Documentation 
how to do it.



with best regards


Ludwig


On 11/21/2016 09:36 PM, Deucher, Alexander wrote:
This is certainly not the first time this has been brought up, but I'd 
like to try and get some consensus on the best way to move this 
forward.  Allowing devices to talk directly improves performance and 
reduces latency by avoiding the use of staging buffers in system 
memory.  Also in cases where both devices are behind a switch, it 
avoids the CPU entirely.  Most current APIs (DirectGMA, PeerDirect, 
CUDA, HSA) that deal with this are pointer based.  Ideally we'd be 
able to take a CPU virtual address and be able to get to a physical 
address taking into account IOMMUs, etc.  Having struct pages for the 
memory would allow it to work more generally and wouldn't require as 
much explicit support in drivers that wanted to use it.

Some use cases:
1. Storage devices streaming directly to GPU device memory
2. GPU device memory to GPU device memory streaming
3. DVB/V4L/SDI devices streaming directly to GPU device memory
4. DVB/V4L/SDI devices streaming directly to storage devices
Here is a relatively simple example of how this could work for 
testing.  This is obviously not a complete solution.
- Device memory will be registered with Linux memory sub-system by 
created corresponding struct page structures for device memory
- get_user_pages_fast() will  return corresponding struct pages when 
CPU address points to the device memory

- put_page() will deal with struct pages for device memory
Previously proposed solutions and related proposals:
1.P2P DMA
DMA-API/PCI map_peer_resource support for peer-to-peer 
(http://www.spinics.net/lists/linux-pci/msg44560.html)

Pros: Low impact, already largely reviewed.
Cons: requires explicit support in all drivers that want to support 
it, doesn't handle S/G in device memory.

2. ZONE_DEVICE IO
Direct I/O and DMA for persistent memory 
(https://lwn.net/Articles/672457/)
Add support for ZONE_DEVICE IO memory with struct pages. 
(https://patchwork.kernel.org/patch/8583221/)

Pro: Doesn't waste system memory for ZONE metadata
Cons: CPU access to ZONE metadata slow, may be lost, corrupted on 
device reset.

3. DMA-BUF
RDMA subsystem DMA-BUF support 
(http://www.spinics.net/lists/linux-rdma/msg38748.html)

Pros: uses existing dma-buf interface
Cons: dma-buf is handle based, requires explicit dma-buf support in 
drivers.


4. iopmem
iopmem : A block device for PCIe memory 
(https://lwn.net/Articles/703895/)

5. HMM
Heterogeneous Memory Management 
(http://lkml.iu.edu/hypermail/linux/kernel/1611.2/02473.html)


6. Some new mmap-like interface that takes a userptr and a length and 
returns a dma-buf and offset?

Alex

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


___
Linux-nvdimm mailing list
linux-nvd...@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

On 20/10/17 16:00, Tim Harvey wrote:
> On Thu, Oct 19, 2017 at 12:39 AM, Hans Verkuil  wrote:
> 
 What I am missing here is handling of the RGB quantization range.
 An HDMI receiver will typically send full range RGB or limited range YUV
 to the SoC. The HDMI source can however send full or limited range RGB
 or limited range YUV (full range YUV is theoretically possible, but nobody
 does that).

>>>
>>> isn't this quantization range a function of the colorspace and
>>> colorimetry dictated by the AVI infoframe? I'm taking these into
>>> consideration when setting up the conversion matrix in
>>> tda1997x_configure_conv().
>>
>> No, it's independent of that.
> 
> and from another reply:
>> A small correction here: while ideally you should indeed check if the current
>> EDID supports selectable RGB Quantization Range, in practice you don't need
>> to. If the source explicitly sets the RGB quantization range, then just use
>> that.
>>
>> Note: some hardware can do this automatically (adv7604) by detecting what is
>> transmitted in the AVI InfoFrame. That's probably not the case here since you
>> have to provide a conversion matrix.
> 
> I see the AVI infoframe has hdmi_quantization_range and
> hdmi_ycc_quantization_range along with vid_code.
> 
> I'm not at all clear what to do with this information. Is there
> anything you see in the datasheet [1] that points to something I need
> to be doing?

You can ignore hdmi_ycc_quantization_range, it is the hdmi_quantization_range
that you need to read out.

The TDA can receive the following formats:

RGB Full Range
RGB Limited Range
YUV Bt.601 (aka SMPTE 170M)
YUV Rec.709

The YUV formats are always limited range.

The TDA can transmit RGB and YUV to the SoC. You want RGB to be full range and
YUV to be limited range. YUV can be either 601 or 709.

So if the TDA transmits RGB then you need to support the following conversions:

RGB Full -> RGB Full
RGB Limited -> RGB Full
YUV 601 -> RGB Full
YUV 709 -> RGB Full

And if the TDA transmits YUV then you need these conversions:

RGB Full -> YUV601 or YUV709
RGB Limited -> YUV601 or YUV709
YUV601 -> YUV601
YUV709 -> YUV709

For the RGB to YUV conversion you have a choice of converting to YUV601 or 709.
I recommend to either always convert to YUV601 or to let it depend on the 
resolution
(SDTV YUV601, HDTV YUV709).

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

> 
>>
>>>
 For a Full HD receiver the rules when receiving RGB video are as follows:

 If the EDID supports selectable RGB Quantization Range, then check if the
 source explicitly sets the RGB quantization range in the AVI InfoFrame and
 use that value.

 Otherwise fall back to the default rules:

 if VIC == 0, then expect full range RGB, otherwise expect limited range 
 RGB.
>>>
>>> Are you referring to the video_code field of the AVI infoframe or vic
>>> from a vendor infoframe?
>>
>> AVI InfoFrame.
>>
>> The HDMI VIC codes in the vendor InfoFrame are only valid for 4k formats. And
>> that's not supported by this device, right?
> 
> Right, the TDA1997x supports 1080p only.
> 
>>
>>>

 It gets even more complicated with 4k video, but this is full HD only.

 In addition, you may also want to implement the V4L2_CID_DV_RX_RGB_RANGE 
 control
 to let userspace override the autodetection.
>>>
>>> I'll add that as an additional patch. Are there other V4L2_CID's that
>>> I should be adding here?
>>
>> V4L2_CID_DV_RX_POWER_PRESENT (if possible) and optionally 
>> V4L2_CID_DV_RX_IT_CONTENT_TYPE.
>>
> 
> It looks like there is a register for 5V_HPD detect.
> 
> I assume the content type to return is the value reported from the AVI frame?

Correct.

> 
> 
>>>
>>> Regarding video standard detection where this chip provides me with
>>> vertical-period, horizontal-period, and horizontal-pulse-width I
>>> should be able to detect the standard simply based off of
>>> vertical-period (framerate) and horizontal-period (line width
>>> including blanking) right? I wasn't sure if my method of matching
>>> these within 14% tolerance made sense. I will be removing the hsmatch
>>> logic from that as it seems the horizontal-pulse-width should be
>>> irrelevant.
>>
>> For proper video detection you ideally need:
>>
>> h/v sync size
>> h/v back/front porch size
>> h/v polarity
>> pixelclock (usually an approximation)
>>
>> The v4l2_find_dv_timings_cap() helper can help you find the corresponding
>> timings, allowing for pixelclock variation.
>>
>> That function assumes that the sync/back/frontporch values are all known.
>> But not all devices can actually discover those values. What can your
>> hardware detect? Can it tell front and backporch apart? Can it determine
>> the sync size?
>>
>> I've been considering for some time to improve that helper function to be
>> able to handle hardware that isn't able separate sync/back/frontporch values.
>>
> 
> The T

Re: [PATCH] pinctrl: rockchip: Add iomux-route switching support for rk3288

2017-10-20 Thread Heiko Stübner

Am Freitag, 20. Oktober 2017, 09:44:55 CEST schrieb Hans Verkuil:
> On 20/10/17 09:38, Heiko Stübner wrote:
> > Hi Hans,
> > 
> > Am Freitag, 20. Oktober 2017, 09:28:58 CEST schrieb Hans Verkuil:
> >> On 14/10/17 17:39, Heiko Stuebner wrote:
> >>> So far only the hdmi cec supports using one of two different pins
> >>> as source, so add the route switching for it.
> >>> 
> >>> Signed-off-by: Heiko Stuebner 
> >> 
> >> Just tested this on my firefly reload and it works great!
> >> 
> >> Tested-by: Hans Verkuil 
> > 
> > oh cool. I really only wrote this based on the soc manual,
> > so it actually surprises me, that it works on the first try :-)
> 
> One note though: I've only tested it on my Firefly Reload. I don't have a
> regular Firefly, so I can't be certain it works there. Just covering my ass
> here :-)

Haha ... I guess the only thing I could have messed up would be the
ordering (valu0 -> gpio0, value1 -> gpio7 ... and reverse), so if it were
really wrong, you shouldn've have seen any results at all.

[PATCH v2] drm: bridge: synopsys/dw-hdmi: Enable cec clock

2017-10-20 Thread Pierre-Hugues Husson

The documentation already mentions "cec" optional clock, but
currently the driver doesn't enable it.

Changes:
v2:
- Separate ENOENT errors from others
- Propagate other errors (especially -EPROBE_DEFER)

Signed-off-by: Pierre-Hugues Husson 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..b31fc95d5fef 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -138,6 +138,7 @@ struct dw_hdmi {
struct device *dev;
struct clk *isfr_clk;
struct clk *iahb_clk;
+   struct clk *cec_clk;
struct dw_hdmi_i2c *i2c;
 
struct hdmi_data_info hdmi_data;
@@ -2382,6 +2383,27 @@ __dw_hdmi_probe(struct platform_device *pdev,
goto err_isfr;
}
 
+   hdmi->cec_clk = devm_clk_get(hdmi->dev, "cec");
+   if (PTR_ERR(hdmi->cec_clk) == -ENOENT) {
+   hdmi->cec_clk = NULL;
+   } else if (IS_ERR(hdmi->cec_clk)) {
+   ret = PTR_ERR(hdmi->cec_clk);
+   if (ret != -EPROBE_DEFER) {
+   dev_err(hdmi->dev, "Cannot get HDMI cec clock: %d\n",
+   ret);
+   }
+
+   hdmi->cec_clk = NULL;
+   goto err_iahb;
+   } else {
+   ret = clk_prepare_enable(hdmi->cec_clk);
+   if (ret) {
+   dev_err(hdmi->dev, "Cannot enable HDMI cec clock: %d\n",
+   ret);
+   goto err_iahb;
+   }
+   }
+
/* Product and revision IDs */
hdmi->version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
  | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
@@ -2518,6 +2540,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
cec_notifier_put(hdmi->cec_notifier);
 
clk_disable_unprepare(hdmi->iahb_clk);
+   if (hdmi->cec_clk)
+   clk_disable_unprepare(hdmi->cec_clk);
 err_isfr:
clk_disable_unprepare(hdmi->isfr_clk);
 err_res:
@@ -2541,6 +2565,8 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
 
clk_disable_unprepare(hdmi->iahb_clk);
clk_disable_unprepare(hdmi->isfr_clk);
+   if (hdmi->cec_clk)
+   clk_disable_unprepare(hdmi->cec_clk);
 
if (hdmi->i2c)
i2c_del_adapter(&hdmi->i2c->adap);
-- 
2.14.1

Re: [PATCH 1/3] drm: bridge: synopsys/dw-hdmi: Enable cec clock

2017-10-20 Thread Pierre-Hugues Husson

2017-10-20 10:12 GMT+02:00 Russell King - ARM Linux :
> On Sat, Oct 14, 2017 at 12:53:35AM +0200, Pierre-Hugues Husson wrote:
>> @@ -2382,6 +2383,18 @@ __dw_hdmi_probe(struct platform_device *pdev,
>>   goto err_isfr;
>>   }
>>
>> + hdmi->cec_clk = devm_clk_get(hdmi->dev, "cec");
>> + if (IS_ERR(hdmi->cec_clk)) {
>> + hdmi->cec_clk = NULL;
>
> What if devm_clk_get() returns EPROBE_DEFER?  Does that really mean the
> clock does not exist?
Should be fixed in v2.
Thanks

[RFC v4 05/17] [media] v4l: add V4L2_EVENT_OUT_FENCE event

From: Gustavo Padovan 

Add a new event the userspace can subscribe to receive notifications
of the out_fence_fd when a buffer is queued onto the driver.
The event provides the index of the queued buffer and the out_fence_fd.

v3: - Rename event to V4L2_EVENT_OUT_FENCE

v2: - Add missing Documentation (Mauro)

Signed-off-by: Gustavo Padovan 
---
 Documentation/media/uapi/v4l/vidioc-dqevent.rst | 23 +++
 Documentation/media/videodev2.h.rst.exceptions  |  1 +
 include/uapi/linux/videodev2.h  | 12 
 3 files changed, 36 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
index cb3565f36793..2143df63aeb1 100644
--- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
+++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
@@ -79,6 +79,10 @@ call.
   - ``src_change``
   - Event data for event V4L2_EVENT_SOURCE_CHANGE.
 * -
+  - struct :c:type:`v4l2_event_buf_queued`
+  - ``buf_queued``
+  - Event data for event V4L2_EVENT_OUT_FENCE.
+* -
   - __u8
   - ``data``\ [64]
   - Event data. Defined by the event type. The union should be used to
@@ -338,6 +342,25 @@ call.
each cell in the motion detection grid, then that all cells are
automatically assigned to the default region 0.
 
+.. c:type:: v4l2_event_out_fence
+
+.. flat-table:: struct v4l2_event_out_fence
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u32
+  - ``index``
+  - The index of the buffer that was queued to the driver.
+* - __s32
+  - ``out_fence_fd``
+  - The out-fence file descriptor of the buffer that was queued to
+   the driver. It will signal when the buffer is ready, or if an
+   error happens.
+
+
+
+.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
 
 .. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index a5cb0a8686ac..32f3d5b37e3a 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -462,6 +462,7 @@ replace define V4L2_EVENT_CTRL event-type
 replace define V4L2_EVENT_FRAME_SYNC event-type
 replace define V4L2_EVENT_SOURCE_CHANGE event-type
 replace define V4L2_EVENT_MOTION_DET event-type
+replace define V4L2_EVENT_OUT_FENCE event-type
 replace define V4L2_EVENT_PRIVATE_START event-type
 
 replace define V4L2_EVENT_CTRL_CH_VALUE ctrl-changes-flags
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 185d6a0acc06..2a432e8c18e3 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2156,6 +2156,7 @@ struct v4l2_streamparm {
 #define V4L2_EVENT_FRAME_SYNC  4
 #define V4L2_EVENT_SOURCE_CHANGE   5
 #define V4L2_EVENT_MOTION_DET  6
+#define V4L2_EVENT_OUT_FENCE   7
 #define V4L2_EVENT_PRIVATE_START   0x0800
 
 /* Payload for V4L2_EVENT_VSYNC */
@@ -2208,6 +2209,16 @@ struct v4l2_event_motion_det {
__u32 region_mask;
 };
 
+/**
+ * struct v4l2_event_out_fence - out fence fd event
+ * @index: index of the buffer queued in the driver
+ * @out_fence_fd:  out-fence fd of the buffer queued
+ */
+struct v4l2_event_out_fence {
+   __u32 index;
+   __s32 out_fence_fd;
+};
+
 struct v4l2_event {
__u32   type;
union {
@@ -2216,6 +2227,7 @@ struct v4l2_event {
struct v4l2_event_frame_syncframe_sync;
struct v4l2_event_src_changesrc_change;
struct v4l2_event_motion_detmotion_det;
+   struct v4l2_event_out_fence out_fence;
__u8data[64];
} u;
__u32   pending;
-- 
2.13.6

[RFC v4 13/17] [media] vb2: add in-fence support to QBUF

From: Gustavo Padovan 

Receive in-fence from userspace and add support for waiting on them
before queueing the buffer to the driver. Buffers are only queued
to the driver once they are ready. A buffer is ready when its
in-fence signals.

For queues that require vb2 to queue buffers to the v4l2 driver in same
order they are received from userspace we use fence_array to keep that
ordering. Basically we create a fence_array that contains both the current
fence and the fence from the previous buffer (which might be a fence array
as well). The base fence class for the fence_array becomes the new buffer
fence, waiting on that one guarantees that it won't be queued out of
order.

v5: - use fence_array to keep buffers ordered in vb2 core when
needed (Brian Stark)
- keep backward compatibility on the reserved2 field (Brian Stark)
- protect fence callback removal with lock (Brian Stark)

v4:
- Add a comment about dma_fence_add_callback() not returning a
error (Hans)
- Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
- select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
- Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
- Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
-  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
vb2_start_streaming() (Hans)
- set IN_FENCE flags on __fill_v4l2_buffer (Hans)
- Queue buffers to the driver as soon as they are ready (Hans)
- call fill_user_buffer() after queuing the buffer (Hans)
- add err: label to clean up fence
- add dma_fence_wait() before calling vb2_start_streaming()

v3: - document fence parameter
- remove ternary if at vb2_qbuf() return (Mauro)
- do not change if conditions behaviour (Mauro)

v2:
- fix vb2_queue_or_prepare_buf() ret check
- remove check for VB2_MEMORY_DMABUF only (Javier)
- check num of ready buffers to start streaming
- when queueing, start from the first ready buffer
- handle queue cancel

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/Kconfig  |   1 +
 drivers/media/v4l2-core/videobuf2-core.c | 179 ---
 drivers/media/v4l2-core/videobuf2-v4l2.c |  29 -
 include/media/videobuf2-core.h   |  17 ++-
 4 files changed, 208 insertions(+), 18 deletions(-)

diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index a35c33686abf..3f988c407c80 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -83,6 +83,7 @@ config VIDEOBUF_DVB
 # Used by drivers that need Videobuf2 modules
 config VIDEOBUF2_CORE
select DMA_SHARED_BUFFER
+   select SYNC_FILE
tristate
 
 config VIDEOBUF2_MEMOPS
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 60f8b582396a..78f369dba3e3 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -346,6 +346,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
vb2_memory memory,
vb->index = q->num_buffers + buffer;
vb->type = q->type;
vb->memory = memory;
+   spin_lock_init(&vb->fence_cb_lock);
for (plane = 0; plane < num_planes; ++plane) {
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
@@ -1222,6 +1223,9 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
 
+   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
+   return;
+
vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(&q->owned_by_drv_count);
 
@@ -1273,6 +1277,20 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
return 0;
 }
 
+static int __get_num_ready_buffers(struct vb2_queue *q)
+{
+   struct vb2_buffer *vb;
+   int ready_count = 0;
+
+   /* count num of buffers ready in front of the queued_list */
+   list_for_each_entry(vb, &q->queued_list, queued_entry) {
+   if (!vb->in_fence || dma_fence_is_signaled(vb->in_fence))
+   ready_count++;
+   }
+
+   return ready_count;
+}
+
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
 {
struct vb2_buffer *vb;
@@ -1361,7 +1379,74 @@ static int vb2_start_streaming(struct vb2_queue *q)
return ret;
 }
 
-int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
+static struct dma_fence *__set_in_fence(struct vb2_queue *q,
+   struct vb2_buffer *vb,
+   struct dma_fence *fence)
+{
+   if (q->last_fence && dma_fence_is_signaled(q->last_fence)) {
+   dma_fence_put(q->last_fence);
+   q->last_fenc

[RFC v4 17/17] [media] v4l: Document explicit synchronization behaviour

From: Gustavo Padovan 

Add section to VIDIOC_QBUF about it

v3:
- make the out_fence refer to the current buffer (Hans)
- Note what happens when the IN_FENCE is not set (Hans)

v2:
- mention that fences are files (Hans)
- rework for the new API

Signed-off-by: Gustavo Padovan 
---
 Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 
 1 file changed, 31 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
index 9e448a4aa3aa..a65a50578bad 100644
--- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
+++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
@@ -118,6 +118,37 @@ immediately with an ``EAGAIN`` error code when no buffer 
is available.
 The struct :c:type:`v4l2_buffer` structure is specified in
 :ref:`buffer`.
 
+Explicit Synchronization
+
+
+Explicit Synchronization allows us to control the synchronization of
+shared buffers from userspace by passing fences to the kernel and/or
+receiving them from it. Fences passed to the kernel are named in-fences and
+the kernel should wait on them to signal before using the buffer, i.e., 
queueing
+it to the driver. On the other side, the kernel can create out-fences for the
+buffers it queues to the drivers. Out-fences signal when the driver is
+finished with buffer, i.e., the buffer is ready. The fences are represented
+as a file and passed as a file descriptor to userspace.
+
+The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` ioctl
+using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer
+flags and the `fence_fd` field. If an in-fence needs to be passed to the 
kernel,
+`fence_fd` should be set to the fence file descriptor number and the
+``V4L2_BUF_FLAG_IN_FENCE`` should be set as well Setting one but not the other
+will cause ``VIDIOC_QBUF`` to return with error.
+
+The fence_fd field (formely the reserved2 field) will be ignored if the
+``V4L2_BUF_FLAG_IN_FENCE`` is not set.
+
+To get an out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag should
+be set to ask for a fence to be attached to the buffer. To become aware of
+the out-fence created one should listen for the ``V4L2_EVENT_OUT_FENCE`` event.
+An event will be triggered for every buffer queued to the V4L2 driver with the
+``V4L2_BUF_FLAG_OUT_FENCE``.
+
+At streamoff the out-fences will either signal normally if the drivers waits
+for the operations on the buffers to finish or signal with error if the
+driver cancels the pending operations.
 
 Return Value
 
-- 
2.13.6

[RFC v4 16/17] [media] vb2: add out-fence support to QBUF

From: Gustavo Padovan 

If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence and send to userspace on the V4L2_EVENT_OUT_FENCE when
the buffer is queued to the driver, or right away if the queue is ordered
both in VB2 and in the driver.

The fence is signaled on buffer_done(), when the job on the buffer is
finished.

v5:
- delay fd_install to DQ_EVENT (Hans)
- if queue is fully ordered send OUT_FENCE event right away
(Brian)
- rename 'q->ordered' to 'q->ordered_in_driver'
- merge change to implement OUT_FENCE event here

v4:
- return the out_fence_fd in the BUF_QUEUED event(Hans)

v3: - add WARN_ON_ONCE(q->ordered) on requeueing (Hans)
- set the OUT_FENCE flag if there is a fence pending (Hans)
- call fd_install() after vb2_core_qbuf() (Hans)
- clean up fence if vb2_core_qbuf() fails (Hans)
- add list to store sync_file and fence for the next queued buffer

v2: check if the queue is ordered.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/v4l2-event.c |  2 ++
 drivers/media/v4l2-core/videobuf2-core.c | 25 +++
 drivers/media/v4l2-core/videobuf2-v4l2.c | 55 
 3 files changed, 82 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-event.c 
b/drivers/media/v4l2-core/v4l2-event.c
index 6274e3e174e0..275da224ace4 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -385,6 +385,8 @@ int v4l2_subscribe_event_v4l2(struct v4l2_fh *fh,
switch (sub->type) {
case V4L2_EVENT_CTRL:
return v4l2_ctrl_subscribe_event(fh, sub);
+   case V4L2_EVENT_OUT_FENCE:
+   return v4l2_event_subscribe(fh, sub, VIDEO_MAX_FRAME, NULL);
}
return -EINVAL;
 }
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index c7ba67bda5ac..21e2052776c1 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -354,6 +354,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
vb2_memory memory,
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
}
+   vb->out_fence_fd = -1;
q->bufs[vb->index] = vb;
 
/* Allocate video buffer memory for the MMAP type */
@@ -934,10 +935,24 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
case VB2_BUF_STATE_QUEUED:
return;
case VB2_BUF_STATE_REQUEUEING:
+   /*
+* Explicit synchronization requires ordered queues for now,
+* so WARN_ON if we are requeuing on an ordered queue.
+*/
+   if (vb->out_fence)
+   WARN_ON_ONCE(q->ordered_in_driver);
+
if (q->start_streaming_called)
__enqueue_in_driver(vb);
return;
default:
+   if (state == VB2_BUF_STATE_ERROR)
+   dma_fence_set_error(vb->out_fence, -ENOENT);
+   dma_fence_signal(vb->out_fence);
+   dma_fence_put(vb->out_fence);
+   vb->out_fence = NULL;
+   vb->out_fence_fd = -1;
+
/* Inform any processes that may be waiting for buffers */
wake_up(&q->done_wq);
break;
@@ -1235,6 +1250,9 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
trace_vb2_buf_queue(q, vb);
 
call_void_vb_qop(vb, buf_queue, vb);
+
+   if (!(q->is_output || q->ordered_in_vb2))
+   call_void_bufop(q, send_out_fence, vb);
 }
 
 static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
@@ -1451,6 +1469,7 @@ static struct dma_fence *__set_in_fence(struct vb2_queue 
*q,
}
 
q->last_fence = dma_fence_get(fence);
+   call_void_bufop(q, send_out_fence, vb);
}
 
return fence;
@@ -1840,6 +1859,11 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
}
 
/*
+* Renew out-fence context.
+*/
+   q->out_fence_context = dma_fence_context_alloc(1);
+
+   /*
 * Remove all buffers from videobuf's list...
 */
INIT_LIST_HEAD(&q->queued_list);
@@ -2171,6 +2195,7 @@ int vb2_core_queue_init(struct vb2_queue *q)
spin_lock_init(&q->done_lock);
mutex_init(&q->mmap_lock);
init_waitqueue_head(&q->done_wq);
+   q->out_fence_context = dma_fence_context_alloc(1);
 
if (q->buf_struct_size == 0)
q->buf_struct_size = sizeof(struct vb2_buffer);
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 4c09ea007d90..9fb01ddefdc9 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/vide

[RFC v4 15/17] [media] vb2: add infrastructure to support out-fences

From: Gustavo Padovan 

Add vb2_setup_out_fence() and the needed members to struct vb2_buffer.

v2: - change it to reflect fd_install at DQEVENT
- add fence context for out-fences

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/videobuf2-core.c | 31 +++
 include/media/videobuf2-core.h   | 20 
 2 files changed, 51 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 78f369dba3e3..c7ba67bda5ac 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -23,8 +23,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
+#include 
 #include 
 
 #include 
@@ -1316,6 +1319,34 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned 
int index, void *pb)
 }
 EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
 
+int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index)
+{
+   struct vb2_buffer *vb;
+   struct dma_fence *fence;
+
+   vb = q->bufs[index];
+
+   vb->out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
+
+   fence = vb2_fence_alloc(q->out_fence_context);
+   if (!fence) {
+   put_unused_fd(vb->out_fence_fd);
+   return -ENOMEM;
+   }
+
+   vb->sync_file = sync_file_create(fence);
+   if (!vb->sync_file) {
+   dma_fence_put(fence);
+   put_unused_fd(vb->out_fence_fd);
+   return -ENOMEM;
+   }
+
+   vb->out_fence = dma_fence_get(fence);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(vb2_setup_out_fence);
+
 /**
  * vb2_start_streaming() - Attempt to start streaming.
  * @q: videobuf2 queue
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 624ca2dce9ea..1925ede73804 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -259,6 +259,10 @@ struct vb2_buffer {
 *  using the buffer (queueing to the driver)
 * fence_cb:fence callback information
 * fence_cb_lock:   protect callback signal/remove
+* out_fence_fd:the out_fence_fd to be shared with userspace.
+* out_fence:   the out-fence associated with the buffer once
+*  it is queued to the driver.
+* sync_file:   the sync file to wrap the out fence
 */
enum vb2_buffer_state   state;
 
@@ -269,6 +273,10 @@ struct vb2_buffer {
struct dma_fence_cb fence_cb;
spinlock_t  fence_cb_lock;
 
+   int out_fence_fd;
+   struct dma_fence*out_fence;
+   struct sync_file*sync_file;
+
 #ifdef CONFIG_VIDEO_ADV_DEBUG
/*
 * Counters for how often these buffer-related ops are
@@ -518,6 +526,7 @@ struct vb2_buf_ops {
  * @ordered_in_vb2: set by the driver to tell vb2 te guarantee the order
  * of buffer queue from userspace with QBUF() until they are
  * queued to the driver.
+ * @out_fence_context: the fence context for the out fences
  * @last_fence:last in-fence received. Used to keep ordering.
  * @fileio:file io emulator internal data, used only if emulator is active
  * @threadio:  thread io internal data, used only if thread is active
@@ -574,6 +583,7 @@ struct vb2_queue {
unsigned intordered_in_driver:1;
unsigned intordered_in_vb2:1;
 
+   u64 out_fence_context;
struct dma_fence*last_fence;
 
struct vb2_fileio_data  *fileio;
@@ -745,6 +755,16 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
vb2_memory memory,
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb);
 
 /**
+ * vb2_setup_out_fence() - setup new out-fence
+ * @q: The vb2_queue where to setup it
+ * @index: index of the buffer
+ *
+ * Setup the file descriptor, the fence and the sync_file for the next
+ * buffer to be queued and add everything to the tail of the q->out_fence_list.
+ */
+int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index);
+
+/**
  * vb2_core_qbuf() - Queue a buffer from userspace
  *
  * @q: videobuf2 queue
-- 
2.13.6

[RFC v4 14/17] [media] vb2: add videobuf2 dma-buf fence helpers

From: Javier Martinez Canillas 

Add a videobuf2-fence.h header file that contains different helpers
for DMA buffer sharing explicit fence support in videobuf2.

v2: - use fence context provided by the caller in vb2_fence_alloc()

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Gustavo Padovan 
---
 include/media/videobuf2-fence.h | 48 +
 1 file changed, 48 insertions(+)
 create mode 100644 include/media/videobuf2-fence.h

diff --git a/include/media/videobuf2-fence.h b/include/media/videobuf2-fence.h
new file mode 100644
index ..b49cc1bf6bb4
--- /dev/null
+++ b/include/media/videobuf2-fence.h
@@ -0,0 +1,48 @@
+/*
+ * videobuf2-fence.h - DMA buffer sharing fence helpers for videobuf 2
+ *
+ * Copyright (C) 2016 Samsung Electronics
+ *
+ * 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.
+ */
+
+#include 
+#include 
+
+static DEFINE_SPINLOCK(vb2_fence_lock);
+
+static inline const char *vb2_fence_get_driver_name(struct dma_fence *fence)
+{
+   return "vb2_fence";
+}
+
+static inline const char *vb2_fence_get_timeline_name(struct dma_fence *fence)
+{
+   return "vb2_fence_timeline";
+}
+
+static inline bool vb2_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+static const struct dma_fence_ops vb2_fence_ops = {
+   .get_driver_name = vb2_fence_get_driver_name,
+   .get_timeline_name = vb2_fence_get_timeline_name,
+   .enable_signaling = vb2_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+};
+
+static inline struct dma_fence *vb2_fence_alloc(u64 context)
+{
+   struct dma_fence *vb2_fence = kzalloc(sizeof(*vb2_fence), GFP_KERNEL);
+
+   if (!vb2_fence)
+   return NULL;
+
+   dma_fence_init(vb2_fence, &vb2_fence_ops, &vb2_fence_lock, context, 1);
+
+   return vb2_fence;
+}
-- 
2.13.6

[RFC v4 12/17] [media] vb2: add explicit fence user API

From: Gustavo Padovan 

Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel and return an out-fence from the kernel to
userspace.

Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
when sending a fence to the kernel to be waited on, and
V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.

v3:
- make the out_fence refer to the current buffer (Hans)

v2: add documentation

Signed-off-by: Gustavo Padovan 
---
 Documentation/media/uapi/v4l/buffer.rst   | 15 +++
 drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
 drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
 include/uapi/linux/videodev2.h|  4 +++-
 5 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index ae6ee73f151c..99afc0837671 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -648,6 +648,21 @@ Buffer Flags
   - Start Of Exposure. The buffer timestamp has been taken when the
exposure of the frame has begun. This is only valid for the
``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
+* .. _`V4L2-BUF-FLAG-IN-FENCE`:
+
+  - ``V4L2_BUF_FLAG_IN_FENCE``
+  - 0x0020
+  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
+   won't be queued to the driver until the fence signals.
+
+* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
+
+  - ``V4L2_BUF_FLAG_OUT_FENCE``
+  - 0x0040
+  - Request a fence to be attached to the buffer. One should listen for
+   the ``V4L2_EVENT_OUT_FENCE`` event to receive the buffer ``index``
+   and the ``out_fence_fd`` attached to the buffer.  The event is
+   triggered at the moment the buffer is queued to the V4L2 driver.
 
 
 
diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
b/drivers/media/usb/cpia2/cpia2_v4l.c
index 4666a642b2f6..d9d6b6a31751 100644
--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, struct 
v4l2_buffer *buf)
buf->sequence = cam->buffers[buf->index].seq;
buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
buf->length = cam->frame_size;
-   buf->reserved2 = 0;
+   buf->fence_fd = -1;
buf->reserved = 0;
memset(&buf->timecode, 0, sizeof(buf->timecode));
 
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 821f2aa299ae..3a31d318df2a 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -370,7 +370,7 @@ struct v4l2_buffer32 {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   __s32   fence_fd;
__u32   reserved;
 };
 
@@ -533,7 +533,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, struct 
v4l2_buffer32 __user
put_user(kp->timestamp.tv_usec, &up->timestamp.tv_usec) ||
copy_to_user(&up->timecode, &kp->timecode, sizeof(struct 
v4l2_timecode)) ||
put_user(kp->sequence, &up->sequence) ||
-   put_user(kp->reserved2, &up->reserved2) ||
+   put_user(kp->fence_fd, &up->fence_fd) ||
put_user(kp->reserved, &up->reserved) ||
put_user(kp->length, &up->length))
return -EFAULT;
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 0c0669976bdc..110fb45fef6f 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
b->timestamp = ns_to_timeval(vb->timestamp);
b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
-   b->reserved2 = 0;
+   b->fence_fd = -1;
b->reserved = 0;
 
if (q->is_multiplanar) {
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2a432e8c18e3..8975fec4ab68 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -924,7 +924,7 @@ struct v4l2_buffer {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   __s32   fence_fd;
__u32   reserved;
 };
 
@@ -961,6 +961,8 @@ struct v4l2_buffer {
 #define V4L2_BUF_FLAG_TSTAMP_SRC_SOE   0x0001
 /* mem2mem encoder/decoder */
 #define V4L2_BUF_FLAG_LAST 0x0010
+#define V4L2_BUF_FLAG_IN_FENCE 0x0020
+#define V4L2_BUF_FLAG_OUT_FENCE0x0040
 
 /**
  * st

[RFC v4 11/17] [media] vb2: check earlier if stream can be started

From: Gustavo Padovan 

To support explicit synchronization we need to run all operations that can
fail before we queue the buffer to the driver. With fences the queueing
will be delayed if the fence is not signaled yet and it will be better if
such callback do not fail.

For that we move the vb2_start_streaming() before the queuing for the
buffer may happen.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/videobuf2-core.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index cb115ba6a1d2..60f8b582396a 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1399,29 +1399,27 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
trace_vb2_qbuf(q, vb);
 
/*
-* If already streaming, give the buffer to driver for processing.
-* If not, the buffer will be given to driver on next streamon.
-*/
-   if (q->start_streaming_called)
-   __enqueue_in_driver(vb);
-
-   /* Fill buffer information for the userspace */
-   if (pb)
-   call_void_bufop(q, fill_user_buffer, vb, pb);
-
-   /*
 * If streamon has been called, and we haven't yet called
 * start_streaming() since not enough buffers were queued, and
 * we now have reached the minimum number of queued buffers,
 * then we can finally call start_streaming().
+*
+* If already streaming, give the buffer to driver for processing.
+* If not, the buffer will be given to driver on next streamon.
 */
if (q->streaming && !q->start_streaming_called &&
q->queued_count >= q->min_buffers_needed) {
ret = vb2_start_streaming(q);
if (ret)
return ret;
+   } else if (q->start_streaming_called) {
+   __enqueue_in_driver(vb);
}
 
+   /* Fill buffer information for the userspace */
+   if (pb)
+   call_void_bufop(q, fill_user_buffer, vb, pb);
+
dprintk(2, "qbuf of buffer %d succeeded\n", vb->index);
return 0;
 }
-- 
2.13.6

[RFC v4 10/17] [media] vivid: mark vivid queues as ordered_in_driver

From: Gustavo Padovan 

To enable vivid to be used with explicit synchronization we need
to mark its queues as ordered. vivid queues are already ordered by
default so we no changes are needed.

v2: rename 'ordered' to 'ordered_in_driver' to avoid confusion.

Signed-off-by: Gustavo Padovan 
Acked-by: Hans Verkuil  (v1)
---
 drivers/media/platform/vivid/vivid-core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
index 608bcceed463..1f7702faea7d 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -1063,6 +1063,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->multiplanar ? V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE 
:
V4L2_BUF_TYPE_VIDEO_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered_in_driver = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = &vivid_vid_cap_qops;
@@ -1083,6 +1084,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->multiplanar ? V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE :
V4L2_BUF_TYPE_VIDEO_OUTPUT;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_WRITE;
+   q->ordered_in_driver = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = &vivid_vid_out_qops;
@@ -1103,6 +1105,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->has_raw_vbi_cap ? V4L2_BUF_TYPE_VBI_CAPTURE :
  V4L2_BUF_TYPE_SLICED_VBI_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered_in_driver = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = &vivid_vbi_cap_qops;
@@ -1123,6 +1126,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->has_raw_vbi_out ? V4L2_BUF_TYPE_VBI_OUTPUT :
  V4L2_BUF_TYPE_SLICED_VBI_OUTPUT;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_WRITE;
+   q->ordered_in_driver = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = &vivid_vbi_out_qops;
@@ -1142,6 +1146,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q = &dev->vb_sdr_cap_q;
q->type = V4L2_BUF_TYPE_SDR_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered_in_driver = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = &vivid_sdr_cap_qops;
-- 
2.13.6

[RFC v4 09/17] [media] vb2: add 'ordered_in_vb2' property to queues

From: Gustavo Padovan 

By setting this member on vb2_queue the driver tell vb2 core that
it requires the buffers queued in QBUF to be queued with same order to the
driver.

Signed-off-by: Gustavo Padovan 
---
 include/media/videobuf2-core.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 6dd3f0181107..fc333e10e7d8 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -505,6 +505,9 @@ struct vb2_buf_ops {
  * the same order they are dequeued from the driver. The default
  * is not ordered unless the driver sets this flag. As of now it
  * is mandatory for using explicit fences.
+ * @ordered_in_vb2: set by the driver to tell vb2 te guarantee the order
+ * of buffer queue from userspace with QBUF() until they are
+ * queued to the driver.
  * @fileio:file io emulator internal data, used only if emulator is active
  * @threadio:  thread io internal data, used only if thread is active
  */
@@ -558,6 +561,7 @@ struct vb2_queue {
unsigned intcopy_timestamp:1;
unsigned intlast_buffer_dequeued:1;
unsigned intordered_in_driver:1;
+   unsigned intordered_in_vb2:1;
 
struct vb2_fileio_data  *fileio;
struct vb2_threadio_data*threadio;
-- 
2.13.6

[RFC v4 08/17] [media] vb2: add 'ordered_in_driver' property to queues

From: Gustavo Padovan 

For explicit synchronization (and soon for HAL3/Request API) we need
the v4l2-driver to guarantee the ordering in which the buffers were queued
by userspace. This is already true for many drivers, but we never needed
to say it.

v2: rename property to 'ordered_in_driver' to avoid confusion

Signed-off-by: Gustavo Padovan 
---
 include/media/videobuf2-core.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 96af4eb49e52..6dd3f0181107 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -500,6 +500,11 @@ struct vb2_buf_ops {
  * @last_buffer_dequeued: used in poll() and DQBUF to immediately return if the
  * last decoded buffer was already dequeued. Set for capture queues
  * when a buffer with the V4L2_BUF_FLAG_LAST is dequeued.
+ * @ordered_in_driver: if the driver can guarantee that the queue will be
+ * ordered or not, i.e., the buffers are queued to the driver in
+ * the same order they are dequeued from the driver. The default
+ * is not ordered unless the driver sets this flag. As of now it
+ * is mandatory for using explicit fences.
  * @fileio:file io emulator internal data, used only if emulator is active
  * @threadio:  thread io internal data, used only if thread is active
  */
@@ -552,6 +557,7 @@ struct vb2_queue {
unsigned intis_output:1;
unsigned intcopy_timestamp:1;
unsigned intlast_buffer_dequeued:1;
+   unsigned intordered_in_driver:1;
 
struct vb2_fileio_data  *fileio;
struct vb2_threadio_data*threadio;
-- 
2.13.6

[RFC v4 03/17] [media] v4l: use v4l2_subscribe_event_v4l2() on drivers

From: Gustavo Padovan 

Driver that implement their own .vidioc_subscribe_event function should
be using v4l2_subscribe_event_v4l2() instead of
v4l2_ctrl_subscribe_event().

Signed-off-by: Gustavo Padovan 
---
 drivers/media/pci/cobalt/cobalt-v4l2.c | 2 +-
 drivers/media/pci/ivtv/ivtv-ioctl.c| 2 +-
 drivers/media/pci/tw5864/tw5864-video.c| 2 +-
 drivers/media/platform/coda/coda-common.c  | 2 +-
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 2 +-
 drivers/media/platform/qcom/venus/vdec.c   | 4 +---
 drivers/media/platform/rcar-vin/rcar-v4l2.c| 2 +-
 drivers/media/platform/vivid/vivid-vid-out.c   | 2 +-
 drivers/media/usb/go7007/go7007-v4l2.c | 2 +-
 drivers/media/usb/uvc/uvc_v4l2.c   | 2 +-
 10 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/media/pci/cobalt/cobalt-v4l2.c 
b/drivers/media/pci/cobalt/cobalt-v4l2.c
index def4a3b37084..7b79daa09416 100644
--- a/drivers/media/pci/cobalt/cobalt-v4l2.c
+++ b/drivers/media/pci/cobalt/cobalt-v4l2.c
@@ -1071,7 +1071,7 @@ static int cobalt_subscribe_event(struct v4l2_fh *fh,
case V4L2_EVENT_SOURCE_CHANGE:
return v4l2_event_subscribe(fh, sub, 4, NULL);
}
-   return v4l2_ctrl_subscribe_event(fh, sub);
+   return v4l2_subscribe_event_v4l2(fh, sub);
 }
 
 static int cobalt_g_parm(struct file *file, void *fh, struct v4l2_streamparm 
*a)
diff --git a/drivers/media/pci/ivtv/ivtv-ioctl.c 
b/drivers/media/pci/ivtv/ivtv-ioctl.c
index 670462d195b5..4d76a433fcf3 100644
--- a/drivers/media/pci/ivtv/ivtv-ioctl.c
+++ b/drivers/media/pci/ivtv/ivtv-ioctl.c
@@ -1507,7 +1507,7 @@ static int ivtv_subscribe_event(struct v4l2_fh *fh, const 
struct v4l2_event_subs
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 0, NULL);
default:
-   return v4l2_ctrl_subscribe_event(fh, sub);
+   return v4l2_subscribe_event_v4l2(fh, sub);
}
 }
 
diff --git a/drivers/media/pci/tw5864/tw5864-video.c 
b/drivers/media/pci/tw5864/tw5864-video.c
index e7bd2b8484e3..67fa883bed3c 100644
--- a/drivers/media/pci/tw5864/tw5864-video.c
+++ b/drivers/media/pci/tw5864/tw5864-video.c
@@ -671,7 +671,7 @@ static int tw5864_subscribe_event(struct v4l2_fh *fh,
 */
return v4l2_event_subscribe(fh, sub, 30, NULL);
default:
-   return v4l2_ctrl_subscribe_event(fh, sub);
+   return v4l2_subscribe_event_v4l2(fh, sub);
}
 }
 
diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 15eb5dc4dff9..897c6939ab0f 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1085,7 +1085,7 @@ static int coda_subscribe_event(struct v4l2_fh *fh,
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 0, NULL);
default:
-   return v4l2_ctrl_subscribe_event(fh, sub);
+   return v4l2_subscribe_event_v4l2(fh, sub);
}
 }
 
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 843510979ad8..a9f80db14b47 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -629,7 +629,7 @@ static int vidioc_vdec_subscribe_evt(struct v4l2_fh *fh,
case V4L2_EVENT_SOURCE_CHANGE:
return v4l2_src_change_event_subscribe(fh, sub);
default:
-   return v4l2_ctrl_subscribe_event(fh, sub);
+   return v4l2_subscribe_event_v4l2(fh, sub);
}
 }
 
diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index da611a5eb670..ccf9b778dcf9 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -459,10 +459,8 @@ static int vdec_subscribe_event(struct v4l2_fh *fh,
return v4l2_event_subscribe(fh, sub, 2, NULL);
case V4L2_EVENT_SOURCE_CHANGE:
return v4l2_src_change_event_subscribe(fh, sub);
-   case V4L2_EVENT_CTRL:
-   return v4l2_ctrl_subscribe_event(fh, sub);
default:
-   return -EINVAL;
+   return v4l2_subscribe_event_v4l2(fh, sub);
}
 }
 
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index dd37ea811680..153622e0d42f 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -542,7 +542,7 @@ static int rvin_subscribe_event(struct v4l2_fh *fh,
case V4L2_EVENT_SOURCE_CHANGE:
return v4l2_event_subscribe(fh, sub, 4, NULL);
}
-   return v4l2_ctrl_subscribe_event(fh, sub);
+   return v4l2_subscribe_event_v4l2(fh, sub);
 }
 
 static int rvin_enum_dv_timings(struct file *file, void *priv_fh,
diff -

[RFC v4 07/17] [media] vivid: assign the specific device to the vb2_queue->dev

From: Gustavo Padovan 

Instead of assigning the global v4l2 device, assign the specific device.
This was causing trouble when using V4L2 events with vivid devices.
The device's queue should be the same we opened in userspace.

This is needed for the upcoming V4L2_EVENT_OUT_FENCE support. The current
vivid code isn't wrong, it just needs to be changed so V4L2_EVENT_OUT_FENCE
can be supported. The change doesn't affect any other behaviour of vivid.

Signed-off-by: Gustavo Padovan 
Acked-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
index 5f316a5e38db..608bcceed463 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -1070,7 +1070,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = &dev->mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = &dev->vid_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1090,7 +1090,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = &dev->mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = &dev->vid_out_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1110,7 +1110,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = &dev->mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = &dev->vbi_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1130,7 +1130,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = &dev->mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = &dev->vbi_out_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1149,7 +1149,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 8;
q->lock = &dev->mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = &dev->sdr_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
-- 
2.13.6

[RFC v4 06/17] [media] vb2: add .send_out_fence() to notify userspace of out_fence_fd

From: Gustavo Padovan 

With the upcoming explicit synchronization support to V4L2 we need a
way to notify userspace of the out_fence_fd when buffers are queued to the
driver - buffers with in-fences attached to it can only be queued once the
fence signal, so the queueing to the driver might be deferred.

v2: rename to .send_out_fence()

Signed-off-by: Gustavo Padovan 
---
 include/media/videobuf2-core.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index ef9b64398c8c..96af4eb49e52 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -408,6 +408,7 @@ struct vb2_ops {
  * will return an error.
  * @copy_timestamp:copy the timestamp from a userspace structure to
  * the vb2_buffer struct.
+ * @send_out_fence:send an out_fence fd of the buffer queued to userspace.
  */
 struct vb2_buf_ops {
int (*verify_planes_array)(struct vb2_buffer *vb, const void *pb);
@@ -415,6 +416,7 @@ struct vb2_buf_ops {
int (*fill_vb2_buffer)(struct vb2_buffer *vb, const void *pb,
struct vb2_plane *planes);
void (*copy_timestamp)(struct vb2_buffer *vb, const void *pb);
+   void (*send_out_fence)(struct vb2_buffer *vb);
 };
 
 /**
-- 
2.13.6

[RFC v4 04/17] WIP: [media] v4l2: add v4l2_event_queue_fh_with_cb()

From: Gustavo Padovan 

For some type of events we may require the event user in the
kernel to run some operation when DQ_EVENT() is called.
V4L2_EVENT_OUT_FENCE is the first user of this mechanism as it needs
to call v4l2 core back to install a file descriptor.

This is WIP, I believe we are able to come up with better ways to do it,
but as that is not the main part of the patchset I'll keep it like
this for now.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/v4l2-event.c | 31 +++
 include/media/v4l2-event.h   |  7 +++
 2 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-event.c 
b/drivers/media/v4l2-core/v4l2-event.c
index 313ee9d1f9ee..6274e3e174e0 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -58,6 +58,9 @@ static int __v4l2_event_dequeue(struct v4l2_fh *fh, struct 
v4l2_event *event)
 
spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
 
+   if (kev->prepare)
+   kev->prepare(kev->data);
+
return 0;
 }
 
@@ -104,8 +107,11 @@ static struct v4l2_subscribed_event *v4l2_event_subscribed(
return NULL;
 }
 
-static void __v4l2_event_queue_fh(struct v4l2_fh *fh, const struct v4l2_event 
*ev,
-   const struct timespec *ts)
+static void __v4l2_event_queue_fh_with_cb(struct v4l2_fh *fh,
+ const struct v4l2_event *ev,
+ const struct timespec *ts,
+ void (*prepare)(void *data),
+ void *data)
 {
struct v4l2_subscribed_event *sev;
struct v4l2_kevent *kev;
@@ -155,6 +161,8 @@ static void __v4l2_event_queue_fh(struct v4l2_fh *fh, const 
struct v4l2_event *e
kev->event.id = ev->id;
kev->event.timestamp = *ts;
kev->event.sequence = fh->sequence;
+   kev->prepare = prepare;
+   kev->data = data;
sev->in_use++;
list_add_tail(&kev->list, &fh->available);
 
@@ -177,7 +185,7 @@ void v4l2_event_queue(struct video_device *vdev, const 
struct v4l2_event *ev)
spin_lock_irqsave(&vdev->fh_lock, flags);
 
list_for_each_entry(fh, &vdev->fh_list, list)
-   __v4l2_event_queue_fh(fh, ev, ×tamp);
+   __v4l2_event_queue_fh_with_cb(fh, ev, ×tamp, NULL, NULL);
 
spin_unlock_irqrestore(&vdev->fh_lock, flags);
 }
@@ -191,11 +199,26 @@ void v4l2_event_queue_fh(struct v4l2_fh *fh, const struct 
v4l2_event *ev)
ktime_get_ts(×tamp);
 
spin_lock_irqsave(&fh->vdev->fh_lock, flags);
-   __v4l2_event_queue_fh(fh, ev, ×tamp);
+   __v4l2_event_queue_fh_with_cb(fh, ev, ×tamp, NULL, NULL);
spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
 }
 EXPORT_SYMBOL_GPL(v4l2_event_queue_fh);
 
+void v4l2_event_queue_fh_with_cb(struct v4l2_fh *fh,
+const struct v4l2_event *ev,
+void (*prepare)(void *data), void *data)
+{
+   unsigned long flags;
+   struct timespec timestamp;
+
+   ktime_get_ts(×tamp);
+
+   spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+   __v4l2_event_queue_fh_with_cb(fh, ev, ×tamp, prepare, data);
+   spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_event_queue_fh_with_cb);
+
 int v4l2_event_pending(struct v4l2_fh *fh)
 {
return fh->navailable;
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 2b794f2ad824..dc770257811e 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -68,11 +68,14 @@ struct video_device;
  * @list:  List node for the v4l2_fh->available list.
  * @sev:   Pointer to parent v4l2_subscribed_event.
  * @event: The event itself.
+ * @prepare:   Callback to prepare the event only at DQ_EVENT() time.
  */
 struct v4l2_kevent {
struct list_headlist;
struct v4l2_subscribed_event *sev;
struct v4l2_event   event;
+   void (*prepare)(void *data);
+   void *data;
 };
 
 /**
@@ -160,6 +163,10 @@ void v4l2_event_queue(struct video_device *vdev, const 
struct v4l2_event *ev);
  */
 void v4l2_event_queue_fh(struct v4l2_fh *fh, const struct v4l2_event *ev);
 
+void v4l2_event_queue_fh_with_cb(struct v4l2_fh *fh,
+const struct v4l2_event *ev,
+void (*prepare)(void *data), void *data);
+
 /**
  * v4l2_event_pending - Check if an event is available
  *
-- 
2.13.6

[RFC v4 01/17] [media] v4l: create v4l2_event_subscribe_v4l2()

From: Gustavo Padovan 

We need a common function to subscribe all the common events in drivers,
so far we had only V4L2_EVENT_CTRL, so such a function wasn't necessary,
but we are about to introduce a new event for the upcoming explicit fences
implementation, thus a common place is needed.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/v4l2-event.c | 12 
 include/media/v4l2-event.h   |  8 
 2 files changed, 20 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-event.c 
b/drivers/media/v4l2-core/v4l2-event.c
index 968c2eb08b5a..313ee9d1f9ee 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -354,3 +355,14 @@ int v4l2_src_change_event_subdev_subscribe(struct 
v4l2_subdev *sd,
return v4l2_src_change_event_subscribe(fh, sub);
 }
 EXPORT_SYMBOL_GPL(v4l2_src_change_event_subdev_subscribe);
+
+int v4l2_subscribe_event_v4l2(struct v4l2_fh *fh,
+ const struct v4l2_event_subscription *sub)
+{
+   switch (sub->type) {
+   case V4L2_EVENT_CTRL:
+   return v4l2_ctrl_subscribe_event(fh, sub);
+   }
+   return -EINVAL;
+}
+EXPORT_SYMBOL(v4l2_subscribe_event_v4l2);
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 6741910c3a18..2b794f2ad824 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -236,4 +236,12 @@ int v4l2_src_change_event_subscribe(struct v4l2_fh *fh,
 int v4l2_src_change_event_subdev_subscribe(struct v4l2_subdev *sd,
   struct v4l2_fh *fh,
   struct v4l2_event_subscription *sub);
+/**
+ * v4l2_subscribe_event_v4l2 - helper function that subscribe all v4l2 events
+ *
+ * @fh: pointer to struct v4l2_fh
+ * @sub: pointer to &struct v4l2_event_subscription
+ */
+int v4l2_subscribe_event_v4l2(struct v4l2_fh *fh,
+ const struct v4l2_event_subscription *sub);
 #endif /* V4L2_EVENT_H */
-- 
2.13.6

[RFC v4 02/17] [media] v4l: use v4l2_subscribe_event_v4l2() on vtables

From: Gustavo Padovan 

In all places that we were calling v4l2_ctrl_subscribe event() we now call
v4l2_subscribe_event_v4l2() that embed v4l2_ctrl_subscribe event() and can
be expanded to support more events.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/common/saa7146/saa7146_video.c  | 4 ++--
 drivers/media/dvb-frontends/rtl2832_sdr.c | 2 +-
 drivers/media/pci/bt8xx/bttv-driver.c | 4 ++--
 drivers/media/pci/cx18/cx18-ioctl.c   | 2 +-
 drivers/media/pci/cx23885/cx23885-video.c | 2 +-
 drivers/media/pci/cx25821/cx25821-video.c | 2 +-
 drivers/media/pci/cx88/cx88-blackbird.c   | 2 +-
 drivers/media/pci/cx88/cx88-video.c   | 4 ++--
 drivers/media/pci/meye/meye.c | 2 +-
 drivers/media/pci/saa7134/saa7134-empress.c   | 2 +-
 drivers/media/pci/saa7134/saa7134-video.c | 4 ++--
 drivers/media/pci/saa7164/saa7164-encoder.c   | 2 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2.c| 2 +-
 drivers/media/pci/sta2x11/sta2x11_vip.c   | 2 +-
 drivers/media/pci/tw68/tw68-video.c   | 2 +-
 drivers/media/pci/tw686x/tw686x-video.c   | 2 +-
 drivers/media/pci/zoran/zoran_driver.c| 2 +-
 drivers/media/platform/am437x/am437x-vpfe.c   | 2 +-
 drivers/media/platform/atmel/atmel-isc.c  | 2 +-
 drivers/media/platform/atmel/atmel-isi.c  | 2 +-
 drivers/media/platform/fsl-viu.c  | 2 +-
 drivers/media/platform/marvell-ccic/mcam-core.c   | 2 +-
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c  | 2 +-
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c| 2 +-
 drivers/media/platform/pxa_camera.c   | 2 +-
 drivers/media/platform/qcom/venus/venc.c  | 2 +-
 drivers/media/platform/rcar_drif.c| 2 +-
 drivers/media/platform/rcar_fdp1.c| 2 +-
 drivers/media/platform/rcar_jpu.c | 2 +-
 drivers/media/platform/s3c-camif/camif-capture.c  | 2 +-
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 2 +-
 drivers/media/platform/sti/hva/hva-v4l2.c | 2 +-
 drivers/media/platform/stm32/stm32-dcmi.c | 2 +-
 drivers/media/platform/ti-vpe/cal.c   | 2 +-
 drivers/media/platform/ti-vpe/vpe.c   | 2 +-
 drivers/media/platform/vim2m.c| 2 +-
 drivers/media/radio/dsbr100.c | 2 +-
 drivers/media/radio/radio-cadet.c | 2 +-
 drivers/media/radio/radio-isa.c   | 2 +-
 drivers/media/radio/radio-keene.c | 2 +-
 drivers/media/radio/radio-ma901.c | 2 +-
 drivers/media/radio/radio-miropcm20.c | 2 +-
 drivers/media/radio/radio-mr800.c | 2 +-
 drivers/media/radio/radio-sf16fmi.c   | 2 +-
 drivers/media/radio/radio-si476x.c| 2 +-
 drivers/media/radio/radio-tea5764.c   | 2 +-
 drivers/media/radio/radio-tea5777.c   | 2 +-
 drivers/media/radio/radio-timb.c  | 2 +-
 drivers/media/radio/si470x/radio-si470x-common.c  | 2 +-
 drivers/media/radio/si4713/radio-platform-si4713.c| 2 +-
 drivers/media/radio/si4713/radio-usb-si4713.c | 2 +-
 drivers/media/radio/tea575x.c | 2 +-
 drivers/media/usb/airspy/airspy.c | 2 +-
 drivers/media/usb/au0828/au0828-video.c   | 2 +-
 drivers/media/usb/cpia2/cpia2_v4l.c   | 2 +-
 drivers/media/usb/cx231xx/cx231xx-417.c   | 2 +-
 drivers/media/usb/cx231xx/cx231xx-video.c | 4 ++--
 drivers/media/usb/em28xx/em28xx-video.c   | 4 ++--
 drivers/media/usb/gspca/gspca.c   | 2 +-
 drivers/media/usb/hackrf/hackrf.c | 2 +-
 drivers/media/usb/hdpvr/hdpvr-video.c | 2 +-
 drivers/media/usb/msi2500/msi2500.c   | 2 +-
 drivers/media/usb/pwc/pwc-v4l.c   | 2 +-
 drivers/media/usb/s2255/s2255drv.c| 2 +-
 drivers/media/usb/stk1160/stk1160-v4l.c   | 2 +-
 drivers/media/usb/stkwebcam/stk-webcam.c  | 2 +-
 drivers/media/usb/tm6000/tm6000-video.c   | 4 ++--
 drivers/media/usb/usbvision/usbvision-video.c

[RFC v4 00/17] V4L2 Explicit Synchronization support

From: Gustavo Padovan 

Hi,

I renamed this back to RFC as many things are still under
discussion/open but it integrates all comments received on the
previous round[1].

My main goal now is to fit as many use cases as possible into this
Explicit Synchronization implementation, but first I'd like to recap
some detail of the implementation, as some pieces changed since the last
patchset, that means the explanation on previous cover letters aren't
entirely valid anymore.

Explicit Synchronization allows us to control the synchronization of
shared buffers from userspace by passing fences to the kernel and/or
receiving them from it. Fences passed to the kernel are named in-fences
and the kernel should wait them to signal before using the buffer, i.e.,
queueing it to the driver. On the other side, the kernel can create
out-fences for the buffers it queues to the drivers, out-fences signal
when the driver is finished with buffer, that is, the buffer is ready.

Before we talk about more details, lets differentiate ordering concepts,
there is two orthogonal places in the pipeline where buffers may or may
not be ordered. Inside the drivers and inside vb2 core:

* Ordering in the driver: In this RFC to use out-fences v4l2 drivers
  need to guarantee ordering of the buffers inside the driver, that is,
  buffers should become done (think calling vb2_buffer_done() here) in
  the same order they are queued to the driver. Drivers should set
  q->ordered_in_driver to 1 if they can keep ordering. (See patch 08/17)

* Ordering in vb2: Some queues (OUTPUT queues and some m2m devices)
  requires that the order we queue buffers to the driver do not change
  in relation to the order they were queued from userspace. So that is
  marked in the code by q->is_output or q->ordered_in_vb2 and this
  implementation can work with both ordered and not-ordered queues at the
  vb2 level. (See patch 09/17)

The in-fences are communicated at the VIDIOC_QBUF ioctl using the
V4L2_BUF_FLAG_IN_FENCE buffer flag and the fence_fd field. If an
in-fence needs to be passed to the kernel, fence_fd should be set to the
fence file descriptor number and the V4L2_BUF_FLAG_IN_FENCE should be
set as well. If ordered in vb2 needs to be kept we use fence arrays (see
patch 12 and 13)

Out-fence for a given buffer is enabled if the V4L2_BUF_FLAG_OUT_FENCE
flag is passed in the QBUF() call and then communicated to userspace via
the newly created V4L2_EVENT_OUT_FENCE event. The event is queued for
userspace pick up when the buffer is queued to the driver, or if the
queue is ordered both in the driver and vb2 we send the event right
away. (see patch 14 to 16)

Use cases
-

I believe use cases like camera app preview, photoshoot, video record,
m2m color converters and scalers (with ordered queues) and output
devices are covered by this RFC, but others like synchronized
Audio/Video transmission doesn't seem to benefit too much from fences.
Talking to Nicolas he expressed that fences are not really useful for
such cases because we still need to sync with the Audio side, so may
be we need wait at least for a start of streaming signal or something
like that.  For m2m encoders, we would be in a similar situation
needing to know bytesused beforehand. I want to hear what others think
here.

WIP on V4L2 event
-

As the V4L2 event part is not the crucial part here, the current
changes there to allow install the fence_fd at DQ_EVENT() are to
be considered PoC. Suggestions are welcome. (See patch 4)

Main Changes on v4
---

* Keep ordering in vb2 of buffers queued from userspace with
  in-fence attached. This is necessary for OUTPUT and some m2m
  queues.

* V4L2_EVENT_BUF_QUEUED event was renamed to
  V4L2_EVENT_OUT_FENCE and is only sent when an out-fence
  exists.

* For queues that are both ordered in vb2 and in driver the
  OUT_FENCE event is sent out immediately without waiting for
  the buffer to be queued on the driver

* The out-fence FD is only installed at DQ_EVENT(), but this
  implementation needs improvement. See 'Open Questions'

* Refactor slightly event subscription for v4l2 driver, now
  there is a v4l2_event_subscribe_v4l2() that will subscribe for
  event that all devices need.

* Protect dma_fence_remove_callback() with the fence lock.

Only the most important changes are detailed here, for a full
list of them, see each individual patch.

Open Questions
--

* synchronized Audio/Video transmission and m2m encoders use
  cases discussed above

* V4L2 event: Improve solution to install the fd and figure how
  to clean up a event if userspace don't pick it up.

Test tool
-

Test tool I've been using can be found at:
https://git.collabora.com/cgit/user/padovan/v4l2-test.git/

Regards,

Gustavo

--
[1] https://lkml.org/lkml/2017/9/7/489

Gustavo Padovan (16):
  [media] v4l: create v4l2_event_subscribe_v4l2()
  [media] v4l: use v4l2_subscribe_event_v4l2() on vtables
  [media] v4l: use v4l2_subscribe_eve

cron job: media_tree daily build: WARNINGS