Hi Rob,
On Thu, Sep 6, 2012 at 3:18 AM, Rob Clark wrote:
> From: Rob Clark
>
> 'struct omap_video_timings' was updated w/ a 'bool interlaced'. Without
> a matching update in omap_connector, this field could have undefined
> values from the stack, which isn't quite ideal.
>
> Update the fxns to c
Hi Rob,
On Thu, Sep 6, 2012 at 3:18 AM, Rob Clark wrote:
> From: Rob Clark
>
> 'struct omap_video_timings' was updated w/ a 'bool interlaced'. Without
> a matching update in omap_connector, this field could have undefined
> values from the stack, which isn't quite ideal.
>
> Update the fxns to c
On Thu, Aug 9, 2012 at 10:26 PM, Rob Clark wrote:
> On Thu, Aug 9, 2012 at 12:14 AM, Andy Gross wrote:
>> Fix the following sparse warnings:
>>
>> drivers/staging/omapdrm/omap_dmm_tiler.c:123:13:
>>warning: symbol 'omap_dmm_irq_handler' was not declared.
>>Should it be static?
>>
>> drive
On Thu, Aug 9, 2012 at 10:26 PM, Rob Clark wrote:
> On Thu, Aug 9, 2012 at 12:14 AM, Andy Gross wrote:
>> Fix the following sparse warnings:
>>
>> drivers/staging/omapdrm/omap_dmm_tiler.c:123:13:
>>warning: symbol 'omap_dmm_irq_handler' was not declared.
>>Should it be static?
>>
>> drive
On Fri, Jul 20, 2012 at 10:09 PM, Rob Clark wrote:
> Fyi, Daniel Vetter had suggested on IRC that it would be cleaner to
> have a single helper fxn that most-restrictive union of all attached
> device's dma_parms. Really this should include dma_mask and
> coherent_dma_mask, I think. But that tou
On Fri, Jul 20, 2012 at 10:09 PM, Rob Clark wrote:
> Fyi, Daniel Vetter had suggested on IRC that it would be cleaner to
> have a single helper fxn that most-restrictive union of all attached
> device's dma_parms. Really this should include dma_mask and
> coherent_dma_mask, I think. But that tou
Hi Rob, Tomi,
On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark wrote:
> On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen
> wrote:
>> On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote:
>>> On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen
>>> wrote:
>>> > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote
Hi Rob, Tomi,
On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark wrote:
> On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen wrote:
>> On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote:
>>> On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen
>>> wrote:
>>> > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:
>
On Wed, Aug 1, 2012 at 3:02 PM, Chandrabhanu Mahapatra
wrote:
> The reclaim_buffers callback has already been removed by Daniel Vetter
> with his patch "drm: kill reclaim_buffers
> callback"
> for which the kernel compilation fails with omapdrm support. So, the callback
> for reclaim_buffers is
On Wed, Aug 1, 2012 at 3:02 PM, Chandrabhanu Mahapatra
wrote:
> The reclaim_buffers callback has already been removed by Daniel Vetter
> with his patch "drm: kill reclaim_buffers callback"
> for which the kernel compilation fails with omapdrm support. So, the callback
> for reclaim_buffers is rem
On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart
wrote:
> Hi Tomasz,
Hi Tomasz, Laurent, Mauro,
>
> On Wednesday 23 May 2012 14:10:14 Tomasz Stanislawski wrote:
>> Hello everyone,
>> This patchset adds support for DMABUF [2] importing to V4L2 stack.
>> The support for DMABUF exporting was moved t
On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart
wrote:
> Hi Tomasz,
Hi Tomasz, Laurent, Mauro,
>
> On Wednesday 23 May 2012 14:10:14 Tomasz Stanislawski wrote:
>> Hello everyone,
>> This patchset adds support for DMABUF [2] importing to V4L2 stack.
>> The support for DMABUF exporting was moved t
Hi Joonyoung,
On Thu, Apr 5, 2012 at 3:53 PM, Joonyoung Shim
wrote:
> Some defines and members in struct mixer_context aren't used, remove
> them.
>
> Signed-off-by: Joonyoung Shim
> Signed-off-by: Kyungmin Park
> ---
> ?drivers/gpu/drm/exynos/exynos_hdmi.c ?| ? ?1 -
> ?drivers/gpu/drm/exynos/
Hi Joonyoung,
On Thu, Apr 5, 2012 at 3:53 PM, Joonyoung Shim wrote:
> Some defines and members in struct mixer_context aren't used, remove
> them.
>
> Signed-off-by: Joonyoung Shim
> Signed-off-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 1 -
> drivers/gpu/drm/exynos/e
Hi Daniel,
On Tue, Mar 6, 2012 at 12:27 AM, Daniel Vetter
wrote:
> On Fri, Mar 2, 2012 at 23:24, Rob Clark wrote:
>> Perhaps we should check somewhere for required dmabuf ops fxns (like
>> kmap_atomic here), rather than just calling unconditionally what might
>> be a null ptr. ?At least put it i
Hi Daniel,
On Tue, Mar 6, 2012 at 12:27 AM, Daniel Vetter wrote:
> On Fri, Mar 2, 2012 at 23:24, Rob Clark wrote:
>> Perhaps we should check somewhere for required dmabuf ops fxns (like
>> kmap_atomic here), rather than just calling unconditionally what might
>> be a null ptr. At least put it in
Hello Laurent, Everyone:
On Fri, Feb 17, 2012 at 4:55 AM, Laurent Pinchart
wrote:
> Hello everybody,
>
> First of all, I would like to thank all the attendees for their participation
> in the mini-summit that helped make the meeting a success.
>
> *** ?dma-buf Implementation in V4L2 ***
>
> ?Go
Hello Laurent, Everyone:
On Fri, Feb 17, 2012 at 4:55 AM, Laurent Pinchart
wrote:
> Hello everybody,
>
> First of all, I would like to thank all the attendees for their participation
> in the mini-summit that helped make the meeting a success.
>
> *** dma-buf Implementation in V4L2 ***
>
> Go
Hi Laurent,
On Jan 30, 2012 7:48 PM, "Laurent Pinchart" <
laurent.pinchart at ideasonboard.com> wrote:
>
> Hi Sumit,
>
> On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
> > Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
> > enum dma_data_direction for both map and u
Hi Laurent,
On Jan 30, 2012 7:48 PM, "Laurent Pinchart" <
laurent.pinch...@ideasonboard.com> wrote:
>
> Hi Sumit,
>
> On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
> > Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
> > enum dma_data_direction for both map and unma
Please ignore! I will send out a new version in a minute.
Thanks and best regards,
~Sumit.
On Fri, Jan 27, 2012 at 3:04 PM, Sumit Semwal wrote:
> Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
> enum dma_data_direction while unmapping.
>
> Thus, the unmap dma_buf_op al
Please ignore! I will send out a new version in a minute.
Thanks and best regards,
~Sumit.
On Fri, Jan 27, 2012 at 3:04 PM, Sumit Semwal wrote:
> Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
> enum dma_data_direction while unmapping.
>
> Thus, the unmap dma_buf_op al
On Thu, Jan 26, 2012 at 1:37 AM, Daniel Vetter wrote:
> On Wed, Jan 25, 2012 at 06:02:41PM +0100, Tomasz Stanislawski wrote:
>> Hi Sumit,
>>
>> On 12/26/2011 10:23 AM, Sumit Semwal wrote:
>> >This is the first step in defining a dma buffer sharing mechanism.
>> >
>> [snip]
>>
>> >+struct sg_table
On Thu, Jan 26, 2012 at 1:37 AM, Daniel Vetter wrote:
> On Wed, Jan 25, 2012 at 06:02:41PM +0100, Tomasz Stanislawski wrote:
>> Hi Sumit,
>>
>> On 12/26/2011 10:23 AM, Sumit Semwal wrote:
>> >This is the first step in defining a dma buffer sharing mechanism.
>> >
>> [snip]
>>
>> >+struct sg_table
On Fri, Jan 20, 2012 at 6:53 PM, Laurent Pinchart
wrote:
> Hi Summit,
>
> Sorry for the late review. I know that this code is now in mainline, but I
> still have a couple of comments. I'll send patches if you agree with them.
Hi Laurent,
Thanks for your review; apologies for being late in replyin
On Sat, Jan 21, 2012 at 11:02 PM, Daniel Vetter wrote:
> On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
>> On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
>> > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell
>> > wrote:
>> > &
On Fri, Jan 20, 2012 at 6:53 PM, Laurent Pinchart
wrote:
> Hi Summit,
>
> Sorry for the late review. I know that this code is now in mainline, but I
> still have a couple of comments. I'll send patches if you agree with them.
Hi Laurent,
Thanks for your review; apologies for being late in replyin
On Sat, Jan 21, 2012 at 11:02 PM, Daniel Vetter wrote:
> On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
>> On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
>> > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell wrote:
>> > > EXPORT_SYMBOL_
Hi Linus,
Post the merge of dma-buf tree that was (very kindly) sent by Dave
Airlie, various people involved in this project feel it is natural and
practical for me to be the maintainer of this code.
This is my first pull request to you, which only changes the
MAINTAINERS file - could you please
Hi Linus,
Post the merge of dma-buf tree that was (very kindly) sent by Dave
Airlie, various people involved in this project feel it is natural and
practical for me to be the maintainer of this code.
This is my first pull request to you, which only changes the
MAINTAINERS file - could you please
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 infrastructure is
> explicitly intended as an interface between modules/drivers, so it
> should use EXPORT_SYMBOL ins
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 infrastructure is
> explicitly intended as an interface between modules/drivers, so it
> should use EXPORT_SYMBOL ins
On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark wrote:
> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote:
>> 2012/1/10 Rob Clark :
>> at least with no IOMMU, the memory information(containing physical
>> memory address) would be copied to vb2_xx_buf object if drm gem
>> exported its own buffer and vb2
On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark wrote:
> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote:
>> 2012/1/10 Rob Clark :
>> at least with no IOMMU, the memory information(containing physical
>> memory address) would be copied to vb2_xx_buf object if drm gem
>> exported its own buffer and vb2
On Fri, Dec 23, 2011 at 10:50 PM, Rob Clark wrote:
> On Fri, Dec 23, 2011 at 4:08 AM, Semwal, Sumit wrote:
>> On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie wrote:
>>
>>>>
>>>> Hence for both patches:
>>>> Reviewed-by: Daniel Vetter
&
On Fri, Dec 23, 2011 at 10:50 PM, Rob Clark wrote:
> On Fri, Dec 23, 2011 at 4:08 AM, Semwal, Sumit wrote:
>> On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie wrote:
>>
>>>>
>>>> Hence for both patches:
>>>> Reviewed-by: Daniel Vetter
&
On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie wrote:
>>
>> I think this is a really good v1 version of dma_buf. It contains all the
>> required bits (with well-specified semantics in the doc patch) to
>> implement some basic use-cases and start fleshing out the integration with
>> various subsyste
On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann wrote:
> On Tuesday 20 December 2011, Daniel Vetter wrote:
>> > I'm thinking for a first version, we can get enough mileage out of it by
>> > saying:
>> > 1) only exporter can mmap to userspace
>> > 2) only importers that do not need CPU access to b
Hi Konrad,
On Tue, Dec 20, 2011 at 10:06 PM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>>
>> A new buffer object dma_buf is added, with operations and API to allow easy
>> shar
On Wed, Dec 21, 2011 at 3:56 AM, Rob Clark wrote:
> On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie wrote:
>>>
>>> I think this is a really good v1 version of dma_buf. It contains all the
>>> required bits (with well-specified semantics in the doc patch) to
>>> implement some basic use-cases a
On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie wrote:
>>
>> I think this is a really good v1 version of dma_buf. It contains all the
>> required bits (with well-specified semantics in the doc patch) to
>> implement some basic use-cases and start fleshing out the integration with
>> various subsyste
On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann wrote:
> On Tuesday 20 December 2011, Daniel Vetter wrote:
>> > I'm thinking for a first version, we can get enough mileage out of it by
>> > saying:
>> > 1) only exporter can mmap to userspace
>> > 2) only importers that do not need CPU access to b
Hi Konrad,
On Tue, Dec 20, 2011 at 10:06 PM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>>
>> A new buffer object dma_buf is added, with operations and API to allow easy
>> shar
On Wed, Dec 21, 2011 at 3:56 AM, Rob Clark wrote:
> On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie wrote:
>>>
>>> I think this is a really good v1 version of dma_buf. It contains all the
>>> required bits (with well-specified semantics in the doc patch) to
>>> implement some basic use-cases a
Hi Arnd, Daniel,
On Mon, Dec 12, 2011 at 10:18 PM, Arnd Bergmann wrote:
> On Saturday 10 December 2011, Daniel Vetter wrote:
>> If userspace (through some driver calls)
>> tries to do stupid things, it'll just get garbage. See
>> Message-ID: > mail.gmail.com>
>> for my reasons why it think this i
Hi Arnd, Daniel,
On Mon, Dec 12, 2011 at 10:18 PM, Arnd Bergmann wrote:
> On Saturday 10 December 2011, Daniel Vetter wrote:
>> If userspace (through some driver calls)
>> tries to do stupid things, it'll just get garbage. See
>> Message-ID:
>>
>> for my reasons why it think this is the right w
Hi Daniel, Rob,
On Tue, Dec 6, 2011 at 3:41 AM, Rob Clark wrote:
> On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter wrote:
>> On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
>>> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
>>> > In the patch 2, you have a section about migrati
On Wed, Dec 7, 2011 at 3:41 PM, Arnd Bergmann wrote:
> On Wednesday 07 December 2011, Semwal, Sumit wrote:
>> >
>> > Do you have a use case for making the interface compile-time disabled?
>> > I had assumed that any code using it would make no sense if it
Hi Arnd,
Thanks for your review!
On Mon, Dec 5, 2011 at 10:48 PM, Arnd Bergmann wrote:
> On Friday 02 December 2011, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>
> This looks very nice, but there are a few things I don't understand yet
> and a bunch
Hi Daniel, Rob,
On Tue, Dec 6, 2011 at 3:41 AM, Rob Clark wrote:
> On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter wrote:
>> On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
>>> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
>>> > In the patch 2, you have a section about migrati
On Wed, Dec 7, 2011 at 3:41 PM, Arnd Bergmann wrote:
> On Wednesday 07 December 2011, Semwal, Sumit wrote:
>> >
>> > Do you have a use case for making the interface compile-time disabled?
>> > I had assumed that any code using it would make no sense if it
Hi Arnd,
Thanks for your review!
On Mon, Dec 5, 2011 at 10:48 PM, Arnd Bergmann wrote:
> On Friday 02 December 2011, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>
> This looks very nice, but there are a few things I don't understand yet
> and a bunch
Hi Konrad,
On Fri, Dec 2, 2011 at 10:41 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Dec 02, 2011 at 02:27:31PM +0530, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>>
>>
>> [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
>> [2]: http://lwn.net
Hi Konrad,
On Fri, Dec 2, 2011 at 10:41 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Dec 02, 2011 at 02:27:31PM +0530, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>>
>>
>> [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
>> [2]: http://lwn.net
Hi Dave, Daniel, Rob,
>
> On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark wrote:
>>
>> On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter wrote:
>> > On Fri, Nov 25, 2011 at 17:28, Dave Airlie wrote:
>> >> I've rebuilt my PRIME interface on top of dmabuf to see how it would
>> >> work,
>> >>
>> >> I've
Hi Dave, Daniel, Rob,
On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark wrote:
> On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter wrote:
> > On Fri, Nov 25, 2011 at 17:28, Dave Airlie wrote:
> >> I've rebuilt my PRIME interface on top of dmabuf to see how it would
> work,
> >>
> >> I've got primed gea
Hi Dave, Daniel, Rob,
>
> On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark wrote:
>>
>> On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter wrote:
>> > On Fri, Nov 25, 2011 at 17:28, Dave Airlie wrote:
>> >> I've rebuilt my PRIME interface on top of dmabuf to see how it would
>> >> work,
>> >>
>> >> I've
Hi Dave, Daniel, Rob,
On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark wrote:
> On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter wrote:
> > On Fri, Nov 25, 2011 at 17:28, Dave Airlie wrote:
> >> I've rebuilt my PRIME interface on top of dmabuf to see how it would
> work,
> >>
> >> I've got primed gea
Hi Randy,
On Thu, Oct 13, 2011 at 4:00 AM, Randy Dunlap wrote:
> On 10/11/2011 02:23 AM, Sumit Semwal wrote:
>> Add documentation for dma buffer sharing framework, explaining the
>> various operations, members and API of the dma buffer sharing
>> framework.
>>
>> Signed-off-by: Sumit Semwal
>> Si
Hi Randy,
On Thu, Oct 13, 2011 at 4:00 AM, Randy Dunlap wrote:
> On 10/11/2011 02:23 AM, Sumit Semwal wrote:
>> Add documentation for dma buffer sharing framework, explaining the
>> various operations, members and API of the dma buffer sharing
>> framework.
>>
>> Signed-off-by: Sumit Semwal
>> Si
60 matches
Mail list logo
