Hi Bing Bu,
On Mon, Nov 12, 2018 at 12:31:16PM +0800, Bing Bu Cao wrote:
>
>
> On 11/09/2018 06:09 PM, Sakari Ailus wrote:
> > Hi Bing Bu,
> >
> > On Wed, Nov 07, 2018 at 12:16:47PM +0800, Bing Bu Cao wrote:
> >> On 11/01/2018 08:03 PM, Sakari Ailus wrote:
> >>> Hi Yong,
> >>>
> >>> Thanks for
From: Hans Verkuil
Copy tags in vicodec.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vicodec/vicodec-core.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
From: Hans Verkuil
Add support for tags to vb2. Besides just storing and setting
the tag this patch also adds the vb2_find_tag() function that
can be used to find a buffer with the given tag.
This function will only look at DEQUEUED and DONE buffers, i.e.
buffers that are already processed.
Replace old reference frame indices by new tag method.
Signed-off-by: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-ctrls.c | 9
drivers/staging/media/sunxi/cedrus/cedrus.h | 9 +---
.../staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
When debugging is on, log the new tag field of struct v4l2_buffer
as well.
Signed-off-by: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-ioctl.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
From: Hans Verkuil
Add support for 'tags' to struct v4l2_buffer. These can be used
by m2m devices so userspace can set a tag for an output buffer and
this value will then be copied to the capture buffer(s).
This tag can be used to refer to capture buffers, something that
is needed by stateless
From: Hans Verkuil
Copy tags in vim2m.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vim2m.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index d82db738f174..9d1222f489b8 100644
---
Document V4L2_BUF_FLAG_TAG and struct v4l2_buffer_tag.
Signed-off-by: Hans Verkuil
---
Documentation/media/uapi/v4l/buffer.rst | 61 ---
.../media/uapi/v4l/vidioc-reqbufs.rst | 4 ++
2 files changed, 57 insertions(+), 8 deletions(-)
diff --git
Memory-to-memory devices should copy various parts of
struct v4l2_buffer from the output buffer to the capture buffer.
Add a helper function that does that to simplify the driver code.
Signed-off-by: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 23 +++
Add new flag to indicate that buffer tags are supported.
Signed-off-by: Hans Verkuil
---
drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 ++
include/media/videobuf2-core.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
As was discussed here (among other places):
https://lkml.org/lkml/2018/10/19/440
using capture queue buffer indices to refer to reference frames is
not a good idea. A better idea is to use a 'tag' where the
application can assign a u64 tag to an output buffer, which is then
copied to the
Hi,
On Thu, 2018-10-18 at 15:02 -0300, Ezequiel Garcia wrote:
> This series goal is to avoid drivers from having ad-hoc code
> to call .device_run in non-atomic context. Currently, .device_run
> can be called via v4l2_m2m_job_finish(), not only running
> in interrupt context, but also creating a
Hi,
On Mon, 2018-11-12 at 18:05 -0300, Ezequiel Garcia wrote:
> On Mon, 12 Nov 2018 at 13:52, Paul Kocialkowski
> wrote:
> > Hi,
> >
> > On Sun, 2018-11-11 at 18:26 -0300, Ezequiel Garcia wrote:
> > > On Thu, 2018-10-18 at 15:02 -0300, Ezequiel Garcia wrote:
> > > > This series goal is to avoid
The clock structure for the PCLK is quite obscure in the documentation, and
was hardcoded through the bytes array of each and every mode.
This is troublesome, since we cannot adjust it at runtime based on other
parameters (such as the number of bytes per pixel), and we can't support
either
Hi,
Here is a "small" series that mostly cleans up the ov5640 driver code,
slowly getting rid of the big data array for more understandable code
(hopefully).
The biggest addition would be the clock rate computation at runtime,
instead of relying on those arrays to setup the clock tree
properly.
The autoexposure setup in the 1080p init array is redundant with the
default value of the sensor.
Remove it.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
Part of the hardcoded initialization sequence is to set up the proper clock
dividers. However, this is now done dynamically through proper code and as
such, the static one is now redundant.
Let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 46
In the ov5640_try_frame_interval function, the ret variable actually holds
the frame rate index to use, which is represented by the enum
ov5640_frame_rate in the driver.
Make it more obvious.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 8
1 file changed, 4
On 11/13/2018 06:31 PM, Sakari Ailus wrote:
> Hi Bing Bu,
>
> On Mon, Nov 12, 2018 at 12:31:16PM +0800, Bing Bu Cao wrote:
>>
>> On 11/09/2018 06:09 PM, Sakari Ailus wrote:
>>> Hi Bing Bu,
>>>
>>> On Wed, Nov 07, 2018 at 12:16:47PM +0800, Bing Bu Cao wrote:
On 11/01/2018 08:03 PM, Sakari
On Tue, Nov 13, 2018 at 01:00:50AM +0900, Akinobu Mita wrote:
> The ov2640 has the test pattern generator features. This makes use of
> it through V4L2_CID_TEST_PATTERN control.
>
> Cc: Sakari Ailus
> Cc: Mauro Carvalho Chehab
> Signed-off-by: Akinobu Mita
> ---
> drivers/media/i2c/ov2640.c
The MIPI divider is also cleared as part of the clock setup sequence, so we
can remove that code.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index
The OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT and OV5640_SCLK_ROOT_DIVIDER_DEFAULT
defines represent exactly the same setup, and are at the same value, than
the more consistent with the rest of the driver OV5640_SCLK2X_ROOT_DIV and
OV5640_SCLK_ROOT_DIV.
Remove them.
Signed-off-by: Maxime Ripard
---
The current code uses an algorithm to clamp the FPS values and round them
to the closest supported one that isn't really allows to be extended to
more than two values.
Rework it a bit to make it much easier to extend the amount of FPS options
we support.
Signed-off-by: Maxime Ripard
---
Now that we have moved the clock generation logic out of the bytes array,
these arrays are identical between the 15fps and 30fps variants.
Remove the duplicate entries, and convert the code accordingly.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 306
The clock rate, while hardcoded until now, is actually a function of the
resolution, framerate and bytes per pixel. Now that we have an algorithm to
adjust our clock rate, we can select it dynamically when we change the
mode.
This changes a bit the clock rate being used, with the following
The pixel clock rates were introduced to report the initially static clock
rate.
Since this is now handled dynamically, we can remove them entirely.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff
On Sat, 2018-11-03 at 07:55 -0700, Derek Kelly wrote:
> The following patch adds event codes for common buttons found on
> various
> provider and universal remote controls. They represent functions not
> covered by existing event codes. Once added, rc_keymaps can be
> updated
> accordingly where
Now that we have everything in place to compute the clock rate at runtime,
we can enable the 60fps framerate for the mode we tested it with.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git
2018年11月13日(火) 19:37 Sakari Ailus :
>
> On Tue, Nov 13, 2018 at 01:00:50AM +0900, Akinobu Mita wrote:
> > The ov2640 has the test pattern generator features. This makes use of
> > it through V4L2_CID_TEST_PATTERN control.
> >
> > Cc: Sakari Ailus
> > Cc: Mauro Carvalho Chehab
> > Signed-off-by:
Sorry, that should have said [PATCH v2].
regards
Philipp
> On Sat, 2018-11-03 at 07:55 -0700, Derek Kelly wrote:
> > The following patch adds event codes for common buttons found on
> > various
> > provider and universal remote controls. They represent functions not
> > covered by existing event codes. Once added, rc_keymaps can be
> > updated
> >
If a filehandle is dup()ped, then it is possible to close it from one fd
and call mmap from the other. This creates a race condition in vb2_mmap
where it is using queue data that __vb2_queue_free (called from close())
is in the process of releasing.
By moving up the mutex_lock(mmap_lock) in
Calling VIDIOC_DQBUF can release the core serialization lock pointed to
by vb2_queue->lock if it has to wait for a new buffer to arrive.
However, if userspace dup()ped the video device filehandle, then it is
possible to read or call DQBUF from two filehandles at the same time.
It is also
From: Hans Verkuil
These two patches fix syzkaller race conditions. The basic problem is
the same for both: in some specific cases an ioctl can release the
core serialization mutex, thus allowing another thread to access the
same vb2 queue through a dup()ped filehandle.
This can happen in
Hi Philipp,
On 11/13/18 16:06, Philipp Zabel wrote:
> From: John Sheu
>
> Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
> buffers if the queue is of type V4L2_MEMORY_MMAP, and if the buffers are
> considered "in use". This is different behavior than for other memory
From: John Sheu
Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
buffers if the queue is of type V4L2_MEMORY_MMAP, and if the buffers are
considered "in use". This is different behavior than for other memory
types and prevents us from deallocating buffers in following
Calling the stop_streaming op can release the core serialization lock
pointed to by vb2_queue->lock if it has to wait for buffers to finish.
An example of that behavior is the vivid driver.
However, if userspace dup()ped the video device filehandle, then it is
possible to stop streaming on one
Le mercredi 14 novembre 2018 à 00:27 +0200, Sakari Ailus a écrit :
> Hi Philipp,
>
> On Tue, Nov 13, 2018 at 04:06:21PM +0100, Philipp Zabel wrote:
> > From: John Sheu
> >
> > Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
> > buffers if the queue is of type
Hi Philipp,
On Tue, Nov 13, 2018 at 04:06:21PM +0100, Philipp Zabel wrote:
> From: John Sheu
>
> Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
> buffers if the queue is of type V4L2_MEMORY_MMAP, and if the buffers are
> considered "in use". This is different behavior
Hello Mita-san,
thanks for the patches
On Tue, Nov 13, 2018 at 01:00:47AM +0900, Akinobu Mita wrote:
> This patchset addds relatively small enhancements (log_status ioctl, event
> interface, V4L2_CID_TEST_PATTERN control, and V4L2_CID_COLORFX control) for
> mt9m111, ov2640, ov5640, ov7670, and
Hi Hans, Mauro,
On Wed, Oct 31, 2018 at 07:54:21AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 31 Oct 2018 11:00:22 +0100
> Hans Verkuil escreveu:
>
> > On 10/31/2018 10:40 AM, Mauro Carvalho Chehab wrote:
> > > Em Wed, 31 Oct 2018 11:29:45 +0200
> > > Sakari Ailus escreveu:
> > >
> > >>
On Tue, Nov 13, 2018 at 10:55:46PM +0900, Akinobu Mita wrote:
> 2018年11月13日(火) 19:37 Sakari Ailus :
> >
> > On Tue, Nov 13, 2018 at 01:00:50AM +0900, Akinobu Mita wrote:
> > > The ov2640 has the test pattern generator features. This makes use of
> > > it through V4L2_CID_TEST_PATTERN control.
> >
On Tue, Nov 13, 2018 at 07:04:01PM +0800, Bing Bu Cao wrote:
>
>
> On 11/13/2018 06:31 PM, Sakari Ailus wrote:
> > Hi Bing Bu,
> >
> > On Mon, Nov 12, 2018 at 12:31:16PM +0800, Bing Bu Cao wrote:
> >>
> >> On 11/09/2018 06:09 PM, Sakari Ailus wrote:
> >>> Hi Bing Bu,
> >>>
> >>> On Wed, Nov 07,
On Mon, Oct 29, 2018 at 03:22:54PM -0700, Yong Zhi wrote:
> Hi,
>
> This series 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
On Wed, Nov 14, 2018 at 8:51 AM Nicolas Dufresne wrote:
>
> Le mercredi 14 novembre 2018 à 00:27 +0200, Sakari Ailus a écrit :
> > Hi Philipp,
> >
> > On Tue, Nov 13, 2018 at 04:06:21PM +0100, Philipp Zabel wrote:
> > > From: John Sheu
> > >
> > > Videobuf2 presently does not allow
On 11/14/2018 05:58 AM, Sakari Ailus wrote:
> On Tue, Nov 13, 2018 at 07:04:01PM +0800, Bing Bu Cao wrote:
>>
>> On 11/13/2018 06:31 PM, Sakari Ailus wrote:
>>> Hi Bing Bu,
>>>
>>> On Mon, Nov 12, 2018 at 12:31:16PM +0800, Bing Bu Cao wrote:
On 11/09/2018 06:09 PM, Sakari Ailus wrote:
Hi Jacopo,
On Wed, Nov 14, 2018 at 01:25:11AM +0100, jacopo mondi wrote:
> On Mon, Oct 29, 2018 at 03:22:54PM -0700, Yong Zhi wrote:
> > Hi,
> >
> > This series adds support for the Intel IPU3 (Image Processing Unit)
> > ImgU which is essentially a modern memory-to-memory ISP. It implements
> >
On 11/13/2018 10:42 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add support for 'tags' to struct v4l2_buffer. These can be used
> by m2m devices so userspace can set a tag for an output buffer and
> this value will then be copied to the capture buffer(s).
>
> This tag can be used to refer
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Wed Nov 14 05:00:11 CET 2018
media-tree git hash:fbe57dde7126d1b2712ab5ea93fb9d15f89de708
media_build
49 matches
Mail list logo
