* Re: [PATCH v2 2/3] powerpc: document the Open PIC device tree binding
From: Meador Inge @ 2011-02-03 16:29 UTC (permalink / raw)
To: Grant Likely; +Cc: Hollis Blanchard, devicetree-discuss, linuxppc-dev
In-Reply-To: <AANLkTinVak_ukf0wP8=zbGTq8ENV4d88hNuzW_tqvCFf@mail.gmail.com>
On 02/03/2011 09:56 AM, Grant Likely wrote:
> On Wed, Feb 2, 2011 at 6:51 PM, Meador Inge<meador_inge@mentor.com> wrote:
>> This binding documents several properties that have been in use for quite
>> some time, and adds one new property 'no-reset', which controls whether the
>> Open PIC should be reset during runtime initialization.
>>
>> The general formatting and interrupt specifier definition is based off of
>> Stuart Yoder's FSL MPIC binding.
>>
>> Signed-off-by: Meador Inge<meador_inge@mentor.com>
>> CC: Hollis Blanchard<hollis_blanchard@mentor.com>
>> CC: Stuart Yoder<stuart.yoder@freescale.com>
>> ---
>> Documentation/powerpc/dts-bindings/open-pic.txt | 115 +++++++++++++++++++++++
>> 1 files changed, 115 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/powerpc/dts-bindings/open-pic.txt
>>
>> diff --git a/Documentation/powerpc/dts-bindings/open-pic.txt b/Documentation/powerpc/dts-bindings/open-pic.txt
>> new file mode 100644
>> index 0000000..447ef65
>> --- /dev/null
>> +++ b/Documentation/powerpc/dts-bindings/open-pic.txt
>> @@ -0,0 +1,115 @@
>> +* Open PIC Binding
>> +
>> +This binding specifies what properties must be available in the device tree
>> +representation of an Open PIC compliant interrupt controller. This binding is
>> +based on the binding defined for Open PIC in [1] and is a superset of that
>> +binding.
>> +
>> +PROPERTIES
>> +
>> + NOTE: Many of these descriptions were paraphrased here from [1] to aid
>> + readability.
>> +
>> + - compatible
>> + Usage: required
>> + Value type:<string>
>> + Definition: Specifies the compatibility list for the PIC. The
>> + property value shall include "open-pic".
>> +
>> + - reg
>> + Usage: required
>> + Value type:<prop-encoded-array>
>> + Definition: Specifies the base physical address(s) and size(s) of this
>> + PIC's addressable register space.
>> +
>> + - interrupt-controller
>> + Usage: required
>> + Value type:<empty>
>> + Definition: The presence of this property identifies the node
>> + as an Open PIC. No property value should be defined.
>> +
>> + - #interrupt-cells
>> + Usage: required
>> + Value type:<u32>
>> + Definition: Specifies the number of cells needed to encode an
>> + interrupt source. Shall be 2.
>> +
>> + - #address-cells
>> + Usage: required
>> + Value type:<u32>
>> + Definition: Specifies the number of cells needed to encode an
>> + address. The value of this property shall always be 0.
>> + As such, 'interrupt-map' nodes do not have to specify a
>> + parent unit address.
>> +
>> + - no-reset
>> + Usage: optional
>> + Value type:<empty>
>> + Definition: The presence of this property indicates that the PIC
>> + should not be reset during runtime initialization. The presence of
>> + this property also mandates that any initialization related to
>> + interrupt sources shall be limited to sources explicitly referenced
>> + in the device tree.
>
> Please follow the lead set by the other binding documentation which is
> more concise and tends to be of the form:
>
> Required properties:
> - reg :<description>
> - interrupt-controller :<description>
>
> Optional Properties:
> - no-reset : blah
OK, will do. The one thing that I like about the other format, though,
is that it specifies the value type. That is a useful addition.
> I'm considering formalizing the binding format so that fully specified
> and cross-referenced documentation can be generated from the bindings
> directory.
Formalizing the binding format would be great. Perhaps we should add a
HOWTO write a new binding document to the "Documentation" directory?
The would be a great place to capture some of the common pitfalls that
have been coming up on the list lately (versioned compatibility tags,
for example).
> Also, to avoid the potential of a future namespace collision, it would
> not be a bad idea to name this openpic-no-reset or something that
> makes it clear that this is a binding specific property. "no-reset"
> sounds generic enough to give me pause.
Isn't that a little redundant, though (e.g.
"/soc/pic/openpic-no-reset")? It is already scoped to the PIC node:
mpic: pic@40000 {
compatible = "open-pic";
no-reset;
};
Or are you worried that someone will find the wrong "no-reset" property
when searching from a location higher in the tree than the PIC node?
I don't have a serious objection to the idea, but it seems slightly odd
to partially flatten the hierarchy back into the property names. On the
other hand, I do see the practical consideration of having a more unique
property which might prevent programming confusion/errors.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [PATCH v2 2/3] powerpc: document the Open PIC device tree binding
From: Grant Likely @ 2011-02-03 15:56 UTC (permalink / raw)
To: Meador Inge; +Cc: Hollis Blanchard, devicetree-discuss, linuxppc-dev
In-Reply-To: <1296697900-14004-3-git-send-email-meador_inge@mentor.com>
On Wed, Feb 2, 2011 at 6:51 PM, Meador Inge <meador_inge@mentor.com> wrote:
> This binding documents several properties that have been in use for quite
> some time, and adds one new property 'no-reset', which controls whether t=
he
> Open PIC should be reset during runtime initialization.
>
> The general formatting and interrupt specifier definition is based off of
> Stuart Yoder's FSL MPIC binding.
>
> Signed-off-by: Meador Inge <meador_inge@mentor.com>
> CC: Hollis Blanchard <hollis_blanchard@mentor.com>
> CC: Stuart Yoder <stuart.yoder@freescale.com>
> ---
> =A0Documentation/powerpc/dts-bindings/open-pic.txt | =A0115 +++++++++++++=
++++++++++
> =A01 files changed, 115 insertions(+), 0 deletions(-)
> =A0create mode 100644 Documentation/powerpc/dts-bindings/open-pic.txt
>
> diff --git a/Documentation/powerpc/dts-bindings/open-pic.txt b/Documentat=
ion/powerpc/dts-bindings/open-pic.txt
> new file mode 100644
> index 0000000..447ef65
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/open-pic.txt
> @@ -0,0 +1,115 @@
> +* Open PIC Binding
> +
> +This binding specifies what properties must be available in the device t=
ree
> +representation of an Open PIC compliant interrupt controller. =A0This bi=
nding is
> +based on the binding defined for Open PIC in [1] and is a superset of th=
at
> +binding.
> +
> +PROPERTIES
> +
> + =A0NOTE: Many of these descriptions were paraphrased here from [1] to a=
id
> + =A0 =A0 =A0 =A0readability.
> +
> + =A0- compatible
> + =A0 =A0 =A0Usage: required
> + =A0 =A0 =A0Value type: <string>
> + =A0 =A0 =A0Definition: Specifies the compatibility list for the PIC. =
=A0The
> + =A0 =A0 =A0 =A0 =A0property value shall include "open-pic".
> +
> + =A0- reg
> + =A0 =A0 =A0Usage: required
> + =A0 =A0 =A0Value type: <prop-encoded-array>
> + =A0 =A0 =A0Definition: Specifies the base physical address(s) and size(=
s) of this
> + =A0 =A0 =A0 =A0 =A0PIC's addressable register space.
> +
> + =A0- interrupt-controller
> + =A0 =A0 =A0Usage: required
> + =A0 =A0 =A0Value type: <empty>
> + =A0 =A0 =A0Definition: The presence of this property identifies the nod=
e
> + =A0 =A0 =A0 =A0 =A0as an Open PIC. =A0No property value should be defin=
ed.
> +
> + =A0- #interrupt-cells
> + =A0 =A0 =A0Usage: required
> + =A0 =A0 =A0Value type: <u32>
> + =A0 =A0 =A0Definition: Specifies the number of cells needed to encode a=
n
> + =A0 =A0 =A0 =A0 =A0interrupt source. =A0Shall be 2.
> +
> + =A0- #address-cells
> + =A0 =A0 =A0Usage: required
> + =A0 =A0 =A0Value type: <u32>
> + =A0 =A0 =A0Definition: Specifies the number of cells needed to encode a=
n
> + =A0 =A0 =A0 =A0 =A0address. =A0The value of this property shall always =
be 0.
> + =A0 =A0 =A0 =A0 =A0As such, 'interrupt-map' nodes do not have to specif=
y a
> + =A0 =A0 =A0 =A0 =A0parent unit address.
> +
> + =A0- no-reset
> + =A0 =A0 =A0Usage: optional
> + =A0 =A0 =A0Value type: <empty>
> + =A0 =A0 =A0Definition: The presence of this property indicates that the=
PIC
> + =A0 =A0 =A0 =A0 =A0should not be reset during runtime initialization. =
=A0The presence of
> + =A0 =A0 =A0 =A0 =A0this property also mandates that any initialization =
related to
> + =A0 =A0 =A0 =A0 =A0interrupt sources shall be limited to sources explic=
itly referenced
> + =A0 =A0 =A0 =A0 =A0in the device tree.
Please follow the lead set by the other binding documentation which is
more concise and tends to be of the form:
Required properties:
- reg : <description>
- interrupt-controller : <description>
Optional Properties:
- no-reset : blah
I'm considering formalizing the binding format so that fully specified
and cross-referenced documentation can be generated from the bindings
directory.
Also, to avoid the potential of a future namespace collision, it would
not be a bad idea to name this openpic-no-reset or something that
makes it clear that this is a binding specific property. "no-reset"
sounds generic enough to give me pause.
> +
> +INTERRUPT SPECIFIER DEFINITION
> +
> + =A0Interrupt specifiers consists of 2 cells encoded as
> + =A0follows:
> +
> + =A0 <1st-cell> =A0 interrupt-number
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Identifies the interrupt source.
> +
> + =A0 <2nd-cell> =A0 level-sense information, encoded as follows:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00 =3D low-to-high edge triggered
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01 =3D active low level-sensitive
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02 =3D active high level-sensitiv=
e
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03 =3D high-to-low edge triggered
> +
> +EXAMPLE 1
> +
> + =A0 =A0/*
> + =A0 =A0 * An Open PIC interrupt controller
> + =A0 =A0 */
> + =A0 =A0 =A0 mpic: pic@40000 {
> + =A0 =A0 =A0 =A0// This is an interrupt controller node.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-controller;
> +
> + =A0 =A0 =A0 =A0// No address cells so that 'interrupt-map' nodes which =
reference
> + =A0 =A0 =A0 =A0// this Open PIC node do not need a parent address speci=
fier.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <0>;
> +
> + =A0 =A0 =A0 =A0// Two cells to encode interrupt sources.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #interrupt-cells =3D <2>;
> +
> + =A0 =A0 =A0 =A0// Offset address of 0x40000 and size of 0x40000.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0x40000 0x40000>;
> +
> + =A0 =A0 =A0 =A0// Compatible with Open PIC.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "open-pic";
> +
> + =A0 =A0 =A0 =A0// The PIC should not be reset.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 no-reset;
> + =A0 =A0 =A0 };
> +
> +EXAMPLE 2
> +
> + =A0 =A0/*
> + =A0 =A0 * An interrupt generating device that is wired to an Open PIC.
> + =A0 =A0 */
> + =A0 =A0serial0: serial@4500 {
> + =A0 =A0 =A0 =A0// Interrupt source '42' that is active high level-sensi=
tive.
> + =A0 =A0 =A0 =A0// Note that there are only two cells as specified in th=
e interrupt
> + =A0 =A0 =A0 =A0// parent's '#interrupt-cells' property.
> + =A0 =A0 =A0 =A0interrupts =3D <42 2>;
> +
> + =A0 =A0 =A0 =A0// The interrupt controller that this device is wired to=
.
> + =A0 =A0 =A0 =A0interrupt-parent =3D <&mpic>;
> + =A0 =A0};
> +
> +REFERENCES
> +
> +[1] Power.org (TM) Standard for Embedded Power Architecture (TM) Platfor=
m
> + =A0 =A0Requirements (ePAPR), Version 1.0, July 2008.
> + =A0 =A0(http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v=
1.0.pdf)
> +
> --
> 1.6.3.3
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2 1/3] powerpc: Removing support for 'protected-sources'
From: Arnd Bergmann @ 2011-02-03 15:56 UTC (permalink / raw)
To: devicetree-discuss; +Cc: Meador Inge, Hollis Blanchard, linuxppc-dev
In-Reply-To: <1296697900-14004-2-git-send-email-meador_inge@mentor.com>
On Thursday 03 February 2011, Meador Inge wrote:
> In a recent discussion [1, 2] concerning device trees for AMP systems, the
> question of whether we really need 'protected-sources' arose. The general
> consensus was that if you don't want a source to be used, then it should *not*
> be mentioned in an 'interrupts' property. If a source really needs to be
> mentioned, then it should be put in a property other than 'interrupts' with
> a specific binding for that use case.
>
> [1] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/004038.html
> [2] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/003991.html
That doesn't work in the case that this code was written for:
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg01394.html
The problem is that you don't want the mpic to initialize the interrupt
line to the default, but instead leave it at whatever the boot firmware
has set up. Note that interrupt is not listed in any "interrupts"
property of any of the devices on the CPU interpreting the device
tree, but it may be mentioned in the device tree that another CPU
uses to access the same MPIC.
Arnd
^ permalink raw reply
* Re: [PATCH v2 0/3] powerpc: Open PIC binding and 'no-reset' implementation
From: Kumar Gala @ 2011-02-03 15:22 UTC (permalink / raw)
To: Meador Inge; +Cc: Hollis Blanchard, devicetree-discuss, linuxppc-dev
In-Reply-To: <1296697900-14004-1-git-send-email-meador_inge@mentor.com>
On Feb 2, 2011, at 7:51 PM, Meador Inge wrote:
> This patch set provides a binding for Open PIC and implements support =
for
> a new property, specified by that binding, called 'no-reset'. With =
'no-reset'
> in place the 'protected-sources' property is no longer needed and was =
removed.
>=20
> Signed-off-by: Meador Inge <meador_inge@mentor.com>
> CC: Hollis Blanchard <hollis_blanchard@mentor.com>
>=20
> Meador Inge (3):
> powerpc: Removing support for 'protected-sources'
> powerpc: document the Open PIC device tree binding
> powerpc: make MPIC honor the 'no-reset' device tree property
>=20
> Documentation/powerpc/dts-bindings/open-pic.txt | 115 =
+++++++++++++++++++++++
> arch/powerpc/include/asm/mpic.h | 7 +-
> arch/powerpc/sysdev/mpic.c | 92 =
++++++++----------
> 3 files changed, 160 insertions(+), 54 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/open-pic.txt
>=20
Please cleanup all the .dts that are impacted by this.
- k
^ permalink raw reply
* Re: [PATCH V2 4/6] powerpc/44x: don't use tlbivax on AMP systems
From: David Gibson @ 2011-02-03 5:03 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linuxppc-dev
In-Reply-To: <1296690839.12290.108.camel@shaggy-w500>
On Wed, Feb 02, 2011 at 05:53:59PM -0600, Dave Kleikamp wrote:
> On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
> > On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> > > Since other OS's may be running on the other cores don't use tlbivax
> >
> > [snip]
> > > +#ifdef CONFIG_44x
> > > +void __init early_init_mmu_44x(void)
> > > +{
> > > + unsigned long root = of_get_flat_dt_root();
> > > + if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))
> > > + amp = 1;
> > > +}
> > > +#endif /* CONFIG_44x */
> >
> > A test against a hardcoded compatible string seems a nasty way to do
> > this. Maybe we should define a new boolean property for the root
> > node.
>
> I'm not crazy about this string, but I needed something in the device
> tree to key off of. Freescale has something similar (i.e.
> MPC8572DS-CAMP), so I chose to follow their example. I'd be happy to
> replace it with a boolean property. Any objection to just using
> "amp"?
Bit too short, I think. I'd suggest either spelling out
'asymmetric-multiprocessor' or 'cooperative-partition' (a more
accurate term, IMO).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 6/6] ftrace syscalls: Early terminate search for sys_ni_syscall
From: Ian Munsie @ 2011-02-03 3:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andreas Dilger, Andreas Schwab, Dave Kleikamp, Namhyung Kim,
Jiri Kosina, Jason Baron, Alexander Graf, Steven Rostedt,
David Gibson, Ingo Molnar, Paul Mackerras, Ian Munsie,
KOSAKI Motohiro, Frederic Weisbecker, Scott Wood, Nathan Lynch,
Andrew Morton, linuxppc-dev, Avantika Mathur
In-Reply-To: <1296703645-18718-1-git-send-email-imunsie@au1.ibm.com>
From: Ian Munsie <imunsie@au1.ibm.com>
Many system calls are unimplemented and mapped to sys_ni_syscall, but at
boot ftrace would still search through every syscall metadata entry for
a match which wouldn't be there.
This patch adds causes the search to terminate early if the system call
is not mapped.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
kernel/trace/trace_syscalls.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 7b76a65..f498154 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -84,6 +84,9 @@ static struct syscall_metadata *find_syscall_meta(unsigned long syscall)
stop = (struct syscall_metadata *)__stop_syscalls_metadata;
kallsyms_lookup(syscall, NULL, NULL, NULL, str);
+ if (arch_syscall_match_sym_name(str, "sys_ni_syscall"))
+ return NULL;
+
for ( ; start < stop; start++) {
if (start->name && arch_syscall_match_sym_name(str, start->name))
return start;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 5/6] ftrace, powerpc: Implement raw syscall tracepoints on PowerPC
From: Ian Munsie @ 2011-02-03 3:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andreas Dilger, Andreas Schwab, Dave Kleikamp, Namhyung Kim,
Jiri Kosina, Jason Baron, Alexander Graf, Steven Rostedt,
David Gibson, Ingo Molnar, Paul Mackerras, Ian Munsie,
KOSAKI Motohiro, Frederic Weisbecker, Scott Wood, Nathan Lynch,
Andrew Morton, linuxppc-dev, Avantika Mathur
In-Reply-To: <1296703645-18718-1-git-send-email-imunsie@au1.ibm.com>
From: Ian Munsie <imunsie@au.ibm.com>
This patch implements the raw syscall tracepoints on PowerPC and exports
them for ftrace syscalls to use.
To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within the 16 bits of the andi. instruction's UI field. The instructions
in question are in /arch/powerpc/kernel/entry_{32,64}.S to and the
_TIF_SYSCALL_T_OR_A with the thread flags to see if system call tracing
is enabled.
In the case of 64bit PowerPC, arch_syscall_addr and
arch_syscall_match_sym_name are overridden to allow ftrace syscalls to
work given the unusual system call table structure and symbol names that
start with a period.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/ftrace.h | 14 ++++++++++++++
arch/powerpc/include/asm/syscall.h | 5 +++++
arch/powerpc/include/asm/thread_info.h | 7 +++++--
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/ftrace.c | 8 ++++++++
arch/powerpc/kernel/ptrace.c | 10 ++++++++++
7 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 7d69e9b..a0e8e02 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -134,6 +134,7 @@ config PPC
select HAVE_GENERIC_HARDIRQS
select HAVE_SPARSE_IRQ
select IRQ_PER_CPU
+ select HAVE_SYSCALL_TRACEPOINTS
config EARLY_PRINTK
bool
diff --git a/arch/powerpc/include/asm/ftrace.h b/arch/powerpc/include/asm/ftrace.h
index dde1296..169d039 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -60,4 +60,18 @@ struct dyn_arch_ftrace {
#endif
+#if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_PPC64) && !defined(__ASSEMBLY__)
+#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+static inline bool arch_syscall_match_sym_name(const char *sym, const char *name)
+{
+ /*
+ * Compare the symbol name with the system call name. Skip the .sys or .SyS
+ * prefix from the symbol name and the sys prefix from the system call name and
+ * just match the rest. This is only needed on ppc64 since symbol names on
+ * 32bit do not start with a period so the generic function will work.
+ */
+ return !strcmp(sym + 4, name + 3);
+}
+#endif /* CONFIG_FTRACE_SYSCALLS && CONFIG_PPC64 && !__ASSEMBLY__ */
+
#endif /* _ASM_POWERPC_FTRACE */
diff --git a/arch/powerpc/include/asm/syscall.h b/arch/powerpc/include/asm/syscall.h
index 23913e9..b54b2ad 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
@@ -15,6 +15,11 @@
#include <linux/sched.h>
+/* ftrace syscalls requires exporting the sys_call_table */
+#ifdef CONFIG_FTRACE_SYSCALLS
+extern const unsigned long *sys_call_table;
+#endif /* CONFIG_FTRACE_SYSCALLS */
+
static inline long syscall_get_nr(struct task_struct *task,
struct pt_regs *regs)
{
diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
index 65eb859..4403f09 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -110,7 +110,8 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_NOERROR 12 /* Force successful syscall return */
#define TIF_NOTIFY_RESUME 13 /* callback before returning to user */
#define TIF_FREEZE 14 /* Freezing for suspend */
-#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */
+#define TIF_SYSCALL_TRACEPOINT 15 /* syscall tracepoint instrumentation */
+#define TIF_RUNLATCH 16 /* Is the runlatch enabled? */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
@@ -127,8 +128,10 @@ static inline struct thread_info *current_thread_info(void)
#define _TIF_NOERROR (1<<TIF_NOERROR)
#define _TIF_NOTIFY_RESUME (1<<TIF_NOTIFY_RESUME)
#define _TIF_FREEZE (1<<TIF_FREEZE)
+#define _TIF_SYSCALL_TRACEPOINT (1<<TIF_SYSCALL_TRACEPOINT)
#define _TIF_RUNLATCH (1<<TIF_RUNLATCH)
-#define _TIF_SYSCALL_T_OR_A (_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP)
+#define _TIF_SYSCALL_T_OR_A (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
+ _TIF_SECCOMP | _TIF_SYSCALL_TRACEPOINT)
#define _TIF_USER_WORK_MASK (_TIF_SIGPENDING | _TIF_NEED_RESCHED | \
_TIF_NOTIFY_RESUME)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 3bb2a3e..fe1ac47 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -105,6 +105,7 @@ obj64-$(CONFIG_AUDIT) += compat_audit.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
+obj-$(CONFIG_FTRACE_SYSCALLS) += ftrace.o
obj-$(CONFIG_PERF_EVENTS) += perf_callchain.o
obj-$(CONFIG_PPC_PERF_CTRS) += perf_event.o
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index ce1f3e4..bf99cfa 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -22,6 +22,7 @@
#include <asm/cacheflush.h>
#include <asm/code-patching.h>
#include <asm/ftrace.h>
+#include <asm/syscall.h>
#ifdef CONFIG_DYNAMIC_FTRACE
@@ -600,3 +601,10 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr)
}
}
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+
+#if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_PPC64)
+unsigned long __init arch_syscall_addr(int nr)
+{
+ return sys_call_table[nr*2];
+}
+#endif /* CONFIG_FTRACE_SYSCALLS && CONFIG_PPC64 */
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 9065369..b6ff0cb 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -29,6 +29,7 @@
#include <linux/signal.h>
#include <linux/seccomp.h>
#include <linux/audit.h>
+#include <trace/syscall.h>
#ifdef CONFIG_PPC32
#include <linux/module.h>
#endif
@@ -40,6 +41,9 @@
#include <asm/pgtable.h>
#include <asm/system.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/syscalls.h>
+
/*
* The parameter save area on the stack is used to store arguments being passed
* to callee function and is located at fixed offset from stack pointer.
@@ -1691,6 +1695,9 @@ long do_syscall_trace_enter(struct pt_regs *regs)
*/
ret = -1L;
+ if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
+ trace_sys_enter(regs, regs->gpr[0]);
+
if (unlikely(current->audit_context)) {
#ifdef CONFIG_PPC64
if (!is_32bit_task())
@@ -1719,6 +1726,9 @@ void do_syscall_trace_leave(struct pt_regs *regs)
audit_syscall_exit((regs->ccr&0x10000000)?AUDITSC_FAILURE:AUDITSC_SUCCESS,
regs->result);
+ if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
+ trace_sys_exit(regs, regs->result);
+
step = test_thread_flag(TIF_SINGLESTEP);
if (step || test_thread_flag(TIF_SYSCALL_TRACE))
tracehook_report_syscall_exit(regs, step);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/6] ftrace syscalls: Allow arch specific syscall symbol matching
From: Ian Munsie @ 2011-02-03 3:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andreas Dilger, Andreas Schwab, Dave Kleikamp,
open list:DOCUMENTATION, Namhyung Kim, Jiri Kosina, Jason Baron,
Alexander Graf, Steven Rostedt, David Gibson, Ingo Molnar,
Paul Mackerras, Ian Munsie, KOSAKI Motohiro, Frederic Weisbecker,
Scott Wood, Nathan Lynch, Andrew Morton, linuxppc-dev,
Avantika Mathur
In-Reply-To: <1296703645-18718-1-git-send-email-imunsie@au1.ibm.com>
From: Ian Munsie <imunsie@au1.ibm.com>
Some architectures have unusual symbol names and the generic code to
match the symbol name with the function name for the syscall metadata
will fail. For example, symbols on PPC64 start with a period and the
generic code will fail to match them.
This patch moves the match logic out into a separate function which an
arch can override by defining ARCH_HAS_SYSCALL_MATCH_SYM_NAME in
asm/ftrace.h and implementing arch_syscall_match_sym_name.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
Documentation/trace/ftrace-design.txt | 4 ++++
kernel/trace/trace_syscalls.c | 21 ++++++++++++++-------
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt
index 6fca17b..79fcafc 100644
--- a/Documentation/trace/ftrace-design.txt
+++ b/Documentation/trace/ftrace-design.txt
@@ -250,6 +250,10 @@ You need very few things to get the syscalls tracing in an arch.
- If the system call table on this arch is more complicated than a simple array
of addresses of the system calls, implement an arch_syscall_addr to return
the address of a given system call.
+- If the symbol names of the system calls do not match the function names on
+ this arch, define ARCH_HAS_SYSCALL_MATCH_SYM_NAME in asm/ftrace.h and
+ implement arch_syscall_match_sym_name with the appropriate logic to return
+ true if the function name corresponds with the symbol name.
- Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 33360b9..7b76a65 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -60,6 +60,19 @@ extern unsigned long __stop_syscalls_metadata[];
static struct syscall_metadata **syscalls_metadata;
+#ifndef ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+static inline bool arch_syscall_match_sym_name(const char *sym, const char *name)
+{
+ /*
+ * Only compare after the "sys" prefix. Archs that use
+ * syscall wrappers may have syscalls symbols aliases prefixed
+ * with "SyS" instead of "sys", leading to an unwanted
+ * mismatch.
+ */
+ return !strcmp(sym + 3, name + 3);
+}
+#endif
+
static struct syscall_metadata *find_syscall_meta(unsigned long syscall)
{
struct syscall_metadata *start;
@@ -72,13 +85,7 @@ static struct syscall_metadata *find_syscall_meta(unsigned long syscall)
kallsyms_lookup(syscall, NULL, NULL, NULL, str);
for ( ; start < stop; start++) {
- /*
- * Only compare after the "sys" prefix. Archs that use
- * syscall wrappers may have syscalls symbols aliases prefixed
- * with "SyS" instead of "sys", leading to an unwanted
- * mismatch.
- */
- if (start->name && !strcmp(start->name + 3, str + 3))
+ if (start->name && arch_syscall_match_sym_name(str, start->name))
return start;
}
return NULL;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/6] ftrace syscalls: Make arch_syscall_addr weak
From: Ian Munsie @ 2011-02-03 3:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andreas Dilger, Andreas Schwab, Dave Kleikamp,
open list:DOCUMENTATION, Namhyung Kim, Jiri Kosina, Jason Baron,
Alexander Graf, Steven Rostedt, David Gibson, Ingo Molnar,
Paul Mackerras, Ian Munsie, KOSAKI Motohiro, Frederic Weisbecker,
Scott Wood, Nathan Lynch, Andrew Morton, linuxppc-dev,
Avantika Mathur
In-Reply-To: <1296703645-18718-1-git-send-email-imunsie@au1.ibm.com>
From: Ian Munsie <imunsie@au1.ibm.com>
Some architectures use non-trivial system call tables and will not work
with the generic arch_syscall_addr code. For example, PowerPC64 uses a
table of twin long longs.
This patch makes the generic arch_syscall_addr weak to allow
architectures with non-trivial system call tables to override it.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
Documentation/trace/ftrace-design.txt | 3 +++
kernel/trace/trace_syscalls.c | 2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt
index dc52bd4..6fca17b 100644
--- a/Documentation/trace/ftrace-design.txt
+++ b/Documentation/trace/ftrace-design.txt
@@ -247,6 +247,9 @@ You need very few things to get the syscalls tracing in an arch.
- Support the TIF_SYSCALL_TRACEPOINT thread flags.
- Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace
in the ptrace syscalls tracing path.
+- If the system call table on this arch is more complicated than a simple array
+ of addresses of the system calls, implement an arch_syscall_addr to return
+ the address of a given system call.
- Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 1a6e8dd..33360b9 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -445,7 +445,7 @@ int init_syscall_trace(struct ftrace_event_call *call)
return id;
}
-unsigned long __init arch_syscall_addr(int nr)
+unsigned long __init __weak arch_syscall_addr(int nr)
{
return (unsigned long)sys_call_table[nr];
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/6] ftrace syscalls: Convert redundant syscall_nr checks into WARN_ON
From: Ian Munsie @ 2011-02-03 3:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andreas Dilger, Andreas Schwab, Dave Kleikamp, Namhyung Kim,
Jiri Kosina, Jason Baron, Alexander Graf, Steven Rostedt,
David Gibson, Ingo Molnar, Paul Mackerras, Ian Munsie,
KOSAKI Motohiro, Frederic Weisbecker, Scott Wood, Nathan Lynch,
Andrew Morton, linuxppc-dev, Avantika Mathur
In-Reply-To: <1296703645-18718-1-git-send-email-imunsie@au1.ibm.com>
From: Ian Munsie <imunsie@au1.ibm.com>
With the ftrace events now checking if the syscall_nr is valid upon
initialisation it should no longer be possible to register or unregister
a syscall event without a valid syscall_nr since they should not be
created. This adds a WARN_ON_ONCE in the register and unregister
functions to locate potential regressions in the future.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
kernel/trace/trace_syscalls.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index a66bc13..1a6e8dd 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -358,7 +358,7 @@ int reg_event_syscall_enter(struct ftrace_event_call *call)
int num;
num = ((struct syscall_metadata *)call->data)->syscall_nr;
- if (num < 0 || num >= NR_syscalls)
+ if (WARN_ON_ONCE(num < 0 || num >= NR_syscalls))
return -ENOSYS;
mutex_lock(&syscall_trace_lock);
if (!sys_refcount_enter)
@@ -376,7 +376,7 @@ void unreg_event_syscall_enter(struct ftrace_event_call *call)
int num;
num = ((struct syscall_metadata *)call->data)->syscall_nr;
- if (num < 0 || num >= NR_syscalls)
+ if (WARN_ON_ONCE(num < 0 || num >= NR_syscalls))
return;
mutex_lock(&syscall_trace_lock);
sys_refcount_enter--;
@@ -392,7 +392,7 @@ int reg_event_syscall_exit(struct ftrace_event_call *call)
int num;
num = ((struct syscall_metadata *)call->data)->syscall_nr;
- if (num < 0 || num >= NR_syscalls)
+ if (WARN_ON_ONCE(num < 0 || num >= NR_syscalls))
return -ENOSYS;
mutex_lock(&syscall_trace_lock);
if (!sys_refcount_exit)
@@ -410,7 +410,7 @@ void unreg_event_syscall_exit(struct ftrace_event_call *call)
int num;
num = ((struct syscall_metadata *)call->data)->syscall_nr;
- if (num < 0 || num >= NR_syscalls)
+ if (WARN_ON_ONCE(num < 0 || num >= NR_syscalls))
return;
mutex_lock(&syscall_trace_lock);
sys_refcount_exit--;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/6] ftrace syscalls: don't add events for unmapped syscalls
From: Ian Munsie @ 2011-02-03 3:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andreas Dilger, Andreas Schwab, Dave Kleikamp, Namhyung Kim,
Jiri Kosina, Jason Baron, Alexander Graf, Steven Rostedt,
David Gibson, Ingo Molnar, Paul Mackerras, Ian Munsie,
KOSAKI Motohiro, Frederic Weisbecker, Scott Wood, Nathan Lynch,
Andrew Morton, linuxppc-dev, Avantika Mathur
In-Reply-To: <1296703645-18718-1-git-send-email-imunsie@au1.ibm.com>
From: Ian Munsie <imunsie@au1.ibm.com>
FTRACE_SYSCALLS would create events for each and every system call, even
if it had failed to map the system call's name with it's number. This
resulted in a number of events being created that would not behave as
expected.
This could happen, for example, on architectures who's symbol names are
unusual and will not match the system call name. It could also happen
with system calls which were mapped to sys_ni_syscall.
This patch changes the default system call number in the metadata to -1.
If the system call name from the metadata is not successfully mapped to
a system call number during boot, than the event initialisation routine
will now return an error, preventing the event from being created.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
include/linux/syscalls.h | 2 ++
kernel/trace/trace_syscalls.c | 8 ++++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 18cd068..2e5a68d 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -160,6 +160,7 @@ extern struct trace_event_functions exit_syscall_print_funcs;
__attribute__((section("__syscalls_metadata"))) \
__syscall_meta_##sname = { \
.name = "sys"#sname, \
+ .syscall_nr = -1, /* Filled in at boot */ \
.nb_args = nb, \
.types = types_##sname, \
.args = args_##sname, \
@@ -176,6 +177,7 @@ extern struct trace_event_functions exit_syscall_print_funcs;
__attribute__((section("__syscalls_metadata"))) \
__syscall_meta__##sname = { \
.name = "sys_"#sname, \
+ .syscall_nr = -1, /* Filled in at boot */ \
.nb_args = 0, \
.enter_event = &event_enter__##sname, \
.exit_event = &event_exit__##sname, \
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index b706529..a66bc13 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -423,6 +423,14 @@ void unreg_event_syscall_exit(struct ftrace_event_call *call)
int init_syscall_trace(struct ftrace_event_call *call)
{
int id;
+ int num;
+
+ num = ((struct syscall_metadata *)call->data)->syscall_nr;
+ if (num < 0 || num >= NR_syscalls) {
+ pr_debug("syscall %s metadata not mapped, disabling ftrace event\n",
+ ((struct syscall_metadata *)call->data)->name);
+ return -ENOSYS;
+ }
if (set_syscall_print_fmt(call) < 0)
return -ENOMEM;
--
1.7.2.3
^ permalink raw reply related
* PowerPC, ftrace: Add PPC raw syscall tracepoints & ftrace fixes (mimimal subset only) v4
From: Ian Munsie @ 2011-02-03 3:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andreas Dilger, Andreas Schwab, Dave Kleikamp, Namhyung Kim,
Jiri Kosina, Jason Baron, Alexander Graf, Steven Rostedt,
David Gibson, Ingo Molnar, Paul Mackerras, KOSAKI Motohiro,
Frederic Weisbecker, Scott Wood, Nathan Lynch, Andrew Morton,
linuxppc-dev, Avantika Mathur
Hi All,
This is a partial version of my 'ftrace syscalls, PowerPC: Various fixes,
Compat Syscall support and PowerPC implementation'. This is updated from
yesterday with arch_syscall_addr changed to a static inline function from
Steven's suggestion.
This subset implements the raw syscall tracepoints on PowerPC which has been
requested recently. It also fixes ftrace syscalls to ensure that events will
only be created for syscalls that successfully map their metadata to a syscall
number, so that non-working phantom events are not created. Patches #2 and #6
in this series are not strictly necessary for this, they just optimise ftrace
syscalls a bit.
What's missing from this series that was in the full 40 patch v2 series is the
conversion of all the syscalls implemented under /arch/powerpc, Jason Baron's
compat syscall support and the conversion of the remaining native and compat
syscalls to this infrastructure.
Cheers,
-Ian
Changelog:
Subset v4:
- Changed arch_syscall_addr to a static inline function from Steven's
suggestion. Archs implementing their own function must now define
ARCH_HAS_SYSCALL_MATCH_SYM_NAME in their asm/ftrace.h
Subset v3:
- Rather than removing the redundant syscall_nr checks completely, I have
turned them into WARN_ON_ONCE to catch possible future regressions, from
Steven Rostedt's suggestion.
- From Mike Frysinger's suggestion, arch_syscall_addr is now a macro rather
than a weak function to minimise the overhead at boot. Archs with special
requirements (such as ppc64) can define their own macro in asm/ftrace.h.
Steven Rostedt suggested this be made a static inline function, but I don't
see how this would be possible (at least without #defines and #ifndefs) given
that it has to be weak to allow archs to override it (Unless I misunderstood
something? Steven?).
Subset v2:
- Minimal unchanged subset from 'ftrace syscalls, PowerPC: Various fixes,
Compat Syscall support and PowerPC implementation' v2 patch series.
^ permalink raw reply
* [PATCH v2 3/3] powerpc: make MPIC honor the 'no-reset' device tree property
From: Meador Inge @ 2011-02-03 1:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss, Hollis Blanchard
In-Reply-To: <1296697900-14004-1-git-send-email-meador_inge@mentor.com>
This property, defined in the Open PIC binding, tells the kernel not to use the
reset bit in the global configuration register. Additionally, its presence
mandates that only sources which are actually used (i.e. appear in the device
tree) should have their VECPRI bits initialized.
Signed-off-by: Meador Inge <meador_inge@mentor.com>
CC: Hollis Blanchard <hollis_blanchard@mentor.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/mpic.h | 4 ++-
arch/powerpc/sysdev/mpic.c | 54 ++++++++++++++++++++++++++++++--------
2 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index 9b94f18..688e3e0 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -322,6 +322,8 @@ struct mpic
#ifdef CONFIG_PM
struct mpic_irq_save *save_data;
#endif
+
+ int cpu;
};
/*
@@ -333,7 +335,7 @@ struct mpic
*/
/* This is the primary controller, only that one has IPIs and
- * has afinity control. A non-primary MPIC always uses CPU0
+ * has affinity control. A non-primary MPIC always uses CPU0
* registers only
*/
#define MPIC_PRIMARY 0x00000001
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index a98f41d..5f17022 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -308,6 +308,15 @@ static inline void mpic_map(struct mpic *mpic, struct device_node *node,
#define mpic_map(m,n,p,b,o,s) _mpic_map_mmio(m,p,b,o,s)
#endif /* !CONFIG_PPC_DCR */
+static inline void mpic_init_vector(struct mpic *mpic, int source)
+{
+ /* start with vector = source number, and masked */
+ u32 vecpri = MPIC_VECPRI_MASK | source | (8 << MPIC_VECPRI_PRIORITY_SHIFT);
+
+ /* init hw */
+ mpic_irq_write(source, MPIC_INFO(IRQ_VECTOR_PRI), vecpri);
+ mpic_irq_write(source, MPIC_INFO(IRQ_DESTINATION), 1 << mpic->cpu);
+}
/* Check if we have one of those nice broken MPICs with a flipped endian on
@@ -622,6 +631,14 @@ static unsigned int mpic_is_ipi(struct mpic *mpic, unsigned int irq)
return (src >= mpic->ipi_vecs[0] && src <= mpic->ipi_vecs[3]);
}
+/* Determine if the linux irq is a timer interrupt */
+static unsigned int mpic_is_timer_interrupt(struct mpic *mpic, unsigned int irq)
+{
+ unsigned int src = mpic_irq_to_hw(irq);
+
+ return (src >= mpic->timer_vecs[0] && src <= mpic->timer_vecs[3]);
+}
+
/* Convert a cpu mask from logical to physical cpu numbers. */
static inline u32 mpic_physmask(u32 cpumask)
@@ -963,6 +980,15 @@ static int mpic_host_map(struct irq_host *h, unsigned int virq,
if (hw >= mpic->irq_count)
return -EINVAL;
+ /* If the MPIC was reset, then all vectors have already been
+ * initialized. Otherwise, the appropriate vector needs to be
+ * initialized here to ensure that only used sources are setup with
+ * a vector.
+ */
+ if (!(mpic->flags & MPIC_WANTS_RESET))
+ if (!(mpic_is_ipi(mpic, hw) || mpic_is_timer_interrupt(mpic, hw)))
+ mpic_init_vector(mpic, hw);
+
mpic_msi_reserve_hwirq(mpic, hw);
/* Default chip */
@@ -1129,7 +1155,16 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mpic_map(mpic, node, paddr, &mpic->tmregs, MPIC_INFO(TIMER_BASE), 0x1000);
/* Reset */
- if (flags & MPIC_WANTS_RESET) {
+
+ /* When using a device-node, reset requests are only honored if the MPIC
+ * is allowed to reset.
+ */
+ if (node && of_get_property(node, "no-reset", NULL)) {
+ mpic->flags &= ~MPIC_WANTS_RESET;
+ }
+
+ if (mpic->flags & MPIC_WANTS_RESET) {
+ printk(KERN_DEBUG "mpic: Resetting\n");
mpic_write(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0),
mpic_read(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0))
| MPIC_GREG_GCONF_RESET);
@@ -1246,7 +1281,6 @@ void __init mpic_set_default_senses(struct mpic *mpic, u8 *senses, int count)
void __init mpic_init(struct mpic *mpic)
{
int i;
- int cpu;
BUG_ON(mpic->num_sources == 0);
@@ -1290,18 +1324,14 @@ void __init mpic_init(struct mpic *mpic)
mpic_pasemi_msi_init(mpic);
if (mpic->flags & MPIC_PRIMARY)
- cpu = hard_smp_processor_id();
+ mpic->cpu = hard_smp_processor_id();
else
- cpu = 0;
+ mpic->cpu = 0;
- for (i = 0; i < mpic->num_sources; i++) {
- /* start with vector = source number, and masked */
- u32 vecpri = MPIC_VECPRI_MASK | i |
- (8 << MPIC_VECPRI_PRIORITY_SHIFT);
-
- /* init hw */
- mpic_irq_write(i, MPIC_INFO(IRQ_VECTOR_PRI), vecpri);
- mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION), 1 << cpu);
+ if (mpic->flags & MPIC_WANTS_RESET) {
+ for (i = 0; i < mpic->num_sources; i++) {
+ mpic_init_vector(mpic, i);
+ }
}
/* Init spurious vector */
--
1.6.3.3
^ permalink raw reply related
* [PATCH v2 2/3] powerpc: document the Open PIC device tree binding
From: Meador Inge @ 2011-02-03 1:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss, Hollis Blanchard, Stuart Yoder
In-Reply-To: <1296697900-14004-1-git-send-email-meador_inge@mentor.com>
This binding documents several properties that have been in use for quite
some time, and adds one new property 'no-reset', which controls whether the
Open PIC should be reset during runtime initialization.
The general formatting and interrupt specifier definition is based off of
Stuart Yoder's FSL MPIC binding.
Signed-off-by: Meador Inge <meador_inge@mentor.com>
CC: Hollis Blanchard <hollis_blanchard@mentor.com>
CC: Stuart Yoder <stuart.yoder@freescale.com>
---
Documentation/powerpc/dts-bindings/open-pic.txt | 115 +++++++++++++++++++++++
1 files changed, 115 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/open-pic.txt
diff --git a/Documentation/powerpc/dts-bindings/open-pic.txt b/Documentation/powerpc/dts-bindings/open-pic.txt
new file mode 100644
index 0000000..447ef65
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/open-pic.txt
@@ -0,0 +1,115 @@
+* Open PIC Binding
+
+This binding specifies what properties must be available in the device tree
+representation of an Open PIC compliant interrupt controller. This binding is
+based on the binding defined for Open PIC in [1] and is a superset of that
+binding.
+
+PROPERTIES
+
+ NOTE: Many of these descriptions were paraphrased here from [1] to aid
+ readability.
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Specifies the compatibility list for the PIC. The
+ property value shall include "open-pic".
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: Specifies the base physical address(s) and size(s) of this
+ PIC's addressable register space.
+
+ - interrupt-controller
+ Usage: required
+ Value type: <empty>
+ Definition: The presence of this property identifies the node
+ as an Open PIC. No property value should be defined.
+
+ - #interrupt-cells
+ Usage: required
+ Value type: <u32>
+ Definition: Specifies the number of cells needed to encode an
+ interrupt source. Shall be 2.
+
+ - #address-cells
+ Usage: required
+ Value type: <u32>
+ Definition: Specifies the number of cells needed to encode an
+ address. The value of this property shall always be 0.
+ As such, 'interrupt-map' nodes do not have to specify a
+ parent unit address.
+
+ - no-reset
+ Usage: optional
+ Value type: <empty>
+ Definition: The presence of this property indicates that the PIC
+ should not be reset during runtime initialization. The presence of
+ this property also mandates that any initialization related to
+ interrupt sources shall be limited to sources explicitly referenced
+ in the device tree.
+
+INTERRUPT SPECIFIER DEFINITION
+
+ Interrupt specifiers consists of 2 cells encoded as
+ follows:
+
+ <1st-cell> interrupt-number
+
+ Identifies the interrupt source.
+
+ <2nd-cell> level-sense information, encoded as follows:
+ 0 = low-to-high edge triggered
+ 1 = active low level-sensitive
+ 2 = active high level-sensitive
+ 3 = high-to-low edge triggered
+
+EXAMPLE 1
+
+ /*
+ * An Open PIC interrupt controller
+ */
+ mpic: pic@40000 {
+ // This is an interrupt controller node.
+ interrupt-controller;
+
+ // No address cells so that 'interrupt-map' nodes which reference
+ // this Open PIC node do not need a parent address specifier.
+ #address-cells = <0>;
+
+ // Two cells to encode interrupt sources.
+ #interrupt-cells = <2>;
+
+ // Offset address of 0x40000 and size of 0x40000.
+ reg = <0x40000 0x40000>;
+
+ // Compatible with Open PIC.
+ compatible = "open-pic";
+
+ // The PIC should not be reset.
+ no-reset;
+ };
+
+EXAMPLE 2
+
+ /*
+ * An interrupt generating device that is wired to an Open PIC.
+ */
+ serial0: serial@4500 {
+ // Interrupt source '42' that is active high level-sensitive.
+ // Note that there are only two cells as specified in the interrupt
+ // parent's '#interrupt-cells' property.
+ interrupts = <42 2>;
+
+ // The interrupt controller that this device is wired to.
+ interrupt-parent = <&mpic>;
+ };
+
+REFERENCES
+
+[1] Power.org (TM) Standard for Embedded Power Architecture (TM) Platform
+ Requirements (ePAPR), Version 1.0, July 2008.
+ (http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf)
+
--
1.6.3.3
^ permalink raw reply related
* [PATCH v2 1/3] powerpc: Removing support for 'protected-sources'
From: Meador Inge @ 2011-02-03 1:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss, Hollis Blanchard
In-Reply-To: <1296697900-14004-1-git-send-email-meador_inge@mentor.com>
In a recent discussion [1, 2] concerning device trees for AMP systems, the
question of whether we really need 'protected-sources' arose. The general
consensus was that if you don't want a source to be used, then it should *not*
be mentioned in an 'interrupts' property. If a source really needs to be
mentioned, then it should be put in a property other than 'interrupts' with
a specific binding for that use case.
[1] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/004038.html
[2] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/003991.html
Signed-off-by: Meador Inge <meador_inge@mentor.com>
CC: Hollis Blanchard <hollis_blanchard@mentor.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/mpic.h | 3 ---
arch/powerpc/sysdev/mpic.c | 38 --------------------------------------
2 files changed, 0 insertions(+), 41 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index e000cce..9b94f18 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -301,9 +301,6 @@ struct mpic
struct mpic_reg_bank cpuregs[MPIC_MAX_CPUS];
struct mpic_reg_bank isus[MPIC_MAX_ISU];
- /* Protected sources */
- unsigned long *protected;
-
#ifdef CONFIG_MPIC_WEIRD
/* Pointer to HW info array */
u32 *hw_set;
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 7c13426..a98f41d 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -947,8 +947,6 @@ static int mpic_host_map(struct irq_host *h, unsigned int virq,
if (hw == mpic->spurious_vec)
return -EINVAL;
- if (mpic->protected && test_bit(hw, mpic->protected))
- return -EINVAL;
#ifdef CONFIG_SMP
else if (hw >= mpic->ipi_vecs[0]) {
@@ -1095,26 +1093,6 @@ struct mpic * __init mpic_alloc(struct device_node *node,
if (node && of_get_property(node, "big-endian", NULL) != NULL)
mpic->flags |= MPIC_BIG_ENDIAN;
- /* Look for protected sources */
- if (node) {
- int psize;
- unsigned int bits, mapsize;
- const u32 *psrc =
- of_get_property(node, "protected-sources", &psize);
- if (psrc) {
- psize /= 4;
- bits = intvec_top + 1;
- mapsize = BITS_TO_LONGS(bits) * sizeof(unsigned long);
- mpic->protected = kzalloc(mapsize, GFP_KERNEL);
- BUG_ON(mpic->protected == NULL);
- for (i = 0; i < psize; i++) {
- if (psrc[i] > intvec_top)
- continue;
- __set_bit(psrc[i], mpic->protected);
- }
- }
- }
-
#ifdef CONFIG_MPIC_WEIRD
mpic->hw_set = mpic_infos[MPIC_GET_REGSET(flags)];
#endif
@@ -1321,9 +1299,6 @@ void __init mpic_init(struct mpic *mpic)
u32 vecpri = MPIC_VECPRI_MASK | i |
(8 << MPIC_VECPRI_PRIORITY_SHIFT);
- /* check if protected */
- if (mpic->protected && test_bit(i, mpic->protected))
- continue;
/* init hw */
mpic_irq_write(i, MPIC_INFO(IRQ_VECTOR_PRI), vecpri);
mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION), 1 << cpu);
@@ -1492,13 +1467,6 @@ static unsigned int _mpic_get_one_irq(struct mpic *mpic, int reg)
mpic_eoi(mpic);
return NO_IRQ;
}
- if (unlikely(mpic->protected && test_bit(src, mpic->protected))) {
- if (printk_ratelimit())
- printk(KERN_WARNING "%s: Got protected source %d !\n",
- mpic->name, (int)src);
- mpic_eoi(mpic);
- return NO_IRQ;
- }
return irq_linear_revmap(mpic->irqhost, src);
}
@@ -1532,12 +1500,6 @@ unsigned int mpic_get_coreint_irq(void)
mpic_eoi(mpic);
return NO_IRQ;
}
- if (unlikely(mpic->protected && test_bit(src, mpic->protected))) {
- if (printk_ratelimit())
- printk(KERN_WARNING "%s: Got protected source %d !\n",
- mpic->name, (int)src);
- return NO_IRQ;
- }
return irq_linear_revmap(mpic->irqhost, src);
#else
--
1.6.3.3
^ permalink raw reply related
* [PATCH v2 0/3] powerpc: Open PIC binding and 'no-reset' implementation
From: Meador Inge @ 2011-02-03 1:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss, Hollis Blanchard
This patch set provides a binding for Open PIC and implements support for
a new property, specified by that binding, called 'no-reset'. With 'no-reset'
in place the 'protected-sources' property is no longer needed and was removed.
Signed-off-by: Meador Inge <meador_inge@mentor.com>
CC: Hollis Blanchard <hollis_blanchard@mentor.com>
Meador Inge (3):
powerpc: Removing support for 'protected-sources'
powerpc: document the Open PIC device tree binding
powerpc: make MPIC honor the 'no-reset' device tree property
Documentation/powerpc/dts-bindings/open-pic.txt | 115 +++++++++++++++++++++++
arch/powerpc/include/asm/mpic.h | 7 +-
arch/powerpc/sysdev/mpic.c | 92 ++++++++----------
3 files changed, 160 insertions(+), 54 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/open-pic.txt
^ permalink raw reply
* Re: [PATCH 4/6] ftrace syscalls: Allow arch specific syscall symbol matching
From: Ian Munsie @ 2011-02-03 0:28 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andreas Dilger, Andreas Schwab, Dave Kleikamp, DOCUMENTATION,
Namhyung Kim, Jiri Kosina, Jason Baron, linux-kernel,
Alexander Graf, Ingo Molnar, Paul Mackerras, KOSAKI Motohiro,
Frederic Weisbecker, Scott Wood, Nathan Lynch, Andrew Morton,
David Gibson, linuxppc-dev, Avantika Mathur
In-Reply-To: <1296655484.10797.47.camel@gandalf.stny.rr.com>
Excerpts from Steven Rostedt's message of Thu Feb 03 01:04:44 +1100 2011:
> I'll answer your question here.
> > +#define arch_syscall_match_sym_name(sym, name) !strcmp(sym + 3, name + 3)
>
> Instead, you could have:
>
> #ifndef ARCH_HAS_SYSCALL_MATCH_SYM_NAME
>
> static inline arch_syscall_match_sym_name(const char *sym, const char *name)
> {
> return strcmp(sym + 3, name + 3) != 0;
> }
>
>
> If an arch needs to make its own, then it can simply override it by
> creating its own version and defining:
>
> #define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
>
> Just like they do when an arch has its own strcmp.
Ok, I've changed it over. Just doing a quick regression test on ppc64 &
x86 then I'll repost.
Cheers,
-Ian
^ permalink raw reply
* Re: [PATCH V2 1/6] powerpc: Move udbg_early_init() after early_init_devtree()
From: Dave Kleikamp @ 2011-02-03 0:00 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20110202230643.GF3032@yookeroo>
On Thu, 2011-02-03 at 10:06 +1100, David Gibson wrote:
> On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
> > so that it can use information from the device tree.
>
> Hrm. On the other hand this means that the early_init_devtree() code
> can't benefit from hardcoded early debugging. Since you don't
> actually appear to use devtree information in udbg_early_init() in the
> latest series, I'd suggest dropping this patch.
Patch 2 depends on early_init_devtree() being run. Until then, I don't
know of a way to get at the bootargs.
--
Dave Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH V2 4/6] powerpc/44x: don't use tlbivax on AMP systems
From: Dave Kleikamp @ 2011-02-02 23:53 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20110202230844.GG3032@yookeroo>
On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
> On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> > Since other OS's may be running on the other cores don't use tlbivax
>
> [snip]
> > +#ifdef CONFIG_44x
> > +void __init early_init_mmu_44x(void)
> > +{
> > + unsigned long root = of_get_flat_dt_root();
> > + if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))
> > + amp = 1;
> > +}
> > +#endif /* CONFIG_44x */
>
> A test against a hardcoded compatible string seems a nasty way to do
> this. Maybe we should define a new boolean property for the root
> node.
I'm not crazy about this string, but I needed something in the device
tree to key off of. Freescale has something similar (i.e.
MPC8572DS-CAMP), so I chose to follow their example. I'd be happy to
replace it with a boolean property. Any objection to just using "amp"?
Thanks,
Shaggy
--
Dave Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH V2 4/6] powerpc/44x: don't use tlbivax on AMP systems
From: David Gibson @ 2011-02-02 23:08 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linuxppc-dev
In-Reply-To: <1296586126-32765-5-git-send-email-shaggy@linux.vnet.ibm.com>
On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> Since other OS's may be running on the other cores don't use tlbivax
[snip]
> +#ifdef CONFIG_44x
> +void __init early_init_mmu_44x(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> + if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))
> + amp = 1;
> +}
> +#endif /* CONFIG_44x */
A test against a hardcoded compatible string seems a nasty way to do
this. Maybe we should define a new boolean property for the root
node.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH V2 1/6] powerpc: Move udbg_early_init() after early_init_devtree()
From: David Gibson @ 2011-02-02 23:06 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linuxppc-dev
In-Reply-To: <1296586126-32765-2-git-send-email-shaggy@linux.vnet.ibm.com>
On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
> so that it can use information from the device tree.
Hrm. On the other hand this means that the early_init_devtree() code
can't benefit from hardcoded early debugging. Since you don't
actually appear to use devtree information in udbg_early_init() in the
latest series, I'd suggest dropping this patch.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: BootX
From: Benjamin Herrenschmidt @ 2011-02-02 22:29 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTin+1pENJ_CNQGoPA=Hisv4qkJWCE01uyZEXipNu@mail.gmail.com>
On Wed, 2011-02-02 at 16:09 -0600, kevin diggs wrote:
> Hi,
>
> And one more thing: Why does an SMP kernel (mesh compiled in an SMP
> enabled kernel) work?
Could be an alignment or timing problem, depending on random things the
alignment of some DMA data structures or timing of access might end up
being subtely different.
> What all does SMP do? If it matters, I'm voluntary preempt.
>
> Is the DMA hardware in this thing used in any other system (I guess I
> mean both other computers and other sub-systems in this computer -
> does the 53c94 use it? The audio uses it, right?)?
The DBDMA engine is used in various Apple chips but with more or less HW
bugs in it :-)
To get some more info about the MESH, I suggest you google for a
document called "MacTech.pdf" (Macintosh Technology in the
Common Hardware Reference Platform).
This describes the "MacIO" chip that was designed by Apple for CHRP
machines, which is a successor of the Bandit chip which I think contains
the MESH on your machine. The basic IO cells like MESH are the same (tho
it's possible that the one you have contains more bugs).
Cheers,
Ben.
^ permalink raw reply
* Re: BootX
From: kevin diggs @ 2011-02-02 22:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=xM5qt4sic-YBD87Znt0vVOyX2yOyhODhtKNqC@mail.gmail.com>
Hi,
And one more thing: Why does an SMP kernel (mesh compiled in an SMP
enabled kernel) work?
What all does SMP do? If it matters, I'm voluntary preempt.
Is the DMA hardware in this thing used in any other system (I guess I
mean both other computers and other sub-systems in this computer -
does the 53c94 use it? The audio uses it, right?)?
kevin
^ permalink raw reply
* Question on supporting multiple HW versions with a single driver (warning: long post)
From: Bruce_Leonard @ 2011-02-02 21:57 UTC (permalink / raw)
To: linuxppc-dev
So this is sort of a follow on question to one I posted a month ago about
trying to get a PCI driver to work with OF (which I think I more or less
understood the answer to). I'm encountering a different sort of problem
that I'd like to solve with OF but I'm not sure I can. Let me lay out a
little background first.
We build embedded systems, so we never really have hot plug events and our
addresses (at least for HW interfaces) are pretty much static for any
given product. In other words for product "A" the NAND controller will
always be at address "X", though on product "B" that same NAND controller
may be at address "Y". Also, the devices in the product are static, i.e.,
we'll always talk to an LXT971 as the PHY.
Currently I'm working on building a driver for an ethernet MAC we're
putting in an FPGA. The MAC is based on the MPC8347 TSEC and the driver
is based on the gianfar driver. (My previous question was how to spoof
the OF gianfar driver into thinking it was a PCI driver because our MAC is
going to be hanging off a PCI bus. Ultimately I decided to just
steal...err...borrow... the guts of the gianfar driver and make it a PCI
driver that only deals with our MAC.)
Right in the middle of writing this driver, my HW guys came to me and said
they wanted to use this same MAC in other products. Great I said. Local
bus they said. Which opens up a whole can of worms and leads to my
question. We've got a MAC in a FPGA with a nice generic interface on the
front of it that can talk to a whole range of different busses, PCI, PCIe,
local bus (of any variety of any processor), etc. But the internals of
the MAC (i.e., the register sets, the buffers, the whole buffer descriptor
mechanism) all looks the same. Seems to me that this is exactly the sort
of situation OF and device trees was developed for.
What I'd like to do, and I'm sure it's possible but I have no idea how, is
to still have this as an OF driver and have the device tree tell the
kernel about the HW interface to use. So on one product (currently all
products use an MCP83xx variant) I would have a child node under a PCI
node to describe it's interrupts, addressing (which could also come from a
PCI probe I expect), compatibility, any attached PHYs etc, and on a second
product do the same thing under a localbus node.
First question that comes to mind is ordering. If I put a child node in
the PCI node of the device tree, what happens when the device tree is
processed? Is it immediately going to try and find and install a driver
for that child node? Since the device tree is processed very early, the
PCI bus isn't going to be set up and available yet. Will trying to
install a PCI driver via OF even be possible at this point? Then I'd
still need a PCI function to claim the device when the PCI bus gets
probed. If the driver is already installed via OF, what does the PCI
function do?
Or am I all backwards. Does having the child node to the PCI node
actually do anything when the early OF code runs? If not would the PCI
probe function be the first indication to the system that the driver needs
to be loaded? In which case I just walk the device tree looking
for...what? How would I match up the PCI ID with something in the device
tree?
Then there's the local bus side of the question? That should truly be an
OF driver and use struct of_platform_driver along with that whole
mechanism. How do I make that compatible with the version of the MAC that
runs on PCI?
Or am I making a whole lot of work for myself and I should just make them
separate drivers? I'm trying to keep the code base as small and coherent
as possible. I don't want to have to maintain multiple copies of a driver
that are essentially identical.
Thanks.
Bruce
^ permalink raw reply
* Re: BootX
From: kevin diggs @ 2011-02-02 21:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1296682842.2349.730.camel@pasglop>
Ben,
I know you are VERY busy. I appreciate your taking the time to reply.
Since I'm am still using this thing I'll take a stab at trying to
track it down. I just posted the FYI to see if I could trigger some
thoughts (like your post).
With a 4.3.5 compiled mesh, it fails a lot of early stuff like getting
cache info? I don't remember the full list because it fails to find
the root fs and does the reboot in 180 seconds thing (I still have in
a back corner of my brain the serial console xmon boot stuff and will
probably eventually try that).
I am hopeful that since it (at least so far) always fails that it
might not be THAT bad to track down. That coupled with some knowledge
of what the compilers are doing differently can hopefully help track
it down.
Thanks!
kevin
On Wed, Feb 2, 2011 at 3:40 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> That's interesting... That driver is really nasty, we probably have a
> bug in it that's exposed by optimizations done by more recent compilers
> but it's not going to be trivial to figure out I'm afraid. I at least
> have very dim memories of mesh and how it operates...
>
> One thing to be careful of with Mesh is that the DMA engine, while
> supposedly cache coherent, has shown in the past to have issues when
> DMA'ing to unaligned memory locations. This shouldn't be a problem with
> normal block transfers but we may have to be careful with things like
> inquiry, mode pages, sense requests etc...
>
> Ben.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox