[PATCH] allow coherent DMA API to work before main page allocator is set up

[Marcelo Tosatti]

On Fri, May 20, 2005 at 05:03:59PM -0400, Dan Malek wrote:
> 
> On May 20, 2005, at 10:12 AM, Marcelo Tosatti wrote:
> 
> >The following patch changes dma_alloc_coherent() to, in case the
> >main page allocator is not yet up and running, use the bootmem
> >allocator instead.
> 
> I'm concerned about this ...  Why did the drivers change in 2.6
> such that they now call dma_alloc_coherent() prior to the VM set up?

Well, as far as I can see, it is expected that console_init() gets called
before the main page allocator.

The startup sequence, on both v2.4 and v2.6, is:

setup_arch()
...
	console_init()
		console_8xx_init()
			register_console()
				release_console_sem() 
...
	mem_init()

register_console calls the driver ->setup method, and release_console_sem() 
is going to ->write pending data from the log buffer to the device.

As you well know, ->setup calls m8xx_cpm_hostalloc(). 

I must be missing something very obvious here, can you explain how 
did you arrange things in v2.4 such that the console's ->setup 
method is called _after_ mem_init() ? 

> >It also adds a new parameter to m8xx_cpm_hostalloc() to send back
> >the physical address to its caller.
> 
> Anyone calling m8xx_cpm_hostalloc() is likely to be immediately
> calling dma_alloc_coherent().  There is some design problem here
> if we can't properly use these interfaces and get the mapping we
> need.  The TLB pinning option won't work if we can't do this.
> 
> 
> > ..... Special casing such as
> >drivers/serial/cpm_uart/cpm_uart_cpm1.c's cpm_uart_allocbuf() can be
> >removed:
> >
> >        if (is_con) {
> >                mem_addr = (u8 *) m8xx_cpm_hostalloc(memsz);
> >                dma_addr = 0;
> >        } else
> >                mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
> >                                              GFP_KERNEL);
> 
> This is bogus and should not be necessary.  The original serial
> driver was able to work without doing this, I spent lots of time so
> stuff like this wasn't necessary, and it's sad to see us take such
> a step backward. 

Well, if you got this right in v2.4 then it must be possible to get 
it right in v2.6 too...

Thanks!