[U-Boot] [PATCH 05/22] RFC: x86: Split up arch_cpu_init()

[Simon Glass]

Hi Bin,

On 26 February 2015 at 00:15, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Thu, Feb 26, 2015 at 8:55 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin,
>>
>> On 25 February 2015 at 01:45, Bin Meng <bmeng.cn at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Thu, Feb 19, 2015 at 5:10 AM, Simon Glass <sjg at chromium.org> wrote:
>>>> At present we do more in this function than we should. Create a new
>>>> x86_post_cpu_init() which can be called from the board file when needed
>>>> (e.g. in board_early_init_f(). This allows us to use driver model for
>>>> our x86_post_cpu_init() function.
>>>>
>>>> It is likely that some future refactoring will improve this and reduce
>>>> the number of steps, using driver model's probing features.
>>>>
>>>> Note: this needs more discussion - e.g. I believe it breaks other x86
>>>> boards. We may want to plumb this in differently (e.g. promote
>>>> x86_post_cpu_init() to the board_init_f() boot sequence).
>>>
>>> Or maybe change the order in board_f.c so that arch_cpu_init() comes
>>> after init_dm()?
>>
>> I feel that arch_cpu_init() should be for very early things, the
>> absolute minimum to allow the machine to function and driver model to
>> be set up. Clearly x86 does not conform to that now!
>>
>> But I think there are a few things that fit in this category so having
>> the separated seems better.
>
> OK, I would prefer we explicitly put the post_cpu_init() into
> board_f.c initialization sequence. This isn't x86-specific. Any
> architecture which uses DM and generic board (starting from v2015.04
> release) will benefit from this.

Yes I'll do this, sounds like a good idea.

Regards,
Simon