atmel_nand, DMA, and "Fall back to CPU I/O"

atmel_nand, DMA, and "Fall back to CPU I/O"

[George Pontis]

Working with 3.0.13 kernel and the at91sam9g45, 8b NAND flash with rootfs in
NAND

At boot, the kernel shows 22 DMA warnings, then another 260 as UBIFS mounts
the root FS:

atmel_nand atmel_nand: Fall back to CPU I/O

The Atmel nand driver is being passed an address, 0xc80000000, that fails
the test
for being at or higher than high_memory. The memory layout looks like this:

Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffa00000 - 0xffe00000   (   4 MB)
    vmalloc : 0xc8800000 - 0xfee00000   ( 870 MB)
    lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .init : 0xc0008000 - 0xc0027000   ( 124 kB)
      .text : 0xc0027000 - 0xc0456d8c   (4288 kB)
      .data : 0xc0458000 - 0xc0480ae0   ( 163 kB)
       .bss : 0xc0480b04 - 0xc04ab8b4   ( 172 kB)

Is it normal for a driver to get an address that is not inside one of these
ranges, whether
it used vmalloc or not ?

If the driver is not going to get pointers to a DMA-safe area, would it not
be better
to disable DMA, or at least set the default use_dma=0 ? 

George

Re: atmel_nand, DMA, and "Fall back to CPU I/O"

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

On Wed, 2012-04-25 at 15:09 -0700, George Pontis wrote:
> Working with 3.0.13 kernel and the at91sam9g45, 8b NAND flash with rootfs in
> NAND
> 
> At boot, the kernel shows 22 DMA warnings, then another 260 as UBIFS mounts
> the root FS:
> 
> atmel_nand atmel_nand: Fall back to CPU I/O
> 

Unfortunately UBI and UBIFS use vmalloced memory for I/O and many people
yelled but no one cared to fix this. I think we should make UBI/UBIFS to
use kmalloc()'ed memory instead.


-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: atmel_nand, DMA, and "Fall back to CPU I/O"

[Brian Norris]

On Wed, May 2, 2012 at 4:53 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Wed, 2012-04-25 at 15:09 -0700, George Pontis wrote:
>> Working with 3.0.13 kernel and the at91sam9g45, 8b NAND flash with rootfs in
>> NAND
>>
>> At boot, the kernel shows 22 DMA warnings, then another 260 as UBIFS mounts
>> the root FS:
>>
>> atmel_nand atmel_nand: Fall back to CPU I/O
>>
>
> Unfortunately UBI and UBIFS use vmalloced memory for I/O and many people
> yelled but no one cared to fix this. I think we should make UBI/UBIFS to
> use kmalloc()'ed memory instead.

I've noticed this problem before. It sometimes give problems for my
DMA controller, but my driver falls back to PIO if it can't pass a
check for '!is_vmalloc_addr(addr)'. Would this solution work for you,
George?

And how might you recommend we use kmalloc()'ed memory, Artem? We
can't really kmalloc() whole eraseblock-sized chunks. Or is there an
inexpensive way of providing an intermediary kmalloc'ed buffer? I'm
not too familiar at hacking at UBI(FS), but it might be worth a shot
sometime, if you think it's reasonable.

Brian

Re: atmel_nand, DMA, and "Fall back to CPU I/O"

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Wed, 2012-05-02 at 12:32 -0700, Brian Norris wrote:
> 
> And how might you recommend we use kmalloc()'ed memory, Artem? We
> can't really kmalloc() whole eraseblock-sized chunks. Or is there an
> inexpensive way of providing an intermediary kmalloc'ed buffer? I'm
> not too familiar at hacking at UBI(FS), but it might be worth a shot
> sometime, if you think it's reasonable.

This would need to change several places in UBI and UBIFS and switch
from continuous vmalloc buffers to iterating over an array of smaller
buffers.

I was thinking about this in the past but this is rather big project (a
months or a couple I'd say) so I did not have time to do this.

I think we basically need to switch to flexible arrays
(Documentation/flexible-arrays.txt), but last time I looked at this I
remember I decided that flexible arrays functionality would need to be
extended for our purposes.

If someone seriously is going to do this work, I am happy to discuss.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]