| Message ID | 5208E2D3.7060005@arm.com |
|---|---|
| State | New |
| Headers | show |
On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote: > The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: > > Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) > > are available in the git repository at: > > git://linux-arm.org/linux-skn.git cpu_of_node > > for you to fetch changes up to 9e9e26dde91f22635c87d0e45f3938b5ded96f0d: > > cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes > (2013-08-12 10:22:29 +0100) > > ---------------------------------------------------------------- > Sudeep KarkadaNagesha (16): > of: add support for retrieving cpu node for a given logical cpu index > ARM: DT/kernel: define ARM specific arch_match_cpu_phys_id > driver/core: cpu: initialize of_node in cpu's device struture > of/device: add helper to get cpu device node from logical cpu index > ARM: topology: remove hwid/MPIDR dependency from cpu_capacity > ARM: mvebu: remove device tree parsing for cpu nodes > drivers/bus: arm-cci: avoid parsing DT for cpu device nodes > cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes > cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes > cpufreq: highbank-cpufreq: remove device tree parsing for cpu nodes > cpufreq: spear-cpufreq: remove device tree parsing for cpu nodes > cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes > cpufreq: arm_big_little: remove device tree parsing for cpu nodes > cpufreq: maple-cpufreq: remove device tree parsing for cpu nodes > cpufreq: pmac64-cpufreq: remove device tree parsing for cpu nodes > cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes > > arch/arm/kernel/devtree.c | 5 +++++ > arch/arm/kernel/topology.c | 61 > +++++++++++++++++++------------------------------------------ > arch/arm/mach-imx/mach-imx6q.c | 3 +-- > arch/arm/mach-mvebu/platsmp.c | 52 > ++++++++++++++++++++++++---------------------------- > drivers/base/cpu.c | 2 ++ > drivers/bus/arm-cci.c | 28 +++++++--------------------- > drivers/cpufreq/arm_big_little_dt.c | 40 > ++++++++++++++-------------------------- > drivers/cpufreq/cpufreq-cpu0.c | 23 ++++------------------- > drivers/cpufreq/highbank-cpufreq.c | 18 ++++++------------ > drivers/cpufreq/imx6q-cpufreq.c | 4 +--- > drivers/cpufreq/kirkwood-cpufreq.c | 8 +++++--- > drivers/cpufreq/maple-cpufreq.c | 23 +++-------------------- > drivers/cpufreq/pmac32-cpufreq.c | 5 +++-- > drivers/cpufreq/pmac64-cpufreq.c | 47 > +++++++++++------------------------------------ > drivers/cpufreq/spear-cpufreq.c | 4 ++-- > drivers/of/base.c | 73 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > include/linux/cpu.h | 1 + > include/linux/of.h | 6 ++++++ > include/linux/of_device.h | 15 +++++++++++++++ > 19 files changed, 202 insertions(+), 216 deletions(-) > > > PS: This patch series is reviewed and acknowledged @ > > v1: https://lkml.org/lkml/2013/7/15/128 > v2: https://lkml.org/lkml/2013/7/17/341 > v3: https://lkml.org/lkml/2013/7/22/219 Pulled, thanks!
Adding PowerPC list On 13/08/13 14:00, Rafael J. Wysocki wrote: > On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote: >> The following changes since commit >> d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: >> >> Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) >> >> are available in the git repository at: >> >> git://linux-arm.org/linux-skn.git cpu_of_node >> >> for you to fetch changes up to >> 9e9e26dde91f22635c87d0e45f3938b5ded96f0d: >> >> cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes >> (2013-08-12 10:22:29 +0100) >> >> ---------------------------------------------------------------- >> Sudeep KarkadaNagesha (16): of: add support for retrieving cpu node >> for a given logical cpu index ARM: DT/kernel: define ARM specific >> arch_match_cpu_phys_id driver/core: cpu: initialize of_node in >> cpu's device struture of/device: add helper to get cpu device node >> from logical cpu index ARM: topology: remove hwid/MPIDR dependency >> from cpu_capacity ARM: mvebu: remove device tree parsing for cpu >> nodes drivers/bus: arm-cci: avoid parsing DT for cpu device nodes >> cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes >> cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes >> cpufreq: highbank-cpufreq: remove device tree parsing for cpu >> nodes cpufreq: spear-cpufreq: remove device tree parsing for cpu >> nodes cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu >> nodes cpufreq: arm_big_little: remove device tree parsing for cpu >> nodes cpufreq: maple-cpufreq: remove device tree parsing for cpu >> nodes cpufreq: pmac64-cpufreq: remove device tree parsing for cpu >> nodes cpufreq: pmac32-cpufreq: remove device tree parsing for cpu >> nodes >> >> arch/arm/kernel/devtree.c | 5 +++++ >> arch/arm/kernel/topology.c | 61 >> +++++++++++++++++++------------------------------------------ >> arch/arm/mach-imx/mach-imx6q.c | 3 +-- >> arch/arm/mach-mvebu/platsmp.c | 52 >> ++++++++++++++++++++++++---------------------------- >> drivers/base/cpu.c | 2 ++ drivers/bus/arm-cci.c >> | 28 +++++++--------------------- >> drivers/cpufreq/arm_big_little_dt.c | 40 >> ++++++++++++++-------------------------- >> drivers/cpufreq/cpufreq-cpu0.c | 23 ++++------------------- >> drivers/cpufreq/highbank-cpufreq.c | 18 ++++++------------ >> drivers/cpufreq/imx6q-cpufreq.c | 4 +--- >> drivers/cpufreq/kirkwood-cpufreq.c | 8 +++++--- >> drivers/cpufreq/maple-cpufreq.c | 23 +++-------------------- >> drivers/cpufreq/pmac32-cpufreq.c | 5 +++-- >> drivers/cpufreq/pmac64-cpufreq.c | 47 >> +++++++++++------------------------------------ >> drivers/cpufreq/spear-cpufreq.c | 4 ++-- drivers/of/base.c >> | 73 >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> include/linux/cpu.h | 1 + >> include/linux/of.h | 6 ++++++ >> include/linux/of_device.h | 15 +++++++++++++++ 19 files >> changed, 202 insertions(+), 216 deletions(-) >> >> >> PS: This patch series is reviewed and acknowledged @ >> >> v1: https://lkml.org/lkml/2013/7/15/128 v2: >> https://lkml.org/lkml/2013/7/17/341 v3: >> https://lkml.org/lkml/2013/7/22/219 > > Pulled, thanks! > Hi Rob, Rafael, On 13/08/13 15:16, kbuild test robot wrote:> tree: git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge > head: 0d4bcb5dc7d3040c0ce7572ea30ab9e5d9455bfa commit: > 7939ff8d991de2c0b15064e76ee549a6df5ae67f [151/204] of: add > support for retrieving cpu node for a given logical cpu index > config: make ARCH=powerpc allmodconfig > > All error/warnings: > > warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) > selects FSL_LBC which has unmet direct dependencies (FSL_SOC) > warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) > selects FSL_LBC which has unmet direct dependencies (FSL_SOC) > In file included from arch/powerpc/include/asm/kvm_para.h:26:0, from > include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, > from include/linux/kvm_host.h:30, from > arch/powerpc/kernel/asm-offsets.c:53: > include/linux/of.h:269:28: error: conflicting types for >'of_get_cpu_node' > extern struct device_node *of_get_cpu_node(int cpu); ^ In file > included from include/linux/of.h:139:0, from > arch/powerpc/include/asm/kvm_para.h:26, from > include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, > from include/linux/kvm_host.h:30, from > arch/powerpc/kernel/asm-offsets.c:53: > arch/powerpc/include/asm/prom.h:47:21: note: previous declaration > of 'of_get_cpu_node' was here > struct device_node *of_get_cpu_node(int cpu, unsigned int *thread); > ^ make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1 make[2]: > Target `__build' not remade because of errors. make[1]: *** > [prepare0] Error 2 make[1]: Target `prepare' not remade because of > errors. make: *** [sub-make] Error 2 > There seems to be conflict in the new function "of_get_cpu_node" added. PowerPC also defines the same function name. Further microblaze and openrisc declares it(can be removed) but doesn't define it. To fix this: 1. I can rename the newly added function to something different like `of_get_cpunode` or 2. If of_* namespace should be used by only OF/FDT and not by any architecture specific code, then the arch specific version can be renamed to some thing like arch_of_get_cpu_node. Also most of the calls to arch specific function can be moved to generic code. Let me know your thoughts. Regards, Sudeep
On 08/13/2013 05:40 PM, Sudeep KarkadaNagesha wrote: > Adding PowerPC list > > On 13/08/13 14:00, Rafael J. Wysocki wrote: >> On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote: >>> The following changes since commit >>> d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: >>> >>> Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) >>> >>> are available in the git repository at: >>> >>> git://linux-arm.org/linux-skn.git cpu_of_node >>> >>> for you to fetch changes up to >>> 9e9e26dde91f22635c87d0e45f3938b5ded96f0d: >>> >>> cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes >>> (2013-08-12 10:22:29 +0100) >>> >>> ---------------------------------------------------------------- >>> Sudeep KarkadaNagesha (16): of: add support for retrieving cpu node >>> for a given logical cpu index ARM: DT/kernel: define ARM specific >>> arch_match_cpu_phys_id driver/core: cpu: initialize of_node in >>> cpu's device struture of/device: add helper to get cpu device node >>> from logical cpu index ARM: topology: remove hwid/MPIDR dependency >>> from cpu_capacity ARM: mvebu: remove device tree parsing for cpu >>> nodes drivers/bus: arm-cci: avoid parsing DT for cpu device nodes >>> cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes >>> cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes >>> cpufreq: highbank-cpufreq: remove device tree parsing for cpu >>> nodes cpufreq: spear-cpufreq: remove device tree parsing for cpu >>> nodes cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu >>> nodes cpufreq: arm_big_little: remove device tree parsing for cpu >>> nodes cpufreq: maple-cpufreq: remove device tree parsing for cpu >>> nodes cpufreq: pmac64-cpufreq: remove device tree parsing for cpu >>> nodes cpufreq: pmac32-cpufreq: remove device tree parsing for cpu >>> nodes >>> >>> arch/arm/kernel/devtree.c | 5 +++++ >>> arch/arm/kernel/topology.c | 61 >>> +++++++++++++++++++------------------------------------------ >>> arch/arm/mach-imx/mach-imx6q.c | 3 +-- >>> arch/arm/mach-mvebu/platsmp.c | 52 >>> ++++++++++++++++++++++++---------------------------- >>> drivers/base/cpu.c | 2 ++ drivers/bus/arm-cci.c >>> | 28 +++++++--------------------- >>> drivers/cpufreq/arm_big_little_dt.c | 40 >>> ++++++++++++++-------------------------- >>> drivers/cpufreq/cpufreq-cpu0.c | 23 ++++------------------- >>> drivers/cpufreq/highbank-cpufreq.c | 18 ++++++------------ >>> drivers/cpufreq/imx6q-cpufreq.c | 4 +--- >>> drivers/cpufreq/kirkwood-cpufreq.c | 8 +++++--- >>> drivers/cpufreq/maple-cpufreq.c | 23 +++-------------------- >>> drivers/cpufreq/pmac32-cpufreq.c | 5 +++-- >>> drivers/cpufreq/pmac64-cpufreq.c | 47 >>> +++++++++++------------------------------------ >>> drivers/cpufreq/spear-cpufreq.c | 4 ++-- drivers/of/base.c >>> | 73 >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> > include/linux/cpu.h | 1 + >>> include/linux/of.h | 6 ++++++ >>> include/linux/of_device.h | 15 +++++++++++++++ 19 files >>> changed, 202 insertions(+), 216 deletions(-) >>> >>> >>> PS: This patch series is reviewed and acknowledged @ >>> >>> v1: https://lkml.org/lkml/2013/7/15/128 v2: >>> https://lkml.org/lkml/2013/7/17/341 v3: >>> https://lkml.org/lkml/2013/7/22/219 >> >> Pulled, thanks! >> > Hi Rob, Rafael, > > On 13/08/13 15:16, kbuild test robot wrote:> tree: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > bleeding-edge >> head: 0d4bcb5dc7d3040c0ce7572ea30ab9e5d9455bfa commit: >> 7939ff8d991de2c0b15064e76ee549a6df5ae67f [151/204] of: add >> support for retrieving cpu node for a given logical cpu index >> config: make ARCH=powerpc allmodconfig >> >> All error/warnings: >> >> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) >> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) >> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) >> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) >> In file included from arch/powerpc/include/asm/kvm_para.h:26:0, from >> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, >> from include/linux/kvm_host.h:30, from >> arch/powerpc/kernel/asm-offsets.c:53: >> include/linux/of.h:269:28: error: conflicting types for >> 'of_get_cpu_node' >> extern struct device_node *of_get_cpu_node(int cpu); ^ In file >> included from include/linux/of.h:139:0, from >> arch/powerpc/include/asm/kvm_para.h:26, from >> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, >> from include/linux/kvm_host.h:30, from >> arch/powerpc/kernel/asm-offsets.c:53: >> arch/powerpc/include/asm/prom.h:47:21: note: previous declaration >> of 'of_get_cpu_node' was here >> struct device_node *of_get_cpu_node(int cpu, unsigned int *thread); >> ^ make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1 make[2]: >> Target `__build' not remade because of errors. make[1]: *** >> [prepare0] Error 2 make[1]: Target `prepare' not remade because of >> errors. make: *** [sub-make] Error 2 >> > > There seems to be conflict in the new function "of_get_cpu_node" added. > PowerPC also defines the same function name. Further microblaze and > openrisc declares it(can be removed) but doesn't define it. Feel free to remove it for Microblaze. There was probably any reason why it was there. Or maybe no reason and it was just there because Microblaze was based on powerpc code. Thanks, Michal
On Tue, Aug 13, 2013 at 10:40 AM, Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com> wrote: > Adding PowerPC list > > On 13/08/13 14:00, Rafael J. Wysocki wrote: >> On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote: >>> The following changes since commit >>> d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: >>> >>> Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) >>> >>> are available in the git repository at: >>> >>> git://linux-arm.org/linux-skn.git cpu_of_node [snip] >> All error/warnings: >> >> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) >> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) >> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) >> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) >> In file included from arch/powerpc/include/asm/kvm_para.h:26:0, from >> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, >> from include/linux/kvm_host.h:30, from >> arch/powerpc/kernel/asm-offsets.c:53: >> include/linux/of.h:269:28: error: conflicting types for >>'of_get_cpu_node' >> extern struct device_node *of_get_cpu_node(int cpu); ^ In file >> included from include/linux/of.h:139:0, from >> arch/powerpc/include/asm/kvm_para.h:26, from >> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, >> from include/linux/kvm_host.h:30, from >> arch/powerpc/kernel/asm-offsets.c:53: >> arch/powerpc/include/asm/prom.h:47:21: note: previous declaration >> of 'of_get_cpu_node' was here >> struct device_node *of_get_cpu_node(int cpu, unsigned int *thread); >> ^ make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1 make[2]: >> Target `__build' not remade because of errors. make[1]: *** >> [prepare0] Error 2 make[1]: Target `prepare' not remade because of >> errors. make: *** [sub-make] Error 2 >> > > There seems to be conflict in the new function "of_get_cpu_node" added. > PowerPC also defines the same function name. Further microblaze and > openrisc declares it(can be removed) but doesn't define it. > To fix this: > 1. I can rename the newly added function to something different like > `of_get_cpunode` or > 2. If of_* namespace should be used by only OF/FDT and not by any > architecture specific code, then the arch specific version can be > renamed to some thing like arch_of_get_cpu_node. > Also most of the calls to arch specific function can be moved to > generic code. > > Let me know your thoughts. It is up to Rafael if he is willing/able to rebase his tree, but I would drop this series until this is sorted out. I think the new common function should be and can be generalized to work for powerpc. It would need to make reg property optional and pass in the device node to the arch specific function. A short term solution would be just to make the function "#ifndef CONFIG_PPC". Rob
On Tuesday, August 13, 2013 01:44:23 PM Rob Herring wrote: > On Tue, Aug 13, 2013 at 10:40 AM, Sudeep KarkadaNagesha > <Sudeep.KarkadaNagesha@arm.com> wrote: > > Adding PowerPC list > > > > On 13/08/13 14:00, Rafael J. Wysocki wrote: > >> On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote: > >>> The following changes since commit > >>> d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: > >>> > >>> Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) > >>> > >>> are available in the git repository at: > >>> > >>> git://linux-arm.org/linux-skn.git cpu_of_node > > [snip] > > >> All error/warnings: > >> > >> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) > >> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) > >> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) > >> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) > >> In file included from arch/powerpc/include/asm/kvm_para.h:26:0, from > >> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, > >> from include/linux/kvm_host.h:30, from > >> arch/powerpc/kernel/asm-offsets.c:53: > >> include/linux/of.h:269:28: error: conflicting types for > >>'of_get_cpu_node' > >> extern struct device_node *of_get_cpu_node(int cpu); ^ In file > >> included from include/linux/of.h:139:0, from > >> arch/powerpc/include/asm/kvm_para.h:26, from > >> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, > >> from include/linux/kvm_host.h:30, from > >> arch/powerpc/kernel/asm-offsets.c:53: > >> arch/powerpc/include/asm/prom.h:47:21: note: previous declaration > >> of 'of_get_cpu_node' was here > >> struct device_node *of_get_cpu_node(int cpu, unsigned int *thread); > >> ^ make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1 make[2]: > >> Target `__build' not remade because of errors. make[1]: *** > >> [prepare0] Error 2 make[1]: Target `prepare' not remade because of > >> errors. make: *** [sub-make] Error 2 > >> > > > > There seems to be conflict in the new function "of_get_cpu_node" added. > > PowerPC also defines the same function name. Further microblaze and > > openrisc declares it(can be removed) but doesn't define it. > > To fix this: > > 1. I can rename the newly added function to something different like > > `of_get_cpunode` or > > 2. If of_* namespace should be used by only OF/FDT and not by any > > architecture specific code, then the arch specific version can be > > renamed to some thing like arch_of_get_cpu_node. > > Also most of the calls to arch specific function can be moved to > > generic code. > > > > Let me know your thoughts. > > It is up to Rafael if he is willing/able to rebase his tree, but I > would drop this series until this is sorted out. Yeah, I've just done that. > I think the new common function should be and can be generalized to work for > powerpc. > It would need to make reg property optional and pass in the device > node to the arch specific function. > > A short term solution would be just to make the function "#ifndef CONFIG_PPC". I wouldn't do that, it's almost guaranteed to be messy going forward. I'd go for 1 above personally. Thanks, Rafael
On Tue, 2013-08-13 at 16:40 +0100, Sudeep KarkadaNagesha wrote: > There seems to be conflict in the new function "of_get_cpu_node" added. > PowerPC also defines the same function name. Further microblaze and > openrisc declares it(can be removed) but doesn't define it. > To fix this: > 1. I can rename the newly added function to something different like > `of_get_cpunode` or > 2. If of_* namespace should be used by only OF/FDT and not by any > architecture specific code, then the arch specific version can be > renamed to some thing like arch_of_get_cpu_node. > Also most of the calls to arch specific function can be moved to > generic code. > > Let me know your thoughts. What is your new function about ? Does it perform the same job as the one in powerpc ? If yes, make sure you have the same signature and either copy the powerpc one over to a generic place or make the generic one weak if you don't want the powerpc thread counting logic. Cheers, Ben.
On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote: > I don't understand completely the use of ibm,ppc-interrupt-server#s and > its implications on generic of_get_cpu_node implementation. > I see the PPC specific definition of of_get_cpu_node uses thread id only > in 2 instances. Based on that, I have tried to move all the other > instances to use generic definition. > > Let me know if the idea is correct. No. The device-tree historically only represents cores, not HW threads, so it makes sense to retrieve also the thread number corresponding to the CPU. However, the mechanism to represent HW threads in the device-tree is currently somewhat platform specific (the ibm,ppc-interrupt-server#s). So what you could do for now is: - Have a generic version that always returns 0 as the thread, which is weak - powerpc keeps its own implementation - Start a discussion on the bindings (if not already there) to define threads in a better way at which point the generic function can be updated. Cheers, Ben.
On Tue, 2013-08-13 at 13:44 -0500, Rob Herring wrote: > It is up to Rafael if he is willing/able to rebase his tree, but I > would drop this series until this is sorted out. I think the new > common function should be and can be generalized to work for powerpc. > It would need to make reg property optional and pass in the device > node to the arch specific function. > > A short term solution would be just to make the function "#ifndef > CONFIG_PPC". Please, no ifdef's with different signatures. Let's agree on the prototype first (ie, thread output argument) and make the generic one weak. Cheers, Ben.
On Tue, 2013-08-13 at 21:45 +0200, Rafael J. Wysocki wrote: > > I'd go for 1 above personally. Yuck no. Two functions with roughly the same name and the same purpose differing only by an underscore just because one can't take 5mn to reconcile the new one with the old one ? No way. Ben.
On 13/08/13 19:37, Michal Simek wrote: > On 08/13/2013 05:40 PM, Sudeep KarkadaNagesha wrote: >> Adding PowerPC list >> >> On 13/08/13 14:00, Rafael J. Wysocki wrote: >>> On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote: >>>> The following changes since commit >>>> d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: >>>> >>>> Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) >>>> >>>> are available in the git repository at: >>>> >>>> git://linux-arm.org/linux-skn.git cpu_of_node >>>> >>>> for you to fetch changes up to >>>> 9e9e26dde91f22635c87d0e45f3938b5ded96f0d: >>>> >>>> cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes >>>> (2013-08-12 10:22:29 +0100) >>>> >>>> ---------------------------------------------------------------- >>>> Sudeep KarkadaNagesha (16): of: add support for retrieving cpu node >>>> for a given logical cpu index ARM: DT/kernel: define ARM specific >>>> arch_match_cpu_phys_id driver/core: cpu: initialize of_node in >>>> cpu's device struture of/device: add helper to get cpu device node >>>> from logical cpu index ARM: topology: remove hwid/MPIDR dependency >>>> from cpu_capacity ARM: mvebu: remove device tree parsing for cpu >>>> nodes drivers/bus: arm-cci: avoid parsing DT for cpu device nodes >>>> cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes >>>> cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes >>>> cpufreq: highbank-cpufreq: remove device tree parsing for cpu >>>> nodes cpufreq: spear-cpufreq: remove device tree parsing for cpu >>>> nodes cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu >>>> nodes cpufreq: arm_big_little: remove device tree parsing for cpu >>>> nodes cpufreq: maple-cpufreq: remove device tree parsing for cpu >>>> nodes cpufreq: pmac64-cpufreq: remove device tree parsing for cpu >>>> nodes cpufreq: pmac32-cpufreq: remove device tree parsing for cpu >>>> nodes >>>> >>>> arch/arm/kernel/devtree.c | 5 +++++ >>>> arch/arm/kernel/topology.c | 61 >>>> +++++++++++++++++++------------------------------------------ >>>> arch/arm/mach-imx/mach-imx6q.c | 3 +-- >>>> arch/arm/mach-mvebu/platsmp.c | 52 >>>> ++++++++++++++++++++++++---------------------------- >>>> drivers/base/cpu.c | 2 ++ drivers/bus/arm-cci.c >>>> | 28 +++++++--------------------- >>>> drivers/cpufreq/arm_big_little_dt.c | 40 >>>> ++++++++++++++-------------------------- >>>> drivers/cpufreq/cpufreq-cpu0.c | 23 ++++------------------- >>>> drivers/cpufreq/highbank-cpufreq.c | 18 ++++++------------ >>>> drivers/cpufreq/imx6q-cpufreq.c | 4 +--- >>>> drivers/cpufreq/kirkwood-cpufreq.c | 8 +++++--- >>>> drivers/cpufreq/maple-cpufreq.c | 23 +++-------------------- >>>> drivers/cpufreq/pmac32-cpufreq.c | 5 +++-- >>>> drivers/cpufreq/pmac64-cpufreq.c | 47 >>>> +++++++++++------------------------------------ >>>> drivers/cpufreq/spear-cpufreq.c | 4 ++-- drivers/of/base.c >>>> | 73 >>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> >> include/linux/cpu.h | 1 + >>>> include/linux/of.h | 6 ++++++ >>>> include/linux/of_device.h | 15 +++++++++++++++ 19 files >>>> changed, 202 insertions(+), 216 deletions(-) >>>> >>>> >>>> PS: This patch series is reviewed and acknowledged @ >>>> >>>> v1: https://lkml.org/lkml/2013/7/15/128 v2: >>>> https://lkml.org/lkml/2013/7/17/341 v3: >>>> https://lkml.org/lkml/2013/7/22/219 >>> >>> Pulled, thanks! >>> >> Hi Rob, Rafael, >> >> On 13/08/13 15:16, kbuild test robot wrote:> tree: >> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git >> bleeding-edge >>> head: 0d4bcb5dc7d3040c0ce7572ea30ab9e5d9455bfa commit: >>> 7939ff8d991de2c0b15064e76ee549a6df5ae67f [151/204] of: add >>> support for retrieving cpu node for a given logical cpu index >>> config: make ARCH=powerpc allmodconfig >>> >>> All error/warnings: >>> >>> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) >>> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) >>> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) >>> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) >>> In file included from arch/powerpc/include/asm/kvm_para.h:26:0, from >>> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, >>> from include/linux/kvm_host.h:30, from >>> arch/powerpc/kernel/asm-offsets.c:53: >>> include/linux/of.h:269:28: error: conflicting types for >>> 'of_get_cpu_node' >>> extern struct device_node *of_get_cpu_node(int cpu); ^ In file >>> included from include/linux/of.h:139:0, from >>> arch/powerpc/include/asm/kvm_para.h:26, from >>> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, >>> from include/linux/kvm_host.h:30, from >>> arch/powerpc/kernel/asm-offsets.c:53: >>> arch/powerpc/include/asm/prom.h:47:21: note: previous declaration >>> of 'of_get_cpu_node' was here >>> struct device_node *of_get_cpu_node(int cpu, unsigned int *thread); >>> ^ make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1 make[2]: >>> Target `__build' not remade because of errors. make[1]: *** >>> [prepare0] Error 2 make[1]: Target `prepare' not remade because of >>> errors. make: *** [sub-make] Error 2 >>> >> >> There seems to be conflict in the new function "of_get_cpu_node" added. >> PowerPC also defines the same function name. Further microblaze and >> openrisc declares it(can be removed) but doesn't define it. > > Feel free to remove it for Microblaze. > There was probably any reason why it was there. > Or maybe no reason and it was just there because Microblaze > was based on powerpc code. > Thanks Michal, will remove it. Regards, Sudeep
On 13/08/13 20:45, Rafael J. Wysocki wrote: > On Tuesday, August 13, 2013 01:44:23 PM Rob Herring wrote: >> On Tue, Aug 13, 2013 at 10:40 AM, Sudeep KarkadaNagesha >> <Sudeep.KarkadaNagesha@arm.com> wrote: >>> Adding PowerPC list >>> >>> On 13/08/13 14:00, Rafael J. Wysocki wrote: >>>> On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote: >>>>> The following changes since commit >>>>> d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: >>>>> >>>>> Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) >>>>> >>>>> are available in the git repository at: >>>>> >>>>> git://linux-arm.org/linux-skn.git cpu_of_node >> >> [snip] >> >>>> All error/warnings: >>>> >>>> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) >>>> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) >>>> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) >>>> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) >>>> In file included from arch/powerpc/include/asm/kvm_para.h:26:0, from >>>> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, >>>> from include/linux/kvm_host.h:30, from >>>> arch/powerpc/kernel/asm-offsets.c:53: >>>> include/linux/of.h:269:28: error: conflicting types for >>>> 'of_get_cpu_node' >>>> extern struct device_node *of_get_cpu_node(int cpu); ^ In file >>>> included from include/linux/of.h:139:0, from >>>> arch/powerpc/include/asm/kvm_para.h:26, from >>>> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, >>>> from include/linux/kvm_host.h:30, from >>>> arch/powerpc/kernel/asm-offsets.c:53: >>>> arch/powerpc/include/asm/prom.h:47:21: note: previous declaration >>>> of 'of_get_cpu_node' was here >>>> struct device_node *of_get_cpu_node(int cpu, unsigned int *thread); >>>> ^ make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1 make[2]: >>>> Target `__build' not remade because of errors. make[1]: *** >>>> [prepare0] Error 2 make[1]: Target `prepare' not remade because of >>>> errors. make: *** [sub-make] Error 2 >>>> >>> >>> There seems to be conflict in the new function "of_get_cpu_node" added. >>> PowerPC also defines the same function name. Further microblaze and >>> openrisc declares it(can be removed) but doesn't define it. >>> To fix this: >>> 1. I can rename the newly added function to something different like >>> `of_get_cpunode` or >>> 2. If of_* namespace should be used by only OF/FDT and not by any >>> architecture specific code, then the arch specific version can be >>> renamed to some thing like arch_of_get_cpu_node. >>> Also most of the calls to arch specific function can be moved to >>> generic code. >>> >>> Let me know your thoughts. >> >> It is up to Rafael if he is willing/able to rebase his tree, but I >> would drop this series until this is sorted out. > > Yeah, I've just done that. > Thanks Rafael, sorry for the trouble. I didn't expect of_* name-space to be used in ARCH specific code. >> I think the new common function should be and can be generalized to work for >> powerpc. >> It would need to make reg property optional and pass in the device >> node to the arch specific function. >> >> A short term solution would be just to make the function "#ifndef CONFIG_PPC". > > I wouldn't do that, it's almost guaranteed to be messy going forward. > > I'd go for 1 above personally. Even though it's easier approach, I would go for fixing PPC and converge at generic of_get_cpu_node implementation if possible. Regards, Sudeep
On 13/08/13 22:07, Benjamin Herrenschmidt wrote: > On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote: >> I don't understand completely the use of ibm,ppc-interrupt-server#s and >> its implications on generic of_get_cpu_node implementation. >> I see the PPC specific definition of of_get_cpu_node uses thread id only >> in 2 instances. Based on that, I have tried to move all the other >> instances to use generic definition. >> >> Let me know if the idea is correct. > > No. The device-tree historically only represents cores, not HW threads, so > it makes sense to retrieve also the thread number corresponding to the CPU. > Ok > However, the mechanism to represent HW threads in the device-tree is currently > somewhat platform specific (the ibm,ppc-interrupt-server#s). I see most of the callers pass NULL to thread id argument except 2 instances in entire tree. If that's the case why can't we move to use generic of_get_cpu_node in most of those cases and have PPC specific implementation for the ones using thread id. > > So what you could do for now is: > > - Have a generic version that always returns 0 as the thread, which is weak I would prefer to move to generic of_get_cpu_node where ever possible and rename the function that takes thread id rather than making generic one weak. > > - powerpc keeps its own implementation How about only in cases where it needs thread_id. > > - Start a discussion on the bindings (if not already there) to define threads > in a better way at which point the generic function can be updated. > I am not sure if we need to define any new bindings. Excerpts from ePAPR (v1.1): "3.7.1 General Properties of CPU nodes The value of "reg" is a <prop-encoded-array> that defines a unique CPU/thread id for the CPU/threads represented by the CPU node. If a CPU supports more than one thread (i.e. multiple streams of execution) the reg property is an array with 1 element per thread. The #address-cells on the /cpus node specifies how many cells each element of the array takes. Software can determine the number of threads by dividing the size of reg by the parent node's #address-cells." And this is exactly in agreement to what's implemented in the generic of_get_cpu_node: for_each_child_of_node(cpus, cpun) { if (of_node_cmp(cpun->type, "cpu")) continue; cell = of_get_property(cpun, "reg", &prop_len); if (!cell) { pr_warn("%s: missing reg property\n", cpun->full_name); continue; } prop_len /= sizeof(*cell); while (prop_len) { hwid = of_read_number(cell, ac); prop_len -= ac; if (arch_match_cpu_phys_id(cpu, hwid)) return cpun; } } Yes this doesn't cover the historical "ibm,ppc-interrupt-server#s", for which we can have PPC specific wrapper above the generic one i.e. get the cpu node and then parse for thread id under custom property. Let me know your thoughts. Regards, Sudeep
On Wed, 2013-08-14 at 11:01 +0100, Sudeep KarkadaNagesha wrote: > Yes this doesn't cover the historical "ibm,ppc-interrupt-server#s", > for > which we can have PPC specific wrapper above the generic one i.e. get > the cpu node and then parse for thread id under custom property. A wrapper is wrong. I don't want to have to have all ppc callers to use a different function. As I said, just make a generic one that returns a thread ID, ie, same signature as the powerpc one. Make it weak, we can override it in powerpc-land, or we can move the ibm,ppc-interrupt-server#s handling into the generic one, it won't hurt, but leave the thread_id return there, it doesn't hurt it will come in handy in a few cases without causing code duplication. Cheers, Ben.
On 08/14/2013 05:01 AM, Sudeep KarkadaNagesha wrote: > On 13/08/13 22:07, Benjamin Herrenschmidt wrote: >> On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote: >>> I don't understand completely the use of ibm,ppc-interrupt-server#s and >>> its implications on generic of_get_cpu_node implementation. >>> I see the PPC specific definition of of_get_cpu_node uses thread id only >>> in 2 instances. Based on that, I have tried to move all the other >>> instances to use generic definition. >>> >>> Let me know if the idea is correct. >> >> No. The device-tree historically only represents cores, not HW threads, so >> it makes sense to retrieve also the thread number corresponding to the CPU. >> > Ok > >> However, the mechanism to represent HW threads in the device-tree is currently >> somewhat platform specific (the ibm,ppc-interrupt-server#s). > I see most of the callers pass NULL to thread id argument except 2 > instances in entire tree. If that's the case why can't we move to use > generic of_get_cpu_node in most of those cases and have PPC specific > implementation for the ones using thread id. > >> >> So what you could do for now is: >> >> - Have a generic version that always returns 0 as the thread, which is weak > I would prefer to move to generic of_get_cpu_node where ever possible > and rename the function that takes thread id rather than making generic > one weak. > >> >> - powerpc keeps its own implementation > How about only in cases where it needs thread_id. > >> >> - Start a discussion on the bindings (if not already there) to define threads >> in a better way at which point the generic function can be updated. >> > I am not sure if we need to define any new bindings. Excerpts from ePAPR > (v1.1): > "3.7.1 General Properties of CPU nodes > The value of "reg" is a <prop-encoded-array> that defines a unique > CPU/thread id for the CPU/threads represented by the CPU node. > If a CPU supports more than one thread (i.e. multiple streams of > execution) the reg property is an array with 1 element per thread. The > #address-cells on the /cpus node specifies how many cells each element > of the array takes. Software can determine the number of threads by > dividing the size of reg by the parent node's #address-cells." > > And this is exactly in agreement to what's implemented in the generic > of_get_cpu_node: > > for_each_child_of_node(cpus, cpun) { > if (of_node_cmp(cpun->type, "cpu")) > continue; > cell = of_get_property(cpun, "reg", &prop_len); > if (!cell) { > pr_warn("%s: missing reg property\n", cpun->full_name); > continue; > } > prop_len /= sizeof(*cell); > while (prop_len) { > hwid = of_read_number(cell, ac); > prop_len -= ac; > if (arch_match_cpu_phys_id(cpu, hwid)) > return cpun; > } > } How about something like this: for_each_child_of_node(cpus, cpun) { if (of_node_cmp(cpun->type, "cpu")) continue; if (arch_of_get_cpu_node(cpun, thread)) return cpun; cell = of_get_property(cpun, "reg", &prop_len); if (!cell) { pr_warn("%s: missing reg property\n", cpun->full_name); continue; } prop_len /= sizeof(*cell); while (prop_len) { hwid = of_read_number(cell, ac); prop_len -= ac; if (arch_match_cpu_phys_id(cpu, hwid)) return cpun; } } For PPC: arch_of_get_cpu_node() { const u32 *intserv; unsigned int plen, t; /* Check for ibm,ppc-interrupt-server#s. */ intserv = of_get_property(np, "ibm,ppc-interrupt-server#s", &plen); if (!intserv) return false; hardid = get_hard_smp_processor_id(cpu); plen /= sizeof(u32); for (t = 0; t < plen; t++) { if (hardid == intserv[t]) { if (thread) *thread = t; return true; } } return false; } > > Yes this doesn't cover the historical "ibm,ppc-interrupt-server#s", for > which we can have PPC specific wrapper above the generic one i.e. get > the cpu node and then parse for thread id under custom property. > > Let me know your thoughts. > > Regards, > Sudeep > > >
On 14/08/13 12:37, Benjamin Herrenschmidt wrote: > On Wed, 2013-08-14 at 11:01 +0100, Sudeep KarkadaNagesha wrote: >> Yes this doesn't cover the historical "ibm,ppc-interrupt-server#s", >> for >> which we can have PPC specific wrapper above the generic one i.e. get >> the cpu node and then parse for thread id under custom property. > > A wrapper is wrong. I don't want to have to have all ppc callers to use > a different function. Ok. On the side note the main intention of this patch series[1] is to avoid calling of_get_cpu_node function once CPU devices are registered. It initialises the of_node in all the cpu devices using this function when registering the CPU device. It can be retrieved from cpu_dev->of_node. So direct users of of_get_cpu_node can be reduced to avoid unnecessary parsing of DT to find cpu node. > > As I said, just make a generic one that returns a thread ID, ie, same > signature as the powerpc one. Make it weak, we can override it in > powerpc-land, IMO, making generic definition which adhere to the ePAPR specification as weak is not so clean. > or we can move the ibm,ppc-interrupt-server#s handling > into the generic one, it won't hurt, but leave the thread_id return > there, it doesn't hurt it will come in handy in a few cases without > causing code duplication. > IMO moving of handling ibm,ppc-interrupt-server#s to generic code under #ifdef CONFIG_PPC seems to be cleaner approach than weak definitation. As per my understanding each thread is a different logical cpu. Each logical cpu is mapped to unique physical id(either present in reg field or legacy ibm,ppc-interrupt-server#s field). So given a logical cpu id we can get the cpu node corresponding to it. Looking @ smp_setup_cpu_maps in arch/powerpc/kernel/setup-common.c and the comment in the same file: "This implementation only supports power of 2 number of threads.." the thread id id is implicit in the logical cpu id. Do we need to fetch that from DT ? Regards, Sudeep [1] https://lkml.org/lkml/2013/7/22/219
On 14/08/13 13:53, Rob Herring wrote: > On 08/14/2013 05:01 AM, Sudeep KarkadaNagesha wrote: >> On 13/08/13 22:07, Benjamin Herrenschmidt wrote: >>> On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote: >>>> I don't understand completely the use of ibm,ppc-interrupt-server#s and >>>> its implications on generic of_get_cpu_node implementation. >>>> I see the PPC specific definition of of_get_cpu_node uses thread id only >>>> in 2 instances. Based on that, I have tried to move all the other >>>> instances to use generic definition. >>>> >>>> Let me know if the idea is correct. >>> >>> No. The device-tree historically only represents cores, not HW threads, so >>> it makes sense to retrieve also the thread number corresponding to the CPU. >>> >> Ok >> >>> However, the mechanism to represent HW threads in the device-tree is currently >>> somewhat platform specific (the ibm,ppc-interrupt-server#s). >> I see most of the callers pass NULL to thread id argument except 2 >> instances in entire tree. If that's the case why can't we move to use >> generic of_get_cpu_node in most of those cases and have PPC specific >> implementation for the ones using thread id. >> >>> >>> So what you could do for now is: >>> >>> - Have a generic version that always returns 0 as the thread, which is weak >> I would prefer to move to generic of_get_cpu_node where ever possible >> and rename the function that takes thread id rather than making generic >> one weak. >> >>> >>> - powerpc keeps its own implementation >> How about only in cases where it needs thread_id. >> >>> >>> - Start a discussion on the bindings (if not already there) to define threads >>> in a better way at which point the generic function can be updated. >>> >> I am not sure if we need to define any new bindings. Excerpts from ePAPR >> (v1.1): >> "3.7.1 General Properties of CPU nodes >> The value of "reg" is a <prop-encoded-array> that defines a unique >> CPU/thread id for the CPU/threads represented by the CPU node. >> If a CPU supports more than one thread (i.e. multiple streams of >> execution) the reg property is an array with 1 element per thread. The >> #address-cells on the /cpus node specifies how many cells each element >> of the array takes. Software can determine the number of threads by >> dividing the size of reg by the parent node's #address-cells." >> >> And this is exactly in agreement to what's implemented in the generic >> of_get_cpu_node: >> >> for_each_child_of_node(cpus, cpun) { >> if (of_node_cmp(cpun->type, "cpu")) >> continue; >> cell = of_get_property(cpun, "reg", &prop_len); >> if (!cell) { >> pr_warn("%s: missing reg property\n", cpun->full_name); >> continue; >> } >> prop_len /= sizeof(*cell); >> while (prop_len) { >> hwid = of_read_number(cell, ac); >> prop_len -= ac; >> if (arch_match_cpu_phys_id(cpu, hwid)) >> return cpun; >> } >> } > > How about something like this: > > for_each_child_of_node(cpus, cpun) { > if (of_node_cmp(cpun->type, "cpu")) > continue; > > if (arch_of_get_cpu_node(cpun, thread)) > return cpun; > > cell = of_get_property(cpun, "reg", &prop_len); > if (!cell) { > pr_warn("%s: missing reg property\n", cpun->full_name); > continue; > } > prop_len /= sizeof(*cell); > while (prop_len) { > hwid = of_read_number(cell, ac); > prop_len -= ac; > if (arch_match_cpu_phys_id(cpu, hwid)) > return cpun; > } > } > > For PPC: > > arch_of_get_cpu_node() > { > const u32 *intserv; > unsigned int plen, t; > > /* Check for ibm,ppc-interrupt-server#s. */ > intserv = of_get_property(np, "ibm,ppc-interrupt-server#s", > &plen); > if (!intserv) > return false; > > hardid = get_hard_smp_processor_id(cpu); > > plen /= sizeof(u32); > for (t = 0; t < plen; t++) { > if (hardid == intserv[t]) { > if (thread) > *thread = t; > return true; > } > } > return false; > } > Sorry responded to earlier mail before seeing this. This approach looks good, but we still need to have thread id as argument which should be fine. But as per my understanding on how logical cpu<->hard proccessor id is setup, the thread_id is implicit in the logical cpu id making it unnecessary to depend on DT each time. Regards, Sudeep >> >> Yes this doesn't cover the historical "ibm,ppc-interrupt-server#s", for >> which we can have PPC specific wrapper above the generic one i.e. get >> the cpu node and then parse for thread id under custom property. >> >> Let me know your thoughts. >> >> Regards, >> Sudeep >> >> >> > >
On Wed, 2013-08-14 at 14:21 +0100, Sudeep KarkadaNagesha wrote: > IMO moving of handling ibm,ppc-interrupt-server#s to generic code > under > #ifdef CONFIG_PPC seems to be cleaner approach than weak definitation. > > As per my understanding each thread is a different logical cpu. > Each logical cpu is mapped to unique physical id(either present in reg > field or legacy ibm,ppc-interrupt-server#s field). So given a logical > cpu id we can get the cpu node corresponding to it. > Looking @ smp_setup_cpu_maps in arch/powerpc/kernel/setup-common.c > and the comment in the same file: "This implementation only supports > power of 2 number of threads.." the thread id id is implicit in the > logical cpu id. Do we need to fetch that from DT ? I don't want those parsing routines to make those assumptions. We have changed our logical numbering in the past and may again. Cheers, Ben.