From: dingtianhong@huawei.com (Ding Tianhong)
To: linux-arm-kernel@lists.infradead.org
Subject: For the problem when using swiotlb
Date: Thu, 20 Nov 2014 16:34:29 +0800 [thread overview]
Message-ID: <546DA795.9080209@huawei.com> (raw)
In-Reply-To: <2522857.bNQToYpBNt@wuerfel>
On 2014/11/20 15:40, Arnd Bergmann wrote:
> On Thursday 20 November 2014 10:57:53 Ding Tianhong wrote:
>> On 2014/11/19 16:45, Arnd Bergmann wrote:
>>> On Wednesday 19 November 2014 11:17:15 Ding Tianhong wrote:
>>>> On 2014/11/18 2:09, Catalin Marinas wrote:
>>>>> On Mon, Nov 17, 2014 at 12:18:42PM +0000, Arnd Bergmann wrote:
>>>> Thanks everyone, I think I found the way to fix it, need to enable DMA_CMA, to reserve a big memory
>>>> for CMA and set coherent mask for dev, then dma_alloc and dma_mapping will not use the swiotlb until
>>>> the memory out of mask or swiotlb_force is enabled.
>>>>
>>>> If I still understand uncorrectly, please inform me.
>>>>
>>>
>>> Please do not use CMA to work around the problem, but fix the underlying bug
>>> instead.
>>>
>>> The driver should call 'dma_set_mask_and_coherent()' with the appropriate
>>> dma mask, and check whether that succeeded. However, the code implementing
>>> dma_set_mask_and_coherent on arm64 also needs to be changed to look up
>>> the dma-ranges property (see of_dma_configure()), and check if the mask
>>> is possible.
>>>
>> The dma_pfn_offset looks only support arm32, but my platform is aarch64 and I check the latest kernel version,
>> I think the dma-rangs still could not work for aarch64, so maybe we should add dma_pfn_offset for aarch64 first.
>>
>
> I didn't mean the dma_pfn_offset. The problem is that the of_dma_configure
> code currently doesn't look at the mask. As I explained in my reply to
> Catalin, it should set the mask to the size of the dma-ranges if that is
> 32-bit or smaller, and dma_set_mask should look at the same dma-ranges
> property to decide what to set the mask to when a driver asks for a
> mask larger than 64-bit.
>
> Arnd
>
ok, I think the your reply to catalin is clear, I got it, add a appropriate mask for the dev is
reasonable, I think it should be fixed later.
But in my case, if I don't use the DMA_CMA, the dma_alloc_coherent should use the swiotlb directly which maximum is 16M,
so unless I use the kmalloc otherwise I have no better idea for that.
Regards
Ding
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: Ding Tianhong <dingtianhong@huawei.com>
To: Arnd Bergmann <arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: For the problem when using swiotlb
Date: Thu, 20 Nov 2014 16:34:29 +0800 [thread overview]
Message-ID: <546DA795.9080209@huawei.com> (raw)
In-Reply-To: <2522857.bNQToYpBNt@wuerfel>
On 2014/11/20 15:40, Arnd Bergmann wrote:
> On Thursday 20 November 2014 10:57:53 Ding Tianhong wrote:
>> On 2014/11/19 16:45, Arnd Bergmann wrote:
>>> On Wednesday 19 November 2014 11:17:15 Ding Tianhong wrote:
>>>> On 2014/11/18 2:09, Catalin Marinas wrote:
>>>>> On Mon, Nov 17, 2014 at 12:18:42PM +0000, Arnd Bergmann wrote:
>>>> Thanks everyone, I think I found the way to fix it, need to enable DMA_CMA, to reserve a big memory
>>>> for CMA and set coherent mask for dev, then dma_alloc and dma_mapping will not use the swiotlb until
>>>> the memory out of mask or swiotlb_force is enabled.
>>>>
>>>> If I still understand uncorrectly, please inform me.
>>>>
>>>
>>> Please do not use CMA to work around the problem, but fix the underlying bug
>>> instead.
>>>
>>> The driver should call 'dma_set_mask_and_coherent()' with the appropriate
>>> dma mask, and check whether that succeeded. However, the code implementing
>>> dma_set_mask_and_coherent on arm64 also needs to be changed to look up
>>> the dma-ranges property (see of_dma_configure()), and check if the mask
>>> is possible.
>>>
>> The dma_pfn_offset looks only support arm32, but my platform is aarch64 and I check the latest kernel version,
>> I think the dma-rangs still could not work for aarch64, so maybe we should add dma_pfn_offset for aarch64 first.
>>
>
> I didn't mean the dma_pfn_offset. The problem is that the of_dma_configure
> code currently doesn't look at the mask. As I explained in my reply to
> Catalin, it should set the mask to the size of the dma-ranges if that is
> 32-bit or smaller, and dma_set_mask should look at the same dma-ranges
> property to decide what to set the mask to when a driver asks for a
> mask larger than 64-bit.
>
> Arnd
>
ok, I think the your reply to catalin is clear, I got it, add a appropriate mask for the dev is
reasonable, I think it should be fixed later.
But in my case, if I don't use the DMA_CMA, the dma_alloc_coherent should use the swiotlb directly which maximum is 16M,
so unless I use the kmalloc otherwise I have no better idea for that.
Regards
Ding
> .
>
next prev parent reply other threads:[~2014-11-20 8:34 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 [this message]
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
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=546DA795.9080209@huawei.com \
--to=dingtianhong@huawei.com \
--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.