RE: [PATCH 2/4] media: max2175: don't clear V4L2_SUBDEV_FL_IS_I2C
Hi Mita-san, Thank you for fixing this. > Subject: [PATCH 2/4] media: max2175: don't clear V4L2_SUBDEV_FL_IS_I2C > > The v4l2_i2c_subdev_init() sets V4L2_SUBDEV_FL_IS_I2C flag in the > subdev->flags. But this driver overwrites subdev->flags immediately > subdev->after > calling v4l2_i2c_subdev_init(). So V4L2_SUBDEV_FL_IS_I2C is not set after > all. > > This stops breaking subdev->flags and preserves V4L2_SUBDEV_FL_IS_I2C. > > Side note: According to the comment in v4l2_device_unregister(), this is > problematic only if the device is platform bus device. Device tree or > ACPI based devices are not affected. > > Cc: Ramesh Shanmugasundaram > Cc: Mauro Carvalho Chehab > Signed-off-by: Akinobu Mita Acked-by: Ramesh Shanmugasundaram Thanks, Ramesh > --- > drivers/media/i2c/max2175.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/i2c/max2175.c b/drivers/media/i2c/max2175.c > index bf0e821..2f1966b 100644 > --- a/drivers/media/i2c/max2175.c > +++ b/drivers/media/i2c/max2175.c > @@ -1345,7 +1345,7 @@ static int max2175_probe(struct i2c_client *client, > v4l2_i2c_subdev_init(sd, client, &max2175_ops); > ctx->client = client; > > - sd->flags = V4L2_SUBDEV_FL_HAS_DEVNODE; > + sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; > > /* Controls */ > hdl = &ctx->ctrl_hdl; > -- > 2.7.4
[PATCH 0/2] media: usb: remove duplicate & operation
usb_endpoint_maxp() has an inline keyword and searches for bits[10:0] by & operation with 0x7ff. So, we can remove the duplicate & operation with 0x7ff. Jaejoong Kim (2): media: usb: uvc: remove duplicate & operation media: usb: usbtv: remove duplicate & operation drivers/media/usb/usbtv/usbtv-core.c | 2 +- drivers/media/usb/uvc/uvc_video.c| 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) -- 2.7.4
[PATCH 1/2] media: usb: uvc: remove duplicate & operation
usb_endpoint_maxp() has an inline keyword and searches for bits[10:0] by & operation with 0x7ff. So, we can remove the duplicate & operation with 0x7ff. Signed-off-by: Jaejoong Kim --- drivers/media/usb/uvc/uvc_video.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c index fb86d6a..f4ace63 100644 --- a/drivers/media/usb/uvc/uvc_video.c +++ b/drivers/media/usb/uvc/uvc_video.c @@ -1469,13 +1469,13 @@ static unsigned int uvc_endpoint_max_bpi(struct usb_device *dev, case USB_SPEED_HIGH: psize = usb_endpoint_maxp(&ep->desc); mult = usb_endpoint_maxp_mult(&ep->desc); - return (psize & 0x07ff) * mult; + return psize * mult; case USB_SPEED_WIRELESS: psize = usb_endpoint_maxp(&ep->desc); return psize; default: psize = usb_endpoint_maxp(&ep->desc); - return psize & 0x07ff; + return psize; } } -- 2.7.4
[PATCH 2/2] media: usb: usbtv: remove duplicate & operation
usb_endpoint_maxp() has an inline keyword and searches for bits[10:0] by & operation with 0x7ff. So, we can remove the duplicate & operation with 0x7ff. Signed-off-by: Jaejoong Kim --- drivers/media/usb/usbtv/usbtv-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/usbtv/usbtv-core.c b/drivers/media/usb/usbtv/usbtv-core.c index ceb953b..a95a468 100644 --- a/drivers/media/usb/usbtv/usbtv-core.c +++ b/drivers/media/usb/usbtv/usbtv-core.c @@ -84,7 +84,7 @@ static int usbtv_probe(struct usb_interface *intf, /* Packet size is split into 11 bits of base size and count of * extra multiplies of it.*/ size = usb_endpoint_maxp(&ep->desc); - size = (size & 0x07ff) * usb_endpoint_maxp_mult(&ep->desc); + size = size * usb_endpoint_maxp_mult(&ep->desc); /* Device structure */ usbtv = kzalloc(sizeof(struct usbtv), GFP_KERNEL); -- 2.7.4
Re: [PATCH] pinctrl: rockchip: Add iomux-route switching support for rk3288
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
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
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
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
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
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
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
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
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
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
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
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 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
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Oct 21 05:00:16 CEST 2017 media-tree git hash:61065fc3e32002ba48aa6bc3816c1f6f9f8daf55 media_build git hash: c93534951f5d66bef7f17f16293acf2be346b726 v4l-utils git hash: 482c52f946af4c6b16efa63a35790d92fb65326c gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.12.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: WARNINGS linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: WARNINGS linux-3.12.67-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9.26-i686: OK linux-4.10.14-i686: OK linux-4.11-i686: OK linux-4.12.1-i686: OK linux-4.13-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12.67-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: WARNINGS linux-4.9.26-x86_64: WARNINGS linux-4.10.14-x86_64: WARNINGS linux-4.11-x86_64: WARNINGS linux-4.12.1-x86_64: WARNINGS linux-4.13-x86_64: OK apps: OK spec-git: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html