Em Thu, 2 Mar 2017 22:16:49 +0100
Markus Heiser escreveu:
> > Am 02.03.2017 um 20:34 schrieb Mauro Carvalho Chehab
> > :
> >
> > Em Thu, 2 Mar 2017 20:06:39 +0100
> > Markus Heiser escreveu:
> >
> >> Hi Mauro,
> >>
> >>&
Em Thu, 2 Mar 2017 18:29:39 -0300
Mauro Carvalho Chehab escreveu:
> Em Thu, 2 Mar 2017 16:40:02 +0100
> Daniel Vetter escreveu:
>
> > From: Markus Heiser
> >
> > This patch brings scalable figure, image handling and a concept to
> > embed *rend
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 (easily at least) test
> >> on sphinx 1.3.
> >
> > V
Em Thu, 2 Mar 2017 19:16:47 +0100
Markus Heiser escreveu:
> > Am 02.03.2017 um 17:29 schrieb Mauro Carvalho Chehab
> > :
> >
> > Em Thu, 2 Mar 2017 17:13:25 +0100
> > Markus Heiser escreveu:
> >
> >>> Am 02.03.2017 um 16:49 schrieb Mauro C
Now that we have an extension to handle images, use it.
Signed-off-by: Mauro Carvalho Chehab
---
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 some extra warning
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 12:29:11AM +0800, Randy
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 01:42:55PM +0200
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 01:42:55PM +0200
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 a
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 structur
igned-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/gp
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 cec/
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 samsung.c
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 w
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.
>
> Signed-
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 t
ff-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-v
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
>
> We
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
>
> S
: 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 @@ config DRM_EXYNOS_VIDI
config
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/exynos/exynos_drm_g2d.c
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 Che
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 ord
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 met
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 time.
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 RGB
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 let
y Utkin
>
> 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
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
vers/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
uf *dmabuf)
> > {
> > @@ -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(p
c: 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
> Cc: linux-arm-kernel at lists.infradead.or
; Cc: Ian Campbell
> 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
> Cc: linux-media at vger.kernel.o
> > with a call to the new helper dma_set_mask_and_coherent().
> >
> > Signed-off-by: Russell King
>
> Acked-by: Hans Verkuil
Somehow, I lost your original post (I got unsubscribed on a few days
from all vger mailing lists at the end of september).
I suspect that you want to sent this via
' are identical, so replace 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 fi
' are identical, so replace 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 +-
> includ
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
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 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, inc
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, inc
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 interface".
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 interface".
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 EXPORT_SYMB
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 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 EXPORT_SYMB
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 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,
> > > >
> > > >
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,
> > > >
> > > >
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 API
>>&g
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 API
>>&g
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
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
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 ma
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 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 ma
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:
> 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 descripto
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 i
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 descripto
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 t
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 t
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 t
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 t
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 infrastructu
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 infrastructu
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
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 a
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
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
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 in
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 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 in
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 I've
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)
&g
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 u
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)
&g
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 u
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-r
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-r
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
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
701 - 798 of 798 matches
Mail list logo
