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.
next prev parent 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