All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: For the problem when using swiotlb
Date: Mon, 24 Nov 2014 21:12:09 +0100	[thread overview]
Message-ID: <2166613.l2i4mdmtLA@wuerfel> (raw)
In-Reply-To: <20141121180925.GG19783@e104818-lin.cambridge.arm.com>

On Friday 21 November 2014 18:09:25 Catalin Marinas wrote:
> On Fri, Nov 21, 2014 at 05:51:19PM +0000, Catalin Marinas wrote:
> > On Fri, Nov 21, 2014 at 05:04:28PM +0000, Arnd Bergmann wrote:
> > > On Friday 21 November 2014 16:57:09 Catalin Marinas wrote:
> > > > There is a scenario where smaller mask would work on arm64. For example
> > > > Juno, you can have 2GB of RAM in the 32-bit phys range (starting at
> > > > 0x80000000). A device with 31-bit mask and a dma_pfn_offset of
> > > > 0x80000000 would still work (there isn't any but just as an example). So
> > > > the check in dma_alloc_coherent() would be something like:
> > > > 
> > > > 	phys_to_dma(top of ZONE_DMA) - dma_pfn_offset <= coherent_dma_mask
> > > > 
> > > > (or assuming RAM starts at 0 and ignoring dma_pfn_offset for now)
> > > > 
> > > > If the condition above fails, dma_alloc_coherent() would no longer fall
> > > > back to swiotlb but issue a dev_warn() and return NULL.
> > > 
> > > Ah, that looks like it should work on all architectures, very nice.
> > > How about checking this condition, and then printing a small warning
> > > (dev_warn, not WARN_ON) and setting the dma_mask pointer to NULL?
> > 
> > I would not add the above ZONE_DMA check to of_dma_configure(). For
> > example on arm64, we may not support a small coherent_dma_mask but the
> > same value for dma_mask could be fine via swiotlb bouncing (or IOMMU).
> > However, that's an arch-specific decision. Maybe after the above setting
> > of dev->coherent_dma_mask in of_dma_configure(), we could add:
> > 

You seem to implement the opposite:

> +	/*
> +	 * If the bus dma-ranges property specifies a size smaller than 4GB,
> +	 * the device would not be capable of accessing the whole 32-bit
> +	 * space, so reduce the default coherent_dma_mask accordingly.
> +	 */
> +	if (size && size < (1ULL << 32))
> +		dev->coherent_dma_mask = DMA_BIT_MASK(ilog2(size));
> +
> +	/*
> +	 * Set dma_mask to coherent_dma_mask by default if the architecture
> +	 * code has not set it and DMA on such mask is supported.
> +	 */
> +	if (!dev->dma_mask && dma_supported(dev, dev->coherent_dma_mask))
> +		dev->dma_mask = &dev->coherent_dma_mask;
>  }
>  

Here, coherent_dma_mask wouldn't work while dma_mask might be
fine in case of swiotlb, but you set a nonzero coherent_dma_mask
and an invalid dma_mask.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ding Tianhong <dingtianhong@huawei.com>
Subject: Re: For the problem when using swiotlb
Date: Mon, 24 Nov 2014 21:12:09 +0100	[thread overview]
Message-ID: <2166613.l2i4mdmtLA@wuerfel> (raw)
In-Reply-To: <20141121180925.GG19783@e104818-lin.cambridge.arm.com>

On Friday 21 November 2014 18:09:25 Catalin Marinas wrote:
> On Fri, Nov 21, 2014 at 05:51:19PM +0000, Catalin Marinas wrote:
> > On Fri, Nov 21, 2014 at 05:04:28PM +0000, Arnd Bergmann wrote:
> > > On Friday 21 November 2014 16:57:09 Catalin Marinas wrote:
> > > > There is a scenario where smaller mask would work on arm64. For example
> > > > Juno, you can have 2GB of RAM in the 32-bit phys range (starting at
> > > > 0x80000000). A device with 31-bit mask and a dma_pfn_offset of
> > > > 0x80000000 would still work (there isn't any but just as an example). So
> > > > the check in dma_alloc_coherent() would be something like:
> > > > 
> > > > 	phys_to_dma(top of ZONE_DMA) - dma_pfn_offset <= coherent_dma_mask
> > > > 
> > > > (or assuming RAM starts at 0 and ignoring dma_pfn_offset for now)
> > > > 
> > > > If the condition above fails, dma_alloc_coherent() would no longer fall
> > > > back to swiotlb but issue a dev_warn() and return NULL.
> > > 
> > > Ah, that looks like it should work on all architectures, very nice.
> > > How about checking this condition, and then printing a small warning
> > > (dev_warn, not WARN_ON) and setting the dma_mask pointer to NULL?
> > 
> > I would not add the above ZONE_DMA check to of_dma_configure(). For
> > example on arm64, we may not support a small coherent_dma_mask but the
> > same value for dma_mask could be fine via swiotlb bouncing (or IOMMU).
> > However, that's an arch-specific decision. Maybe after the above setting
> > of dev->coherent_dma_mask in of_dma_configure(), we could add:
> > 

You seem to implement the opposite:

> +	/*
> +	 * If the bus dma-ranges property specifies a size smaller than 4GB,
> +	 * the device would not be capable of accessing the whole 32-bit
> +	 * space, so reduce the default coherent_dma_mask accordingly.
> +	 */
> +	if (size && size < (1ULL << 32))
> +		dev->coherent_dma_mask = DMA_BIT_MASK(ilog2(size));
> +
> +	/*
> +	 * Set dma_mask to coherent_dma_mask by default if the architecture
> +	 * code has not set it and DMA on such mask is supported.
> +	 */
> +	if (!dev->dma_mask && dma_supported(dev, dev->coherent_dma_mask))
> +		dev->dma_mask = &dev->coherent_dma_mask;
>  }
>  

Here, coherent_dma_mask wouldn't work while dma_mask might be
fine in case of swiotlb, but you set a nonzero coherent_dma_mask
and an invalid dma_mask.

	Arnd

  reply	other threads:[~2014-11-24 20:12 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-17 11:56 For the problem when using swiotlb Ding Tianhong
2014-11-17 11:56 ` Ding Tianhong
2014-11-17 12:18 ` Arnd Bergmann
2014-11-17 12:18   ` Arnd Bergmann
2014-11-17 18:09   ` Catalin Marinas
2014-11-17 18:09     ` Catalin Marinas
2014-11-19  3:17     ` Ding Tianhong
2014-11-19  3:17       ` Ding Tianhong
2014-11-19  8:45       ` Arnd Bergmann
2014-11-19  8:45         ` Arnd Bergmann
2014-11-19 11:29         ` Catalin Marinas
2014-11-19 11:29           ` Catalin Marinas
2014-11-19 12:48           ` Arnd Bergmann
2014-11-19 12:48             ` Arnd Bergmann
2014-11-19 15:46             ` Catalin Marinas
2014-11-19 15:46               ` Catalin Marinas
2014-11-19 15:56               ` Arnd Bergmann
2014-11-19 15:56                 ` Arnd Bergmann
2014-11-21 11:06                 ` Catalin Marinas
2014-11-21 11:06                   ` Catalin Marinas
2014-11-21 11:26                   ` Arnd Bergmann
2014-11-21 11:26                     ` Arnd Bergmann
2014-11-21 11:36                     ` Catalin Marinas
2014-11-21 11:36                       ` Catalin Marinas
2014-11-21 12:27                       ` Arnd Bergmann
2014-11-21 12:27                         ` Arnd Bergmann
2014-11-20  2:57         ` Ding Tianhong
2014-11-20  2:57           ` Ding Tianhong
2014-11-20  7:40           ` Arnd Bergmann
2014-11-20  7:40             ` Arnd Bergmann
2014-11-20  8:34             ` Ding Tianhong
2014-11-20  8:34               ` Ding Tianhong
2014-11-20  9:02               ` Arnd Bergmann
2014-11-20  9:02                 ` Arnd Bergmann
2014-11-20  9:21                 ` Ding Tianhong
2014-11-20  9:21                   ` Ding Tianhong
2014-11-21  9:35             ` Catalin Marinas
2014-11-21  9:35               ` Catalin Marinas
2014-11-21 10:32               ` Catalin Marinas
2014-11-21 10:32                 ` Catalin Marinas
2014-11-21 12:48               ` Arnd Bergmann
2014-11-21 12:48                 ` Arnd Bergmann
2014-11-21 16:57                 ` Catalin Marinas
2014-11-21 16:57                   ` Catalin Marinas
2014-11-21 17:04                   ` Arnd Bergmann
2014-11-21 17:04                     ` Arnd Bergmann
2014-11-21 17:51                     ` Catalin Marinas
2014-11-21 17:51                       ` Catalin Marinas
2014-11-21 18:09                       ` Catalin Marinas
2014-11-21 18:09                         ` Catalin Marinas
2014-11-24 20:12                         ` Arnd Bergmann [this message]
2014-11-24 20:12                           ` Arnd Bergmann
2014-11-25 10:58                           ` Catalin Marinas
2014-11-25 10:58                             ` Catalin Marinas
2014-11-25 11:29                             ` Russell King - ARM Linux
2014-11-25 11:29                               ` Russell King - ARM Linux
2014-11-25 12:23                               ` Catalin Marinas
2014-11-25 12:23                                 ` Catalin Marinas
2014-11-27  2:36                                 ` Ding Tianhong
2014-11-27  2:36                                   ` Ding Tianhong

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=2166613.l2i4mdmtLA@wuerfel \
    --to=arnd@arndb.de \
    --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.