On 4/8/19 8:26 PM, Sakari Ailus wrote:
> Hi Bingbu,
>
> Thanks for the patch.
>
> On Fri, Mar 22, 2019 at 07:14:45PM +0800, bingbu@intel.com wrote:
>> From: Bingbu Cao
>>
>> Current ImgU driver processes and releases the parameter buffer
>> immediately after queued from user. This does no
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: Tue Apr 9 05:00:14 CEST 2019
media-tree git hash:1c3ec30bb23023d738b538e64ac3028902d53692
media_build gi
Hi Sean,
On 08/04/2019 15.55, Sean Young wrote:
> On Mon, Apr 08, 2019 at 01:14:08PM -0500, Brad Love wrote:
>> On 05/04/2019 05.29, Sean Young wrote:
>>> On Sat, Dec 29, 2018 at 11:51:16AM -0600, Brad Love wrote:
Some software reports no signal found on a frequency due to immediately
c
On Mon, Apr 08, 2019 at 01:14:08PM -0500, Brad Love wrote:
>
> On 05/04/2019 05.29, Sean Young wrote:
> > On Sat, Dec 29, 2018 at 11:51:16AM -0600, Brad Love wrote:
> >> Some software reports no signal found on a frequency due to immediately
> >> checking for lock as soon as set_params returns. Th
Hi Brad,
On Mon, Apr 08, 2019 at 01:01:43PM -0500, Brad Love wrote:
>
> On 05/04/2019 10.29, Sean Young wrote:
> > On Fri, Apr 05, 2019 at 04:24:24PM +0100, Sean Young wrote:
> >> On Wed, Feb 27, 2019 at 01:16:06PM -0600, Brad Love wrote:
> > > +pr_info("%s(): resetting 160xxx de
Hello,
It seems that commit 6e21f6f34c1d7c3a7a059062e1ddd9705c984e2c is also
missing on 1.16 (in addition to 1.14). Otherwise the return paths are
still messed up:
ret = dvb_fe_open_fname(parms, dvb_dev->path, flags);
if (ret < 0) {
free(parms); <--- double
On 05/04/2019 05.29, Sean Young wrote:
> On Sat, Dec 29, 2018 at 11:51:16AM -0600, Brad Love wrote:
>> Some software reports no signal found on a frequency due to immediately
>> checking for lock as soon as set_params returns. This waits up 40ms for
>> tuning operation, then from 30-150ms (dig/an
On 05/04/2019 08.24, Sean Young wrote:
> On Wed, Feb 27, 2019 at 12:27:39PM -0600, Brad Love wrote:
>> Include set_analog_params, get_frequency, and get_bandwidth.
>>
>> Tested with NTSC and PAL standards via ch3/4 generator. Other standards
>> are included, but are untested due to lack of genera
On 05/04/2019 05.00, Sean Young wrote:
> On Wed, Feb 27, 2019 at 01:16:04PM -0600, Brad Love wrote:
>> All changes are equivalent and backwards compatible.
>> All current devices have been changed to use fe[0]
>> Cleanup has been added to dvb init to support cleanup after failure.
> Just very min
On 05/04/2019 10.29, Sean Young wrote:
> On Fri, Apr 05, 2019 at 04:24:24PM +0100, Sean Young wrote:
>> On Wed, Feb 27, 2019 at 01:16:06PM -0600, Brad Love wrote:
> > + pr_info("%s(): resetting 160xxx demod\n", __func__);
>>> + /* TODO: not sure this is proper place to reset o
Em Mon, 8 Apr 2019 16:46:02 +0200
Hans Verkuil escreveu:
> On 4/8/19 4:41 PM, Philipp Zabel wrote:
> > On Mon, 2019-04-08 at 12:44 +0200, Hans Verkuil wrote (paraphrased):
> >> On 4/8/19 12:28 PM, Mauro Carvalho Chehab wrote (paraphrased):
> > [...]
> [I hate colors]
> >>> [I love co
On 4/8/19 6:10 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 8 Apr 2019 12:44:18 +0200
> Hans Verkuil escreveu:
>
>> On 4/8/19 12:28 PM, Mauro Carvalho Chehab wrote:
>>> Em Mon, 8 Apr 2019 11:05:20 +0200
>>> Hans Verkuil escreveu:
>>>
Hi Philipp,
On 4/8/19 10:45 AM, Philipp Zabel
Em Mon, 8 Apr 2019 12:44:18 +0200
Hans Verkuil escreveu:
> On 4/8/19 12:28 PM, Mauro Carvalho Chehab wrote:
> > Em Mon, 8 Apr 2019 11:05:20 +0200
> > Hans Verkuil escreveu:
> >
> >> Hi Philipp,
> >>
> >> On 4/8/19 10:45 AM, Philipp Zabel wrote:
> >>> Hi,
> >>>
> >>> not sure if anybody find
On 4/8/19 4:41 PM, Philipp Zabel wrote:
> On Mon, 2019-04-08 at 12:44 +0200, Hans Verkuil wrote (paraphrased):
>> On 4/8/19 12:28 PM, Mauro Carvalho Chehab wrote (paraphrased):
> [...]
[I hate colors]
>>> [I love colors]
>> I could live with [compromise]
>
> Sorry for opening that can of worm
On Mon, 2019-04-08 at 12:44 +0200, Hans Verkuil wrote (paraphrased):
> On 4/8/19 12:28 PM, Mauro Carvalho Chehab wrote (paraphrased):
[...]
> > > [I hate colors]
> > [I love colors]
> I could live with [compromise]
Sorry for opening that can of worms :-)
How about doing something similar to 'ls':
On Mon, Apr 08, 2019 at 01:04:00PM +0200, Hans Verkuil wrote:
> The SECO CEC driver never decremented the HDMI device refcount.
> CEC drivers only need the HDMI device pointer as a key in the
> notifier list, it never accesses the device, so there is no
> need to keep a reference.
>
> Signed-off-b
On 4/8/19 3:09 PM, Thierry Reding wrote:
> On Mon, Apr 08, 2019 at 01:03:55PM +0200, Hans Verkuil wrote:
>> Add helper function to parse the DT for the hdmi-phandle property
>> and find the corresponding struct device pointer.
>>
>> It takes care to avoid increasing the device refcount since all
>>
On Mon, Apr 08, 2019 at 01:03:55PM +0200, Hans Verkuil wrote:
> Add helper function to parse the DT for the hdmi-phandle property
> and find the corresponding struct device pointer.
>
> It takes care to avoid increasing the device refcount since all
> we need is the device pointer. This pointer is
Le lun. 8 avr. 2019 à 13:04, Hans Verkuil a écrit :
>
> The STI CEC driver increased the HDMI device refcount when
> it shouldn't. Use the new helper function to ensure that that
> doesn't happen and to simplify the driver code.
>
> Signed-off-by: Hans Verkuil
Acked-by: Benjamin Gaignard
> ---
Since levels are specified in terms of maximum values, there is no
reason to filter out lower levels than the supported maximum.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 22 --
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/
The chosen codec depends on the coded format, which is known as soon as
the S_FMT call on the coded queue. This allows to use the codec in
callbacks that may be called before start_streaming, such as buf_queue.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 28 +
The memory-to-memory stateful video decoder interface documentation
requires the decoder stop command initiating the drain sequence to have
flags set to zero.
Stop to black makes no sense as stopped memory-to-memory decoders do not
produce any frames, and stopping immediately can be achieved by sto
Add min number of buffers for capture (decoder) and output (encoder)
controls, which are required by the stateful video decoder / encoder
interface specification.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/
The error return value is not written by some firmware codecs, such as
MPEG-2 decode on CodaHx4. Clear the error return value before starting
the picture run to avoid misinterpreting unrelated values returned by
sequence initialization as error return value.
Signed-off-by: Philipp Zabel
---
driv
If VIDIOC_CREATE_BUFS is called with a sizeimage smaller than the
queue sizeimage, fail with -EINVAL instead of correcting the size
and continuing without error. This is required by v4l2-compliance.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 3 +++
1 file change
v4l2-compliance sets colorimetry on the output queue and then verifies
that querying colorimetry on the capture queue returns the same
configuration. For this to work, the encoder must allow setting context
colorimetry parameters on the output queue.
Signed-off-by: Philipp Zabel
---
drivers/medi
Let VIDIOC_ENUM_FRAMEINTERVALS return -EINVAL if userspace queries
frame intervals for unsupported frame sizes.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 33 ++-
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/media/pl
The stateful encoder API requires VIDIOC_ENUM_FRAMESIZES to be
implemented.
Allow enumeration of supported frame sizes for encoding.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 37 +++
1 file changed, 37 insertions(+)
diff --git a/drivers/med
Return -ENOTTY when userspace tries to call VIDIOC_(TRY_)ENCODER_CMD on
a decoder instance or VIDIOC_(TRY_)DECODER_CMD on an encoder instance.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
dif
Hi Bingbu,
Thanks for the patch.
On Fri, Mar 22, 2019 at 07:14:45PM +0800, bingbu@intel.com wrote:
> From: Bingbu Cao
>
> Current ImgU driver processes and releases the parameter buffer
> immediately after queued from user. This does not align with other
> image buffers which are grouped in
On 08/04/2019 13:03, Hans Verkuil wrote:
> The meson CEC driver increased the HDMI device refcount when
> it shouldn't. Use the new helper function to ensure that that
> doesn't happen and to simplify the driver code.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/platform/meson/ao-cec.c
Add helper function to parse the DT for the hdmi-phandle property
and find the corresponding struct device pointer.
It takes care to avoid increasing the device refcount since all
we need is the device pointer. This pointer is used in the
notifier list as a key, but it is never accessed by the CEC
The meson CEC driver increased the HDMI device refcount when
it shouldn't. Use the new helper function to ensure that that
doesn't happen and to simplify the driver code.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/meson/ao-cec.c | 16 +---
1 file changed, 5 insertions(+),
The Tegra CEC driver increased the HDMI device refcount when
it shouldn't. Use the new helper function to ensure that that
doesn't happen and to simplify the driver code.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/tegra-cec/tegra_cec.c | 14 --
1 file changed, 4 insertion
The CrosEC CEC driver never decremented the HDMI device refcount.
CEC drivers only need the HDMI device pointer as a key in the
notifier list, it never accesses the device, so there is no
need to keep a reference.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/cros-ec-cec/cros-ec-cec.c |
The S5P CEC driver increased the HDMI device refcount when
it shouldn't. Use the new helper function to ensure that that
doesn't happen and to simplify the driver code.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/s5p-cec/s5p_cec.c | 16 +---
1 file changed, 5 insertions(+)
Wen Yang reported that some CEC drivers incremented the refcount
of the HDMI device, but never decremented it, potentially leading
to memory leaks.
Rather than fixing each driver I decided to create a helper function
that finds the HDMI device and handles the refcounting correctly.
Two drivers (s
The SECO CEC driver never decremented the HDMI device refcount.
CEC drivers only need the HDMI device pointer as a key in the
notifier list, it never accesses the device, so there is no
need to keep a reference.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/seco-cec/seco-cec.c | 1 +
1
The STI CEC driver increased the HDMI device refcount when
it shouldn't. Use the new helper function to ensure that that
doesn't happen and to simplify the driver code.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/sti/cec/stih-cec.c | 21 +++--
1 file changed, 7 inserti
Hello everyone,
---8<-
I've changed the original report according to the comments received on the
list so there's nothing major new here; just a small update.
Mauro: I've made the changes discussed over e-mail. Could you split off
the latter part of the report into a separate arti
On 4/8/19 12:28 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 8 Apr 2019 11:05:20 +0200
> Hans Verkuil escreveu:
>
>> Hi Philipp,
>>
>> On 4/8/19 10:45 AM, Philipp Zabel wrote:
>>> Hi,
>>>
>>> not sure if anybody finds this as useful as I do to spot compliance
>>> failures and warnings in a sea of O
Em Mon, 8 Apr 2019 11:05:20 +0200
Hans Verkuil escreveu:
> Hi Philipp,
>
> On 4/8/19 10:45 AM, Philipp Zabel wrote:
> > Hi,
> >
> > not sure if anybody finds this as useful as I do to spot compliance
> > failures and warnings in a sea of OKs more easily, but this patch adds
> > some color escap
The ctrl_check_input() function is called from pvr2_ctrl_range_check().
It's supposed to validate user supplied input and return true or false
depending on whether the input is valid or not. The problem is that
negative shifts or shifts greater than 31 are undefined in C. In
practice with GCC the
Hi Philipp,
On 4/8/19 10:45 AM, Philipp Zabel wrote:
> Hi,
>
> not sure if anybody finds this as useful as I do to spot compliance
> failures and warnings in a sea of OKs more easily, but this patch adds
> some color escape codes to the output of v4l2-compliance. It marks "OK"
> green, "warn" bol
On Tue, Mar 26, 2019 at 1:33 AM Hans Verkuil wrote:
>
> On 3/25/19 2:12 PM, Hans Verkuil wrote:
> > Another comment found while creating compliance tests:
> >
> > On 1/24/19 11:04 AM, Tomasz Figa wrote:
> >> +Drain
> >> +=
> >> +
> >> +To ensure that all the queued ``OUTPUT`` buffers have been
Hi,
not sure if anybody finds this as useful as I do to spot compliance
failures and warnings in a sea of OKs more easily, but this patch adds
some color escape codes to the output of v4l2-compliance. It marks "OK"
green, "warn" bold, and "fail" / "FAIL" bright red if the output is a
terminal. I w
If the output is a terminal, use color codes to mark OK, warn, and
FAIL messages with green, bold, and bright red accents, respectively.
Signed-off-by: Philipp Zabel
---
utils/v4l2-compliance/v4l2-compliance.cpp | 11 ---
utils/v4l2-compliance/v4l2-compliance.h | 15 ---
2
Use the warn() macro in warn_once() instead of duplicating its contents.
Signed-off-by: Philipp Zabel
---
utils/v4l2-compliance/v4l2-compliance.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/utils/v4l2-compliance/v4l2-compliance.h
b/utils/v4l2-compliance/v4l2-compli
48 matches
Mail list logo
