linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Punit Agrawal <punit.agrawal@arm.com>
Cc: linux-doc@vger.kernel.org, will.deacon@arm.com,
	robin.murphy@arm.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, arnd@arndb.de,
	joro@8bytes.org, dwmw2@infradead.org
Subject: Re: [PATCH] Documentation: DMA-API: Clarify semantics of dma_set_mask_and_coherent
Date: Fri, 21 Oct 2016 15:09:16 -0600	[thread overview]
Message-ID: <20161021150916.0d274e9f@lwn.net> (raw)
In-Reply-To: <20161017152623.7649-1-punit.agrawal@arm.com>

On Mon, 17 Oct 2016 16:26:23 +0100
Punit Agrawal <punit.agrawal@arm.com> wrote:

> The dma mapping api howto gives the impression that using the
> dma_set_mask_and_coherent (and related DMA APIs) will cause the kernel
> to check all the components in the path from the device to memory for
> addressing restrictions. In systems with address translations between
> the device and memory (e.g., when using IOMMU), this implies that a
> successful call to set set dma mask has checked the addressing
> constraints of the intermediaries as well.
> 
> For the IOMMU drivers in the tree, the check is actually performed while
> allocating the DMA buffer rather than when the DMA mask is
> configured. For MMUs that do not support the full device addressing
> capability, the allocations are made from a reduced address space.
> 
> Update the documentation to clarify that even though the call to
> dma_set_mask_and_coherent succeeds, it may not be possible to use the
> full addressing capability of the device.

OK, so I guess I can buy this.  But...

> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> ---
>  Documentation/DMA-API-HOWTO.txt | 39 +++++++++++++++++++++++----------------
>  1 file changed, 23 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
> index 979228b..240d1ee 100644
> --- a/Documentation/DMA-API-HOWTO.txt
> +++ b/Documentation/DMA-API-HOWTO.txt
> @@ -159,39 +159,46 @@ support 64-bit addressing (DAC) for all transactions.  And at least
>  one platform (SGI SN2) requires 64-bit consistent allocations to
>  operate correctly when the IO bus is in PCI-X mode.
>  
> -For correct operation, you must interrogate the kernel in your device
> -probe routine to see if the DMA controller on the machine can properly
> -support the DMA addressing limitation your device has.  It is good
> +For correct operation, you must inform the kernel in your device probe
> +routine to see if the DMA controller on the machine can properly
> +support the DMA addressing capabilities your device has.  It is good

Here it's still saying "to see if the DMA controller on the machine can
properly support the DMA addressing capabilities your device has".  So
you've not really changed the sense of this sentence here.

If I understand things correctly, the calls in question are storing the
device's limitations; they will only fail if the kernel is entirely
unable to work within the indicated range, right?  I don't think there's
ever been any guarantee that the system as a whole could use the entire
range that is addressable by the device.  I have no objection to making
that more clear, but let's actually make it more clear by saying what the
functions are actually doing.

Make sense, or am I missing something here?

Thanks,

jon

  reply	other threads:[~2016-10-21 21:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17 15:26 [PATCH] Documentation: DMA-API: Clarify semantics of dma_set_mask_and_coherent Punit Agrawal
2016-10-21 21:09 ` Jonathan Corbet [this message]
2016-10-24 11:08   ` Joerg Roedel
2016-10-24 11:37     ` Punit Agrawal
2016-10-24 11:51   ` Punit Agrawal
2016-10-24 14:44   ` Arnd Bergmann

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=20161021150916.0d274e9f@lwn.net \
    --to=corbet@lwn.net \
    --cc=arnd@arndb.de \
    --cc=dwmw2@infradead.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=punit.agrawal@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=will.deacon@arm.com \
    /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;
as well as URLs for NNTP newsgroup(s).