Re: noveau vs arm dma ops

(While there's a rain shower...) On Thu, Apr 26, 2018 at 02:09:42AM -0700, Christoph Hellwig wrote: > synopsis: > > drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c:pdevinfo.dma_mask > = DMA_BIT_MASK(32); > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c: pdevinfo.dma_mask =

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote: > On arm that doesn't work. The iommu api seems like a good fit, except > the dma-api tends to get in the way a bit (drm/msm apparently has > similar problems like tegra), and if you need contiguous memory > dma_alloc_coherent is the

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: > > - dma api hides the cache flushing requirements from us. GPUs love > > non-snooped access, and worse give userspace control over that. We want > > a strict

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote: > [discussion about this patch, which should have been cced to the iommu > and linux-arm-kernel lists, but wasn't: > https://www.spinics.net/lists/dri-devel/msg173630.html] > > On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry

Re: [PATCH v3 0/7] TDA998x CEC support

On Tue, Apr 24, 2018 at 11:29:42AM +0200, Hans Verkuil wrote: > On 04/09/18 14:15, Russell King - ARM Linux wrote: > > Hi, > > > > This patch series adds CEC support to the DRM TDA998x driver. The > > TDA998x family of devices integrate a TDA9950 CEC at a separate I2

Re: [PATCH v3 5/7] drm/i2c: tda9950: add CEC driver

On Fri, Apr 20, 2018 at 05:48:12PM +0200, Hans Verkuil wrote: > On 04/20/2018 05:31 PM, Russell King - ARM Linux wrote: > > Hi Hans, > > > > Any comments? > > I have been traveling and haven't had time to look at this. Next week will > be busy as well, b

Re: [PATCH v3 5/7] drm/i2c: tda9950: add CEC driver

Hi Hans, Any comments? Thanks. On Mon, Apr 09, 2018 at 01:16:32PM +0100, Russell King wrote: > Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device, > but is also integrated into HDMI transceivers such as the TDA9989 and > TDA19989. > > The TDA9950 contains a command

[PATCH v3 0/7] TDA998x CEC support

Hi, This patch series adds CEC support to the DRM TDA998x driver. The TDA998x family of devices integrate a TDA9950 CEC at a separate I2C address from the HDMI encoder. Implementation of the CEC part is separate to allow independent CEC implementations, or independent HDMI implementations

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

Do you think that the appropriate patches could be copied to the appropriate people please? On Thu, Jan 11, 2018 at 04:46:24PM -0800, Dan Williams wrote: > Changes since v1 [1]: > * fixup the ifence definition to use alternative_2 per recent AMD > changes in tip/x86/pti (Tom) > > * drop

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)) { > +

Re: [PATCH][MEDIA]i.MX6 CSI: Fix MIPI camera operation in RAW/Bayer mode

On Tue, Oct 17, 2017 at 03:26:19PM +0200, Krzysztof Hałasa wrote: > Fabio Estevam writes: > > >> --- a/drivers/staging/media/imx/imx-media-csi.c > >> +++ b/drivers/staging/media/imx/imx-media-csi.c > >> @@ -340,7 +340,7 @@ static int csi_idmac_setup_channel(struct csi_priv >

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

On Thu, Oct 12, 2017 at 12:06:33AM +0100, Russell King - ARM Linux wrote: > Now, if you mean "known" to be equivalent with "recognised by > imx-media" then, as I've pointed out several times already, that > statement is FALSE. I'm not sure how many times I'm going

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

On Wed, Oct 11, 2017 at 03:14:26PM -0700, Steve Longerbeam wrote: > > > On 10/11/2017 02:49 PM, Russell King - ARM Linux wrote: > >On Tue, Oct 03, 2017 at 12:09:13PM -0700, Steve Longerbeam wrote: > >>imx_media_link_notify() should not return error if the source subdevi

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

On Tue, Oct 03, 2017 at 12:09:13PM -0700, Steve Longerbeam wrote: > imx_media_link_notify() should not return error if the source subdevice > is not recognized by imx-media, that isn't an error. If the subdev has > controls they will be inherited starting from a known subdev. What does "a known

Re: [PATCH RFC] media: staging/imx: fix complete handler

On Mon, Oct 02, 2017 at 05:59:30PM -0700, Steve Longerbeam wrote: > > > On 10/01/2017 04:36 PM, Russell King - ARM Linux wrote: > >On Sun, Oct 01, 2017 at 01:16:53PM -0700, Steve Longerbeam wrote: > >>Right, imx_media_add_vdev_to_pa() has followed a link to an > >

Re: [PATCH 1/1] v4l: async: Fix notifier complete callback error handling

On Mon, Oct 02, 2017 at 02:28:46PM +0300, Sakari Ailus wrote: > On Mon, Oct 02, 2017 at 01:59:54PM +0300, Sakari Ailus wrote: > > The notifier complete callback may return an error. This error code was > > simply returned to the caller but never handled properly. > > > > Move calling the complete

Re: [PATCH RFC] media: staging/imx: fix complete handler

On Sun, Oct 01, 2017 at 01:16:53PM -0700, Steve Longerbeam wrote: > Right, imx_media_add_vdev_to_pa() has followed a link to an > entity that imx is not aware of. > > The only effect of this patch (besides allowing the driver to load > with smiapp cameras), is that no controls from the unknown

Re: [PATCH v3 0/2] [media] videobuf2-dc: Add support for cacheable MMAP

On Thu, Jul 13, 2017 at 01:13:28PM +0200, Marek Szyprowski wrote: > Hi Christoph, > > On 2017-07-05 19:33, Christoph Hellwig wrote: > >On Mon, Jul 03, 2017 at 11:27:32AM +0200, Marek Szyprowski wrote: > >>The main question here if we want to merge incomplete solution or not. As > >>for now, there

Re: [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2)

On Wed, Apr 26, 2017 at 06:43:54PM +0300, Ivaylo Dimitrov wrote: > >+static int get_luminosity_bayer10(uint16_t *buf, const struct v4l2_format > >*fmt) > >+{ > >+long long avg_lum = 0; > >+int x, y; > >+ > >+buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 + > >+

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

On Sun, Apr 16, 2017 at 07:10:21PM -0600, Shuah Khan wrote: > On 04/14/2017 03:46 AM, Russell King - ARM Linux wrote: > > On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote: > >>>> This would be however quite large task, especially taking into account > &g

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote: > >>This would be however quite large task, especially taking into account > >>all current users of DMA-buf framework... > >Yeah it will be a large task. > > Maybe once scatterlist are switched to pfns, changing dmabuf internal >

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, Apr 06, 2017 at 05:01:52PM +0200, Philipp Zabel wrote: > On Thu, 2017-04-06 at 15:05 +0100, Russell King - ARM Linux wrote: > > On Thu, Apr 06, 2017 at 03:55:29PM +0200, Philipp Zabel wrote: > > > + > > > + /* Retain current field setting as default */ > &g

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, Apr 06, 2017 at 04:20:21PM +0200, Hans Verkuil wrote: > On 04/06/2017 03:55 PM, Philipp Zabel wrote: > > If the the field order is set to ANY in set_fmt, choose the currently > > set field order. If the colorspace is set to DEFAULT, choose the current > > colorspace. If any of xfer_func,

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, Apr 06, 2017 at 03:55:29PM +0200, Philipp Zabel wrote: > + > + /* Retain current field setting as default */ > + if (sdformat->format.field == V4L2_FIELD_ANY) > + sdformat->format.field = fmt->field; > + > + /* Retain current colorspace setting as default */ > +

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

On Wed, Apr 05, 2017 at 10:02:42AM -0600, Shuah Khan wrote: > When coherent DMA memory without struct page is shared, importer > fails to find the page and runs into kernel page fault when it > tries to dmabuf_ops_attach/map_sg/map_page the invalid page found > in the sg_table. Please see

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

On Tue, Apr 04, 2017 at 05:44:05PM -0700, Steve Longerbeam wrote: > > > On 04/04/2017 05:40 PM, Steve Longerbeam wrote: > > > > > >On 04/04/2017 04:10 PM, Russell King - ARM Linux wrote: > >>On Thu, Mar 30, 2017 at 07:25:49PM +0200, Philipp Zabel wrote:

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

On Thu, Mar 30, 2017 at 07:25:49PM +0200, Philipp Zabel wrote: > The TVP5150 DT bindings specify a single output port (port 0) that > corresponds to the video output pad (pad 1, DEMOD_PAD_VID_OUT). > > Signed-off-by: Philipp Zabel > --- > I'm trying to get this to work

Re: [PATCH 2/2] [media] cec: Handle RC capability more elegantly

On Tue, Apr 04, 2017 at 05:10:05PM +0100, Lee Jones wrote: > @@ -237,7 +241,6 @@ struct cec_adapter *cec_allocate_adapter(const struct > cec_adap_ops *ops, > if (!(caps & CEC_CAP_RC)) > return adap; > > -#if IS_REACHABLE(CONFIG_RC_CORE) > /* Prepare the RC input device

Re: [PATCH] [media] cec: Handle RC capability more elegantly

On Tue, Apr 04, 2017 at 04:19:39PM +0100, Lee Jones wrote: > On Tue, 04 Apr 2017, Hans Verkuil wrote: > > > On 04/04/2017 04:43 PM, Lee Jones wrote: > > > If a user specifies the use of RC as a capability, they should > > > really be enabling RC Core code. If they do not we WARN() them > > > of

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

On Mon, Apr 03, 2017 at 09:07:43AM -0500, Rob Herring wrote: > On Tue, Mar 28, 2017 at 05:35:52PM -0700, Steve Longerbeam wrote: > > I assume if there's another binding doc in progress, it means > > someone is working on another Synopsys DW CSI-2 subdevice driver. > > Yes. see

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

On Mon, Apr 03, 2017 at 09:11:35AM -0500, Rob Herring wrote: > On Wed, Mar 29, 2017 at 09:39:05AM +0100, Russell King - ARM Linux wrote: > > On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote: > > > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam <slongerb...@gm

Re: [PATCHv6 01/10] media: add CEC notifier support

On Sat, Apr 01, 2017 at 11:22:03AM +0200, Hans Verkuil wrote: > On 31/03/17 22:46, Russell King - ARM Linux wrote: > > On Fri, Mar 31, 2017 at 02:20:27PM +0200, Hans Verkuil wrote: > >> +struct cec_notifier *cec_notifier_get(struct device *dev) > >> +{ >

Re: [PATCHv6 01/10] media: add CEC notifier support

On Fri, Mar 31, 2017 at 02:20:27PM +0200, Hans Verkuil wrote: > +struct cec_notifier *cec_notifier_get(struct device *dev) > +{ > + struct cec_notifier *n; > + > + mutex_lock(_notifiers_lock); > + list_for_each_entry(n, _notifiers, head) { > + if (n->dev == dev) { > +

Re: [PATCHv6 00/10] video/exynos/sti/cec: add CEC notifier & use in drivers

On Fri, Mar 31, 2017 at 03:39:20PM +0100, Russell King - ARM Linux wrote: > On Fri, Mar 31, 2017 at 02:20:26PM +0200, Hans Verkuil wrote: > > Comments are welcome. I'd like to get this in for the 4.12 kernel as > > this is a missing piece needed to integrate CEC drivers. > &

Re: [PATCHv6 00/10] video/exynos/sti/cec: add CEC notifier & use in drivers

On Fri, Mar 31, 2017 at 02:20:26PM +0200, Hans Verkuil wrote: > Comments are welcome. I'd like to get this in for the 4.12 kernel as > this is a missing piece needed to integrate CEC drivers. First two patches seem fine, and work with dw-hdmi. I'll hold dw-hdmi off until after 4.11 - I currently

Re: [PATCHv5 04/11] exynos_hdmi: add CEC notifier support

On Wed, Mar 29, 2017 at 04:15:36PM +0200, Hans Verkuil wrote: > + cec_notifier_set_phys_addr(hdata->notifier, > +cec_get_edid_phys_addr(edid)); This pattern causes problems - can we have the notifier taking the EDID please, and stubs in cec-notifier.h to stub

Re: [PATCH v6 00/39] i.MX Media Driver

On Thu, Mar 30, 2017 at 09:12:29AM -0700, Steve Longerbeam wrote: > > > On 03/30/2017 04:02 AM, Russell King - ARM Linux wrote: > >This fails at step 1. The removal of the frame interval support now > >means my setup script fails when trying to set the frame inte

Re: [PATCH v6 00/39] i.MX Media Driver

This fails at step 1. The removal of the frame interval support now means my setup script fails when trying to set the frame interval on the camera: Enumerating pads and links Setting up format SRGGB8_1X8 816x616 on pad imx219 0-0010/0 Format set: SRGGB8_1X8 816x616 Setting up frame interval

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote: > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam > wrote: > > Add bindings documentation for the i.MX media driver. > > > > Signed-off-by: Steve Longerbeam > > --- > >

Re: [PATCH v5 00/39] i.MX Media Driver

On Tue, Mar 21, 2017 at 11:59:02AM +0100, Hans Verkuil wrote: > Ah, good to hear that -s works with MC. I was not sure about that. > Thanks for the feedback! Not soo good on iMX6: $ v4l2-compliance -d /dev/video10 -s --expbuf-device=/dev/video0 ... Input ioctls: test

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

On Mon, Mar 20, 2017 at 06:23:24PM +0100, Philipp Zabel wrote: > @@ -1173,15 +1196,8 @@ static void csi_try_fmt(struct csi_priv *priv, > incc = imx_media_find_mbus_format(infmt->code, > CS_SEL_ANY, true); > > - if

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

On Mon, Mar 20, 2017 at 06:23:24PM +0100, Philipp Zabel wrote: > --8<-- > >From 2830aebc404bdfc9d7fc1ec94e5282d0b668e8f6 Mon Sep 17 00:00:00 2001 > From: Philipp Zabel > Date: Mon, 20 Mar 2017 17:10:21 +0100 > Subject: [PATCH] media: imx: csi: add sink

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

On Mon, Mar 20, 2017 at 06:40:21PM +0100, Philipp Zabel wrote: > On Mon, 2017-03-20 at 14:17 +0000, Russell King - ARM Linux wrote: > > I have tripped over a bug in media-ctl when specifying both a crop and > > compose rectangle - the --help output suggests that "," shoul

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

On Mon, Mar 20, 2017 at 02:17:05PM +, Russell King - ARM Linux wrote: > On Mon, Mar 20, 2017 at 03:00:51PM +0100, Philipp Zabel wrote: > > On Mon, 2017-03-20 at 12:08 +, Russell King - ARM Linux wrote: > > > The same document says: > > > > > > Scaling

Re: [PATCH v5 00/39] i.MX Media Driver

On Mon, Mar 20, 2017 at 05:29:07PM +0100, Philipp Zabel wrote: > According to the documentation [1], you are doing the right thing: > > The struct v4l2_subdev_frame_interval pad references a non-existing > pad, or the pad doesn’t support frame intervals. > > But v4l2_subdev_call returns

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Mon, Mar 20, 2017 at 12:39:38PM -0300, Mauro Carvalho Chehab wrote: > Em Mon, 20 Mar 2017 14:24:25 +0100 > Hans Verkuil escreveu: > > I don't think this control inheritance patch will magically prevent you > > from needed a plugin. > > Yeah, it is not just control

Re: [PATCH v5 00/39] i.MX Media Driver

On Mon, Mar 20, 2017 at 02:20:16PM +0100, Philipp Zabel wrote: > To set and read colorimetry information: > https://patchwork.linuxtv.org/patch/39350/ Thanks, I've applied all four of your patches, but there's a side effect from that. Old media-ctl (modified by me): - entity 53: imx219 0-0010

Re: [PATCHv2 1/4] video: add hotplug detect notifier support

On Mon, Mar 20, 2017 at 02:26:16PM +, Russell King - ARM Linux wrote: > On Mon, Jan 02, 2017 at 03:19:04PM +0100, Hans Verkuil wrote: > > From: Hans Verkuil <hans.verk...@cisco.com> > > > > Add support for video hotplug detect and EDID/ELD notifiers, which is use

Re: [PATCHv2 1/4] video: add hotplug detect notifier support

On Mon, Jan 02, 2017 at 03:19:04PM +0100, Hans Verkuil wrote: > From: Hans Verkuil > > Add support for video hotplug detect and EDID/ELD notifiers, which is used > to convey information from video drivers to their CEC and audio counterparts. > > Based on an earlier

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

On Mon, Mar 20, 2017 at 03:00:51PM +0100, Philipp Zabel wrote: > On Mon, 2017-03-20 at 12:08 +0000, Russell King - ARM Linux wrote: > > The same document says: > > > > Scaling support is optional. When supported by a subdev, the crop > > rectangle on the

Re: [PATCH v5 00/39] i.MX Media Driver

On Mon, Mar 20, 2017 at 02:57:03PM +0100, Hans Verkuil wrote: > On 03/20/2017 02:29 PM, Russell King - ARM Linux wrote: > > It's what I have - remember, not everyone is happy to constantly replace > > their distro packages with random new stuff. > > This is a c

Re: [PATCH v5 00/39] i.MX Media Driver

On Mon, Mar 20, 2017 at 02:01:58PM +0100, Hans Verkuil wrote: > On 03/19/2017 06:54 PM, Steve Longerbeam wrote: > > > > > > On 03/19/2017 03:38 AM, Russell King - ARM Linux wrote: > >> What did you do with: > >> > >> ioctl(3, VIDIOC_REQBUFS, {count

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

On Mon, Mar 20, 2017 at 12:55:26PM +0100, Philipp Zabel wrote: > The above paragraph suggests we skip any rectangles that are not > supported. In our case that would be 3. and 4., since the CSI can't > compose into a larger frame. I hadn't realised that the crop selection > currently happens on

Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration

On Mon, Mar 20, 2017 at 10:23:30AM +0100, Philippe De Muyter wrote: > So existing gstreamer applications using /dev/video* to control framerate, > and even gain and exposure won't work anymore :( ? > > I had hoped to keep compatibility, with added robustness and functionality. > > I seems like

Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration

On Mon, Mar 20, 2017 at 09:55:12AM +0100, Philippe De Muyter wrote: > Hi Russel, > > On Sun, Mar 19, 2017 at 10:49:08AM +, Russell King wrote: > > Add support for enumerating frame sizes and frame intervals from the > > first subdev via the V4L2 interfaces. > > > > Signed-off-by: Russell

Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration

On Sun, Mar 19, 2017 at 03:21:37PM -0700, Steve Longerbeam wrote: > > > On 03/19/2017 03:49 AM, Russell King wrote: > >Add support for enumerating frame sizes and frame intervals from the > >first subdev via the V4L2 interfaces. > > > >Signed-off-by: Russell King >

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 11:37:15AM -0700, Steve Longerbeam wrote: > On 03/19/2017 05:14 AM, Russell King - ARM Linux wrote: > >Right now, CSI doesn't do that - it only looks at the width, height, > >code, and field. > > Correct, there is currently no propagation of the col

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 10:54:22AM -0700, Steve Longerbeam wrote: > > > On 03/19/2017 03:38 AM, Russell King - ARM Linux wrote: > >On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > >>Right, imx-media-capture.c (the "standard" v4l2 user interfa

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

On Thu, Mar 09, 2017 at 08:53:18PM -0800, Steve Longerbeam wrote: > From: Philipp Zabel > > The csi_try_crop call in set_fmt should compare the cropping rectangle > to the currently set input format, not to the previous input format. Are we really sure that the cropping

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 05:00:08PM +0200, Vladimir Zapolskiy wrote: > On 03/19/2017 04:22 PM, Russell King - ARM Linux wrote: > > On Sun, Mar 19, 2017 at 02:21:10PM +, Russell King - ARM Linux wrote: > >> There's a good reason why I dumped a full debug log using GST_DEBUG=

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 10:33:25AM -0400, Nicolas Dufresne wrote: > Le dimanche 19 mars 2017 à 00:54 +0000, Russell King - ARM Linux a > écrit : > > > > > > In practice, I have the impression there is a fair reason why > > > framerate > > > enumeration is

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 02:21:10PM +, Russell King - ARM Linux wrote: > There's a good reason why I dumped a full debug log using GST_DEBUG=*:9, > analysed it for the cause of the failure, and tried several different > pipelines, including the standard bayer2rgb plugin. > > Ple

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 03:57:56PM +0200, Vladimir Zapolskiy wrote: > Hi Russell, > > On 03/18/2017 10:43 PM, Russell King - ARM Linux wrote: > > On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > >> Can you share your gstreamer

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > On 03/18/2017 12:22 PM, Russell King - ARM Linux wrote: > >0:00:01.955927879 20954 0x15ffe90 INFOv4l2 > >gstv4l2object.c:3811:gst_v4l2_object_get_caps: probed caps: > >video/x-bayer

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > Right, imx-media-capture.c (the "standard" v4l2 user interface module) > is not implementing VIDIOC_ENUM_FRAMESIZES. It should, but it can only > return the single frame size that the pipeline has configured (the mbus > format of

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 08:41:14PM -0400, Nicolas Dufresne wrote: > Along with the norm fallback, GStreamer could could also consider the > currently set framerate as returned by VIDIOC_G_PARM. At the same time, > implementing that enumeration shall be straightforward, and will make a > large

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 08:41:14PM -0400, Nicolas Dufresne wrote: > Le samedi 18 mars 2017 à 20:43 +0000, Russell King - ARM Linux a > écrit : > > On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > > > Can you share your gstreamer pip

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > Can you share your gstreamer pipeline? For now, until > VIDIOC_ENUM_FRAMESIZES is implemented, try a pipeline that > does not attempt to specify a frame rate. I use the attached > script for testing, which works for me. It's

Re: [PATCH v5 00/39] i.MX Media Driver

Hi Steve, I've just been trying to get gstreamer to capture and h264 encode video from my camera at various frame rates, and what I've discovered does not look good. 1) when setting frame rates, media-ctl _always_ calls VIDIOC_SUBDEV_S_FRAME_INTERVAL with pad=0. 2) media-ctl never retrieves

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Fri, Mar 17, 2017 at 02:51:10PM +0100, Philipp Zabel wrote: > On Fri, 2017-03-17 at 10:24 -0300, Mauro Carvalho Chehab wrote: > [...] > > The big question, waiting for an answer on the last 8 years is > > who would do that? Such person would need to have several different > > hardware from

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Fri, Mar 17, 2017 at 01:02:07PM +0100, Philipp Zabel wrote: > I think most of the simple, fixed pipeline use cases could be handled by > libv4l2, by allowing to pass a v4l2 subdevice path to v4l2_open. If that > function internally would set up the media links to the > nearest /dev/video

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote: > We're all very driver-development-driven, and userspace gets very little > attention in general. So before just throwing in the towel we should take > a good look at the reasons why there has been little or no development: is > it

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

On Tue, Mar 14, 2017 at 12:21:31PM -0400, Nicolas Dufresne wrote: > My main concern here based on what I'm reading, is that this driver is > not even able to notice immediately that a produced frame was corrupted > (because it's out of sync). From usability perspective, this is really > bad. Can't

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

On Mon, Mar 13, 2017 at 11:03:50PM +0200, Sakari Ailus wrote: > Hi Steve, > > On Mon, Mar 13, 2017 at 11:06:22AM -0700, Steve Longerbeam wrote: > > I'm kinda in the middle on this topic. I agree with Sakari that > > frame rate can fluctuate, but that should only be temporary. If > > the frame

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

On Mon, Mar 13, 2017 at 10:56:46PM +0200, Sakari Ailus wrote: > Hi Russell, > > On Mon, Mar 13, 2017 at 01:27:02PM +, Russell King - ARM Linux wrote: > > On Mon, Mar 13, 2017 at 03:16:48PM +0200, Sakari Ailus wrote: > > > The vast majority of existing drivers d

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

On Mon, Mar 13, 2017 at 03:16:48PM +0200, Sakari Ailus wrote: > The vast majority of existing drivers do not implement them nor the user > space expects having to set them. Making that mandatory would break existing > user space. > > In addition, that does not belong to link validation either:

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Mon, Mar 13, 2017 at 08:42:15AM -0300, Mauro Carvalho Chehab wrote: > I don't have myself any hardware with i.MX6. Yet, I believe that > a low cost board like SolidRun Hummingboard - with comes with a > CSI interface compatible with RPi camera modules - will likely > attract users who need to

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Mon, Mar 13, 2017 at 11:44:50AM +0100, Hans Verkuil wrote: > On 03/12/2017 06:56 PM, Steve Longerbeam wrote: > > In summary, I do like the media framework, it's a good abstraction of > > hardware pipelines. It does require a lot of system level knowledge to > > configure, but as I said that is

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

On Mon, Mar 13, 2017 at 11:02:34AM +0100, Hans Verkuil wrote: > On 03/11/2017 07:14 PM, Steve Longerbeam wrote: > > The event must be user visible, otherwise the user has no indication > > the error, and can't correct it by stream restart. > > In that case the driver can detect this and call

Re: [PATCH v5 00/39] i.MX Media Driver

On Mon, Mar 13, 2017 at 08:16:25AM +, Russell King - ARM Linux wrote: > On Sun, Mar 12, 2017 at 09:26:41PM -0700, Steve Longerbeam wrote: > > On 03/12/2017 01:22 PM, Russell King - ARM Linux wrote: > > >What I had was this patch for your v3. I never got to testing yo

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 12, 2017 at 09:26:41PM -0700, Steve Longerbeam wrote: > On 03/12/2017 01:22 PM, Russell King - ARM Linux wrote: > >What I had was this patch for your v3. I never got to testing your > >v4 because of the LP-11 problem. > > > >In v5, you've changed to propag

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 12, 2017 at 05:59:28PM -0300, Mauro Carvalho Chehab wrote: > Yet, udev/systemd has some rules that provide an unique name for V4L > devices at /lib/udev/rules.d/60-persistent-v4l.rules. Basically, it > runs a small application (v4l_id) with creates a persistent symling > using rules

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 12, 2017 at 08:40:37PM +, Russell King - ARM Linux wrote: > On Sun, Mar 12, 2017 at 01:36:32PM -0700, Steve Longerbeam wrote: > > But hold on, if my logic is correct, then why did the CSI power-off > > get reached in your case, multiple times? Yes I think

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 12, 2017 at 01:36:32PM -0700, Steve Longerbeam wrote: > But hold on, if my logic is correct, then why did the CSI power-off > get reached in your case, multiple times? Yes I think there is a bug, > link_notify() is not checking if the link has already been disabled. > I will fix this.

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 12, 2017 at 01:05:06PM -0700, Steve Longerbeam wrote: > > > On 03/12/2017 12:57 PM, Russell King - ARM Linux wrote: > >On Sat, Mar 11, 2017 at 04:30:53PM -0800, Steve Longerbeam wrote: > >>If it's too difficult to get the imx219 csi-2 transmitter into the

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 11, 2017 at 04:30:53PM -0800, Steve Longerbeam wrote: > If it's too difficult to get the imx219 csi-2 transmitter into the > LP-11 state on power on, perhaps the csi-2 receiver can be a little > more lenient on the transmitter and make the LP-11 timeout a warning > instead of

Re: [PATCH v5 00/39] i.MX Media Driver

Another issue. The "reboot and the /dev/video* devices come up in a completely different order" problem seems to exist with this version. The dot graph I supplied previously had "ipu1_csi0 capture" on /dev/video4. I've just rebooted, and now I find it's on /dev/video2 instead. Here's the

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 12, 2017 at 12:21:45PM -0700, Steve Longerbeam wrote: > There's actually nothing preventing userland from disabling a link > multiple times, and imx_media_link_notify() complies, and so > csi_s_power(OFF) gets called multiple times, and so that WARN_ON() > in there is silly, I borrowed

Re: [PATCH v5 00/39] i.MX Media Driver

I've just looked at my test system's dmesg, and spotted this in the log. It's been a while since these popped out of the kernel, so I don't know what caused them (other than the obvious, a media-ctl command.) My script which sets this up only enables links, and then configures the formats etc,

Re: [PATCH v5 00/39] i.MX Media Driver

On Fri, Mar 10, 2017 at 03:20:34PM -0800, Steve Longerbeam wrote: > > > On 03/10/2017 12:13 PM, Russell King - ARM Linux wrote: > >Version 5 gives me no v4l2 controls exposed through the video device > >interface. > > > >Just like with version 4, version 5

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote: > > > On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote: > >On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote: > >> > >> > >>On 03/11/2017 10:45 AM, Russell King -

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Sat, Mar 11, 2017 at 08:25:49AM -0300, Mauro Carvalho Chehab wrote: > This situation is there since 2009. If I remember well, you tried to write > such generic plugin in the past, but never finished it, apparently because > it is too complex. Others tried too over the years. > > The last

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Sat, Mar 11, 2017 at 11:06:55AM -0800, Steve Longerbeam wrote: > On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote: > >On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote: > >> > >> > >>On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote: > > > On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote: > >I really don't think expecting the user to understand and configure > >the pipeline is a sane way forward. Think about it - should the

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

On Sat, Mar 11, 2017 at 10:14:49AM -0800, Steve Longerbeam wrote: > On 03/11/2017 03:39 AM, Hans Verkuil wrote: > >It's fine to use an internal event as long as the end-user doesn't > >see it. But if you lose vsyncs, then you never capture another frame, > >right? > > No, that's not correct. By

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Sat, Mar 11, 2017 at 10:08:23AM -0800, Steve Longerbeam wrote: > On 03/11/2017 07:32 AM, Sakari Ailus wrote: > >Hi Mauro and Hans, > > > >On Sat, Mar 11, 2017 at 10:14:08AM -0300, Mauro Carvalho Chehab wrote: > >>Em Sat, 11 Mar 2017 12:32:43 +0100 > >>Hans Verkuil escreveu:

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Sat, Mar 11, 2017 at 05:32:29PM +0200, Sakari Ailus wrote: > My understanding of the i.MX6 case is the hardware is configurable enough > to warrant the use of the Media controller API. Some patches indicate > there are choices to be made in data routing. The iMX6 does have configurable data

Re: [PATCH v5 00/39] i.MX Media Driver

Version 5 gives me no v4l2 controls exposed through the video device interface. Just like with version 4, version 5 is completely useless with IMX219: imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200 ipu1_csi0: pipeline start failed with -110 imx6-mipi-csi2: LP-11 timeout, phy_state =

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Fri, Mar 10, 2017 at 03:57:09PM +, Russell King - ARM Linux wrote: > Enabling debug output in gstreamer's v4l2src plugin confirms that > the kernel's bayer format are totally hidden from gstreamer when > linked with libv4l2, but are present when it isn't linked with > libv

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Fri, Mar 10, 2017 at 12:26:34PM -0300, Mauro Carvalho Chehab wrote: > Hi Russell, > > Em Fri, 10 Mar 2017 13:07:33 + > Russell King - ARM Linux <li...@armlinux.org.uk> escreveu: > > > The idea that the v4l libraries should intercept the format negotiation

  1   2   3   4   5   >