* Re: Login prompt on a video console instead of serial port?
From: McClintock Matthew-B29882 @ 2011-05-02 19:55 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: linux-fbdev@vger.kernel.org, devicetree-discuss,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4DBF065C.3030407@freescale.com>
Don't you have to spawn a terminal on the framebuffer for the login?
Right now getty spawns the login on the serial port via /etc/inittab.
Something similiar is probably needed for the framebuffer.
-M
On Mon, May 2, 2011 at 2:30 PM, Timur Tabi <timur@freescale.com> wrote:
> I'm using a Freescale P1022DS (PowerPC e500 core) system, which has a bui=
lt-in
> video controller. =A0I have a framebuffer driver that works fine, and if =
I add
> "video=3Dfslfb:1280x1024-32@60,monitor=3D0 console=3Dtty0" to the command=
-line, then
> *most* of the kernel boot log appears on the serial port and the video di=
splay.
>
> However, the login prompt is always on the serial port. =A0This happens e=
ven if I
> delete the "console=3DttyS0,115200" from the command-line. =A0I presume t=
his is
> because the "linux,stdout-path" property in the device tree always points=
to a
> serial port node.
>
> So my question is: what do I need to do get the login prompt on the video
> console? =A0That is, stdout goes to /dev/fb0 but stdin is still from /dev=
/ttyS0.
> I presume I need to direct "linux,stdout-path" to the fslfb node in the d=
evice
> tree, but there doesn't appear to be support for "linux,stdin-path".=
^ permalink raw reply
* Login prompt on a video console instead of serial port?
From: Timur Tabi @ 2011-05-02 19:30 UTC (permalink / raw)
To: linuxppc-dev, devicetree-discuss, linux-fbdev
I'm using a Freescale P1022DS (PowerPC e500 core) system, which has a built-in
video controller. I have a framebuffer driver that works fine, and if I add
"video=fslfb:1280x1024-32@60,monitor=0 console=tty0" to the command-line, then
*most* of the kernel boot log appears on the serial port and the video display.
However, the login prompt is always on the serial port. This happens even if I
delete the "console=ttyS0,115200" from the command-line. I presume this is
because the "linux,stdout-path" property in the device tree always points to a
serial port node.
So my question is: what do I need to do get the login prompt on the video
console? That is, stdout goes to /dev/fb0 but stdin is still from /dev/ttyS0.
I presume I need to direct "linux,stdout-path" to the fslfb node in the device
tree, but there doesn't appear to be support for "linux,stdin-path".
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [tip:irq/urgent] genirq: Fix typo CONFIG_GENIRC_IRQ_SHOW_LEVEL
From: tip-bot for Geert Uytterhoeven @ 2011-05-02 19:18 UTC (permalink / raw)
To: linux-tip-commits; +Cc: linuxppc-dev, tglx, mingo, geert, hpa
Commit-ID: 94b2c363dcf732a4edab4ed66041cb36e7f28fbf
Gitweb: http://git.kernel.org/tip/94b2c363dcf732a4edab4ed66041cb36e7f28fbf
Author: Geert Uytterhoeven <geert@linux-m68k.org>
AuthorDate: Sat, 30 Apr 2011 22:56:20 +0200
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Mon, 2 May 2011 21:16:37 +0200
genirq: Fix typo CONFIG_GENIRC_IRQ_SHOW_LEVEL
commit ab7798ffcf98b11a9525cf65bacdae3fd58d357f ("genirq: Expand generic
show_interrupts()") added the Kconfig option GENERIC_IRQ_SHOW_LEVEL to
accomodate PowerPC, but this doesn't actually enable the functionality due
to a typo in the #ifdef check.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux/PPC Development <linuxppc-dev@lists.ozlabs.org>
Link: http://lkml.kernel.org/r/%3Calpine.DEB.2.00.1104302251370.19068%40ayla.of.borg%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
kernel/irq/proc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index dd201bd..834899f 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq/proc.c
@@ -419,7 +419,7 @@ int show_interrupts(struct seq_file *p, void *v)
} else {
seq_printf(p, " %8s", "None");
}
-#ifdef CONFIG_GENIRC_IRQ_SHOW_LEVEL
+#ifdef CONFIG_GENERIC_IRQ_SHOW_LEVEL
seq_printf(p, " %-8s", irqd_is_level_type(&desc->irq_data) ? "Level" : "Edge");
#endif
if (desc->name)
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc: add support for MPIC message register API
From: Hollis Blanchard @ 2011-05-02 16:03 UTC (permalink / raw)
To: Kushwaha Prabhakar-B32579
Cc: Meador Inge, Wood Scott-B07421,
devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org, openmcapi-dev@googlegroups.com
In-Reply-To: <071A08F2C6A57E4E94D980ECA553F8741984EE@039-SN1MPN1-004.039d.mgd.msft.net>
On 05/01/2011 08:41 PM, Kushwaha Prabhakar-B32579 wrote:
>>>>> Hi,
>>>>>
>>>>> I have no comments about coding and architecture. It looks fine.
>>>>>
>>>>> Only have a query about its use case..
>>>>> "Any application intended to use message interrupt requires to
>>>>> know
>>>> reg_num because of struct mpic_msgr* mpic_msgr_get(unsigned int
>>>> reg_num) API"
>>>>> It will be good to search available unit internally and provide
>>>>> its
>>>> pointer. It will make application more flexible.
>>>> The problem is that you fundamentally cannot implement an allocator
>>>> for MSG registers if you're going to communicate with another kernel
>>>> (how would both kernels' allocators be synchronized?). So the
>>>> message register allocation must be decided at design time, not run time.
>>> I agree with you.. It is true while communicating with another kernel.
>>> But message interrupts can be used by different independent drivers
>> within same kernel. For eg. PCIe and Ethernet driver.
>>> As per current design both drivers needs to be in sync before
>> requesting any message unit for avoiding any conflict. As these drivers
>> are completely independent. It is very difficult.
>>> Can it be possible to provide new API to take care it.
>> Do you have a real use case in mind where these message registers (not
>> MSIs) are used internally in this manner?
> Yes, we use for PCIe host/agent test case scenario.
> Host usage message register to interrupt Agent...
> Agent uses message register to generate irq_out (automatically generate MSI) to interrupt master. Please see RM for more details about irq_out
>
>
> Note: PCIe host/agent test scenario is used internally and we are working on pushing it out..
I believe this has been true for several years.
>> Perhaps an allocator could be added in the same patchset that adds such a
>> user.
> Yaa. It can be done. Otherwise module has to query each message unit for its availability.
No, instead the system designer should pick one. If it doesn't matter
which one, then the designer is free to pick any.
An allocator can't work if you're going to mix drivers. For example,
driver A needs MSRG0, and driver B doesn't care. Driver B loads first,
the allocator selects MSGR0; driver A loads and fails. Having an
allocator at all will create this conflict.
To prevent this scenario, either don't use a MSGR (can you configure
anything else for irq_out?), or have the system designer choose all MSGRs.
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: Read/write BCSR registers of PPC460EX
From: Stefan Roese @ 2011-05-02 13:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev
In-Reply-To: <31523658.post@talk.nabble.com>
Hi Efti,
On Monday 02 May 2011 15:36:15 linuxppc-dev wrote:
> Dear Stefan,
>
> I have changed CPLD/BCSR address with 0x4E1000000.
>
> static unsigned long mem_addr = 0x4E1000000;
Thats a 64bit address, so you need this:
static unsigned long long mem_addr = 0x4E1000000ULL;
You should have seen a compilation warning about this too.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: Read/write BCSR registers of PPC460EX
From: linuxppc-dev @ 2011-05-02 13:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <201105021453.32775.sr@denx.de>
Dear Stefan,
I have changed CPLD/BCSR address with 0x4E1000000.
static unsigned long mem_addr = 0x4E1000000;
But still I get the Machine check error When I load my module. I have posted
the error Message below.
Error Message
-------------
<4>minimod: module license 'unspecified' taints kernel.
<4>Disabling lock debugging due to kernel taint
<4>ioremap: Virtual Address e8f20000
<4>Machine check in kernel mode.
<4>Data Read PLB Error
<4>Oops: Machine check, sig: 7 [#1]
<4>PowerPC 44x Platform
<4>Modules linked in: minimod(P+)
<4>NIP: e4ff60ec LR: e4ff60d8 CTR: c0167174
<4>REGS: dfff7f10 TRAP: 0214 Tainted: P (2.6.30.3)
<4>MSR: 00029000 <EE,ME,CE> CR: 24000028 XER: 20000007
<4>TASK = de518000[956] 'insmod' THREAD: da282000
<6>GPR00: e4ff60d8 da283e90 de518000 00000025 00000000 ffffffff c01646c8
0000321d
<6>GPR08: 00000000 e8f20000 0000321d 00004000 44000022 101c0dac 100ab618
10095434
<6>GPR16: 100f0000 100f0000 bfee5eec 00000002 bfee5ef0 00000000 101ebf80
bfd0c274
<6>GPR24: 10130a48 00000000 c0350000 c0326008 c0326014 e4ff0000 da282000
e4ff6524
<4>NIP [e4ff60ec] io_driver_init+0x9c/0x150 [minimod]
<4>LR [e4ff60d8] io_driver_init+0x88/0x150 [minimod]
<4>Call Trace:
<4>[da283e90] [e4ff60d8] io_driver_init+0x88/0x150 [minimod] (unreliable)
<4>[da283eb0] [c00013d8] do_one_initcall+0x34/0x1a0
<4>[da283f20] [c004dc14] sys_init_module+0xb0/0x1b8
<4>[da283f40] [c000de8c] ret_from_syscall+0x0/0x3c
<4>Instruction dump:
<4>7c601b78 3c60e4ff 3fa0e4ff 386361ec 7c040378 901d6658 4800007d 813d6658
<4>2f890000 419e004c 7c0004ac 80890000 <0c040000> 4c00012c 3c60e4ff 3863621c
<4>---[ end trace 0af1ade6d5d6a053 ]---
Thanks,
Efti
Stefan Roese wrote:
>
> On Monday 02 May 2011 14:40:39 Josh Boyer wrote:
>> >static unsigned long mem_addr = 0xC0000000;// IP base address
>>
>> Is this the correct address for the BCSR? On the 460EX Canyonlands
>> board, the CPLD/BCSR is at 0xE1000000.
>
> To be precise: It's 0x4.e100.0000 as 36bit physical address.
>
> Cheers,
> Stefan
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
--
View this message in context: http://old.nabble.com/Read-write-BCSR-registers-of-PPC460EX-tp31522823p31523658.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Read/write BCSR registers of PPC460EX
From: Stefan Roese @ 2011-05-02 12:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, linuxppc-dev
In-Reply-To: <20110502124039.GB3269@zod.rchland.ibm.com>
On Monday 02 May 2011 14:40:39 Josh Boyer wrote:
> >static unsigned long mem_addr = 0xC0000000;// IP base address
>
> Is this the correct address for the BCSR? On the 460EX Canyonlands
> board, the CPLD/BCSR is at 0xE1000000.
To be precise: It's 0x4.e100.0000 as 36bit physical address.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: Read/write BCSR registers of PPC460EX
From: Josh Boyer @ 2011-05-02 12:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev
In-Reply-To: <31522823.post@talk.nabble.com>
On Mon, May 02, 2011 at 04:50:30AM -0700, linuxppc-dev wrote:
>
>Hi,
>
>I am trying to read the BCSR register of my PPC460ex board.But when I load
>the module, then I get the "Machine Check Error".
>
>I am not sure if I missed out something.
>
>I would really appreciate it if somebody could help me on this.
>
>I have posted the source code below, as well as the complete message.
>
>Thanks,
>efti
>
>Source code
>------------
>
>#include <linux/init.h> // to use module_init and module_exit
>#include <linux/module.h>// macros for modules
>#include <linux/kernel.h>
>#include <linux/ioport.h>
>#include <linux/errno.h>
>#include <asm/io.h>
>
>static unsigned int reg1 = 1; // test data
>static unsigned int reg2 = 2; // test data
>static unsigned int reg3 = 3; // test data
>static unsigned int *virtual_base = 0; // remapped address
>static unsigned long mem_addr = 0xC0000000;// IP base address
Is this the correct address for the BCSR? On the 460EX Canyonlands
board, the CPLD/BCSR is at 0xE1000000.
>static unsigned long mem_size = 0x10000; // 64KB
>
>int io_driver_init(void)
>{
> int i;
> if(check_mem_region(mem_addr,mem_size))
> {
> printk("simp_mult: memory already in use\n");
> return -EBUSY;
> }
> // request memory for the device
> request_mem_region(mem_addr,mem_size,"simp_mult");
> // remap
> virtual_base = ioremap(mem_addr,mem_size);
> printk("ioremap: Virtual Address %08x\n",(unsigned int)virtual_base);
> if( virtual_base==0 )
> {
> printk("ioremap failed\n");
> return -EBUSY ;
> }
> else
> {
>
> unsigned int value;
> value = in_be32(virtual_base);
> printk("Data to Read : %08x\n",value);
>
> return 0; // indicate a success
> }
>}
Aside from minor things like using unsigned int instead of unsigned
long, the code looks correct. The thing to check is if you are
ioremapping the right physical address, and making sure you're reading a
proper location.
josh
^ permalink raw reply
* Read/write BCSR registers of PPC460EX
From: linuxppc-dev @ 2011-05-02 11:50 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am trying to read the BCSR register of my PPC460ex board.But when I load
the module, then I get the "Machine Check Error".
I am not sure if I missed out something.
I would really appreciate it if somebody could help me on this.
I have posted the source code below, as well as the complete message.
Thanks,
efti
Source code
------------
#include <linux/init.h> // to use module_init and module_exit
#include <linux/module.h>// macros for modules
#include <linux/kernel.h>
#include <linux/ioport.h>
#include <linux/errno.h>
#include <asm/io.h>
static unsigned int reg1 = 1; // test data
static unsigned int reg2 = 2; // test data
static unsigned int reg3 = 3; // test data
static unsigned int *virtual_base = 0; // remapped address
static unsigned long mem_addr = 0xC0000000;// IP base address
static unsigned long mem_size = 0x10000; // 64KB
int io_driver_init(void)
{
int i;
if(check_mem_region(mem_addr,mem_size))
{
printk("simp_mult: memory already in use\n");
return -EBUSY;
}
// request memory for the device
request_mem_region(mem_addr,mem_size,"simp_mult");
// remap
virtual_base = ioremap(mem_addr,mem_size);
printk("ioremap: Virtual Address %08x\n",(unsigned int)virtual_base);
if( virtual_base==0 )
{
printk("ioremap failed\n");
return -EBUSY ;
}
else
{
unsigned int value;
value = in_be32(virtual_base);
printk("Data to Read : %08x\n",value);
return 0; // indicate a success
}
}
void io_driver_exit(void)
{
printk("Release Memory Region...\n") ;
iounmap(virtual_base) ;
release_mem_region(mem_addr,mem_size) ;
}
module_init(io_driver_init);
module_exit(io_driver_exit);
--
View this message in context: http://old.nabble.com/Read-write-BCSR-registers-of-PPC460EX-tp31522823p31522823.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH 2/2] powerpc: Save Come-From Address Register (CFAR) in exception frame
From: Paul Mackerras @ 2011-05-02 5:48 UTC (permalink / raw)
To: linuxppc-dev
Recent 64-bit server processors (POWER6 and POWER7) have a "Come-From
Address Register" (CFAR), that records the address of the most recent
branch or rfid (return from interrupt) instruction for debugging purposes.
This saves the value of the CFAR in the exception entry code and stores
it in the exception frame. We also make xmon print the CFAR value in
its register dump code.
Rather than extend the pt_regs struct at this time, we steal the orig_gpr3
field, which is only used for system calls, and use it for the CFAR value
for all exceptions/interrupts other than system calls. This means we
don't save the CFAR on system calls, which is not a great problem since
system calls tend not to happen unexpectedly, and also avoids adding the
overhead of reading the CFAR to the system call entry path.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/cputable.h | 6 ++++--
arch/powerpc/include/asm/exception-64s.h | 9 +++++++++
arch/powerpc/include/asm/paca.h | 6 +++---
arch/powerpc/include/asm/reg.h | 1 +
arch/powerpc/kernel/exceptions-64s.S | 4 ++++
arch/powerpc/xmon/xmon.c | 4 ++++
6 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 3db2476..b0069ed 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -197,6 +197,7 @@ extern const char *powerpc_base_platform;
#define CPU_FTR_STCX_CHECKS_ADDRESS LONG_ASM_CONST(0x0200000000000000)
#define CPU_FTR_POPCNTB LONG_ASM_CONST(0x0400000000000000)
#define CPU_FTR_POPCNTD LONG_ASM_CONST(0x0800000000000000)
+#define CPU_FTR_CFAR LONG_ASM_CONST(0x1000000000000000)
#ifndef __ASSEMBLY__
@@ -411,14 +412,15 @@ extern const char *powerpc_base_platform;
CPU_FTR_COHERENT_ICACHE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD | \
- CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB)
+ CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_CFAR)
#define CPU_FTRS_POWER7 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_HVMODE_206 |\
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT | \
- CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD)
+ CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD |\
+ CPU_FTR_CFAR)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 96ccef1..f5dfe34 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -46,6 +46,7 @@
#define EX_CCR 60
#define EX_R3 64
#define EX_LR 72
+#define EX_CFAR 80
/*
* We're short on space and time in the exception prolog, so we can't
@@ -66,6 +67,10 @@
std r10,area+EX_R10(r13); \
std r11,area+EX_R11(r13); \
std r12,area+EX_R12(r13); \
+ BEGIN_FTR_SECTION_NESTED(66); \
+ mfspr r10,SPRN_CFAR; \
+ std r10,area+EX_CFAR(r13); \
+ END_FTR_SECTION_NESTED(CPU_FTR_CFAR, CPU_FTR_CFAR, 66); \
GET_SCRATCH0(r9); \
std r9,area+EX_R13(r13); \
mfcr r9
@@ -130,6 +135,10 @@
std r9,GPR11(r1); \
std r10,GPR12(r1); \
std r11,GPR13(r1); \
+ BEGIN_FTR_SECTION_NESTED(66); \
+ ld r10,area+EX_CFAR(r13); \
+ std r10,ORIG_GPR3(r1); \
+ END_FTR_SECTION_NESTED(CPU_FTR_CFAR, CPU_FTR_CFAR, 66); \
ld r2,PACATOC(r13); /* get kernel TOC into r2 */ \
mflr r9; /* save LR in stackframe */ \
std r9,_LINK(r1); \
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 65c13c4..7412676 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -92,9 +92,9 @@ struct paca_struct {
* Now, starting in cacheline 2, the exception save areas
*/
/* used for most interrupts/exceptions */
- u64 exgen[10] __attribute__((aligned(0x80)));
- u64 exmc[10]; /* used for machine checks */
- u64 exslb[10]; /* used for SLB/segment table misses
+ u64 exgen[11] __attribute__((aligned(0x80)));
+ u64 exmc[11]; /* used for machine checks */
+ u64 exslb[11]; /* used for SLB/segment table misses
* on the linear mapping */
/* SLB related definitions */
u16 vmalloc_sllp;
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 1f9ac12..47e3416 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -188,6 +188,7 @@
#define SPRN_CTR 0x009 /* Count Register */
#define SPRN_DSCR 0x11
+#define SPRN_CFAR 0x1c /* Come From Address Register */
#define SPRN_CTRLF 0x088
#define SPRN_CTRLT 0x098
#define CTRL_CT 0xc0000000 /* current thread */
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 27ca8b7..0ec3b42 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -474,6 +474,10 @@ bad_stack:
std r9,GPR11(r1)
std r10,GPR12(r1)
std r11,GPR13(r1)
+BEGIN_FTR_SECTION
+ ld r10,EX_CFAR(r3)
+ std r10,ORIG_GPR3(r1)
+END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
SAVE_8GPRS(14,r1)
SAVE_10GPRS(22,r1)
lhz r12,PACA_TRAP_SAVE(r13)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 60593ad..909804a 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1497,6 +1497,10 @@ static void prregs(struct pt_regs *fp)
#endif
printf("pc = ");
xmon_print_symbol(fp->nip, " ", "\n");
+ if (TRAP(fp) != 0xc00 && cpu_has_feature(CPU_FTR_CFAR)) {
+ printf("cfar= ");
+ xmon_print_symbol(fp->orig_gpr3, " ", "\n");
+ }
printf("lr = ");
xmon_print_symbol(fp->link, " ", "\n");
printf("msr = "REG" cr = %.8lx\n", fp->msr, fp->ccr);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] powerpc: Save register r9-r13 values accurately on interrupt with bad stack
From: Paul Mackerras @ 2011-05-02 5:46 UTC (permalink / raw)
To: linuxppc-dev
When we take an interrupt or exception from kernel mode and the stack
pointer is obviously not a kernel address (i.e. the top bit is 0), we
switch to an emergency stack, save register values and panic. However,
on 64-bit server machines, we don't actually save the values of r9 - r13
at the time of the interrupt, but rather values corrupted by the
exception entry code for r12-r13, and nothing at all for r9-r11.
This fixes it by passing a pointer to the register save area in the paca
through to the bad_stack code in r3. The register values are saved in
one of the paca register save areas (depending on which exception this
is). Using the pointer in r3, the bad_stack code now retrieves the
saved values of r9 - r13 and stores them in the exception frame on the
emergency stack. This also stores the normal exception frame marker
("regshere") in the exception frame.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/exception-64s.h | 7 ++++---
arch/powerpc/kernel/exceptions-64s.S | 20 +++++++++++++++++---
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index d6b4849..96ccef1 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -104,10 +104,11 @@
beq- 1f; \
ld r1,PACAKSAVE(r13); /* kernel stack to use */ \
1: cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
- bge- cr1,2f; /* abort if it is */ \
- b 3f; \
-2: li r1,(n); /* will be reloaded later */ \
+ blt+ cr1,3f; /* abort if it is */ \
+ li r1,(n); /* will be reloaded later */ \
sth r1,PACA_TRAP_SAVE(r13); \
+ std r3,area+EX_R3(r13); \
+ addi r3,r13,area; /* r3 -> where regs are saved*/ \
b bad_stack; \
3: std r9,_CCR(r1); /* save CR in stackframe */ \
std r11,_NIP(r1); /* save SRR0 in stackframe */ \
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 226cc8c..27ca8b7 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -461,9 +461,20 @@ bad_stack:
std r12,_XER(r1)
SAVE_GPR(0,r1)
SAVE_GPR(2,r1)
- SAVE_4GPRS(3,r1)
- SAVE_2GPRS(7,r1)
- SAVE_10GPRS(12,r1)
+ ld r10,EX_R3(r3)
+ std r10,GPR3(r1)
+ SAVE_GPR(4,r1)
+ SAVE_4GPRS(5,r1)
+ ld r9,EX_R9(r3)
+ ld r10,EX_R10(r3)
+ SAVE_2GPRS(9,r1)
+ ld r9,EX_R11(r3)
+ ld r10,EX_R12(r3)
+ ld r11,EX_R13(r3)
+ std r9,GPR11(r1)
+ std r10,GPR12(r1)
+ std r11,GPR13(r1)
+ SAVE_8GPRS(14,r1)
SAVE_10GPRS(22,r1)
lhz r12,PACA_TRAP_SAVE(r13)
std r12,_TRAP(r1)
@@ -472,6 +483,9 @@ bad_stack:
li r12,0
std r12,0(r11)
ld r2,PACATOC(r13)
+ ld r11,exception_marker@toc(r2)
+ std r12,RESULT(r1)
+ std r11,STACK_FRAME_OVERHEAD-16(r1)
1: addi r3,r1,STACK_FRAME_OVERHEAD
bl .kernel_bad_stack
b 1b
--
1.7.4.1
^ permalink raw reply related
* RE: [PATCH 2/2] powerpc: add support for MPIC message register API
From: Kushwaha Prabhakar-B32579 @ 2011-05-02 3:41 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Meador Inge, openmcapi-dev@googlegroups.com,
devicetree-discuss@lists.ozlabs.org, Hollis Blanchard,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110429123051.4ed1ca01@schlenkerla.am.freescale.net>
>=20
> >
> >
> > > > Hi,
> > > >
> > > > I have no comments about coding and architecture. It looks fine.
> > > >
> > > > Only have a query about its use case..
> > > > "Any application intended to use message interrupt requires to
> > > > know
> > > reg_num because of struct mpic_msgr* mpic_msgr_get(unsigned int
> > > reg_num) API"
> > > >
> > > > It will be good to search available unit internally and provide
> > > > its
> > > pointer. It will make application more flexible.
> > > >
> > >
> > > The problem is that you fundamentally cannot implement an allocator
> > > for MSG registers if you're going to communicate with another kernel
> > > (how would both kernels' allocators be synchronized?). So the
> > > message register allocation must be decided at design time, not run
> time.
> > >
> >
> > I agree with you.. It is true while communicating with another kernel.
> > But message interrupts can be used by different independent drivers
> within same kernel. For eg. PCIe and Ethernet driver.
> > As per current design both drivers needs to be in sync before
> requesting any message unit for avoiding any conflict. As these drivers
> are completely independent. It is very difficult.
> >
> > Can it be possible to provide new API to take care it.
>=20
> Do you have a real use case in mind where these message registers (not
> MSIs) are used internally in this manner?
Yes, we use for PCIe host/agent test case scenario.
Host usage message register to interrupt Agent...
Agent uses message register to generate irq_out (automatically generate MSI=
) to interrupt master. Please see RM for more details about irq_out
=20
Note: PCIe host/agent test scenario is used internally and we are working o=
n pushing it out..
=20
> Perhaps an allocator could be added in the same patchset that adds such a
> user.
>=20
Yaa. It can be done. Otherwise module has to query each message unit for it=
s availability.=20
--Prabhakar
^ permalink raw reply
* linux module cannot read/write BSCR Register.
From: linuxppc-dev @ 2011-05-01 11:43 UTC (permalink / raw)
To: linuxppc-dev
Dear,
I am trying to write embedded linux kernel module to get the value of BCSR
registers for ppc460ex .
I am a newbie. How I access the BCSR register.
Thanks,
Efti
--
View this message in context: http://old.nabble.com/linux-module-cannot-read-write-BSCR-Register.-tp31516688p31516688.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* linux module cannot read/write BSCR Register
From: Eftakhar Chowdhury @ 2011-05-01 11:56 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 184 bytes --]
Dear,
I am trying to write embedded linux kernel module to get the value of BCSR registers for ppc460ex .
I am a newbie. How I access the BCSR register.
Thanks,
Efti
[-- Attachment #2: Type: text/html, Size: 314 bytes --]
^ permalink raw reply
* RE: [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX
From: Tirumala Marri @ 2011-05-01 4:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Ayman El-Khashab; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1304109476.2513.243.camel@pasglop>
I'm tempted to put it in if Tirumala doesn't get to review it asap.
[Marri] Sorry for the late response. I don't see any issue with changes,
please go ahead.
^ permalink raw reply
* [PATCH] genirq: Fix typo CONFIG_GENIRC_IRQ_SHOW_LEVEL
From: Geert Uytterhoeven @ 2011-04-30 20:56 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linux/PPC Development, Linux Kernel Development
commit ab7798ffcf98b11a9525cf65bacdae3fd58d357f ("genirq: Expand generic
show_interrupts()") added the Kconfig option GENERIC_IRQ_SHOW_LEVEL to
accomodate PowerPC, but this doesn't actually enable the functionality due
to a typo in the #ifdef check.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
kernel/irq/proc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index dd201bd..834899f 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq/proc.c
@@ -419,7 +419,7 @@ int show_interrupts(struct seq_file *p, void *v)
} else {
seq_printf(p, " %8s", "None");
}
-#ifdef CONFIG_GENIRC_IRQ_SHOW_LEVEL
+#ifdef CONFIG_GENERIC_IRQ_SHOW_LEVEL
seq_printf(p, " %-8s", irqd_is_level_type(&desc->irq_data) ? "Level" : "Edge");
#endif
if (desc->name)
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply related
* Re: [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX
From: Benjamin Herrenschmidt @ 2011-04-29 20:37 UTC (permalink / raw)
To: Ayman El-Khashab; +Cc: Tirumala Marri, Paul Mackerras, linuxppc-dev
In-Reply-To: <20110429170240.GA21384@crust.elkhashab.com>
On Fri, 2011-04-29 at 12:02 -0500, Ayman El-Khashab wrote:
> On Tue, Apr 12, 2011 at 07:09:49PM -0700, Tirumala Marri wrote:
> > You originally submitted the support for 460ex. Can you chime in (and
> > review Ayman patch) please ?
> >
> > [Marri] Ben sure I will review it and send you my feedback in couple of
> > days.
>
> Is there any update on this patch? Any comment? Any reason it _cant_
> be included?
I'm tempted to put it in if Tirumala doesn't get to review it asap.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 0/6] General device tree irq domain infrastructure
From: Grant Likely @ 2011-04-29 17:43 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Michal Simek, devicetree-discuss, x86, linux-kernel, Ralf Baechle,
hpa, Dirk Brandewie, Thomas Gleixner, linuxppc-dev
In-Reply-To: <4DBAE461.7000307@linutronix.de>
On Fri, Apr 29, 2011 at 06:16:33PM +0200, Sebastian Andrzej Siewior wrote:
> Grant Likely wrote:
> >I'd really like to get patches 1-4 merged into 2.6.40. Please test.
> >I'm also running through build testing here, and when it's complete
> >I'll push it out to a 'devicetree/irq-domain' branch on
> >git://git.secretlab.ca/git/linux-2.6
>
> I pulled this, built and booted my x86-dt box and nothing exploded so far.
>
> If you merge Linus' tree then you will get a conflict (sooner or later) in
> ioapic_of_irq_map() in arch/x86/kernel/devicetree.c:
>
> - return io_apic_setup_irq_pin_once(*out_hwirq, cpu_to_node(0), &attr);
> - if (io_apic_setup_irq_pin(hwirq, cpu_to_node(0), &attr))
> ++ if (io_apic_setup_irq_pin_once(hwirq, cpu_to_node(0), &attr))
>
> Sebastian
Thanks Sebastian. Unless you say otherwise, I'll take that as an Acked-by. :-)
g.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: add support for MPIC message register API
From: Scott Wood @ 2011-04-29 17:30 UTC (permalink / raw)
To: Kushwaha Prabhakar-B32579
Cc: Meador Inge, openmcapi-dev@googlegroups.com,
devicetree-discuss@lists.ozlabs.org, Hollis Blanchard,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <071A08F2C6A57E4E94D980ECA553F8741967EC@039-SN1MPN1-004.039d.mgd.msft.net>
On Fri, 29 Apr 2011 17:27:06 +0000
Kushwaha Prabhakar-B32579 <B32579@freescale.com> wrote:
>
>
> > > Hi,
> > >
> > > I have no comments about coding and architecture. It looks fine.
> > >
> > > Only have a query about its use case..
> > > "Any application intended to use message interrupt requires to know
> > reg_num because of struct mpic_msgr* mpic_msgr_get(unsigned int reg_num)
> > API"
> > >
> > > It will be good to search available unit internally and provide its
> > pointer. It will make application more flexible.
> > >
> >
> > The problem is that you fundamentally cannot implement an allocator for
> > MSG registers if you're going to communicate with another kernel (how
> > would both kernels' allocators be synchronized?). So the message register
> > allocation must be decided at design time, not run time.
> >
>
> I agree with you.. It is true while communicating with another kernel.
> But message interrupts can be used by different independent drivers within same kernel. For eg. PCIe and Ethernet driver.
> As per current design both drivers needs to be in sync before requesting any message unit for avoiding any conflict. As these drivers are completely independent. It is very difficult.
>
> Can it be possible to provide new API to take care it.
Do you have a real use case in mind where these message registers (not
MSIs) are used internally in this manner?
Perhaps an allocator could be added in the same patchset that adds such a
user.
-Scott
^ permalink raw reply
* RE: [PATCH 2/2] powerpc: add support for MPIC message register API
From: Kushwaha Prabhakar-B32579 @ 2011-04-29 17:27 UTC (permalink / raw)
To: Hollis Blanchard
Cc: Meador Inge, openmcapi-dev@googlegroups.com,
devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4DBAED5D.4060906@mentor.com>
> > Hi,
> >
> > I have no comments about coding and architecture. It looks fine.
> >
> > Only have a query about its use case..
> > "Any application intended to use message interrupt requires to know
> reg_num because of struct mpic_msgr* mpic_msgr_get(unsigned int reg_num)
> API"
> >
> > It will be good to search available unit internally and provide its
> pointer. It will make application more flexible.
> >
>=20
> The problem is that you fundamentally cannot implement an allocator for
> MSG registers if you're going to communicate with another kernel (how
> would both kernels' allocators be synchronized?). So the message register
> allocation must be decided at design time, not run time.
>=20
I agree with you.. It is true while communicating with another kernel.
But message interrupts can be used by different independent drivers within =
same kernel. For eg. PCIe and Ethernet driver.=20
As per current design both drivers needs to be in sync before requesting an=
y message unit for avoiding any conflict. As these drivers are completely i=
ndependent. It is very difficult.=20
Can it be possible to provide new API to take care it.
--Prabhakar
^ permalink raw reply
* Re: [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX
From: Ayman El-Khashab @ 2011-04-29 17:02 UTC (permalink / raw)
To: Tirumala Marri; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <178c7df4696bacdd1510bacae143222a@mail.gmail.com>
On Tue, Apr 12, 2011 at 07:09:49PM -0700, Tirumala Marri wrote:
> You originally submitted the support for 460ex. Can you chime in (and
> review Ayman patch) please ?
>
> [Marri] Ben sure I will review it and send you my feedback in couple of
> days.
Is there any update on this patch? Any comment? Any reason it _cant_
be included?
Thanks
Ayman
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: add support for MPIC message register API
From: Hollis Blanchard @ 2011-04-29 16:54 UTC (permalink / raw)
To: Kushwaha Prabhakar-B32579
Cc: Meador Inge, openmcapi-dev@googlegroups.com,
devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <071A08F2C6A57E4E94D980ECA553F8741959CA@039-SN1MPN1-004.039d.mgd.msft.net>
On 04/28/2011 10:00 PM, Kushwaha Prabhakar-B32579 wrote:
> Hi,
>
> I have no comments about coding and architecture. It looks fine.
>
> Only have a query about its use case..
> "Any application intended to use message interrupt requires to know reg_num because of struct mpic_msgr* mpic_msgr_get(unsigned int reg_num) API"
>
> It will be good to search available unit internally and provide its pointer. It will make application more flexible.
>
The problem is that you fundamentally cannot implement an allocator for
MSG registers if you're going to communicate with another kernel (how
would both kernels' allocators be synchronized?). So the message
register allocation must be decided at design time, not run time.
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: [PATCH 0/6] General device tree irq domain infrastructure
From: Sebastian Andrzej Siewior @ 2011-04-29 16:16 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, devicetree-discuss, x86, linux-kernel, Ralf Baechle,
hpa, Dirk Brandewie, Thomas Gleixner, linuxppc-dev
In-Reply-To: <20110428192227.8979.49181.stgit@ponder>
Grant Likely wrote:
> I'd really like to get patches 1-4 merged into 2.6.40. Please test.
> I'm also running through build testing here, and when it's complete
> I'll push it out to a 'devicetree/irq-domain' branch on
> git://git.secretlab.ca/git/linux-2.6
I pulled this, built and booted my x86-dt box and nothing exploded so far.
If you merge Linus' tree then you will get a conflict (sooner or later) in
ioapic_of_irq_map() in arch/x86/kernel/devicetree.c:
- return io_apic_setup_irq_pin_once(*out_hwirq, cpu_to_node(0), &attr);
- if (io_apic_setup_irq_pin(hwirq, cpu_to_node(0), &attr))
++ if (io_apic_setup_irq_pin_once(hwirq, cpu_to_node(0), &attr))
Sebastian
^ permalink raw reply
* Kernel cannot see PCI device on 460EX
From: Prashant Bhole @ 2011-04-29 10:22 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
Hi,
I have a custom made 460EX board. On that board u-boot can see a PCI device
but linux kernel cannot see it. What could be the problem?
On u-boot "pci 2" commands displays following device:
Scanning PCI devices on bus 2
BusDevFun VendorId DeviceId Device Class Sub-Class
_____________________________________________________________
02.00.00 0x1000 0x0072 Mass storage controller 0x00
And when linux is booted there is only one pci device (bridge):
#ls /sys/bus/pci/devices
0000:80:00.0
Thanks in advance.
-Prashant
[-- Attachment #2: Type: text/html, Size: 781 bytes --]
^ permalink raw reply
* RE: [PATCH 2/2] powerpc: add support for MPIC message register API
From: Kushwaha Prabhakar-B32579 @ 2011-04-29 5:00 UTC (permalink / raw)
To: Meador Inge
Cc: openmcapi-dev@googlegroups.com, linuxppc-dev@lists.ozlabs.org,
devicetree-discuss@lists.ozlabs.org, Hollis Blanchard
In-Reply-To: <1303232375-25014-3-git-send-email-meador_inge@mentor.com>
Hi,
I have no comments about coding and architecture. It looks fine.
Only have a query about its use case..
"Any application intended to use message interrupt requires to know reg_n=
um because of struct mpic_msgr* mpic_msgr_get(unsigned int reg_num) API"
It will be good to search available unit internally and provide its pointer=
. It will make application more flexible.=20
Regards,
Prabhakar
> -----Original Message-----
> From: devicetree-discuss-bounces+b32579=3Dfreescale.com@lists.ozlabs.org
> [mailto:devicetree-discuss-bounces+b32579=3Dfreescale.com@lists.ozlabs.or=
g]
> On Behalf Of Meador Inge
> Sent: Tuesday, April 19, 2011 10:30 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: openmcapi-dev@googlegroups.com; devicetree-discuss@lists.ozlabs.org;
> Hollis Blanchard
> Subject: [PATCH 2/2] powerpc: add support for MPIC message register API
>=20
> Some MPIC implementations contain one or more blocks of message registers
> that are used to send messages between cores via IPIs. A simple API has
> been added to access (get/put, read, write, etc ...) these message
> registers.
> The available message registers are initially discovered via nodes in the
> device tree. A separate commit contains a binding for the message
> register nodes.
>=20
> Signed-off-by: Meador Inge <meador_inge@mentor.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Hollis Blanchard <hollis_blanchard@mentor.com>
> ---
> arch/powerpc/include/asm/mpic_msgr.h | 35 +++++
> arch/powerpc/platforms/Kconfig | 8 +
> arch/powerpc/sysdev/Makefile | 3 +-
> arch/powerpc/sysdev/mpic_msgr.c | 279
> ++++++++++++++++++++++++++++++++++
> 4 files changed, 324 insertions(+), 1 deletions(-) create mode 100644
> arch/powerpc/include/asm/mpic_msgr.h
> create mode 100644 arch/powerpc/sysdev/mpic_msgr.c
>=20
> diff --git a/arch/powerpc/include/asm/mpic_msgr.h
> b/arch/powerpc/include/asm/mpic_msgr.h
> new file mode 100644
> index 0000000..370dcb4
> --- /dev/null
> +++ b/arch/powerpc/include/asm/mpic_msgr.h
> @@ -0,0 +1,35 @@
> +/*
> + * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; version 2 of the
> + * License.
> + *
> + */
> +
> +#ifndef _ASM_MPIC_MSGR_H
> +#define _ASM_MPIC_MSGR_H
> +
> +#include <linux/types.h>
> +
> +struct mpic_msgr {
> + u32 __iomem *addr;
> + u32 __iomem *mer;
> + u32 __iomem *msr;
> + int irq;
> + atomic_t in_use;
> + int num;
> +};
> +
> +extern struct mpic_msgr* mpic_msgr_get(unsigned int reg_num); extern
> +void mpic_msgr_put(struct mpic_msgr* msgr); extern void
> +mpic_msgr_enable(struct mpic_msgr *msgr); extern void
> +mpic_msgr_disable(struct mpic_msgr *msgr); extern void
> +mpic_msgr_write(struct mpic_msgr *msgr, u32 message); extern u32
> +mpic_msgr_read(struct mpic_msgr *msgr); extern void
> +mpic_msgr_clear(struct mpic_msgr *msgr); extern void
> +mpic_msgr_set_destination(struct mpic_msgr *msgr, u32 cpu_num); extern
> +int mpic_msgr_get_irq(struct mpic_msgr *msgr);
> +
> +#endif
> diff --git a/arch/powerpc/platforms/Kconfig
> b/arch/powerpc/platforms/Kconfig index f7b0772..4d65593 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -78,6 +78,14 @@ config MPIC_WEIRD
> bool
> default n
>=20
> +config MPIC_MSGR
> + bool "MPIC message register support"
> + depends on MPIC
> + default n
> + help
> + Enables support for the MPIC message registers. These
> + registers are used for inter-processor communication.
> +
> config PPC_I8259
> bool
> default n
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index 1e0c933..6d40185 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -3,7 +3,8 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) :=3D -Werror
> ccflags-$(CONFIG_PPC64) :=3D -mno-minimal-toc
>=20
> mpic-msi-obj-$(CONFIG_PCI_MSI) +=3D mpic_msi.o mpic_u3msi.o
> mpic_pasemi_msi.o
> -obj-$(CONFIG_MPIC) +=3D mpic.o $(mpic-msi-obj-y)
> +mpic-msgr-obj-$(CONFIG_MPIC_MSGR) +=3D mpic_msgr.o
> +obj-$(CONFIG_MPIC) +=3D mpic.o $(mpic-msi-obj-y) $(mpic-msgr-
> obj-y)
> fsl-msi-obj-$(CONFIG_PCI_MSI) +=3D fsl_msi.o
> obj-$(CONFIG_PPC_MSI_BITMAP) +=3D msi_bitmap.o
>=20
> diff --git a/arch/powerpc/sysdev/mpic_msgr.c
> b/arch/powerpc/sysdev/mpic_msgr.c new file mode 100644 index
> 0000000..352bfa6
> --- /dev/null
> +++ b/arch/powerpc/sysdev/mpic_msgr.c
> @@ -0,0 +1,279 @@
> +/*
> + * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
> + *
> + * Some ideas based on un-pushed work done by Vivek Mahajan, Jason Jin,
> +and
> + * Mingkai Hu from Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; version 2 of the
> + * License.
> + *
> + */
> +
> +#include <linux/list.h>
> +#include <linux/of_platform.h>
> +#include <linux/errno.h>
> +#include <asm/prom.h>
> +#include <asm/hw_irq.h>
> +#include <asm/ppc-pci.h>
> +#include <asm/mpic_msgr.h>
> +
> +#define MPIC_MSGR_REGISTERS_PER_BLOCK 4 #define MSGR_INUSE 0 #define
> +MSGR_FREE 1
> +
> +/* Internal structure used *only* for IO mapping register blocks. */
> +struct mpic_msgr_block {
> + struct msgr {
> + u32 msgr;
> + u8 res[12];
> + } msgrs[MPIC_MSGR_REGISTERS_PER_BLOCK];
> + u8 res0[192];
> + u32 mer;
> + u8 res1[12];
> + u32 msr;
> +};
> +
> +static struct mpic_msgr **mpic_msgrs =3D 0; static unsigned int
> +mpic_msgr_count =3D 0;
> +
> +struct mpic_msgr* mpic_msgr_get(unsigned int reg_num) {
> + struct mpic_msgr* msgr;
> +
> + if (reg_num >=3D mpic_msgr_count)
> + return ERR_PTR(-ENODEV);
> +
> + msgr =3D mpic_msgrs[reg_num];
> +
> + if (atomic_cmpxchg(&msgr->in_use, MSGR_FREE, MSGR_INUSE) =3D=3D
> MSGR_FREE)
> + return msgr;
> +
> + return ERR_PTR(-EBUSY);
> +}
> +EXPORT_SYMBOL(mpic_msgr_get);
> +
> +void mpic_msgr_put(struct mpic_msgr* msgr) {
> + atomic_set(&msgr->in_use, MSGR_FREE);
> +}
> +EXPORT_SYMBOL(mpic_msgr_put);
> +
> +void mpic_msgr_enable(struct mpic_msgr *msgr) {
> + out_be32(msgr->mer, in_be32(msgr->mer) | (1 << msgr->num)); }
> +EXPORT_SYMBOL(mpic_msgr_enable);
> +
> +void mpic_msgr_disable(struct mpic_msgr *msgr) {
> + out_be32(msgr->mer, in_be32(msgr->mer) & ~(1 << msgr->num)); }
> +EXPORT_SYMBOL(mpic_msgr_disable);
> +
> +void mpic_msgr_write(struct mpic_msgr *msgr, u32 message) {
> + out_be32(msgr->addr, message);
> +}
> +EXPORT_SYMBOL(mpic_msgr_write);
> +
> +u32 mpic_msgr_read(struct mpic_msgr *msgr) {
> + return in_be32(msgr->addr);
> +}
> +EXPORT_SYMBOL(mpic_msgr_read);
> +
> +void mpic_msgr_clear(struct mpic_msgr *msgr) {
> + (void) mpic_msgr_read(msgr);
> +}
> +EXPORT_SYMBOL(mpic_msgr_clear);
> +
> +void mpic_msgr_set_destination(struct mpic_msgr *msgr, u32 cpu_num) {
> + out_be32(msgr->addr, 1 << cpu_num);
> +}
> +EXPORT_SYMBOL(mpic_msgr_set_destination);
> +
> +int mpic_msgr_get_irq(struct mpic_msgr *msgr) {
> + return msgr->irq;
> +}
> +EXPORT_SYMBOL(mpic_msgr_get_irq);
> +
> +/* The following three functions are used to compute the order and
> +number of
> + * the message register blocks. They are clearly very inefficent.
> +However,
> + * they are called *only* a few times during device initialization.
> + */
> +static unsigned int mpic_msgr_number_of_blocks(void) {
> + unsigned int count;
> + struct device_node *aliases;
> +
> + count =3D 0;
> + aliases =3D of_find_node_by_name(NULL, "aliases");
> +
> + if (aliases) {
> + char buf[32];
> +
> + for (;;) {
> + snprintf(buf, sizeof(buf), "msgr-block%d", count);
> + if (!of_find_property(aliases, buf, NULL))
> + break;
> +
> + count +=3D 1;
> + }
> + }
> +
> + return count;
> +}
> +
> +static unsigned int mpic_msgr_number_of_registers(void)
> +{
> + return mpic_msgr_number_of_blocks() *
> MPIC_MSGR_REGISTERS_PER_BLOCK; }
> +
> +static int mpic_msgr_block_number(struct device_node *node) {
> + struct device_node *aliases;
> + unsigned int index, number_of_blocks;
> + char buf[64];
> +
> + number_of_blocks =3D mpic_msgr_number_of_blocks();
> + aliases =3D of_find_node_by_name(NULL, "aliases");
> + if (!aliases)
> + return -1;
> +
> + for (index =3D 0; index < number_of_blocks; ++index) {
> + struct property *prop;
> +
> + snprintf(buf, sizeof(buf), "msgr-block%d", index);
> + prop =3D of_find_property(aliases, buf, NULL);
> + if (node =3D=3D of_find_node_by_path(prop->value))
> + break;
> + }
> +
> + return index =3D=3D number_of_blocks ? -1 : index; }
> +
> +/* The probe function for a single message register block.
> + */
> +static __devinit int mpic_msgr_probe(struct platform_device *dev) {
> + struct mpic_msgr_block __iomem *msgr_block;
> + int block_number;
> + struct resource rsrc;
> + unsigned int i;
> + unsigned int irq_index;
> + struct device_node *np =3D dev->dev.of_node;
> + unsigned int receive_mask;
> + const unsigned int *prop;
> +
> + if (!np) {
> + dev_err(&dev->dev, "Device OF-Node is NULL");
> + return -EFAULT;
> + }
> +
> + /* Allocate the message register array upon the first device
> + * registered.
> + */
> + if (!mpic_msgrs) {
> + mpic_msgr_count =3D mpic_msgr_number_of_registers();
> + dev_info(&dev->dev, "Found %d message registers\n",
> mpic_msgr_count);
> +
> + mpic_msgrs =3D kzalloc(sizeof(struct mpic_msgr) *
> mpic_msgr_count,
> + GFP_KERNEL);
> + if (!mpic_msgrs) {
> + dev_err(&dev->dev, "No memory for message register
> blocks\n");
> + return -ENOMEM;
> + }
> + }
> + dev_info(&dev->dev, "Of-device full name %s\n", np->full_name);
> +
> + /* IO map the message register block. */
> + of_address_to_resource(np, 0, &rsrc);
> + msgr_block =3D ioremap(rsrc.start, rsrc.end - rsrc.start);
> + if (!msgr_block) {
> + dev_err(&dev->dev, "Failed to iomap MPIC message registers");
> + return -EFAULT;
> + }
> +
> + /* Ensure the block has a defined order. */
> + block_number =3D mpic_msgr_block_number(np);
> + if (block_number < 0) {
> + dev_err(&dev->dev, "Failed to find message register block
> alias\n");
> + return -ENODEV;
> + }
> + dev_info(&dev->dev, "Setting up message register block %d\n",
> +block_number);
> +
> + /* Grab the receive mask which specifies what registers can receive
> + * interrupts.
> + */
> + prop =3D of_get_property(np, "msg-receive-mask", NULL);
> + receive_mask =3D (prop) ? *prop : 0xF;
> +
> + /* Build up the appropriate message register data structures. */
> + for (i =3D 0, irq_index =3D 0; i < MPIC_MSGR_REGISTERS_PER_BLOCK; ++i)
> {
> + struct mpic_msgr *msgr;
> + unsigned int reg_number;
> +
> + msgr =3D kzalloc(sizeof(struct mpic_msgr), GFP_KERNEL);
> + if (!msgr) {
> + dev_err(&dev->dev, "No memory for message register\n");
> + return -ENOMEM;
> + }
> +
> + reg_number =3D block_number * MPIC_MSGR_REGISTERS_PER_BLOCK +
> i;
> + msgr->addr =3D &msgr_block->msgrs[i].msgr;
> + msgr->mer =3D &msgr_block->mer;
> + msgr->msr =3D &msgr_block->msr;
> + atomic_set(&msgr->in_use, MSGR_FREE);
> + msgr->num =3D reg_number;
> +
> + if (receive_mask & (1 << i)) {
> + struct resource irq;
> +
> + if (of_irq_to_resource(np, irq_index, &irq) =3D=3D NO_IRQ)
> {
> + dev_err(&dev->dev, "Missing interrupt
> specifier");
> + kfree(msgr);
> + return -EFAULT;
> + }
> + msgr->irq =3D irq.start;
> + irq_index +=3D 1;
> + } else {
> + msgr->irq =3D NO_IRQ;
> + }
> +
> + mpic_msgrs[reg_number] =3D msgr;
> + mpic_msgr_disable(msgr);
> + dev_info(&dev->dev, "Register %d initialized: irq %d\n",
> + msgr->num, msgr->irq);
> +
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id mpic_msgr_ids[] =3D {
> + {
> + .compatible =3D "fsl,mpic-v3.1-msgr",
> + .data =3D NULL,
> + },
> + {}
> +};
> +
> +static struct platform_driver mpic_msgr_driver =3D {
> + .driver =3D {
> + .name =3D "mpic-msgr",
> + .owner =3D THIS_MODULE,
> + .of_match_table =3D mpic_msgr_ids,
> + },
> + .probe =3D mpic_msgr_probe,
> +};
> +
> +static __init int mpic_msgr_init(void)
> +{
> + return platform_driver_register(&mpic_msgr_driver);
> +}
> +subsys_initcall(mpic_msgr_init);
> --
> 1.6.3.3
>=20
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox