Scott Wood wrote:
> On Mon, Jul 20, 2009 at 09:51:03PM +1000, Mark Ware wrote:
>> This is another alloc_bootmem() -> kzalloc() change, this time to
>> fix the non-fatal badness caused when booting with a cpm2_uart console.
>>
>> Signed-Off-By: Mark Ware <mw...@elphinstone.net>
>>
>> ---
>> drivers/serial/cpm_uart/cpm_uart_cpm2.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
>> b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
>> index 141c0a3..a9802e7 100644
>> --- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
>> +++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
>> @@ -132,7 +132,7 @@ int cpm_uart_allocbuf(struct uart_cpm_port *pinfo,
>> unsigned int is_con)
>> memsz = L1_CACHE_ALIGN(pinfo->rx_nrfifos * pinfo->rx_fifosize) +
>> L1_CACHE_ALIGN(pinfo->tx_nrfifos * pinfo->tx_fifosize);
>> if (is_con) {
>> - mem_addr = alloc_bootmem(memsz);
>> + mem_addr = kzalloc(memsz, GFP_NOWAIT);
>> dma_addr = virt_to_bus(mem_addr);
>> }
>
> Hmm, is dma_alloc_coherent() now available this early as well? If so, we
> could get rid of the separate "is_con" handling altogether.
>
> -Scott
>
This was my first thought as well, but calling dma_alloc_coherent() on a
console resulted in a hang on boot before any console output.
I have no actual proof, but it seems likely that it is not available at that
point in the boot.
Regards,
Mark
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
