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 n
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
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 ++
.../staging/media/sunxi/cedrus/c
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
b/drivers/media/v4l2-core/v4l2-ioctl.
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 H
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
---
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 capture
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 a/Documentation/medi
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 +++
include/m
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
b/drivers/media/platform/vicodec/vicodec-cor
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.
Sig
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 t
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 |
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 Ai
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 framera
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. A
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
in
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 insertions(
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 1b295d07aa15.
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
---
dr
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
---
drivers
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 effect:
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 --gi
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 a/drive
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 ap
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:
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 vb2_mm
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 two
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 fil
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 possible
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 VIDIOC
Sorry, that should have said [PATCH v2].
regards
Philipp
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
>
> 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
> > accord
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, 2
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
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:
> > >
> > >> H
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 V4L2_MEMORY
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
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 proc
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 VIDIOC_REQBUFS
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 git
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:
>
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 t
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
> > ra
Hi Malathi,
On 11/13/18 9:28 AM, mgot...@codeaurora.org wrote:
> On 2018-11-12 18:04, Stanimir Varbanov wrote:
>> Hi Tomasz,
>>
>> On 10/23/2018 05:50 AM, Tomasz Figa wrote:
>>> Hi Malathi,
>>>
>>> On Tue, Oct 9, 2018 at 4:58 PM Malathi Gottam
>>> wrote:
For lower resolutions, incase of
The older CSI drivers have camera capture interface different from the one
in the newer ones.
This IP is pretty simple. Some variants (one controller out of two
instances on some SoCs) have an ISP embedded, but there's no code that make
use of it, so we ignored that part for now.
Signed-off-by: M
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 98 +-
1 file changed, 98 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 70dfc4ac0bb5..18dbff9f1ce9 100644
--- a/arch/arm/boo
The CSI controller embedded in the A20 can be supported by our new driver.
Let's add it to our DT.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun7i-a20.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.d
Hi,
Here is a series introducing the support for the A10 (and SoCs of the same
generation) CMOS Sensor Interface (called CSI, not to be confused with
MIPI-CSI, which isn't support by that IP).
That interface is pretty straightforward, but the driver has a few issues
that I wanted to bring up:
The Makefile and Kconfig for the sun6i CSI driver are included in the main
Makefile / KConfig file. Since we're going to add a new CSI driver for an
older chip, and the Cedrus driver eventually, it makes more sense to put
those in our directory.
Signed-off-by: Maxime Ripard
---
drivers/media/pla
The Allwinner A10 CMOS Sensor Interface is a camera capture interface also
used in later (A10s, A13, A20, R8 and GR8) SoCs.
On some SoCs, like the A10, there's multiple instances of that controller,
with one instance supporting more channels and having an ISP.
Signed-off-by: Maxime Ripard
---
D
Hi Maxime,
On Tue, Nov 13, 2018 at 09:24:13AM +0100, Maxime Ripard wrote:
> The Allwinner A10 CMOS Sensor Interface is a camera capture interface also
> used in later (A10s, A13, A20, R8 and GR8) SoCs.
>
> On some SoCs, like the A10, there's multiple instances of that controller,
> with one insta
Hi Maxime,
On Tue, Nov 13, 2018 at 09:24:15AM +0100, Maxime Ripard wrote:
> The older CSI drivers have camera capture interface different from the one
> in the newer ones.
>
> This IP is pretty simple. Some variants (one controller out of two
> instances on some SoCs) have an ISP embedded, but th
Hi Rob, my responses inline.
On 24-Oct-18 18:36, Rob Herring wrote:
> On Fri, Oct 19, 2018 at 02:52:23PM +0200, Luis Oliveira wrote:
>> Add device-tree bindings documentation for SNPS DesignWare MIPI D-PHY in
>> RX mode.
>>
>> Signed-off-by: Luis Oliveira
>> ---
>> Changelog
>> v2-V3
>> - removed
On Tue, Nov 13, 2018 at 5:12 PM Stanimir Varbanov
wrote:
>
> Hi Malathi,
>
> On 11/13/18 9:28 AM, mgot...@codeaurora.org wrote:
> > On 2018-11-12 18:04, Stanimir Varbanov wrote:
> >> Hi Tomasz,
> >>
> >> On 10/23/2018 05:50 AM, Tomasz Figa wrote:
> >>> Hi Malathi,
> >>>
> >>> On Tue, Oct 9, 2018 a
Hi Rob, my responses inline.
On 24-Oct-18 18:36, Rob Herring wrote:
> On Fri, Oct 19, 2018 at 02:52:23PM +0200, Luis Oliveira wrote:
>> Add device-tree bindings documentation for SNPS DesignWare MIPI D-PHY in
>> RX mode.
>>
>> Signed-off-by: Luis Oliveira
>> ---
>> Changelog
>> v2-V3
>> - removed
The last buffer is often signaled by an empty buffer with the
V4L2_BUF_FLAG_LAST flag set. Such buffers were returned with the
bytesused field set to the full size of the OPB, which leads
user-space to believe that the buffer actually contains useful data. Fix
this by passing the number of bytes re
On Mon, Nov 12, 2018 at 9:20 PM Stanimir Varbanov
wrote:
>
> Hi Alex,
>
> On 11/12/18 10:12 AM, Alexandre Courbot wrote:
> > Hi Stan,
> >
> > On Thu, Nov 8, 2018 at 7:16 PM Stanimir Varbanov
> > wrote:
> >>
> >> Hi,
> >>
> >> On 9/29/18 3:00 PM, Srinu Gorle wrote:
> >>> - In video decoder session
Hi Dave,
Apologies for the delay.
On Fri, Sep 21, 2018 at 02:46:23PM +0100, Dave Stevenson wrote:
> Hi Sakari
>
> On Fri, 21 Sep 2018 at 13:03, Sakari Ailus wrote:
> >
> > Hi Laurent,
> >
> > On Fri, Sep 21, 2018 at 01:01:09PM +0300, Laurent Pinchart wrote:
> > ...
> > > > There is also the odd
On 24-Oct-18 18:40, Rob Herring wrote:
> On Fri, Oct 19, 2018 at 02:52:25PM +0200, Luis Oliveira wrote:
>> Add bindings for Synopsys DesignWare MIPI CSI-2 host.
>>
>> Signed-off-by: Luis Oliveira
>> ---
>> Changelog
>> v2-V3
>> - removed IPI settings
>>
>> .../devicetree/bindings/media/snps,dw
On 24-Oct-18 18:41, Rob Herring wrote:
> On Fri, Oct 19, 2018 at 02:52:25PM +0200, Luis Oliveira wrote:
>> Add bindings for Synopsys DesignWare MIPI CSI-2 host.
>
> Also, drop "Documentation: " from the subject. All bindings are
> documentation and the preferred prefix is 'dt-bindings: : '.
>
Hi Myungho,
On 2018-11-12 01:49, Myungho Jung wrote:
> The mutex that is held from vb2_fop_read() can be unlocked while waiting
> for a buffer if the queue is streaming and blocking. Meanwhile, fileio
> can be released. So, it should return an error if the fileio address is
> changed.
>
> Signed-o
Hi Maxime,
On Tue, Nov 13, 2018 at 09:24:13AM +0100, Maxime Ripard wrote:
> The Allwinner A10 CMOS Sensor Interface is a camera capture interface also
...
> +Optional properties:
> + - allwinner,csi-channels: Number of channels available in the CSI
> +controller. If no
Hi Tomasz,
On 11/13/18 11:13 AM, Tomasz Figa wrote:
> On Tue, Nov 13, 2018 at 5:12 PM Stanimir Varbanov
> wrote:
>>
>> Hi Malathi,
>>
>> On 11/13/18 9:28 AM, mgot...@codeaurora.org wrote:
>>> On 2018-11-12 18:04, Stanimir Varbanov wrote:
Hi Tomasz,
On 10/23/2018 05:50 AM, Tomasz Fi
On 11/13/18 11:27, Marek Szyprowski wrote:
> Hi Myungho,
>
> On 2018-11-12 01:49, Myungho Jung wrote:
>> The mutex that is held from vb2_fop_read() can be unlocked while waiting
>> for a buffer if the queue is streaming and blocking. Meanwhile, fileio
>> can be released. So, it should return an er
Hi Maxime,
A quick code review:
On 11/13/18 09:24, Maxime Ripard wrote:
> The older CSI drivers have camera capture interface different from the one
> in the newer ones.
>
> This IP is pretty simple. Some variants (one controller out of two
> instances on some SoCs) have an ISP embedded, but the
On 11/13/18 09:24, Maxime Ripard wrote:
> Hi,
>
> Here is a series introducing the support for the A10 (and SoCs of the same
> generation) CMOS Sensor Interface (called CSI, not to be confused with
> MIPI-CSI, which isn't support by that IP).
>
> That interface is pretty straightforward, but the
On Tue, Nov 13, 2018 at 6:25 AM Maxime Ripard wrote:
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
> @@ -0,0 +1,275 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
According to Documentation/process/license-rules.rst this should be:
+// SPDX-License-Identifier: G
Hi Yong,
On Tue, Oct 30, 2018 at 04:09:48PM +0800, Yong Deng wrote:
> I can't make v4l2-compliance always happy.
> The V3s CSI support many pixformats. But they are not always available.
> It's dependent on the input bus format (MEDIA_BUS_FMT_*).
> Example:
> V4L2_PIX_FMT_SBGGR8: MEDIA_BUS_FMT_SB
On 11/13/18 13:48, Fabio Estevam wrote:
> On Tue, Nov 13, 2018 at 6:25 AM Maxime Ripard
> wrote:
>
>> --- /dev/null
>> +++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
>> @@ -0,0 +1,275 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>
> According to Documentation/process/license-ru
Hi Hans,
On Tue, Nov 13, 2018 at 01:30:49PM +0100, Hans Verkuil wrote:
> On 11/13/18 09:24, Maxime Ripard wrote:
> > Hi,
> >
> > Here is a series introducing the support for the A10 (and SoCs of the same
> > generation) CMOS Sensor Interface (called CSI, not to be confused with
> > MIPI-CSI, whic
On 11/13/18 14:52, Maxime Ripard wrote:
> Hi Hans,
>
> On Tue, Nov 13, 2018 at 01:30:49PM +0100, Hans Verkuil wrote:
>> On 11/13/18 09:24, Maxime Ripard wrote:
>>> Hi,
>>>
>>> Here is a series introducing the support for the A10 (and SoCs of the same
>>> generation) CMOS Sensor Interface (called C
When streaming is starting ask the sensor for its skip frames value.
Max supported frame skip is 29 frames, so clip it if it is higher.
Signed-off-by: Todor Tomov
---
drivers/media/platform/qcom/camss/camss-vfe.c | 23 ++-
drivers/media/platform/qcom/camss/camss.c | 2 +-
syzbot has found a reproducer for the following crash on:
HEAD commit:ccda4af0f4b9 Linux 4.20-rc2
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1779cb0b40
kernel config: https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
dashboard link: https:
Hi Hans,
On Tue, Nov 13, 2018 at 11:37 AM Hans Verkuil wrote:
>
> On 11/13/18 13:48, Fabio Estevam wrote:
> > On Tue, Nov 13, 2018 at 6:25 AM Maxime Ripard
> > wrote:
> >
> >> --- /dev/null
> >> +++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
> >> @@ -0,0 +1,275 @@
> >> +// SPDX-Licens
Hello,
On Tue, 13 Nov 2018 12:13:09 -0200, Fabio Estevam wrote:
> > Actually, LICENSES/preferred/GPL-2.0 has GPL-2.0-or-later
> > as a valid license:
> >
> > Valid-License-Identifier: GPL-2.0-or-later
> >
> > Personally I very much prefer GPL-2.0-or-later since I think it is
> > much clearer.
>
On Tue, 2018-11-13 at 13:24 +0100, Hans Verkuil wrote:
> On 11/13/18 09:24, Maxime Ripard wrote:
> > The older CSI drivers have camera capture interface different from the one
> > in the newer ones.
[]
> > diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.h
> > b/drivers/media/platform
On 11/13/18 16:19, Joe Perches wrote:
> On Tue, 2018-11-13 at 13:24 +0100, Hans Verkuil wrote:
>> On 11/13/18 09:24, Maxime Ripard wrote:
>>> The older CSI drivers have camera capture interface different from the one
>>> in the newer ones.
> []
>>> diff --git a/drivers/media/platform/sunxi/sun4i-cs
On Tue, Nov 13, 2018 at 03:01:45PM +0100, Hans Verkuil wrote:
> On 11/13/18 14:52, Maxime Ripard wrote:
> > Hi Hans,
> >
> > On Tue, Nov 13, 2018 at 01:30:49PM +0100, Hans Verkuil wrote:
> >> On 11/13/18 09:24, Maxime Ripard wrote:
> >>> Hi,
> >>>
> >>> Here is a series introducing the support for
On 11/13/18 16:52, Maxime Ripard wrote:
> On Tue, Nov 13, 2018 at 03:01:45PM +0100, Hans Verkuil wrote:
>> On 11/13/18 14:52, Maxime Ripard wrote:
>>> Hi Hans,
>>>
>>> On Tue, Nov 13, 2018 at 01:30:49PM +0100, Hans Verkuil wrote:
On 11/13/18 09:24, Maxime Ripard wrote:
> Hi,
>
> He
On 09.11.2018 17:32, Hans Verkuil wrote:
> On 11/08/18 12:02, Colin King wrote:
>> From: Colin Ian King
>>
>> The frame.flags & FLAG_B_FRAME is promoted to a long unsigned because
>> of the use of the BIT() macro when defining FLAG_B_FRAME and causing a
>> build warning. Fix this by using the %lu
Hello,
On Tue, 13 Nov 2018 17:00:25 +0100, Hans Verkuil wrote:
> Weird, if I build directly from that tarball, then v4l2-compliance should say:
>
> v4l2-compliance SHA: not available, 64 bits
>
> So that's what I expect to see from buildroot as well.
Indeed, that's strange, I see that the v4l2
On 13.11.2018 19:52, Dmitry Osipenko wrote:
> On 09.11.2018 17:32, Hans Verkuil wrote:
>> On 11/08/18 12:02, Colin King wrote:
>>> From: Colin Ian King
>>>
>>> The frame.flags & FLAG_B_FRAME is promoted to a long unsigned because
>>> of the use of the BIT() macro when defining FLAG_B_FRAME and cau
On 11/13/2018 05:55 PM, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 13 Nov 2018 17:00:25 +0100, Hans Verkuil wrote:
>
>> Weird, if I build directly from that tarball, then v4l2-compliance should
>> say:
>>
>> v4l2-compliance SHA: not available, 64 bits
>>
>> So that's what I expect to see from
On Tue, Nov 13, 2018 at 12:56:18PM +0100, Hans Verkuil wrote:
> On 11/13/18 11:27, Marek Szyprowski wrote:
> > Hi Myungho,
> >
> > On 2018-11-12 01:49, Myungho Jung wrote:
> >> The mutex that is held from vb2_fop_read() can be unlocked while waiting
> >> for a buffer if the queue is streaming and
Hi Kieran, All,
sorry for joining this late... See below my considerations.
On 02/11/18 16:47, Kieran Bingham wrote:
> From: Laurent Pinchart
>
> The MAX9286 deserializes video data received on up to 4 Gigabit
> Multimedia Serial Links (GMSL) and outputs them on a CSI-2 port using up
> to 4 dat
Hi Kieran, All,
below a few minor questions, and a big one at the bottom.
On 02/11/18 16:47, Kieran Bingham wrote:
> From: Kieran Bingham
>
> The MAX9286 is a 4-channel GMSL deserializer with coax or STP input and
> CSI-2 output. The device supports multicamera streaming applications,
> and fea
Hi Luca,
On 13/11/2018 14:42, Luca Ceresoli wrote:
> Hi Kieran, All,
>
> sorry for joining this late... See below my considerations.
I'd say you're on time - not late,
Thanks for joining :)
>
> On 02/11/18 16:47, Kieran Bingham wrote:
>> From: Laurent Pinchart
>>
>> The MAX9286 deserializes
Hi Luca,
Thank you for your review,
On 13/11/2018 14:49, Luca Ceresoli wrote:
> Hi Kieran, All,
>
> below a few minor questions, and a big one at the bottom.
>
> On 02/11/18 16:47, Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> The MAX9286 is a 4-channel GMSL deserializer with coax or STP
On Tue, Nov 13, 2018 at 4:24 PM Maxime Ripard wrote:
>
> Hi,
>
> Here is a series introducing the support for the A10 (and SoCs of the same
> generation) CMOS Sensor Interface (called CSI, not to be confused with
> MIPI-CSI, which isn't support by that IP).
>
> That interface is pretty straightfor
On Tue, Nov 13, 2018 at 7:46 PM Stanimir Varbanov
wrote:
>
> Hi Tomasz,
>
> On 11/13/18 11:13 AM, Tomasz Figa wrote:
> > On Tue, Nov 13, 2018 at 5:12 PM Stanimir Varbanov
> > wrote:
> >>
> >> Hi Malathi,
> >>
> >> On 11/13/18 9:28 AM, mgot...@codeaurora.org wrote:
> >>> On 2018-11-12 18:04, Stani
On Wed, Nov 14, 2018 at 3:54 AM Nicolas Dufresne wrote:
>
>
>
> Le mar. 13 nov. 2018 04 h 30, Alexandre Courbot a
> écrit :
>>
>> The last buffer is often signaled by an empty buffer with the
>> V4L2_BUF_FLAG_LAST flag set. Such buffers were returned with the
>> bytesused field set to the full s
Hello,
syzbot found the following crash on:
HEAD commit:ccda4af0f4b9 Linux 4.20-rc2
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16f9cb0b40
kernel config: https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
dashboard link: https://syzkaller.a
98 matches
Mail list logo
