Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.

[Aaro Koskinen]

Hi,

On Mon, Dec 22, 2014 at 02:38:40PM +0800, Dongsheng Wang wrote:
 From: Wang Dongsheng dongsheng.w...@freescale.com
 
 Kernel cannot bring up Non-boot cpus always get Processor xx is stuck.
 this issue bring by http://patchwork.ozlabs.org/patch/418912/ (powerpc:
 Secondary CPUs must set cpu_callin_map after setting active and online)
 We need to take timebase after bootup cpu give the timebase firstly.
 
 When start_secondary, non-boot cpus set cpu_callin_map for boot cpu
 after that boot cpu will give the timebase for non-boot cpu. Otherwise
 non-boot cpus will fall in dead loop to waiting bootup cpu to give
 imebase.
 
 Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com

This fixes v3.19-rc1 boot on G5 Xserve.

Tested-by: Aaro Koskinen aaro.koski...@iki.fi

A.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] i2c-qoriq: modified compatibility for correct prescaler

[Scott Wood]

On Tue, 2014-12-23 at 14:49 +0100, Wolfram Sang wrote:
 On Tue, Dec 23, 2014 at 02:23:01PM +0100, Valentin Longchamp wrote:
  Wolfgang, Scott,
 
 Wolfram, please.
 
   What is then the agreement here ? Add a clock-div to the device trees ? 
   Or do
   something similar to  mpc_i2c_get_sec_cfg_8xxx() ?
   
   I think the clock-div property is better according to Freescale's AN 2919
   section 3.1 Source clock. All the source clocks are fixed (with a 
   clock-div of 2
   in case of mpc8536/43/45/47/48/67/68/72, plus p2020) except for the 
   mpc8533/44
   where it can be 2 or 3, and that's what mpc_i2c_get_sec_cfg_8xxx() 
   determines.
   
   So mpc_i2c_get_sec_cfg_8xxx() should remain the exception and the other
   prescaler values should be derived from an additional clock-div that must 
   be
   added in the respective device trees (at least for the qoriq devices, 
   because
   for instance mpc8543 already has the correct prescaler thanks to
   mpc_i2c_data_8543 from i2c-mpc.c).
   
  
  Do you have an opinion on the above ?
 
 I don't mind. I'll leave it to PowerPC experts to judge if a new binding
 is apropriate or reading SVR is the way to go. If it is going to be a
 new binding, then please look around before if there is already
 something similar around...

I'd rather use SVR so things work with existing device trees.

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev