Hi Laurent,
Thanks for your review comments.
Please find my comments inline:
> As Felipe has already applied the patch to his public tree, I'll send
> incremental cleanup patches. Here's my review nonetheless, with a
> question
> which I'd like to know your opinion about to write the cleanup patc
Use memweight() to count the total number of bits set in memory area.
Signed-off-by: Akinobu Mita
Acked-by: Laurent Pinchart
Cc: linux-media@vger.kernel.org
---
No changes from v1
drivers/media/video/uvc/uvc_ctrl.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/dr
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.
Signed-off-by: Akinobu Mita
Cc: Anders Larsen
Cc: Alasdair K
On Fri, Jun 8, 2012 at 2:42 PM, Daniel Vetter wrote:
>> I think this is an approach worth investigating. I'd like a way to
>> either opt out of implicit sync or have a way to check if a dma-buf
>> has an attached fence and detach it. Actually, that could work really
>> well. Consider:
>>
>> * Ea
On Fri, Jun 08, 2012 at 01:56:05PM -0700, Erik Gilling wrote:
> On Thu, Jun 7, 2012 at 4:35 AM, Tom Cooksey wrote:
> > The alternate is to not associate sync objects with buffers and
> > have them be distinct entities, exposed to userspace. This gives
> > userpsace more power and flexibility and m
On Thu, Jun 7, 2012 at 4:35 AM, Tom Cooksey wrote:
> The alternate is to not associate sync objects with buffers and
> have them be distinct entities, exposed to userspace. This gives
> userpsace more power and flexibility and might allow for use-cases
> which an implicit synchronization mechanism
On Thu, Jun 7, 2012 at 10:52 AM, Maarten Lankhorst
wrote:
> I do agree you need some way to synch userspace though, but I
> think adding a new api for userspace is not the way to go.
I'm not sure I understand how you propose to expose the functionality
to userspace in a way that does not depend o
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:Fri Jun 8 19:00:16 CEST 2012
git hash:5472d3f17845c4398c6a510b46855820920c2181
gcc version: i686-linux-gcc (GC
Hi Bhupesh,
Thanks for the patch.
As Felipe has already applied the patch to his public tree, I'll send
incremental cleanup patches. Here's my review nonetheless, with a question
which I'd like to know your opinion about to write the cleanup patches.
On Friday 01 June 2012 15:08:56 Bhupesh Sha
On Fri, Jun 08, 2012 at 01:32:27PM +0200, javier Martin wrote:
> On 8 June 2012 11:23, Sascha Hauer wrote:
> > On Fri, Jun 08, 2012 at 11:02:31AM +0200, javier Martin wrote:
>
> Hi Sascha,
>
> From our point of view the current situation is the following:
> We have a very reliable driver for the
Hi Laurent and Subash,
I confirm the issue found by Subash. The function
vb2_dc_kaddr_to_pages does fail for some occasions.
The failures are rather strange like 'got 95 of
150 pages'. It took me some time to find the reason
of the problem.
I found that dma_alloc_coherent for iommu an ARM does
us
Hello Ralph Metzler,
The patch 43dd07f758d8: "[media] DRX-K: Initial check-in" from Jul 3,
2011, leads to the following warning:
drivers/media/dvb/frontends/drxk_hard.c:2980 ADCSynchronization()
warn: suspicious bitop condition
2977 status = read16(state, IQM_AF_CLKNE
In function vb2_dma_contig_cleanup_ctx(), we only kfree the alloc_ctx
If we didn't assign NULL to this point after kfree it,
we may encounter the following kernel panic:
kernel BUG at kernel/cred.c:98!
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c000
On 8 June 2012 11:23, Sascha Hauer wrote:
> On Fri, Jun 08, 2012 at 11:02:31AM +0200, javier Martin wrote:
>> Hi,
>> I've checked this matter with a colleague and we have several reasons
>> to doubt that the i.MX27 and the i.MX53 can share the same driver for
>> their Video Processing Units (VPU):
Update zr364xx to the latest frameworks (except for vb2) and add
suspend/resume support.
Tested with actual hardware on both little and big endian hosts.
Regards,
Hans
The following changes since commit 5472d3f17845c4398c6a510b46855820920c2181:
[media] mt9m032: Implement V4L2_CID_PIX
On Fri, Jun 08, 2012 at 11:02:31AM +0200, javier Martin wrote:
> Hi,
> I've checked this matter with a colleague and we have several reasons
> to doubt that the i.MX27 and the i.MX53 can share the same driver for
> their Video Processing Units (VPU):
>
> 1. The VPU in the i.MX27 is a "codadx6" wit
Hi,
I've checked this matter with a colleague and we have several reasons
to doubt that the i.MX27 and the i.MX53 can share the same driver for
their Video Processing Units (VPU):
1. The VPU in the i.MX27 is a "codadx6" with support for H.264, H.263
and MPEG4-Part2 [1]. Provided Freescale is using
On 8 June 2012 10:48, Sascha Hauer wrote:
> On Fri, Jun 08, 2012 at 09:39:15AM +0200, javier Martin wrote:
>> Hi Robert,
>>
>> On 8 June 2012 09:26, Robert Schwebel wrote:
>> > Hi Javier,
>> >
>> > On Fri, Jun 08, 2012 at 09:21:13AM +0200, javier Martin wrote:
>> >> If you refer to driver in [1]
On Fri, Jun 08, 2012 at 09:39:15AM +0200, javier Martin wrote:
> Hi Robert,
>
> On 8 June 2012 09:26, Robert Schwebel wrote:
> > Hi Javier,
> >
> > On Fri, Jun 08, 2012 at 09:21:13AM +0200, javier Martin wrote:
> >> If you refer to driver in [1] I have some concerns: i.MX27 VPU should
> >> be imp
Hi Janusz
On Wed, 6 Jun 2012, Janusz Uzycki wrote:
> > > This is why "v4l2-ctl -s 5" used before my simple test program (modified
> > > capture example with mmap method) finally has no effect for VOU.
> > > When the test program opens video device it causes reset PAL mode in VOU
> > > and
> > > d
On Fri, Jun 08, 2012 at 09:39:15AM +0200, javier Martin wrote:
> Do you plan to provide both encoding and decoding support or just one
> of them?
We need both.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://ww
Hi Robert,
On 8 June 2012 09:26, Robert Schwebel wrote:
> Hi Javier,
>
> On Fri, Jun 08, 2012 at 09:21:13AM +0200, javier Martin wrote:
>> If you refer to driver in [1] I have some concerns: i.MX27 VPU should
>> be implemented as a V4L2 mem2mem device since it gets raw pictures
>> from memory and
Fabio,
On 8 June 2012 08:51, javier Martin wrote:
> Hi Fabio,
>
> On 7 June 2012 19:35, Fabio Estevam wrote:
>> Hi Javier,
>>
>> On Thu, Jun 7, 2012 at 5:30 AM, javier Martin
>> wrote:
>>
>>> As i stated, the driver is still in an early development stage, it
>>> doesn't do anything useful yet.
23 matches
Mail list logo
