All of lore.kernel.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 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.