Re: powerpc/85xx: Move ePAPR paravirt initialization earlier

[Tudor Laurentiu <Laurentiu.Tudor@freescale.com>]

On 06/26/2013 02:14 AM, Scott Wood wrote:
> On Tue, Mar 05, 2013 at 05:52:36PM +0200, Laurentiu TUDOR wrote:
>> From: Tudor Laurentiu<laurentiu.tudor@freescale.com>
>>
>> The ePAPR para-virtualization needs to happen very early
>> otherwise the bytechannel based console will silently
>> drop some of the early boot messages.
>>
>> Before this patch, this is how the kernel log started:
>> -----------------------------------------------------
>>   >  Brought up 2 CPUs
>>   >  devtmpfs: initialized
>>   >  NET: Registered protocol family 16
>>   [...]
>> -----------------------------------------------------
>>
>> After the patch the early messages show up:
>> -----------------------------------------------------
>>   >  Using P5020 DS machine description
>>   >  MMU: Supported page sizes
>>   >           4 KB as direct
>>   >        4096 KB as direct
>>   [...]
>> -----------------------------------------------------
>>
>> At console init, the kernel tried to flush the log buffer.
>> Since the paravirt was not yet initialized the console write
>> function failed silently, thus losing the buffered messages.
> [snip]
>> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
>> index 6da881b..ce092ac 100644
>> --- a/arch/powerpc/kernel/setup_64.c
>> +++ b/arch/powerpc/kernel/setup_64.c
>> @@ -66,6 +66,7 @@
>>   #include<asm/code-patching.h>
>>   #include<asm/kvm_ppc.h>
>>   #include<asm/hugetlb.h>
>> +#include<asm/epapr_hcalls.h>
>>
>>   #include "setup.h"
>>
>> @@ -599,6 +600,8 @@ void __init setup_arch(char **cmdline_p)
>>   	/* Initialize the MMU context management stuff */
>>   	mmu_context_init();
>>
>> +	epapr_paravirt_init();
>> +
>>   	kvm_linear_init();
>>
>>   	/* Interrupt code needs to be 64K-aligned */
>
> Is this early enough?  There's udbg activity before this.  Maybe it
> should even go before udbg_early_init...

Right. I'll try moving it in machine_init().

> This would require converting
> the code to use the early device tree functions.
>

I see. Had a look at that api and it seems pretty limited.
I couldn't find a simple way of reading a property other than scanning 
the entire tree with of_scan_flat_dt().

---
Best Regards, Laurentiu