Linux Renesas SOC kernel development
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Nikita Yushchenko <nikita.yoush@cogentembedded.com>,
	Will Deacon <will.deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-renesas-soc@vger.kernel.org,
	Simon Horman <horms@verge.net.au>,
	Bjorn Helgaas <bhelgaas@google.com>,
	fkan@apm.com
Subject: Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports
Date: Wed, 11 Jan 2017 11:54:37 +0000	[thread overview]
Message-ID: <57459a4a-2c57-e081-8f27-cb83f23b5815@arm.com> (raw)
In-Reply-To: <67314806-361d-e0ac-9292-37542160ead5@cogentembedded.com>

On 11/01/17 07:59, Nikita Yushchenko wrote:
>>> +	/*
>>> +	 * we don't yet support buses that have a non-zero mapping.
>>> +	 *  Let's hope we won't need it
>>> +	 */
>>> +	WARN_ON(dma_base != 0);
>>
>> I believe we now accomodate the bus remap bits on BCM2837 as a DMA
>> offset, so unfortunately I think this is no longer true.
> 
> Arnd, this check is from you. Any updates? Perhaps this check can be
> just dropped?
> 
> In swiotlb code, dma address (i.e. with offset already applied) is
> checked against mask.  Not sure what 'dma_base' means in iommu case.
> 
>>> +	/*
>>> +	 * Whatever the parent bus can set. A device must not set
>>> +	 * a DMA mask larger than this.
>>> +	 */
>>> +	dev->archdata.parent_dma_mask = size - 1;
>>
>> This will effectively constrain *all* DMA masks to be 32-bit, since for
>> 99% of devices we're going to see a size derived from the default mask
>> passed in here. I worry that that's liable to lead to performance and
>> stability regressions
> 
> That was exactly my concern when I first tried to address this issue. My
> first attempt was to alter very locally exact configuration where
> problem shows, while ensuring that everything else stays as is. See
> https://lkml.org/lkml/2016/12/29/218
> 
> But looks like people want a generic solution.
> 
>> I reckon the easiest way forward would be to pass in some flag to
>> arch_setup_dma_ops to indicate whether it's an explicitly-configured
>> range or not - then simply initialising parent_dma_mask to ~0 for the
>> default case *should* keep things working as before.
> 
> Currently only arm, arm64 and mips define arch_setup_dma_ops().
> Mips version only checks 'coherent' argument, 'size' is used only by arm
> and arm64.
> 
> Maybe move setting the default from caller to callee?
> I.e. pass size=0 if no explicit information exists, and let architecture
> handle that?

Yes, I think that ought to work, although the __iommu_setup_dma_ops()
call will still want a real size reflecting the default mask, so
something like:

if (size == 0) {
	dev->archdata.parent_dma_mask = ~0;
	size = 1ULL << 32;
} else {
	dev->archdata.parent_dma_mask = size - 1;
}

should probably do the trick.

Robin.

  reply	other threads:[~2017-01-11 11:54 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-09  7:30 [PATCH v2] arm64: do not set dma masks that device connection can't handle Nikita Yushchenko
2017-01-10 11:51 ` Will Deacon
2017-01-10 12:47   ` Nikita Yushchenko
2017-01-10 13:12     ` Arnd Bergmann
2017-01-10 13:25     ` Robin Murphy
2017-01-10 13:42       ` Arnd Bergmann
2017-01-10 14:16         ` Robin Murphy
2017-01-10 15:06           ` Arnd Bergmann
2017-01-11 12:37           ` Nikita Yushchenko
2017-01-11 16:21             ` Arnd Bergmann
2017-01-11 18:28             ` Robin Murphy
2017-01-10 14:59         ` Christoph Hellwig
2017-01-10 14:00       ` [PATCH] arm64: avoid increasing DMA masks above what hardware supports Nikita Yushchenko
2017-01-10 17:14         ` Robin Murphy
2017-01-11  7:59           ` Nikita Yushchenko
2017-01-11 11:54             ` Robin Murphy [this message]
2017-01-11 13:41               ` Nikita Yushchenko
2017-01-11 14:50                 ` Robin Murphy
     [not found]                   ` <105b0b38-8c48-3355-4951-435c5dca18a4@cogentembedded.com>
2017-01-11 16:50                     ` Robin Murphy
2017-01-11 18:31           ` [PATCH 0/2] arm64: fix handling of DMA masks wider than bus supports Nikita Yushchenko
2017-01-11 18:31             ` [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops() Nikita Yushchenko
2017-01-11 21:08               ` Arnd Bergmann
2017-01-12  5:52                 ` Nikita Yushchenko
2017-01-12  6:33                   ` Nikita Yushchenko
2017-01-12 13:28                     ` Arnd Bergmann
2017-01-12 13:39                       ` Nikita Yushchenko
2017-01-12 12:16                   ` Will Deacon
2017-01-12 13:25                     ` Arnd Bergmann
2017-01-12 13:43                       ` Robin Murphy
2017-01-13 10:40               ` kbuild test robot
2017-01-11 18:31             ` [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports Nikita Yushchenko
2017-01-11 21:11               ` Arnd Bergmann
2017-01-12  5:53                 ` Nikita Yushchenko
2017-01-13 10:16               ` kbuild test robot
2017-01-10 14:01       ` [PATCH v2] arm64: do not set dma masks that device connection can't handle Nikita Yushchenko
2017-01-10 14:57       ` Christoph Hellwig
2017-01-10 14:51     ` Christoph Hellwig

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=57459a4a-2c57-e081-8f27-cb83f23b5815@arm.com \
    --to=robin.murphy@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=fkan@apm.com \
    --cc=horms@verge.net.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=nikita.yoush@cogentembedded.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