Hi Russell, everyone,
First up, sincere apologies for being awol for sometime; had some
personal / medical things to take care of, and then I thought I'd wait
for the merge window to get over before beginning to discuss this
again.
On 11 February 2015 at 21:53, Russell King - ARM Linux
On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote:
Hello,
On 2015-02-11 12:12, Russell King - ARM Linux wrote:
Which is a damn good reason to NAK it - by that admission, it's a half-baked
idea.
If all we want to know is whether the importer can accept only contiguous
Hello,
On 2015-01-27 09:25, Sumit Semwal wrote:
Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.
At each attach, the constraints are calculated based on the following:
- max_segment_size, max_segment_count, segment_boundary_mask from
On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote:
Hello,
On 2015-01-27 09:25, Sumit Semwal wrote:
Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.
At each attach, the constraints are calculated based on the following:
-
On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote:
Hello,
On 2015-01-27 09:25, Sumit Semwal wrote:
Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.
Hello,
On 2015-02-11 12:12, Russell King - ARM Linux wrote:
On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote:
On 2015-01-27 09:25, Sumit Semwal wrote:
Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.
At each attach, the constraints
On Wed, Feb 11, 2015 at 06:23:52AM -0500, Rob Clark wrote:
On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
As I've already pointed out, there's a major problem if you have already
had a less restrictive attachment which has an active mapping, and a new
On Wed, Feb 11, 2015 at 7:56 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Feb 11, 2015 at 06:23:52AM -0500, Rob Clark wrote:
On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
As I've already pointed out, there's a major problem if you have already
On Tue, Feb 03, 2015 at 02:28:26PM +0100, Christian Gmeiner wrote:
2015-02-03 13:28 GMT+01:00 Russell King - ARM Linux li...@arm.linux.org.uk:
What I've found with *my* etnaviv drm implementation (not Christian's - I
found it impossible to work with Christian, especially with the endless
On Tue, Feb 03, 2015 at 09:04:03AM -0500, Rob Clark wrote:
Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
drop use of dma-mapping entirely (incl the current call to dma_map_sg,
which I just need until we can use drm_cflush on arm), and
attach/detach iommu domains directly
On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote:
On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
drop use of dma-mapping entirely (incl the current call to dma_map_sg,
which I just need until we can use
On Tue, Feb 3, 2015 at 9:37 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 03, 2015 at 09:04:03AM -0500, Rob Clark wrote:
Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
drop use of dma-mapping entirely (incl the current call to dma_map_sg,
which I
On Tue, Feb 3, 2015 at 9:41 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote:
On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
drop use of
On Tue, Feb 3, 2015 at 9:52 AM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote:
On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
Since I'm stuck w/ an iommu, instead
On Tue, Feb 03, 2015 at 03:52:48PM +0100, Arnd Bergmann wrote:
On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
I'd go as far as saying that the DMA API on top of IOMMU is more
intended to be for a system IOMMU for the bus in question, rather
than a device-level IOMMU.
On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote:
On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
drop use of dma-mapping entirely
On Tue, Feb 03, 2015 at 09:44:57AM -0500, Rob Clark wrote:
On Tue, Feb 3, 2015 at 9:37 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 03, 2015 at 09:04:03AM -0500, Rob Clark wrote:
Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
drop use of
On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote:
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
My initial thought is for dma-buf to not try to prevent something than
an exporter can actually
On Tue, Feb 03, 2015 at 12:28:14PM +, Russell King - ARM Linux wrote:
On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote:
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
My initial thought is
On Tue, Feb 3, 2015 at 7:28 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote:
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
My initial
On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
On Tue, Feb 3, 2015 at 2:48 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
My initial thought is for dma-buf to
2015-02-03 13:28 GMT+01:00 Russell King - ARM Linux li...@arm.linux.org.uk:
On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote:
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
My initial thought is
On Tue, Feb 3, 2015 at 2:48 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
My initial thought is for dma-buf to not try to prevent something than
an exporter can
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
My initial thought is for dma-buf to not try to prevent something than
an exporter can actually do.. I think the scenario you describe could
be handled by two sg-lists, if the exporter was clever enough.
That's already
On Mon, Feb 2, 2015 at 4:46 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
My initial thought is for dma-buf to not try to prevent something than
an
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
My initial thought is for dma-buf to not try to prevent something than
an exporter can actually do.. I think the scenario you describe could
be handled by two
On Mon, Feb 02, 2015 at 05:36:10PM -0500, Rob Clark wrote:
well, I guess anyways when it comes to sharing buffers, it won't be
the vram placement of the bo that gets shared ;-)
Actually that's pretty much what I'd like to be able to do for i915.
Except that vram is just a specially protected
On Mon, Feb 02, 2015 at 09:46:16PM +, Russell King - ARM Linux wrote:
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
My initial thought is for dma-buf to not try to prevent something than
an exporter can
On Thu, Jan 29, 2015 at 05:18:33PM -0500, Rob Clark wrote:
On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
Quite possibly for some of these edge some of cases, some of the
dma-buf exporters
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote:
My initial thought is for dma-buf to not try to prevent something than
an exporter can actually do.. I think the scenario you describe could
be handled by two
Hi Russell,
On 30 January 2015 at 00:56, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
Quite possibly for some of these edge some of cases, some of the
dma-buf exporters are going to need to get more clever (ie. hand off
On 29 January 2015 at 21:17, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
So, short answer is, it is left to the exporter to decide. The dma-buf
framework should not even attempt to decide or enforce any of the
above.
At
Hi Russell!
On 29 January 2015 at 20:09, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote:
+/*
+ * recalc_constraints - recalculates constraints for all attached devices;
+ * useful for detach() recalculation, and for
Op 27-01-15 om 09:25 schreef Sumit Semwal:
Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.
At each attach, the constraints are calculated based on the following:
- max_segment_size, max_segment_count, segment_boundary_mask from
On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote:
+/*
+ * recalc_constraints - recalculates constraints for all attached devices;
+ * useful for detach() recalculation, and for dma_buf_recalc_constraints()
+ * helper.
+ * Returns recalculated constraints in recalc_cons, or
On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
So, short answer is, it is left to the exporter to decide. The dma-buf
framework should not even attempt to decide or enforce any of the
above.
At each dma_buf_attach(), there's a callback to the exporter, where
the exporter can
On Thu, Jan 29, 2015 at 10:47 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
So, short answer is, it is left to the exporter to decide. The dma-buf
framework should not even attempt to decide or enforce any of the
above.
On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
Quite possibly for some of these edge some of cases, some of the
dma-buf exporters are going to need to get more clever (ie. hand off
different scatterlists to different clients). Although I think by far
the two common cases will be I
On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
Quite possibly for some of these edge some of cases, some of the
dma-buf exporters are going to need to get more clever (ie. hand off
different
On Thu, Jan 29, 2015 at 05:18:33PM -0500, Rob Clark wrote:
On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Now, if we're going to do the more clever thing you mention above,
that rather negates the point of this two-part patch set, which is to
On Thu, Jan 29, 2015 at 5:31 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jan 29, 2015 at 05:18:33PM -0500, Rob Clark wrote:
On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Now, if we're going to do the more clever thing you
41 matches
Mail list logo
