All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv6 0/5] DMA Atomic pool for arm64
Date: Mon, 11 Aug 2014 10:30:24 +0100	[thread overview]
Message-ID: <20140811093024.GF15344@arm.com> (raw)
In-Reply-To: <1407529848-6806-1-git-send-email-lauraa@codeaurora.org>

On Fri, Aug 08, 2014 at 09:30:48PM +0100, Laura Abbott wrote:
> Hi,
> 
> This is v6 of the series to add an atomic pool for arm64 and refactor some of
> the arm dma_atomic code as well.
> 
> Russell, assuming you have no issues I'd like to get your Acked-by before
> Catalin picks this up. As always, testing and reviews are appreiciated.
> 
> Thanks,
> Laura
> 
> 
> v6: Tweaked the commit text to clarify that arm is moving from
> ioremap_page_range to map_vm_area and friends
> 
> v5: v4: Addressed comments from Thierry and Catalin. Updated map_vm_area call in
> dma_common_pages_remap since the API changed.
> 
> v4: Simplified the logic in gen_pool_first_fit_order_align which makes the
> data argument actually unused.
> 
> v3: Now a patch series due to refactoring of arm code. arm and arm64 now both
> use genalloc for atomic pool management. genalloc extensions added.
> DMA remapping code factored out as well.
> 
> v2: Various bug fixes pointed out by David and Ritesh (CMA dependency, swapping
> coherent, noncoherent). I'm still not sure how to address the devicetree
> suggestion by Will [1][2]. I added the devicetree mailing list this time around
> to get more input on this.
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249180.html
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249528.html

FWIW: I don't think the device-tree comments need to block this series. I
was just curious as to why they weren't being used.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Laura Abbott <lauraa@codeaurora.org>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
	Russell King <linux@arm.linux.org.uk>,
	David Riley <davidriley@chromium.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Ritesh Harjain <ritesh.harjani@gmail.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCHv6 0/5] DMA Atomic pool for arm64
Date: Mon, 11 Aug 2014 10:30:24 +0100	[thread overview]
Message-ID: <20140811093024.GF15344@arm.com> (raw)
In-Reply-To: <1407529848-6806-1-git-send-email-lauraa@codeaurora.org>

On Fri, Aug 08, 2014 at 09:30:48PM +0100, Laura Abbott wrote:
> Hi,
> 
> This is v6 of the series to add an atomic pool for arm64 and refactor some of
> the arm dma_atomic code as well.
> 
> Russell, assuming you have no issues I'd like to get your Acked-by before
> Catalin picks this up. As always, testing and reviews are appreiciated.
> 
> Thanks,
> Laura
> 
> 
> v6: Tweaked the commit text to clarify that arm is moving from
> ioremap_page_range to map_vm_area and friends
> 
> v5: v4: Addressed comments from Thierry and Catalin. Updated map_vm_area call in
> dma_common_pages_remap since the API changed.
> 
> v4: Simplified the logic in gen_pool_first_fit_order_align which makes the
> data argument actually unused.
> 
> v3: Now a patch series due to refactoring of arm code. arm and arm64 now both
> use genalloc for atomic pool management. genalloc extensions added.
> DMA remapping code factored out as well.
> 
> v2: Various bug fixes pointed out by David and Ritesh (CMA dependency, swapping
> coherent, noncoherent). I'm still not sure how to address the devicetree
> suggestion by Will [1][2]. I added the devicetree mailing list this time around
> to get more input on this.
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249180.html
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249528.html

FWIW: I don't think the device-tree comments need to block this series. I
was just curious as to why they weren't being used.

Will

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Laura Abbott <lauraa@codeaurora.org>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
	Russell King <linux@arm.linux.org.uk>,
	David Riley <davidriley@chromium.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Ritesh Harjain <ritesh.harjani@gmail.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCHv6 0/5] DMA Atomic pool for arm64
Date: Mon, 11 Aug 2014 10:30:24 +0100	[thread overview]
Message-ID: <20140811093024.GF15344@arm.com> (raw)
In-Reply-To: <1407529848-6806-1-git-send-email-lauraa@codeaurora.org>

On Fri, Aug 08, 2014 at 09:30:48PM +0100, Laura Abbott wrote:
> Hi,
> 
> This is v6 of the series to add an atomic pool for arm64 and refactor some of
> the arm dma_atomic code as well.
> 
> Russell, assuming you have no issues I'd like to get your Acked-by before
> Catalin picks this up. As always, testing and reviews are appreiciated.
> 
> Thanks,
> Laura
> 
> 
> v6: Tweaked the commit text to clarify that arm is moving from
> ioremap_page_range to map_vm_area and friends
> 
> v5: v4: Addressed comments from Thierry and Catalin. Updated map_vm_area call in
> dma_common_pages_remap since the API changed.
> 
> v4: Simplified the logic in gen_pool_first_fit_order_align which makes the
> data argument actually unused.
> 
> v3: Now a patch series due to refactoring of arm code. arm and arm64 now both
> use genalloc for atomic pool management. genalloc extensions added.
> DMA remapping code factored out as well.
> 
> v2: Various bug fixes pointed out by David and Ritesh (CMA dependency, swapping
> coherent, noncoherent). I'm still not sure how to address the devicetree
> suggestion by Will [1][2]. I added the devicetree mailing list this time around
> to get more input on this.
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249180.html
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249528.html

FWIW: I don't think the device-tree comments need to block this series. I
was just curious as to why they weren't being used.

Will

  reply	other threads:[~2014-08-11  9:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08 20:30 [PATCHv6 0/5] DMA Atomic pool for arm64 Laura Abbott
2014-08-08 20:30 ` Laura Abbott
2014-08-08 20:30 ` Laura Abbott
2014-08-11  9:30 ` Will Deacon [this message]
2014-08-11  9:30   ` Will Deacon
2014-08-11  9:30   ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140811093024.GF15344@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.