On 02/04/2015 05:06 PM, Jurgen Kramer wrote:
Hi Hans,
On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote:
Raimonds and Jurgen,
Can you both test with the following patch applied to the driver:
Unfortunately the mpeg error is not (completely) gone:
OK, I suspected that might be the
There must be used 'min_t', not 'max_t' for calculating the divider.
Signed-off-by: Enrico Scholz enrico.sch...@sigma-chemnitz.de
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/mt9p031.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, 2015-02-04 at 17:19 +0100, Hans Verkuil wrote:
On 02/04/2015 05:06 PM, Jurgen Kramer wrote:
Hi Hans,
On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote:
Raimonds and Jurgen,
Can you both test with the following patch applied to the driver:
Unfortunately the mpeg error
Gets a handle to the system clock, already described in the binding
document, and calls the appropriate common clock framework functions
to mark it prepared/enabled, the common clock framework initially
enables the clock and doesn't disable it at least until the
device/driver is removed.
It's
Hi Prabhakar,
Thank you for the patch. Here's a partial review.
On Thursday 15 January 2015 23:39:23 Lad, Prabhakar wrote:
From: Benoit Parrot bpar...@ti.com
this patch adds support for omnivision's ov2659
sensor.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Lad, Prabhakar
Ok, Doron Cohen solved the problem in 5 seconds.
There are 2 mode for DVB-T, we need to force mode 4 instead of mode 0.
Thanks to Roberto for trying to solve the problem and to Olli for the
e-mail of Doron Cohen.
Regards
Francesco
2015-02-03 11:57 GMT+01:00 Olli Salonen olli.salo...@iki.fi:
On 04/02/15 16:48, Sifan Naeem wrote:
Gets a handle to the system clock, already described in the binding
document, and calls the appropriate common clock framework functions
to mark it prepared/enabled, the common clock framework initially
enables the clock and doesn't disable it at least
Laurent Pinchart laurent.pinch...@ideasonboard.com writes:
and the upper limit is '63' (value uses 6:0 register bits).
And this I don't. You can encode numbers from 0 to 127 on 7 bits.
yes; you are right (original '64' was correct because sensor allows only
dividers of a power-of-two).
-
Hi Enrico,
Thank you for the patch.
On Wednesday 04 February 2015 15:53:32 Enrico Scholz wrote:
There must be used 'min_t', not 'max_t' for calculating the divider
That I agree with.
and the upper limit is '63' (value uses 6:0 register bits).
And this I don't. You can encode numbers from 0
From: Mauro Carvalho Chehab mche...@osg.samsung.com
The cos table used at fixp-arith.h has only 8 bits of precision.
That causes problems if it is reused on other drivers.
As some media drivers require a higher precision sin/cos
implementation, replace the current implementation by one that
will
On 02/03/15 18:13, Pablo Anton wrote:
It is confusing which parts of the driver are adv7604 specific, adv7611
specific or common for both.
This patch renames any adv7604 prefixes (both for functions and defines) to
adv76xx whenever they are common.
Signed-off-by: Pablo Anton
Too bad. I will check anyway the export cost, just to check if it makes sense.
BTW, did you have the chance to look at the logs I attached, just to figure out
if something is wrong or something can be debugged at my side? I'm not expert
in V4L stuff, but I am a programmer and could test things
These patches improve the sine tone generation in the vivid SDR driver (Software
Defined Radio). The main problem in that driver was the poor sin/cos function
implementation.
This started with improvements in vivid sine tone generation. It turned out
that to improve sine tone, we needed to
From: Prashant Laddha prlad...@cisco.com
The common implementation for sin/cos in include/linux/fixp-arith.h
has been improved recently to provide higher precision.
Replacing native implementation of sin/cos in vivid sdr with common
implementation. This serves two purposes:
1. Improved
From: Prashant Laddha prlad...@cisco.com
FM (frequency modulated) signal for SDR is generated by varying the
phase, where phase variation is proportional to input signal. It is
seen that, the larger phase increments leads to discontinuities in
the signal recovered after demodulation. Reducing the
Hi Florian,
On 02/03/2015 09:45 PM, Florian Echtler wrote:
Sorry to bring this up again, but would it be acceptable to simply use
dma-contig after all? Since the GFP_DMA flag is gone, this shouldn't be
too big of an issue IMHO, and I was kind of hoping the patch could still
be part of 3.20.
On Wed, Feb 04, 2015 at 10:07:30AM +0100, Hans Verkuil wrote:
From: Mauro Carvalho Chehab mche...@osg.samsung.com
The cos table used at fixp-arith.h has only 8 bits of precision.
That causes problems if it is reused on other drivers.
As some media drivers require a higher precision sin/cos
On 04.02.2015 18:19, Hans Verkuil wrote:
On 02/04/2015 05:06 PM, Jurgen Kramer wrote:
Hi Hans,
On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote:
Raimonds and Jurgen,
Can you both test with the following patch applied to the driver:
Raimond, do you still see the AMD iommu faults with
Tested with a couple of DVBSky T982 adapters against latest media
master. No problems detected.
Moreover: even with earlier versions of the media tree (starting with
the version in witch support for DVBSky t982 was added), I never
encountered any problems.
Regards,
Tycho.
Op 04-02-15 om
Hi Laurent,
Thanks for the review.
On Wed, Feb 4, 2015 at 5:03 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Prabhakar,
Thank you for the patch. Here's a partial review.
On Thursday 15 January 2015 23:39:23 Lad, Prabhakar wrote:
From: Benoit Parrot bpar...@ti.com
this
Hi Hans,
On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote:
On 02/01/2015 02:06 PM, Raimonds Cicans wrote:
On 29.01.2015 14:12, Hans Verkuil wrote:
On 01/29/15 12:51, Raimonds Cicans wrote:
On 29.01.2015 09:33, Hans Verkuil wrote:
On 01/11/2015 10:33 AM, Raimonds Cicans wrote:
I
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: Thu Feb 5 04:00:16 CET 2015
git branch: test
git hash: 4bad5d2d25099a42e146d7b18d2b98950ed287f5
gcc
Here's my updated version of the previous patch to add raw video streaming
support to the SUR40. So far, for reasons opaque to me, dma-contig is the
only allocator that works properly. Hoping for some feedback where the issue
might be hidden; perhaps it's related to the following test failure from
On 04.02.2015 11:22, Hans Verkuil wrote:
On 02/04/15 11:08, Florian Echtler wrote:
On 04.02.2015 09:08, Hans Verkuil wrote:
You can also make a version with vmalloc and I'll merge that, and then
you can look more into the DMA issues. That way the driver is merged,
even if it is perhaps not
On 02/04/15 12:27, Laurent Pinchart wrote:
Hi Hans,
Thank you for the patch.
On Wednesday 04 February 2015 10:55:21 Hans Verkuil wrote:
On 02/03/15 18:13, Pablo Anton wrote:
It is confusing which parts of the driver are adv7604 specific, adv7611
specific or common for both. This patch
Hi Hans, and thanks for reviewing.
2015-02-04 10:55 GMT+01:00 Hans Verkuil hverk...@xs4all.nl:
On 02/03/15 18:13, Pablo Anton wrote:
It is confusing which parts of the driver are adv7604 specific, adv7611
specific or common for both.
This patch renames any adv7604 prefixes (both for
On Tue, Feb 03, 2015 at 08:34:01PM +0200, Antti Palosaari wrote:
On 02/03/2015 07:53 PM, Mauro Carvalho Chehab wrote:
If latter a better way to lock the I2C mux appears, we can reverse
this change.
More I am worried about next patch in a serie, which converts all that to
regmap API... Same
Hi Laurent,
Am Dienstag, den 03.02.2015, 13:20 +0200 schrieb Laurent Pinchart:
On Monday 02 February 2015 15:00:51 Hans Verkuil wrote:
On 01/22/2015 12:28 PM, Philipp Zabel wrote:
If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return
Understood, thank you. I will consider donating it to you after my new HVR-2200
seems stable enough.
BR
Mensaje original
De : st...@kernellabs.com
Fecha : 04/02/2015 - 12:51 (GMT)
Para : dcr...@telefonica.net
CC : linux-media@vger.kernel.org
Asunto : Re: Re: [possible BUG, cx23885]
Hi Florian,
On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote:
On 04.02.2015 11:22, Hans Verkuil wrote:
On 02/04/15 11:08, Florian Echtler wrote:
On 04.02.2015 09:08, Hans Verkuil wrote:
You can also make a version with vmalloc and I'll merge that, and then
you can look more
To my knowledge the driver is now stable. There is still the occasional
kernel message that shouldn't be there which I am trying to track down,
but the driver crashes due to a vb2 race condition have been fixed.
Thank you for the clarification Hans, and thanks for taking care of VB2 etc.
--
Hi Jean-Michel and others,
On Thu, 29 Jan 2015, Jean-Michel Hautbois wrote:
First of all, this subject puzzles me... What means WmT ??
That's just my initialism, to differentiate my work from that of
colleagues'. I'll submit without those in due course (and SOBs).
- fmt =
-next is -next-20150204)
drivers/media/usb/cx231xx/cx231xx-core.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-core.c
b/drivers/media/usb/cx231xx/cx231xx-core.c
index 4a3f28c..832ba99 100644
--- a/drivers/media/usb/cx231xx
Fixing a few checkpatch errors of type: space required after that ','
Signed-off-by: Luis de Bethencourt luis...@samsung.com
---
drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dvb-usb-dvb.c
The bits are the same, but register is 0xf4 on ADV7611 instead of 0xfc.
When reading back the value in log_status, differentiate both.
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
v2: Use adv7604_chip_info to get register instead of testing the chip ID
At the V4L2 codec API session during ELC-E 2014, we agreed that for the decoder
draining flow, after a V4L2_DEC_CMD_STOP decoder command was issued, the last
decoded buffer should get dequeued with a V4L2_BUF_FLAG_LAST set. After that,
poll should immediately return and all following VIDIOC_DQBUF
From: Peter Seiderer ps.rep...@gmx.net
This v4l2_buffer flag can be used by drivers to mark a capture buffer
as the last generated buffer, for example after a V4L2_DEC_CMD_STOP
command was issued.
Signed-off-by: Peter Seiderer ps.rep...@gmx.net
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Setting the last buffer flag causes the videobuf2 core to return -EPIPE from
DQBUF calls on the capture queue after the last buffer is dequeued.
This patch also fixes the EOS event to conform to the specification. It now is
sent right after the last buffer has been decoded instead of when the last
Setting the last buffer flag causes the videobuf2 core to return -EPIPE from
DQBUF calls on the capture queue after the last buffer is dequeued.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 +
1 file changed, 1 insertion(+)
diff --git
This patch mentions mem2mem codecs and the mem2mem draining flow signals in the
VIDIOC_DECODER_CMD V4L2_DEC_CMD_STOP and VIDIOC_ENCODER_CMD V4L2_ENC_CMD_STOP
documentation.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 6 +-
If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST.
To reenable dequeuing on the capture queue, the
Hello everyone,
On 04.02.2015 12:39, Hans Verkuil wrote:
On 02/04/15 12:34, Laurent Pinchart wrote:
On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote:
That's what I assumed, however, I'm running into the same problem as
with dma-sg when I switch to vmalloc...?
I don't expect
Hi Hans,
On Wednesday 04 February 2015 12:39:30 Hans Verkuil wrote:
On 02/04/15 12:34, Laurent Pinchart wrote:
On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote:
On 04.02.2015 11:22, Hans Verkuil wrote:
On 02/04/15 11:08, Florian Echtler wrote:
On 04.02.2015 09:08, Hans
Hi Florian,
On Wednesday 04 February 2015 14:21:47 Florian Echtler wrote:
On 04.02.2015 12:39, Hans Verkuil wrote:
On 02/04/15 12:34, Laurent Pinchart wrote:
On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote:
That's what I assumed, however, I'm running into the same problem as
Hi Hans,
On Wednesday 04 February 2015 12:35:34 Hans Verkuil wrote:
On 02/04/15 12:27, Laurent Pinchart wrote:
On Wednesday 04 February 2015 10:55:21 Hans Verkuil wrote:
On 02/03/15 18:13, Pablo Anton wrote:
It is confusing which parts of the driver are adv7604 specific, adv7611
specific
Hi Rob,
Thanks for the review.
On Wed, Feb 4, 2015 at 2:55 PM, Rob Herring robherri...@gmail.com wrote:
On Thu, Jan 15, 2015 at 5:39 PM, Lad, Prabhakar
prabhakar.cse...@gmail.com wrote:
From: Benoit Parrot bpar...@ti.com
this patch adds support for omnivision's ov2659
sensor.
There must be used 'min_t', not 'max_t' for calculating the divider and
the upper limit is '63' (value uses 6:0 register bits).
Signed-off-by: Enrico Scholz enrico.sch...@sigma-chemnitz.de
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/mt9p031.c | 2 +-
1 file
On 02/04/2015 09:54 AM, Hans Verkuil wrote:
On 02/03/2015 08:32 PM, Steven Toth wrote:
While I am the maintainer of the cx23885 driver, its currently
undergoing a significant amount of churn related to Han's recent VB2
and other changes. I consider the current driver broken until the
feedback
On 02/04/15 15:14, William Towle wrote:
Hi Jean-Michel and others,
On Thu, 29 Jan 2015, Jean-Michel Hautbois wrote:
First of all, this subject puzzles me... What means WmT ??
That's just my initialism, to differentiate my work from that of
colleagues'. I'll submit without those in due
Hi Mauro and Philipp,
On Mon, Feb 02, 2015 at 01:24:21PM -0200, Mauro Carvalho Chehab wrote:
Em Mon, 02 Feb 2015 16:21:00 +0100
Philipp Zabel p.za...@pengutronix.de escreveu:
Am Montag, den 02.02.2015, 16:08 +0100 schrieb Hans Verkuil:
On 12/03/2014 02:53 PM, Philipp Zabel wrote:
On Thu, Jan 15, 2015 at 5:39 PM, Lad, Prabhakar
prabhakar.cse...@gmail.com wrote:
From: Benoit Parrot bpar...@ti.com
this patch adds support for omnivision's ov2659
sensor.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
[...]
Hi Sifan,
On 03/02/15 17:30, Sifan Naeem wrote:
Gets a handle to the system clock, already described in the binding
document, and calls the appropriate common clock
framework functions to mark it prepared/enabled, the common clock
framework initially enables the clock and doesn't disable it
Hi Hans,
Thank you for the patch.
On Wednesday 04 February 2015 10:55:21 Hans Verkuil wrote:
On 02/03/15 18:13, Pablo Anton wrote:
It is confusing which parts of the driver are adv7604 specific, adv7611
specific or common for both. This patch renames any adv7604 prefixes
(both for
On 02/04/15 12:34, Laurent Pinchart wrote:
Hi Florian,
On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote:
On 04.02.2015 11:22, Hans Verkuil wrote:
On 02/04/15 11:08, Florian Echtler wrote:
On 04.02.2015 09:08, Hans Verkuil wrote:
You can also make a version with vmalloc and I'll
I didn't see anything obvious in the logs :(
Please don't send the hardware to the US unless you're willing to
leave it with me permanently, I don't work on hardware for free if I
don't get to keep the final hardware. I hope you understand.
- Steve
--
Steven Toth - Kernel Labs
Hello Hans,
On 04.02.2015 09:08, Hans Verkuil wrote:
I remain very skeptical about the use of dma-contig (or dma-sg for that
matter). Have you tried using vmalloc and check if the USB core isn't
automatically using DMA transfers for that?
Basically I would like to see proof that vmalloc is
On 02/04/15 11:08, Florian Echtler wrote:
Hello Hans,
On 04.02.2015 09:08, Hans Verkuil wrote:
I remain very skeptical about the use of dma-contig (or dma-sg for that
matter). Have you tried using vmalloc and check if the USB core isn't
automatically using DMA transfers for that?
Rob,
On Wed, Feb 4, 2015 at 12:55 PM, Rob Herring robherri...@gmail.com wrote:
I'm surprised there are not already compatible strings with
OmniVision. There are some examples using omnivision, but no dts
files and examples don't count.
The stock ticker is ovti, so please use that.
That's
This patch adds raw video support for the Samsung SUR40, now finally using
videobuf2-dma-sg and the usb_sg_init/_wait helper functions. Further comments
regarding buffer handling are invited, as v4l2-compliance -s still fails the
USERPTR test.
Signed-off-by: Florian Echtler f...@butterbrot.org
On Wed, Feb 4, 2015 at 3:23 PM, Fabio Estevam feste...@gmail.com wrote:
Rob,
On Wed, Feb 4, 2015 at 12:55 PM, Rob Herring robherri...@gmail.com wrote:
I'm surprised there are not already compatible strings with
OmniVision. There are some examples using omnivision, but no dts
files and
The slab for vm_area_struct which is vm_area_cachep is already prepared
for the general use. Instead of kmalloc() for the vma copy for userptr,
allocation from vm_area_cachep is more beneficial.
CC: Mauro Carvalho Chehab mche...@osg.samsung.com
CC: Hans Verkuil hans.verk...@cisco.com
CC: Laurent
61 matches
Mail list logo
