From: vladimir.murzin@arm•com (Vladimir Murzin)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC v2 PATCH 0/3] Fix dma_alloc_coherent() and friends for NOMMU
Date: Wed, 14 Dec 2016 10:15:33 +0000 [thread overview]
Message-ID: <58511BC5.9060904@arm.com> (raw)
In-Reply-To: <552e7994-31ee-9ec8-4acd-8f37d1a157a4@arm.com>
On 13/12/16 18:32, Robin Murphy wrote:
> On 13/12/16 15:02, Vladimir Murzin wrote:
>> On 13/12/16 14:25, Robin Murphy wrote:
>>> On 13/12/16 14:14, Vladimir Murzin wrote:
>>>> On 13/12/16 14:07, Russell King - ARM Linux wrote:
>>>>> On Tue, Dec 13, 2016 at 01:45:01PM +0000, Vladimir Murzin wrote:
>>>>>> This patch set is trying to address the issue by providing region of
>>>>>> memory suitable for consistent DMA operations. It is supposed that such
>>>>>> region is marked by MPU as non-cacheable. Since we have MPU support in
>>>>>> Linux for R-class only and M-class setting MPU in bootloader, proposed
>>>>>> interface to advertise such memory is via "memdma=size at start" command
>>>>>> line option, to avoid clashing with normal memory (which usually comes
>>>>>> from dts) it'd be safer to use it together with "mem=" command line
>>>>>> option. Meanwhile, I'm open to suggestions for the better way telling
>>>>>> Linux of such memory.
>>>>>
>>>>> For those nommu systems where the MPU is not used, how do they allocate
>>>>> DMA memory without setting aside a chunk of memory?
>>>>>
>>>>> >From what I understand of the current nommu code, it would just use
>>>>> the normal page allocator for DMA memory allocation, so now requiring
>>>>> everything to fit the "nommu has mpu" case seems like it's going to
>>>>> break older nommu.
>>>>>
>>>>
>>>> Probably, it'd be better if we just fallback to dma-noop operations if there
>>>> is no dma region, i.e. assume that platform is coherent. We still need a way
>>>> to tell user that absence of such region can be reason of broken DMA.
>>>
>>> As I mentioned internally, I think it would be worth trying to use CMA
>>> for this, because dma_map_ops are already wired to try that first, and
>>> from what I can see it seems already set up to do precisely this via a
>>> "shared-dma-pool" reserved memory region (see rmem_cma_setup() in
>>> drivers/base/dma-contiguous.c) - mandating that for cached v7-M systems
>>> whilst letting cache-less/non-MPU systems automatically fall back to the
>>> normal page allocator in its absence would seem to solve all 3 cases.
>>
>> Unfortunately,
>>
>> config DMA_CMA
>> bool "DMA Contiguous Memory Allocator"
>> depends on HAVE_DMA_CONTIGUOUS && CMA
>> help
>> ...
>> config CMA
>> bool "Contiguous Memory Allocator"
>> depends on HAVE_MEMBLOCK && MMU
>> select MIGRATION
>>
>> and it blows up if I remove dependecy on MMU :(
>
> Ah yes, fair enough.
>
>> Another option would be drivers/base/dma-coherent.c, but, IIUC, in this case
>> memory is reserved per device exclusively, so I'm in doubt if tiny M-class can
>> afford that...
>
> I think as usual I managed to conflate the two - it was actually
> dma_alloc_from_coherent() I had in mind when I mentioned dma_map_ops. It
> does seem from 7bfa5ab6fa1b that dma-coherent *can* handle multiple
> devices per region, so it wouldn't appear to be too hard to implement a
> default coherent region (possibly specific to ARM_MPU) for all devices
> in a similar manner to the default contiguous region. Either way I do
> still think a reserved memory region in the DT is nicer and probably
> more robust than the command line parameter.
Ok, I'll look at this option in detail.
Thanks
Vladimir
>
> Robin.
>
>>> Other than the allocator issue, though, the rest of the refactoring does
>>> look nice.
>>
>> Thanks for going through it!
>>
>> Cheers
>> Vladimir
>
>
next prev parent reply other threads:[~2016-12-14 10:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-13 13:45 [RFC v2 PATCH 0/3] Fix dma_alloc_coherent() and friends for NOMMU Vladimir Murzin
2016-12-13 13:45 ` [RFC v2 PATCH 1/3] ARM: NOMMU: introduce dma operations for noMMU Vladimir Murzin
2017-01-02 15:26 ` Benjamin Gaignard
2017-01-04 10:33 ` Vladimir Murzin
2017-01-06 13:58 ` Benjamin Gaignard
2017-01-09 13:54 ` Vladimir Murzin
2016-12-13 13:45 ` [RFC v2 PATCH 2/3] ARM: NOMMU: set ARM_DMA_MEM_BUFFERABLE for M-class cpus Vladimir Murzin
2016-12-13 13:45 ` [RFC v2 PATCH 3/3] ARM: dma-mapping: remove traces of NOMMU code Vladimir Murzin
2016-12-13 14:07 ` [RFC v2 PATCH 0/3] Fix dma_alloc_coherent() and friends for NOMMU Russell King - ARM Linux
2016-12-13 14:14 ` Vladimir Murzin
2016-12-13 14:25 ` Robin Murphy
2016-12-13 15:02 ` Vladimir Murzin
2016-12-13 18:32 ` Robin Murphy
2016-12-14 10:15 ` Vladimir Murzin [this message]
2016-12-13 14:33 ` Szemző András
2016-12-13 15:04 ` Vladimir Murzin
2016-12-16 14:57 ` Alexandre Torgue
2016-12-16 15:00 ` Vladimir Murzin
2016-12-16 15:33 ` Alexandre Torgue
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=58511BC5.9060904@arm.com \
--to=vladimir.murzin@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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