Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
Hello Shao-Hui,
On 12/21/2014 08:31 PM, Xie Shaohui-B21989 wrote:
On Fri, 2014-12-19 at 01:23 -0600, Xie Shaohui-B21989 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Friday, December 19, 2014 6:01 AM
To: Xie Shaohui-B21989
Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve
Emilian- EMMEDVE1; Liberman Igal-B31950
Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
On Thu, 2014-12-18 at 06:53 -0600, Xie Shaohui-B21989 wrote:
Ping.
Best Regards,
Shaohui Xie
I can't put patches in my -next until the merge window closes.
+EXAMPLE
+
+Example for FMan v2 external MDIO:
+
+mdio@f1000 {
+compatible = fsl,fman-xmdio;
+reg = 0xf1000 0x1000;
+bus-frequency = 2;
+};
So the bus frequency is only 20 KHz? Or is the unit supposed
to be something other than Hz?
[S.H] it's only an example, it could be different on real SoCs,
but they always lower than the standard one, The standard one is
2.5MHz, I have
to use Hz for it.
Is there any SoC for which 20 kHz is the right frequency? I just
want to make sure the example is realistic.
[S.H] the clock divider has a limitation that the MAX value it can get
on Fman v2 is 255 (0xff, 8 bits), On Fman v3 is 511(0x1ff, 9 bits).
So the lowest frequency on Fman v2 is: Fman_clock / (2 * 255), On Fman
v3 is: Fman_clock / ((2 * 511) + 1).
Take default Fman frequency setting from SDK1.7 as example, the lowest
clock used for Fman v2 is 581MHz, The lowest clock for Fman v3 is 600MHz.
Then the lowest bus frequency can get is:
Fman v2: ~1140KHz
Fman v3: ~587KHz
20KHz is not practice, we don't have a suggested value in errata document.
For this example, should I post a new version with a value like 1200KHz?
This is different from how you described the problem before. If the
limitation
is on the divider, rather than the absolute bus frequency, then specifiy
the max
divider. Or better, since according to the above this correlates with fman
version, just have the driver know what the max divider is for each fman
version.
[S.H] The problem is not the divider has limitation, the problem is a
different bus frequency
Is needed which is lower than the standard, but due to the divider
limitation, the lowest
bus frequency also has limitation. i.e. we need to use the divider to get a
lower frequency,
but how much lower the value could be is restricted by the divider
limitation.
This is difficult to follow -- are you saying the erratum requires a
speed that is not achievable?
For the purpose of an example in the binding document, I suggest we just
stick with the IEEE standard frequency.
The whole reason for this property existing in the device tree is
non-standard frequencies.
We can continue this conversation about errata handling when we submit
the code relevant to this binding (and the FMan v3 support)
It affects the binding, so let's discuss it now please.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v3.19-rc1
On Mon, Dec 22, 2014 at 9:31 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
Below is the list of build error/warning regressions/improvements in
v3.19-rc1[1] compared to v3.18[2].
Summarized:
- build errors: +24/-16
+ /home/kisskb/slave/src/arch/powerpc/xmon/xmon.c: error: unused
variable 'badaddr' [-Werror=unused-variable]: = 1185:13
+ /home/kisskb/slave/src/arch/powerpc/xmon/xmon.c: error: unused
variable 'mode' [-Werror=unused-variable]: = 1183:6
powerpc-randconfig
+ /home/kisskb/slave/src/arch/sh/boards/mach-se/7343/irq.c: error:
too few arguments to function 'ioread16': = 44:2
+ /home/kisskb/slave/src/arch/sh/boards/mach-se/7343/irq.c: error:
too few arguments to function 'iowrite16': = 123:2
sh4/se7343_defconfig
+ /home/kisskb/slave/src/arch/sh/boards/mach-se/7722/irq.c: error:
too few arguments to function 'ioread16': = 43:2
+ /home/kisskb/slave/src/arch/sh/boards/mach-se/7722/irq.c: error:
too few arguments to function 'iowrite16': = 116:2
sh4/se7722_defconfig
+ /home/kisskb/slave/src/drivers/usb/musb/blackfin.c: error:
'bfin_writel' undeclared here (not in a function): = 476:13
bfin/BF527-EZKIT-V2_defconfig
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_BABBLE_CTL' undeclared here (not in a function): = 67:17
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_CONFIGDATA' undeclared here (not in a function): = 62:18
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_EPINFO' undeclared here (not in a function): = 74:14
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_RAMINFO' undeclared here (not in a function): = 75:15
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_RXFIFOADD' undeclared here (not in a function): = 71:17
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_RXFIFOSZ' undeclared here (not in a function): = 69:16
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_TXFIFOADD' undeclared here (not in a function): = 70:17
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_TXFIFOSZ' undeclared here (not in a function): = 68:16
bfin/BF527-EZKIT_defconfig
bfin/BF527-EZKIT-V2_defconfig
bfin/BF548-EZKIT_defconfig
bfin/CM-BF548_defconfig
bfin/CM-BF527_defconfig
+ /home/kisskb/slave/src/include/linux/irq.h: error: conflicting
types for 'ioread16': = 856:19
+ /home/kisskb/slave/src/include/linux/irq.h: error: conflicting
types for 'iowrite16': = 847:20
sh4/se7343_defconfig
sh4/se7722_defconfig
+ error: csum_partial_copy_nocheck [net/ipv6/ipv6.ko] undefined!: = N/A
cris/cris-allmodconfig
+ error: No rule to make target include/config/auto.conf: = N/A
arm/arm-randconfig
[1] http://kisskb.ellerman.id.au/kisskb/head/8241/ (262 out of 262 configs)
[2] http://kisskb.ellerman.id.au/kisskb/head/8168/ (262 out of 262 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
-Original Message-
From: Wood Scott-B07421
Sent: Monday, December 22, 2014 4:33 PM
To: Medve Emilian-EMMEDVE1
Cc: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org;
devicet...@vger.kernel.org; Liberman Igal-B31950
Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
Hello Shao-Hui,
On 12/21/2014 08:31 PM, Xie Shaohui-B21989 wrote:
On Fri, 2014-12-19 at 01:23 -0600, Xie Shaohui-B21989 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Friday, December 19, 2014 6:01 AM
To: Xie Shaohui-B21989
Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org;
Medve
Emilian- EMMEDVE1; Liberman Igal-B31950
Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
On Thu, 2014-12-18 at 06:53 -0600, Xie Shaohui-B21989 wrote:
Ping.
Best Regards,
Shaohui Xie
I can't put patches in my -next until the merge window closes.
+EXAMPLE
+
+Example for FMan v2 external MDIO:
+
+mdio@f1000 {
+ compatible = fsl,fman-xmdio;
+ reg = 0xf1000 0x1000;
+ bus-frequency = 2;
+};
So the bus frequency is only 20 KHz? Or is the unit supposed
to be something other than Hz?
[S.H] it's only an example, it could be different on real SoCs,
but they always lower than the standard one, The standard one
is 2.5MHz, I have
to use Hz for it.
Is there any SoC for which 20 kHz is the right frequency? I just
want to make sure the example is realistic.
[S.H] the clock divider has a limitation that the MAX value it can
get on Fman v2 is 255 (0xff, 8 bits), On Fman v3 is 511(0x1ff, 9 bits).
So the lowest frequency on Fman v2 is: Fman_clock / (2 * 255), On
Fman
v3 is: Fman_clock / ((2 * 511) + 1).
Take default Fman frequency setting from SDK1.7 as example, the
lowest clock used for Fman v2 is 581MHz, The lowest clock for Fman v3 is
600MHz.
Then the lowest bus frequency can get is:
Fman v2: ~1140KHz
Fman v3: ~587KHz
20KHz is not practice, we don't have a suggested value in errata
document.
For this example, should I post a new version with a value like 1200KHz?
This is different from how you described the problem before. If
the limitation is on the divider, rather than the absolute bus
frequency, then specifiy the max divider. Or better, since
according to the above this correlates with fman version, just have the
driver know what the max divider is for each fman version.
[S.H] The problem is not the divider has limitation, the problem is
a different bus frequency Is needed which is lower than the
standard, but due to the divider limitation, the lowest bus
frequency also has limitation. i.e. we need to use the divider to get a
lower frequency, but how much lower the value could be is restricted by the
divider limitation.
This is difficult to follow -- are you saying the erratum requires a speed
that
is not achievable?
[S.H] The errata only stated that it need to use a larger divider to reduce the
clock
Frequency, but it did not provide a suggested value, what we know is since the
divider
Has a limitation, then how much lower the clock frequency could be reduced has
a limitation.
Thanks!
Shaohui
For the purpose of an example in the binding document, I suggest we
just stick with the IEEE standard frequency.
The whole reason for this property existing in the device tree is non-standard
frequencies.
We can continue this conversation about errata handling when we submit
the code relevant to this binding (and the FMan v3 support)
It affects the binding, so let's discuss it now please.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
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 diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c index 8ec017c..9e29836 100644 --- a/arch/powerpc/kernel/smp.c +++ b/arch/powerpc/kernel/smp.c @@ -703,10 +703,6 @@ void start_secondary(void *unused) if (smp_ops-setup_cpu) smp_ops-setup_cpu(cpu); - if (smp_ops-take_timebase) - smp_ops-take_timebase(); - - secondary_cpu_time_init(); #ifdef CONFIG_PPC64 if (system_state == SYSTEM_RUNNING) @@ -746,6 +742,16 @@ void start_secondary(void *unused) smp_wmb(); cpu_callin_map[cpu] = 1; + /* +* We need to take timebase after bootup cpu give the timebase. +* Base on cpu_callin_map move to here, so we also need move +* take_timebase. Because bootup cpu waiting for cpu_callin_map +* be set after that give_timebase can be executed. +*/ + if (smp_ops-take_timebase) + smp_ops-take_timebase(); + secondary_cpu_time_init(); + local_irq_enable(); cpu_startup_entry(CPUHP_ONLINE); -- 2.1.0.27.g96db324 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote: Hello Scott, On 12/22/2014 02:32 AM, Scott Wood wrote: On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote: For the purpose of an example in the binding document, I suggest we just stick with the IEEE standard frequency. The whole reason for this property existing in the device tree is non-standard frequencies. While the standard claims 2.5 MHz, most MDIO controllers and PHY devices support frequencies well beyond the standard. Specifying a lower then the standard frequency for the benefit of some errata is just one side of this property The erratum was (until now) the only claimed reason for it. If there are other reasons why one would specify a different frequency (in particular, that relate to hardware description), please elaborate. We can continue this conversation about errata handling when we submit the code relevant to this binding (and the FMan v3 support) It affects the binding, so let's discuss it now please. I think this specific (unpublished yet) errata has less bearing on the binding then you might believe. This is mostly about providing a common/default frequency supported by all the devices on some board What reason other than an erratum would there be for the standard frequency not being supported? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
Hello Scott,
On 12/22/2014 02:32 AM, Scott Wood wrote:
On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
Hello Shao-Hui,
On 12/21/2014 08:31 PM, Xie Shaohui-B21989 wrote:
On Fri, 2014-12-19 at 01:23 -0600, Xie Shaohui-B21989 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Friday, December 19, 2014 6:01 AM
To: Xie Shaohui-B21989
Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve
Emilian- EMMEDVE1; Liberman Igal-B31950
Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
On Thu, 2014-12-18 at 06:53 -0600, Xie Shaohui-B21989 wrote:
Ping.
Best Regards,
Shaohui Xie
I can't put patches in my -next until the merge window closes.
+EXAMPLE
+
+Example for FMan v2 external MDIO:
+
+mdio@f1000 {
+compatible = fsl,fman-xmdio;
+reg = 0xf1000 0x1000;
+bus-frequency = 2;
+};
So the bus frequency is only 20 KHz? Or is the unit supposed
to be something other than Hz?
[S.H] it's only an example, it could be different on real SoCs,
but they always lower than the standard one, The standard one is
2.5MHz, I have
to use Hz for it.
Is there any SoC for which 20 kHz is the right frequency? I just
want to make sure the example is realistic.
[S.H] the clock divider has a limitation that the MAX value it can get
on Fman v2 is 255 (0xff, 8 bits), On Fman v3 is 511(0x1ff, 9 bits).
So the lowest frequency on Fman v2 is: Fman_clock / (2 * 255), On Fman
v3 is: Fman_clock / ((2 * 511) + 1).
Take default Fman frequency setting from SDK1.7 as example, the lowest
clock used for Fman v2 is 581MHz, The lowest clock for Fman v3 is 600MHz.
Then the lowest bus frequency can get is:
Fman v2: ~1140KHz
Fman v3: ~587KHz
20KHz is not practice, we don't have a suggested value in errata document.
For this example, should I post a new version with a value like 1200KHz?
This is different from how you described the problem before. If the
limitation
is on the divider, rather than the absolute bus frequency, then specifiy
the max
divider. Or better, since according to the above this correlates with fman
version, just have the driver know what the max divider is for each fman
version.
[S.H] The problem is not the divider has limitation, the problem is a
different bus frequency
Is needed which is lower than the standard, but due to the divider
limitation, the lowest
bus frequency also has limitation. i.e. we need to use the divider to get a
lower frequency,
but how much lower the value could be is restricted by the divider
limitation.
This is difficult to follow -- are you saying the erratum requires a
speed that is not achievable?
For the purpose of an example in the binding document, I suggest we just
stick with the IEEE standard frequency.
The whole reason for this property existing in the device tree is
non-standard frequencies.
While the standard claims 2.5 MHz, most MDIO controllers and PHY devices
support frequencies well beyond the standard. Specifying a lower then
the standard frequency for the benefit of some errata is just one side
of this property
We can continue this conversation about errata handling when we submit
the code relevant to this binding (and the FMan v3 support)
It affects the binding, so let's discuss it now please.
I think this specific (unpublished yet) errata has less bearing on the
binding then you might believe. This is mostly about providing a
common/default frequency supported by all the devices on some board
Anyway, the above thread about bits and lowest frequency limitation(s)
is not really a problem/limitation. The range of frequencies (dividers)
supported by both controller versions in all the supported SoC(s) allows
responding to this (FMan v3 only) errata just fine
Cheers,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
Hello Shao-Hui,
On 12/21/2014 08:31 PM, Xie Shaohui-B21989 wrote:
On Fri, 2014-12-19 at 01:23 -0600, Xie Shaohui-B21989 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Friday, December 19, 2014 6:01 AM
To: Xie Shaohui-B21989
Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve
Emilian- EMMEDVE1; Liberman Igal-B31950
Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
On Thu, 2014-12-18 at 06:53 -0600, Xie Shaohui-B21989 wrote:
Ping.
Best Regards,
Shaohui Xie
I can't put patches in my -next until the merge window closes.
+EXAMPLE
+
+Example for FMan v2 external MDIO:
+
+mdio@f1000 {
+ compatible = fsl,fman-xmdio;
+ reg = 0xf1000 0x1000;
+ bus-frequency = 2;
+};
So the bus frequency is only 20 KHz? Or is the unit supposed
to be something other than Hz?
[S.H] it's only an example, it could be different on real SoCs,
but they always lower than the standard one, The standard one is
2.5MHz, I have
to use Hz for it.
Is there any SoC for which 20 kHz is the right frequency? I just
want to make sure the example is realistic.
[S.H] the clock divider has a limitation that the MAX value it can get
on Fman v2 is 255 (0xff, 8 bits), On Fman v3 is 511(0x1ff, 9 bits).
So the lowest frequency on Fman v2 is: Fman_clock / (2 * 255), On Fman
v3 is: Fman_clock / ((2 * 511) + 1).
Take default Fman frequency setting from SDK1.7 as example, the lowest
clock used for Fman v2 is 581MHz, The lowest clock for Fman v3 is 600MHz.
Then the lowest bus frequency can get is:
Fman v2: ~1140KHz
Fman v3: ~587KHz
20KHz is not practice, we don't have a suggested value in errata document.
For this example, should I post a new version with a value like 1200KHz?
This is different from how you described the problem before. If the
limitation
is on the divider, rather than the absolute bus frequency, then specifiy the
max
divider. Or better, since according to the above this correlates with fman
version, just have the driver know what the max divider is for each fman
version.
[S.H] The problem is not the divider has limitation, the problem is a
different bus frequency
Is needed which is lower than the standard, but due to the divider
limitation, the lowest
bus frequency also has limitation. i.e. we need to use the divider to get a
lower frequency,
but how much lower the value could be is restricted by the divider limitation.
For the purpose of an example in the binding document, I suggest we just
stick with the IEEE standard frequency. We can continue this
conversation about errata handling when we submit the code relevant to
this binding (and the FMan v3 support)
Cheers,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 0/2] powerpc32: handle inverted _PAGE_RW bit outside of TLB handlers
Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only) bit. This patch implements the handling of a _PAGE_RO flag to be used in place of _PAGE_RW Patchset: 1) powerpc32: adds handling of _PAGE_RO 2) powerpc/8xx: use _PAGE_RO instead of _PAGE_RW All changes have been successfully tested on MPC885 Signed-off-by: Christophe Leroy christophe.le...@c-s.fr Tested-by: Christophe Leroy christophe.le...@c-s.fr --- v2 is a complete rework compared to v1 v3 takes into account comments from Scott on v2 arch/powerpc/include/asm/pgtable-ppc32.h | 12 +++- arch/powerpc/include/asm/pgtable.h | 7 +-- arch/powerpc/include/asm/pte-8xx.h | 9 - arch/powerpc/include/asm/pte-common.h| 25 + arch/powerpc/kernel/head_8xx.S | 3 --- arch/powerpc/mm/gup.c| 2 ++ arch/powerpc/mm/pgtable_32.c | 2 +- 7 files changed, 36 insertions(+), 24 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/2] powerpc32: adds handling of _PAGE_RO
Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only)
bit.
This patch implements the handling of a _PAGE_RO flag to be used in place of
_PAGE_RW
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
v2 is a complete rework of v1
v3:
- cleared PTE can remain 0, no need of _PAGE_RO on PAGE_NONE
- fix __ptep_set_access_flags() to be independant of clear/set order in
pte_update()
arch/powerpc/include/asm/pgtable-ppc32.h | 7 ---
arch/powerpc/include/asm/pgtable.h | 7 +--
arch/powerpc/include/asm/pte-common.h| 25 +
arch/powerpc/mm/gup.c| 2 ++
arch/powerpc/mm/pgtable_32.c | 2 +-
5 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h
b/arch/powerpc/include/asm/pgtable-ppc32.h
index 543bb8e..caf094a 100644
--- a/arch/powerpc/include/asm/pgtable-ppc32.h
+++ b/arch/powerpc/include/asm/pgtable-ppc32.h
@@ -275,7 +275,7 @@ static inline pte_t ptep_get_and_clear(struct mm_struct
*mm, unsigned long addr,
static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
{
- pte_update(ptep, (_PAGE_RW | _PAGE_HWWRITE), 0);
+ pte_update(ptep, (_PAGE_RW | _PAGE_HWWRITE), _PAGE_RO);
}
static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
unsigned long addr, pte_t *ptep)
@@ -286,9 +286,10 @@ static inline void huge_ptep_set_wrprotect(struct
mm_struct *mm,
static inline void __ptep_set_access_flags(pte_t *ptep, pte_t entry)
{
- unsigned long bits = pte_val(entry)
+ unsigned long set = pte_val(entry)
(_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_RW | _PAGE_EXEC);
- pte_update(ptep, 0, bits);
+ unsigned long clr = ~pte_val(entry) _PAGE_RO;
+ pte_update(ptep, clr, set);
}
#define __HAVE_ARCH_PTE_SAME
diff --git a/arch/powerpc/include/asm/pgtable.h
b/arch/powerpc/include/asm/pgtable.h
index 316f9a5..0f713fa 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -30,7 +30,8 @@ struct mm_struct;
#include asm/tlbflush.h
/* Generic accessors to PTE bits */
-static inline int pte_write(pte_t pte) { return pte_val(pte)
_PAGE_RW; }
+static inline int pte_write(pte_t pte)
+{ return (pte_val(pte) (_PAGE_RW | _PAGE_RO)) != _PAGE_RO; }
static inline int pte_dirty(pte_t pte) { return pte_val(pte)
_PAGE_DIRTY; }
static inline int pte_young(pte_t pte) { return pte_val(pte)
_PAGE_ACCESSED; }
static inline int pte_file(pte_t pte) { return pte_val(pte)
_PAGE_FILE; }
@@ -115,12 +116,14 @@ static inline unsigned long pte_pfn(pte_t pte){
/* Generic modifiers for PTE bits */
static inline pte_t pte_wrprotect(pte_t pte) {
- pte_val(pte) = ~(_PAGE_RW | _PAGE_HWWRITE); return pte; }
+ pte_val(pte) = ~(_PAGE_RW | _PAGE_HWWRITE);
+ pte_val(pte) |= _PAGE_RO; return pte; }
static inline pte_t pte_mkclean(pte_t pte) {
pte_val(pte) = ~(_PAGE_DIRTY | _PAGE_HWWRITE); return pte; }
static inline pte_t pte_mkold(pte_t pte) {
pte_val(pte) = ~_PAGE_ACCESSED; return pte; }
static inline pte_t pte_mkwrite(pte_t pte) {
+ pte_val(pte) = ~_PAGE_RO;
pte_val(pte) |= _PAGE_RW; return pte; }
static inline pte_t pte_mkdirty(pte_t pte) {
pte_val(pte) |= _PAGE_DIRTY; return pte; }
diff --git a/arch/powerpc/include/asm/pte-common.h
b/arch/powerpc/include/asm/pte-common.h
index e040c35..2aef9b7 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -34,6 +34,12 @@
#ifndef _PAGE_PSIZE
#define _PAGE_PSIZE0
#endif
+/* _PAGE_RO and _PAGE_RW shall not be defined at the same time */
+#ifndef _PAGE_RO
+#define _PAGE_RO 0
+#else
+#define _PAGE_RW 0
+#endif
#ifndef _PMD_PRESENT_MASK
#define _PMD_PRESENT_MASK _PMD_PRESENT
#endif
@@ -42,10 +48,10 @@
#define PMD_PAGE_SIZE(pmd) bad_call_to_PMD_PAGE_SIZE()
#endif
#ifndef _PAGE_KERNEL_RO
-#define _PAGE_KERNEL_RO0
+#define _PAGE_KERNEL_RO(_PAGE_RO)
#endif
#ifndef _PAGE_KERNEL_ROX
-#define _PAGE_KERNEL_ROX (_PAGE_EXEC)
+#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_RO)
#endif
#ifndef _PAGE_KERNEL_RW
#define _PAGE_KERNEL_RW(_PAGE_DIRTY | _PAGE_RW | _PAGE_HWWRITE)
@@ -95,7 +101,7 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
/* Mask of bits returned by pte_pgprot() */
#define PAGE_PROT_BITS (_PAGE_GUARDED | _PAGE_COHERENT | _PAGE_NO_CACHE | \
_PAGE_WRITETHRU | _PAGE_ENDIAN | _PAGE_4K_PFN | \
-_PAGE_USER | _PAGE_ACCESSED | \
+_PAGE_USER | _PAGE_ACCESSED | _PAGE_RO | \
_PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | _PAGE_EXEC)
#ifdef CONFIG_NUMA_BALANCING
@@ -128,11 +134,14 @@ extern unsigned long
[PATCH v3 2/2] powerpc/8xx: use _PAGE_RO instead of _PAGE_RW
On powerpc 8xx, in TLB entries, 0x400 bit is set to 1 for read-only pages and is set to 0 for RW pages. So we should use _PAGE_RO instead of _PAGE_RW Signed-off-by: Christophe Leroy christophe.le...@c-s.fr --- v2 is a complete rework compared to v1 v3: fixing pte_update() and comments arch/powerpc/include/asm/pgtable-ppc32.h | 5 +++-- arch/powerpc/include/asm/pte-8xx.h | 9 - arch/powerpc/kernel/head_8xx.S | 3 --- 3 files changed, 7 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h index caf094a..b4e0c3b 100644 --- a/arch/powerpc/include/asm/pgtable-ppc32.h +++ b/arch/powerpc/include/asm/pgtable-ppc32.h @@ -178,9 +178,10 @@ static inline unsigned long pte_update(pte_t *p, andc%1,%0,%5\n\ or %1,%1,%6\n\ /* 0x200 == Extended encoding, bit 22 */ \ - /* Bit 22 has to be 1 if neither _PAGE_USER nor _PAGE_RW are set */ \ + /* Bit 22 has to be 1 when _PAGE_USER is unset and _PAGE_RO is set */ \ rlwimi %1,%1,32-2,0x200\n /* get _PAGE_USER */ \ - rlwinm %3,%1,32-1,0x200\n /* get _PAGE_RW */ \ + rlwinm %3,%1,32-1,0x200\n /* get _PAGE_RO */ \ + xori%3,%3,0x200\n \ or %1,%3,%1\n\ xori%1,%1,0x200\n stwcx. %1,0,%4\n\ diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h index daa4616..eb6edb4 100644 --- a/arch/powerpc/include/asm/pte-8xx.h +++ b/arch/powerpc/include/asm/pte-8xx.h @@ -46,9 +46,9 @@ * require a TLB exception handler change. It is assumed unused bits * are always zero. */ -#define _PAGE_RW 0x0400 /* lsb PP bits, inverted in HW */ +#define _PAGE_RO 0x0400 /* lsb PP bits */ #define _PAGE_USER 0x0800 /* msb PP bits */ -/* set when neither _PAGE_USER nor _PAGE_RW are set */ +/* set when _PAGE_USER is unset and _PAGE_RO is set */ #define _PAGE_KNLRO0x0200 #define _PMD_PRESENT 0x0001 @@ -62,9 +62,8 @@ #define PTE_ATOMIC_UPDATES 1 /* We need to add _PAGE_SHARED to kernel pages */ -#define _PAGE_KERNEL_RO(_PAGE_SHARED | _PAGE_KNLRO) -#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_KNLRO) -#define _PAGE_KERNEL_RW(_PAGE_DIRTY | _PAGE_RW | _PAGE_HWWRITE) +#define _PAGE_KERNEL_RO(_PAGE_SHARED | _PAGE_RO | _PAGE_KNLRO) +#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_RO | _PAGE_KNLRO) #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_PTE_8xx_H */ diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 3d4b8ee..807b0db 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -441,9 +441,6 @@ DataStoreTLBMiss: and r11, r11, r10 rlwimi r10, r11, 0, _PAGE_PRESENT #endif - /* invert RW */ - xorir10, r10, _PAGE_RW - /* The Linux PTE won't go exactly into the MMU TLB. * Software indicator bits 22 and 28 must be clear. * Software indicator bits 24, 25, 26, and 27 must be -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2 PATCH 1/2] powerpc32: adds handling of _PAGE_RO
Le 18/12/2014 03:14, Scott Wood a écrit :
On Wed, 2014-12-17 at 10:14 +0100, Christophe Leroy wrote:
Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only)
bit.
This patch implements the handling of a _PAGE_RO flag to be used in place of
_PAGE_RW
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
v2 is a complete rework compared to v1
arch/powerpc/include/asm/pgtable-ppc32.h | 11 ++-
arch/powerpc/include/asm/pgtable.h | 10 +++---
arch/powerpc/include/asm/pte-common.h| 27 ++-
arch/powerpc/mm/gup.c| 2 ++
arch/powerpc/mm/mem.c| 2 +-
arch/powerpc/mm/pgtable_32.c | 24
6 files changed, 54 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h
b/arch/powerpc/include/asm/pgtable-ppc32.h
index 543bb8e..64ed9e1 100644
--- a/arch/powerpc/include/asm/pgtable-ppc32.h
+++ b/arch/powerpc/include/asm/pgtable-ppc32.h
@@ -125,7 +125,7 @@ extern int icache_44x_need_flush;
#ifndef __ASSEMBLY__
#define pte_clear(mm, addr, ptep) \
- do { pte_update(ptep, ~_PAGE_HASHPTE, 0); } while (0)
+ do { pte_update(ptep, ~_PAGE_HASHPTE, _PAGE_RO); } while (0)
Is this really necessary? It's already clearing the valid bit.
Likewise in several other places that set or check for _PAGE_RO on pages
for which no access is permitted.
You are right, this is not needed. I needed it because I had defined
pte_none() as requiring _PAGE_RO set. But we can keep value 0 as
pte_none. Taken into account in v3
Christophe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/config: enable mdio buses muxing via Memory-mapped device
From: Andy Fleming aflem...@gmail.com Signed-off-by: Andy Fleming aflem...@gmail.com Signed-off-by: Shaohui Xie shaohui@freescale.com --- arch/powerpc/configs/corenet32_smp_defconfig | 1 + arch/powerpc/configs/corenet64_smp_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index 7525835..6577c41 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -105,6 +105,7 @@ CONFIG_AT803X_PHY=y CONFIG_FIXED_PHY=y CONFIG_MDIO_BUS_MUX=y CONFIG_MDIO_BUS_MUX_GPIO=y +CONFIG_MDIO_BUS_MUX_MMIOREG=y # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index f915fe4..4016cf6 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -82,6 +82,7 @@ CONFIG_DUMMY=y CONFIG_E1000E=y CONFIG_MDIO_BUS_MUX=y CONFIG_MDIO_BUS_MUX_GPIO=y +CONFIG_MDIO_BUS_MUX_MMIOREG=y CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set -- 1.8.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/config: enable mdio buses muxing via gpio
From: Andy Fleming aflem...@gmail.com Signed-off-by: Andy Fleming aflem...@gmail.com Signed-off-by: Shaohui Xie shaohui@freescale.com --- arch/powerpc/configs/corenet32_smp_defconfig | 2 ++ arch/powerpc/configs/corenet64_smp_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index 611efe9..7525835 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -103,6 +103,8 @@ CONFIG_E1000E=y CONFIG_VITESSE_PHY=y CONFIG_AT803X_PHY=y CONFIG_FIXED_PHY=y +CONFIG_MDIO_BUS_MUX=y +CONFIG_MDIO_BUS_MUX_GPIO=y # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index be24a18..f915fe4 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -80,6 +80,8 @@ CONFIG_SATA_SIL24=y CONFIG_NETDEVICES=y CONFIG_DUMMY=y CONFIG_E1000E=y +CONFIG_MDIO_BUS_MUX=y +CONFIG_MDIO_BUS_MUX_GPIO=y CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set -- 1.8.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
Hello Scott, On 12/22/2014 03:42 AM, Scott Wood wrote: On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote: Hello Scott, On 12/22/2014 02:32 AM, Scott Wood wrote: On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote: For the purpose of an example in the binding document, I suggest we just stick with the IEEE standard frequency. The whole reason for this property existing in the device tree is non-standard frequencies. While the standard claims 2.5 MHz, most MDIO controllers and PHY devices support frequencies well beyond the standard. Specifying a lower then the standard frequency for the benefit of some errata is just one side of this property The erratum was (until now) the only claimed reason for it. If there are other reasons why one would specify a different frequency (in particular, that relate to hardware description), please elaborate. From memory, the 1 Gb/s Vitesse PHY(s) we have on some of our DS boards support 12.5 MHz. I can dig out more specs for specifics on other PHY(s) 2.5 MHz is slow and even more so for high speed interfaces. With both polling and interrupts (both MDIO and/or PHY) we've noticed (or blamed) in the past some Ethernet performance issues on this very slowness As of right now I'm not aware of another way to specify/coordinate the MDC speed so setting a default (common denominator) in the DT that is different then the IEEE standard seems ok We can continue this conversation about errata handling when we submit the code relevant to this binding (and the FMan v3 support) It affects the binding, so let's discuss it now please. I think this specific (unpublished yet) errata has less bearing on the binding then you might believe. This is mostly about providing a common/default frequency supported by all the devices on some board What reason other than an erratum would there be for the standard frequency not being supported? This is not about not supporting the standard frequency. This is about the default frequency being different then the standard Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull mpe/linux.git powerpc-3.19-2 tag
Michael Ellerman m...@ellerman.id.au writes: Anton Blanchard (1): powerpc: Secondary CPUs must set cpu_callin_map after setting active and online This breaks booting on the PowerMac7,3. It takes forever to boot to user space (~5 minutes instead of ~4 seconds), and then I see these processes in top: 37 root 20 0 0 0 0 D 0.000 0.000 0:00.00 kwindfarm 10 root rt 0 0 0 0 R 0.000 0.000 0:00.00 migration/1 11 root 20 0 0 0 0 R 0.000 0.000 0:00.00 ksoftirqd/1 (The latter two processes don't accumulate any cpu time, but they are constantly in run state.) Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 1/4] tools/perf: support parsing parameterized events
On Sun, Dec 21, 2014 at 11:49:24PM -0800, Sukadev Bhattiprolu wrote:
SNIP
+ }
switch (format-value) {
case PERF_PMU_FORMAT_VALUE_CONFIG:
@@ -592,11 +629,16 @@ static int pmu_config_term(struct list_head *formats,
}
/*
- * XXX If we ever decide to go with string values for
- * non-hardcoded terms, here's the place to translate
- * them into value.
+ * Either directly use a numeric term, or try to translate string terms
+ * using event parameters.
*/
- pmu_format_value(format-bits, term-val.num, vp, zero);
+ if (term-type_val == PARSE_EVENTS__TERM_TYPE_NUM)
+ val = term-val.num;
+ else
+ if (pmu_resolve_param_term(term, head_terms, val))
+ return -EINVAL;
+
I'm ok with the change logic, but I'm missing here check for the 'term'
string value to be '?', so we force subst terms to have '?' as value..
I believe thats what we decided in the previous set discussion, right?
I guess the it'd be nice to parse it directly in the bison code like
below (could be done later), but I'd be ok with simple check on this
place for now.
thanks,
jirka
---
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 93c4c9fbc922..7e021c64d5cc 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -484,6 +484,14 @@ PE_TERM '=' PE_VALUE
$$ = term;
}
|
+PE_TERM '=' PE_SUBST
+{
+ struct parse_events_term *term;
+
+ ABORT_ON(parse_events_term__subst(term, (int)$1, NULL, NULL));
+ $$ = term;
+}
+|
PE_TERM
{
struct parse_events_term *term;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 3/4] perf Documentation: add event parameters
On Sun, Dec 21, 2014 at 11:49:26PM -0800, Sukadev Bhattiprolu wrote: From: Cody P Schafer c...@linux.vnet.ibm.com Event parameters are a basic way for partial events to be specified in sysfs with per-event names given to the fields that need to be filled in when using a particular event. It is intended for supporting cases where the single 'cpu' parameter is insufficient. For example, POWER 8 has events for physical sockets/cores/cpus that are accessible from with virtual machines. To keep using the single 'cpu' parameter we'd need to perform a mapping between Linux's cpus and the physical machine's cpus (in this case Linux is running under a hypervisor). This isn't possible because bindings between our cpus and physical cpus may not be fixed, and we probably won't have a cpu on each physical cpu. Changelog[v6] Update event description to explain how required parameters are displayed. CC: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com CC: Haren Myneni hb...@us.ibm.com CC: Cody P Schafer d...@codyps.com Signed-off-by: Cody P Schafer c...@linux.vnet.ibm.com --- Documentation/ABI/testing/sysfs-bus-event_source-devices-events | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events index 20979f8..47ad2a1 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events @@ -52,12 +52,18 @@ Description: Per-pmu performance monitoring events specific to the running syste event=0x2abc event=0x423,inv,cmask=0x3 domain=0x1,offset=0x8,starting_index=0x + domain=0x1,offset=0x8,core=? Each of the assignments indicates a value to be assigned to a particular set of bits (as defined by the format file corresponding to the term) in the perf_event structure passed to the perf_open syscall. + In the case of the last example, a value replacing ? would + need to be provided by the user selecting the particular event. + This is referred to as event parameterization. All + non-numerical values indicate an event parameter. I see.. here's the glitch ;-) I thought we agreed on forcing '?' as the value for param events, not 'All non-numerical values' thanks, jirka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 4/4] tools/perf: Document parameterized and symbolic events
On Sun, Dec 21, 2014 at 11:49:27PM -0800, Sukadev Bhattiprolu wrote:
From: Cody P Schafer c...@linux.vnet.ibm.com
Changelog[v6]:
- [Sukadev Bhattiprolu]: Update documentation of perf-list and
perf-record; Added documentation for perf-stat.
CC: Haren Myneni hb...@us.ibm.com
CC: Cody P Schafer d...@codyps.com
Signed-off-by: Cody P Schafer c...@linux.vnet.ibm.com
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
tools/perf/Documentation/perf-list.txt | 13 +
tools/perf/Documentation/perf-record.txt | 12
tools/perf/Documentation/perf-stat.txt | 20
3 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/tools/perf/Documentation/perf-list.txt
b/tools/perf/Documentation/perf-list.txt
index cbb4f74..d8be6fa 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -89,6 +89,19 @@ raw encoding of 0x1A8 can be used:
You should refer to the processor specific documentation for getting these
details. Some of them are referenced in the SEE ALSO section below.
+PARAMETERIZED EVENTS
+
+
+Some pmu events listed by 'perf-list' will be displayed with '$x' in them.
For
+example:
s/$x/?/
+
+ hv_gpci/dtbp_ptitc,phys_processor_idx=?/
+
+This means that when provided as an event, a value for '?' must
+also be supplied. For example:
+
+ perf stat -C 0 -e 'hv_gpci/dtbp_ptitc,phys_processor_idx=0x2/' ...
+
OPTIONS
---
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index af9a54e..acdcf3b 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -33,6 +33,18 @@ OPTIONS
- a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a
hexadecimal event descriptor.
SNIP
+
+ - a symbolically formed event like 'pmu/config=M,config1=N,config3=K/'
+
+ where M, N, K are numbers (in decimal, hex, octal format).
Acceptable
+ values for each of 'config', 'config1' and 'config2' are defined by
+ corresponding entries in
/sys/bus/event_sources/devices/pmu/format/*
+ param1 and param2 are defined as formats for the PMU in:
+ /sys/bus/event_sources/devices/pmu/format/*
misaligned tab
+
- a hardware breakpoint event in the form of '\mem:addr[:access]'
where addr is the address in memory you want to break in.
Access is the memory access type (read, write, execute) it can
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 29ee857..04e150d 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -25,10 +25,22 @@ OPTIONS
thanks,
jirka
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
On Sat, 2014-12-20 at 16:00 +0100, Rickard Strandqvist wrote: Remove the function ps3_repository_write_highmem_info() that is not used anywhere. NAK ps3_repository_write_highmem_info() is needed by otheros++. What we need is a kernel patch to add the highmem info to the repository once it is known. These ps3_repository_write_highmem routines are also the only documentation the freeBSD port has as to how the highmem info is (should be) saved in the repository. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
On 12/22/14 09:26, Geoff Levand wrote: On Sat, 2014-12-20 at 16:00 +0100, Rickard Strandqvist wrote: Remove the function ps3_repository_write_highmem_info() that is not used anywhere. NAK ps3_repository_write_highmem_info() is needed by otheros++. What we need is a kernel patch to add the highmem info to the repository once it is known. These ps3_repository_write_highmem routines are also the only documentation the freeBSD port has as to how the highmem info is (should be) saved in the repository. -Geoff Yes, we really need this for FreeBSD since that port uses the repository directly instead of FDT. Thanks for noticing this. We could adapt FreeBSD to use FDT (this is the only non-device-tree PowerPC port), but there hasn't been any reason to do that thus far given the availability of the repository information. -Nathan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull mpe/linux.git powerpc-3.19-2 tag
On Mon, 2014-12-22 at 15:33 +0100, Andreas Schwab wrote: Michael Ellerman m...@ellerman.id.au writes: Anton Blanchard (1): powerpc: Secondary CPUs must set cpu_callin_map after setting active and online This breaks booting on the PowerMac7,3. It takes forever to boot to user space (~5 minutes instead of ~4 seconds), and then I see these processes in top: 37 root 20 0 0 0 0 D 0.000 0.000 0:00.00 kwindfarm 10 root rt 0 0 0 0 R 0.000 0.000 0:00.00 migration/1 11 root 20 0 0 0 0 R 0.000 0.000 0:00.00 ksoftirqd/1 (The latter two processes don't accumulate any cpu time, but they are constantly in run state.) http://patchwork.ozlabs.org/patch/423315/ -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 1/4] tools/perf: support parsing parameterized events
Jiri Olsa [jo...@redhat.com] wrote:
| On Sun, Dec 21, 2014 at 11:49:24PM -0800, Sukadev Bhattiprolu wrote:
|
| SNIP
|
| + }
|
| switch (format-value) {
| case PERF_PMU_FORMAT_VALUE_CONFIG:
| @@ -592,11 +629,16 @@ static int pmu_config_term(struct list_head *formats,
| }
|
| /*
| -* XXX If we ever decide to go with string values for
| -* non-hardcoded terms, here's the place to translate
| -* them into value.
| +* Either directly use a numeric term, or try to translate string terms
| +* using event parameters.
| */
| - pmu_format_value(format-bits, term-val.num, vp, zero);
| + if (term-type_val == PARSE_EVENTS__TERM_TYPE_NUM)
| + val = term-val.num;
| + else
| + if (pmu_resolve_param_term(term, head_terms, val))
| + return -EINVAL;
| +
|
| I'm ok with the change logic, but I'm missing here check for the 'term'
| string value to be '?', so we force subst terms to have '?' as value..
| I believe thats what we decided in the previous set discussion, right?
The =? is not a user input, so I did not think of validating that.
perf tool expects kernel/sysfs to show entries like 'core=?'. Are you
saying that we should error out if kernel mistakenly displays 'core=$val'
or 'core=?val' ?
If a required parameter is missing, we catch that in pmu_resolve_param_term().
If a bogus parameter is specified we catch that above in pmu_config_term().
|
| I guess the it'd be nice to parse it directly in the bison code like
| below (could be done later), but I'd be ok with simple check on this
| place for now.
|
| thanks,
| jirka
|
|
| ---
| diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
| index 93c4c9fbc922..7e021c64d5cc 100644
| --- a/tools/perf/util/parse-events.y
| +++ b/tools/perf/util/parse-events.y
| @@ -484,6 +484,14 @@ PE_TERM '=' PE_VALUE
| $$ = term;
| }
| |
| +PE_TERM '=' PE_SUBST
| +{
| + struct parse_events_term *term;
| +
| + ABORT_ON(parse_events_term__subst(term, (int)$1, NULL, NULL));
| + $$ = term;
| +}
| +|
| PE_TERM
| {
| struct parse_events_term *term;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 3/4] perf Documentation: add event parameters
Jiri Olsa [jo...@redhat.com] wrote: | On Sun, Dec 21, 2014 at 11:49:26PM -0800, Sukadev Bhattiprolu wrote: | From: Cody P Schafer c...@linux.vnet.ibm.com | + In the case of the last example, a value replacing ? would | + need to be provided by the user selecting the particular event. | + This is referred to as event parameterization. All | + non-numerical values indicate an event parameter. | | I see.. here's the glitch ;-) I thought we agreed on forcing '?' | as the value for param events, not 'All non-numerical values' Yes, it is currently more broad than needed, but it is not really user input - we are just parsing sysfs entries that developer specified in the kernel. If necessary, we can tighten that independently ? | | thanks, | jirka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 4/4] tools/perf: Document parameterized and symbolic events
Jiri Olsa [jo...@redhat.com] wrote: | + values for each of 'config', 'config1' and 'config2' are defined by | + corresponding entries in /sys/bus/event_sources/devices/pmu/format/* | + param1 and param2 are defined as formats for the PMU in: | + /sys/bus/event_sources/devices/pmu/format/* | | misaligned tab Thanks, Fixed the typos and alignment below. --- From 1fdb5012081903172c11a41f9edb0d51525ba500 Mon Sep 17 00:00:00 2001 From: Cody P Schafer c...@linux.vnet.ibm.com Date: Wed, 24 Sep 2014 12:27:23 -0700 Subject: [PATCH v6 4/4] tools/perf: Document parameterized and symbolic events Changelog[v6]: - [Sukadev Bhattiprolu]: Update documentation of perf-list and perf-record; Added documentation for perf-stat. - [Jiri Olsa] Fix some typos/formatting CC: Haren Myneni hb...@us.ibm.com CC: Cody P Schafer d...@codyps.com Signed-off-by: Cody P Schafer c...@linux.vnet.ibm.com Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com --- tools/perf/Documentation/perf-list.txt | 13 + tools/perf/Documentation/perf-record.txt | 12 tools/perf/Documentation/perf-stat.txt | 20 3 files changed, 41 insertions(+), 4 deletions(-) diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt index cbb4f74..3e2aec9 100644 --- a/tools/perf/Documentation/perf-list.txt +++ b/tools/perf/Documentation/perf-list.txt @@ -89,6 +89,19 @@ raw encoding of 0x1A8 can be used: You should refer to the processor specific documentation for getting these details. Some of them are referenced in the SEE ALSO section below. +PARAMETERIZED EVENTS + + +Some pmu events listed by 'perf-list' will be displayed with '?' in them. For +example: + + hv_gpci/dtbp_ptitc,phys_processor_idx=?/ + +This means that when provided as an event, a value for '?' must +also be supplied. For example: + + perf stat -C 0 -e 'hv_gpci/dtbp_ptitc,phys_processor_idx=0x2/' ... + OPTIONS --- diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt index af9a54e..7d8df2e 100644 --- a/tools/perf/Documentation/perf-record.txt +++ b/tools/perf/Documentation/perf-record.txt @@ -33,6 +33,18 @@ OPTIONS - a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a hexadecimal event descriptor. + - a symbolically formed PMU event like 'pmu/param1=0x3,param2/' where + 'param1', 'param2', etc are defined as formats for the PMU in + /sys/bus/event_sources/devices/pmu/format/*. + + - a symbolically formed event like 'pmu/config=M,config1=N,config3=K/' + + where M, N, K are numbers (in decimal, hex, octal format). Acceptable + values for each of 'config', 'config1' and 'config2' are defined by + corresponding entries in /sys/bus/event_sources/devices/pmu/format/* + param1 and param2 are defined as formats for the PMU in: + /sys/bus/event_sources/devices/pmu/format/* + - a hardware breakpoint event in the form of '\mem:addr[:access]' where addr is the address in memory you want to break in. Access is the memory access type (read, write, execute) it can diff --git a/tools/perf/Documentation/perf-stat.txt b/tools/perf/Documentation/perf-stat.txt index 29ee857..04e150d 100644 --- a/tools/perf/Documentation/perf-stat.txt +++ b/tools/perf/Documentation/perf-stat.txt @@ -25,10 +25,22 @@ OPTIONS -e:: --event=:: - Select the PMU event. Selection can be a symbolic event name - (use 'perf list' to list all events) or a raw PMU - event (eventsel+umask) in the form of rNNN where NNN is a -hexadecimal event descriptor. + Select the PMU event. Selection can be: + + - a symbolic event name (use 'perf list' to list all events) + + - a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a + hexadecimal event descriptor. + + - a symbolically formed event like 'pmu/param1=0x3,param2/' where + param1 and param2 are defined as formats for the PMU in + /sys/bus/event_sources/devices/pmu/format/* + + - a symbolically formed event like 'pmu/config=M,config1=N,config2=K/' + where M, N, K are numbers (in decimal, hex, octal format). + Acceptable values for each of 'config', 'config1' and 'config2' + parameters are defined by corresponding entries in + /sys/bus/event_sources/devices/pmu/format/* -i:: --no-inherit:: -- 1.8.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
On Mon, 2014-12-22 at 05:08 -0600, Emil Medve wrote: Hello Scott, On 12/22/2014 03:42 AM, Scott Wood wrote: On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote: Hello Scott, On 12/22/2014 02:32 AM, Scott Wood wrote: On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote: For the purpose of an example in the binding document, I suggest we just stick with the IEEE standard frequency. The whole reason for this property existing in the device tree is non-standard frequencies. While the standard claims 2.5 MHz, most MDIO controllers and PHY devices support frequencies well beyond the standard. Specifying a lower then the standard frequency for the benefit of some errata is just one side of this property The erratum was (until now) the only claimed reason for it. If there are other reasons why one would specify a different frequency (in particular, that relate to hardware description), please elaborate. From memory, the 1 Gb/s Vitesse PHY(s) we have on some of our DS boards support 12.5 MHz. I can dig out more specs for specifics on other PHY(s) 2.5 MHz is slow and even more so for high speed interfaces. With both polling and interrupts (both MDIO and/or PHY) we've noticed (or blamed) in the past some Ethernet performance issues on this very slowness As of right now I'm not aware of another way to specify/coordinate the MDC speed so setting a default (common denominator) in the DT that is different then the IEEE standard seems ok We can continue this conversation about errata handling when we submit the code relevant to this binding (and the FMan v3 support) It affects the binding, so let's discuss it now please. I think this specific (unpublished yet) errata has less bearing on the binding then you might believe. This is mostly about providing a common/default frequency supported by all the devices on some board What reason other than an erratum would there be for the standard frequency not being supported? This is not about not supporting the standard frequency. This is about the default frequency being different then the standard OK, though rather than talk about defaults I'd phrase it as indicating that a higher frequency than standard is supported, or that a lower frequency than standard is required. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
2014-12-22 18:36 GMT+01:00 Nathan Whitehorn nwhiteh...@freebsd.org: On 12/22/14 09:26, Geoff Levand wrote: On Sat, 2014-12-20 at 16:00 +0100, Rickard Strandqvist wrote: Remove the function ps3_repository_write_highmem_info() that is not used anywhere. NAK ps3_repository_write_highmem_info() is needed by otheros++. What we need is a kernel patch to add the highmem info to the repository once it is known. These ps3_repository_write_highmem routines are also the only documentation the freeBSD port has as to how the highmem info is (should be) saved in the repository. -Geoff Yes, we really need this for FreeBSD since that port uses the repository directly instead of FDT. Thanks for noticing this. We could adapt FreeBSD to use FDT (this is the only non-device-tree PowerPC port), but there hasn't been any reason to do that thus far given the availability of the repository information. -Nathan Hi Too bad that did not have the benefit of the patch, but it looks like something good come because of it anyhow. Kind regards Rickard Strandqvist ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [TRIVIAL] IBM Akebono: Remove select of IBM_EMAC_RGMII_WOL
Hi Paul, These days I've been made maintainer of the PPC4XX tree so maybe adding Acked- by: Alistair Popple alist...@popple.id.au might help? Jiri, if you would rather this go via the main PPC tree please let us know and we'll see if Michael Ellerman (added to CC) would be willing to take it (he has taken over most of the day to day maintenance of the PPC tree). Thanks! Regards, Alistair On Mon, 22 Dec 2014 11:14:33 Paul Bolle wrote: Hi Jiri, On Mon, 2014-11-03 at 10:52 +0100, Paul Bolle wrote: Commit 2a2c74b2efcb (IBM Akebono: Add the Akebono platform) added a select of IBM_EMAC_RGMII_WOL. But that Kconfig symbol isn't (yet) part of the tree. So this select has been a nop since that commit was included in v3.16-rc1. The code to add this symbol is not included in next-20141103. So let's remove this select. It can be readded when that symbol is actually added to the tree. Signed-off-by: Paul Bolle pebo...@tiscali.nl Cc: Alistair Popple alist...@popple.id.au --- Untested. Done on top of next-20141103. Third time's a charm? First raised in https://lkml.org/lkml/2014/5/1/106 . Reminder sent in https://lkml.org/lkml/2014/9/4/645 . I'm not aware of any news on this front, so this trivial patch seems reasonable now. A patch to readd this select could be added - if people still care about it, that is - in the series that adds this symbol. A web search suggests Alistair takes care of that series, so Alistair gets a Cc: here. This select of IBM_EMAC_RGMII_WOL still shows up in next-20141221 and v3.19-rc1. Did you have a chance to look at this patch? arch/powerpc/platforms/44x/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig index d2ac1c116454..5538e57c36c1 100644 --- a/arch/powerpc/platforms/44x/Kconfig +++ b/arch/powerpc/platforms/44x/Kconfig @@ -214,7 +214,6 @@ config AKEBONO select ETHERNET select NET_VENDOR_IBM select IBM_EMAC_EMAC4 - select IBM_EMAC_RGMII_WOL select USB if USB_SUPPORT select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD Thanks, Paul Bolle ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
On Mon, 2014-12-22 at 09:26 -0800, Geoff Levand wrote: On Sat, 2014-12-20 at 16:00 +0100, Rickard Strandqvist wrote: Remove the function ps3_repository_write_highmem_info() that is not used anywhere. NAK ps3_repository_write_highmem_info() is needed by otheros++. What we need is a kernel patch to add the highmem info to the repository once it is known. OK so where's that patch? These ps3_repository_write_highmem routines are also the only documentation the freeBSD port has as to how the highmem info is (should be) saved in the repository. We don't carry dead code as documentation for BSD. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [TRIVIAL] IBM Akebono: Remove select of IBM_EMAC_RGMII_WOL
On Tue, 2014-12-23 at 09:48 +1100, Alistair Popple wrote: Hi Paul, These days I've been made maintainer of the PPC4XX tree so maybe adding Acked- by: Alistair Popple alist...@popple.id.au might help? Jiri, if you would rather this go via the main PPC tree please let us know and we'll see if Michael Ellerman (added to CC) would be willing to take it (he has taken over most of the day to day maintenance of the PPC tree). Thanks! It never went to linuxppc as far as I can see, though I am happy to take it. Although it is a trivial patch I'd still rather you CC'ed us on patches to arch/powerpc. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
On Mon, 2014-12-22 at 14:38 +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. Right. However, doesn't this introduce the possibility that the secondary cpu is up and marked online but has an unsynchronised clock? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
-Original Message- From: Michael Ellerman [mailto:m...@ellerman.id.au] Sent: Tuesday, December 23, 2014 9:01 AM To: Wang Dongsheng-B40534 Cc: b...@kernel.crashing.org; Wood Scott-B07421; an...@samba.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up. On Mon, 2014-12-22 at 14:38 +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. Right. However, doesn't this introduce the possibility that the secondary cpu is up and marked online but has an unsynchronised clock? Yes, right. But Freescale platform boot-cpu will freeze the TB until secondary cpu take the time base, so the clock is synchronized. For generic PowerPC maybe has this issue. So for safe I think we need to set cpu online after synchronized clock. I will update my patch if you agree this way. + if (smp_ops-take_timebase) + smp_ops-take_timebase(); + secondary_cpu_time_init(); + Move set_cpu_online to here. + set_cpu_online(cpu, true); Regards, -Dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
Hi Michael, On Tue, 2014-12-23 at 11:26 +1100, Michael Ellerman wrote: On Mon, 2014-12-22 at 09:26 -0800, Geoff Levand wrote: ps3_repository_write_highmem_info() is needed by otheros++. What we need is a kernel patch to add the highmem info to the repository once it is known. OK so where's that patch? I put one in my ps3-linux repo. I'll post it after I do some more testing. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
On Tue, 2014-12-23 at 02:41 +, dongsheng.w...@freescale.com wrote: -Original Message- From: Michael Ellerman [mailto:m...@ellerman.id.au] Sent: Tuesday, December 23, 2014 9:01 AM To: Wang Dongsheng-B40534 Cc: b...@kernel.crashing.org; Wood Scott-B07421; an...@samba.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up. On Mon, 2014-12-22 at 14:38 +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. Right. However, doesn't this introduce the possibility that the secondary cpu is up and marked online but has an unsynchronised clock? Yes, right. But Freescale platform boot-cpu will freeze the TB until secondary cpu take the time base, so the clock is synchronized. It does the freeze in give_timebase() doesn't it? So there's still a window there where the secondary is up online but hasn't had it's timebase synchronised, and the primary hasn't frozen the timebase yet. So that makes me nervous. For generic PowerPC maybe has this issue. So for safe I think we need to set cpu online after synchronized clock. I will update my patch if you agree this way. + if (smp_ops-take_timebase) + smp_ops-take_timebase(); + secondary_cpu_time_init(); + Move set_cpu_online to here. + set_cpu_online(cpu, true); But that reverses the effect of the original patch, which was that we have to set online *before* we set the callin map. Looking harder at Anton's patch I'm not sure it's right anyway. The issue he was trying to fix was that the cpu was online but not active, which confused the scheduler. I think Anton missed that we have a loop that waits for online at the bottom of __cpu_up(): /* Wait until cpu puts itself in the online map */ while (!cpu_online(cpu)) cpu_relax(); He must have seen a case where that popped due to the cpu being online, but the cpu wasn't yet active. His patch fixed the problem by ensuring the previous loop that waits for cpu_callin_map doesn't finish until active online are set, making the while loop above a nop. So I think we should probably revert Anton's patch and instead change that while loop to: /* Wait until cpu is online AND active */ while (!cpu_online(cpu) || !cpu_active(cpu)) cpu_relax(); cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
On Mon, 2014-12-22 at 18:44 -0800, Geoff Levand wrote: Hi Michael, On Tue, 2014-12-23 at 11:26 +1100, Michael Ellerman wrote: On Mon, 2014-12-22 at 09:26 -0800, Geoff Levand wrote: ps3_repository_write_highmem_info() is needed by otheros++. What we need is a kernel patch to add the highmem info to the repository once it is known. OK so where's that patch? I put one in my ps3-linux repo. I'll post it after I do some more testing. Great, thanks. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
-Original Message- From: Michael Ellerman [mailto:m...@ellerman.id.au] Sent: Tuesday, December 23, 2014 1:46 PM To: Wang Dongsheng-B40534 Cc: b...@kernel.crashing.org; Wood Scott-B07421; an...@samba.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up. On Tue, 2014-12-23 at 02:41 +, dongsheng.w...@freescale.com wrote: -Original Message- From: Michael Ellerman [mailto:m...@ellerman.id.au] Sent: Tuesday, December 23, 2014 9:01 AM To: Wang Dongsheng-B40534 Cc: b...@kernel.crashing.org; Wood Scott-B07421; an...@samba.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up. On Mon, 2014-12-22 at 14:38 +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. Right. However, doesn't this introduce the possibility that the secondary cpu is up and marked online but has an unsynchronised clock? Yes, right. But Freescale platform boot-cpu will freeze the TB until secondary cpu take the time base, so the clock is synchronized. It does the freeze in give_timebase() doesn't it? So there's still a window there where the secondary is up online but hasn't had it's timebase synchronised, and the primary hasn't frozen the timebase yet. So that makes me nervous. For generic PowerPC maybe has this issue. So for safe I think we need to set cpu online after synchronized clock. I will update my patch if you agree this way. + if (smp_ops-take_timebase) + smp_ops-take_timebase(); + secondary_cpu_time_init(); + Move set_cpu_online to here. + set_cpu_online(cpu, true); But that reverses the effect of the original patch, which was that we have to set online *before* we set the callin map. Looking harder at Anton's patch I'm not sure it's right anyway. The issue he was trying to fix was that the cpu was online but not active, which confused the scheduler. I think Anton missed that we have a loop that waits for online at the bottom of __cpu_up(): /* Wait until cpu puts itself in the online map */ while (!cpu_online(cpu)) cpu_relax(); He must have seen a case where that popped due to the cpu being online, but the cpu wasn't yet active. His patch fixed the problem by ensuring the previous loop that waits for cpu_callin_map doesn't finish until active online are set, making the while loop above a nop. So I think we should probably revert Anton's patch and instead change that while loop to: /* Wait until cpu is online AND active */ while (!cpu_online(cpu) || !cpu_active(cpu)) cpu_relax(); Umm.. Sorry about that...I forgot Anton's patch. But set_cpu_online also set cpu_active_bits, I think this judgment cannot fix Anton's issue. It is actually the effects of the original is the same. Regrads, -Dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/kvm: Create proper names for the kvm_host_state PMU fields
We have two arrays in kvm_host_state that contain register values for the PMU. Currently we only create an asm-offsets symbol for the base of the arrays, and do the array offset in the assembly code. Creating an asm-offsets symbol for each field individually makes the code much nicer to read, particularly for the MMCRx/SIxR/SDAR fields, and might have helped us notice the recent double restore bug we had in this code. Signed-off-by: Michael Ellerman m...@ellerman.id.au Acked-by: Alexander Graf ag...@suse.de --- arch/powerpc/kernel/asm-offsets.c | 15 +-- arch/powerpc/kvm/book3s_hv_interrupts.S | 26 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 28 ++-- 3 files changed, 40 insertions(+), 29 deletions(-) Looks like this fell through the cracks between the powerpc kvm trees. It needed a rework to go on top of the 970 HV removal, this is the result. I'll put it in the powerpc tree. cheers diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c index e624f9646350..4717859fdd04 100644 --- a/arch/powerpc/kernel/asm-offsets.c +++ b/arch/powerpc/kernel/asm-offsets.c @@ -644,8 +644,19 @@ int main(void) HSTATE_FIELD(HSTATE_SAVED_XIRR, saved_xirr); HSTATE_FIELD(HSTATE_HOST_IPI, host_ipi); HSTATE_FIELD(HSTATE_PTID, ptid); - HSTATE_FIELD(HSTATE_MMCR, host_mmcr); - HSTATE_FIELD(HSTATE_PMC, host_pmc); + HSTATE_FIELD(HSTATE_MMCR0, host_mmcr[0]); + HSTATE_FIELD(HSTATE_MMCR1, host_mmcr[1]); + HSTATE_FIELD(HSTATE_MMCRA, host_mmcr[2]); + HSTATE_FIELD(HSTATE_SIAR, host_mmcr[3]); + HSTATE_FIELD(HSTATE_SDAR, host_mmcr[4]); + HSTATE_FIELD(HSTATE_MMCR2, host_mmcr[5]); + HSTATE_FIELD(HSTATE_SIER, host_mmcr[6]); + HSTATE_FIELD(HSTATE_PMC1, host_pmc[0]); + HSTATE_FIELD(HSTATE_PMC2, host_pmc[1]); + HSTATE_FIELD(HSTATE_PMC3, host_pmc[2]); + HSTATE_FIELD(HSTATE_PMC4, host_pmc[3]); + HSTATE_FIELD(HSTATE_PMC5, host_pmc[4]); + HSTATE_FIELD(HSTATE_PMC6, host_pmc[5]); HSTATE_FIELD(HSTATE_PURR, host_purr); HSTATE_FIELD(HSTATE_SPURR, host_spurr); HSTATE_FIELD(HSTATE_DSCR, host_dscr); diff --git a/arch/powerpc/kvm/book3s_hv_interrupts.S b/arch/powerpc/kvm/book3s_hv_interrupts.S index 36540a99d178..0fdc4a28970b 100644 --- a/arch/powerpc/kvm/book3s_hv_interrupts.S +++ b/arch/powerpc/kvm/book3s_hv_interrupts.S @@ -93,15 +93,15 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S) mfspr r5, SPRN_MMCR1 mfspr r9, SPRN_SIAR mfspr r10, SPRN_SDAR - std r7, HSTATE_MMCR(r13) - std r5, HSTATE_MMCR + 8(r13) - std r6, HSTATE_MMCR + 16(r13) - std r9, HSTATE_MMCR + 24(r13) - std r10, HSTATE_MMCR + 32(r13) + std r7, HSTATE_MMCR0(r13) + std r5, HSTATE_MMCR1(r13) + std r6, HSTATE_MMCRA(r13) + std r9, HSTATE_SIAR(r13) + std r10, HSTATE_SDAR(r13) BEGIN_FTR_SECTION mfspr r9, SPRN_SIER - std r8, HSTATE_MMCR + 40(r13) - std r9, HSTATE_MMCR + 48(r13) + std r8, HSTATE_MMCR2(r13) + std r9, HSTATE_SIER(r13) END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S) mfspr r3, SPRN_PMC1 mfspr r5, SPRN_PMC2 @@ -109,12 +109,12 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S) mfspr r7, SPRN_PMC4 mfspr r8, SPRN_PMC5 mfspr r9, SPRN_PMC6 - stw r3, HSTATE_PMC(r13) - stw r5, HSTATE_PMC + 4(r13) - stw r6, HSTATE_PMC + 8(r13) - stw r7, HSTATE_PMC + 12(r13) - stw r8, HSTATE_PMC + 16(r13) - stw r9, HSTATE_PMC + 20(r13) + stw r3, HSTATE_PMC1(r13) + stw r5, HSTATE_PMC2(r13) + stw r6, HSTATE_PMC3(r13) + stw r7, HSTATE_PMC4(r13) + stw r8, HSTATE_PMC5(r13) + stw r9, HSTATE_PMC6(r13) 31: /* diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S index 10554df13852..bb94e6f20c81 100644 --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S @@ -83,35 +83,35 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S) cmpwi r4, 0 beq 23f /* skip if not */ BEGIN_FTR_SECTION - ld r3, HSTATE_MMCR(r13) + ld r3, HSTATE_MMCR0(r13) andi. r4, r3, MMCR0_PMAO_SYNC | MMCR0_PMAO cmpwi r4, MMCR0_PMAO beqlkvmppc_fix_pmao END_FTR_SECTION_IFSET(CPU_FTR_PMAO_BUG) - lwz r3, HSTATE_PMC(r13) - lwz r4, HSTATE_PMC + 4(r13) - lwz r5, HSTATE_PMC + 8(r13) - lwz r6, HSTATE_PMC + 12(r13) - lwz r8, HSTATE_PMC + 16(r13) - lwz r9, HSTATE_PMC + 20(r13) + lwz r3, HSTATE_PMC1(r13) + lwz r4, HSTATE_PMC2(r13) + lwz r5, HSTATE_PMC3(r13) + lwz r6, HSTATE_PMC4(r13) + lwz r8, HSTATE_PMC5(r13) + lwz
RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
Best Regards, Shaohui Xie -Original Message- From: Wood Scott-B07421 Sent: Tuesday, December 23, 2014 5:26 AM To: Medve Emilian-EMMEDVE1 Cc: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Liberman Igal-B31950 Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan On Mon, 2014-12-22 at 05:08 -0600, Emil Medve wrote: Hello Scott, On 12/22/2014 03:42 AM, Scott Wood wrote: On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote: Hello Scott, On 12/22/2014 02:32 AM, Scott Wood wrote: On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote: For the purpose of an example in the binding document, I suggest we just stick with the IEEE standard frequency. The whole reason for this property existing in the device tree is non-standard frequencies. While the standard claims 2.5 MHz, most MDIO controllers and PHY devices support frequencies well beyond the standard. Specifying a lower then the standard frequency for the benefit of some errata is just one side of this property The erratum was (until now) the only claimed reason for it. If there are other reasons why one would specify a different frequency (in particular, that relate to hardware description), please elaborate. From memory, the 1 Gb/s Vitesse PHY(s) we have on some of our DS boards support 12.5 MHz. I can dig out more specs for specifics on other PHY(s) 2.5 MHz is slow and even more so for high speed interfaces. With both polling and interrupts (both MDIO and/or PHY) we've noticed (or blamed) in the past some Ethernet performance issues on this very slowness As of right now I'm not aware of another way to specify/coordinate the MDC speed so setting a default (common denominator) in the DT that is different then the IEEE standard seems ok We can continue this conversation about errata handling when we submit the code relevant to this binding (and the FMan v3 support) It affects the binding, so let's discuss it now please. I think this specific (unpublished yet) errata has less bearing on the binding then you might believe. This is mostly about providing a common/default frequency supported by all the devices on some board What reason other than an erratum would there be for the standard frequency not being supported? This is not about not supporting the standard frequency. This is about the default frequency being different then the standard OK, though rather than talk about defaults I'd phrase it as indicating that a higher frequency than standard is supported, or that a lower frequency than standard is required. [S.H] below is the statement in v2: +- bus-frequency + Usage: optional + Value type: u32 + Definition: Specifies external MDIO bus clock speed which is + different from MDIO standard 2.5MHz. Should be defined for SoCs + on which the standard one cannot work. What should I rephrase it? Replace the last sentence with Should be defined For SoCs on which a lower frequency than the standard is required.? How about the value used in example? Should 2.5MHz be used or a lower one? Thanks! Shaohui ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, December 23, 2014 2:53 PM
To: 'Michael Ellerman'
Cc: b...@kernel.crashing.org; Wood Scott-B07421; an...@samba.org; linuxppc-
d...@lists.ozlabs.org
Subject: RE: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
-Original Message-
From: Michael Ellerman [mailto:m...@ellerman.id.au]
Sent: Tuesday, December 23, 2014 1:46 PM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; Wood Scott-B07421; an...@samba.org;
linuxppc- d...@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
On Tue, 2014-12-23 at 02:41 +, dongsheng.w...@freescale.com wrote:
-Original Message-
From: Michael Ellerman [mailto:m...@ellerman.id.au]
Sent: Tuesday, December 23, 2014 9:01 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; Wood Scott-B07421; an...@samba.org;
linuxppc- d...@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
On Mon, 2014-12-22 at 14:38 +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.
Right.
However, doesn't this introduce the possibility that the secondary
cpu is up and marked online but has an unsynchronised clock?
Yes, right. But Freescale platform boot-cpu will freeze the TB until
secondary cpu take the time base, so the clock is synchronized.
It does the freeze in give_timebase() doesn't it?
So there's still a window there where the secondary is up online but
hasn't had it's timebase synchronised, and the primary hasn't frozen the
timebase yet.
So that makes me nervous.
For generic PowerPC maybe has this issue. So for safe I think we
need to set cpu online after synchronized clock.
I will update my patch if you agree this way.
+ if (smp_ops-take_timebase)
+ smp_ops-take_timebase();
+ secondary_cpu_time_init();
+
Move set_cpu_online to here.
+ set_cpu_online(cpu, true);
But that reverses the effect of the original patch, which was that we
have to set online *before* we set the callin map.
Looking harder at Anton's patch I'm not sure it's right anyway.
The issue he was trying to fix was that the cpu was online but not
active, which confused the scheduler.
I think Anton missed that we have a loop that waits for online at the
bottom of
__cpu_up():
/* Wait until cpu puts itself in the online map */
while (!cpu_online(cpu))
cpu_relax();
He must have seen a case where that popped due to the cpu being
online, but the cpu wasn't yet active.
His patch fixed the problem by ensuring the previous loop that waits
for cpu_callin_map doesn't finish until active online are set,
making the while loop above a nop.
So I think we should probably revert Anton's patch and instead change
that while loop to:
/* Wait until cpu is online AND active */
while (!cpu_online(cpu) || !cpu_active(cpu))
cpu_relax();
Base on Anton's patch, we should probably change __cup_up.
Please comment the changes.
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -528,12 +528,10 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
}
/*
-* wait to see if the cpu made a callin (is actually up).
-* use this value that I found through experimentation.
-* -- Cort
+* Wait until cpu puts itself in the online map
*/
if (system_state SYSTEM_RUNNING)
- for (c = 5; c !cpu_callin_map[cpu]; c--)
+ for (c = 5; c !cpu_online(cpu); c--)
udelay(100);
#ifdef CONFIG_HOTPLUG_CPU
else
@@ -541,11 +539,10 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
* CPUs can take much longer to come up in the
* hotplug case. Wait five seconds.
*/
- for (c = 5000; c !cpu_callin_map[cpu]; c--)
+ for (c = 5000; c !cpu_online(cpu); c--)
msleep(1);
#endif
-
- if (!cpu_callin_map[cpu]) {
+ if (!cpu_online(cpu)) {
printk(KERN_ERR Processor %u is stuck.\n, cpu);
return -ENOENT;
}
@@ -555,8 +552,8 @@ int __cpu_up(unsigned int
Ask help about killing irqchip.irq_print_chip on PPC platforms
Hi Scott and Tudor, Sorry, resend and Ccing the list. We are trying to clean up some irqchip interfaces, and irqchip.irq_print_chip is a candidate for removal. After some changes on x86 side, arch/powerpc/sysdev/fsl_msi.c may be the last user of irqchip.irq_print_chip. So could you please help to advice on whether we could kill irqchip.irq_print_chip by using fsl-msi instead of fsl-msi-%d for irqchip name? Will it break any userspace interfaces? Thanks! Gerry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Ask help about killing irqchip.irq_print_chip on PPC platforms
On Tue, 2014-12-23 at 15:56 +0800, Jiang Liu wrote: Hi Scott and Tudor, Sorry, resend and Ccing the list. Resending reply... We are trying to clean up some irqchip interfaces, and irqchip.irq_print_chip is a candidate for removal. After some changes on x86 side, arch/powerpc/sysdev/fsl_msi.c may be the last user of irqchip.irq_print_chip. So could you please help to advice on whether we could kill irqchip.irq_print_chip by using fsl-msi instead of fsl-msi-%d for irqchip name? Will it break any userspace interfaces? Thanks! Gerry fsl-msi-%d was introduced to allow userspace to identify the cascade interrupt belonging to a particular MSI, for the purpose of setting affinity, as this cannot be done on the MSI itself due to hardware limitations. Removing it would not exactly eliminate a lot of code or complexity... -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
