On 22/05/18 07:56, ilialin@xxxxxxxxxxxxxx wrote: > > >> -----Original Message----- >> From: Sudeep Holla <sudeep.holla@xxxxxxx> >> Sent: Monday, May 21, 2018 16:05 [...] >> >> >> That may be true and I am not that bothered about it. But assuming physical >> ordering from the logical cpu number is *incorrect* and will break if kernel >> decides to change the allocation algorithm. Kernel provides no guarantee on >> that, so you need to depend on some physical ID or may be DT to achieve >> what your want. But the current code as it stands is wrong. > > Got your point. In fact CPUs are numbered 0-3 and ordered into 2 clusters in the DT: > > cpus { > #address-cells = <2>; > #size-cells = <0>; > > CPU0: cpu@0 { > ... > reg = <0x0 0x0>; > ... > }; > > CPU1: cpu@1 { > ... > reg = <0x0 0x1>; > ... > }; > > CPU2: cpu@100 { > ... > reg = <0x0 0x100>; > ... > }; > > CPU3: cpu@101 { > ... > reg = <0x0 0x101>; > ... > }; > > cpu-map { > cluster0 { > core0 { > cpu = <&CPU0>; > }; > > core1 { > cpu = <&CPU1>; > }; > }; > > cluster1 { > core0 { > cpu = <&CPU2>; > }; > > core1 { > cpu = <&CPU3>; > }; > }; > }; > }; > > As far, as I understand, they are probed in the same order. Yes that's correct today, will that have to remain same for ever ? No it's not user ABI and kernel can decide to change the allocation order. What if for some reason one/more CPUs fails to boot or even configured not to boot ? > However, to be certain that the physical CPU is the one I intend to > configure, I have to fetch the device structure pointer for the cpu-map -> > clusterX -> core0 -> cpu path. Could you suggest a kernel API to do > that? > Let's rewind a bit. Do you supply OPPs only on CPU0 and CPU2 ? If yes, that's again wrong. Simple solution is to parse all logical CPUs and skip if the share OPPs with some other CPUs. I think that logic already exists in OPP library IIRC. -- Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html