On Mon June 4 2012 23:58:07 Hans Verkuil wrote:
> Hi Rebecca,
>
> On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote:
> > I have a system where the data is planar, but the kernel drivers
> > expect to get one allocation with offsets for the planes. I can't
> > figure out how to do that with
It probably is a fixed offset, but all the information describing it
is in userspace... In my experience, it's always almost one of the
pre-defined formats, but then there's some extra padding, weird
alignment etc. I'm trying to convert code that used userptr, but
where the planes were offsets in
Hi Rebecca,
On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote:
> I have a system where the data is planar, but the kernel drivers
> expect to get one allocation with offsets for the planes. I can't
> figure out how to do that with the current dma_buf implementation. I
> thought I could pas
On Mon June 4 2012 21:50:46 Ezequiel Garcia wrote:
> On Mon, Jun 4, 2012 at 5:47 AM, Hans Verkuil wrote:
> >
> >> Would you care to explain me this change in your patch?
> >> + set_bit(V4L2_FL_USE_FH_PRIO, &dev->vdev.flags);
> >
> > See Documentation/video4linux/v4l2-framework.txt:
> >
> > "
can you check expected size vs dmabuf->size - offset?
On Tue, Jun 5, 2012 at 4:46 AM, Rebecca Schultz Zavin
wrote:
> I'm trying to do it in my drivier, but I'm not sure how to make it
> safe since there is no way to tell the kernel the total size of the
> buffer. From what I can tell, I can't sa
Also the data_offset field (and bytes_used field) only get copied
from the v4l2_buffer into the vb2_buffer struct if the buffer is an
output buffer.
Rebecca
On Mon, Jun 4, 2012 at 1:46 PM, Rebecca Schultz Zavin
wrote:
> I'm trying to do it in my drivier, but I'm not sure how to make it
> safe s
I'm trying to do it in my drivier, but I'm not sure how to make it
safe since there is no way to tell the kernel the total size of the
buffer. From what I can tell, I can't sanity check that the offset
and lengths are within the buffer without adding a field.
Rebecca
On Mon, Jun 4, 2012 at 1:28
this is at least how we do it w/ drm/kms.. I would expect that if you
could do that w/ output for v4l you also could for input, but perhaps
the individual driver needs to do something to support mplane? I
guess the v4l folks would know better
BR,
-R
On Tue, Jun 5, 2012 at 3:34 AM, Rebecca Schult
On Mon, Jun 4, 2012 at 5:47 AM, Hans Verkuil wrote:
>
>> Would you care to explain me this change in your patch?
>> + set_bit(V4L2_FL_USE_FH_PRIO, &dev->vdev.flags);
>
> See Documentation/video4linux/v4l2-framework.txt:
>
> "flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for the planes. I can't
figure out how to do that with the current dma_buf implementation. I
thought I could pass the same dma_buf several times and use the
data_offset field of the v4l2_pla
Hello,
On 6/4/12 12:57 PM, Hans de Goede wrote:
> I've been doing a lot of work on xawtv3 lately, mostly on the radio app
> but also some on xawtv itself. I'm no done and IMHO it would be good
> to do a new upstream release to get all those changes out there.
>
> So any comments / suggestions? 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:Mon Jun 4 19:00:20 CEST 2012
git hash:5472d3f17845c4398c6a510b46855820920c2181
gcc version: i686-linux-gcc (GC
Hi Guennadi.
I am trying to force to proper work CS4954 encoder with sh4.
I want to use sh4 VOU in PAL mode (kernel 3.2.7). Do you have any experience
with AK881x and PAL?
If I set PAL mode (v4l2-ctl -s) VOUCR::MD is still configured for NTSC. I
noticed that VOU is limited to NTSC resolution: "
For one, the driver device pointer needs to be filled in, or the lirc core
will refuse to load the driver. And we really need to wire up all the
platform_device bits. This has been tested via the lirc sourceforge tree
and verified to work, been sitting there for months, finally getting
around to se
Hi, Guennadi
Got it! Thank you!
We will update our client driver.
Thanks
Albert Wang
86-21-61092656
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Monday, 04 June, 2012 23:49
To: Albert Wang
Cc: linux-media@vger.kernel.org
Subject: RE: [PATCH] [media
On Mon, Jun 04, 2012 at 06:40:46PM +0200, Laurent Pinchart wrote:
> Hi Felipe,
>
> On Monday 04 June 2012 18:28:33 Felipe Balbi wrote:
> > On Mon, Jun 04, 2012 at 11:21:13PM +0800, Bhupesh SHARMA wrote:
> > > On Monday, June 04, 2012 8:44 PM Felipe Balbi wrote:
> > > > On Fri, Jun 01, 2012 at 03:0
Hi Felipe,
On Monday 04 June 2012 18:28:33 Felipe Balbi wrote:
> On Mon, Jun 04, 2012 at 11:21:13PM +0800, Bhupesh SHARMA wrote:
> > On Monday, June 04, 2012 8:44 PM Felipe Balbi wrote:
> > > On Fri, Jun 01, 2012 at 03:08:57PM +0530, Bhupesh Sharma wrote:
> > > > This patch reworks the videobuffer
Hi Ritesh,
On Thursday 31 May 2012 03:26:57 Ritesh wrote:
> Hi Laurent,
> For me even ISP revision print log is not displaying and moreover when I am
> checking the interrupts using cat /proc/interrupts
> Only iommu interrupt is showing for interrupt line 24
>
> Seems ISP probe function is not at
On Mon, 4 Jun 2012, Albert Wang wrote:
> Hi, Guennadi
>
> Yes, maybe you are right.
> I checked some i2c client drivers, they all changed it to:
>
> struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
>
> We also can update our client driver, but could you please explain why
> do you
Hi Felipe,
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Monday, June 04, 2012 9:11 PM
> To: Bhupesh SHARMA
> Cc: ba...@ti.com; laurent.pinch...@ideasonboard.com; linux-
> u...@vger.kernel.org; linux-media@vger.kernel.org;
> gre...@linuxfoundation.org
> Subject: R
Hi,
On Mon, Jun 04, 2012 at 11:37:59PM +0800, Bhupesh SHARMA wrote:
> > -Original Message-
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Monday, June 04, 2012 8:59 PM
> > To: Bhupesh SHARMA
> > Cc: ba...@ti.com; laurent.pinch...@ideasonboard.com; linux-
> > u...@vger.kernel.org; l
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Monday, June 04, 2012 8:59 PM
> To: Bhupesh SHARMA
> Cc: ba...@ti.com; laurent.pinch...@ideasonboard.com; linux-
> u...@vger.kernel.org; linux-media@vger.kernel.org;
> gre...@linuxfoundation.org
> Subject: Re: [PATCH 4/
On 04.06.2012 16:02, Laurent Pinchart wrote:
> Hi Oleksiy,
>
> Thank you for the patch.
>
> [CC'ing linux-media]
>
> On Sunday 03 June 2012 19:17:06 Oleksij Rempel wrote:
>> Hi Laurent,
>>
>> in attachment is a suggestion patch for media framework and a test
>> program which use this patch.
>>
>
Hi, Guennadi
Yes, maybe you are right.
I checked some i2c client drivers, they all changed it to:
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
We also can update our client driver, but could you please explain why do you
change it?
Thank you very much!
Thanks
Albert Wang
86-2
On Mon, Jun 04, 2012 at 11:21:13PM +0800, Bhupesh SHARMA wrote:
> Hi Felipe,
>
> > -Original Message-
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Monday, June 04, 2012 8:44 PM
> > To: Bhupesh SHARMA
> > Cc: laurent.pinch...@ideasonboard.com; linux-...@vger.kernel.org;
> > ba...@
On Fri, Jun 01, 2012 at 03:08:57PM +0530, Bhupesh Sharma wrote:
> This patch reworks the videobuffer management logic present in the UVC
> webcam gadget and ports it to use the "more apt" videobuf2 framework for
> video buffer management.
>
> To support routing video data captured from a real V4L2
Hi Felipe,
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Monday, June 04, 2012 8:44 PM
> To: Bhupesh SHARMA
> Cc: laurent.pinch...@ideasonboard.com; linux-...@vger.kernel.org;
> ba...@ti.com; linux-media@vger.kernel.org; gre...@linuxfoundation.org
> Subject: Re: [
On Mon June 4 2012 16:02:12 Laurent Pinchart wrote:
> Hi Oleksiy,
>
> Thank you for the patch.
>
> [CC'ing linux-media]
>
> On Sunday 03 June 2012 19:17:06 Oleksij Rempel wrote:
> > Hi Laurent,
> >
> > in attachment is a suggestion patch for media framework and a test
> > program which use this
Hi Oleksiy,
Thank you for the patch.
[CC'ing linux-media]
On Sunday 03 June 2012 19:17:06 Oleksij Rempel wrote:
> Hi Laurent,
>
> in attachment is a suggestion patch for media framework and a test
> program which use this patch.
>
> Suddenly we still didn't solved the problem with finding of X
On 12-06-04 09:35 AM, Devin Heitmueller wrote:
>
> The 950q doesn't use the dvb-usb framework (nor does it load the
> firmware at init). Whatever is going on there is completely unrelated
> to what Antti is debugging.
Ahhh. Pity. I was almost giddy there for a second. :-/
Cheers,
b.
sign
On Mon, Jun 4, 2012 at 9:32 AM, Brian J. Murrell wrote:
> On 12-06-03 05:01 PM, Antti Palosaari wrote:
>>
>> That firmware downloading patch is done top of my new dvb-usb
>> development tree. I have converted very limited set of drivers for that
>> tree, af9015, au6610, ec168 and anysee (and those
On Mon 04-06-12 20:46:14, Akinobu Mita wrote:
> 2012/6/4 Jan Kara :
> > On Sat 02-06-12 22:40:07, Akinobu Mita wrote:
> >> memweight() is the function that counts the total number of bits set
> >> in memory area. Unlike bitmap_weight(), memweight() takes pointer
> >> and size in bytes to specify a
On 12-06-03 05:01 PM, Antti Palosaari wrote:
>
> That firmware downloading patch is done top of my new dvb-usb
> development tree. I have converted very limited set of drivers for that
> tree, af9015, au6610, ec168 and anysee (and those are only on my local
> hard disk). I tried to backport patch
On Wed, 2012-05-23 at 14:28 +0200, Hans Verkuil wrote:
> On Wed 23 May 2012 13:20:03 Andrzej Hajda wrote:
> > On Wed, 2012-05-23 at 09:43 +0200, Hans Verkuil wrote:
> > > Hi Andrzej!
> > >
> > > Thanks for the patch, but I do have two questions:
> > >
> > > On Tue 22 May 2012 17:33:53 Andrzej Haj
Hi Albert
On Mon, 4 Jun 2012, Albert Wang wrote:
> This patch corrects icl platform data assignment
>
> from:
> icl->board_info->platform_data = icl;
> to:
> icl->board_info->platform_data = icd;
>
> during init i2c device board info
No, I don't think this is right. If
2012/6/4 Jan Kara :
> On Sat 02-06-12 22:40:07, Akinobu Mita wrote:
>> memweight() is the function that counts the total number of bits set
>> in memory area. Unlike bitmap_weight(), memweight() takes pointer
>> and size in bytes to specify a memory area which does not need to be
>> aligned to lon
Hi All,
I've been doing a lot of work on xawtv3 lately, mostly on the radio app
but also some on xawtv itself. I'm no done and IMHO it would be good
to do a new upstream release to get all those changes out there.
So any comments / suggestions? Note "go for it" also is a valid
comment :)
Regard
On Sat 02-06-12 22:40:07, Akinobu Mita wrote:
> memweight() is the function that counts the total number of bits set
> in memory area. Unlike bitmap_weight(), memweight() takes pointer
> and size in bytes to specify a memory area which does not need to be
> aligned to long-word boundary.
>
> Sign
This patch corrects icl platform data assignment
from:
icl->board_info->platform_data = icl;
to:
icl->board_info->platform_data = icd;
during init i2c device board info
Change-Id: Ia40a5ce96adbc5a1c3f3a90028e87a6fdbabc881
Signed-off-by: Albert Wang
---
drivers/media/vid
On Sun June 3 2012 23:44:03 Ezequiel Garcia wrote:
> Hans,
>
> On Sun, Jun 3, 2012 at 7:33 AM, Hans Verkuil wrote:
> >
> > Thanks. I've fixed several things reported by v4l2-compliance (see my patch
> > below), but you are using an older v4l2-compliance version. You should clone
> > and compile t
40 matches
Mail list logo