Re: [PATCH v2] cpm2_pic: Allow correct flow_types for port C interrupts
Scott Wood wrote:
> Anton Vorontsov wrote:
>>> +if ((flow_type != IRQ_TYPE_EDGE_BOTH) && +
>>> (flow_type != IRQ_TYPE_EDGE_FALLING)) {
>>
>> I'd place one more tab here.
>
> Or better, align one "flow_type" with the other.
>
> -Scott
>
Thanks Anton and Scott.
Scott's suggestion is also my preferred style, but a (brief) search through the
source didn't reveal much support.
I'll send a new version shortly including you suggestions.
- Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] cpm2_pic: Allow correct flow_types for port C interrupts
Port C interrupts can be either falling edge, or either edge.
Other external interrupts are either falling edge or active low.
Tested on a custom 8280 based board.
Signed-off-by: Mark Ware
---
Changed in v3:
- Cosmetic improvements as suggested by Anton and Scott
- Added tested note to changelog
arch/powerpc/sysdev/cpm2_pic.c | 28 +---
1 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2_pic.c b/arch/powerpc/sysdev/cpm2_pic.c
index 78f1f7c..b1e9206 100644
--- a/arch/powerpc/sysdev/cpm2_pic.c
+++ b/arch/powerpc/sysdev/cpm2_pic.c
@@ -141,13 +141,23 @@ static int cpm2_set_irq_type(unsigned int virq, unsigned
int flow_type)
struct irq_desc *desc = get_irq_desc(virq);
unsigned int vold, vnew, edibit;
- if (flow_type == IRQ_TYPE_NONE)
- flow_type = IRQ_TYPE_LEVEL_LOW;
-
- if (flow_type & IRQ_TYPE_EDGE_RISING) {
- printk(KERN_ERR "CPM2 PIC: sense type 0x%x not supported\n",
- flow_type);
- return -EINVAL;
+ /* Port C interrupts are either IRQ_TYPE_EDGE_FALLING or
+* IRQ_TYPE_EDGE_BOTH (default). All others are IRQ_TYPE_EDGE_FALLING
+* or IRQ_TYPE_LEVEL_LOW (default)
+*/
+ if (src >= CPM2_IRQ_PORTC15 && src <= CPM2_IRQ_PORTC0) {
+ if (flow_type == IRQ_TYPE_NONE)
+ flow_type = IRQ_TYPE_EDGE_BOTH;
+
+ if (flow_type != IRQ_TYPE_EDGE_BOTH &&
+ flow_type != IRQ_TYPE_EDGE_FALLING)
+ goto err_sense;
+ } else {
+ if (flow_type == IRQ_TYPE_NONE)
+ flow_type = IRQ_TYPE_LEVEL_LOW;
+
+ if (flow_type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH))
+ goto err_sense;
}
desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
@@ -179,6 +189,10 @@ static int cpm2_set_irq_type(unsigned int virq, unsigned
int flow_type)
if (vold != vnew)
out_be32(&cpm2_intctl->ic_siexr, vnew);
return 0;
+
+err_sense:
+ pr_err("CPM2 PIC: sense type 0x%x not supported\n", flow_type);
+ return -EINVAL;
}
static struct irq_chip cpm2_pic = {
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] pseries: Don't panic when H_PROD fails during cpu-online.
If an online-attempt on a CPU which has been offlined using H_CEDE
with an appropriate cede latency hint fails, don't panic.
Instead print the error message and let the __cpu_up() code notify the
CPU Hotplug framework of the failure, which in turn can notify the
other subsystem through CPU_UP_CANCELED.
Signed-off-by: Gautham R Shenoy
---
arch/powerpc/platforms/pseries/smp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/smp.c
b/arch/powerpc/platforms/pseries/smp.c
index 8868c01..b488663 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -144,8 +144,8 @@ static void __devinit smp_pSeries_kick_cpu(int nr)
hcpuid = get_hard_smp_processor_id(nr);
rc = plpar_hcall_norets(H_PROD, hcpuid);
if (rc != H_SUCCESS)
- panic("Error: Prod to wake up processor %d Ret= %ld\n",
- nr, rc);
+ printk(KERN_ERR "Error: Prod to wake up processor %d\
+ Ret= %ld\n", nr, rc);
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] pseries: Make declarations of cpu_hotplug_driver_lock() ANSI compatible.
And add the __acquires() and __releases() annotations, while at it.
Signed-off-by: Gautham R Shenoy
---
arch/powerpc/platforms/pseries/dlpar.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
index 12df9e8..67b7a10 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -346,12 +346,14 @@ int dlpar_release_drc(u32 drc_index)
static DEFINE_MUTEX(pseries_cpu_hotplug_mutex);
-void cpu_hotplug_driver_lock()
+void cpu_hotplug_driver_lock(void)
+__acquires(pseries_cpu_hotplug_mutex)
{
mutex_lock(&pseries_cpu_hotplug_mutex);
}
-void cpu_hotplug_driver_unlock()
+void cpu_hotplug_driver_unlock(void)
+__releases(pseries_cpu_hotplug_mutex)
{
mutex_unlock(&pseries_cpu_hotplug_mutex);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] cpm2_pic: Allow correct flow_types for port C interrupts
On Dec 10, 2009, at 5:14 AM, Mark Ware wrote: > Port C interrupts can be either falling edge, or either edge. > Other external interrupts are either falling edge or active low. > Tested on a custom 8280 based board. > > Signed-off-by: Mark Ware > --- > Changed in v3: > - Cosmetic improvements as suggested by Anton and Scott > - Added tested note to changelog > > arch/powerpc/sysdev/cpm2_pic.c | 28 +--- > 1 files changed, 21 insertions(+), 7 deletions(-) Scott, Anton do you want to add an Ack to this version? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] cpm2_pic: Allow correct flow_types for port C interrupts
On Thu, Dec 10, 2009 at 08:52:01AM -0600, Kumar Gala wrote: > > On Dec 10, 2009, at 5:14 AM, Mark Ware wrote: > > > Port C interrupts can be either falling edge, or either edge. > > Other external interrupts are either falling edge or active low. > > Tested on a custom 8280 based board. > > > > Signed-off-by: Mark Ware > > --- > > Changed in v3: > > - Cosmetic improvements as suggested by Anton and Scott > > - Added tested note to changelog > > > > arch/powerpc/sysdev/cpm2_pic.c | 28 +--- > > 1 files changed, 21 insertions(+), 7 deletions(-) > > Scott, Anton do you want to add an Ack to this version? Acked-by: Anton Vorontsov Thanks! -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
On Wed, 2009-12-02 at 17:51 -0800, Pravin Bathija wrote:
> Powerpc 44x uses 36 bit real address while the real address defined
> in MPT Fusion driver is of type 32 bit. This causes ioremap to fail and
> driver
> fails to initialize. This fix changes the data types representing the real
> address from unsigned long 32-bit types to resource_size_t which is
> 64-bit. The
> driver has been tested, the disks get discovered correctly and can do IO.
>
> Signed-off-by: Pravin Bathija
> Acked-by: Feng Kan
> Acked-by: Fushen Chen
> Acked-by: Loc Ho
> Acked-by: Tirumala Reddy Marri
> Acked-by: Victor Gallardo
> ---
> drivers/message/fusion/mptbase.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/message/fusion/mptbase.c
> b/drivers/message/fusion/mptbase.c
> index 5d496a9..9f14a60 100644
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -1511,7 +1511,7 @@ mpt_mapresources(MPT_ADAPTER *ioc)
> {
> u8 __iomem *mem;
> int ii;
> - unsigned longmem_phys;
> + resource_size_t mem_phys;
You never actually compiled this, did you?
drivers/message/fusion/mptbase.c: In function 'mpt_mapresources':
drivers/message/fusion/mptbase.c:1680: warning: format '%lx' expects type 'long
unsigned int', but argument 4 has type 'resource_size_t'
I'll just fold the fix in
James
---
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 162923f..85bc6a6 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1677,8 +1677,8 @@ mpt_mapresources(MPT_ADAPTER *ioc)
return -EINVAL;
}
ioc->memmap = mem;
- dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = %p, mem_phys = %lx\n",
- ioc->name, mem, mem_phys));
+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = %p, mem_phys = %llx\n",
+ ioc->name, mem, (unsigned long long)mem_phys));
ioc->mem_phys = mem_phys;
ioc->chip = (SYSIF_REGS __iomem *)mem;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
These patches implement an extention to the ptrace interface proposed by
Thiago Bauermann and the the PowerPC gdb team.
GDB intends to support the following hardware debug features of BookE
processors:
4 hardware breakpoints (IAC)
2 hardware watchpoints (read, write and read-write) (DAC)
2 value conditions for the hardware watchpoints (DVC)
For that, we need to extend ptrace so that GDB can query and set these
resources. Since we're extending, we're trying to create an interface
that's extendable and that covers both BookE and server processors, so
that GDB doesn't need to special-case each of them. We propose the
following 3 new ptrace requests described below.
There have been discussions of a generic hardware debug interface for the
kernel which would hopefully contemplate all the functionality below and
supersede it. But we need something that works now, and which enables GDB
to be simpler and work with both Server and Embedded processors without
special cases.
1. PTRACE_PPC_GETHWDEBUGINFO
Query for GDB to discover the hardware debug features. The main info to
be returned here is the minimum alignment for the hardware watchpoints.
BookE processors don't have restrictions here, but server processors have
an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
adding special cases to GDB based on what it sees in AUXV.
Since we're at it, we added other useful info that the kernel can return to
GDB: this query will return the number of hardware breakpoints, hardware
watchpoints and whether it supports a range of addresses and a condition.
The query will fill the following structure provided by the requesting process:
struct ppc_debug_info {
unit32_t version;
unit32_t num_instruction_bps;
unit32_t num_data_bps;
unit32_t num_condition_regs;
unit32_t data_bp_alignment;
unit32_t sizeof_condition; /* size of the DVC register */
uint64_t features; /* bitmask of the individual flags */
};
features will have bits indicating whether there is support for:
#define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
2. PTRACE_SETHWDEBUG
Sets a hardware breakpoint or watchpoint, according to the provided structure:
struct ppc_hw_breakpoint {
uint32_t version;
#define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x1
#define PPC_BREAKPOINT_TRIGGER_READ 0x2
#define PPC_BREAKPOINT_TRIGGER_WRITE0x4
uint32_t trigger_type; /* only some combinations allowed */
#define PPC_BREAKPOINT_MODE_EXACT 0x0
#define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE 0x1
#define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE 0x2
#define PPC_BREAKPOINT_MODE_MASK0x3
uint32_t addr_mode; /* address match mode */
#define PPC_BREAKPOINT_CONDITION_NONE 0x0
#define PPC_BREAKPOINT_CONDITION_AND0x1
#define PPC_BREAKPOINT_CONDITION_EXACT 0x1 /* different name for the same
thing as above */
#define PPC_BREAKPOINT_CONDITION_OR 0x2
#define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
#define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff /* byte enable bits */
#define PPC_BREAKPOINT_CONDITION_BE(n) (1<<((n)+16))
uint32_t condition_mode; /* break/watchpoint condition flags */
uint64_t addr;
uint64_t addr2;
uint64_t condition_value;
};
A request specifies one event, not necessarily just one register to be set.
For instance, if the request is for a watchpoint with a condition, both the
DAC and DVC registers will be set in the same request.
With this GDB can ask for all kinds of hardware breakpoints and watchpoints
that the BookE supports. COMEFROM breakpoints available in server processors
are not contemplated, but that is out of the scope of this work.
ptrace will return an integer (handle) uniquely identifying the breakpoint or
watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
request to ask for its removal. Return -ENOSPC if the requested breakpoint
can't be allocated on the registers.
Some examples of using the structure to:
- set a breakpoint in the first breakpoint register
p.version = PPC_DEBUG_CURRENT_VERSION;
p.trigger_type= PPC_BREAKPOINT_TRIGGER_EXECUTE;
p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
p.addr= (uint64_t) address;
p.addr2 = 0;
p.condition_value = 0;
- set a watchpoint which triggers on reads in the second watchpoint register
p.version = PPC_DEBUG_CURRENT_VERSION;
p.trigger_type= PPC_BREAKPOINT_TRIGGER_READ;
p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
p.addr= (uint64_t) address;
p.addr2 = 0;
p.condition_value = 0;
- set a watchpoint which triggers only with a specific value
p.ver
[RFC:PATCH 01/03] powerpc: Extended ptrace interface
powerpc: Extended ptrace interface
From: Torez Smith
Add a new extended ptrace interface so that user-space has a single
interface for powerpc, without having to know the specific layout
of the debug registers.
Implement:
PPC_PTRACE_GETHWDEBUGINFO
PPC_PTRACE_SETHWDEBUG
PPC_PTRACE_DELHWDEBUG
Signed-off-by: Dave Kleikamp
Signed-off-by: Torez Smith
Cc: Benjamin Herrenschmidt
Cc: Thiago Jung Bauermann
Cc: Sergio Durigan Junior
Cc: David Gibson
Cc: linuxppc-dev list
---
arch/powerpc/include/asm/ptrace.h | 75
arch/powerpc/kernel/ptrace.c | 88 +
2 files changed, 163 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h
b/arch/powerpc/include/asm/ptrace.h
index 8c34149..7ae887b 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -24,6 +24,12 @@
* 2 of the License, or (at your option) any later version.
*/
+#ifdef __KERNEL__
+#include
+#else
+#include
+#endif
+
#ifndef __ASSEMBLY__
struct pt_regs {
@@ -292,4 +298,73 @@ extern void user_disable_single_step(struct task_struct *);
#define PTRACE_SINGLEBLOCK 0x100 /* resume execution until next branch */
+#define PPC_PTRACE_GETHWDBGINFO0x89
+#define PPC_PTRACE_SETHWDEBUG 0x88
+#define PPC_PTRACE_DELHWDEBUG 0x87
+
+#ifndef __ASSEMBLY__
+
+struct ppc_debug_info {
+ uint32_t version; /* Only version 1 exists to date */
+ uint32_t num_instruction_bps;
+ uint32_t num_data_bps;
+ uint32_t num_condition_regs;
+ uint32_t data_bp_alignment;
+ uint32_t sizeof_condition; /* size of the DVC register */
+ uint64_t features;
+};
+
+#endif /* __ASSEMBLY__ */
+
+/*
+ * features will have bits indication whether there is support for:
+ */
+#define PPC_DEBUG_FEATURE_INSN_BP_RANGE0x1
+#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
+#define PPC_DEBUG_FEATURE_DATA_BP_RANGE0x4
+#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
+
+#ifndef __ASSEMBLY__
+
+struct ppc_hw_breakpoint {
+ uint32_t version; /* currently, version must be 1 */
+ uint32_t trigger_type; /* only some combinations allowed */
+ uint32_t addr_mode; /* address match mode */
+ uint32_t condition_mode;/* break/watchpoint condition flags */
+ uint64_t addr; /* break/watchpoint address */
+ uint64_t addr2; /* range end or mask */
+ uint64_t condition_value; /* contents of the DVC register */
+};
+
+#endif /* __ASSEMBLY__ */
+
+/*
+ * Trigger Type
+ */
+#define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x1
+#define PPC_BREAKPOINT_TRIGGER_READ0x2
+#define PPC_BREAKPOINT_TRIGGER_WRITE 0x4
+#define PPC_BREAKPOINT_TRIGGER_RW 0x6
+
+/*
+ * Address Mode
+ */
+#define PPC_BREAKPOINT_MODE_EXACT 0x0
+#define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE0x1
+#define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE0x2
+#define PPC_BREAKPOINT_MODE_MASK 0x3
+
+/*
+ * Condition Mode
+ */
+#define PPC_BREAKPOINT_CONDITION_NONE 0x0
+#define PPC_BREAKPOINT_CONDITION_AND 0x1
+#define PPC_BREAKPOINT_CONDITION_EXACT 0x1
+#define PPC_BREAKPOINT_CONDITION_OR0x2
+#define PPC_BREAKPOINT_CONDITION_AND_OR0x3
+#define PPC_BREAKPOINT_CONDITION_BE_ALL0x00ff
+#define PPC_BREAKPOINT_CONDITION_BE_SHIFT 16
+#define PPC_BREAKPOINT_CONDITION_BE(n) \
+ (1<<((n)+PPC_BREAKPOINT_CONDITION_BE_SHIFT))
+
#endif /* _ASM_POWERPC_PTRACE_H */
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index ef14988..6be2ce0 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -839,6 +839,50 @@ void ptrace_disable(struct task_struct *child)
user_disable_single_step(child);
}
+static long ppc_set_hwdebug(struct task_struct *child,
+struct ppc_hw_breakpoint *bp_info)
+{
+ /*
+* We currently support one data breakpoint
+*/
+ if (((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0) ||
+ ((bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0) ||
+ (bp_info->trigger_type != PPC_BREAKPOINT_TRIGGER_WRITE) ||
+ (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) ||
+ (bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE))
+ return -EINVAL;
+
+ if (child->thread.dabr)
+ return -ENOSPC;
+
+ if ((unsigned long)bp_info->addr >= TASK_SIZE)
+ return -EIO;
+
+ child->thread.dabr = (unsigned long)bp_info->addr;
+#ifdef CONFIG_BOOKE
+ child->thread.dbcr0 = DBCR0_IDM;
+ if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ)
+ child->thread.dbcr0 |= DBSR_DAC1R;
+ if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
+ child->thread.dbcr0 |= DBSR_DAC1W;
+ child->thread.regs->
[RFC:PATCH 02/03] powerpc: Add definitions for Debug Registers on BookE Platforms
powerpc: Add definitions for Debug Registers on BookE Platforms
From: Torez Smith
This patch adds additional definitions for BookE Debug Registers
to the reg_booke.h header file.
Signed-off-by: Torez Smith
Signed-off-by: Dave Kleikamp
Cc: Benjamin Herrenschmidt
Cc: Thiago Jung Bauermann
Cc: Sergio Durigan Junior
Cc: David Gibson
Cc: linuxppc-dev list
---
arch/powerpc/include/asm/processor.h | 30 +-
arch/powerpc/include/asm/reg_booke.h | 176 +-
2 files changed, 178 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index 9eed29e..1393307 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -161,9 +161,35 @@ struct thread_struct {
#ifdef CONFIG_PPC32
void*pgdir; /* root of page-table tree */
#endif
-#if defined(CONFIG_4xx) || defined (CONFIG_BOOKE)
- unsigned long dbcr0; /* debug control register values */
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ /*
+* The following help to manage the use of Debug Control Registers
+* om the BookE platforms.
+*/
+ unsigned long dbcr0;
unsigned long dbcr1;
+ unsigned long dbcr2;
+ /*
+* The stored value of the DBSR register will be the value at the
+* last debug interrupt. This register can only be read from the
+* user (will never be written to) and has value while helping to
+* describe the reason for the last debug trap. Torez
+*/
+ unsigned long dbsr;
+ /*
+* The following will contain addresses used by debug applications
+* to help trace and trap on particular address locations.
+* The bits in the Debug Control Registers above help define which
+* of the following registers will contain valid data and/or addresses.
+*/
+ unsigned long iac1;
+ unsigned long iac2;
+ unsigned long iac3;
+ unsigned long iac4;
+ unsigned long dac1;
+ unsigned long dac2;
+ unsigned long dvc1;
+ unsigned long dvc2;
#endif
/* FP and VSX 0-31 register set */
double fpr[32][TS_FPRWIDTH];
diff --git a/arch/powerpc/include/asm/reg_booke.h
b/arch/powerpc/include/asm/reg_booke.h
index 3bf7835..7f8c71f 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -248,6 +248,8 @@
#define DBSR_RET 0x8000 /* Return Debug Event */
#define DBSR_CIRPT 0x0040 /* Critical Interrupt Taken Event */
#define DBSR_CRET 0x0020 /* Critical Return Debug Event */
+#define DBSR_IAC12ATS 0x0002 /* Instr Address Compare 1/2 Toggle */
+#define DBSR_IAC34ATS 0x0001 /* Instr Address Compare 3/4 Toggle */
#endif
#ifdef CONFIG_40x
#define DBSR_IC0x8000 /* Instruction Completion */
@@ -294,25 +296,68 @@
#define DBCR0_IC 0x0800 /* Instruction Completion */
#define DBCR0_ICMP DBCR0_IC
#define DBCR0_BT 0x0400 /* Branch Taken */
-#define DBCR0_BRT DBCR0_BT
#define DBCR0_EDE 0x0200 /* Exception Debug Event */
#define DBCR0_IRPT DBCR0_EDE
#define DBCR0_TDE 0x0100 /* TRAP Debug Event */
-#define DBCR0_IA1 0x0080 /* Instr Addr compare 1 enable */
-#define DBCR0_IAC1 DBCR0_IA1
-#define DBCR0_IA2 0x0040 /* Instr Addr compare 2 enable */
-#define DBCR0_IAC2 DBCR0_IA2
-#define DBCR0_IA12 0x0020 /* Instr Addr 1-2 range enable */
-#define DBCR0_IA12X0x0010 /* Instr Addr 1-2 range eXclusive */
-#define DBCR0_IA3 0x0008 /* Instr Addr compare 3 enable */
-#define DBCR0_IAC3 DBCR0_IA3
-#define DBCR0_IA4 0x0004 /* Instr Addr compare 4 enable */
-#define DBCR0_IAC4 DBCR0_IA4
-#define DBCR0_IA34 0x0002 /* Instr Addr 3-4 range Enable */
-#define DBCR0_IA34X0x0001 /* Instr Addr 3-4 range eXclusive */
-#define DBCR0_IA12T0x8000 /* Instr Addr 1-2 range Toggle */
-#define DBCR0_IA34T0x4000 /* Instr Addr 3-4 range Toggle */
+#define DBCR0_IAC1 0x0080 /* Instr Addr compare 1 enable */
+#define DBCR0_IAC2 0x0040 /* Instr Addr compare 2 enable */
+#define DBCR0_IAC12M 0x0030 /* Instr Addr 1-2 range enable */
+#define DBCR0_IAC12M_R 0x0010 /* Instr Addr 1-2 Reserved state */
+#define DBCR0_IAC12M_I 0x0020 /* Instr Addr 1-2 range Inclusive */
+#define DBCR0_IAC12M_X 0x0030 /* Instr Addr 1-2 range eXclusive */
+#define DBCR0_IAC3 0x0008 /* Instr Addr compare 3 enable */
+#define DBCR0_IAC4 0x0004 /* Instr Addr compare 4 enable */
+#define DBCR0_IAC340x0002 /* Instr Addr 3-4 range Enable */
+#define DBCR0_IAC34X 0x0001 /* Instr Addr 3
[RFC:PATCH 03/03] powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
From: Torez Smith
This patch defines context switch and trap related functionality
for BookE specific Debug Registers. It adds support to ptrace()
for setting and getting BookE related Debug Registers
Signed-off-by: Torez Smith
Signed-off-by: Dave Kleikamp
Cc: Benjamin Herrenschmidt
Cc: Thiago Jung Bauermann
Cc: Sergio Durigan Junior
Cc: David Gibson
Cc: linuxppc-dev list
---
arch/powerpc/include/asm/system.h |2
arch/powerpc/kernel/process.c | 109 -
arch/powerpc/kernel/ptrace.c | 435 ++---
arch/powerpc/kernel/signal.c |6 -
arch/powerpc/kernel/signal_32.c |8 +
arch/powerpc/kernel/traps.c | 86 ++-
6 files changed, 564 insertions(+), 82 deletions(-)
diff --git a/arch/powerpc/include/asm/system.h
b/arch/powerpc/include/asm/system.h
index bb8e006..474bf23 100644
--- a/arch/powerpc/include/asm/system.h
+++ b/arch/powerpc/include/asm/system.h
@@ -114,6 +114,8 @@ static inline int debugger_fault_handler(struct pt_regs
*regs) { return 0; }
extern int set_dabr(unsigned long dabr);
extern void do_dabr(struct pt_regs *regs, unsigned long address,
unsigned long error_code);
+extern void do_send_trap(struct pt_regs *regs, unsigned long address,
+unsigned long error_code, int signal_code, int errno);
extern void print_backtrace(unsigned long *);
extern void show_regs(struct pt_regs * regs);
extern void flush_instruction_cache(void);
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index c930ac3..a0dbb09 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -245,6 +245,24 @@ void discard_lazy_cpu_state(void)
}
#endif /* CONFIG_SMP */
+void do_send_trap(struct pt_regs *regs, unsigned long address,
+ unsigned long error_code, int signal_code, int errno)
+{
+ siginfo_t info;
+
+ if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
+ 11, SIGSEGV) == NOTIFY_STOP)
+ return;
+
+ /* Deliver the signal to userspace */
+ info.si_signo = SIGTRAP;
+ info.si_errno = errno;
+ info.si_code = signal_code;
+ info.si_addr = (void __user *)address;
+ force_sig_info(SIGTRAP, &info, current);
+}
+
+#if !(defined(CONFIG_40x) || defined(CONFIG_BOOKE))
void do_dabr(struct pt_regs *regs, unsigned long address,
unsigned long error_code)
{
@@ -257,12 +275,6 @@ void do_dabr(struct pt_regs *regs, unsigned long address,
if (debugger_dabr_match(regs))
return;
- /* Clear the DAC and struct entries. One shot trigger */
-#if defined(CONFIG_BOOKE)
- mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBSR_DAC1R | DBSR_DAC1W
- | DBCR0_IDM));
-#endif
-
/* Clear the DABR */
set_dabr(0);
@@ -273,9 +285,71 @@ void do_dabr(struct pt_regs *regs, unsigned long address,
info.si_addr = (void __user *)address;
force_sig_info(SIGTRAP, &info, current);
}
+#endif
static DEFINE_PER_CPU(unsigned long, current_dabr);
+#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
+/*
+ * Set the debug registers back to their default "safe" values.
+ */
+static void set_debug_reg_defaults(struct thread_struct *thread)
+{
+ thread->iac1 = thread->iac2 = thread->iac3 = thread->iac4 = 0;
+ thread->dac1 = thread->dac2 = 0;
+ thread->dvc1 = thread->dvc2 = 0;
+ /*
+* reset the DBCR0, DBCR1 and DBCR2 registers. All bits with
+* the exception of the reserved bits should be cleared out
+* and set to 0.
+*
+* For the DBCR0 register, the reserved bits are bits 17:30.
+* Reserved bits for DBCR1 are bits 10:14 and bits 26:30.
+* And, bits 10:11 for DBCR2.
+*/
+ thread->dbcr0 = DBCR0_BASE_REG_VALUE;
+ /*
+* First clear all "non reserved" bits from DBCR1 then initialize reg
+* to force User/Supervisor bits to b11 (user-only MSR[PR]=1) and
+* Effective/Real * bits to b10 (trap only if IS==0)
+*/
+ thread->dbcr1 = DBCR1_BASE_REG_VALUE;
+ /*
+* Force Data Address Compare User/Supervisor bits to be User-only
+* (0b11 MSR[PR]=1) and set all other bits in DBCR2 register to be 0.
+* This sets the Data Address Compare Effective/Real bits to be 0b00
+* (Effective, MSR[DS]=don't care).
+*/
+ thread->dbcr2 = DBCR2_BASE_REG_VALUE;
+}
+
+static void prime_debug_regs(struct thread_struct *thread)
+{
+ mtspr(SPRN_IAC1, thread->iac1);
+ mtspr(SPRN_IAC2, thread->iac2);
+ mtspr(SPRN_IAC3, thread->iac3);
+ mtspr(SPRN_IAC4, thread->iac4);
+ mtspr(SPRN_DAC1, thread->dac1);
+ mtspr(SPRN_DAC2, thread->dac2);
+ mtspr(SPRN_DVC1, thread->dvc1);
+ mtspr(SPRN_DVC2, thr
[ibm_emac] rx_dropped_stack
Hi all, I am using linux version 2.6.25.20 on cpu : 440GRX revision: 24.212 (pvr 2162 18d4) bogomips: 995.32 vendor : AMCC machine : PPC440EPx LWMON5 I am using ethtool to read out NIC statistics. On every tested board I saw the counter increasing for 'rx_dropped_stack', on some boards also for 'rx_bd_errors', 'rx_bd_bad_fcs' and on few boards for 'tx_underrun' or 'tx_dropped'. Can you help me interpret those values? Which values are nice for information, which are really bad? thanks in advance, Stephan Liebherr-Werk Ehingen GmbH Dr.-Hans-Liebherr-Str. 1 89584 Ehingen E-Mail: stephan.br...@liebherr.com Internet: http://www.liebherr.com Vorsitzender des Aufsichtsrats: Dipl.-Volksw. Henning Rapp Geschäftsführer: Dr.-Ing. Ulrich Hamme, Dr.-Ing. Hubert Hummel, Dipl.-Ing. (FH) Christoph Kleiner, Dipl.-Kfm. Mario Trunzer Sitz: 89584 Ehingen/Donau, Amtsgericht Ulm/Donau, HRB 490123, Ust-Id. Nr.: DE 811120093 liebherrb2b...@il ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Ping does not work on my MPC8544 board, using linux2.6.23
2009/12/10 Scott Wood > 林志平 wrote: > >> > Another question is that I found linux2.6.31 does not support >> > board mpc8544ds, >> >>It should. What problems do you see? >> >> => bootm 0x100 0x180 0x80 >> ## Booting kernel from Legacy Image at 0100 ... >> Image Name: Linux-2.6.31 >> Image Type: PowerPC Linux Kernel Image (gzip compressed) >> Data Size:2185099 Bytes = 2.1 MB >> Load Address: >> Entry Point: >> Verifying Checksum ... OK >> ## Loading init Ramdisk from Legacy Image at 0180 ... >> Image Name: Simple Embedded Linux Framework >> Image Type: PowerPC Linux RAMDisk Image (gzip compressed) >> Data Size:1859256 Bytes = 1.8 MB >> Load Address: >> Entry Point: >> Verifying Checksum ... OK >> ## Flattened Device Tree blob at 0080 >> Booting using the fdt blob at 0x80 >> Uncompressing Kernel Image ... OK >> Loading Ramdisk to 1fca7000, end 1fe6ceb8 ... OK >> booting kernel using flat tree >> It then stops and never print any more, I use mpc85xx_defconfig, I select >> mpc85xxds in the menuconfig and deselect other options like mpc8540ads etc. >> > > Are you using the mpc8544ds device tree from 2.6.31, unchanged? Try > turning on CONFIG_PPC_EARLY_DEBUG. > > No need to deselect the others, BTW. >Does mpc85xx_defconfig not work? >> >> Yes mcp85xx_defconfig does not work, I can see mpc8540ads in the >> menuconfig, but no mpc8544ds. >> > > mpc8544ds is supported by CONFIG_MPC85xx_DS. > CONFIG_MPC85XX_DS does not exist. Only mpc85xx_defconfig in > arch/powerpc/configs > -Scott > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
On Thu, 10 Dec 2009 09:43:38 -0600
James Bottomley wrote:
> On Wed, 2009-12-02 at 17:51 -0800, Pravin Bathija wrote:
> > Powerpc 44x uses 36 bit real address while the real address defined
> > in MPT Fusion driver is of type 32 bit. This causes ioremap to fail and
> > driver
> > fails to initialize. This fix changes the data types representing the
> > real
> > address from unsigned long 32-bit types to resource_size_t which is
> > 64-bit. The
> > driver has been tested, the disks get discovered correctly and can do
> > IO.
> >
> > Signed-off-by: Pravin Bathija
> > Acked-by: Feng Kan
> > Acked-by: Fushen Chen
> > Acked-by: Loc Ho
> > Acked-by: Tirumala Reddy Marri
> > Acked-by: Victor Gallardo
> > ---
> > drivers/message/fusion/mptbase.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/message/fusion/mptbase.c
> > b/drivers/message/fusion/mptbase.c
> > index 5d496a9..9f14a60 100644
> > --- a/drivers/message/fusion/mptbase.c
> > +++ b/drivers/message/fusion/mptbase.c
> > @@ -1511,7 +1511,7 @@ mpt_mapresources(MPT_ADAPTER *ioc)
> > {
> > u8 __iomem *mem;
> > int ii;
> > - unsigned longmem_phys;
> > + resource_size_t mem_phys;
>
> You never actually compiled this, did you?
>
> drivers/message/fusion/mptbase.c: In function 'mpt_mapresources':
> drivers/message/fusion/mptbase.c:1680: warning: format '%lx' expects type
> 'long unsigned int', but argument 4 has type 'resource_size_t'
>
> I'll just fold the fix in
another patch (inlined below) should probably also go in as 'mem_phys' is
assigned to ioc->mem_phys which is 'u32'. ioc->mem_phys is never used in
the driver, however.
Some time ago I posted a patch which enables using second LSI SAS HBA on
PPC440SPe based katmai board again:
http://thread.gmane.org/gmane.linux.scsi/54839
Could someone comment on this patch, please. Thanks!
Anatolij
---
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index 8dd4d21..8dc58e3 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -605,7 +605,7 @@ typedef struct _MPT_ADAPTER
SYSIF_REGS __iomem *chip; /* == c8817000 (mmap) */
SYSIF_REGS __iomem *pio_chip; /* Programmed IO (downloadboot)
*/
u8 bus_type;
- u32 mem_phys; /* == f402 (mmap) */
+ resource_size_t mem_phys; /* == f402 (mmap) */
u32 pio_mem_phys; /* Programmed IO (downloadboot)
*/
int mem_size; /* mmap memory size */
int number_of_buses;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 02/03] powerpc: Add definitions for Debug Registers on BookE Platforms
On Thu, Dec 10, 2009 at 01:57:21PM -0200, Dave Kleikamp wrote:
>diff --git a/arch/powerpc/include/asm/processor.h
>b/arch/powerpc/include/asm/processor.h
>index 9eed29e..1393307 100644
>--- a/arch/powerpc/include/asm/processor.h
>+++ b/arch/powerpc/include/asm/processor.h
>@@ -161,9 +161,35 @@ struct thread_struct {
> #ifdef CONFIG_PPC32
> void*pgdir; /* root of page-table tree */
> #endif
>-#if defined(CONFIG_4xx) || defined (CONFIG_BOOKE)
>- unsigned long dbcr0; /* debug control register values */
>+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
>+ /*
>+ * The following help to manage the use of Debug Control Registers
>+ * om the BookE platforms.
>+ */
>+ unsigned long dbcr0;
> unsigned long dbcr1;
>+ unsigned long dbcr2;
This is wrong for 405. 405 only has dbcr0 and dbcr1. I don't see why you'd
change the #define values to be more explicit and then include things that
don't make sense.
>+ /*
>+ * The stored value of the DBSR register will be the value at the
>+ * last debug interrupt. This register can only be read from the
>+ * user (will never be written to) and has value while helping to
>+ * describe the reason for the last debug trap. Torez
>+ */
>+ unsigned long dbsr;
>+ /*
>+ * The following will contain addresses used by debug applications
>+ * to help trace and trap on particular address locations.
>+ * The bits in the Debug Control Registers above help define which
>+ * of the following registers will contain valid data and/or addresses.
>+ */
>+ unsigned long iac1;
>+ unsigned long iac2;
>+ unsigned long iac3;
>+ unsigned long iac4;
>+ unsigned long dac1;
>+ unsigned long dac2;
>+ unsigned long dvc1;
>+ unsigned long dvc2;
> #endif
Without digging much, I'm wondering if we could just use a pointer to a debug
register structure here instead of growing struct thread more.
> /* FP and VSX 0-31 register set */
> double fpr[32][TS_FPRWIDTH];
>diff --git a/arch/powerpc/include/asm/reg_booke.h
>b/arch/powerpc/include/asm/reg_booke.h
>index 3bf7835..7f8c71f 100644
>--- a/arch/powerpc/include/asm/reg_booke.h
>+++ b/arch/powerpc/include/asm/reg_booke.h
>@@ -248,6 +248,8 @@
> #define DBSR_RET 0x8000 /* Return Debug Event */
> #define DBSR_CIRPT0x0040 /* Critical Interrupt Taken Event */
> #define DBSR_CRET 0x0020 /* Critical Return Debug Event */
>+#define DBSR_IAC12ATS 0x0002 /* Instr Address Compare 1/2 Toggle */
>+#define DBSR_IAC34ATS 0x0001 /* Instr Address Compare 3/4 Toggle */
> #endif
> #ifdef CONFIG_40x
> #define DBSR_IC 0x8000 /* Instruction Completion */
>@@ -294,25 +296,68 @@
> #define DBCR0_IC 0x0800 /* Instruction Completion */
> #define DBCR0_ICMPDBCR0_IC
> #define DBCR0_BT 0x0400 /* Branch Taken */
>-#define DBCR0_BRT DBCR0_BT
> #define DBCR0_EDE 0x0200 /* Exception Debug Event */
> #define DBCR0_IRPTDBCR0_EDE
> #define DBCR0_TDE 0x0100 /* TRAP Debug Event */
>-#define DBCR0_IA1 0x0080 /* Instr Addr compare 1 enable */
>-#define DBCR0_IAC1DBCR0_IA1
>-#define DBCR0_IA2 0x0040 /* Instr Addr compare 2 enable */
>-#define DBCR0_IAC2DBCR0_IA2
>-#define DBCR0_IA120x0020 /* Instr Addr 1-2 range enable */
>-#define DBCR0_IA12X 0x0010 /* Instr Addr 1-2 range eXclusive */
>-#define DBCR0_IA3 0x0008 /* Instr Addr compare 3 enable */
>-#define DBCR0_IAC3DBCR0_IA3
>-#define DBCR0_IA4 0x0004 /* Instr Addr compare 4 enable */
>-#define DBCR0_IAC4DBCR0_IA4
>-#define DBCR0_IA340x0002 /* Instr Addr 3-4 range Enable */
>-#define DBCR0_IA34X 0x0001 /* Instr Addr 3-4 range eXclusive */
>-#define DBCR0_IA12T 0x8000 /* Instr Addr 1-2 range Toggle */
>-#define DBCR0_IA34T 0x4000 /* Instr Addr 3-4 range Toggle */
>+#define DBCR0_IAC10x0080 /* Instr Addr compare 1 enable */
>+#define DBCR0_IAC20x0040 /* Instr Addr compare 2 enable */
>+#define DBCR0_IAC12M 0x0030 /* Instr Addr 1-2 range enable */
>+#define DBCR0_IAC12M_R0x0010 /* Instr Addr 1-2 Reserved
>state */
>+#define DBCR0_IAC12M_I0x0020 /* Instr Addr 1-2 range
>Inclusive */
>+#define DBCR0_IAC12M_X0x0030 /* Instr Addr 1-2 range
>eXclusive */
>+#define DBCR0_IAC30x0008 /* Instr Addr compare 3 enable */
>+#define DBCR0_IAC40x0004 /* Instr Addr compare 4 enable */
>+#define DBCR0_IAC34 0x0002 /* Instr Addr 3-4 range Enable */
>+#define DBCR0_IAC34X 0x0001 /* Instr Addr 3-4 range eXclusive */
>+#define DBCR0_IAC12T 0x8000 /* Instr Addr 1-2 range Toggle */
>+#define DBCR0_IAC34T 0x400
Re: [RFC:PATCH 03/03] powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
On Thu, Dec 10, 2009 at 01:57:27PM -0200, Dave Kleikamp wrote:
>powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
>
>From: Torez Smith
>
>This patch defines context switch and trap related functionality
>for BookE specific Debug Registers. It adds support to ptrace()
>for setting and getting BookE related Debug Registers
>
>Signed-off-by: Torez Smith
>Signed-off-by: Dave Kleikamp
>Cc: Benjamin Herrenschmidt
>Cc: Thiago Jung Bauermann
>Cc: Sergio Durigan Junior
>Cc: David Gibson
>Cc: linuxppc-dev list
>---
>
> arch/powerpc/include/asm/system.h |2
> arch/powerpc/kernel/process.c | 109 -
> arch/powerpc/kernel/ptrace.c | 435 ++---
> arch/powerpc/kernel/signal.c |6 -
> arch/powerpc/kernel/signal_32.c |8 +
> arch/powerpc/kernel/traps.c | 86 ++-
> 6 files changed, 564 insertions(+), 82 deletions(-)
>
>
>diff --git a/arch/powerpc/include/asm/system.h
>b/arch/powerpc/include/asm/system.h
>index bb8e006..474bf23 100644
>--- a/arch/powerpc/include/asm/system.h
>+++ b/arch/powerpc/include/asm/system.h
>@@ -114,6 +114,8 @@ static inline int debugger_fault_handler(struct pt_regs
>*regs) { return 0; }
> extern int set_dabr(unsigned long dabr);
> extern void do_dabr(struct pt_regs *regs, unsigned long address,
> unsigned long error_code);
>+extern void do_send_trap(struct pt_regs *regs, unsigned long address,
>+ unsigned long error_code, int signal_code, int errno);
> extern void print_backtrace(unsigned long *);
> extern void show_regs(struct pt_regs * regs);
> extern void flush_instruction_cache(void);
>diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
>index c930ac3..a0dbb09 100644
>--- a/arch/powerpc/kernel/process.c
>+++ b/arch/powerpc/kernel/process.c
>@@ -245,6 +245,24 @@ void discard_lazy_cpu_state(void)
> }
> #endif /* CONFIG_SMP */
>
>+void do_send_trap(struct pt_regs *regs, unsigned long address,
>+unsigned long error_code, int signal_code, int errno)
>+{
>+ siginfo_t info;
>+
>+ if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
>+ 11, SIGSEGV) == NOTIFY_STOP)
>+ return;
>+
>+ /* Deliver the signal to userspace */
>+ info.si_signo = SIGTRAP;
>+ info.si_errno = errno;
>+ info.si_code = signal_code;
>+ info.si_addr = (void __user *)address;
>+ force_sig_info(SIGTRAP, &info, current);
>+}
>+
>+#if !(defined(CONFIG_40x) || defined(CONFIG_BOOKE))
> void do_dabr(struct pt_regs *regs, unsigned long address,
> unsigned long error_code)
> {
>@@ -257,12 +275,6 @@ void do_dabr(struct pt_regs *regs, unsigned long address,
> if (debugger_dabr_match(regs))
> return;
>
>- /* Clear the DAC and struct entries. One shot trigger */
>-#if defined(CONFIG_BOOKE)
>- mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBSR_DAC1R | DBSR_DAC1W
>- | DBCR0_IDM));
>-#endif
>-
> /* Clear the DABR */
> set_dabr(0);
>
>@@ -273,9 +285,71 @@ void do_dabr(struct pt_regs *regs, unsigned long address,
> info.si_addr = (void __user *)address;
> force_sig_info(SIGTRAP, &info, current);
> }
>+#endif
>
> static DEFINE_PER_CPU(unsigned long, current_dabr);
>
>+#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
>+/*
>+ * Set the debug registers back to their default "safe" values.
>+ */
>+static void set_debug_reg_defaults(struct thread_struct *thread)
>+{
>+ thread->iac1 = thread->iac2 = thread->iac3 = thread->iac4 = 0;
>+ thread->dac1 = thread->dac2 = 0;
>+ thread->dvc1 = thread->dvc2 = 0;
>+ /*
>+ * reset the DBCR0, DBCR1 and DBCR2 registers. All bits with
>+ * the exception of the reserved bits should be cleared out
>+ * and set to 0.
>+ *
>+ * For the DBCR0 register, the reserved bits are bits 17:30.
>+ * Reserved bits for DBCR1 are bits 10:14 and bits 26:30.
>+ * And, bits 10:11 for DBCR2.
>+ */
>+ thread->dbcr0 = DBCR0_BASE_REG_VALUE;
>+ /*
>+ * First clear all "non reserved" bits from DBCR1 then initialize reg
>+ * to force User/Supervisor bits to b11 (user-only MSR[PR]=1) and
>+ * Effective/Real * bits to b10 (trap only if IS==0)
>+ */
>+ thread->dbcr1 = DBCR1_BASE_REG_VALUE;
>+ /*
>+ * Force Data Address Compare User/Supervisor bits to be User-only
>+ * (0b11 MSR[PR]=1) and set all other bits in DBCR2 register to be 0.
>+ * This sets the Data Address Compare Effective/Real bits to be 0b00
>+ * (Effective, MSR[DS]=don't care).
>+ */
>+ thread->dbcr2 = DBCR2_BASE_REG_VALUE;
>+}
>+
>+static void prime_debug_regs(struct thread_struct *thread)
>+{
>+ mtspr(SPRN_IAC1, thread->iac1);
>+ mtspr(SPRN_IAC2, thread->iac2);
>+ mtspr(SPRN_IAC3, thread->iac3);
>+ mtspr(SPRN_IAC4, thread->iac4);
>+ mtsp
Re: Ping does not work on my MPC8544 board, using linux2.6.23
林志平 wrote: Yes mcp85xx_defconfig does not work, I can see mpc8540ads in the menuconfig, but no mpc8544ds. mpc8544ds is supported by CONFIG_MPC85xx_DS. CONFIG_MPC85XX_DS does not exist. Only mpc85xx_defconfig in arch/powerpc/configs I'm looking right at it, in arch/powerpc/platforms/85xx/Kconfig in 2.6.31. mpc85xx_defconfig selects this option. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/5] More unreachable() conversions.
Back in commit 38938c879eb0c39edf85d5164aa0cffe2874304c the new macro unreachable() was added. We can use it in BUG instead of a variety of ad hoc endless loops. This patch set consists of the patches from the original set that were never Acked-by anyone. Although they are completely untested, they seem plausible. I don't plan on pushing these things out any more, so if you like them please merge them via your architecture trees. I will reply with the 5 patches. David Daney (5): mn10300: Convert BUG() to use unreachable() parisc: Convert BUG() to use unreachable() powerpc: Convert BUG() to use unreachable() alpha: Convert BUG() to use unreachable() blackfin: Convert BUG() to use unreachable() arch/alpha/include/asm/bug.h|3 ++- arch/blackfin/include/asm/bug.h |2 +- arch/mn10300/include/asm/bug.h |3 ++- arch/parisc/include/asm/bug.h |4 ++-- arch/powerpc/include/asm/bug.h |2 +- 5 files changed, 8 insertions(+), 6 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/5] powerpc: Convert BUG() to use unreachable()
Use the new unreachable() macro instead of for(;;);
Signed-off-by: David Daney
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: linuxppc-...@ozlabs.org
---
arch/powerpc/include/asm/bug.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index 64e1fdc..2c15212 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -68,7 +68,7 @@
_EMIT_BUG_ENTRY \
: : "i" (__FILE__), "i" (__LINE__), \
"i" (0), "i" (sizeof(struct bug_entry))); \
- for(;;) ; \
+ unreachable(); \
} while (0)
#define BUG_ON(x) do { \
--
1.6.2.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 03/03] powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
On Thu, Dec 10, 2009 at 12:27:11PM -0500, Josh Boyer wrote:
>On Thu, Dec 10, 2009 at 01:57:27PM -0200, Dave Kleikamp wrote:
>>+static void prime_debug_regs(struct thread_struct *thread)
>>+{
>>+ mtspr(SPRN_IAC1, thread->iac1);
>>+ mtspr(SPRN_IAC2, thread->iac2);
>>+ mtspr(SPRN_IAC3, thread->iac3);
>>+ mtspr(SPRN_IAC4, thread->iac4);
>>+ mtspr(SPRN_DAC1, thread->dac1);
>>+ mtspr(SPRN_DAC2, thread->dac2);
>>+ mtspr(SPRN_DVC1, thread->dvc1);
>>+ mtspr(SPRN_DVC2, thread->dvc2);
>>+ mtspr(SPRN_DBCR0, thread->dbcr0);
>>+ mtspr(SPRN_DBCR1, thread->dbcr1);
>>+ mtspr(SPRN_DBCR2, thread->dbcr2);
>
>405 has no DBCR2, so I doubt setting it via mtspr would be good. Does this
>compile for 40x and did you test it at all?
>
>Also, looking at the current kernel it seems SPRN_DBCR2 is only defined for
>CONFIG_PPC_BOOK3E_64 which is also inaccurate.
I mis-read the code on this part. SPRN_DBCR2 gets defined unconditionally,
so Book-E should be fine. Still seems broken on 405 though.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] cpm2_pic: Allow correct flow_types for port C interrupts
Anton Vorontsov wrote: On Thu, Dec 10, 2009 at 08:52:01AM -0600, Kumar Gala wrote: On Dec 10, 2009, at 5:14 AM, Mark Ware wrote: Port C interrupts can be either falling edge, or either edge. Other external interrupts are either falling edge or active low. Tested on a custom 8280 based board. Signed-off-by: Mark Ware --- Changed in v3: - Cosmetic improvements as suggested by Anton and Scott - Added tested note to changelog arch/powerpc/sysdev/cpm2_pic.c | 28 +--- 1 files changed, 21 insertions(+), 7 deletions(-) Scott, Anton do you want to add an Ack to this version? Acked-by: Anton Vorontsov Acked-by: Scott Wood -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/3] powerpc/83xx: Sleep and deep sleep support for MPC8315E-RDB
Hi all, This is quite late resend, sorry. Only the third patch has changed, i.e. I got rid of sleep-nexus stuff per Scott and Benjamin suggestions. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] powerpc/83xx/suspend: Clear deep_sleeping after devices resume
Currently 83xx PMC driver clears deep_sleeping variable very early,
before devices are resumed. This makes fsl_deep_sleep() unusable in
drivers' resume() callback.
Sure, drivers can store fsl_deep_sleep() value on suspend and use
the stored value on resume. But a better solution is to postpone
clearing the deep_sleeping variable, i.e. move it into finish()
callback.
Signed-off-by: Anton Vorontsov
Acked-by: Scott Wood
---
arch/powerpc/platforms/83xx/suspend.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/suspend.c
b/arch/powerpc/platforms/83xx/suspend.c
index d306f07..b0c2619 100644
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -194,7 +194,7 @@ out:
return ret;
}
-static void mpc83xx_suspend_finish(void)
+static void mpc83xx_suspend_end(void)
{
deep_sleeping = 0;
}
@@ -278,7 +278,7 @@ static struct platform_suspend_ops mpc83xx_suspend_ops = {
.valid = mpc83xx_suspend_valid,
.begin = mpc83xx_suspend_begin,
.enter = mpc83xx_suspend_enter,
- .finish = mpc83xx_suspend_finish,
+ .end = mpc83xx_suspend_end,
};
static int pmc_probe(struct of_device *ofdev,
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc/83xx/suspend: Save and restore SICRL, SICRH and SCCR
We need to save SICRL, SICRH and SCCR registers on suspend, and restore
them on resume. Otherwise, we lose IO and clocks setup on MPC8315E-RDB
boards when ULPI USB PHY is used (non-POR setup).
Signed-off-by: Anton Vorontsov
---
arch/powerpc/platforms/83xx/suspend.c | 48 +
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/suspend.c
b/arch/powerpc/platforms/83xx/suspend.c
index b0c2619..4380534 100644
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -32,6 +32,7 @@
#define PMCCR1_NEXT_STATE 0x0C /* Next state for power management */
#define PMCCR1_NEXT_STATE_SHIFT 2
#define PMCCR1_CURR_STATE 0x03 /* Current state for power management*/
+#define IMMR_SYSCR_OFFSET 0x100
#define IMMR_RCW_OFFSET 0x900
#define RCW_PCI_HOST0x8000
@@ -78,6 +79,22 @@ struct mpc83xx_clock {
u32 sccr;
};
+struct mpc83xx_syscr {
+ __be32 sgprl;
+ __be32 sgprh;
+ __be32 spridr;
+ __be32 :32;
+ __be32 spcr;
+ __be32 sicrl;
+ __be32 sicrh;
+};
+
+struct mpc83xx_saved {
+ u32 sicrl;
+ u32 sicrh;
+ u32 sccr;
+};
+
struct pmc_type {
int has_deep_sleep;
};
@@ -87,6 +104,8 @@ static int has_deep_sleep, deep_sleeping;
static int pmc_irq;
static struct mpc83xx_pmc __iomem *pmc_regs;
static struct mpc83xx_clock __iomem *clock_regs;
+static struct mpc83xx_syscr __iomem *syscr_regs;
+static struct mpc83xx_saved saved_regs;
static int is_pci_agent, wake_from_pci;
static phys_addr_t immrbase;
static int pci_pm_state;
@@ -137,6 +156,20 @@ static irqreturn_t pmc_irq_handler(int irq, void *dev_id)
return ret;
}
+static void mpc83xx_suspend_restore_regs(void)
+{
+ out_be32(&syscr_regs->sicrl, saved_regs.sicrl);
+ out_be32(&syscr_regs->sicrh, saved_regs.sicrh);
+ out_be32(&clock_regs->sccr, saved_regs.sccr);
+}
+
+static void mpc83xx_suspend_save_regs(void)
+{
+ saved_regs.sicrl = in_be32(&syscr_regs->sicrl);
+ saved_regs.sicrh = in_be32(&syscr_regs->sicrh);
+ saved_regs.sccr = in_be32(&clock_regs->sccr);
+}
+
static int mpc83xx_suspend_enter(suspend_state_t state)
{
int ret = -EAGAIN;
@@ -166,6 +199,8 @@ static int mpc83xx_suspend_enter(suspend_state_t state)
*/
if (deep_sleeping) {
+ mpc83xx_suspend_save_regs();
+
out_be32(&pmc_regs->mask, PMCER_ALL);
out_be32(&pmc_regs->config1,
@@ -179,6 +214,8 @@ static int mpc83xx_suspend_enter(suspend_state_t state)
in_be32(&pmc_regs->config1) & ~PMCCR1_POWER_OFF);
out_be32(&pmc_regs->mask, PMCER_PMCI);
+
+ mpc83xx_suspend_restore_regs();
} else {
out_be32(&pmc_regs->mask, PMCER_PMCI);
@@ -333,12 +370,23 @@ static int pmc_probe(struct of_device *ofdev,
goto out_pmc;
}
+ if (has_deep_sleep) {
+ syscr_regs = ioremap(immrbase + IMMR_SYSCR_OFFSET,
+sizeof(*syscr_regs));
+ if (!syscr_regs) {
+ ret = -ENOMEM;
+ goto out_syscr;
+ }
+ }
+
if (is_pci_agent)
mpc83xx_set_agent();
suspend_set_ops(&mpc83xx_suspend_ops);
return 0;
+out_syscr:
+ iounmap(clock_regs);
out_pmc:
iounmap(pmc_regs);
out:
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc/83xx: Add power management support for MPC8315E-RDB boards
- Add nodes for PMC and GTM controllers. GTM4 can be used as a wakeup
source;
- Add fsl,magic-packet properties to eTSEC nodes, i.e. wake-on-lan
support. Unlike MPC8313 processors, MPC8315 can resume from deep
sleep upon magic packet reception.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/boot/dts/mpc8315erdb.dts | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts
b/arch/powerpc/boot/dts/mpc8315erdb.dts
index 32e10f5..8a3a4f3 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -204,6 +204,7 @@
interrupt-parent = <&ipic>;
tbi-handle = <&tbi0>;
phy-handle = < &phy0 >;
+ fsl,magic-packet;
m...@520 {
#address-cells = <1>;
@@ -246,6 +247,7 @@
interrupt-parent = <&ipic>;
tbi-handle = <&tbi1>;
phy-handle = < &phy1 >;
+ fsl,magic-packet;
m...@520 {
#address-cells = <1>;
@@ -309,6 +311,22 @@
interrupt-parent = <&ipic>;
};
+ gtm1: ti...@500 {
+ compatible = "fsl,mpc8315-gtm", "fsl,gtm";
+ reg = <0x500 0x100>;
+ interrupts = <90 8 78 8 84 8 72 8>;
+ interrupt-parent = <&ipic>;
+ clock-frequency = <1>;
+ };
+
+ ti...@600 {
+ compatible = "fsl,mpc8315-gtm", "fsl,gtm";
+ reg = <0x600 0x100>;
+ interrupts = <91 8 79 8 85 8 73 8>;
+ interrupt-parent = <&ipic>;
+ clock-frequency = <1>;
+ };
+
/* IPIC
* interrupts cell =
* sense values match linux IORESOURCE_IRQ_* defines:
@@ -337,6 +355,15 @@
0x59 0x8>;
interrupt-parent = < &ipic >;
};
+
+ pmc: po...@b00 {
+ compatible = "fsl,mpc8315-pmc", "fsl,mpc8313-pmc",
+"fsl,mpc8349-pmc";
+ reg = <0xb00 0x100 0xa00 0x100>;
+ interrupts = <80 8>;
+ interrupt-parent = <&ipic>;
+ fsl,mpc8313-wakeup-timer = <>m1>;
+ };
};
pci0: p...@e0008500 {
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 03/03] powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
On Thu, 2009-12-10 at 12:41 -0500, Josh Boyer wrote:
> On Thu, Dec 10, 2009 at 12:27:11PM -0500, Josh Boyer wrote:
> >On Thu, Dec 10, 2009 at 01:57:27PM -0200, Dave Kleikamp wrote:
> >>+static void prime_debug_regs(struct thread_struct *thread)
> >>+{
> >>+ mtspr(SPRN_IAC1, thread->iac1);
> >>+ mtspr(SPRN_IAC2, thread->iac2);
> >>+ mtspr(SPRN_IAC3, thread->iac3);
> >>+ mtspr(SPRN_IAC4, thread->iac4);
> >>+ mtspr(SPRN_DAC1, thread->dac1);
> >>+ mtspr(SPRN_DAC2, thread->dac2);
> >>+ mtspr(SPRN_DVC1, thread->dvc1);
> >>+ mtspr(SPRN_DVC2, thread->dvc2);
> >>+ mtspr(SPRN_DBCR0, thread->dbcr0);
> >>+ mtspr(SPRN_DBCR1, thread->dbcr1);
> >>+ mtspr(SPRN_DBCR2, thread->dbcr2);
> >
> >405 has no DBCR2, so I doubt setting it via mtspr would be good. Does this
> >compile for 40x and did you test it at all?
> >
> >Also, looking at the current kernel it seems SPRN_DBCR2 is only defined for
> >CONFIG_PPC_BOOK3E_64 which is also inaccurate.
>
> I mis-read the code on this part. SPRN_DBCR2 gets defined unconditionally,
> so Book-E should be fine. Still seems broken on 405 though.
Agreed. I'll rushed through the 405 stuff a bit. I'll scrutinize and
test it before I post again.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/3] powerpc/83xx: Sleep and deep sleep support for MPC8315E-RDB
Anton Vorontsov wrote: Hi all, This is quite late resend, sorry. Only the third patch has changed, i.e. I got rid of sleep-nexus stuff per Scott and Benjamin suggestions. Acked-by: Scott Wood -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Floating point in the kernel
One of our drivers has code that was originally running on a DSP. The code makes heavy use of floating point. We have isolated all the floating point to one kthread in the driver. Using enable_kernel_fp() this has worked well. But under a specific heavy RTP load, we started getting kernel panics. To make a long story short, the scheduler disables FP when you are context switched out. When you come back and access a FP instruction, you trap and call load_up_fpu() and everything is fine. unless you are in the kernel. If you are in the kernel, like our kthread is, you get a "kernel FP unavailable exception". Basically we got away with it for two years because the thread is at high priority (-20) and tries very hard to finish within 1ms. But the RTP high load causes us to context switch out and crash. The following patch fixes this: diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h index 50504ae..3476de9 100644 --- a/arch/powerpc/kernel/head_booke.h +++ b/arch/powerpc/kernel/head_booke.h @@ -383,7 +383,7 @@ label: #define FP_UNAVAILABLE_EXCEPTION \ START_EXCEPTION(FloatingPointUnavailable) \ NORMAL_EXCEPTION_PROLOG; \ - beq 1f; \ + /* SAM beq 1f; */ \ bl load_up_fpu;/* if from user, just load it up */ \ b fast_exception_return;\ 1: addir3,r1,STACK_FRAME_OVERHEAD; \ With the patch we run fine, at the expense that we lose the ability to catch real FP unavailable exceptions in the kernel. It is because of this loss that I have not submitted this patch. We also hit another problem under high RTP load... and this is the patch that fixes it: diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S index fc8f5b1..051a02c 100644 --- a/arch/powerpc/kernel/fpu.S +++ b/arch/powerpc/kernel/fpu.S @@ -83,6 +83,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX) stfdfr0,THREAD_FPSCR(r4) PPC_LL r5,PT_REGS(r4) toreal(r5) + + /* Under heavy RTP load the hsp thread can have a NULL pt_regs. */ + PPC_LCMPI 0,r5,0 + beq 1f + PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5) li r10,MSR_FP|MSR_FE0|MSR_FE1 andcr4,r4,r10 /* disable FP for previous task */ So, if you are still reading this far, I am just looking for any suggestions. Are there better ways of handling this? Have I missed something? Anybody know why pt_regs might be NULL? Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] cpm2_pic: Allow correct flow_types for port C interrupts
On Dec 10, 2009, at 5:14 AM, Mark Ware wrote: > Port C interrupts can be either falling edge, or either edge. > Other external interrupts are either falling edge or active low. > Tested on a custom 8280 based board. > > Signed-off-by: Mark Ware > --- > Changed in v3: > - Cosmetic improvements as suggested by Anton and Scott > - Added tested note to changelog > > arch/powerpc/sysdev/cpm2_pic.c | 28 +--- > 1 files changed, 21 insertions(+), 7 deletions(-) Applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Floating point in the kernel
On Thu, 2009-12-10 at 13:13 -0500, Sean MacLennan wrote: > One of our drivers has code that was originally running on a DSP. The > code makes heavy use of floating point. We have isolated all the > floating point to one kthread in the driver. Using enable_kernel_fp() > this has worked well. > > But under a specific heavy RTP load, we started getting kernel panics. > To make a long story short, the scheduler disables FP when you are > context switched out. When you come back and access a FP instruction, > you trap and call load_up_fpu() and everything is fine. unless you > are in the kernel. If you are in the kernel, like our kthread is, you > get a "kernel FP unavailable exception". Right, you must not use floating point in the kernel -and- expect it to survive schedule. You should use preempt_disable() and ensure you don't schedule() around a block using the FP. Note that you may also lose the FP register content if you schedule. > Basically we got away with it for two years because the thread is at > high priority (-20) and tries very hard to finish within 1ms. But the > RTP high load causes us to context switch out and crash. The following > patch fixes this: > > diff --git a/arch/powerpc/kernel/head_booke.h > b/arch/powerpc/kernel/head_booke.h > index 50504ae..3476de9 100644 > --- a/arch/powerpc/kernel/head_booke.h > +++ b/arch/powerpc/kernel/head_booke.h > @@ -383,7 +383,7 @@ label: > #define FP_UNAVAILABLE_EXCEPTION > \ > START_EXCEPTION(FloatingPointUnavailable) > \ > NORMAL_EXCEPTION_PROLOG; > \ > - beq 1f; > \ > + /* SAM beq 1f; */ \ > bl load_up_fpu;/* if from user, just load it up */ > \ > b fast_exception_return; > \ > 1: addir3,r1,STACK_FRAME_OVERHEAD; > \ > > With the patch we run fine, at the expense that we lose the ability to > catch real FP unavailable exceptions in the kernel. It is because of > this loss that I have not submitted this patch. I'm not sure that will work in all cases, you are playing a bit with fire :-) I suppose I could think it through after breakfast but my first thought is "don't do that !". Among other things you may not have a pt_regs to save the registers to. > We also hit another problem under high RTP load... and this is the > patch that fixes it: > > diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S > index fc8f5b1..051a02c 100644 > --- a/arch/powerpc/kernel/fpu.S > +++ b/arch/powerpc/kernel/fpu.S > @@ -83,6 +83,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX) > stfdfr0,THREAD_FPSCR(r4) > PPC_LL r5,PT_REGS(r4) > toreal(r5) > + > + /* Under heavy RTP load the hsp thread can have a NULL pt_regs. */ > + PPC_LCMPI 0,r5,0 > + beq 1f > + Right and that means you just lost the content of your FP registers. > PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5) > li r10,MSR_FP|MSR_FE0|MSR_FE1 > andcr4,r4,r10 /* disable FP for previous task */ > > So, if you are still reading this far, I am just looking for any > suggestions. Are there better ways of handling this? Have I > missed something? Anybody know why pt_regs might be NULL? Just don't schedule when you enable_kernel_fp() or move your workload to userspace :-) Cheers, Ben. > Cheers, >Sean > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Floating point in the kernel
On Thursday 10 December 2009 18:13:11 Sean MacLennan wrote: > One of our drivers has code that was originally running on a DSP. The > code makes heavy use of floating point. We have isolated all the > floating point to one kthread in the driver. Using enable_kernel_fp() > this has worked well. > > But under a specific heavy RTP load, we started getting kernel panics. > To make a long story short, the scheduler disables FP when you are > context switched out. When you come back and access a FP instruction, > you trap and call load_up_fpu() and everything is fine. unless you > are in the kernel. If you are in the kernel, like our kthread is, you > get a "kernel FP unavailable exception". I think the rule here is that you have to disable preemption and must not call any potentially blocking functions like kmalloc when enable_kernel_fp is set. The kernel has good control over whether a thread get context switched or not, so it should be able to prevent these problems. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Floating point in the kernel
On Fri, 11 Dec 2009 07:19:39 +1100 Benjamin Herrenschmidt wrote: > I'm not sure that will work in all cases, you are playing a bit with > fire :-) I suppose I could think it through after breakfast but my > first thought is "don't do that !". Among other things you may not > have a pt_regs to save the registers to. Actually, we usually do have pt_regs, or we are stealing some ;) > > We also hit another problem under high RTP load... and this is the > > patch that fixes it: > > > > diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S > > index fc8f5b1..051a02c 100644 > > --- a/arch/powerpc/kernel/fpu.S > > +++ b/arch/powerpc/kernel/fpu.S > > @@ -83,6 +83,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX) > > stfdfr0,THREAD_FPSCR(r4) > > PPC_LL r5,PT_REGS(r4) > > toreal(r5) > > + > > + /* Under heavy RTP load the hsp thread can have a NULL > > pt_regs. */ > > + PPC_LCMPI 0,r5,0 > > + beq 1f > > + > > Right and that means you just lost the content of your FP registers. This only happens once in a blue moon, even under heavy RTP load. But I agree, this could be a real problem. > > PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5) > > li r10,MSR_FP|MSR_FE0|MSR_FE1 > > andcr4,r4,r10 /* disable FP for previous > > task */ > > > > So, if you are still reading this far, I am just looking for any > > suggestions. Are there better ways of handling this? Have I > > missed something? Anybody know why pt_regs might be NULL? > > Just don't schedule when you enable_kernel_fp() or move your workload > to userspace :-) To be honest, I can't find *why* we are scheduling :( They only way we give up the CPU is with locking... and none of the locks where hit during the problem. We also never get near our timeslice... the longest run I saw when the problem happened was 670us. Is there a way to disable scheduling? We currently do not have preempt enabled... but may in the future. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Deprecating of_platform, the path from here...
Hi David, On Wed, Dec 9, 2009 at 5:21 PM, David Miller wrote: > From: David Miller > Date: Wed, 09 Dec 2009 16:15:50 -0800 (PST) > >> From: Grant Likely >> Date: Wed, 9 Dec 2009 15:06:29 -0700 >> >>> 1) of_platform will be deprecated in preference of the platform bus. >> >> What a shame, it's one of the cleanest driver probing models >> in the tree. > > And BTW, have you folks who "decided" this considered at all the fact > that it is much easier to describe represent platform devices using > of OF devices rather than the other way around? Yup. I also think of_platform is a cleaner implementation than platform, but the fact remains that there are far more platform drivers than there are of_platform. So, as nice as of_platform is, it still does pretty much exactly the same job as platform. I'd rather see of_platform features migrated to platform than creating drivers with dual registrations to be used on both OF and non-OF platforms. Trying to go the other way around (deprecate platform and encouraging of_platform instead) I don't think will gain much traction; whereas I think bringing of_platform features into platform will be an easier sell. I'm trying to be pragmatic here. > The platform device pdata mechanism requires data structure changes > and is not dynamically extensible, whereas OF devices are > fundamentally so. > > I don't like the idea to get rid of of_platform devices at all. There are no plans to actually remove of_platform. I certainly don't plan to try and force SPARC to switch from of_platform to platform bus. But on PowerPC (and probably Microblaze) the plan is to move away from of_platform for all the reasons discussed, and I'm not be bringing of_platform over as I work on ARM support. > OF devices are really clean, much like netlink messages, where > arbitrary named attributes can be added or removed without any data > structure changes at all. No argument here. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Floating point in the kernel
On Thu, 2009-12-10 at 15:33 -0500, Sean MacLennan wrote: > To be honest, I can't find *why* we are scheduling :( They only way we > give up the CPU is with locking... and none of the locks where hit > during the problem. We also never get near our timeslice... the > longest > run I saw when the problem happened was 670us. > > Is there a way to disable scheduling? We currently do not have preempt > enabled... but may in the future. Well, that would be interesting to see where you schedule indeed. Outside of preempt and an explicit lock or memory allocation I don't see ... Or get/put_user ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Deprecating of_platform, the path from here...
On Thu, 2009-12-10 at 12:45 +1100, Benjamin Herrenschmidt wrote: > I don't agree with grant idea however that just converting the content > of the device node into properties is the way to go. And here of course I meant " converting the content of the device node into into pdata" ... > I do prefer your proposed approach (from our IRC discussion) which is > instead to allocate a struct device-node, convert pdata into properties, > and modify the drier to use these properties. > > The main difference thus between the two type of conversions (convert to > of_platform vs convert to platform) is that in the first case, you have > to convert the driver to use properties -and- convert all platforms in > all archs including gory ARM cell phone stuff you really don't want to > go anywhere near. In the second case, you still convert the driver to > use properties natively, but you keep a "wart" to turn pdata into a > device-node -inside the driver-, protected by a CONFIG option maybe, so > that those archs can be left alone until it becomes so obvious to > everybody what approach is better that they'll end up being converted > too and the wart can go. > > I believe the second approach, while less "clean" in the absolute is a > more realistic path to take. > > Now, orthogonally to that, I do believe it's still nice to provide a way > to statically lay out a device node in platform code, to allow archs > that don't otherwise have the device-tree to replace pdata with > something nicer and get rid of the wart quicker. > > We could either find a way with macros to layout an actual struct > device_node statically along with all the properties etc... but that > sounds a tad hard. > > We could have something that convert an entirely ASCII representation > into a struct device_node, but that would be akin of having dtc in the > kernel, might be a bit bloated no ? Though it could be made simpler and > more restrictive. > > Or we could find an in-between .. .A different struct type that is more > suitable for being laid out statically (a name, a type, and an enum of > structs for various property "types", ie, strings, words, bytes, ...) > with a little helper function that conver that into a device node at > runtime ? > > What do you think ? > > Cheers, > Ben. > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Floating point in the kernel
On Thursday 10 December 2009, Sean MacLennan wrote: > To be honest, I can't find why we are scheduling :( They only way we > give up the CPU is with locking... and none of the locks where hit > during the problem. We also never get near our timeslice... the longest > run I saw when the problem happened was 670us. > > Is there a way to disable scheduling? We currently do not have preempt > enabled... but may in the future. If you do preempt_disable(), it should give you a nice oops with a backtrace at the point where an actual schedule happens. The sequence should be something like preempt_disable(); enable_kernel_fp(); /* use FP here */ preempt_enable(); /* may schedule again */ Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Deprecating of_platform, the path from here...
Hey guys, some more thoughts below... On Wed, Dec 9, 2009 at 6:45 PM, Benjamin Herrenschmidt wrote: > First the probing because that's the real important issue, I believe the > other one is mostly academic and can be dealt on a per driver basis > (I'll discuss it later too). > > I'm not totally sold on the idea of the table that Grant proposed. I > think I proposed it initially in a discussion we had on IRC as one > possible option and in fact it was suggested by Paulus so don't > completely blame Grant for it though. It does mean that either platform > code or core code will have some kind of big table that associates a > whole pile of of_device_id with a platform device name. It somewhat > sucks when I think more about it and it does feel like a step backward > from of_platform_device. For the record, I don't like it either. But it is the pragmatic thing to do because it is simple to implement, and can easily be replaced later with a better scheme with little impact on drivers. Basically, it's a migration plan. > If we could make platform_driver grow an of_device_id match list it > would be indeed nicer. Of course you'll reply to that "let's just use > of_platform" instead :-) > > I would then argue that I don't like having two different bus types, > platform and of_platform for "generic platform" devices that aren't > typed on a bus type. There's a lot of existing "platform device" and it > would be quite hard to convert them all. Especially since a lot of them > are used today on archs that don't have device trees and may never grow > one. > > IE. I believe it's going to be an easier path to grow platform_device > into something that has the of_device probing functionality rather than > turn everything into of_platform. (I'm not talking here about the pdata > and retrieval of informations from the tree, this is the second part of > the discussion, discussed below). > > The main problem with moving existing platform_device to of_platform is > how do we deal with archs that don't have the device-tree infrastructure > and use those drivers today ? > > We could I suppose create a helper that looks a lot like the current > platform device creation one, which would create an of_platform device > instead, along with a struct device_node attached (which isn't part of a > tree) to it, and create a single "compatible" property whose content is > the platform data name. > > But that means that for every driver we want to be able to use a > device-tree probing for, we would have to convert all archs & platforms > that may instanciate it to use the new helpers, in addition to replacing > whatever pdata they have statically stored into a device node (see the > second part of the discussion). > > It's possible I suppose. I just feel that it's going to be a tougher > sell to the rest of the world. > > There's one nit to be careful of. Some drivers (sadly) have the fact > that they appear under /sys/bus/platform/ as a userspace ABI thingy. Sad > but a fact. This is one of the reasons why rather than actually > converting to of_platform I'd rather find a way to add the of_device_id > match mechanism to the existing platform_device and deprecate the pdata > over time. > > It will also provide with an easier transition. Basically transform > platform_device into of_platform_device by first adding the missing bits > and -then- trimming the crufty remains. I 100% agree with you here on the matching problem. > Now let's move to the second part of the discussion which is the > retrieval of various configuration informations by the driver. > > Here too, our model is better, I think there's little argument there. A > named list of properties is just so much more flexible than a statically > data structure that has to be in sync between the driver and all > platforms using it leaves little room for improvement or adding platform > specific attributes which some drivers might need, etc... > > Grant proposal is to have drivers create the pdata from the device-tree. > This is something I believe we both disagree with, though you more > vehemently than me I suppose :-) See my pdata comment lower down. > There are various things at play here: > > First, let me make it clear that imho, the device type > (of_platform_device vs. platform_device) is irrelevant to that aspect of > the problem since nowadays we have the ability to carry a device node > pointer in any descendant of struct device (and we use that heavily for > devices using specific bus types already). And even if we kept of_platform; the same problem of parsing device tree data exists for all other bus types. Places where of_platform isn't used today (i2c, spi, pci, mdio, etc). It makes sense to establish a pattern for matching and probing with device tree data that is usable by all bus types. > If you take an existing platform driver that you want to use on a > device-tree enabled platform (other than just creating it and pdata from > arch code which we all a
Re: Deprecating of_platform, the path from here...
From: Grant Likely Date: Thu, 10 Dec 2009 13:47:33 -0700 > Trying to go the other way around (deprecate platform and encouraging > of_platform instead) I don't think will gain much traction; whereas I > think bringing of_platform features into platform will be an easier > sell. I'm trying to be pragmatic here. When people use words like "traction" and "pragmatic" that means they are making decisions for reasons other than technical ones. :-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Deprecating of_platform, the path from here...
On Thu, Dec 10, 2009 at 2:56 PM, David Miller wrote: > From: Grant Likely > Date: Thu, 10 Dec 2009 13:47:33 -0700 > >> Trying to go the other way around (deprecate platform and encouraging >> of_platform instead) I don't think will gain much traction; whereas I >> think bringing of_platform features into platform will be an easier >> sell. I'm trying to be pragmatic here. > > When people use words like "traction" and "pragmatic" that means they > are making decisions for reasons other than technical ones. :-) 100% true. :-) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 09/11] of: merge of_attach_node() & of_detach_node()
On Wed, Nov 25, 2009 at 9:07 PM, Benjamin Herrenschmidt wrote: > On Tue, 2009-11-24 at 01:19 -0700, Grant Likely wrote: >> Merge common code between PowerPC and Microblaze > > Some of those guys might wnat to be in of_dynamic (see previous email) > > Remember: We want to keep the footprint low for embedded archs that > don't want to do dynamic stuff. Really low. I agree. If it is okay by you I'll update this in a subsequent patch. Once the code is merge, then I'm going to do a bunch of refactoring patches. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Floating point in the kernel
Found it. We are calling sock_sendmsg, which is definitely a call that can block! The receive side is done in a thread (which does no floating point ;), but the send was called directly from the "evil FP thread". It looks like under light load, you tend to get away with it, so our trivial testing did not catch it. And most of our warp users do RTP via asterisk, so this RTP path was not really tested. I really appreciate the input, the comments convinced me I was going in the wrong direction and forced me to look harder. I am going to back out the two patches I sent and fix this properly instead. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 01/03] powerpc: Extended ptrace interface
On Thu, Dec 10, 2009 at 01:57:15PM -0200, Dave Kleikamp wrote:
> powerpc: Extended ptrace interface
>
> From: Torez Smith
>
> Add a new extended ptrace interface so that user-space has a single
> interface for powerpc, without having to know the specific layout
> of the debug registers.
> Implement:
> PPC_PTRACE_GETHWDEBUGINFO
> PPC_PTRACE_SETHWDEBUG
> PPC_PTRACE_DELHWDEBUG
>
> Signed-off-by: Dave Kleikamp
> Signed-off-by: Torez Smith
Apart from the data breakpoint alignment for 32-bit systems, all the
comments below are trivial nits, so:
Acked-by: David Gibson
[snip]
> +/*
> + * Trigger Type
> + */
> +#define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x1
> +#define PPC_BREAKPOINT_TRIGGER_READ 0x2
> +#define PPC_BREAKPOINT_TRIGGER_WRITE 0x4
> +#define PPC_BREAKPOINT_TRIGGER_RW0x6
For a little extra safety, I'd tend towards defining the RW constant
in terms of the READ and WRITE constants.
> +
> +/*
> + * Address Mode
> + */
> +#define PPC_BREAKPOINT_MODE_EXACT0x0
> +#define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE 0x1
> +#define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE 0x2
> +#define PPC_BREAKPOINT_MODE_MASK 0x3
> +
> +/*
> + * Condition Mode
> + */
> +#define PPC_BREAKPOINT_CONDITION_NONE0x0
> +#define PPC_BREAKPOINT_CONDITION_AND 0x1
> +#define PPC_BREAKPOINT_CONDITION_EXACT 0x1
And likewuse define EXACT in terms of AND.
> +#define PPC_BREAKPOINT_CONDITION_OR 0x2
> +#define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
> +#define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff
> +#define PPC_BREAKPOINT_CONDITION_BE_SHIFT16
> +#define PPC_BREAKPOINT_CONDITION_BE(n) \
> + (1<<((n)+PPC_BREAKPOINT_CONDITION_BE_SHIFT))
[snip]
> + case PPC_PTRACE_GETHWDBGINFO: {
> + struct ppc_debug_info dbginfo;
> +
> + dbginfo.version = 1;
> + dbginfo.num_instruction_bps = 0;
> + dbginfo.num_data_bps = 1;
> + dbginfo.num_condition_regs = 0;
> +#ifdef CONFIG_PPC64
> + dbginfo.data_bp_alignment = 8;
> +#else
> + dbginfo.data_bp_alignment = 0;
Uh.. this looks wrong. Surely it should be 4.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 02/03] powerpc: Add definitions for Debug Registers on BookE Platforms
On Thu, Dec 10, 2009 at 01:57:21PM -0200, Dave Kleikamp wrote: > powerpc: Add definitions for Debug Registers on BookE Platforms > > From: Torez Smith > > This patch adds additional definitions for BookE Debug Registers > to the reg_booke.h header file. > > Signed-off-by: Torez Smith > Signed-off-by: Dave Kleikamp As with patch 1/3, none of the comments below is anything that couldn't be fixed up after merging. So, Acked-by: David Gibson > Cc: Benjamin Herrenschmidt > Cc: Thiago Jung Bauermann > Cc: Sergio Durigan Junior > Cc: David Gibson > Cc: linuxppc-dev list > --- > > arch/powerpc/include/asm/processor.h | 30 +- > arch/powerpc/include/asm/reg_booke.h | 176 > +- > 2 files changed, 178 insertions(+), 28 deletions(-) [snip] > + /* > + * The following will contain addresses used by debug applications > + * to help trace and trap on particular address locations. > + * The bits in the Debug Control Registers above help define which > + * of the following registers will contain valid data and/or addresses. > + */ > + unsigned long iac1; > + unsigned long iac2; > + unsigned long iac3; > + unsigned long iac4; > + unsigned long dac1; > + unsigned long dac2; > + unsigned long dvc1; > + unsigned long dvc2; I think you'd make the logic in patch 3 substantially easier, if you defined these as unsigned long iac[4]; unsigned long dac[2]; unsigned long dvc[2]; instead of as individual structure members. [snip] > +#define DBCR0_USER_DEBUG (DBCR0_IDM | DBCR0_ICMP | DBCR0_IAC1 | \ > + DBCR0_IAC2 | DBCR0_IAC3 | DBCR0_IAC4) > +#define DBCR0_BASE_REG_VALUE 0 These constants are left over from when the interface allowed more-or-less direct access to the debug regs. I don't think the USER_DEBUG constant is used at all any more, and the BASE_REG_VALUE is just used in the load_default function, and might as well be inline there. [snip] > + > +#define dbcr_iac_range(task) ((task)->thread.dbcr0) Hrm, I think the way these macros work to do the 40x vs. BookE abstration is kind of ugly. But an unequivocally better way doesn't immediately occur to me. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 02/03] powerpc: Add definitions for Debug Registers on BookE Platforms
On Fri, 2009-12-11 at 11:53 +1100, David Gibson wrote: > On Thu, Dec 10, 2009 at 01:57:21PM -0200, Dave Kleikamp wrote: > > powerpc: Add definitions for Debug Registers on BookE Platforms > > > > From: Torez Smith > > > > This patch adds additional definitions for BookE Debug Registers > > to the reg_booke.h header file. > > > > Signed-off-by: Torez Smith > > Signed-off-by: Dave Kleikamp > > As with patch 1/3, none of the comments below is anything that > couldn't be fixed up after merging. So, > > Acked-by: David Gibson > > > Cc: Benjamin Herrenschmidt > > Cc: Thiago Jung Bauermann > > Cc: Sergio Durigan Junior > > Cc: David Gibson > > Cc: linuxppc-dev list > > --- > > > > arch/powerpc/include/asm/processor.h | 30 +- > > arch/powerpc/include/asm/reg_booke.h | 176 > > +- > > 2 files changed, 178 insertions(+), 28 deletions(-) > > [snip] > > + /* > > +* The following will contain addresses used by debug applications > > +* to help trace and trap on particular address locations. > > +* The bits in the Debug Control Registers above help define which > > +* of the following registers will contain valid data and/or addresses. > > +*/ > > + unsigned long iac1; > > + unsigned long iac2; > > + unsigned long iac3; > > + unsigned long iac4; > > + unsigned long dac1; > > + unsigned long dac2; > > + unsigned long dvc1; > > + unsigned long dvc2; > > I think you'd make the logic in patch 3 substantially easier, if you > defined these as > unsigned long iac[4]; > unsigned long dac[2]; > unsigned long dvc[2]; > instead of as individual structure members. I'll give that a look. You're probably right. > [snip] > > +#define DBCR0_USER_DEBUG (DBCR0_IDM | DBCR0_ICMP | DBCR0_IAC1 | \ > > +DBCR0_IAC2 | DBCR0_IAC3 | DBCR0_IAC4) > > +#define DBCR0_BASE_REG_VALUE 0 > > These constants are left over from when the interface allowed > more-or-less direct access to the debug regs. I don't think the > USER_DEBUG constant is used at all any more, and the BASE_REG_VALUE is > just used in the load_default function, and might as well be inline > there. Right. > [snip] > > + > > +#define dbcr_iac_range(task) ((task)->thread.dbcr0) > > Hrm, I think the way these macros work to do the 40x vs. BookE > abstration is kind of ugly. But an unequivocally better way doesn't > immediately occur to me. Without this, the ifdef's were horrendous. I'm open to renaming this or redefining it to be more intuitive if anyone has a better idea. -- David Kleikamp IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/83xx: Add power management support for MPC8315E-RDB boards
On Dec 10, 2009, at 12:01 PM, Anton Vorontsov wrote: > - Add nodes for PMC and GTM controllers. GTM4 can be used as a wakeup > source; > > - Add fsl,magic-packet properties to eTSEC nodes, i.e. wake-on-lan > support. Unlike MPC8313 processors, MPC8315 can resume from deep > sleep upon magic packet reception. > > Signed-off-by: Anton Vorontsov > --- > arch/powerpc/boot/dts/mpc8315erdb.dts | 27 +++ > 1 files changed, 27 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/83xx/suspend: Save and restore SICRL, SICRH and SCCR
On Dec 10, 2009, at 12:00 PM, Anton Vorontsov wrote: > We need to save SICRL, SICRH and SCCR registers on suspend, and restore > them on resume. Otherwise, we lose IO and clocks setup on MPC8315E-RDB > boards when ULPI USB PHY is used (non-POR setup). > > Signed-off-by: Anton Vorontsov > --- > arch/powerpc/platforms/83xx/suspend.c | 48 + > 1 files changed, 48 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/83xx/suspend: Clear deep_sleeping after devices resume
On Dec 10, 2009, at 12:00 PM, Anton Vorontsov wrote: > Currently 83xx PMC driver clears deep_sleeping variable very early, > before devices are resumed. This makes fsl_deep_sleep() unusable in > drivers' resume() callback. > > Sure, drivers can store fsl_deep_sleep() value on suspend and use > the stored value on resume. But a better solution is to postpone > clearing the deep_sleeping variable, i.e. move it into finish() > callback. > > Signed-off-by: Anton Vorontsov > Acked-by: Scott Wood > --- > arch/powerpc/platforms/83xx/suspend.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: dts file for MPC8343EA
Hi Scott:
I am still stuck at Linux kernel booting in MPC8343EA based board.
I have disabled "Ethernet, PCI, USB, dma engines " in the *.dts file and
also in the kernel config.
I am using MPC8349emitxgp.dts ; enabled MPC8349ITX support in kernel config
also. In fact, I tried building MPC8349emITX; MPC8349MDS also. Same
behaviour!
With this, the kernel boots up (explicitly passing the DTB file and cuImage
NEVER worked) and hangs after
I am using Linux-V-2.6.27.18 and using powerpc-e300c3-gnu toolchain -
gcc-4.1.69-eglibc-2.5.69-1 to build u-boot-1.3.2 & linux.
With this, the kernel boots up (explicitly passing the DTB file and cuImage
NEVER worked) and hangs after printing
"Calibrating delay loop... 133.12 BogoMIPS (lpj=266240)"
With a few debug printks looks like the kernel hangs in
"cpu_idle" in --main/init.c
Any clues..?? HELP!!!
Please find the dts file and screen-dump below:
Thanks,
Junita
DTS file:
===
/dts-v1/;
/ {
model = "MPC8349EMITXGP";
compatible = "MPC8349EMITXGP", "MPC834xMITX", "MPC83xxMITX";
#address-cells = <1>;
#size-cells = <1>;
aliases {
serial0 = &serial0;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8...@0 {
device_type = "cpu";
reg = <0x0>;
d-cache-line-size = <32>;
i-cache-line-size = <32>;
d-cache-size = <32768>;
i-cache-size = <32768>;
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>;// from bootloader
clock-frequency = <0>; // from bootloader
};
};
memory {
device_type = "memory";
reg = <0x 0x1000>;
};
soc8...@e000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "simple-bus";
ranges = <0x0 0xe000 0x0010>;
reg = <0xe000 0x0200>;
bus-frequency = <0x0fe502a8>;// from
bootloader
w...@200 {
device_type = "watchdog";
compatible = "mpc83xx_wdt";
reg = <0x200 0x100>;
};
i...@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <14 0x8>;
interrupt-parent = <&ipic>;
dfsrr;
};
m...@24520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
reg = <0x24520 0x20>;
};
serial0: ser...@4500 {
cell-index = <0>;
device_type = "serial";
compatible = "ns16550";
reg = <0x4500 0x100>;
clock-frequency = <0>; // from bootloader
interrupts = <9 0x8>;
interrupt-parent = <&ipic>;
};
ipic: p...@700 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x700 0x100>;
device_type = "ipic";
};
};
};
Screen-shot:
==
Trying TSEC0
Speed: 100, full duplex
Using TSEC0 device
TFTP from server 192.168.201.14; our IP address is 192.168.201.199
Filename '8349.dtb'.
Load address: 0x90
Loading: #
done
Bytes transferred = 12288 (3000 hex)
SC3000> bootm 0x0060 - 0x0090
## Booting image at 0060 ...
Image Name: Linux-2.6.27.18
Created: 2009-12-11 0:16:24 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:850785 Bytes = 830.8 kB
Load Address:
Entry Point:
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x0FF9BD48 => set upper limit to 0x0080
## cmdline at 0x007FFF00 ... 0x007FFF2E
bd address = 0x0FF9BFC4
memstart= 0x
memsize = 0x1000
flashstart = 0xFE00
flashsize = 0x0008
flashoffset = 0x00034000
sramstart = 0x
sramsize= 0x
bootflags = 0x0001
intfreq = 399.999 MHz
busfreq = 266.666 MHz
ethaddr = 00:E0:0C:00:8C:01
IP addr = 192.168.201.199
baudrate= 115200 bps
Skipping initrd
Booting using the fdt at 0x90
No initrd
## dev
Re: [PATCH 2/3] asm/gpio.h: support gpio_to_irq()
On Dec 1, 2009, at 2:48 PM, Peter Korsgaard wrote: > gpiolib returns -ENXIO if struct gpio_chip::to_irq isn't set, so it's > safe to always call. > > Signed-off-by: Peter Korsgaard > --- > arch/powerpc/include/asm/gpio.h |5 + > 1 files changed, 1 insertions(+), 4 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mpc8xxx_gpio: add interrupt support
On Dec 9, 2009, at 1:33 AM, Peter Korsgaard wrote: >> "Peter" == Peter Korsgaard writes: > > Comments? > > Peter> Signed-off-by: Peter Korsgaard > Peter> --- > Peter> arch/powerpc/sysdev/mpc8xxx_gpio.c | 147 > > Peter> 1 files changed, 147 insertions(+), 0 deletions(-) We need a binding document to go with this. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
> These patches implement an extention to the ptrace interface proposed by
> Thiago Bauermann and the the PowerPC gdb team.
>
> GDB intends to support the following hardware debug features of BookE
> processors:
>
> 4 hardware breakpoints (IAC)
> 2 hardware watchpoints (read, write and read-write) (DAC)
> 2 value conditions for the hardware watchpoints (DVC)
>
> For that, we need to extend ptrace so that GDB can query and set these
> resources. Since we're extending, we're trying to create an interface
> that's extendable and that covers both BookE and server processors, so
> that GDB doesn't need to special-case each of them. We propose the
> following 3 new ptrace requests described below.
>
> There have been discussions of a generic hardware debug interface for the
> kernel which would hopefully contemplate all the functionality below and
> supersede it. But we need something that works now, and which enables GDB
> to be simpler and work with both Server and Embedded processors without
> special cases.
>
> 1. PTRACE_PPC_GETHWDEBUGINFO
>
> Query for GDB to discover the hardware debug features. The main info to
> be returned here is the minimum alignment for the hardware watchpoints.
> BookE processors don't have restrictions here, but server processors have
> an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
> adding special cases to GDB based on what it sees in AUXV.
>
> Since we're at it, we added other useful info that the kernel can return to
> GDB: this query will return the number of hardware breakpoints, hardware
> watchpoints and whether it supports a range of addresses and a condition.
> The query will fill the following structure provided by the requesting
> process:
>
> struct ppc_debug_info {
> unit32_t version;
> unit32_t num_instruction_bps;
> unit32_t num_data_bps;
> unit32_t num_condition_regs;
> unit32_t data_bp_alignment;
> unit32_t sizeof_condition; /* size of the DVC register */
> uint64_t features; /* bitmask of the individual flags */
> };
>
> features will have bits indicating whether there is support for:
>
> #define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
> #define PPC_DEBUG_FEATURE_INSN_BP_MASK0x2
> #define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
> #define PPC_DEBUG_FEATURE_DATA_BP_MASK0x8
Is GDB smart enough to deal w/no condition_regs? On some Book-E devices we
have 2 IACs, 2 DACs, and 0 DVCs. Does it need to be in the features?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
> These patches implement an extention to the ptrace interface proposed by
> Thiago Bauermann and the the PowerPC gdb team.
>
> GDB intends to support the following hardware debug features of BookE
> processors:
>
> 4 hardware breakpoints (IAC)
> 2 hardware watchpoints (read, write and read-write) (DAC)
> 2 value conditions for the hardware watchpoints (DVC)
>
> For that, we need to extend ptrace so that GDB can query and set these
> resources. Since we're extending, we're trying to create an interface
> that's extendable and that covers both BookE and server processors, so
> that GDB doesn't need to special-case each of them. We propose the
> following 3 new ptrace requests described below.
>
> There have been discussions of a generic hardware debug interface for the
> kernel which would hopefully contemplate all the functionality below and
> supersede it. But we need something that works now, and which enables GDB
> to be simpler and work with both Server and Embedded processors without
> special cases.
>
> 1. PTRACE_PPC_GETHWDEBUGINFO
>
> Query for GDB to discover the hardware debug features. The main info to
> be returned here is the minimum alignment for the hardware watchpoints.
> BookE processors don't have restrictions here, but server processors have
> an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
> adding special cases to GDB based on what it sees in AUXV.
>
> Since we're at it, we added other useful info that the kernel can return to
> GDB: this query will return the number of hardware breakpoints, hardware
> watchpoints and whether it supports a range of addresses and a condition.
> The query will fill the following structure provided by the requesting
> process:
>
> struct ppc_debug_info {
> unit32_t version;
> unit32_t num_instruction_bps;
> unit32_t num_data_bps;
> unit32_t num_condition_regs;
> unit32_t data_bp_alignment;
> unit32_t sizeof_condition; /* size of the DVC register */
> uint64_t features; /* bitmask of the individual flags */
> };
>
> features will have bits indicating whether there is support for:
>
> #define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
> #define PPC_DEBUG_FEATURE_INSN_BP_MASK0x2
> #define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
> #define PPC_DEBUG_FEATURE_DATA_BP_MASK0x8
>
> 2. PTRACE_SETHWDEBUG
>
> Sets a hardware breakpoint or watchpoint, according to the provided structure:
>
> struct ppc_hw_breakpoint {
>uint32_t version;
> #define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x1
> #define PPC_BREAKPOINT_TRIGGER_READ 0x2
> #define PPC_BREAKPOINT_TRIGGER_WRITE0x4
>uint32_t trigger_type; /* only some combinations allowed */
> #define PPC_BREAKPOINT_MODE_EXACT 0x0
> #define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE 0x1
> #define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE 0x2
> #define PPC_BREAKPOINT_MODE_MASK0x3
>uint32_t addr_mode; /* address match mode */
>
> #define PPC_BREAKPOINT_CONDITION_NONE 0x0
> #define PPC_BREAKPOINT_CONDITION_AND0x1
> #define PPC_BREAKPOINT_CONDITION_EXACT 0x1 /* different name for the same
> thing as above */
> #define PPC_BREAKPOINT_CONDITION_OR 0x2
> #define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
> #define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff/* byte enable bits */
> #define PPC_BREAKPOINT_CONDITION_BE(n) (1<<((n)+16))
>uint32_t condition_mode; /* break/watchpoint condition flags */
>
>uint64_t addr;
>uint64_t addr2;
>uint64_t condition_value;
> };
>
> A request specifies one event, not necessarily just one register to be set.
> For instance, if the request is for a watchpoint with a condition, both the
> DAC and DVC registers will be set in the same request.
>
> With this GDB can ask for all kinds of hardware breakpoints and watchpoints
> that the BookE supports. COMEFROM breakpoints available in server processors
> are not contemplated, but that is out of the scope of this work.
>
> ptrace will return an integer (handle) uniquely identifying the breakpoint or
> watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
> request to ask for its removal. Return -ENOSPC if the requested breakpoint
> can't be allocated on the registers.
>
> Some examples of using the structure to:
>
> - set a breakpoint in the first breakpoint register
>
> p.version = PPC_DEBUG_CURRENT_VERSION;
> p.trigger_type= PPC_BREAKPOINT_TRIGGER_EXECUTE;
> p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
> p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
> p.addr= (uint64_t) address;
> p.addr2 = 0;
> p.condition_value = 0;
>
> - set a watchpoint which triggers on reads in the second watchpoint register
>
> p.version = PPC_DEBUG_CURRENT_VERSION;
> p.trigger_type= PPC_BREAKPOINT_TR
Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
On Thu, 2009-12-10 at 20:23 -0600, Kumar Gala wrote:
> On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
>
> > These patches implement an extention to the ptrace interface proposed by
> > Thiago Bauermann and the the PowerPC gdb team.
> >
> > GDB intends to support the following hardware debug features of BookE
> > processors:
> >
> > 4 hardware breakpoints (IAC)
> > 2 hardware watchpoints (read, write and read-write) (DAC)
> > 2 value conditions for the hardware watchpoints (DVC)
> >
> > For that, we need to extend ptrace so that GDB can query and set these
> > resources. Since we're extending, we're trying to create an interface
> > that's extendable and that covers both BookE and server processors, so
> > that GDB doesn't need to special-case each of them. We propose the
> > following 3 new ptrace requests described below.
> >
> > There have been discussions of a generic hardware debug interface for the
> > kernel which would hopefully contemplate all the functionality below and
> > supersede it. But we need something that works now, and which enables GDB
> > to be simpler and work with both Server and Embedded processors without
> > special cases.
> >
> > 1. PTRACE_PPC_GETHWDEBUGINFO
> >
> > Query for GDB to discover the hardware debug features. The main info to
> > be returned here is the minimum alignment for the hardware watchpoints.
> > BookE processors don't have restrictions here, but server processors have
> > an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
> > adding special cases to GDB based on what it sees in AUXV.
> >
> > Since we're at it, we added other useful info that the kernel can return to
> > GDB: this query will return the number of hardware breakpoints, hardware
> > watchpoints and whether it supports a range of addresses and a condition.
> > The query will fill the following structure provided by the requesting
> > process:
> >
> > struct ppc_debug_info {
> > unit32_t version;
> > unit32_t num_instruction_bps;
> > unit32_t num_data_bps;
> > unit32_t num_condition_regs;
> > unit32_t data_bp_alignment;
> > unit32_t sizeof_condition; /* size of the DVC register */
> > uint64_t features; /* bitmask of the individual flags */
> > };
> >
> > features will have bits indicating whether there is support for:
> >
> > #define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
> > #define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
> > #define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
> > #define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
>
> Is GDB smart enough to deal w/no condition_regs? On some Book-E
> devices we have 2 IACs, 2 DACs, and 0 DVCs. Does it need to be in the
> features?
I had discussed it with the gdb team. I could easily add a feature
flag, but it would be equivalent to num_condition_regs > 0. I don't
have a strong opinion either way.
--
David Kleikamp
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
On Thu, 2009-12-10 at 20:24 -0600, Kumar Gala wrote:
> On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
>
> > These patches implement an extention to the ptrace interface proposed by
> > Thiago Bauermann and the the PowerPC gdb team.
> >
> > GDB intends to support the following hardware debug features of BookE
> > processors:
> >
> > 4 hardware breakpoints (IAC)
> > 2 hardware watchpoints (read, write and read-write) (DAC)
> > 2 value conditions for the hardware watchpoints (DVC)
> >
> > For that, we need to extend ptrace so that GDB can query and set these
> > resources. Since we're extending, we're trying to create an interface
> > that's extendable and that covers both BookE and server processors, so
> > that GDB doesn't need to special-case each of them. We propose the
> > following 3 new ptrace requests described below.
> >
> > There have been discussions of a generic hardware debug interface for the
> > kernel which would hopefully contemplate all the functionality below and
> > supersede it. But we need something that works now, and which enables GDB
> > to be simpler and work with both Server and Embedded processors without
> > special cases.
> >
> > 1. PTRACE_PPC_GETHWDEBUGINFO
> >
> > Query for GDB to discover the hardware debug features. The main info to
> > be returned here is the minimum alignment for the hardware watchpoints.
> > BookE processors don't have restrictions here, but server processors have
> > an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
> > adding special cases to GDB based on what it sees in AUXV.
> >
> > Since we're at it, we added other useful info that the kernel can return to
> > GDB: this query will return the number of hardware breakpoints, hardware
> > watchpoints and whether it supports a range of addresses and a condition.
> > The query will fill the following structure provided by the requesting
> > process:
> >
> > struct ppc_debug_info {
> > unit32_t version;
> > unit32_t num_instruction_bps;
> > unit32_t num_data_bps;
> > unit32_t num_condition_regs;
> > unit32_t data_bp_alignment;
> > unit32_t sizeof_condition; /* size of the DVC register */
> > uint64_t features; /* bitmask of the individual flags */
> > };
> >
> > features will have bits indicating whether there is support for:
> >
> > #define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
> > #define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
> > #define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
> > #define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
> >
> > 2. PTRACE_SETHWDEBUG
> >
> > Sets a hardware breakpoint or watchpoint, according to the provided
> > structure:
> >
> > struct ppc_hw_breakpoint {
> >uint32_t version;
> > #define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x1
> > #define PPC_BREAKPOINT_TRIGGER_READ 0x2
> > #define PPC_BREAKPOINT_TRIGGER_WRITE0x4
> >uint32_t trigger_type; /* only some combinations allowed */
> > #define PPC_BREAKPOINT_MODE_EXACT 0x0
> > #define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE 0x1
> > #define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE 0x2
> > #define PPC_BREAKPOINT_MODE_MASK0x3
> >uint32_t addr_mode; /* address match mode */
> >
> > #define PPC_BREAKPOINT_CONDITION_NONE 0x0
> > #define PPC_BREAKPOINT_CONDITION_AND0x1
> > #define PPC_BREAKPOINT_CONDITION_EXACT 0x1 /* different name for the same
> > thing as above */
> > #define PPC_BREAKPOINT_CONDITION_OR 0x2
> > #define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
> > #define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff /* byte enable bits */
> > #define PPC_BREAKPOINT_CONDITION_BE(n) (1<<((n)+16))
> >uint32_t condition_mode; /* break/watchpoint condition flags */
> >
> >uint64_t addr;
> >uint64_t addr2;
> >uint64_t condition_value;
> > };
> >
> > A request specifies one event, not necessarily just one register to be set.
> > For instance, if the request is for a watchpoint with a condition, both the
> > DAC and DVC registers will be set in the same request.
> >
> > With this GDB can ask for all kinds of hardware breakpoints and watchpoints
> > that the BookE supports. COMEFROM breakpoints available in server processors
> > are not contemplated, but that is out of the scope of this work.
> >
> > ptrace will return an integer (handle) uniquely identifying the breakpoint
> > or
> > watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
> > request to ask for its removal. Return -ENOSPC if the requested breakpoint
> > can't be allocated on the registers.
> >
> > Some examples of using the structure to:
> >
> > - set a breakpoint in the first breakpoint register
> >
> > p.version = PPC_DEBUG_CURRENT_VERSION;
> > p.trigger_type= PPC_BREAKPOINT_TRIGGER_EXECUTE;
> > p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
> > p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
> > p
Re: [RFC:PATCH 02/03] powerpc: Add definitions for Debug Registers on BookE Platforms
On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote: > +#define DBCR1_IAC1US 0xC000 /* Instr Addr Cmp 1 Sup/User */ > +#define DBCR1_IAC1ER 0x3000 /* Instr Addr Cmp 1 Eff/Real */ > +#define DBCR1_IAC1ER_01 0x1000 /* reserved */ > +#define DBCR1_IAC1ER_10 0x2000 /* Instr Addr Cmp 1 Eff/Real > MSR[IS]=0 */ > +#define DBCR1_IAC1ER_11 0x3000 /* Instr Addr Cmp 1 Eff/Real > MSR[IS]=1 */ > +#define DBCR1_IAC2US 0x0C00 /* Instr Addr Cmp 2 Sup/User */ > +#define DBCR1_IAC2ER 0x0300 /* Instr Addr Cmp 2 Eff/Real */ > +#define DBCR1_IAC2ER_01 0x0100 /* reserved */ > +#define DBCR1_IAC2ER_10 0x0200 /* Instr Addr Cmp 2 Eff/Real > MSR[IS]=0 */ > +#define DBCR1_IAC2ER_11 0x0300 /* Instr Addr Cmp 2 Eff/Real > MSR[IS]=1 */ > +#define DBCR1_IAC12M 0x00C0 /* Instr Addr 1-2 range enable */ > +#define DBCR1_IAC12M_R 0x0040 /* Instr Addr 1-2 reserved > state */ > +#define DBCR1_IAC12M_I 0x0080 /* Instr Addr 1-2 range > inclusive */ > +#define DBCR1_IAC12M_X 0x00C0 /* Instr Addr 1-2 range > eXclusive */ > +#define DBCR1_IAC12A_T 0x0001 /* Instr Addr 1-2 range Toggle > */ > +#define DBCR1_IAC3US 0xC000 /* Instr Addr Cmp 3 Sup/User */ > +#define DBCR1_IAC3ER 0x3000 /* Instr Addr Cmp 3 Eff/Real */ > +#define DBCR1_IAC3ER_01 0x1000 /* reserved */ > +#define DBCR1_IAC3ER_10 0x2000 /* Instr Addr Cmp 3 Eff/Real > MSR[IS]=0 */ > +#define DBCR1_IAC3ER_11 0x3000 /* Instr Addr Cmp 3 Eff/Real > MSR[IS]=1 */ > +#define DBCR1_IAC4US 0x0C00 /* Instr Addr Cmp 4 Sup/User */ > +#define DBCR1_IAC4ER 0x0300 /* Instr Addr Cmp 4 Eff/Real */ > +#define DBCR1_IAC4ER_01 0x0100 /* Instr Addr Cmp 4 Eff/Real > MSR[IS]=0 */ > +#define DBCR1_IAC4ER_10 0x0200 /* Instr Addr Cmp 4 Eff/Real > MSR[IS]=0 */ > +#define DBCR1_IAC4ER_11 0x0300 /* Instr Addr Cmp 4 Eff/Real > MSR[IS]=1 */ > +#define DBCR1_IAC34M 0x00C0 /* Instr Addr 3-4 range enable */ > +#define DBCR1_IAC34M_R 0x0040 /* Instr Addr 3-4 reserved > state */ > +#define DBCR1_IAC34M_I 0x0080 /* Instr Addr 3-4 range > inclusive */ > +#define DBCR1_IAC34M_X 0x00C0 /* Instr Addr 3-4 range > eXclusive */ > +#define DBCR1_IAC34A_T 0x0001 /* Instr Addr 3-4 range Toggle > */ > + > +#define DBCR1_USER_DEBUG (DBCR1_IAC12M | DBCR1_IAC34M) > +#define DBCR1_BASE_REG_VALUE (DBCR1_IAC1US | DBCR1_IAC1ER_10 | \ > + DBCR1_IAC2US | DBCR1_IAC2ER_10 | \ > + DBCR1_IAC3US | DBCR1_IAC3ER_10 | \ > + DBCR1_IAC4US | DBCR1_IAC4ER_10) We are we using MSR[IS] IS=0, why not just any Eff address? In the future we might have user as IS = 1, and kernel as IS = 0. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote: > These patches implement an extention to the ptrace interface proposed by > Thiago Bauermann and the the PowerPC gdb team. > > GDB intends to support the following hardware debug features of BookE > processors: > > 4 hardware breakpoints (IAC) > 2 hardware watchpoints (read, write and read-write) (DAC) > 2 value conditions for the hardware watchpoints (DVC) > > For that, we need to extend ptrace so that GDB can query and set these > resources. Since we're extending, we're trying to create an interface > that's extendable and that covers both BookE and server processors, so > that GDB doesn't need to special-case each of them. We propose the > following 3 new ptrace requests described below. > > There have been discussions of a generic hardware debug interface for the > kernel which would hopefully contemplate all the functionality below and > supersede it. But we need something that works now, and which enables GDB > to be simpler and work with both Server and Embedded processors without > special cases. What do we do in EDM mode? We need a flag somewhere to determine if HW supports conveying DBCR0[EDM] and if it does which of the ptrace calls fails? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 03/03] powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
> powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
>
> From: Torez Smith
>
> This patch defines context switch and trap related functionality
> for BookE specific Debug Registers. It adds support to ptrace()
> for setting and getting BookE related Debug Registers
>
> Signed-off-by: Torez Smith
> Signed-off-by: Dave Kleikamp
> Cc: Benjamin Herrenschmidt
> Cc: Thiago Jung Bauermann
> Cc: Sergio Durigan Junior
> Cc: David Gibson
> Cc: linuxppc-dev list
> ---
>
> arch/powerpc/include/asm/system.h |2
> arch/powerpc/kernel/process.c | 109 -
> arch/powerpc/kernel/ptrace.c | 435 ++---
> arch/powerpc/kernel/signal.c |6 -
> arch/powerpc/kernel/signal_32.c |8 +
> arch/powerpc/kernel/traps.c | 86 ++-
> 6 files changed, 564 insertions(+), 82 deletions(-)
>
>
> diff --git a/arch/powerpc/include/asm/system.h
> b/arch/powerpc/include/asm/system.h
> index bb8e006..474bf23 100644
> --- a/arch/powerpc/include/asm/system.h
> +++ b/arch/powerpc/include/asm/system.h
> @@ -114,6 +114,8 @@ static inline int debugger_fault_handler(struct pt_regs
> *regs) { return 0; }
> extern int set_dabr(unsigned long dabr);
> extern void do_dabr(struct pt_regs *regs, unsigned long address,
> unsigned long error_code);
> +extern void do_send_trap(struct pt_regs *regs, unsigned long address,
> + unsigned long error_code, int signal_code, int errno);
> extern void print_backtrace(unsigned long *);
> extern void show_regs(struct pt_regs * regs);
> extern void flush_instruction_cache(void);
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index c930ac3..a0dbb09 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -245,6 +245,24 @@ void discard_lazy_cpu_state(void)
> }
> #endif /* CONFIG_SMP */
>
> +void do_send_trap(struct pt_regs *regs, unsigned long address,
> + unsigned long error_code, int signal_code, int errno)
> +{
> + siginfo_t info;
> +
> + if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
> + 11, SIGSEGV) == NOTIFY_STOP)
> + return;
> +
> + /* Deliver the signal to userspace */
> + info.si_signo = SIGTRAP;
> + info.si_errno = errno;
> + info.si_code = signal_code;
> + info.si_addr = (void __user *)address;
> + force_sig_info(SIGTRAP, &info, current);
> +}
> +
> +#if !(defined(CONFIG_40x) || defined(CONFIG_BOOKE))
> void do_dabr(struct pt_regs *regs, unsigned long address,
> unsigned long error_code)
> {
> @@ -257,12 +275,6 @@ void do_dabr(struct pt_regs *regs, unsigned long address,
> if (debugger_dabr_match(regs))
> return;
>
> - /* Clear the DAC and struct entries. One shot trigger */
> -#if defined(CONFIG_BOOKE)
> - mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBSR_DAC1R | DBSR_DAC1W
> - | DBCR0_IDM));
> -#endif
> -
> /* Clear the DABR */
> set_dabr(0);
>
> @@ -273,9 +285,71 @@ void do_dabr(struct pt_regs *regs, unsigned long address,
> info.si_addr = (void __user *)address;
> force_sig_info(SIGTRAP, &info, current);
> }
> +#endif
>
> static DEFINE_PER_CPU(unsigned long, current_dabr);
>
> +#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
> +/*
> + * Set the debug registers back to their default "safe" values.
> + */
> +static void set_debug_reg_defaults(struct thread_struct *thread)
> +{
> + thread->iac1 = thread->iac2 = thread->iac3 = thread->iac4 = 0;
> + thread->dac1 = thread->dac2 = 0;
> + thread->dvc1 = thread->dvc2 = 0;
> + /*
> + * reset the DBCR0, DBCR1 and DBCR2 registers. All bits with
> + * the exception of the reserved bits should be cleared out
> + * and set to 0.
> + *
> + * For the DBCR0 register, the reserved bits are bits 17:30.
> + * Reserved bits for DBCR1 are bits 10:14 and bits 26:30.
> + * And, bits 10:11 for DBCR2.
> + */
> + thread->dbcr0 = DBCR0_BASE_REG_VALUE;
This seems to always be 0, why have a special #define for it.
> + /*
> + * First clear all "non reserved" bits from DBCR1 then initialize reg
> + * to force User/Supervisor bits to b11 (user-only MSR[PR]=1) and
> + * Effective/Real * bits to b10 (trap only if IS==0)
> + */
> + thread->dbcr1 = DBCR1_BASE_REG_VALUE;
> + /*
> + * Force Data Address Compare User/Supervisor bits to be User-only
> + * (0b11 MSR[PR]=1) and set all other bits in DBCR2 register to be 0.
> + * This sets the Data Address Compare Effective/Real bits to be 0b00
> + * (Effective, MSR[DS]=don't care).
> + */
> + thread->dbcr2 = DBCR2_BASE_REG_VALUE;
> +}
> +
> +static void prime_debug_regs(struct thread_struct *thread)
> +{
> + mtspr(SPRN_IAC1, thread->iac1);
> + mtspr(SPRN_
Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
On Dec 10, 2009, at 8:29 PM, Dave Kleikamp wrote:
> On Thu, 2009-12-10 at 20:24 -0600, Kumar Gala wrote:
>> On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
>>
>>> These patches implement an extention to the ptrace interface proposed by
>>> Thiago Bauermann and the the PowerPC gdb team.
>>>
>>> GDB intends to support the following hardware debug features of BookE
>>> processors:
>>>
>>> 4 hardware breakpoints (IAC)
>>> 2 hardware watchpoints (read, write and read-write) (DAC)
>>> 2 value conditions for the hardware watchpoints (DVC)
>>>
>>> For that, we need to extend ptrace so that GDB can query and set these
>>> resources. Since we're extending, we're trying to create an interface
>>> that's extendable and that covers both BookE and server processors, so
>>> that GDB doesn't need to special-case each of them. We propose the
>>> following 3 new ptrace requests described below.
>>>
>>> There have been discussions of a generic hardware debug interface for the
>>> kernel which would hopefully contemplate all the functionality below and
>>> supersede it. But we need something that works now, and which enables GDB
>>> to be simpler and work with both Server and Embedded processors without
>>> special cases.
>>>
>>> 1. PTRACE_PPC_GETHWDEBUGINFO
>>>
>>> Query for GDB to discover the hardware debug features. The main info to
>>> be returned here is the minimum alignment for the hardware watchpoints.
>>> BookE processors don't have restrictions here, but server processors have
>>> an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
>>> adding special cases to GDB based on what it sees in AUXV.
>>>
>>> Since we're at it, we added other useful info that the kernel can return to
>>> GDB: this query will return the number of hardware breakpoints, hardware
>>> watchpoints and whether it supports a range of addresses and a condition.
>>> The query will fill the following structure provided by the requesting
>>> process:
>>>
>>> struct ppc_debug_info {
>>> unit32_t version;
>>> unit32_t num_instruction_bps;
>>> unit32_t num_data_bps;
>>> unit32_t num_condition_regs;
>>> unit32_t data_bp_alignment;
>>> unit32_t sizeof_condition; /* size of the DVC register */
>>> uint64_t features; /* bitmask of the individual flags */
>>> };
>>>
>>> features will have bits indicating whether there is support for:
>>>
>>> #define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
>>> #define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
>>> #define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
>>> #define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
>>>
>>> 2. PTRACE_SETHWDEBUG
>>>
>>> Sets a hardware breakpoint or watchpoint, according to the provided
>>> structure:
>>>
>>> struct ppc_hw_breakpoint {
>>> uint32_t version;
>>> #define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x1
>>> #define PPC_BREAKPOINT_TRIGGER_READ 0x2
>>> #define PPC_BREAKPOINT_TRIGGER_WRITE0x4
>>> uint32_t trigger_type; /* only some combinations allowed */
>>> #define PPC_BREAKPOINT_MODE_EXACT 0x0
>>> #define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE 0x1
>>> #define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE 0x2
>>> #define PPC_BREAKPOINT_MODE_MASK0x3
>>> uint32_t addr_mode; /* address match mode */
>>>
>>> #define PPC_BREAKPOINT_CONDITION_NONE 0x0
>>> #define PPC_BREAKPOINT_CONDITION_AND0x1
>>> #define PPC_BREAKPOINT_CONDITION_EXACT 0x1 /* different name for the same
>>> thing as above */
>>> #define PPC_BREAKPOINT_CONDITION_OR 0x2
>>> #define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
>>> #define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff /* byte enable bits */
>>> #define PPC_BREAKPOINT_CONDITION_BE(n) (1<<((n)+16))
>>> uint32_t condition_mode; /* break/watchpoint condition flags */
>>>
>>> uint64_t addr;
>>> uint64_t addr2;
>>> uint64_t condition_value;
>>> };
>>>
>>> A request specifies one event, not necessarily just one register to be set.
>>> For instance, if the request is for a watchpoint with a condition, both the
>>> DAC and DVC registers will be set in the same request.
>>>
>>> With this GDB can ask for all kinds of hardware breakpoints and watchpoints
>>> that the BookE supports. COMEFROM breakpoints available in server processors
>>> are not contemplated, but that is out of the scope of this work.
>>>
>>> ptrace will return an integer (handle) uniquely identifying the breakpoint
>>> or
>>> watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
>>> request to ask for its removal. Return -ENOSPC if the requested breakpoint
>>> can't be allocated on the registers.
>>>
>>> Some examples of using the structure to:
>>>
>>> - set a breakpoint in the first breakpoint register
>>>
>>> p.version = PPC_DEBUG_CURRENT_VERSION;
>>> p.trigger_type= PPC_BREAKPOINT_TRIGGER_EXECUTE;
>>> p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
>>> p.condition_mode =
Re: [RFC:PATCH 01/03] powerpc: Extended ptrace interface
On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
> powerpc: Extended ptrace interface
>
> From: Torez Smith
>
> Add a new extended ptrace interface so that user-space has a single
> interface for powerpc, without having to know the specific layout
> of the debug registers.
>
> Implement:
> PPC_PTRACE_GETHWDEBUGINFO
> PPC_PTRACE_SETHWDEBUG
> PPC_PTRACE_DELHWDEBUG
>
> Signed-off-by: Dave Kleikamp
> Signed-off-by: Torez Smith
> Cc: Benjamin Herrenschmidt
> Cc: Thiago Jung Bauermann
> Cc: Sergio Durigan Junior
> Cc: David Gibson
> Cc: linuxppc-dev list
> ---
>
> arch/powerpc/include/asm/ptrace.h | 75
> arch/powerpc/kernel/ptrace.c | 88 +
> 2 files changed, 163 insertions(+), 0 deletions(-)
>
>
> diff --git a/arch/powerpc/include/asm/ptrace.h
> b/arch/powerpc/include/asm/ptrace.h
> index 8c34149..7ae887b 100644
> --- a/arch/powerpc/include/asm/ptrace.h
> +++ b/arch/powerpc/include/asm/ptrace.h
> @@ -24,6 +24,12 @@
> * 2 of the License, or (at your option) any later version.
> */
>
> +#ifdef __KERNEL__
> +#include
> +#else
> +#include
> +#endif
> +
> #ifndef __ASSEMBLY__
>
> struct pt_regs {
> @@ -292,4 +298,73 @@ extern void user_disable_single_step(struct task_struct
> *);
>
> #define PTRACE_SINGLEBLOCK0x100 /* resume execution until next branch */
>
> +#define PPC_PTRACE_GETHWDBGINFO 0x89
> +#define PPC_PTRACE_SETHWDEBUG0x88
> +#define PPC_PTRACE_DELHWDEBUG0x87
> +
> +#ifndef __ASSEMBLY__
> +
> +struct ppc_debug_info {
> + uint32_t version; /* Only version 1 exists to date */
> + uint32_t num_instruction_bps;
> + uint32_t num_data_bps;
> + uint32_t num_condition_regs;
> + uint32_t data_bp_alignment;
> + uint32_t sizeof_condition; /* size of the DVC register */
> + uint64_t features;
> +};
> +
> +#endif /* __ASSEMBLY__ */
> +
> +/*
> + * features will have bits indication whether there is support for:
> + */
> +#define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
> +#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
> +#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
> +#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
Pad these out.
#define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x0001
#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x0002
etc..
> +
> +#ifndef __ASSEMBLY__
> +
> +struct ppc_hw_breakpoint {
> + uint32_t version; /* currently, version must be 1 */
> + uint32_t trigger_type; /* only some combinations allowed */
> + uint32_t addr_mode; /* address match mode */
> + uint32_t condition_mode;/* break/watchpoint condition flags */
> + uint64_t addr; /* break/watchpoint address */
> + uint64_t addr2; /* range end or mask */
> + uint64_t condition_value; /* contents of the DVC register */
> +};
> +
> +#endif /* __ASSEMBLY__ */
> +
> +/*
> + * Trigger Type
> + */
> +#define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x1
> +#define PPC_BREAKPOINT_TRIGGER_READ 0x2
> +#define PPC_BREAKPOINT_TRIGGER_WRITE 0x4
> +#define PPC_BREAKPOINT_TRIGGER_RW0x6
(ditto on the padding)
> +
> +/*
> + * Address Mode
> + */
> +#define PPC_BREAKPOINT_MODE_EXACT0x0
> +#define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE 0x1
> +#define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE 0x2
> +#define PPC_BREAKPOINT_MODE_MASK 0x3
> +
(ditto on the padding)
> +/*
> + * Condition Mode
> + */
> +#define PPC_BREAKPOINT_CONDITION_NONE0x0
> +#define PPC_BREAKPOINT_CONDITION_AND 0x1
> +#define PPC_BREAKPOINT_CONDITION_EXACT 0x1
> +#define PPC_BREAKPOINT_CONDITION_OR 0x2
> +#define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
(ditto on the padding)
> +#define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff
> +#define PPC_BREAKPOINT_CONDITION_BE_SHIFT16
> +#define PPC_BREAKPOINT_CONDITION_BE(n) \
> + (1<<((n)+PPC_BREAKPOINT_CONDITION_BE_SHIFT))
> +
> #endif /* _ASM_POWERPC_PTRACE_H */
> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> index ef14988..6be2ce0 100644
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -839,6 +839,50 @@ void ptrace_disable(struct task_struct *child)
> user_disable_single_step(child);
> }
>
> +static long ppc_set_hwdebug(struct task_struct *child,
> + struct ppc_hw_breakpoint *bp_info)
> +{
> + /*
> + * We currently support one data breakpoint
> + */
> + if (((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0) ||
> + ((bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0) ||
> + (bp_info->trigger_type != PPC_BREAKPOINT_TRIGGER_WRITE) ||
> + (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) ||
> + (bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE))
> + return -EINVAL;
> +
> + if (ch
Re: [PATCH] powerpc/85xx: Workaround MPC8572/MPC8536 GPIO 1 errata.
On Aug 12, 2009, at 12:57 AM, Felix Radensky wrote: > On MPC8572 and MPC8536 the status of GPIO pins configured > as output cannot be determined by reading GPDAT register. > Workaround by reading the status of input pins from GPDAT > and the status of output pins from a shadow register. > > Signed-off-by: Felix Radensky > --- > arch/powerpc/sysdev/mpc8xxx_gpio.c | 21 - > 1 files changed, 20 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 03/03] powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
On Thu, Dec 10, 2009 at 01:57:27PM -0200, Dave Kleikamp wrote:
> powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
>
> From: Torez Smith
>
> This patch defines context switch and trap related functionality
> for BookE specific Debug Registers. It adds support to ptrace()
> for setting and getting BookE related Debug Registers
>
> Signed-off-by: Torez Smith
> Signed-off-by: Dave Kleikamp
> Cc: Benjamin Herrenschmidt
> Cc: Thiago Jung Bauermann
> Cc: Sergio Durigan Junior
> Cc: David Gibson
> Cc: linuxppc-dev list
> ---
>
> arch/powerpc/include/asm/system.h |2
> arch/powerpc/kernel/process.c | 109 -
> arch/powerpc/kernel/ptrace.c | 435
> ++---
> arch/powerpc/kernel/signal.c |6 -
> arch/powerpc/kernel/signal_32.c |8 +
> arch/powerpc/kernel/traps.c | 86 ++-
> 6 files changed, 564 insertions(+), 82 deletions(-)
[snip]
> +void do_send_trap(struct pt_regs *regs, unsigned long address,
> + unsigned long error_code, int signal_code, int errno)
> +{
> + siginfo_t info;
> +
> + if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
> + 11, SIGSEGV) == NOTIFY_STOP)
> + return;
> +
> + /* Deliver the signal to userspace */
> + info.si_signo = SIGTRAP;
> + info.si_errno = errno;
We're using the errno siginfo field, but not for an errno, so possibly
the parameter should be called something else.
[snip]
> +#if !(defined(CONFIG_40x) || defined(CONFIG_BOOKE))
> void do_dabr(struct pt_regs *regs, unsigned long address,
> unsigned long error_code)
> {
> @@ -257,12 +275,6 @@ void do_dabr(struct pt_regs *regs, unsigned long address,
> if (debugger_dabr_match(regs))
> return;
>
> - /* Clear the DAC and struct entries. One shot trigger */
> -#if defined(CONFIG_BOOKE)
> - mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBSR_DAC1R | DBSR_DAC1W
> - | DBCR0_IDM));
> -#endif
> -
> /* Clear the DABR */
> set_dabr(0);
Uh.. does this imply we're keeping the one-shot behaviour for
new-style breakpoints? To me the interface really suggests they're
persistent, although dealing with the semantics of that at signal time
can get curly.
>
> @@ -273,9 +285,71 @@ void do_dabr(struct pt_regs *regs, unsigned long address,
> info.si_addr = (void __user *)address;
> force_sig_info(SIGTRAP, &info, current);
> }
> +#endif
>
> static DEFINE_PER_CPU(unsigned long, current_dabr);
>
> +#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
> +/*
> + * Set the debug registers back to their default "safe" values.
> + */
> +static void set_debug_reg_defaults(struct thread_struct *thread)
> +{
> + thread->iac1 = thread->iac2 = thread->iac3 = thread->iac4 = 0;
> + thread->dac1 = thread->dac2 = 0;
> + thread->dvc1 = thread->dvc2 = 0;
> + /*
> + * reset the DBCR0, DBCR1 and DBCR2 registers. All bits with
> + * the exception of the reserved bits should be cleared out
> + * and set to 0.
> + *
> + * For the DBCR0 register, the reserved bits are bits 17:30.
> + * Reserved bits for DBCR1 are bits 10:14 and bits 26:30.
> + * And, bits 10:11 for DBCR2.
> + */
> + thread->dbcr0 = DBCR0_BASE_REG_VALUE;
Since this is now the only place it's used, I'd pull the
BASE_REG_VALUE constant inline here. Makes the actual definition sit
next to the describing comment which is a bonus.
> + /*
> + * First clear all "non reserved" bits from DBCR1 then initialize reg
> + * to force User/Supervisor bits to b11 (user-only MSR[PR]=1) and
> + * Effective/Real * bits to b10 (trap only if IS==0)
> + */
> + thread->dbcr1 = DBCR1_BASE_REG_VALUE;
> + /*
> + * Force Data Address Compare User/Supervisor bits to be User-only
> + * (0b11 MSR[PR]=1) and set all other bits in DBCR2 register to be 0.
> + * This sets the Data Address Compare Effective/Real bits to be 0b00
> + * (Effective, MSR[DS]=don't care).
> + */
> + thread->dbcr2 = DBCR2_BASE_REG_VALUE;
> +}
> +
> +static void prime_debug_regs(struct thread_struct *thread)
> +{
> + mtspr(SPRN_IAC1, thread->iac1);
> + mtspr(SPRN_IAC2, thread->iac2);
> + mtspr(SPRN_IAC3, thread->iac3);
> + mtspr(SPRN_IAC4, thread->iac4);
> + mtspr(SPRN_DAC1, thread->dac1);
> + mtspr(SPRN_DAC2, thread->dac2);
> + mtspr(SPRN_DVC1, thread->dvc1);
> + mtspr(SPRN_DVC2, thread->dvc2);
> + mtspr(SPRN_DBCR0, thread->dbcr0);
> + mtspr(SPRN_DBCR1, thread->dbcr1);
> + mtspr(SPRN_DBCR2, thread->dbcr2);
As Josh pointed out, you'll need to be a little more careful here to
only mtspr() registers which actually exist on the current platform.
We may be better off only implementing the new interface for BookE in
the first cut.
> +}
> +/*
> + * Unless neither the old or new thread are making use of
Re: [RFC:PATCH 02/03] powerpc: Add definitions for Debug Registers on BookE Platforms
On Thu, Dec 10, 2009 at 08:41:53PM -0600, Kumar Gala wrote: [snip] > > +#define DBCR1_USER_DEBUG (DBCR1_IAC12M | DBCR1_IAC34M) > > +#define DBCR1_BASE_REG_VALUE (DBCR1_IAC1US | DBCR1_IAC1ER_10 | \ > > +DBCR1_IAC2US | DBCR1_IAC2ER_10 | \ > > +DBCR1_IAC3US | DBCR1_IAC3ER_10 | \ > > +DBCR1_IAC4US | DBCR1_IAC4ER_10) > > We are we using MSR[IS] IS=0, why not just any Eff address? In the > future we might have user as IS = 1, and kernel as IS = 0. Since the user can't control that directly, we can update this when and if we change our use of address spaces. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Q: how to access the MPC5200B's timer gipo's?
On Wed, Dec 9, 2009 at 9:28 AM, Albrecht Dreà wrote:
> Hi all,
>
> I have a (probably dumb) question regarding the access to the MPC5200B's
> timer gpio's. Â I added e.g.
>
> ti...@640 { Â Â // General Purpose Timer 4
> Â Â Â Â compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> Â Â Â Â reg = <0x640 0x10>;
> Â Â Â Â interrupts = <1 13 0>;
> Â Â Â Â interrupt-parent = <&mpc5200_pic>;
> Â Â Â Â gpio-controller;
> Â Â Â Â #gpio-cells = <2>;
> };
>
> in the DTS file to several timers. Â Several gpiochipxxx folders are now
> present in /sys/class/gpio/.
>
> In my code, I grab the node by calling
> of_find_node_by_path("/soc5...@f000/ti...@640"), which returns the proper
> node. Â Then I try to get the gpio number (for a call to gpio_set_value()) by
> calling of_get_gpio(node, 0) with the node found above. Â However, this call
> always dumps
>
> of_get_gpio_flags: can't parse gpios property
> of_get_gpio_flags exited with status -2
>
> What would be the proper way to determine the gpio number for a timer's gpio
> pin from the node name or path?
The existing API (of_get_gpio()) doesn't operate on gpio-controller
nodes. It operates on a node that uses the gpio (has a 'gpios'
property as documented in
Documentation/powerpc/dts-bindings/gpio/gpio.txt).
Therefore, you need a node to describe the *user* of the GPIO pin, and
call of_get_gpio() on that. If you want to resolve the GPIO number
from the timer node itself, then you'll need to refactor the API a bit
to expose what you want. Nobody has asked to do it that way until
now.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: const intspec pointers
On Tue, Dec 8, 2009 at 7:45 PM, Benjamin Herrenschmidt wrote: > On Tue, 2009-12-08 at 13:39 +0100, Roman Fietze wrote: >> Hello, >> >> Writing a driver using SCLPC on the MPC5200B I detected, that the >> intspec arrays to map irqs to Linux virq cannot be const, because the >> mapping and xlate functions only take non const pointers. All those >> functions do not modify the intspec, so a const pointer could be used. >> >> I tried to compile that patch on different platforms and got no >> compiler errors, so I'd like to ask you to review that patch, and >> check if it's worth using it. > > Looks good. Okay by me too. Acked-by: Grant Likely g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: const intspec pointers
On Tue, Dec 8, 2009 at 5:39 AM, Roman Fietze wrote: > Hello, > > Writing a driver using SCLPC on the MPC5200B I detected, that the > intspec arrays to map irqs to Linux virq cannot be const, because the > mapping and xlate functions only take non const pointers. All those > functions do not modify the intspec, so a const pointer could be used. BTW, if you're interested, there is a driver for the SCLPC FIFO about to be merged into 2.6.33. It's in Ben's tree waiting to be pulled into mainline. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 06/11] of/flattree: merge early_init_devtree() and early_init_move_devtree()
On Wed, Nov 25, 2009 at 9:04 PM, Benjamin Herrenschmidt wrote: > On Tue, 2009-11-24 at 01:19 -0700, Grant Likely wrote: >> /** >> + * early_init_move_devtree - move tree to an unused area, if needed. >> + * >> + * The device tree may be allocated beyond our memory limit, or inside the >> + * crash kernel region for kdump. If so, move it out of the way. >> + */ >> +#if defined(CONFIG_PPC) >> +static void __init early_init_move_devtree(void) > > And you still end up with an ifdef mess in the common code ... The #ifdefs are temporary. I'm leaving them in now exactly because they are ugly and show where the code needs to be refactored and reorganized. Once everything is merged, I'll probably do exactly what you suggest. I just cannot yet tell the exact structure of it until I see the merged version. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 06/11] of/flattree: merge early_init_devtree() and early_init_move_devtree()
On Mon, Dec 7, 2009 at 12:08 AM, Jeremy Kerr wrote: > Hi Grant, > >> + /* Scan memory nodes and rebuild LMBs */ >> + lmb_init(); >> + of_scan_flat_dt(early_init_dt_scan_root, NULL); >> + of_scan_flat_dt(early_init_dt_scan_memory, NULL); >> + >> + /* Save command line for /proc/cmdline and then parse parameters */ >> + strlcpy(boot_command_line, cmd_line, COMMAND_LINE_SIZE); >> + parse_early_param(); >> + >> + /* This is in an arbitrary spot, but it is temporary. After all >> + * the common code is merged, the structure of the early init >> + * code will be reevaluated and refactored */ >> + early_init_devtree_arch(); >> + >> + lmb_analyze(); >> + lmb_dump_all(); > > So we're assuming that the arch has lmb support, or should we make this > conditional on CONFIG_HAVE_LMB? I'm not making any assumptions yet. I'm just merging the code. A lot of it needs to be refactored after the merge. Feel free to send patches to rework want you need. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] ppc440spe-adma: adds updated ppc440spe adma driver
Anatolij Gustschin wrote: This patch adds new version of the PPC440SPe ADMA driver. Signed-off-by: Yuri Tikhonov Signed-off-by: Anatolij Gustschin --- Changes since v2: - Correct Sign-offs order. - Place the driver in 'drivers/dma/ppc4xx' directory as there are wishes to extend the driver to support other CPUs (PPC460EX) later. - Don't duplicate directory name in the driver file names. - Perform checks for 'len' > PAGE_SIZE cases while looking for suitable channel for async operations so that there will be a fallback to synchronous path if a user of the api should ever submit pq_val requests with 'len' > PAGE_SIZE. Ok, please split the katmai.dts fixups to a separate patch to send to Josh as this patch has picked up new conflicts with his tree. It also appears that this is not based on my next branch [1] because the Makefile and Kconfig updates collide with the coh driver. Fix that up and I'll apply this for my pull request for 2.6.33. Thanks, Dan [1] git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git next ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
On Wed, Nov 25, 2009 at 10:27 PM, Benjamin Herrenschmidt wrote: > On Wed, 2009-11-25 at 21:05 -0700, Grant Likely wrote: >> >> You're right, it's not, but makes merging less complex, and then I can >> refactor properly. > > Still, make them __be32 at least Okay. Done. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 07/11] of: merge machine_is_compatible()
On Wed, Nov 25, 2009 at 9:05 PM, Benjamin Herrenschmidt wrote: > On Tue, 2009-11-24 at 01:19 -0700, Grant Likely wrote: >> Merge common code between PowerPC and Microblaze > > I don't like moving this one to common code without the of_ prefix. I > think you should move it with the of_ prefix, and then add a alias in > powerpc and microblaze without of_ in a header until we fix all call > sites (which you can put on your to-do list :-) I've written another patch to rename it. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of: merge of_find_node_by_phandle
On Wed, Dec 9, 2009 at 7:47 PM, Jeremy Kerr wrote: > Merge common function between powerpc, sparc and microblaze. Code is > identical for powerpc and microblaze, but adds a lock (and release) of > the devtree_lock on sparc. > > Currently untested. > > Signed-off-by: Jeremy Kerr Added to my test branch. We'll see how it shakes out. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
