public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: edgar.iglesias@gmail.com (Edgar E. Iglesias)
To: linux-arm-kernel@lists.infradead.org
Subject: RPmsg, DMA and ARM64
Date: Fri, 27 Mar 2015 02:01:36 +1000	[thread overview]
Message-ID: <20150326160136.GC30197@toto> (raw)
In-Reply-To: <20150326152607.GM8656@n2100.arm.linux.org.uk>

On Thu, Mar 26, 2015 at 03:26:07PM +0000, Russell King - ARM Linux wrote:
> On Tue, Mar 24, 2015 at 02:37:49PM +1000, Edgar E. Iglesias wrote:
> > I'm trying to run rpmsg and remoteproc on the ZynqMP but hitting an mm error.
> > I'm not sure who is breaking the rules, rpmsg or the dma allocators?
> > 
> > When rpmsg sets up the virtqueues, it allocates memory with
> > dma_alloc_coherent() and initializes a scatterlist with sg_init_one().
> > drivers/rpmsg/virtio_rpmsg_bus.c:rpmsg_probe().
> > sg_init_one() requires that the memory it gets is virt_addr_valid().
> > 
> > The problem I'm seeing is that on arm64, the dma alloc functions can
> > return vmalloced (via dma_common_contiguous_remap) memory. This
> > then causes havoc when the scatterlist code tries to go virt_to_page
> > and back to get hold of a physical adress (sg_phys()).
> 
> dma_alloc_coherent() is permitted to remap the memory which it returns;
> it's allowed not to be part of the linear mapping.  The underlying
> memory could even be sourced from highmem and mapped in on demand.
> 
> This means that using virt_to_page() et.al. on the return value from
> dma_alloc_coherent() is not permitted.

Thanks Russel, that's info is of great help.

> 
> The only way to pass such memory using scatterlists is by doing:
> 
> 	sg_init_table(sg, 1);
> 	sg_dma_address(sg) = addr;
> 	sg_dma_length(sg) = length;
> 
> Such a scatterlist must _never_ have the dma_(map|unmap|sync)_sg*()
> functions called on it - the only operations which would be permissible
> is to walk the scatterlist, and access it using the standard DMA
> accessors sg_dma_address() and sg_dma_length().

I'll have a closer look and see if I can change rpmsg to deal with
this.

Cheers,
Edgar

  reply	other threads:[~2015-03-26 16:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-24  4:37 RPmsg, DMA and ARM64 Edgar E. Iglesias
2015-03-25 15:36 ` Catalin Marinas
2015-03-26  1:30   ` Edgar E. Iglesias
2015-03-26 15:26 ` Russell King - ARM Linux
2015-03-26 16:01   ` Edgar E. Iglesias [this message]
2015-03-26 16:15     ` Russell King - ARM Linux

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=20150326160136.GC30197@toto \
    --to=edgar.iglesias@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox