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
CC: Hans Verkuil
CC: Laurent Pinchart
Signed-off-by: Cho KyongHo
---
dri
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 versio
Hi Laurent,
Thanks for the review.
On Wed, Feb 4, 2015 at 5:03 PM, Laurent Pinchart
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
>>
>> this patch adds support for omnivision's o
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 16:14
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 thi
On Wed, Feb 04, 2015 at 10:07:30AM +0100, Hans Verkuil wrote:
> From: Mauro Carvalho Chehab
>
> 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,
Laurent Pinchart 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).
>> -mt9p031->clk_div =
There must be used 'min_t', not 'max_t' for calculating the divider.
Signed-off-by: Enrico Scholz
Cc: Laurent Pinchart
---
drivers/media/i2c/mt9p031.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 0cabf91..43e
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
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:
> >
> > Unfortunat
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
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 :
> Well, if you suspe
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
>
> this patch adds support for omnivision's ov2659
> sensor.
>
> Signed-off-by: Benoit Parrot
> Signed-off-by: Lad, Prabhakar
> ---
> .../devicet
On Wed, Feb 4, 2015 at 9:23 AM, Fabio Estevam wrote:
> Rob,
>
> On Wed, Feb 4, 2015 at 12:55 PM, Rob Herring 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 s
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 impor
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
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
On Wed, Feb 4, 2015 at 3:23 PM, Fabio Estevam wrote:
> Rob,
>
> On Wed, Feb 4, 2015 at 12:55 PM, Rob Herring 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 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
---
drivers/input/tou
Rob,
On Wed, Feb 4, 2015 at 12:55 PM, Rob Herring 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 what I sent:
htt
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
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
Cc: Laurent Pinchart
---
drivers/media/i2c/mt9p031.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c
Hi Rob,
Thanks for the review.
On Wed, Feb 4, 2015 at 2:55 PM, Rob Herring wrote:
> On Thu, Jan 15, 2015 at 5:39 PM, Lad, Prabhakar
> wrote:
>> From: Benoit Parrot
>>
>> this patch adds support for omnivision's ov2659
>> sensor.
>>
>> Signed-off-by: Benoit Parrot
>> Signed-off-by: Lad, Prabha
On Thu, Jan 15, 2015 at 5:39 PM, Lad, Prabhakar
wrote:
> From: Benoit Parrot
>
> this patch adds support for omnivision's ov2659
> sensor.
>
> Signed-off-by: Benoit Parrot
> Signed-off-by: Lad, Prabhakar
> ---
[...]
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Doc
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 escreveu:
>
> > Am Montag, den 02.02.2015, 16:08 +0100 schrieb Hans Verkuil:
> > > On 12/03/2014 02:53 PM, Philipp Zabel wrote:
> > > > This patch add
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 thos
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
>
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
---
v2: Use adv7604_chip_info to get register instead of testing the chip ID
drivers/media/i2c/adv7604.c | 5 -
1 file c
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 = v
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 pro
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:0
Fixing a few checkpatch errors of type: space required after that ','
Signed-off-by: Luis de Bethencourt
---
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
b/drivers/media/usb/
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
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
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 s
From: Peter Seiderer
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
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Added documentation
---
Docume
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
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/s5
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
---
Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 6 +-
Documentation/DocBook/m
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 driver
-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/cx231xx-core.c
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, cx2388
> 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.
--
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
http://www.kernel
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
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 retu
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. T
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 ca
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 f
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 per
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...
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?
>>
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 i
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
Hi Hans, and thanks for reviewing.
2015-02-04 10:55 GMT+01:00 Hans Verkuil :
> 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 define
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
> Signe
From: Prashant Laddha
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 accuracy: the native implem
From: Prashant Laddha
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 extent of phase
va
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 improve
From: Mauro Carvalho Chehab
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 provide 32 bits precisi
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
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
62 matches
Mail list logo
