2014-05-20 오후 8:38, Marek Szyprowski 쓴 글:
Hello,
On 2014-05-20 02:50, Gioh Kim wrote:
2014-05-20 오전 4:59, Michal Nazarewicz 쓴 글:
On Sun, May 18 2014, Joonsoo Kim wrote:
I think that this problem is originated from atomic_pool_init().
If configured coherent_pool size is larger than default
On Mon, May 19 2014, Gioh Kim wrote:
> My point is atomic_pool should be able to work with/without CMA.
Agreed.
>> IMO, cma=0 command line argument should be supported, as should having
>> the default CMA size zero. If CMA size is set to zero, kernel should
>> behave as if CMA was not enabled at
Hello,
On 2014-05-20 02:50, Gioh Kim wrote:
2014-05-20 오전 4:59, Michal Nazarewicz 쓴 글:
On Sun, May 18 2014, Joonsoo Kim wrote:
I think that this problem is originated from atomic_pool_init().
If configured coherent_pool size is larger than default cma size,
it can be failed even if this patc
2014-05-20 오전 10:28, Michal Nazarewicz 쓴 글:
On Mon, May 19 2014, Gioh Kim wrote:
If CMA option is not selected, __alloc_from_contiguous would not be
called. We don't need to the fallback allocation.
And if CMA option is selected and initialized correctly,
the cma allocation can fail in case o
On Mon, May 19 2014, Gioh Kim wrote:
> If CMA option is not selected, __alloc_from_contiguous would not be
> called. We don't need to the fallback allocation.
>
> And if CMA option is selected and initialized correctly,
> the cma allocation can fail in case of no-CMA-memory situation.
> I thinks i
2014-05-20 오전 4:59, Michal Nazarewicz 쓴 글:
On Sun, May 18 2014, Joonsoo Kim wrote:
I think that this problem is originated from atomic_pool_init().
If configured coherent_pool size is larger than default cma size,
it can be failed even if this patch is applied.
The coherent_pool size (atomic
On Sun, May 18 2014, Joonsoo Kim wrote:
> I think that this problem is originated from atomic_pool_init().
> If configured coherent_pool size is larger than default cma size,
> it can be failed even if this patch is applied.
>
> How about below patch?
> It uses fallback allocation if CMA is failed.
In __dma_alloc function, your patch can make __alloc_from_pool work.
But __alloc_from_contiguous doesn't work.
Therefore __dma_alloc sometimes works and sometimes not according to the
gfp(__GFP_WAIT) flag.
Do I understand correctly?
I think __dma_alloc should work consistently.
Both of __alloc_f
On Mon, May 19, 2014 at 10:47:12AM +0900, Gioh Kim wrote:
> Thank you for your advice. I didn't notice it.
>
> I'm adding followings according to your advice:
>
> - range restrict for CMA_SIZE_MBYTES and *CMA_SIZE_PERCENTAGE*
> I think this can prevent the wrong kernel option.
>
> - change size_
Thank you for your advice. I didn't notice it.
I'm adding followings according to your advice:
- range restrict for CMA_SIZE_MBYTES and *CMA_SIZE_PERCENTAGE*
I think this can prevent the wrong kernel option.
- change size_cmdline into default value SZ_16M
I am not sure this can prevent if cma=0
On Fri, May 16 2014, Gioh Kim wrote:
> If CMA_SIZE_MBYTES is allowed to be zero, there should be defense code
> to check CMA is initlaized correctly. And atomic_pool initialization
> should be done by __alloc_remap_buffer instead of
> __alloc_from_contiguous if __alloc_from_contiguous is failed.
A
Hi,
I've been trying to apply CMA into my platform.
USB host driver generated kernel panic like below when USB mouse is connected,
because I turned on CMA and set the CMA_SIZE_MBYTES value into zero by mistake.
I think the panic is cuased by atomic_pool in arch/arm/mm/dma-mapping.c.
Zero CMA_SIZ
12 matches
Mail list logo
