Hi Bin,
On 26 February 2015 at 00:15, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Feb 26, 2015 at 8:55 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 25 February 2015 at 01:45, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Feb 19, 2015 at 5:10 AM, Simon Glass sjg@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