[PATCH 2/2] powerpc: Save Come-From Address Register (CFAR) in exception frame
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 --- 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_ADDRESSLONG_ASM_CONST(0x0200) #define CPU_FTR_POPCNTB LONG_ASM_CONST(0x0400) #define CPU_FTR_POPCNTD LONG_ASM_CONST(0x0800) +#define CPU_FTR_CFAR LONG_ASM_CONST(0x1000) #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_CFAR80 /* * 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);\ mfcrr9 @@ -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 */ \ mflrr9; /* 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/
Read/write BCSR registers of PPC460EX
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 // to use module_init and module_exit
#include // macros for modules
#include
#include
#include
#include
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 = 0xC000;// IP base address
static unsigned long mem_size = 0x1; // 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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Read/write BCSR registers of PPC460EX
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 // to use module_init and module_exit
>#include // macros for modules
>#include
>#include
>#include
>#include
>
>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 = 0xC000;// IP base address
Is this the correct address for the BCSR? On the 460EX Canyonlands
board, the CPLD/BCSR is at 0xE100.
>static unsigned long mem_size = 0x1; // 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Read/write BCSR registers of PPC460EX
On Monday 02 May 2011 14:40:39 Josh Boyer wrote: > >static unsigned long mem_addr = 0xC000;// IP base address > > Is this the correct address for the BCSR? On the 460EX Canyonlands > board, the CPLD/BCSR is at 0xE100. To be precise: It's 0x4.e100. 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: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Read/write BCSR registers of PPC460EX
Dear Stefan, I have changed CPLD/BCSR address with 0x4E100. static unsigned long mem_addr = 0x4E100; 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 e8f2 <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 CR: 2428 XER: 2007 <4>TASK = de518000[956] 'insmod' THREAD: da282000 <6>GPR00: e4ff60d8 da283e90 de518000 0025 c01646c8 321d <6>GPR08: e8f2 321d 4000 4422 101c0dac 100ab618 10095434 <6>GPR16: 100f 100f bfee5eec 0002 bfee5ef0 101ebf80 bfd0c274 <6>GPR24: 10130a48 c035 c0326008 c0326014 e4ff 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 487d 813d6658 <4>2f89 419e004c 7c0004ac 8089 <0c04> 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 = 0xC000;// IP base address >> >> Is this the correct address for the BCSR? On the 460EX Canyonlands >> board, the CPLD/BCSR is at 0xE100. > > To be precise: It's 0x4.e100. 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: off...@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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Read/write BCSR registers of PPC460EX
Hi Efti, On Monday 02 May 2011 15:36:15 linuxppc-dev wrote: > Dear Stefan, > > I have changed CPLD/BCSR address with 0x4E100. > > static unsigned long mem_addr = 0x4E100; Thats a 64bit address, so you need this: static unsigned long long mem_addr = 0x4E100ULL; 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: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: add support for MPIC message register API
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[tip:irq/urgent] genirq: Fix typo CONFIG_GENIRC_IRQ_SHOW_LEVEL
Commit-ID: 94b2c363dcf732a4edab4ed66041cb36e7f28fbf
Gitweb: http://git.kernel.org/tip/94b2c363dcf732a4edab4ed66041cb36e7f28fbf
Author: Geert Uytterhoeven
AuthorDate: Sat, 30 Apr 2011 22:56:20 +0200
Committer: Thomas Gleixner
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
Cc: Linux/PPC Development
Link:
http://lkml.kernel.org/r/%3Calpine.DEB.2.00.1104302251370.19068%40ayla.of.borg%3E
Signed-off-by: Thomas Gleixner
---
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)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Login prompt on a video console instead of serial port?
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Login prompt on a video console instead of serial port?
McClintock Matthew-B29882 wrote: > Don't you have to spawn a terminal on the framebuffer for the login? I suppose, but I don't know how to do that. And although that would technically answer the question in the subject of this thread, I still would have *some* boot output on the serial port. It would be nice if I could get all of stdout on the video display, and all of stdin from the serial port. > Right now getty spawns the login on the serial port via /etc/inittab. > Something similiar is probably needed for the framebuffer. getty appears to work only with serial devices, since it insists on a baud rate as one of the parameters. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Login prompt on a video console instead of serial port?
On Mon, May 2, 2011 at 1:30 PM, Timur Tabi wrote: > 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". Look in /etc/inittab. That's usually where the login gettys are specified. g. > > -- > Timur Tabi > Linux kernel developer at Freescale > > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- 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: Login prompt on a video console instead of serial port?
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 wrote: > 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". ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 0/6] powerpc, 52xx: add charon board support
On Tue, Mar 22, 2011 at 09:27:26AM +0100, Heiko Schocher wrote: > cc: Wolfram Sang > cc: Grant Likely > cc: Benjamin Herrenschmidt > cc: linux-fb...@vger.kernel.org > cc: devicetree-disc...@ozlabs.org > cc: Ben Dooks > cc: Vincent Sanders > cc: Samuel Ortiz > cc: linux-ker...@vger.kernel.org > cc: Randy Dunlap > cc: Wolfgang Denk > cc: Paul Mundt > > changes since v5: > - repost complete patchseries, as Paul Mundt suggested > - rebased against current head > - add Acked-by from Samuel Ortiz (MFD parts) > http://www.spinics.net/lists/linux-fbdev/msg02550.html > http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg11798.html > > and Benjamin Herrenschmidt (DTS parts) > http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088279.html > - removed patch > "powerpc, mpc5200: update mpc5200_defconfig to fit for charon board." > therefore added > "powerpc, tqm5200: update tqm5200_defconfig to fit for charon board." Refresh my memory, why was the mpc5200_defconfig updated dropped? g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 2/6] video, sm501: add I/O functions for use on powerpc
On Tue, Mar 22, 2011 at 09:27:28AM +0100, Heiko Schocher wrote:
> - add read/write functions for using this driver
> also on powerpc plattforms
>
> Signed-off-by: Heiko Schocher
> Acked-by: Samuel Ortiz
Merged, thanks.
g.
> cc: Wolfram Sang
> cc: Grant Likely
> cc: Benjamin Herrenschmidt
> cc: linux-fb...@vger.kernel.org
> cc: devicetree-disc...@ozlabs.org
> cc: Ben Dooks
> cc: Vincent Sanders
> cc: Samuel Ortiz
> cc: linux-ker...@vger.kernel.org
> cc: Randy Dunlap
> cc: Wolfgang Denk
> cc: Paul Mundt
> ---
> - changes since v1:
> add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from
> Paul Mundt.
> - changes since v2:
> add comments from Randy Dunlap:
> - move parameter documentation to Documentation/fb/sm501.txt
> - changes since v3:
> - rebased against v2.6.38-rc2
> - split in 3 patches
> - of support patch
> - i/o routine patch
> - use ioread/write32{be} accessors instead of
> __do_readl/__do_writel{_be}
> - edid support patch
> - changes for v6:
> - repost complete patchserie
> - rebased against current head
>
> drivers/mfd/sm501.c | 125 +-
> drivers/video/sm501fb.c | 172 --
> include/linux/sm501.h |8 ++
> 3 files changed, 161 insertions(+), 144 deletions(-)
>
> diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
> index 5de3a76..558d5f3 100644
> --- a/drivers/mfd/sm501.c
> +++ b/drivers/mfd/sm501.c
> @@ -133,10 +133,10 @@ static unsigned long decode_div(unsigned long pll2,
> unsigned long val,
>
> static void sm501_dump_clk(struct sm501_devdata *sm)
> {
> - unsigned long misct = readl(sm->regs + SM501_MISC_TIMING);
> - unsigned long pm0 = readl(sm->regs + SM501_POWER_MODE_0_CLOCK);
> - unsigned long pm1 = readl(sm->regs + SM501_POWER_MODE_1_CLOCK);
> - unsigned long pmc = readl(sm->regs + SM501_POWER_MODE_CONTROL);
> + unsigned long misct = smc501_readl(sm->regs + SM501_MISC_TIMING);
> + unsigned long pm0 = smc501_readl(sm->regs + SM501_POWER_MODE_0_CLOCK);
> + unsigned long pm1 = smc501_readl(sm->regs + SM501_POWER_MODE_1_CLOCK);
> + unsigned long pmc = smc501_readl(sm->regs + SM501_POWER_MODE_CONTROL);
> unsigned long sdclk0, sdclk1;
> unsigned long pll2 = 0;
>
> @@ -193,29 +193,29 @@ static void sm501_dump_regs(struct sm501_devdata *sm)
> void __iomem *regs = sm->regs;
>
> dev_info(sm->dev, "System Control %08x\n",
> - readl(regs + SM501_SYSTEM_CONTROL));
> + smc501_readl(regs + SM501_SYSTEM_CONTROL));
> dev_info(sm->dev, "Misc Control %08x\n",
> - readl(regs + SM501_MISC_CONTROL));
> + smc501_readl(regs + SM501_MISC_CONTROL));
> dev_info(sm->dev, "GPIO Control Low %08x\n",
> - readl(regs + SM501_GPIO31_0_CONTROL));
> + smc501_readl(regs + SM501_GPIO31_0_CONTROL));
> dev_info(sm->dev, "GPIO Control Hi %08x\n",
> - readl(regs + SM501_GPIO63_32_CONTROL));
> + smc501_readl(regs + SM501_GPIO63_32_CONTROL));
> dev_info(sm->dev, "DRAM Control %08x\n",
> - readl(regs + SM501_DRAM_CONTROL));
> + smc501_readl(regs + SM501_DRAM_CONTROL));
> dev_info(sm->dev, "Arbitration Ctrl %08x\n",
> - readl(regs + SM501_ARBTRTN_CONTROL));
> + smc501_readl(regs + SM501_ARBTRTN_CONTROL));
> dev_info(sm->dev, "Misc Timing %08x\n",
> - readl(regs + SM501_MISC_TIMING));
> + smc501_readl(regs + SM501_MISC_TIMING));
> }
>
> static void sm501_dump_gate(struct sm501_devdata *sm)
> {
> dev_info(sm->dev, "CurrentGate %08x\n",
> - readl(sm->regs + SM501_CURRENT_GATE));
> + smc501_readl(sm->regs + SM501_CURRENT_GATE));
> dev_info(sm->dev, "CurrentClock %08x\n",
> - readl(sm->regs + SM501_CURRENT_CLOCK));
> + smc501_readl(sm->regs + SM501_CURRENT_CLOCK));
> dev_info(sm->dev, "PowerModeControl %08x\n",
> - readl(sm->regs + SM501_POWER_MODE_CONTROL));
> + smc501_readl(sm->regs + SM501_POWER_MODE_CONTROL));
> }
>
> #else
> @@ -231,7 +231,7 @@ static inline void sm501_dump_clk(struct sm501_devdata
> *sm) { }
>
> static void sm501_sync_regs(struct sm501_devdata *sm)
> {
> - readl(sm->regs);
> + smc501_readl(sm->regs);
> }
>
> static inline void sm501_mdelay(struct sm501_devdata *sm, unsigned int delay)
> @@ -261,11 +261,11 @@ int sm501_misc_control(struct device *dev,
>
> spin_lock_irqsave(&sm->reg_lock, save);
>
> - misc = readl(sm->regs + SM501_MISC_CONTROL);
> + misc = smc501_readl(sm->regs + SM501_MISC_CONTROL);
> to = (misc & ~clear) | set;
>
> if (to != misc) {
> -
Re: [PATCH v6 3/6] video, sm501: add edid and commandline support
On Tue, Mar 22, 2011 at 09:27:29AM +0100, Heiko Schocher wrote:
> - add commandline options:
> sm501fb.mode:
> Specify resolution as "x[-][@]"
> sm501fb.bpp:
> Specify bit-per-pixel if not specified mode
>
> - Add support for encoding display mode information
> in the device tree using verbatim EDID block.
>
> If the "edid" entry in the "smi,sm501" node is present,
> the driver will build mode database using EDID data
> and allow setting the display modes from this database.
>
> Signed-off-by: Heiko Schocher
Merged, thanks.
g.
> cc: Wolfram Sang
> cc: Grant Likely
> cc: Benjamin Herrenschmidt
> cc: linux-fb...@vger.kernel.org
> cc: devicetree-disc...@ozlabs.org
> cc: Ben Dooks
> cc: Vincent Sanders
> cc: Samuel Ortiz
> cc: linux-ker...@vger.kernel.org
> cc: Randy Dunlap
> cc: Wolfgang Denk
> cc: Paul Mundt
> ---
> - changes since v1:
> add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from
> Paul Mundt.
> - changes since v2:
> add comments from Randy Dunlap:
> - move parameter documentation to Documentation/fb/sm501.txt
> - changes since v3:
> - rebased against v2.6.38-rc2
> - split in 3 patches
> - of support patch
> - i/o routine patch
> - edid support patch
> - changes since v4:
> - add "info->pdata = &sm501fb_def_pdata;" in sm501fb_probe()
> as Paul Mundt suggested (and I wrongly deleted)
> - move kfree(info->edid_data); to patch 3/4
> as edid_data is only allocated in the CONFIG_OF case
> - changes for v6:
> - repost complete patchserie
> - rebased against current head
>
> Documentation/fb/sm501.txt | 10 +++
> drivers/video/sm501fb.c| 65 ---
> 2 files changed, 70 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/fb/sm501.txt
>
> diff --git a/Documentation/fb/sm501.txt b/Documentation/fb/sm501.txt
> new file mode 100644
> index 000..8d17aeb
> --- /dev/null
> +++ b/Documentation/fb/sm501.txt
> @@ -0,0 +1,10 @@
> +Configuration:
> +
> +You can pass the following kernel command line options to sm501
> videoframebuffer:
> +
> + sm501fb.bpp=SM501 Display driver:
> + Specifiy bits-per-pixel if not specified by 'mode'
> +
> + sm501fb.mode= SM501 Display driver:
> + Specify resolution as
> + "x[-][@]"
> diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
> index 5df406c..f31252c 100644
> --- a/drivers/video/sm501fb.c
> +++ b/drivers/video/sm501fb.c
> @@ -41,6 +41,26 @@
> #include
> #include
>
> +#include "edid.h"
> +
> +static char *fb_mode = "640x480-16@60";
> +static unsigned long default_bpp = 16;
> +
> +static struct fb_videomode __devinitdata sm501_default_mode = {
> + .refresh= 60,
> + .xres = 640,
> + .yres = 480,
> + .pixclock = 20833,
> + .left_margin= 142,
> + .right_margin = 13,
> + .upper_margin = 21,
> + .lower_margin = 1,
> + .hsync_len = 69,
> + .vsync_len = 3,
> + .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
> + .vmode = FB_VMODE_NONINTERLACED
> +};
> +
> #define NR_PALETTE 256
>
> enum sm501_controller {
> @@ -77,6 +97,7 @@ struct sm501fb_info {
> void __iomem*regs2d;/* 2d remapped registers */
> void __iomem*fbmem; /* remapped framebuffer */
> size_t fbmem_len; /* length of remapped region */
> + u8 *edid_data;
> };
>
> /* per-framebuffer private data */
> @@ -1725,9 +1746,16 @@ static int sm501fb_init_fb(struct fb_info *fb,
> fb->var.vmode = FB_VMODE_NONINTERLACED;
> fb->var.bits_per_pixel = 16;
>
> + if (info->edid_data) {
> + /* Now build modedb from EDID */
> + fb_edid_to_monspecs(info->edid_data, &fb->monspecs);
> + fb_videomode_to_modelist(fb->monspecs.modedb,
> + fb->monspecs.modedb_len,
> + &fb->modelist);
> + }
> +
> if (enable && (pd->flags & SM501FB_FLAG_USE_INIT_MODE) && 0) {
> /* TODO read the mode from the current display */
> -
> } else {
> if (pd->def_mode) {
> dev_info(info->dev, "using supplied mode\n");
> @@ -1737,12 +1765,34 @@ static int sm501fb_init_fb(struct fb_info *fb,
> fb->var.xres_virtual = fb->var.xres;
> fb->var.yres_virtual = fb->var.yres;
> } else {
> - ret = fb_find_mode(&fb->var, fb,
> + if (info->edid_data)
> + ret = fb_find_mode(&fb->var, fb, fb_mode,
> + fb->monspecs.modedb,
> + fb->monspecs.modedb_len,
> + &
Re: [PATCH v6 4/6] video, sm501: add OF binding to support SM501
On Tue, Mar 22, 2011 at 09:27:30AM +0100, Heiko Schocher wrote:
> - add binding to OF, compatible name "smi,sm501"
>
> Signed-off-by: Heiko Schocher
> Acked-by: Samuel Ortiz
Merged, thanks.
g.
> cc: Wolfram Sang
> cc: Grant Likely
> cc: Benjamin Herrenschmidt
> cc: linux-fb...@vger.kernel.org
> cc: devicetree-disc...@ozlabs.org
> cc: Ben Dooks
> cc: Vincent Sanders
> cc: Samuel Ortiz
> cc: linux-ker...@vger.kernel.org
> cc: Randy Dunlap
> cc: Wolfgang Denk
> cc: Paul Mundt
> ---
> - changes since v1:
> add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from
> Paul Mundt.
> - changes since v2:
> add comments from Randy Dunlap:
> - move parameter documentation to Documentation/fb/sm501.txt
> - changes since v3:
> - rebased against v2.6.38-rc2
> - split in 3 patches
> - of support patch
> - get rid of "#if defined(CONFIG_PPC_MPC52xx)" usage
> hide this in DTS, as Paul suggested.
> - i/o routine patch
> - edid support patch
> - changes since v4
> replace remaining CONFIG_PPC_MPC52xx with CONFIG_OF, as
> it is no longer MPC52xx only.
> - changes since v5
> free edid_data after its usage, as it is no longer needed,
> suggested from Paul Mundt. Also fall back to default if
> kmemdup(edid_data) fails.
> - changes for v6:
> - repost complete patchserie
> - rebased against current head
>
> Documentation/powerpc/dts-bindings/sm501.txt | 34 +
> drivers/mfd/sm501.c |8 +-
> drivers/video/sm501fb.c | 35
> +-
> 3 files changed, 75 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>
> diff --git a/Documentation/powerpc/dts-bindings/sm501.txt
> b/Documentation/powerpc/dts-bindings/sm501.txt
> new file mode 100644
> index 000..7d319fb
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/sm501.txt
> @@ -0,0 +1,34 @@
> +* SM SM501
> +
> +The SM SM501 is a LCD controller, with proper hardware, it can also
> +drive DVI monitors.
> +
> +Required properties:
> +- compatible : should be "smi,sm501".
> +- reg : contain two entries:
> +- First entry: System Configuration register
> +- Second entry: IO space (Display Controller register)
> +- interrupts : SMI interrupt to the cpu should be described here.
> +- interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
> +
> +Optional properties:
> +- mode : select a video mode:
> +x[-][@]
> +- edid : verbatim EDID data block describing attached display.
> + Data from the detailed timing descriptor will be used to
> + program the display controller.
> +- little-endian: availiable on big endian systems, to
> + set different foreign endian.
> +- big-endian: availiable on little endian systems, to
> + set different foreign endian.
> +
> +Example for MPC5200:
> + display@1,0 {
> + compatible = "smi,sm501";
> + reg = <1 0x 0x0080
> +1 0x03e0 0x0020>;
> + interrupts = <1 1 3>;
> + mode = "640x480-32@60";
> + edid = [edid-data];
> + };
> diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
> index 558d5f3..574f696 100644
> --- a/drivers/mfd/sm501.c
> +++ b/drivers/mfd/sm501.c
> @@ -1377,7 +1377,7 @@ static int __devinit sm501_init_dev(struct
> sm501_devdata *sm)
> sm501_register_gpio(sm);
> }
>
> - if (pdata->gpio_i2c != NULL && pdata->gpio_i2c_nr > 0) {
> + if (pdata && pdata->gpio_i2c != NULL && pdata->gpio_i2c_nr > 0) {
> if (!sm501_gpio_isregistered(sm))
> dev_err(sm->dev, "no gpio available for i2c gpio.\n");
> else
> @@ -1735,10 +1735,16 @@ static struct pci_driver sm501_pci_driver = {
>
> MODULE_ALIAS("platform:sm501");
>
> +static struct of_device_id __devinitdata of_sm501_match_tbl[] = {
> + { .compatible = "smi,sm501", },
> + { /* end */ }
> +};
> +
> static struct platform_driver sm501_plat_driver = {
> .driver = {
> .name = "sm501",
> .owner = THIS_MODULE,
> + .of_match_table = of_sm501_match_tbl,
> },
> .probe = sm501_plat_probe,
> .remove = sm501_plat_remove,
> diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
> index f31252c..f275385 100644
> --- a/drivers/video/sm501fb.c
> +++ b/drivers/video/sm501fb.c
> @@ -1729,6 +1729,15 @@ static int sm501fb_init_fb(struct fb_info *fb,
> FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT |
> FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN;
>
> +#if defined(CONFIG_OF)
> +#ifdef __BIG_ENDIAN
> + if (of_get_property(info->dev->parent->of_node, "little-endian", NULL))
> + fb->flags |= FBINFO_FOREIGN_ENDIAN;
> +#else
> + if (of_get_property(info->dev->parent->of_node, "big-endi
Re: [PATCH v6 6/6] powerpc, tqm5200: update tqm5200_defconfig to fit for charon board.
On Tue, Mar 22, 2011 at 10:10:27AM +0100, Wolfram Sang wrote: > > As this board is tqm5200 based, added necessary changes > > to the tqm5200_defconfig. In previous patchserie I added > > the changes to mpc5200_defconfig, as Wolfram Sang mentioned, > > but as tqm5200_defconfig is in mainline, and the board is > > tqm5200 based, I think, thats the appropriate place, as > > I'd think the perfect solution would have been to merge the > tqm-defconfig into the mpc5200-defconfig entirely and get rid of it. > That being said, I don't think this issue is big enough to block this > series, so fine enough with me. Merged, thanks. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 3/6] video, sm501: add edid and commandline support
On Mon, May 2, 2011 at 4:27 PM, Grant Likely wrote:
> On Tue, Mar 22, 2011 at 09:27:29AM +0100, Heiko Schocher wrote:
>> - add commandline options:
>> sm501fb.mode:
>> Specify resolution as "x[-][@]"
>> sm501fb.bpp:
>> Specify bit-per-pixel if not specified mode
>>
>> - Add support for encoding display mode information
>> in the device tree using verbatim EDID block.
>>
>> If the "edid" entry in the "smi,sm501" node is present,
>> the driver will build mode database using EDID data
>> and allow setting the display modes from this database.
>>
>> Signed-off-by: Heiko Schocher
>
> Merged, thanks.
This patch causes the following build warning:
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x1d5572): Section mismatch in reference from
the function sm501fb_init_fb() to the variable
.devinit.data:sm501_default_mode
The function sm501fb_init_fb() references
the variable __devinitdata sm501_default_mode.
This is often because sm501fb_init_fb lacks a __devinitdata
annotation or the annotation of sm501_default_mode is wrong.
WARNING: vmlinux.o(.text+0x1d557a): Section mismatch in reference from
the function sm501fb_init_fb() to the variable
.devinit.data:sm501_default_mode
The function sm501fb_init_fb() references
the variable __devinitdata sm501_default_mode.
This is often because sm501fb_init_fb lacks a __devinitdata
annotation or the annotation of sm501_default_mode is wrong.
I've dropped the __devinitdata declaration in what I committed; can
you investigate and post a fixup patch?
>
> g.
>
>> cc: Wolfram Sang
>> cc: Grant Likely
>> cc: Benjamin Herrenschmidt
>> cc: linux-fb...@vger.kernel.org
>> cc: devicetree-disc...@ozlabs.org
>> cc: Ben Dooks
>> cc: Vincent Sanders
>> cc: Samuel Ortiz
>> cc: linux-ker...@vger.kernel.org
>> cc: Randy Dunlap
>> cc: Wolfgang Denk
>> cc: Paul Mundt
>> ---
>> - changes since v1:
>> add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from
>> Paul Mundt.
>> - changes since v2:
>> add comments from Randy Dunlap:
>> - move parameter documentation to Documentation/fb/sm501.txt
>> - changes since v3:
>> - rebased against v2.6.38-rc2
>> - split in 3 patches
>> - of support patch
>> - i/o routine patch
>> - edid support patch
>> - changes since v4:
>> - add "info->pdata = &sm501fb_def_pdata;" in sm501fb_probe()
>> as Paul Mundt suggested (and I wrongly deleted)
>> - move kfree(info->edid_data); to patch 3/4
>> as edid_data is only allocated in the CONFIG_OF case
>> - changes for v6:
>> - repost complete patchserie
>> - rebased against current head
>>
>> Documentation/fb/sm501.txt | 10 +++
>> drivers/video/sm501fb.c | 65
>> ---
>> 2 files changed, 70 insertions(+), 5 deletions(-)
>> create mode 100644 Documentation/fb/sm501.txt
>>
>> diff --git a/Documentation/fb/sm501.txt b/Documentation/fb/sm501.txt
>> new file mode 100644
>> index 000..8d17aeb
>> --- /dev/null
>> +++ b/Documentation/fb/sm501.txt
>> @@ -0,0 +1,10 @@
>> +Configuration:
>> +
>> +You can pass the following kernel command line options to sm501
>> videoframebuffer:
>> +
>> + sm501fb.bpp= SM501 Display driver:
>> + Specifiy bits-per-pixel if not specified by 'mode'
>> +
>> + sm501fb.mode= SM501 Display driver:
>> + Specify resolution as
>> + "x[-][@]"
>> diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
>> index 5df406c..f31252c 100644
>> --- a/drivers/video/sm501fb.c
>> +++ b/drivers/video/sm501fb.c
>> @@ -41,6 +41,26 @@
>> #include
>> #include
>>
>> +#include "edid.h"
>> +
>> +static char *fb_mode = "640x480-16@60";
>> +static unsigned long default_bpp = 16;
>> +
>> +static struct fb_videomode __devinitdata sm501_default_mode = {
>> + .refresh = 60,
>> + .xres = 640,
>> + .yres = 480,
>> + .pixclock = 20833,
>> + .left_margin = 142,
>> + .right_margin = 13,
>> + .upper_margin = 21,
>> + .lower_margin = 1,
>> + .hsync_len = 69,
>> + .vsync_len = 3,
>> + .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
>> + .vmode = FB_VMODE_NONINTERLACED
>> +};
>> +
>> #define NR_PALETTE 256
>>
>> enum sm501_controller {
>> @@ -77,6 +97,7 @@ struct sm501fb_info {
>> void __iomem *regs2d; /* 2d remapped registers */
>> void __iomem *fbmem; /* remapped framebuffer */
>> size_t fbmem_len; /* length of remapped region */
>> + u8 *edid_data;
>> };
>>
>> /* per-framebuffer private data */
>> @@ -1725,9 +1746,16 @@ static int sm501fb_init_fb(struct fb_info *fb,
>> fb->var.vmode = FB_VMODE_NONINTERLACED;
>> fb->var.bits_per_pixel = 16;
>>
>> + if (info->edid_data) {
>> + /* Now build modedb from EDID */
>> + fb_edid_to_monspecs(info->edid_d
Re: [PATCH 1/4] crypto: caam - handle interrupt lines shared across rings
On Fri, 15 Apr 2011 17:50:49 +0800 Herbert Xu wrote: > On Mon, Apr 11, 2011 at 07:15:16PM -0500, Kim Phillips wrote: > > - add IRQF_SHARED to request_irq flags to support parts such as > > the p1023 that has one IRQ line per couple of rings. > > > > - resetting a job ring triggers an interrupt, so move request_irq > > prior to jr_reset to avoid 'got IRQ but nobody cared' messages. > > > > - disable IRQs in h/w to avoid contention between reset and > > interrupt status > > > > - delete invalid comment - if there were incomplete jobs, > > module would be in use, preventing an unload. > > > > Signed-off-by: Kim Phillips > > --- > > this, and the remaining patches in this series, tested on p1023, p3041, > > p4080, and 32- and 64-bit p5020. > > All four patches applied. Thanks Kim! I don't see them in cryptodev-2.6 - did you forget to push them? Thanks, Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] crypto: caam - handle interrupt lines shared across rings
On Mon, May 02, 2011 at 06:27:27PM -0500, Kim Phillips wrote: > > I don't see them in cryptodev-2.6 - did you forget to push them? Indeed, they were stuck on my other machine. They should be on master now and should show up on the public mirror soon. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/6] General device tree irq domain infrastructure
On Thu, 2011-04-28 at 14:01 -0600, Grant Likely wrote:
> A lot of this series ends up being fixups to powerpc code; but the 4th
> patch is of importance to every architecture using CONFIG_OF (except
> SPARC, which has its own solution).
>
> This series (finally!) factors out device tree irq domain decoding
> from arch/powerpc and makes it generic for all architectures. The
> infrastructure is quite simple. Any interrupt controller can embed
> the of_irq_domain structure and register it with the core code. After
> that, device nodes referencing interrupts on that device tree node
> will trigger a call to the domain's map function.
This leads to an immediate reaction from me : why "of_irq_domain" ?
The concept of interrupt domains is completely orthogonal to "OF" and
whether you use the device-tree or not.
Having a remapping mechanism allowing to deal with multiple interrupt
domains without playing stupid numbering tricks is generally useful for
architectures, regardless of their adoption of the device-tree.
The irq domain has one and -only one- op that is related to OF which
allows to map a device node to a domain, but that's 'optional' and only
use if you use the OF resolving process. The whole mechanism can be (and
is under some circumstances on ppc) without a device-tree relationship.
We instanciate IRQs within domains manually in some cases, either
because we lack proper DT informations or bcs the IRQs come from the
firmware or as "created" out of the blue (device-tree). A domain pointer
(or NULL for the default domain) is all is needed.
Thus I object to tying this infrastructure generically to "OF" even if
it's just a mater of naming of the domain structure and location of the
code in the kernel tree.
It should basically all go into kernel/irq/domains.c or something like
that.
Cheers,
Ben.
> PowerPC and x86 have been converted to use of_irq_domain. MIPS and
> Microblaze have it enabled, but nothing actually registers domains
> yet, so a workaround is in place to preserve the current behaviour
> until it is fixed.
>
> 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
>
> It needs testing. I've booted it on a powerpc board here without any
> apparent regressions, but that isn't a very big sample. I've also
> build tested on everything I think is affected.
>
> I'd also like to get it into linux-next. Ben, if things checkout okay
> over the next few days, would you be okay with me adding it to
> linux-next, say around Wednesday next week? As for merging, I think
> this should probably go via your powerpc tree since the that's where
> the bulk of the changes are, but I'm open to other suggestions).
>
> Patches 5 & 6 are follow-on cleanup work to powerpc, but patch 6 is
> RFC only since there is a locking problem that I haven't fixed yet.
>
> Cheers,
> g.
>
> ---
>
> Grant Likely (6):
> powerpc: stop exporting irq_map
> powerpc: make irq_{alloc,free}_virt private and remove count argument
> powerpc: Make struct irq_host semi-private by moving into irqhost.h
> dt: generalize of_irq_parse_and_map()
> powerpc: move irq_alloc_descs_at() call into irq_alloc_virt()
> powerpc: use irq_alloc_desc() to manage irq allocations
>
>
> arch/microblaze/kernel/irq.c |7 -
> arch/microblaze/kernel/setup.c |2
> arch/mips/kernel/prom.c | 14 -
> arch/powerpc/include/asm/irq.h | 88 +--
> arch/powerpc/include/asm/irqhost.h | 27 ++
> arch/powerpc/kernel/irq.c| 260
> --
> arch/powerpc/platforms/512x/mpc5121_ads_cpld.c |5
> arch/powerpc/platforms/52xx/media5200.c |5
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c|1
> arch/powerpc/platforms/52xx/mpc52xx_pic.c| 80 +--
> arch/powerpc/platforms/82xx/pq2ads-pci-pic.c |5
> arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 26 +-
> arch/powerpc/platforms/86xx/gef_pic.c| 10 -
> arch/powerpc/platforms/8xx/m8xx_setup.c |2
> arch/powerpc/platforms/cell/axon_msi.c | 15 +
> arch/powerpc/platforms/cell/spider-pic.c | 19 +-
> arch/powerpc/platforms/embedded6xx/flipper-pic.c |9 -
> arch/powerpc/platforms/embedded6xx/hlwd-pic.c|9 -
> arch/powerpc/platforms/embedded6xx/wii.c |6 -
> arch/powerpc/platforms/iseries/irq.c | 10 -
> arch/powerpc/platforms/powermac/pic.c| 12 +
> arch/powerpc/platforms/pseries/ras.c |4
> arch/powerpc/platforms/pseries/xics.c| 14 +
> arch/powerpc/sysdev/cpm1.c |8 -
> arch/powerpc/sysdev/cpm2_pic.c | 10 -
> arch/powerpc/s
Re: [PATCH 1/6] powerpc: stop exporting irq_map
On Thu, 2011-04-28 at 14:01 -0600, Grant Likely wrote: > First step in eliminating irq_map[] table entirely > > Signed-off-by: Grant Likely > --- > Ack in principle, needs scrutiny and testing of course :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/6] powerpc: make irq_{alloc, free}_virt private and remove count argument
On Thu, 2011-04-28 at 14:01 -0600, Grant Likely wrote:
> irq_alloc_virt() and irq_free_virt() aren't called anywhere but from
> arch/powerpc/kernel/irq.c, and they are only ever called with count=1.
> This patch removes the prototypes from the header file, removes the
> count arguments, and cuts out the dead code.
>
> Also removes obsolete references to irq_early_init()
Nack.
The count was intended to be able to allocate blocks of interrupts. This
was not used so far because we didn't support MSI blocks (for non-X
MSIs) but that is coming, and unfortunately, the API that was designed
for that is crap and requires contiguous IRQ numbers on the linux side
as well as on the device side (well device side is a HW requirement but
we could have been smarter on the Linux side).
So the ability to allocate blocks will be needed. In fact it's not clear
yet whether we'll also need them to be naturally aligned powers of two
or not at this stage. It depends how the bloody API is going to be used
by drivers.
Cheers,
Ben.
> Signed-off-by: Grant Likely
> ---
> arch/microblaze/kernel/setup.c |2 -
> arch/powerpc/include/asm/irq.h | 32
> arch/powerpc/kernel/irq.c | 82
>
> 3 files changed, 40 insertions(+), 76 deletions(-)
>
> diff --git a/arch/microblaze/kernel/setup.c b/arch/microblaze/kernel/setup.c
> index 8e2c09b..19d3ab7 100644
> --- a/arch/microblaze/kernel/setup.c
> +++ b/arch/microblaze/kernel/setup.c
> @@ -51,8 +51,6 @@ void __init setup_arch(char **cmdline_p)
>
> unflatten_device_tree();
>
> - /* NOTE I think that this function is not necessary to call */
> - /* irq_early_init(); */
> setup_cpuinfo();
>
> microblaze_cache_init();
> diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
> index e1983d5..4d2cc6f 100644
> --- a/arch/powerpc/include/asm/irq.h
> +++ b/arch/powerpc/include/asm/irq.h
> @@ -264,38 +264,6 @@ extern unsigned int irq_linear_revmap(struct irq_host
> *host,
> irq_hw_number_t hwirq);
>
>
> -
> -/**
> - * irq_alloc_virt - Allocate virtual irq numbers
> - * @host: host owning these new virtual irqs
> - * @count: number of consecutive numbers to allocate
> - * @hint: pass a hint number, the allocator will try to use a 1:1 mapping
> - *
> - * This is a low level function that is used internally by
> irq_create_mapping()
> - * and that can be used by some irq controllers implementations for things
> - * like allocating ranges of numbers for MSIs. The revmaps are left
> untouched.
> - */
> -extern unsigned int irq_alloc_virt(struct irq_host *host,
> -unsigned int count,
> -unsigned int hint);
> -
> -/**
> - * irq_free_virt - Free virtual irq numbers
> - * @virq: virtual irq number of the first interrupt to free
> - * @count: number of interrupts to free
> - *
> - * This function is the opposite of irq_alloc_virt. It will not clear reverse
> - * maps, this should be done previously by unmap'ing the interrupt. In fact,
> - * all interrupts covered by the range being freed should have been unmapped
> - * prior to calling this.
> - */
> -extern void irq_free_virt(unsigned int virq, unsigned int count);
> -
> -/**
> - * irq_early_init - Init irq remapping subsystem
> - */
> -extern void irq_early_init(void);
> -
> static __inline__ int irq_canonicalize(int irq)
> {
> return irq;
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 422672b..5ccf38f 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -647,6 +647,9 @@ void irq_set_virq_count(unsigned int count)
> irq_virq_count = count;
> }
>
> +static unsigned int irq_alloc_virt(struct irq_host *host, unsigned int hint);
> +static void irq_free_virt(unsigned int virq);
> +
> static int irq_setup_virq(struct irq_host *host, unsigned int virq,
> irq_hw_number_t hwirq)
> {
> @@ -675,7 +678,7 @@ static int irq_setup_virq(struct irq_host *host, unsigned
> int virq,
> errdesc:
> irq_free_descs(virq, 1);
> error:
> - irq_free_virt(virq, 1);
> + irq_free_virt(virq);
> return -1;
> }
>
> @@ -689,7 +692,7 @@ unsigned int irq_create_direct_mapping(struct irq_host
> *host)
> BUG_ON(host == NULL);
> WARN_ON(host->revmap_type != IRQ_HOST_MAP_NOMAP);
>
> - virq = irq_alloc_virt(host, 1, 0);
> + virq = irq_alloc_virt(host, 0);
> if (virq == NO_IRQ) {
> pr_debug("irq: create_direct virq allocation failed\n");
> return NO_IRQ;
> @@ -742,7 +745,7 @@ unsigned int irq_create_mapping(struct irq_host *host,
> } else {
> /* Allocate a virtual interrupt number */
> hint = hwirq % irq_virq_count;
> - virq = irq_alloc_virt(host, 1, hint);
> + virq = irq_alloc_virt(host, hint);
> if (virq ==
Re: [PATCH 4/6] dt: generalize irq_of_create_mapping()
On Thu, 2011-04-28 at 14:02 -0600, Grant Likely wrote:
> This patch creates a common implementation of irq_of_create_mapping()
> and factors out the interrupt domain translation code from powerpc to
> make it available for all architectures.
I think you are going the wrong way around.
First thing first, is to make the irq domain / mapping API generic
without the OF bits.
IE. move the IRQ domain generically, get rid of irq_map by putting the
domain ptr & hw numbers in the irq desc/data etc...
Then you can move over the OF specific bits which are optional and
orthogonal to a large extent.
Cheers,
Ben.
> It creates a new structure, struct of_irq_domain, which can be
> embedded into the private data structure of an interrupt controller.
> Any interrupt controller can call of_irq_domain_add() to register a
> structure with a .map() hook that can translate irq specifiers from
> the device tree into linux irq numbers.
>
> The patch also modifies the powerpc irq_host to embed the
> of_irq_domain structure and use the new common infrastructure for
> registering domains. This separates the reverse mapping and irq
> allocation infrastructure of irq_host from the domain registration
> infrastructure. I elected to split the functionality this way for
> several reasons. First, with the major irq cleanup done by Thomas
> Gleixner, dynamic allocation of irqs can be handled gracefully with
> irq_alloc_desc*() and interrupt controllers may not need or want an
> irq_host layer to manage it for them. For example, the new
> irq_chip_generic() already has a method for mapping between hwirq and
> Linux irq.
>
> Second, the irq_host code currently has a lot of complexity to handle
> all the different reverse mapping types from a single structure. The
> radix mapping in particular has a lot of support code, but only one
> user. I didn't want to bring that complexity into the common code
> as-is. Instead, I'd prefer to create a separate encapsulating
> structure for each revmap, and each type would have a separate .map
> hook.
>
> For now, the mapping code remains powerpc-specific and further
> generalization will happen in subsequent patches.
>
> Signed-off-by: Grant Likely
> ---
> arch/microblaze/kernel/irq.c |7 --
> arch/mips/kernel/prom.c | 14
> arch/powerpc/include/asm/irq.h | 21 +++--
> arch/powerpc/include/asm/irqhost.h |4 -
> arch/powerpc/kernel/irq.c| 99 ++---
> arch/powerpc/platforms/cell/axon_msi.c | 12 ++-
> arch/powerpc/platforms/cell/spider-pic.c |8 +-
> arch/powerpc/sysdev/fsl_msi.c|2 -
> arch/powerpc/sysdev/i8259.c |2 -
> arch/powerpc/sysdev/ipic.c |2 -
> arch/powerpc/sysdev/mpic.c |4 +
> arch/powerpc/sysdev/mpic_msi.c |2 -
> arch/powerpc/sysdev/mpic_pasemi_msi.c|4 +
> arch/powerpc/sysdev/qe_lib/qe_ic.c |2 -
> arch/x86/include/asm/irq_controller.h| 12 ---
> arch/x86/include/asm/prom.h |1
> arch/x86/kernel/devicetree.c | 77
> drivers/of/irq.c | 118
> ++
> include/linux/of_irq.h | 31
> 19 files changed, 248 insertions(+), 174 deletions(-)
> delete mode 100644 arch/x86/include/asm/irq_controller.h
>
> diff --git a/arch/microblaze/kernel/irq.c b/arch/microblaze/kernel/irq.c
> index ce7ac84..59bb560 100644
> --- a/arch/microblaze/kernel/irq.c
> +++ b/arch/microblaze/kernel/irq.c
> @@ -54,10 +54,3 @@ unsigned int irq_create_mapping(struct irq_host *host,
> irq_hw_number_t hwirq)
> return hwirq;
> }
> EXPORT_SYMBOL_GPL(irq_create_mapping);
> -
> -unsigned int irq_create_of_mapping(struct device_node *controller,
> -const u32 *intspec, unsigned int intsize)
> -{
> - return intspec[0];
> -}
> -EXPORT_SYMBOL_GPL(irq_create_of_mapping);
> diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
> index a19811e9..0b82f98 100644
> --- a/arch/mips/kernel/prom.c
> +++ b/arch/mips/kernel/prom.c
> @@ -60,20 +60,6 @@ void __init early_init_dt_setup_initrd_arch(unsigned long
> start,
> }
> #endif
>
> -/*
> - * irq_create_of_mapping - Hook to resolve OF irq specifier into a Linux irq#
> - *
> - * Currently the mapping mechanism is trivial; simple flat hwirq numbers are
> - * mapped 1:1 onto Linux irq numbers. Cascaded irq controllers are not
> - * supported.
> - */
> -unsigned int irq_create_of_mapping(struct device_node *controller,
> -const u32 *intspec, unsigned int intsize)
> -{
> - return intspec[0];
> -}
> -EXPORT_SYMBOL_GPL(irq_create_of_mapping);
> -
> void __init early_init_devtree(void *params)
> {
> /* Setup flat device-tree pointer */
> diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
> index a44be93..ccefc8c 1006
Re: [PATCH 3/6] powerpc: Make struct irq_host semi-private by moving into irqhost.h
On Thu, 2011-04-28 at 14:01 -0600, Grant Likely wrote:
> Very few files actually need direct access to struct irq_host members.
> This patch moves the irq_host definition into another file so that it
> isn't brought in by default, and to prepare for the addition of
> struct of_irq_domain, which will factor some of the irq_host behaviour
> out into common code. This needs to be done because of_irq_domain
> will be embedded inside struct irq_host, and to do that it needs to be
> guaranteed that struct of_irq_domain gets fully defined first.
Why do you want to separate the irq "host" as used by powerpc with the
generic irq domain ? They should be one single thing...
Cheers,
Ben.
> Signed-off-by: Grant Likely
> ---
> arch/powerpc/include/asm/irq.h | 20 +--
> arch/powerpc/include/asm/irqhost.h | 29
> ++
> arch/powerpc/kernel/irq.c|1 +
> arch/powerpc/platforms/512x/mpc5121_ads_cpld.c |1 +
> arch/powerpc/platforms/52xx/media5200.c |1 +
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c|1 +
> arch/powerpc/platforms/52xx/mpc52xx_pic.c|1 +
> arch/powerpc/platforms/82xx/pq2ads-pci-pic.c |1 +
> arch/powerpc/platforms/cell/axon_msi.c |1 +
> arch/powerpc/platforms/cell/spider-pic.c |1 +
> arch/powerpc/platforms/embedded6xx/flipper-pic.c |1 +
> arch/powerpc/platforms/embedded6xx/hlwd-pic.c|1 +
> arch/powerpc/platforms/embedded6xx/wii.c |6 +++--
> arch/powerpc/sysdev/fsl_msi.c|1 +
> arch/powerpc/sysdev/i8259.c |1 +
> arch/powerpc/sysdev/ipic.c |1 +
> arch/powerpc/sysdev/mpc8xxx_gpio.c |1 +
> arch/powerpc/sysdev/mpic.c |1 +
> arch/powerpc/sysdev/mpic_msi.c |1 +
> arch/powerpc/sysdev/mpic_pasemi_msi.c|1 +
> arch/powerpc/sysdev/qe_lib/qe_ic.c |1 +
> arch/powerpc/sysdev/uic.c|1 +
> arch/powerpc/sysdev/xilinx_intc.c|1 +
> 23 files changed, 54 insertions(+), 21 deletions(-)
> create mode 100644 arch/powerpc/include/asm/irqhost.h
>
> diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
> index 4d2cc6f..a44be93 100644
> --- a/arch/powerpc/include/asm/irq.h
> +++ b/arch/powerpc/include/asm/irq.h
> @@ -104,29 +104,11 @@ struct irq_host_ops {
>irq_hw_number_t *out_hwirq, unsigned int *out_type);
> };
>
> -struct irq_host {
> - struct list_headlink;
> -
> - /* type of reverse mapping technique */
> - unsigned intrevmap_type;
> +/* Reverse map types; pass into irq_alloc_host revmap_type argument */
> #define IRQ_HOST_MAP_LEGACY 0 /* legacy 8259, gets irqs 1..15 */
> #define IRQ_HOST_MAP_NOMAP 1 /* no fast reverse mapping */
> #define IRQ_HOST_MAP_LINEAR 2 /* linear map of interrupts */
> #define IRQ_HOST_MAP_TREE3 /* radix tree */
> - union {
> - struct {
> - unsigned int size;
> - unsigned int *revmap;
> - } linear;
> - struct radix_tree_root tree;
> - } revmap_data;
> - struct irq_host_ops *ops;
> - void*host_data;
> - irq_hw_number_t inval_irq;
> -
> - /* Optional device node pointer */
> - struct device_node *of_node;
> -};
>
> struct irq_data;
> extern irq_hw_number_t irqd_to_hwirq(struct irq_data *d);
> diff --git a/arch/powerpc/include/asm/irqhost.h
> b/arch/powerpc/include/asm/irqhost.h
> new file mode 100644
> index 000..958e6c1
> --- /dev/null
> +++ b/arch/powerpc/include/asm/irqhost.h
> @@ -0,0 +1,29 @@
> +#ifndef _ASM_POWERPC_IRQHOST_H
> +#define _ASM_POWERPC_IRQHOST_H
> +
> +#include
> +#include
> +#include
> +#include
> +
> +struct irq_host {
> + struct list_headlink;
> +
> + /* type of reverse mapping technique */
> + unsigned intrevmap_type;
> + union {
> + struct {
> + unsigned int size;
> + unsigned int *revmap;
> + } linear;
> + struct radix_tree_root tree;
> + } revmap_data;
> + struct irq_host_ops *ops;
> + void*host_data;
> + irq_hw_number_t inval_irq;
> +
> + /* Optional device node pointer */
> + struct device_node *of_node;
> +};
> +
> +#endif /* _ASM_POWERPC_IRQHOST_H */
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 5ccf38f..b961b19 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -56,6 +56,7 @@
> #include
> #include
>
> +#include
> #include
> #include
> #include
> diff --git a/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
> b/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
> index a8b
Re: [PATCH v6 3/6] video, sm501: add edid and commandline support
Hello Grant, Grant Likely wrote: > On Mon, May 2, 2011 at 4:27 PM, Grant Likely > wrote: >> On Tue, Mar 22, 2011 at 09:27:29AM +0100, Heiko Schocher wrote: >>> - add commandline options: >>> sm501fb.mode: >>> Specify resolution as "x[-][@]" >>> sm501fb.bpp: >>> Specify bit-per-pixel if not specified mode >>> >>> - Add support for encoding display mode information >>> in the device tree using verbatim EDID block. >>> >>> If the "edid" entry in the "smi,sm501" node is present, >>> the driver will build mode database using EDID data >>> and allow setting the display modes from this database. >>> >>> Signed-off-by: Heiko Schocher >> Merged, thanks. > > This patch causes the following build warning: Hups ... when I posted the patch, it compiled clean ... > MODPOST vmlinux.o > WARNING: vmlinux.o(.text+0x1d5572): Section mismatch in reference from > the function sm501fb_init_fb() to the variable > .devinit.data:sm501_default_mode > The function sm501fb_init_fb() references > the variable __devinitdata sm501_default_mode. > This is often because sm501fb_init_fb lacks a __devinitdata > annotation or the annotation of sm501_default_mode is wrong. > > WARNING: vmlinux.o(.text+0x1d557a): Section mismatch in reference from > the function sm501fb_init_fb() to the variable > .devinit.data:sm501_default_mode > The function sm501fb_init_fb() references > the variable __devinitdata sm501_default_mode. > This is often because sm501fb_init_fb lacks a __devinitdata > annotation or the annotation of sm501_default_mode is wrong. > > I've dropped the __devinitdata declaration in what I committed; can > you investigate and post a fixup patch? Of course, I look ASAP at it, thanks! (Dummy question: where can I find your tree?) bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 0/6] powerpc, 52xx: add charon board support
Hello Grant, Grant Likely wrote: > On Tue, Mar 22, 2011 at 09:27:26AM +0100, Heiko Schocher wrote: >> cc: Wolfram Sang >> cc: Grant Likely >> cc: Benjamin Herrenschmidt >> cc: linux-fb...@vger.kernel.org >> cc: devicetree-disc...@ozlabs.org >> cc: Ben Dooks >> cc: Vincent Sanders >> cc: Samuel Ortiz >> cc: linux-ker...@vger.kernel.org >> cc: Randy Dunlap >> cc: Wolfgang Denk >> cc: Paul Mundt >> >> changes since v5: >> - repost complete patchseries, as Paul Mundt suggested >> - rebased against current head >> - add Acked-by from Samuel Ortiz (MFD parts) >> http://www.spinics.net/lists/linux-fbdev/msg02550.html >> http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg11798.html >> >> and Benjamin Herrenschmidt (DTS parts) >> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088279.html >> - removed patch >> "powerpc, mpc5200: update mpc5200_defconfig to fit for charon board." >> therefore added >> "powerpc, tqm5200: update tqm5200_defconfig to fit for charon board." > > Refresh my memory, why was the mpc5200_defconfig updated dropped? Because it is a board based on the tqm5200 board port ... no other reason. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Login prompt on a video console instead of serial port?
On Mon, 2011-05-02 at 15:02 -0500, Timur Tabi wrote: > McClintock Matthew-B29882 wrote: > > Don't you have to spawn a terminal on the framebuffer for the login? > > I suppose, but I don't know how to do that. And although that would > technically > answer the question in the subject of this thread, I still would have *some* > boot output on the serial port. It would be nice if I could get all of stdout > on the video display, and all of stdin from the serial port. I don't think we have a way to do that unless you can make a serial "keyboard" device in the input layer. The VT layer will only get its input from such a thing, maybe that does exist in the depth of legacy code in there but it has nothing to do with your device-tree. > > Right now getty spawns the login on the serial port via /etc/inittab. > > Something similiar is probably needed for the framebuffer. > > getty appears to work only with serial devices, since it insists on a baud > rate > as one of the parameters. No, or no existing distro would work :-) Just fake a baudrate for the tty's Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 0/6] powerpc, 52xx: add charon board support
On Mon, May 2, 2011 at 11:17 PM, Heiko Schocher wrote: > Hello Grant, > > Grant Likely wrote: >> On Tue, Mar 22, 2011 at 09:27:26AM +0100, Heiko Schocher wrote: >>> cc: Wolfram Sang >>> cc: Grant Likely >>> cc: Benjamin Herrenschmidt >>> cc: linux-fb...@vger.kernel.org >>> cc: devicetree-disc...@ozlabs.org >>> cc: Ben Dooks >>> cc: Vincent Sanders >>> cc: Samuel Ortiz >>> cc: linux-ker...@vger.kernel.org >>> cc: Randy Dunlap >>> cc: Wolfgang Denk >>> cc: Paul Mundt >>> >>> changes since v5: >>> - repost complete patchseries, as Paul Mundt suggested >>> - rebased against current head >>> - add Acked-by from Samuel Ortiz (MFD parts) >>> http://www.spinics.net/lists/linux-fbdev/msg02550.html >>> http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg11798.html >>> >>> and Benjamin Herrenschmidt (DTS parts) >>> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088279.html >>> - removed patch >>> "powerpc, mpc5200: update mpc5200_defconfig to fit for charon board." >>> therefore added >>> "powerpc, tqm5200: update tqm5200_defconfig to fit for charon board." >> >> Refresh my memory, why was the mpc5200_defconfig updated dropped? > > Because it is a board based on the tqm5200 board port ... no other > reason. Please send a patch to also update the mpc5200_defconfig. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 3/6] video, sm501: add edid and commandline support
On Mon, May 2, 2011 at 11:27 PM, Heiko Schocher wrote: > Hello Grant, > > Grant Likely wrote: >> On Mon, May 2, 2011 at 4:27 PM, Grant Likely >> wrote: >>> On Tue, Mar 22, 2011 at 09:27:29AM +0100, Heiko Schocher wrote: - add commandline options: sm501fb.mode: Specify resolution as "x[-][@]" sm501fb.bpp: Specify bit-per-pixel if not specified mode - Add support for encoding display mode information in the device tree using verbatim EDID block. If the "edid" entry in the "smi,sm501" node is present, the driver will build mode database using EDID data and allow setting the display modes from this database. Signed-off-by: Heiko Schocher >>> Merged, thanks. >> >> This patch causes the following build warning: > > Hups ... when I posted the patch, it compiled clean ... > >> MODPOST vmlinux.o >> WARNING: vmlinux.o(.text+0x1d5572): Section mismatch in reference from >> the function sm501fb_init_fb() to the variable >> .devinit.data:sm501_default_mode >> The function sm501fb_init_fb() references >> the variable __devinitdata sm501_default_mode. >> This is often because sm501fb_init_fb lacks a __devinitdata >> annotation or the annotation of sm501_default_mode is wrong. >> >> WARNING: vmlinux.o(.text+0x1d557a): Section mismatch in reference from >> the function sm501fb_init_fb() to the variable >> .devinit.data:sm501_default_mode >> The function sm501fb_init_fb() references >> the variable __devinitdata sm501_default_mode. >> This is often because sm501fb_init_fb lacks a __devinitdata >> annotation or the annotation of sm501_default_mode is wrong. >> >> I've dropped the __devinitdata declaration in what I committed; can >> you investigate and post a fixup patch? > > Of course, I look ASAP at it, thanks! > (Dummy question: where can I find your tree?) git://git.secretlab.ca/git/linux-2.6 powerpc/next g. > > bye, > Heiko > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > -- 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
[PATCH] powerpc: Add Initiate Coprocessor Store Word (icswx) support
From: Tseng-Hui (Frank) Lin
Icswx is a PowerPC instruction to send data to a co-processor. On Book-S
processors the LPAR_ID and process ID (PID) of the owning process are
registered in the window context of the co-processor at initialization
time. When the icswx instruction is executed the L2 generates a cop-reg
transaction on PowerBus. The transaction has no address and the
processor does not perform an MMU access to authenticate the transaction.
The co-processor compares the LPAR_ID and the PID included in the
transaction and the LPAR_ID and PID held in the window context to
determine if the process is authorized to generate the transaction.
The OS needs to assign a 16-bit PID for the process. This cop-PID needs
to be updated during context switch. The cop-PID needs to be destroyed
when the context is destroyed.
Signed-off-by: Sonny Rao
Signed-off-by: Tseng-Hui (Frank) Lin
Signed-off-by: Anton Blanchard
---
Changes:
- Go back to dynamically allocating the spinlock to avoid the mmu_context.h
and spinlock_types.h include mess.
Index: linux-powerpc/arch/powerpc/include/asm/cputable.h
===
--- linux-powerpc.orig/arch/powerpc/include/asm/cputable.h 2011-05-03
16:39:21.779140935 +1000
+++ linux-powerpc/arch/powerpc/include/asm/cputable.h 2011-05-03
16:39:26.059220272 +1000
@@ -197,6 +197,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_STCX_CHECKS_ADDRESSLONG_ASM_CONST(0x0200)
#define CPU_FTR_POPCNTB
LONG_ASM_CONST(0x0400)
#define CPU_FTR_POPCNTD
LONG_ASM_CONST(0x0800)
+#define CPU_FTR_ICSWX LONG_ASM_CONST(0x1000)
#ifndef __ASSEMBLY__
@@ -418,7 +419,8 @@ 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_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_ICSWX)
#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 | \
Index: linux-powerpc/arch/powerpc/include/asm/mmu-hash64.h
===
--- linux-powerpc.orig/arch/powerpc/include/asm/mmu-hash64.h2011-05-03
16:39:21.789141120 +1000
+++ linux-powerpc/arch/powerpc/include/asm/mmu-hash64.h 2011-05-03
16:39:26.059220272 +1000
@@ -408,6 +408,7 @@ static inline void subpage_prot_init_new
#endif /* CONFIG_PPC_SUBPAGE_PROT */
typedef unsigned long mm_context_id_t;
+struct spinlock;
typedef struct {
mm_context_id_t id;
@@ -423,6 +424,11 @@ typedef struct {
#ifdef CONFIG_PPC_SUBPAGE_PROT
struct subpage_prot_table spt;
#endif /* CONFIG_PPC_SUBPAGE_PROT */
+#ifdef CONFIG_PPC_ICSWX
+ struct spinlock *cop_lockp; /* guard acop and cop_pid */
+ unsigned long acop; /* mask of enabled coprocessor types */
+ unsigned int cop_pid; /* pid value used with coprocessors */
+#endif /* CONFIG_PPC_ICSWX */
} mm_context_t;
Index: linux-powerpc/arch/powerpc/include/asm/mmu_context.h
===
--- linux-powerpc.orig/arch/powerpc/include/asm/mmu_context.h 2011-05-03
16:39:21.779140935 +1000
+++ linux-powerpc/arch/powerpc/include/asm/mmu_context.h2011-05-03
16:39:26.059220272 +1000
@@ -32,6 +32,10 @@ extern void __destroy_context(unsigned l
extern void mmu_context_init(void);
#endif
+extern void switch_cop(struct mm_struct *next);
+extern int use_cop(unsigned long acop, struct mm_struct *mm);
+extern void drop_cop(unsigned long acop, struct mm_struct *mm);
+
/*
* switch_mm is the entry point called from the architecture independent
* code in kernel/sched.c
@@ -55,6 +59,12 @@ static inline void switch_mm(struct mm_s
if (prev == next)
return;
+#ifdef CONFIG_PPC_ICSWX
+ /* Switch coprocessor context only if prev or next uses a coprocessor */
+ if (prev->context.acop || next->context.acop)
+ switch_cop(next);
+#endif /* CONFIG_PPC_ICSWX */
+
/* We must stop all altivec streams before changing the HW
* context
*/
Index: linux-powerpc/arch/powerpc/include/asm/reg.h
===
--- linux-powerpc.orig/arch/powerpc/include/asm/reg.h 2011-05-03
16:39:21.799141306 +1000
+++ linux-powerpc/arch/powerpc/include/asm/reg.h2011-05-03
16:39:26.059220272 +1000
@@ -188,6 +188,7 @@
#define SPRN_CTR 0x009 /* Count Register */
#define SPRN_DSCR 0x11
+#define SPRN_ACOP 0x1F/* Available Coprocessor Register */
#define SPRN_CTRLF 0x088
Re: [PATCH] powerpc: Add Initiate Coprocessor Store Word (icswx) support
On Tue, 2011-05-03 at 16:43 +1000, Anton Blanchard wrote:
> From: Tseng-Hui (Frank) Lin
>
> Icswx is a PowerPC instruction to send data to a co-processor. On Book-S
> processors the LPAR_ID and process ID (PID) of the owning process are
> registered in the window context of the co-processor at initialization
> time. When the icswx instruction is executed the L2 generates a cop-reg
> transaction on PowerBus. The transaction has no address and the
> processor does not perform an MMU access to authenticate the transaction.
> The co-processor compares the LPAR_ID and the PID included in the
> transaction and the LPAR_ID and PID held in the window context to
> determine if the process is authorized to generate the transaction.
>
> The OS needs to assign a 16-bit PID for the process. This cop-PID needs
> to be updated during context switch. The cop-PID needs to be destroyed
> when the context is destroyed.
> Signed-off-by: Sonny Rao
> Signed-off-by: Tseng-Hui (Frank) Lin
> Signed-off-by: Anton Blanchard
> ---
>
> Changes:
>
> - Go back to dynamically allocating the spinlock to avoid the mmu_context.h
> and spinlock_types.h include mess.
My only comment (sorry Anton :-) would have been that we could lazily
allocate the spinlock on the first use_cop() ... or do we have that
potentially called in the wrong context ?
Cheers,
Ben.
> Index: linux-powerpc/arch/powerpc/include/asm/cputable.h
> ===
> --- linux-powerpc.orig/arch/powerpc/include/asm/cputable.h2011-05-03
> 16:39:21.779140935 +1000
> +++ linux-powerpc/arch/powerpc/include/asm/cputable.h 2011-05-03
> 16:39:26.059220272 +1000
> @@ -197,6 +197,7 @@ extern const char *powerpc_base_platform
> #define CPU_FTR_STCX_CHECKS_ADDRESS LONG_ASM_CONST(0x0200)
> #define CPU_FTR_POPCNTB
> LONG_ASM_CONST(0x0400)
> #define CPU_FTR_POPCNTD
> LONG_ASM_CONST(0x0800)
> +#define CPU_FTR_ICSWX
> LONG_ASM_CONST(0x1000)
>
> #ifndef __ASSEMBLY__
>
> @@ -418,7 +419,8 @@ 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_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_ICSWX)
> #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 | \
> Index: linux-powerpc/arch/powerpc/include/asm/mmu-hash64.h
> ===
> --- linux-powerpc.orig/arch/powerpc/include/asm/mmu-hash64.h 2011-05-03
> 16:39:21.789141120 +1000
> +++ linux-powerpc/arch/powerpc/include/asm/mmu-hash64.h 2011-05-03
> 16:39:26.059220272 +1000
> @@ -408,6 +408,7 @@ static inline void subpage_prot_init_new
> #endif /* CONFIG_PPC_SUBPAGE_PROT */
>
> typedef unsigned long mm_context_id_t;
> +struct spinlock;
>
> typedef struct {
> mm_context_id_t id;
> @@ -423,6 +424,11 @@ typedef struct {
> #ifdef CONFIG_PPC_SUBPAGE_PROT
> struct subpage_prot_table spt;
> #endif /* CONFIG_PPC_SUBPAGE_PROT */
> +#ifdef CONFIG_PPC_ICSWX
> + struct spinlock *cop_lockp; /* guard acop and cop_pid */
> + unsigned long acop; /* mask of enabled coprocessor types */
> + unsigned int cop_pid; /* pid value used with coprocessors */
> +#endif /* CONFIG_PPC_ICSWX */
> } mm_context_t;
>
>
> Index: linux-powerpc/arch/powerpc/include/asm/mmu_context.h
> ===
> --- linux-powerpc.orig/arch/powerpc/include/asm/mmu_context.h 2011-05-03
> 16:39:21.779140935 +1000
> +++ linux-powerpc/arch/powerpc/include/asm/mmu_context.h 2011-05-03
> 16:39:26.059220272 +1000
> @@ -32,6 +32,10 @@ extern void __destroy_context(unsigned l
> extern void mmu_context_init(void);
> #endif
>
> +extern void switch_cop(struct mm_struct *next);
> +extern int use_cop(unsigned long acop, struct mm_struct *mm);
> +extern void drop_cop(unsigned long acop, struct mm_struct *mm);
> +
> /*
> * switch_mm is the entry point called from the architecture independent
> * code in kernel/sched.c
> @@ -55,6 +59,12 @@ static inline void switch_mm(struct mm_s
> if (prev == next)
> return;
>
> +#ifdef CONFIG_PPC_ICSWX
> + /* Switch coprocessor context only if prev or next uses a coprocessor */
> + if (prev->context.acop || next->context.acop)
> + switch_cop(next);
> +#endif /* CONFIG_PPC_ICSWX */
> +
> /* We must stop all altivec streams before changing the HW
>* context
>*/
> Index: linux-powerpc/arch/powerpc/include/asm/reg.h
> ===
Re: [PATCH] powerpc: Add Initiate Coprocessor Store Word (icswx) support
Hi Ben, > My only comment (sorry Anton :-) would have been that we could lazily > allocate the spinlock on the first use_cop() ... or do we have that > potentially called in the wrong context ? I worry what might happen in a threaded app. It would be a strange thing to do, but the program may call use_cop from two threads at the same time. In that case you could corrupt the PID/ACOP values and leak a spinlock of memory I think. Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
