All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>
To: linux-sh@vger.kernel.org
Subject: Re: [RFC 0/4] dmaengine: rcar-dmac: add iommu support for slave transfers
Date: Mon, 11 Jan 2016 02:31:12 +0000	[thread overview]
Message-ID: <20160111023112.GC31780@bigcity.dyn.berto.se> (raw)
In-Reply-To: <1452241386-22830-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Hi Geert,

* Geert Uytterhoeven <geert@linux-m68k.org> [2016-01-08 10:28:22 +0100]:

> Hi Niklas,
>
> On Fri, Jan 8, 2016 at 9:23 AM, Niklas Söderlund
> <niklas.soderlund@ragnatech.se> wrote:
> > What I'm most concerned about is that I could not find a good way too
> > keep track of mappings from different DMA channels to the same address
> > so that they could properly be unmapped. This issue is due to that two
> > channels might both try to map the same address (think rx/tx pair) and
> > that would make it unsafe for any one of the channels to unmap the
> > address without knowing if it's in use by the other.
> >
> > A follow up problem to this is that if the same address is mapped from
> > two different channels but with different sizes and the larger size is
> > tried last. If such a condition should happen and the larger size is so
> > large that it crosses a page boundary there would be trouble.
> >
> > An obvious solution to both problem would be to map address to different
> > iova:s in each channel and keep track of the unique mapping. That way
> > all the above problems would go away. The problem is I can't figure out
> > how to allocate a unique iova to feed to iommu_map.
>
> What about
>   1. Reference counting the mappings,
>   2. Returning -EBUSY if the same address is already mapped with a
>      different size? In the case of RX/TX pairs, the size should be the same
>      (one page).

Thanks for the pointers Geert. I did a implementation using reference
counting, it worked but got quiet messy, it was however not all a waste.
I learned that the dma-mapper api is way smarter then me and provided a
interface that solves multiple mappings of the same address.

// Niklas

      parent reply	other threads:[~2016-01-11  2:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-08  8:23 [RFC 0/4] dmaengine: rcar-dmac: add iommu support for slave transfers Niklas Söderlund
2016-01-08  9:28 ` Geert Uytterhoeven
2016-01-11  2:31 ` Niklas Söderlund [this message]

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=20160111023112.GC31780@bigcity.dyn.berto.se \
    --to=niklas.soderlund@ragnatech.se \
    --cc=linux-sh@vger.kernel.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.