Em Thu, 2 Mar 2017 18:29:39 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> escreveu:
> Em Thu, 2 Mar 2017 16:40:02 +0100
> Daniel Vetter <daniel.vet...@ffwll.ch> escreveu:
>
> > From: Markus Heiser <markus.hei...@darmarit.de>
> >
> > This
Em Thu, 2 Mar 2017 16:53:04 +0100
Daniel Vetter escreveu:
> On Thu, Mar 2, 2017 at 4:22 PM, Jonathan Corbet wrote:
> > On Thu, 2 Mar 2017 16:11:08 +0100
> > Daniel Vetter wrote:
> >
> >> I'll give it a shot at implementing it, but I can't
Em Thu, 2 Mar 2017 19:16:47 +0100
Markus Heiser <markus.hei...@darmarit.de> escreveu:
> > Am 02.03.2017 um 17:29 schrieb Mauro Carvalho Chehab
> > <mche...@s-opensource.com>:
> >
> > Em Thu, 2 Mar 2017 17:13:25 +0100
> > Markus Heiser <markus.
Now that we have an extension to handle images, use it.
Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
---
This patch is based on Daniel Vetter & Markus Heiser's work to support
PNG and SVG via kpicture Sphinx extension.
PS.: With this RFC patch, I'm getting now
Em Thu, 5 Jan 2017 20:27:17 +0200
Sakari Ailus escreveu:
> Hi Randy,
>
> On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
> >
> >
> > On 01/05/2017 06:30 PM, Sakari Ailus wrote:
> > >Hi Randy,
> > >
> > >Thanks for the update.
> > >
> > >On Thu, Jan 05, 2017 at
Em Tue, 23 Aug 2016 08:16:33 -0600
Jonathan Corbet escreveu:
> On Tue, 23 Aug 2016 15:28:55 +0200
> Daniel Vetter wrote:
>
> > I think the more interesting story is, what's your plan with all the
> > other driver related subsystem? Especially the ones which already have
> > full directories of
Em Mon, 22 Aug 2016 20:41:45 +0530
Sumit Semwal escreveu:
> Include dma-buf sphinx documentation into top level index.
>
> Signed-off-by: Sumit Semwal
> ---
> Documentation/index.rst | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/index.rst b/Documentation/index.rst
Em Wed, 20 Jul 2016 20:35:09 +0200
Markus Heiser escreveu:
> Am 20.07.2016 um 14:20 schrieb Mauro Carvalho Chehab s-opensource.com>:
>
> > Em Tue, 19 Jul 2016 14:36:50 +0200
> > Daniel Vetter escreveu:
> >
> >> On Tue, Jul 19, 2016 at 0
Em Wed, 20 Jul 2016 20:35:09 +0200
Markus Heiser escreveu:
> Am 20.07.2016 um 14:20 schrieb Mauro Carvalho Chehab s-opensource.com>:
>
> > Em Tue, 19 Jul 2016 14:36:50 +0200
> > Daniel Vetter escreveu:
> >
> >> On Tue, Jul 19, 2016 at 0
Em Wed, 20 Jul 2016 14:29:01 +0200
Markus Heiser escreveu:
> Am 20.07.2016 um 13:27 schrieb Daniel Vetter :
>
> > On Wed, Jul 20, 2016 at 12:55 PM, Markus Heiser
> > wrote:
> >> Hi Daniel, hi Mauro,
> >>
> >> Am 19.07.2016 um 17:32 schrieb Daniel Vetter :
> >>
> >>> On Tue, Jul 19, 2016
Em Tue, 19 Jul 2016 14:36:50 +0200
Daniel Vetter escreveu:
> On Tue, Jul 19, 2016 at 01:42:55PM +0200, Daniel Vetter wrote:
> > These are the leftovers I could only track down using keep_warnings =
> > True. For some of them we might want to update our style guide on how
> > to reference
-off-by: Krzysztof Kozlowski
Acked-by: Mauro Carvalho Chehab
PS.: If you prefer to apply this one via my tree, I'm ok too. Just
let me know when the first patch gets merged upstream.
Regards,
Mauro
> ---
> MAINTAINERS | 8 -
> drivers/gpu/drm/exyn
Em Fri, 17 Jun 2016 13:09:10 +0200
Hans Verkuil escreveu:
> On 06/17/2016 11:50 AM, Mauro Carvalho Chehab wrote:
> >>>> +
> >>>> +CEC_MODE_MONITOR
> >>>> +0xe0
> >>>> +Put the file descri
Em Fri, 17 Jun 2016 10:06:31 +0200
Hans Verkuil escreveu:
> On 06/16/2016 11:22 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 29 Apr 2016 15:52:25 +0200
> > Hans Verkuil escreveu:
> >
> >> From: Hans Verkuil
> >>
> >> Add CEC support to t
Em Fri, 17 Jun 2016 10:03:13 +0200
Hans Verkuil escreveu:
> On 06/16/2016 11:17 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 29 Apr 2016 15:52:24 +0200
> > Hans Verkuil escreveu:
> >
> >> From: Hans Verkuil
> >>
> >> Add CEC support to t
Em Fri, 17 Jun 2016 09:58:53 +0200
Hans Verkuil escreveu:
> On 06/16/2016 11:09 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 29 Apr 2016 15:52:23 +0200
> > Hans Verkuil escreveu:
> >
> >> From: Hans Verkuil
> >>
> >> Add DocBook documentatio
Em Fri, 17 Jun 2016 09:22:05 +0200
Hans Verkuil escreveu:
> On 06/16/2016 10:12 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 29 Apr 2016 15:52:22 +0200
> > Hans Verkuil escreveu:
> >
> >> From: Hans Verkuil
> >>
> >> Document the new H
Em Fri, 29 Apr 2016 15:52:25 +0200
Hans Verkuil escreveu:
> From: Hans Verkuil
>
> Add CEC support to the adv7842 driver.
>
> Signed-off-by: Hans Verkuil
Won't review patches 10-13, as the same reviews I made for patch 9
very likely applies.
As this series is causing non-staging drivers to
Em Fri, 29 Apr 2016 15:52:24 +0200
Hans Verkuil escreveu:
> From: Hans Verkuil
>
> Add CEC support to the adv7604 driver.
>
> Signed-off-by: Hans Verkuil
> [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
> Verkuil]
> [k.debski at samsung.com: add missing methods
Em Fri, 29 Apr 2016 15:52:23 +0200
Hans Verkuil escreveu:
> From: Hans Verkuil
>
> Add DocBook documentation for the CEC API.
Please always send the documentation patch *before* the code,
in order to make easier to do the code review.
>
> Signed-off-by: Hans Verkuil
> [k.debski at
Em Fri, 29 Apr 2016 15:52:22 +0200
Hans Verkuil escreveu:
> From: Hans Verkuil
>
> Document the new HDMI CEC framework.
As we'll be moving documentation to Sphinx/Rst, it would be good if
you could make it work fine with sphinx, as this will likely be needed
for Kernel 4.9. Right now it most
Em Fri, 29 Apr 2016 15:52:20 +0200
Hans Verkuil escreveu:
> From: Hans Verkuil
>
> Explain why cec.c is still in staging.
Hmm... as this is for staging, even having pointed several things to
be improved, I may end merging this series. Will decide after finishing
the patch review.
>
>
Em Fri, 29 Apr 2016 15:52:19 +0200
Hans Verkuil escreveu:
> From: Hans Verkuil
>
> The added HDMI CEC framework provides a generic kernel interface for
> HDMI CEC devices.
>
> Besides the cec module itself it also adds a cec-edid module that
> contains helper functions to find and manipulate
-by: Mauro Carvalho Chehab
---
drivers/gpu/ipu-v3/ipu-cpmem.c | 2 +-
include/uapi/drm/drm_fourcc.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index 63eb16bf2cf0..883a314cd83a 100644
--- a/drivers/gpu/ipu-v3/ipu
Em Tue, 17 Nov 2015 17:21:32 -0700
Jonathan Corbet escreveu:
> On Tue, 17 Nov 2015 13:29:49 -0200
> Mauro Carvalho Chehab wrote:
>
> > The enclosed patch should do the trick. I tested it with perl 5.10 and
> > perl 5.22 it worked fine with both versions.
>
> Indee
Em Tue, 17 Nov 2015 07:44:31 -0700
Jonathan Corbet escreveu:
> On Tue, 17 Nov 2015 08:40:46 -0200
> Mauro Carvalho Chehab wrote:
>
> > The above causes some versions of perl to fail, as keys expect a
> > hash argument:
> >
> > Execution of .//scripts/kern
Hi Danilo,
Em Tue, 28 Jul 2015 16:45:16 -0300
Danilo Cesar Lemes de Paula escreveu:
> The "highlight" code is very sensible to the order of the hash keys,
> but the order of the keys cannot be predicted on Perl. It generates
> faulty DocBook entries like:
> - @device_for_each_child
>
>
Hi Christoph,
Em Sat, 3 Oct 2015 17:19:29 +0200
Christoph Hellwig escreveu:
> This ensures the dma mask that is supported by the driver is recorded
> in the device structure.
For this and the other patches touching at drivers/media:
Acked-by: Mauro Carvalho Chehab
>
>
erkuil
Signed-off-by: Mauro Carvalho Chehab
create mode 100644 mm/frame_vector.c
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 0a6780367d28..fc678289cf79 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -71,6 +71,7 @@
Signed-off-by: Jan Kara
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 81a250830808..810e1ee7c07d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/
Em Wed, 27 May 2015 15:05:42 +0300
Laurent Pinchart escreveu:
> Even though 'compatability' has a dedicated entry in the Wiktionary,
> it's listed as 'Mispelling of compatibility'. Fix it.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Mauro Carvalho Chehab
> ---
> arch
me. I'm open to better
> suggestions though.
Gerd,
It seems that I never actually acked or nacked about this patch.
I'm ok with such change. So:
Acked-by: Mauro Carvalho Chehab
Btw, it would make sense to add some help for config OMAP_IOMMU and
say that this is required in order to comp
Em Mon, 06 Apr 2015 11:50:21 +0200
Paul Bolle escreveu:
> On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote:
> > I think part of the problem is that "select" is often used not as
> > documented [1] but rather as "show my config in menuconfig for
> > convenience even if my dependency is not
Em Wed, 11 Mar 2015 12:24:53 +0100
Kamil Debski escreveu:
> Hi Mauro,
>
> I have some more comments/questions below.
>
> From: Mauro Carvalho Chehab [mailto:mchehab at osg.samsung.com]
> Sent: Sunday, March 08, 2015 3:21 PM
> >
> > Em Thu, 22 Jan 2015 17:04:34 +0
Em Fri, 06 Mar 2015 17:14:50 +0100
Kamil Debski escreveu:
> Hi Sean, Hans,
>
> I am sorry to reply so late, I was busy with other work. I am preparing the
> next version
> of the CEC framework and I would like to discuss your comment.
I'll do a deeper review of this patch when I have some
Em Thu, 22 Jan 2015 17:04:34 +0100
Kamil Debski escreveu:
(c/c linux-input ML)
> Add cec protocol handling the RC framework.
I added some comments, that reflects my understanding from what's there at
the keymap definitions found at:
http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
Em Mon, 02 Feb 2015 16:32:07 +0100
Boris Brezillon escreveu:
> Hi Mauro,
>
> On Mon, 02 Feb 2015 12:57:55 -0200
> Mauro Carvalho Chehab wrote:
>
> > Em Tue, 6 Jan 2015 12:43:35 +0100
> > Boris Brezillon escreveu:
> >
> > > Add RGB444_1X12 and
Em Wed, 28 Jan 2015 18:24:03 +0530
Sumit Semwal escreveu:
> +/**
> + * helper macro for exporters; zeros and fills in most common values
> + */
> +#define DEFINE_DMA_BUF_EXPORT_INFO(a)\
> + struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
> +
I suspect that this will
gt;
> Acked-by: Steven Rostedt
Acked-by: Mauro Carvalho Chehab
>
> -- Steve
>
> > ---
> > drivers/gpu/drm/radeon/mkregtable.c | 24
> > drivers/media/pci/cx18/cx18-driver.h | 2 +-
> > include/linux/list.h | 34
hidden somewere on my
queue... so:
Acked-by: Mauro Carvalho Chehab
> ---
> include/uapi/linux/v4l2-mediabus.h| 2 ++
> include/uapi/linux/video-bus-format.h | 4 +++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/v4l2-mediab
gpu/drm/radeon/radeon_prime.c |8
> drivers/gpu/drm/ttm/ttm_object.c |2 +-
> drivers/media/v4l2-core/videobuf2-dma-contig.c |2 +-
With regards to this small change on VB2-dma-contig:
Acked-by: Mauro Carvalho Chehab
> include/drm/drmP.h
mabuf)
> > {
> > @@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
> > BUG_ON(dmabuf->vmap_ptr);
> >
> > ptr = dmabuf->ops->vmap(dmabuf);
> > - if (IS_ERR_OR_NULL(ptr))
> > + if (WARN_ON_ONCE(IS_ERR(ptr)))
cetree at vger.kernel.org
> Cc: Greg Kroah-Hartman
> Cc: driverdev-devel at linuxdriverproject.org
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Cc: Mauro Carvalho Chehab
> Cc: Laurent Pinchart
> Cc: linux-media at vger.kernel.org
> Cc: Sascha Hauer
>
t; Cc: Ian Campbell <ijc+devicetree at hellion.org.uk>
> Cc: devicetree at vger.kernel.org
> Cc: Greg Kroah-Hartman
> Cc: driverdev-devel at linuxdriverproject.org
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Cc: Mauro Carvalho Chehab
> Cc: Laurent Pinchart
suspect that you want to sent this via your tree, right?
If so:
Acked-by: Mauro Carvalho Chehab
>
> Regards,
>
> Hans
>
> > ---
> > drivers/staging/media/dt3155v4l/dt3155v4l.c |5 +
> > 1 files changed, 1 insertions(+), 4 deletions(-)
> >
place all occurrences of the
> former with the later.
>
> Signed-off-by: Lars-Peter Clausen
> Cc: Kyungmin Park
> Cc: Sylwester Nawrocki
Acked-by: Mauro Carvalho Chehab
> ---
> drivers/media/platform/exynos4-is/media-dev.c | 6 +++---
> 1 file changed, 3 insertions(+), 3
place all occurrences of the
> former with the later.
>
> Signed-off-by: Lars-Peter Clausen
Acked-by: Mauro Carvalho Chehab
> ---
> drivers/media/v4l2-core/tuner-core.c | 6 +++---
> drivers/media/v4l2-core/v4l2-common.c | 10 +-
> include/media/v4l2-common.h
Nawrocki s.nawro...@samsung.com
Signed-off-by: Wolfram Sang w...@the-dreams.de
Acked-by: Mauro Carvalho Chehab m.che...@samsung.com
---
V2-V3: Was trying to be too smart by only fixing includes needed.
Took a more general approach this time, converting of_i2c.h
to i2c.h in case i2c.h
lly register child nodes in the core instead of doing this manually
> in each driver. So, fix the drivers and documentation, too.
>
> Acked-by: Rob Herring
> Reviewed-by: Felipe Balbi
> Acked-by: Rafael J. Wysocki
> Tested-by: Sylwester Nawrocki
> Signed-off-by: Wolfram Sang
Em Thu, 11 Oct 2012 08:47:15 -0500
Rob Clark escreveu:
> On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab
> wrote:
> > Em Thu, 11 Oct 2012 09:20:12 +0200
> > Hans Verkuil escreveu:
> >
> >> > my understaning is
> >> > that the drivers/me
Em Thu, 11 Oct 2012 09:20:12 +0200
Hans Verkuil escreveu:
> > my understaning is
> > that the drivers/media/ authors should also ack with this licensing
> > (possible) change. I am one of the main contributors there. Alan also has
> > copyrights there, and at other parts of the Linux Kernel,
Em Thu, 11 Oct 2012 09:20:12 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
my understaning is
that the drivers/media/ authors should also ack with this licensing
(possible) change. I am one of the main contributors there. Alan also has
copyrights there, and at other parts of the Linux
Em Thu, 11 Oct 2012 08:47:15 -0500
Rob Clark robdcl...@gmail.com escreveu:
On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em Thu, 11 Oct 2012 09:20:12 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
my understaning is
that the drivers/media/ authors
Em Thu, 11 Oct 2012 09:22:34 +1000
Dave Airlie escreveu:
> On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox wrote:
> > On Wed, 10 Oct 2012 08:56:32 -0700
> > Robert Morell wrote:
> >
> >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> >> issue, and not really an
Em Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell escreveu:
> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> issue, and not really an interface". The dma-buf infrastructure is
> explicitly intended as an interface between modules/drivers, so it
> should use
Hi,
Em Tue, 02 Oct 2012 16:27:11 +0200
Tomasz Stanislawski escreveu:
> Hello everyone,
> This patchset adds support for DMABUF [2] importing and exporting to V4L2
> stack.
>
> v9:
> - rebase on 3.6
> - change type for fs to __s32
> - add support for vb2_ioctl_expbuf
> - remove patch 'v4l: vb2:
Em Mon, 08 Oct 2012 19:45:14 +0200
Florian Fainelli f.faine...@gmail.com escreveu:
On Monday 08 October 2012 17:49:00 Hans Verkuil wrote:
On Mon October 8 2012 17:06:20 Florian Fainelli wrote:
Hi Hans,
On Thursday 27 September 2012 16:33:30 Hans Verkuil wrote:
Hi all,
Hi,
Em Tue, 02 Oct 2012 16:27:11 +0200
Tomasz Stanislawski t.stanisl...@samsung.com escreveu:
Hello everyone,
This patchset adds support for DMABUF [2] importing and exporting to V4L2
stack.
v9:
- rebase on 3.6
- change type for fs to __s32
- add support for vb2_ioctl_expbuf
- remove
Em Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell rmor...@nvidia.com escreveu:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf infrastructure is
explicitly intended as an interface between modules/drivers, so it
should
Em Thu, 11 Oct 2012 09:22:34 +1000
Dave Airlie airl...@gmail.com escreveu:
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal
Em Mon, 08 Oct 2012 19:45:14 +0200
Florian Fainelli escreveu:
> On Monday 08 October 2012 17:49:00 Hans Verkuil wrote:
> > On Mon October 8 2012 17:06:20 Florian Fainelli wrote:
> > > Hi Hans,
> > >
> > > On Thursday 27 September 2012 16:33:30 Hans Verkuil wrote:
> > > > Hi all,
> > > >
> > >
/2012 03:04 PM, Mauro Carvalho Chehab wrote:
This one requires more testing:
May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API
http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki
s.nawro...@samsung.com
Hmm, this is not valid any more. Tomasz just posted
ust 2012 18:37:23 Sylwester Nawrocki wrote:
>>>>> On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote:
>>>>>> This one requires more testing:
>>>>>>
>>>>>> May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 A
Em 23-04-2012 07:50, Marek Szyprowski escreveu:
> Hi Mauro,
>
> On Friday, April 20, 2012 3:37 PM Mauro Carvalho Chehab wrote:
>
> (snipped)
>
>>>> So my rough-idea was to remove USERPTR support from kernel
>>>> drivers (if possible of cour
Em 23-04-2012 07:50, Marek Szyprowski escreveu:
Hi Mauro,
On Friday, April 20, 2012 3:37 PM Mauro Carvalho Chehab wrote:
(snipped)
So my rough-idea was to remove USERPTR support from kernel
drivers (if possible of course) and to provide an emulation
layer in the userspace code like
Em 20-04-2012 09:25, Tomasz Stanislawski escreveu:
> Hi Remi,
>> Now, I do realize that some devices cannot support USERPTR efficiently,
>> then they should not support USERPTR.
>
> The problem is not there is *NO* device that can handle USERPTR reliably.
> The can handle USERPTR generated by
Em 20-04-2012 07:56, R?mi Denis-Courmont escreveu:
> On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski
> wrote:
>>> Am I understanding wrong or are you saying that you want to drop
> userptr
>>> from V4L2 API in long-term? If so, why?
>>
>> Dropping userptr is just some brainstorming idea.
Em 19-04-2012 11:32, Tomasz Stanislawski escreveu:
On 04/17/2012 01:25 AM, Laurent Pinchart wrote:
Hi Tomasz,
Thanks for the patch.
On Friday 13 April 2012 17:47:44 Tomasz Stanislawski wrote:
This patch adds description and usage examples for importing
DMABUF file descriptor in V4L2.
Em 19-04-2012 11:32, Tomasz Stanislawski escreveu:
Hi Laurent,
One may find similar sentences in MMAP, USERPTR and DMABUF.
Maybe the common parts like description of STREAMON/OFF,
QBUF/DQBUF shuffling should be moved to separate section
like Streaming :).
Maybe it is worth to introduce
Em 20-04-2012 07:56, RĂ©mi Denis-Courmont escreveu:
On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski
t.stanisl...@samsung.com wrote:
Am I understanding wrong or are you saying that you want to drop
userptr
from V4L2 API in long-term? If so, why?
Dropping userptr is just some
Em 20-04-2012 09:25, Tomasz Stanislawski escreveu:
Hi Remi,
Now, I do realize that some devices cannot support USERPTR efficiently,
then they should not support USERPTR.
The problem is not there is *NO* device that can handle USERPTR reliably.
The can handle USERPTR generated by malloc or
Em 19-04-2012 11:32, Tomasz Stanislawski escreveu:
> Hi Laurent,
>
> One may find similar sentences in MMAP, USERPTR and DMABUF.
> Maybe the common parts like description of STREAMON/OFF,
> QBUF/DQBUF shuffling should be moved to separate section
> like "Streaming" :).
>
> Maybe it is worth to
Em 19-04-2012 11:32, Tomasz Stanislawski escreveu:
> On 04/17/2012 01:25 AM, Laurent Pinchart wrote:
>> Hi Tomasz,
>>
>> Thanks for the patch.
>>
>> On Friday 13 April 2012 17:47:44 Tomasz Stanislawski wrote:
>>> This patch adds description and usage examples for importing
>>> DMABUF file
Em 25-01-2012 11:46, Mauro Carvalho Chehab escreveu:
> Em 25-01-2012 10:30, Alan Cox escreveu:
>>> Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
>>> symbols can be used by the binary blobs, possibly with an open-sourced
>>> shim which provide
Em 25-01-2012 10:30, Alan Cox escreveu:
>> Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
>> symbols can be used by the binary blobs, possibly with an open-sourced
>> shim which provides the buffer-sharing interface to the binary blobs?
>> Are there any reasons to not consider
Em 25-01-2012 10:30, Alan Cox escreveu:
Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
symbols can be used by the binary blobs, possibly with an open-sourced
shim which provides the buffer-sharing interface to the binary blobs?
Are there any reasons to not consider this
Em 25-01-2012 11:46, Mauro Carvalho Chehab escreveu:
Em 25-01-2012 10:30, Alan Cox escreveu:
Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
symbols can be used by the binary blobs, possibly with an open-sourced
shim which provides the buffer-sharing interface to the binary
Em 18-01-2012 10:14, Arnd Bergmann escreveu:
> On Wednesday 18 January 2012, Semwal, Sumit wrote:
>> On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell wrote:
>>> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>>> issue, and not really an interface". The dma-buf
Em 18-01-2012 10:14, Arnd Bergmann escreveu:
On Wednesday 18 January 2012, Semwal, Sumit wrote:
On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf
On 09-12-2011 20:50, Robert Morell wrote:
> On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote:
>> On Friday 02 December 2011, Sumit Semwal wrote:
>>> This is the first step in defining a dma buffer sharing mechanism.
>>
> [...]
>>
>>> + return dmabuf;
>>> +}
>>>
On 09-12-2011 20:50, Robert Morell wrote:
On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
[...]
+ return dmabuf;
+}
+EXPORT_SYMBOL(dma_buf_export);
I
Em 18-05-2011 16:46, Sakari Ailus escreveu:
> Hans Verkuil wrote:
>> Note that many video receivers cannot stall. You can't tell them to wait
>> until
>> the last buffer finished processing. This is different from some/most?
>> sensors.
>
> Not even image sensors. They just output the frame
Em 18-05-2011 16:46, Sakari Ailus escreveu:
Hans Verkuil wrote:
Note that many video receivers cannot stall. You can't tell them to wait
until
the last buffer finished processing. This is different from some/most?
sensors.
Not even image sensors. They just output the frame data; if the
Em 17-05-2011 09:49, Mauro Carvalho Chehab escreveu:
Em 15-05-2011 18:10, Hans Verkuil escreveu:
On Saturday, May 14, 2011 13:46:03 Mauro Carvalho Chehab wrote:
Em 14-05-2011 13:02, Hans Verkuil escreveu:
On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote:
So, based at all I've
Em 16-05-2011 17:45, Guennadi Liakhovetski escreveu:
On Sat, 14 May 2011, Mauro Carvalho Chehab wrote:
Em 18-04-2011 17:15, Jesse Barker escreveu:
One of the big issues we've been faced with at Linaro is around GPU
and multimedia device integration, in particular the memory management
Em 16-05-2011 17:45, Guennadi Liakhovetski escreveu:
> On Sat, 14 May 2011, Mauro Carvalho Chehab wrote:
>
>> Em 18-04-2011 17:15, Jesse Barker escreveu:
>>> One of the big issues we've been faced with at Linaro is around GPU
>>> and multimedia device integra
Em 17-05-2011 09:49, Mauro Carvalho Chehab escreveu:
> Em 15-05-2011 18:10, Hans Verkuil escreveu:
>> On Saturday, May 14, 2011 13:46:03 Mauro Carvalho Chehab wrote:
>>> Em 14-05-2011 13:02, Hans Verkuil escreveu:
>>>> On Saturday, May 14, 2011 12:19:18 Mauro Carva
Em 15-05-2011 18:10, Hans Verkuil escreveu:
> On Saturday, May 14, 2011 13:46:03 Mauro Carvalho Chehab wrote:
>> Em 14-05-2011 13:02, Hans Verkuil escreveu:
>>> On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote:
>>
>>>> So, based at all
Em 14-05-2011 13:02, Hans Verkuil escreveu:
> On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote:
>> So, based at all I've seen, I'm pretty much convinced that the normal MMAP
>> way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's)
>> are not
Em 18-04-2011 17:15, Jesse Barker escreveu:
> One of the big issues we've been faced with at Linaro is around GPU
> and multimedia device integration, in particular the memory management
> requirements for supporting them on ARM. This next cycle, we'll be
> focusing on driving consensus around a
Em 26-01-2011 09:31, Arnd Bergmann escreveu:
> On Wednesday 26 January 2011, Greg KH wrote:
>> On Tue, Jan 25, 2011 at 11:17:14PM +0100, Arnd Bergmann wrote:
>>> I've gone through all the code in the kernel that
>>> uses the big kernel lock and come up with a solution
>>> that seems at least
Em 26-01-2011 09:31, Arnd Bergmann escreveu:
On Wednesday 26 January 2011, Greg KH wrote:
On Tue, Jan 25, 2011 at 11:17:14PM +0100, Arnd Bergmann wrote:
I've gone through all the code in the kernel that
uses the big kernel lock and come up with a solution
that seems at least half-reasonable
Em 14-06-2010 23:26, Justin P. Mattock escreveu:
> not sure if this is correct or not for
> fixing this warning:
> CC [M] drivers/media/common/tuners/tuner-simple.o
> drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq':
>
Em 14-06-2010 23:26, Justin P. Mattock escreveu:
not sure if this is correct or not for
fixing this warning:
CC [M] drivers/media/common/tuners/tuner-simple.o
drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq':
drivers/media/common/tuners/tuner-simple.c:548:20:
701 - 794 of 794 matches
Mail list logo