Just one patch that renames vb2_m2m_request_queue to v4l2_m2m_request_queue.
Regards,
Hans
The following changes since commit e4183d3256e3cd668e899d06af66da5aac3a51af:
media: dt-bindings: Document the Rockchip VPU bindings (2018-10-05 07:00:43
-0400)
are available in the Git
On 10/18/2018 09:23 PM, Ezequiel Garcia wrote:
> Hi everyone,
>
> In Collabora, and as part of our kernelci work, we are doing
> research on kernel functional testing with kernelci.
>
> For those new to kernelci, see
> https://github.com/kernelci/kernelci-doc/wiki/KernelCI
> and
On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
> Set up a statically-allocated, dummy buffer to
> be used as flush buffer, which signals
> a encoding (or decoding) stop.
>
> When the flush buffer is queued to the OUTPUT queue,
> the driver will send an V4L2_EVENT_EOS event, and
> mark the CAPTURE
On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
> The decoder interface (not yet merged) specifies that
> width and height values set on the OUTPUT queue, must
> be propagated to the CAPTURE queue.
>
> This is not enough to comply with the specification,
> which would require to properly support
I noticed that repeatedly running 'cec-ctl --playback' would occasionally
select 'Playback Device 2' instead of 'Playback Device 1', even though there
were no other Playback devices in the HDMI topology. This happened both with
'real' hardware and with the vivid CEC emulation, suggesting that this
On 10/19/18 14:31, Mauro Carvalho Chehab wrote:
> Em Fri, 19 Oct 2018 13:45:32 +0200
> Hans Verkuil escreveu:
>
>> On 10/19/18 13:43, Mauro Carvalho Chehab wrote:
>>> Those drivers are part of the legacy SoC camera framework.
>>> They're being converted to not use it, but sometimes we're
>>>
Hi Nicolas,
On Fri, 2018-10-19 at 07:41 -0400, Nicolas Dufresne wrote:
> Le vendredi 19 octobre 2018 à 07:35 -0400, Nicolas Dufresne a écrit :
> > Le vendredi 19 octobre 2018 à 09:28 +0200, Hans Verkuil a écrit :
> > > On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
> > > > Set up a
Add callback to check if we are already streaming. Now other callbacks
can check the state and return -EBUSY if we already streaming.
Signed-off-by: Marco Felsch
---
drivers/media/i2c/mt9m111.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/i2c/mt9m111.c
From: Michael Grzeschik
Currently set_fmt don't care about the streaming status, so the format
can be changed during streaming. This can lead into wrong behaviours.
Check if the device is already streaming and return -EBUSY to avoid
wrong behaviours.
Signed-off-by: Michael Grzeschik
Hello,
the purpose of this series is to support the pixclk polarity and the
framerate selection. I picked the patches form Michael and Enrico,
ported them to 4.19 and did some adjustments.
I tested the framrate and pixckl selection on a custom arm based board.
Enrico Scholz (1):
media:
From: Enrico Scholz
The chip can be configured to output data transitions on the
rising or falling edge of PIXCLK (Datasheet R58:1[9]), default is on the
falling edge.
Parsing the fw-node is made in a subfunction to bundle all (future)
dt-parsing / fw-parsing stuff.
Signed-off-by: Enrico
From: Michael Grzeschik
This patch implements the framerate selection using the skipping and
readout power-modi features. The power-modi cut the framerate by half
and each context has an independent selection bit. The same applies to
the 2x skipping feature.
Signed-off-by: Michael Grzeschik
Hi Mauro, Hans, Sakari,
On Fri, Oct 19, 2018 at 03:58:51PM +0300, Sakari Ailus wrote:
> Hi Hans, Mauro,
>
> On Fri, Oct 19, 2018 at 02:39:27PM +0200, Hans Verkuil wrote:
> > On 10/19/18 14:31, Mauro Carvalho Chehab wrote:
> > > Em Fri, 19 Oct 2018 13:45:32 +0200
> > > Hans Verkuil escreveu:
> >
On Fri, 2018-10-19 at 09:14 +0200, Hans Verkuil wrote:
> On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
> > The decoder interface (not yet merged) specifies that
> > width and height values set on the OUTPUT queue, must
> > be propagated to the CAPTURE queue.
> >
> > This is not enough to comply
On Fri, 2018-10-19 at 09:06 +0200, Hans Verkuil wrote:
> On 10/18/2018 09:23 PM, Ezequiel Garcia wrote:
> > Hi everyone,
> >
> > In Collabora, and as part of our kernelci work, we are doing
> > research on kernel functional testing with kernelci.
> >
> > For those new to kernelci, see
> >
Hi Hans, Mauro,
On Fri, Oct 19, 2018 at 02:39:27PM +0200, Hans Verkuil wrote:
> On 10/19/18 14:31, Mauro Carvalho Chehab wrote:
> > Em Fri, 19 Oct 2018 13:45:32 +0200
> > Hans Verkuil escreveu:
> >
> >> On 10/19/18 13:43, Mauro Carvalho Chehab wrote:
> >>> Those drivers are part of the legacy
Awesome, thanks Philipp.
For the whole series:
Acked-by: Steve Longerbeam
Tested-by: Steve Longerbeam
on i.MX6q SabreSD.
On 10/19/18 5:15 AM, Philipp Zabel wrote:
Hi,
this is the fourth version of the i.MX mem2mem scaler series.
An alignment issue with 24-bit RGB formats has been
Hi Enrico,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.19-rc8 next-20181019]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
On 10/19/18 2:53 AM, Philipp Zabel wrote:
Hi Tim,
On Thu, 2018-10-18 at 15:53 -0700, Tim Harvey wrote:
[...]
Philipp,
Thanks for submitting this!
I'm hoping this lets us use non-IMX capture devices along with the IMX
media controller entities to so we can use hardware
Hi Jacopo,
On Fri, Oct 19, 2018 at 03:13:28PM +0200, jacopo mondi wrote:
> Hi Mauro, Hans, Sakari,
>
> On Fri, Oct 19, 2018 at 03:58:51PM +0300, Sakari Ailus wrote:
> > Hi Hans, Mauro,
> >
> > On Fri, Oct 19, 2018 at 02:39:27PM +0200, Hans Verkuil wrote:
> > > On 10/19/18 14:31, Mauro Carvalho
Hi Marco,
Thanks for the patchset.
On Fri, Oct 19, 2018 at 05:50:27PM +0200, Marco Felsch wrote:
> From: Enrico Scholz
>
> The chip can be configured to output data transitions on the
> rising or falling edge of PIXCLK (Datasheet R58:1[9]), default is on the
> falling edge.
>
> Parsing the
On 10/18/18 10:56 AM, Tim Harvey wrote:
On Wed, Oct 17, 2018 at 4:37 PM Steve Longerbeam wrote:
On 10/17/18 4:05 PM, Tim Harvey wrote:
On Wed, Oct 17, 2018 at 2:33 PM Steve Longerbeam wrote:
Hi Tim,
On 10/17/18 1:38 PM, Tim Harvey wrote:
On Mon, Jun 4, 2018 at 1:58 AM Krzysztof Hałasa
On Fri, Oct 19, 2018 at 1:19 PM Steve Longerbeam wrote:
>
>
> On 10/19/18 2:53 AM, Philipp Zabel wrote:
> > Hi Tim,
> >
> > On Thu, 2018-10-18 at 15:53 -0700, Tim Harvey wrote:
> > [...]
> >> Philipp,
> >>
> >> Thanks for submitting this!
> >>
> >> I'm hoping this lets us use non-IMX capture
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 20 05:00:11 CEST 2018
media-tree git hash:3b796aa60af087f5fec75aee9b17f2130f2b9adc
media_build
On Fri, 2018-10-19 at 09:28 +0200, Hans Verkuil wrote:
> On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
> > Set up a statically-allocated, dummy buffer to
> > be used as flush buffer, which signals
> > a encoding (or decoding) stop.
> >
> > When the flush buffer is queued to the OUTPUT queue,
> >
From: Steve Longerbeam
Prevent possible race by parallel threads between ipu_image_convert_run()
and ipu_image_convert_unprepare(). This involves setting ctx->aborting
to true unconditionally so that no new job runs can be queued during
unprepare, and holding the ctx->aborting flag until the
From: Steve Longerbeam
Catch calculated tile offsets that are not 8-byte aligned as required by the
IDMAC engine and return error in calc_tile_offsets().
Signed-off-by: Steve Longerbeam
---
New since v3.
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 61 --
1 file
From: Steve Longerbeam
Add a WARN_ON_ONCE() if either the Y/packed buffer, or the U/V offsets,
are not aligned on 8-byte boundaries. This will catch alignment
bugs in DRM, V4L2.
Signed-off-by: Steve Longerbeam
---
No changes since v3.
---
drivers/gpu/ipu-v3/ipu-cpmem.c | 6 ++
1 file
Select seam positions that minimize distortions during seam hiding while
satifying input and output IDMAC, rotator, and image format constraints.
This code looks for aligned output seam positions that minimize the
difference between the fractional corresponding ideal input positions
and the input
Since tile dimensions now vary between tiles, add debug output for each
tile's position and dimensions.
Signed-off-by: Philipp Zabel
---
No changes since v3.
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git
This will allow to calculate seam positions after initializing the
ipu_image base structure but before calculating tile dimensions.
Signed-off-by: Philipp Zabel
---
No changes since v3.
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 18 +-
1 file changed, 13 insertions(+), 5
From: Steve Longerbeam
Allow the caller of ipu_cpmem_set_image() to override the latters
calculation of the chroma plane offsets, by adding override U/V
plane offsets to 'struct ipu_image'.
Signed-off-by: Steve Longerbeam
---
New since v3.
---
drivers/gpu/ipu-v3/ipu-cpmem.c | 46
Store tile top/left position in pixels in the tile structure.
This will allow overlapping tiles with different sizes later.
Signed-off-by: Philipp Zabel
---
No functional changes since v3.
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 27 ++
1 file changed, 15
For planar formats, bytesperline does not depend on BPP. It must always
be larger than width and aligned to tile width alignment restrictions.
The input bytesperline to ipu_image_convert_adjust() may be
uninitialized, so don't rely on input bytesperline as the
minimum value for clamp_align(). Use
Move tile_width_align and tile_height_align up so they
can be used by the tile edge position calculation code.
Signed-off-by: Philipp Zabel
---
No changes since v3.
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 54 +-
1 file changed, 27 insertions(+), 27 deletions(-)
Hi,
this is the fourth version of the i.MX mem2mem scaler series.
An alignment issue with 24-bit RGB formats has been corrected in the
seam position selection patch and a few new fixes by Steve have been
added. If there are no more issues, I'll pick up the ipu-v3 patches
via imx-drm/next. The
For differently sized tiles or if the resizing coefficients change,
we have to stop, reconfigure, and restart the IC between tiles.
Signed-off-by: Philipp Zabel
---
No changes since v3.
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 65 +-
1 file changed, 44 insertions(+),
For the planar but U/V-packed formats NV12 and NV16, 8 pixel width
alignment is good enough to fulfill the 8 byte stride requirement.
If we allow the input 8-pixel DMA bursts to overshoot the end of the
line, the only input alignment restrictions are dictated by the pixel
format and 8-byte aligned
From: Steve Longerbeam
Allow reentrancy into ipu_image_convert_abort(), by moving re-init
of ctx->aborted completion under the spin lock, and only if there is
an active run, and complete all waiters do_bh(). Note:
ipu_image_convert_unprepare() is still _not_ reentrant, and can't
be made
If width or height are in the [2049, 3072] range, allow to
use just three tiles in this dimension, instead of four.
Signed-off-by: Philipp Zabel
---
No changes since v3.
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
Add a single imx-media mem2mem video device that uses the IPU IC PP
(image converter post processing) task for scaling and colorspace
conversion.
On i.MX6Q/DL SoCs with two IPUs currently only the first IPU is used.
The hardware only supports writing to destination buffers up to
1024x1024 pixels
Let convert_start start from a given tile index, allocate intermediate
tile with maximum tile size.
Signed-off-by: Philipp Zabel
---
No changes since v3.
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 60 +++---
1 file changed, 35 insertions(+), 25 deletions(-)
diff --git
Double-buffering only works if tile sizes are the same and the resizing
coefficient does not change between tiles, even for non-planar formats.
Signed-off-by: Philipp Zabel
---
No changes since v3.
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 27 --
1 file changed, 25
From: Steve Longerbeam
Only wait for the ctx->aborted completion if there is an active run
in progress, otherwise the wait will just timeout after 10 seconds.
If there is no active run in progress, the done queue just needs to
be emptied.
Signed-off-by: Steve Longerbeam
---
New since v3.
---
From: Steve Longerbeam
The need_abort flag is not really needed anymore in
__ipu_image_convert_abort(), remove it.
No functional changes.
Signed-off-by: Steve Longerbeam
---
New since v3.
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
Visualize the scaling and rotation pipeline with some ASCII art
diagrams. Remove the FIXME comment about missing seam prevention.
Signed-off-by: Philipp Zabel
---
No changes since v3.
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 39 +++---
1 file changed, 29 insertions(+),
For tiled scaling, we want to compute the scaling coefficients
externally in such a way that the interpolation overshoots tile
boundaries and samples up to the first pixel of the next tile.
Prepare to override the resizing coefficients from the image
conversion code.
Signed-off-by: Philipp Zabel
Slightly modifying resize coefficients per-tile allows to completely
hide the seams between tiles and to sample the correct input pixels at
the bottom and right edges of the image.
Tiling requires a bilinear interpolator reset at each tile start, which
causes the image to be slightly shifted if
Hi Steve,
On Wed, 2018-10-17 at 16:46 -0700, Steve Longerbeam wrote:
> Hi Philipp,
>
> On 10/12/18 5:29 PM, Steve Longerbeam wrote:
> >
> >
> > But one last thing. Conversions to and from YV12 are producing images
> > with wrong colors, it looks like the .uv_swapped boolean needs to be
> >
Em Fri, 19 Oct 2018 13:45:32 +0200
Hans Verkuil escreveu:
> On 10/19/18 13:43, Mauro Carvalho Chehab wrote:
> > Those drivers are part of the legacy SoC camera framework.
> > They're being converted to not use it, but sometimes we're
> > keeping both legacy any new driver.
> >
> > This time,
Le vendredi 19 octobre 2018 à 09:28 +0200, Hans Verkuil a écrit :
> On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
> > Set up a statically-allocated, dummy buffer to
> > be used as flush buffer, which signals
> > a encoding (or decoding) stop.
> >
> > When the flush buffer is queued to the OUTPUT
On 10/19/18 13:35, Nicolas Dufresne wrote:
> Le vendredi 19 octobre 2018 à 09:28 +0200, Hans Verkuil a écrit :
>> On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
>>> Set up a statically-allocated, dummy buffer to
>>> be used as flush buffer, which signals
>>> a encoding (or decoding) stop.
>>>
>>>
Le vendredi 19 octobre 2018 à 07:35 -0400, Nicolas Dufresne a écrit :
> Le vendredi 19 octobre 2018 à 09:28 +0200, Hans Verkuil a écrit :
> > On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
> > > Set up a statically-allocated, dummy buffer to
> > > be used as flush buffer, which signals
> > > a
Those drivers are part of the legacy SoC camera framework.
They're being converted to not use it, but sometimes we're
keeping both legacy any new driver.
This time, for example, we have two drivers on media with
the same name: ov772x. That's bad.
So, in order to prevent that to happen, let's
On 10/19/18 13:43, Mauro Carvalho Chehab wrote:
> Those drivers are part of the legacy SoC camera framework.
> They're being converted to not use it, but sometimes we're
> keeping both legacy any new driver.
>
> This time, for example, we have two drivers on media with
> the same name: ov772x.
Hi!
On Thu, Oct 18, 2018 at 03:46:05PM +0200, jacopo mondi wrote:
> Hello Maxime,
>
> On Thu, Oct 18, 2018 at 11:29:12AM +0200, Maxime Ripard wrote:
> > Hi Jacopo,
> >
> > Thanks for reviewing this patch
> >
> > On Tue, Oct 16, 2018 at 06:54:50PM +0200, jacopo mondi wrote:
> > > > +static
Hi,
On Thu, Oct 18, 2018 at 03:35:25PM +0200, jacopo mondi wrote:
> Hi Maxime,
>
> On Thu, Oct 18, 2018 at 11:15:50AM +0200, Maxime Ripard wrote:
> > On Wed, Oct 17, 2018 at 09:37:17PM +0200, Jacopo Mondi wrote:
> > > Check that the PLL1 output frequency does not exceed the maximum allowed
> >
On Wed, 2018-10-17 at 14:33 -0700, Steve Longerbeam wrote:
[...]
> > I'm also interested in looking at Philipps' 'i.MX media mem2mem
> > scaler' series (https://patchwork.kernel.org/cover/10603881/) and am
> > wondering if anyone has some example pipelines showing that in use.
> > I'm hoping that
Hi Tim,
On Thu, 2018-10-18 at 15:53 -0700, Tim Harvey wrote:
[...]
> Philipp,
>
> Thanks for submitting this!
>
> I'm hoping this lets us use non-IMX capture devices along with the IMX
> media controller entities to so we can use hardware
> CSC,scaling,pixel-format-conversions and ultimately
59 matches
Mail list logo
