Re: powerpc/mpc5200: remove unused #include
On Fri, Aug 22, 2008 at 11:56 PM, Huang Weiyi <[EMAIL PROTECTED]> wrote: > The file(s) below do not use LINUX_VERSION_CODE nor KERNEL_VERSION. > arch/powerpc/sysdev/bestcomm/gen_bd.c > > This patch removes the said #include . > > Signed-off-by: Huang Weiyi <[EMAIL PROTECTED]> Thanks, I'll queue this for .28 g. > > diff --git a/arch/powerpc/sysdev/bestcomm/gen_bd.c > b/arch/powerpc/sysdev/bestcomm/gen_bd.c > index a3a134c..e0a53e3 100644 > --- a/arch/powerpc/sysdev/bestcomm/gen_bd.c > +++ b/arch/powerpc/sysdev/bestcomm/gen_bd.c > @@ -11,7 +11,6 @@ > * > */ > > -#include > #include > #include > #include > > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC] XilinxFB: removed unused #include
On Fri, Aug 22, 2008 at 11:56 PM, Huang Weiyi <[EMAIL PROTECTED]> wrote: > The driver(s) below do not use LINUX_VERSION_CODE nor KERNEL_VERSION. > drivers/video/xilinxfb.c > > This patch removes the said #include . > > Signed-off-by: Huang Weiyi <[EMAIL PROTECTED]> Thanks, I'll pick this one up for .28 g. > > diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c > index 7b3a842..5da3d24 100644 > --- a/drivers/video/xilinxfb.c > +++ b/drivers/video/xilinxfb.c > @@ -24,7 +24,6 @@ > #include > #include > #include > -#include > #include > #include > #include > > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC] XilinxFB: removed unused #include
The driver(s) below do not use LINUX_VERSION_CODE nor KERNEL_VERSION. drivers/video/xilinxfb.c This patch removes the said #include . Signed-off-by: Huang Weiyi <[EMAIL PROTECTED]> diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c index 7b3a842..5da3d24 100644 --- a/drivers/video/xilinxfb.c +++ b/drivers/video/xilinxfb.c @@ -24,7 +24,6 @@ #include #include #include -#include #include #include #include ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc/mpc5200: remove unused #include
The file(s) below do not use LINUX_VERSION_CODE nor KERNEL_VERSION. arch/powerpc/sysdev/bestcomm/gen_bd.c This patch removes the said #include . Signed-off-by: Huang Weiyi <[EMAIL PROTECTED]> diff --git a/arch/powerpc/sysdev/bestcomm/gen_bd.c b/arch/powerpc/sysdev/bestcomm/gen_bd.c index a3a134c..e0a53e3 100644 --- a/arch/powerpc/sysdev/bestcomm/gen_bd.c +++ b/arch/powerpc/sysdev/bestcomm/gen_bd.c @@ -11,7 +11,6 @@ * */ -#include #include #include #include ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Pika Warp appliance watchdog timer
The FPGA based watchdog timer used by the Pika Warp appliance.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index db20542..2bbb607 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -719,6 +719,14 @@ config BOOKE_WDT
Please see Documentation/watchdog/watchdog-api.txt for
more information.
+config PIKA_WDT
+ tristate "PIKA FPGA Watchdog"
+ depends on WARP
+ default y
+ help
+This enables the watchdog in the PIKA FPGA. Currently used on
+the Warp platform.
+
# PPC64 Architecture
config WATCHDOG_RTAS
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index ca3dc04..3527290 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
obj-$(CONFIG_8xxx_WDT) += mpc8xxx_wdt.o
obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
+obj-$(CONFIG_PIKA_WDT) += pika_wdt.o
# PPC64 Architecture
obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
diff --git a/drivers/watchdog/pika_wdt.c b/drivers/watchdog/pika_wdt.c
new file mode 100644
index 000..32e11f7
--- /dev/null
+++ b/drivers/watchdog/pika_wdt.c
@@ -0,0 +1,113 @@
+/*
+ * PIKA FPGA based Watchdog Timer
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+static void __iomem *pikawdt_fpga;
+
+
+static inline void pikawdt_ping(void)
+{
+ unsigned reset = in_be32(pikawdt_fpga + 0x14);
+ reset |= 0xf80; /* enable with max timeout - 15 seconds */
+ out_be32(pikawdt_fpga + 0x14, reset);
+}
+
+static int pikawdt_open(struct inode *inode, struct file *file)
+{
+ printk(KERN_INFO "PIKA WDT started...\n");
+
+ pikawdt_ping();
+
+ return 0;
+}
+
+static int pikawdt_release(struct inode *inode, struct file *file)
+{
+ pikawdt_ping(); /* one last time */
+ return 0;
+}
+
+static ssize_t pikawdt_write(struct file *file, const char __user *buf,
+size_t count, loff_t *ppos)
+{
+ pikawdt_ping();
+ return count;
+}
+
+/* We support the bare minimum to be conformant. */
+static int pikawdt_ioctl(struct inode *inode, struct file *file,
+unsigned int cmd, unsigned long arg)
+{
+ if (cmd == WDIOC_KEEPALIVE) {
+ pikawdt_ping();
+ return 0;
+ } else
+ return -EINVAL;
+}
+
+static const struct file_operations pikawdt_fops = {
+ .owner = THIS_MODULE,
+ .open = pikawdt_open,
+ .release= pikawdt_release,
+ .write = pikawdt_write,
+ .ioctl = pikawdt_ioctl,
+};
+
+static struct miscdevice pikawdt_miscdev = {
+ .minor = WATCHDOG_MINOR,
+ .name = "watchdog",
+ .fops = &pikawdt_fops,
+};
+
+static int __init pikawdt_init(void)
+{
+ struct device_node *np;
+ int ret;
+
+ np = of_find_compatible_node(NULL, NULL, "pika,fpga");
+ if (np == NULL) {
+ printk(KERN_ERR "pikawdt: Unable to find fpga.\n");
+ return -ENOENT;
+ }
+
+ pikawdt_fpga = of_iomap(np, 0);
+
+ of_node_put(np);
+
+ if (pikawdt_fpga == NULL) {
+ printk(KERN_ERR "pikawdt: Unable to map fpga.\n");
+ return -ENOENT;
+ }
+
+ ret = misc_register(&pikawdt_miscdev);
+ if (ret) {
+ iounmap(pikawdt_fpga);
+ printk(KERN_ERR "pikawdt: Unable to register miscdev.\n");
+ return ret;
+ }
+
+ return 0;
+}
+module_init(pikawdt_init);
+
+
+static void __exit pikawdt_exit(void)
+{
+ misc_deregister(&pikawdt_miscdev);
+
+ iounmap(pikawdt_fpga);
+}
+module_exit(pikawdt_exit);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: checkpatch nits ...
On Fri, 22 Aug 2008 17:21:44 -0700 "Kevin Diggs" <[EMAIL PROTECTED]> wrote: > Hi, > > Can I ignore these checkpatch errors: > > ERROR: do not initialise statics to 0 or NULL > #829: FILE: powerpc/kernel/cpu/pll_if.c:61: > +static unsigned int override_bus_clock = 0; > > ERROR: do not initialise externals to 0 or NULL > #1281: FILE: powerpc/kernel/cpu/pll_if.c:513: > +int rval = 0; > > Someone (Arnd?) told me this was due to an older compiler putting > these in a strange section? Older gcc, and in fact many (most?) compilers, put *all* initialized variables in a data section rather than the bss. This means they took up room in the executable. By not explicitly setting them to zero, they where put in the bss and initialized to zero anyway. Newer gccs will put them in the bss if they are zero. You could argue that this is technically wrong. I tend to remove the 0s or nulls just to cut down on the checkpatch errors. You need to decide if it is worth it. I wouldn't submit a patch with *just* these changes. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
checkpatch nits ...
Hi, Can I ignore these checkpatch errors: ERROR: do not initialise statics to 0 or NULL #829: FILE: powerpc/kernel/cpu/pll_if.c:61: +static unsigned int override_bus_clock = 0; ERROR: do not initialise externals to 0 or NULL #1281: FILE: powerpc/kernel/cpu/pll_if.c:513: +int rval = 0; Someone (Arnd?) told me this was due to an older compiler putting these in a strange section? WARNING: externs should be avoided in .c files #1137: FILE: powerpc/kernel/cpu/pll_if.c:369: + __asm__ __volatile__ ( ??? I don't know what this is? The entire block is: __asm__ __volatile__ ( "addi %0,%3,-1\n" "andc %1,%3,%0\n" "cntlzw %1,%1\n" "subfic %1,%1,31\n" "cntlzw %0,%2\n": "=r"(cntlz), "=r"(cnttz): "r"(tmp), "b"(cnttz) ); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Why does one "stw" fail with address translation disabled in PPC405EP?
On Fri, Aug 22, 2008 at 08:27:15PM +0200, Zhou Rui wrote: >Hi, all: >I think I meet an odd problem with PPC405EP (PPChameleonEVB Board). What kernel version are you using? >I am running a kernel module which will execute a user space >application. The entry point of the application is 0x10a0. At the That should be the first clue that you are doing it wrong. Don't do stuff like that in modules... >moment when the processor tries to execute the application, 0x10a0 >is not in TLB (this can be seen from BDI by printing out TLB entries), >so DTLBMiss is called automatically and then finish_tlb_load. However, >InstructionAccess is followed and the problem arises here. >InstructionAccess starts from 0x400, and after instruction "0xc434 >: stw r12,64(r11)", machine check occurs. >This instruction will store the value of r12, which is 0x0 at this >moment, to address 0x03072de0. I am puzzled why this action leads to >machine check. Is it illegal to store 0x0 in a memory address? Or is >there some other cause of the machine check here? I have no idea if you're using physical or virtual addresses here, so there isn't much we can do to help you. Do you have enough DRAM to cover that? Some of those boards only come with 32MiB of DRAM. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] POWERPC: Allow 32-bit pgtable code to support 36-bit physical
On Aug 21, 2008, at 4:40 PM, Kumar Gala wrote:
#define _PMD_PRESENT0
#define _PMD_PRESENT_MASK (PAGE_MASK)
@@ -517,7 +522,13 @@ extern unsigned long
bad_call_to_PMD_PAGE_SIZE(void);
#define pte_none(pte) ((pte_val(pte) & ~_PTE_NONE_MASK) == 0)
#define pte_present(pte)(pte_val(pte) & _PAGE_PRESENT)
+
+#if (defined(CONFIG_PTE_64BIT) && (_PAGE_HASHPTE != 0))
+#define pte_clear(mm, addr, ptep) \
+ do { pte_update((ptep), (~_PAGE_HASHPTE), __pte(0)); } while (0)
drop the __pte(0), doesn't make sense for pte_update
Cut-and-paste strikes again :) Will fix, thanks.
+#else
#define pte_clear(mm,addr,ptep) do { set_pte_at((mm), (addr),
(ptep), __pte(0)); } while (0)
+#endif
Can we just always (for all ppc32) do:
#define pte_clear(mm,addr,ptep)do { pte_update(ptep,
(~_PAGE_HASHPTE), 0); } while (0)
I've already changed this to be:
#define pte_clear(mm,addr,ptep) do { pte_update(ptep, ~0, 0); }
while (0)
That's fine, but it makes me dependent on your tree. Shall I respin
on top of your tree and have you pick this up, or are you going to
push your changes to Paulus?
/*
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/
include/asm/types.h
index d3374bc..a9a9262 100644
--- a/arch/powerpc/include/asm/types.h
+++ b/arch/powerpc/include/asm/types.h
@@ -55,7 +55,7 @@ typedef u64 phys_addr_t;
typedef u32 phys_addr_t;
#endif
-#ifdef __powerpc64__
+#if defined(__powerpc64__) || defined(CONFIG_PHYS_64BIT)
typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
is this really part of this patchset of the IOMMU changes?
It doesn't really belong here - I'll move it.
Thanks,
B
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Why does one "stw" fail with address translation disabled in PPC405EP?
Hi, all:
I think I meet an odd problem with PPC405EP (PPChameleonEVB Board).
I am running a kernel module which will execute a user space
application. The entry point of the application is 0x10a0. At the
moment when the processor tries to execute the application, 0x10a0
is not in TLB (this can be seen from BDI by printing out TLB entries),
so DTLBMiss is called automatically and then finish_tlb_load. However,
InstructionAccess is followed and the problem arises here.
InstructionAccess starts from 0x400, and after instruction "0xc434
: stw r12,64(r11)", machine check occurs.
This instruction will store the value of r12, which is 0x0 at this
moment, to address 0x03072de0. I am puzzled why this action leads to
machine check. Is it illegal to store 0x0 in a memory address? Or is
there some other cause of the machine check here?
405EP>r
GPR00: c31c5200 c3072da0 c03a97b0 10a0
GPR04: c306a000 c306e000 c31c51b8 c306a000
GPR08: c0a64000 c0a64000 4000 03072da0
GPR12:
GPR16:
GPR20:
GPR24:
GPR28: c31d 10a0 c306a000
CR : 2000 MSR: 1000
405EP>t
Core number : 0
Core state: debug mode
Debug entry cause : single step
Current PC: 0x0434
Current CR: 0x2000
Current MSR : 0x1000
Current LR: 0xc31c478c
405EP>r
GPR00: c31c5200 c3072da0 c03a97b0 10a0
GPR04: c306a000 c306e000 c31c51b8 c306a000
GPR08: c0a64000 c0a64000 4000 03072da0
GPR12:
GPR16:
GPR20:
GPR24:
GPR28: c31d 10a0 c306a000
CR : 2000 MSR: 1000
405EP>t
Core number : 0
Core state: debug mode
Debug entry cause : single step
Current PC: 0x0200
Current CR: 0x2000
Current MSR : 0x1000
Current LR: 0xc31c478c
405EP>
The error message shows more information. I am also puzzled why NIP here
is 0x440 but not 0x434:
Data machine check in kernel mode.
PLB0: BEAR= 0x03072dd4 ACR= 0x BESR= 0x00c0
PLB0 to OPB: BEAR= 0x0400 BESR0= 0x BESR1= 0x
Oops: machine check, sig: 7 [#1]
NIP: 0440 LR: C31C478C CTR: 10A0
REGS: c02a8f50 TRAP: 0202 Not tainted (2.6.19.2)
MSR: 00021000 CR: 2000 XER:
TASK = c0399490[987] 'loader.xm' THREAD: c028a000
GPR00: C31C5200 C3072DA0 C0399490 10A0 C306A000 C306E000 C31C51B8
C306A000
GPR08: C0413000 C0413000 03072DA0
GPR16:
GPR24: C31D 10A0
C306A000
NIP [0440] 0x440
LR [C31C478C] jump_xm_dom+0x2c/0x48 [xm]
Call Trace:
Instruction dump:
Data machine check in kernel mode.
PLB0: BEAR= 0x03072dc0 ACR= 0x BESR= 0x0080
PLB0 to OPB: BEAR= 0x0400 BESR0= 0x BESR1= 0x
Oops: machine check, sig: 7 [#2]
NIP: C0002EA8 LR: C0002E94 CTR: C31C3094
REGS: c02a8f50 TRAP: 0202 Not tainted (2.6.19.2)
MSR: 00021030 CR: 22002022 XER:
TASK = c03990d0[905] 'klogd' THREAD: c0e34000
GPR00: C0002E94 C0E35F40 C03990D0 0FFF 0001 0FFF
GPR08: 00021032 C0E34000 0804E364 100F
GPR16: 101009E8 1009DF98 100F 08046368 08046364 07FEF08C 08046130
08004B74
GPR24: 08004FA4 08046130 08004DB4 08004DB8 08004F70 080466BC 08046358
08046AC0
NIP [C0002EA8] ret_from_syscall+0x14/0x3c
LR [C0002E94] ret_from_syscall+0x0/0x3c
Call Trace:
[C0E35F40] [C0002E94] ret_from_syscall+0x0/0x3c (unreliable)
Instruction dump:
614a9634 5400103a 408000a0 7d4a002e 7d4803a6 39210010 4e800021 7c661b78
542c0024 3d42 614a1032 7d400124 <812c0028> 3900fdfc 7120db0f
408201a4
Another question is when 0x10a0 is missed in TLB, why the order of
calling kernel functions is DTLBMiss -- finish_tlb_load --
InstructionAccess?
Appreciate in advance for any advice!!!
Best Wishes
Zhou Rui
2008-08-22
__
¸Ï¿ì×¢²áÑÅ»¢³¬´óÈÝÁ¿Ãâ·ÑÓÊÏä?
http://cn.mail.yahoo.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfreevec benchmarks
On Fri, 2008-08-22 at 12:44 -0500, Ryan S. Arnold wrote: > Today, if glibc is configure with --with-cpu=970 it will actually > default to the power optimizations for the string routines, as > indicated > by the sysdeps/powerpc/powerpc[32|64]/970/Implies files. It'd be > worth > verifying that your baseline glibc runs are against existing optimized > versions of glibc. If they're not then this is a fault of the distro > you're testing on. I intended to say that "it will actually default to the POWER4 optimizations" Regards, Ryan S. Arnold IBM Linux Technology Center Linux Toolchain Development ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfreevec benchmarks
On Thu, 2008-08-21 at 19:09 +0300, Konstantinos Margaritis wrote: > Benh suggested that I made this more known, and in particular to this list, > so > I send this mail in hope that some people might be interested. In particular, > I ran the following benchmarks against libfreevec/glibc: > > http://www.freevec.org/content/libfreevec_104_benchmarks_updated Nice results. > libfreevec has reached a very stable point, where me and a couple of others > (the OpenSuse PowerPC port developer being one) have been using it for weeks > (personally I've been using it for months), using the LD_PRELOAD mechanism > (as > explained here: > http://www.freevec.org/content/howto_using_libfreevec_using_ld_preload). > The OpenSuse guys even consider using it by default on the ppc port even, but > that's not final of course. > > glibc integration _might_ happen if glibc developers change their attitude > (my > mails have been mostly ignored). Konstantinos, Do you have FSF (Free Software Foundation) copyright assignment yet? How've you implemented the optimizations? Vector insns are allowed in the PowerPC code in GLIBC if guarded by PPC_FEATURE_HAS_ALTIVEC (look at setjmp/_longjmp). The use of unguarded vector code is allowed in --with-cpu powerpc-cpu override directories for cpus that support altivec/VMX. Optimizations for individual architectures should follow the powerpc-cpu precedent for providing these routines, e.g. sysdeps/powerpc/powerpc32/power6/memcpy.S sysdeps/powerpc/powerpc64/power6/memcpy.S I believe that optimizations for the G5 processor would go into the existing 970 directories: sysdeps/powerpc/powerpc32/970 sysdeps/powerpc/powerpc64/970 Today, if glibc is configure with --with-cpu=970 it will actually default to the power optimizations for the string routines, as indicated by the sysdeps/powerpc/powerpc[32|64]/970/Implies files. It'd be worth verifying that your baseline glibc runs are against existing optimized versions of glibc. If they're not then this is a fault of the distro you're testing on. I'm not aware of the status of some of the embedded PowerPC processors with-regard to powerpc-cpu optimizations. Our research found that for some tasks on some PowerPC processors the expense of reserving the floating point pipeline for vector operations exceeds the benefit of using vector insns for the task. In these cases we tend to optimize based on pipeline characteristics rather than using the vector facility. Generally our optimizations tend to favor data an average of 12 bytes with 1000 byte max. We also favor aligned data and use the existing implementation as a model as a baseline for where we try to keep unaligned data performance from dropping below. > Last, I've also been working on a libm rewrite, though this will take some > time still. I've reimplemented most math functions at the algorithm level, > eg. > so far, most functions achieve 50%-200% speed increase at full IEEE754 > accuracy (mathematically proven, soon to be published online) without using > Altivec yet, just by choosing a different approximation method (Taylor > approximation is pretty dumb if you ask me anyway). This research would be a good candidate for selectively replacing some of the existing libm functionality. Do these results hold for all permutations of long double support? Do they hold for x86/x86_64 as well as PowerPC? I would suggest against a massive patch to libc-alpha and would instead recommend selective, individual replacement of fundamental routines to start with accompanied by exhaustive profile data. You have to show that you're dedicated to maintenance of these routines and you can't overwhelm the reviewers with massive patches. Any submission to GLIBC is going to require that you and your code follow the GLIBC process or it'll probably be ignored. You can engage me directly via CC and I can help you understand how to integrate the code but I can't give you a free pass or do the work for you. The new libc-help mailing list was also created as a place for people to learn the process and get the patches in a state where they're ready to be submitted to libc-alpha. Regards, Ryan S. Arnold IBM Linux Technology Center Linux Toolchain Development ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc: Board support for GE Fanuc SBC610
On Fri, Aug 22, 2008 at 12:26:01PM +0100, Martyn Welch wrote: > > > drop device_type. > > > > > > > Ah - _all_ device_type! > > > > Um, not all - just the ones where the name of the block matches the > device type(?) All except "cpu" and "memory". -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] POWERPC: Change total_memory to phys_addr_t
It turns out that the commit message was out of date, and the patch itself was correct. I have resubmitted with a different title/log, so this patch can be ignored. Cheers, B On Aug 22, 2008, at 10:26 AM, Becky Bruce wrote: Gah, I just noticed that part of this patch is missing - I will resubmit as soon as I figure out what the heck happened. -Becky ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Change mem.c to support large physical addresses on 32-bit
Use phys_addr_t for sizes and addresses where appropriate.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
arch/powerpc/mm/mem.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 1c93c25..89dc32b 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -75,14 +75,14 @@ static inline pte_t *virt_to_kpte(unsigned long vaddr)
int page_is_ram(unsigned long pfn)
{
- unsigned long paddr = (pfn << PAGE_SHIFT);
+ phys_addr_t paddr = ((phys_addr_t)pfn << PAGE_SHIFT);
#ifndef CONFIG_PPC64 /* XXX for now */
return paddr < __pa(high_memory);
#else
int i;
for (i=0; i < lmb.memory.cnt; i++) {
- unsigned long base;
+ phys_addr_t base;
base = lmb.memory.region[i].base;
@@ -195,7 +195,8 @@ EXPORT_SYMBOL_GPL(walk_memory_resource);
void __init do_init_bootmem(void)
{
unsigned long i;
- unsigned long start, bootmap_pages;
+ phys_addr_t start;
+ unsigned long bootmap_pages;
unsigned long total_pages;
int boot_mapsize;
@@ -234,8 +235,8 @@ void __init do_init_bootmem(void)
/* reserve the sections we're already using */
for (i = 0; i < lmb.reserved.cnt; i++) {
- unsigned long addr = lmb.reserved.region[i].base +
-lmb_size_bytes(&lmb.reserved, i) - 1;
+ phys_addr_t addr = lmb.reserved.region[i].base +
+ lmb_size_bytes(&lmb.reserved, i) - 1;
if (addr < lowmem_end_addr)
reserve_bootmem(lmb.reserved.region[i].base,
lmb_size_bytes(&lmb.reserved, i),
@@ -290,7 +291,7 @@ static int __init mark_nonram_nosave(void)
*/
void __init paging_init(void)
{
- unsigned long total_ram = lmb_phys_mem_size();
+ phys_addr_t total_ram = lmb_phys_mem_size();
phys_addr_t top_of_ram = lmb_end_of_DRAM();
unsigned long max_zone_pfns[MAX_NR_ZONES];
@@ -310,10 +311,10 @@ void __init paging_init(void)
kmap_prot = PAGE_KERNEL;
#endif /* CONFIG_HIGHMEM */
- printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%lx\n",
- (unsigned long long)top_of_ram, total_ram);
+ printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%llx\n",
+ (unsigned long long)top_of_ram, (unsigned long long)total_ram);
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
- (long int)((top_of_ram - total_ram) >> 20));
+ (unsigned long)((top_of_ram - total_ram) >> 20));
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_DMA] = lowmem_end_addr >> PAGE_SHIFT;
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
On Thu, Aug 21, 2008 at 8:39 PM, Jon Smirl <[EMAIL PROTECTED]> wrote: > On 8/21/08, Grant Likely <[EMAIL PROTECTED]> wrote: >> It was over a year ago when support for i2c devices in the device tree >> was merged. > > I see, the old support needed the drivers to be built-in. The newer > code dynamically loads the correct i2c driver and set its parameters. > > Did the old code use anything besides compatible? It would have been > using the older i2c system that probed for the address. I think you're confusing binding with implementation. The binding is the layout of data in the device tree. The implementation uses that data. Your right that the current implementation is new, but it replaces older implementation that uses the same binding. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc: Board support for GE Fanuc SBC610
On Fri, Aug 22, 2008 at 06:46:20AM -0400, Martyn Welch wrote:
> + enet0: [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <0x00024000 0x1000>;
> + mac-address = [ 00 00 00 00 00 00 ]; // set by u-boot
local-mac-address
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
On Fri, Aug 22, 2008 at 09:00:09AM -0700, Yoder Stuart wrote: >There are a few bindings specified in the ePAPR, based on the old >Open Firmware working group stuff: > -cpu > -interrupt controllers > -PCI > -network devices > -DCR devices Er, I don't think that one is based on the old workgroup. DCR is only applicable to PowerPC 4xx devices, and those have never had open firmware. >The best way to publish bindings will be on the web. I've been >looking into getting power.org to host a wiki-based site >that could be used as a repository for bindings. We could have >both an area for general bindings and company specific ones. >I've made some progress here and actually have a sandbox wiki >that I'm playing with. That sounds good, but I have one suggestion. Use the wiki for submission and discussion of new binding proposals, but once they are agreed upon put them in a static webpage somewhere until they are incorporated into the next ePAPR revision. Wikis are awesome for changing stuff, but you don't want people to go back and change a binding that has already been approved (for whatever definition of approved we come up with.) Also, you might want to have some kind of Licensing or copyright assignment for all wiki contributions. Talk to your legal team or the power.org legal team about that if you haven't already. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 0/3]: Sparc OF I2C support.
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Mitch Bradley > Sent: Friday, August 22, 2008 12:19 AM > To: David Miller > Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Wood Scott > Subject: Re: [PATCH 0/3]: Sparc OF I2C support. > > > > David Miller wrote: > > From: "Grant Likely" <[EMAIL PROTECTED]> > > Date: Thu, 21 Aug 2008 22:34:31 -0600 > > > > > >> On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely > >> <[EMAIL PROTECTED]> wrote: > >> > >>> On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley > <[EMAIL PROTECTED]> wrote: > >>> > Hi, I wrote most of 1275. > > Mitch Bradley ([EMAIL PROTECTED]) > > >>> Hi Mitch, > >>> > >>> What is your suggestion. Where should we be discussing new device > >>> tree bindings? Whether it be real Open Firmware, or > flattened device > >>> tree, or something in between > >>> > >> ...and along those lines: is there a place for documenting new > >> bindings? Lacking anything better, those of us in > PowerPC-Linux-land > >> have been adding documentation to > Documentation/powerpc/dts-bindings/* > >> in the Linux kernel tree. > >> > > > > In a discussion I am having with Greg Onufer, David K. and Tayfun > > at Sun, Greg said the some of the newer binding documents are > > being published on the opensolaris site, and he is trying to > > get some of the older cases (like this I2C one) published there > > too. > > > > > > This collection of mailing lists is as good a place as any to discuss > new bindings. I don't know how many Sun people are on the > lists, but we > might be able to persuade various Sun people to lurk on one > or more of > them; I lurk on devicetree-discuss. > > The opensolaris site seems as good as anywhere for publishing the > bindings, especially if they can pull over the old ones from e.g. > playground.sun.com . > > Another possible site might be openbios.org . I agree that the linuxppc-dev and devicetree-discuss mailing lists are probably the best place to discuss bindings. (I'm not aware of other good options). Once there is consensus as to what a binding should be, and publishing is needed-- for general, common bindings some single place is needed. Something that is ideally authoritative, with a committed organization behind it. One suggestion would be the power.org and follow on versions of the ePAPR. ePAPR 1.0 is out now and currently is a base document-- defines the flat device tree concept, and basically extracts the relevant parts of 1275 for how this is used in the embedded space. There are a few bindings specified in the ePAPR, based on the old Open Firmware working group stuff: -cpu -interrupt controllers -PCI -network devices -DCR devices -serial devices ePAPR doc is at: http://www.power.org/resources/downloads/ It's obvious that more bindings are needed, and the expecation from those who worked on the ePAPR (most or all of which are on this mailing list) was that as bindings are codified they could be added to the ePAPR. The best way to publish bindings will be on the web. I've been looking into getting power.org to host a wiki-based site that could be used as a repository for bindings. We could have both an area for general bindings and company specific ones. I've made some progress here and actually have a sandbox wiki that I'm playing with. Stuart Yoder Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
On Thu, Aug 21, 2008 at 10:39:40PM -0400, Jon Smirl wrote: > I see, the old support needed the drivers to be built-in. The newer > code dynamically loads the correct i2c driver and set its parameters. > > Did the old code use anything besides compatible? Yes. > It would have been using the older i2c system that probed for the > address. No, it wouldn't have. It used glue code to generate i2c_board_info structs. > > See commit id d13ae8620dfdedfa7e9ab6d1eec294adc0516065. As shown in the above commit id. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Fri, Aug 22, 2008 at 09:56:16AM -0400, Jimi Xenidis wrote: > Sorry, I have not really been following this, I assume you are > replacing SPR accesses with load/stores that do not trap. > I believe thats fine for reading any SPR, but not true for modifying > some SPRs, particularly MSR. > IMHO you must trap on any instruction that modifies the MSR. > So you should prolly not rewrite mtmsr or wrtee* but let them trap. You only need to trap when changing MSR[EE] if there's a pending interrupt. The hypervisor can change the mapping of the shared page when it is unable to deliver an interrupt due to the virtual EE value being zero. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] POWERPC: Change total_memory to phys_addr_t
Gah, I just noticed that part of this patch is missing - I will
resubmit as soon as I figure out what the heck happened.
-Becky
On Aug 21, 2008, at 3:10 PM, Becky Bruce wrote:
Also change consumers of various lmb funcs/arrays that are now
phys_addr_t to also be phys_addr_t.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
arch/powerpc/mm/mem.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 1c93c25..89dc32b 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -75,14 +75,14 @@ static inline pte_t *virt_to_kpte(unsigned long
vaddr)
int page_is_ram(unsigned long pfn)
{
- unsigned long paddr = (pfn << PAGE_SHIFT);
+ phys_addr_t paddr = ((phys_addr_t)pfn << PAGE_SHIFT);
#ifndef CONFIG_PPC64/* XXX for now */
return paddr < __pa(high_memory);
#else
int i;
for (i=0; i < lmb.memory.cnt; i++) {
- unsigned long base;
+ phys_addr_t base;
base = lmb.memory.region[i].base;
@@ -195,7 +195,8 @@ EXPORT_SYMBOL_GPL(walk_memory_resource);
void __init do_init_bootmem(void)
{
unsigned long i;
- unsigned long start, bootmap_pages;
+ phys_addr_t start;
+ unsigned long bootmap_pages;
unsigned long total_pages;
int boot_mapsize;
@@ -234,8 +235,8 @@ void __init do_init_bootmem(void)
/* reserve the sections we're already using */
for (i = 0; i < lmb.reserved.cnt; i++) {
- unsigned long addr = lmb.reserved.region[i].base +
-lmb_size_bytes(&lmb.reserved, i) - 1;
+ phys_addr_t addr = lmb.reserved.region[i].base +
+ lmb_size_bytes(&lmb.reserved, i) - 1;
if (addr < lowmem_end_addr)
reserve_bootmem(lmb.reserved.region[i].base,
lmb_size_bytes(&lmb.reserved, i),
@@ -290,7 +291,7 @@ static int __init mark_nonram_nosave(void)
*/
void __init paging_init(void)
{
- unsigned long total_ram = lmb_phys_mem_size();
+ phys_addr_t total_ram = lmb_phys_mem_size();
phys_addr_t top_of_ram = lmb_end_of_DRAM();
unsigned long max_zone_pfns[MAX_NR_ZONES];
@@ -310,10 +311,10 @@ void __init paging_init(void)
kmap_prot = PAGE_KERNEL;
#endif /* CONFIG_HIGHMEM */
- printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%lx\n",
- (unsigned long long)top_of_ram, total_ram);
+ printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%llx\n",
+ (unsigned long long)top_of_ram, (unsigned long
long)total_ram);
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
- (long int)((top_of_ram - total_ram) >> 20));
+ (unsigned long)((top_of_ram - total_ram) >> 20));
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_DMA] = lowmem_end_addr >> PAGE_SHIFT;
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] kvmppc: add hypercall infrastructure - guest part
On Friday 22 August 2008 05:38:54 Kumar Gala wrote: > > On Aug 19, 2008, at 5:36 AM, [EMAIL PROTECTED] wrote: > > > From: Christian Ehrhardt <[EMAIL PROTECTED]> > > > > This adds the guest portion of the hypercall infrastructure, > > basically an > > illegal instruction with a defined layout. > > See http://kvm.qumranet.com/kvmwiki/PowerPC_Hypercall_ABI for more > > detail > > on the hypercall ABI for powerpc. > > > > Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> > > --- > > > > [diffstat] > > kvm_para.h | 33 + > > 1 file changed, 33 insertions(+) > > > > [diff] > > Can we make this more generic (naming) and location. I believe there > is some interesting in using the same ABI on the Freescale HV so it > seems like have the wrappers be a bit more generic saves us. Agreed. Maybe something like epapr_hcalls.h . -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Aug 22, 2008, at 4:17 AM, Kumar Gala wrote: On Aug 22, 2008, at 3:08 AM, Christian Ehrhardt wrote: Scott Wood wrote: On Thu, Aug 21, 2008 at 09:21:39AM -0500, Kumar Gala wrote: Where is the other discussion? I'd like to understand what's going on here.. (especially since I added the wrtee[i] changes to kernel way back when). Presumably, they want to be able to replace wrtee with a store to a hypervisor/guest shared memory area, and there's no store-immediate instruction. -Scott Exactly Scott And for your question Kumar, in the last submission I was asked to split host and guest patches. So the host discussion lives on [EMAIL PROTECTED] as I mentioned (maybe a bit too hidden) in the [0/4] mail of this series. Maybe I'm missing something but it seems like just changing the code to wrtee isn't the best way to ensure you have enough space to put the set of instructions you guys want. Sorry, I have not really been following this, I assume you are replacing SPR accesses with load/stores that do not trap. I believe thats fine for reading any SPR, but not true for modifying some SPRs, particularly MSR. IMHO you must trap on any instruction that modifies the MSR. So you should prolly not rewrite mtmsr or wrtee* but let them trap. BTW: actually moving problem SPRs (like MSRs) to a read only page makes decoding far more efficient, but it does burn another TLB entry. -JX - k -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add a simple 405EP based board
On Thursday 21 August 2008, Josh Boyer wrote: > I can understand why, as they are really two different platforms. So > logically it makes sense to have them separate. Ok, fair enough. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc: Board support for GE Fanuc SBC610
On Fri, 22 Aug 2008 12:11:52 +0100
Martyn Welch <[EMAIL PROTECTED]> wrote:
> On Fri, 22 Aug 2008 05:56:53 -0500
> Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> > >
> > > + PowerPC,[EMAIL PROTECTED] {
> > > + device_type = "cpu";
> > > + reg = <0x>;
> > > + d-cache-line-size = <32>; // 32 bytes
> > > + i-cache-line-size = <32>; // 32 bytes
> > > + d-cache-size = <32768>; // L1, 32K
> > > + i-cache-size = <32768>; // L1, 32K
> > > + timebase-frequency = <0>; // From uboot
> > > + bus-frequency = <0>;// From uboot
> > > + clock-frequency = <0>; // From uboot
> > > + l2cr = <0x8000>;// Enable L2
> >
> > do you expect the 'l2cr' prop to do anything? Not sure if this is
> > something apple invented or you did?
> >
>
> TBH, it was in the dts file that I based this on - I thought it was in the
> others as well - my mistake, I shall remove it.
>
> >
> > >
> > > + i2c1: [EMAIL PROTECTED] {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + device_type = "i2c";
> >
> > drop device_type.
> >
>
> Ah - _all_ device_type!
>
Um, not all - just the ones where the name of the block matches the device
type(?)
Martyn
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 729849476
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc: Board support for GE Fanuc SBC610
On Fri, 22 Aug 2008 05:56:53 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
> >
> > + PowerPC,[EMAIL PROTECTED] {
> > + device_type = "cpu";
> > + reg = <0x>;
> > + d-cache-line-size = <32>; // 32 bytes
> > + i-cache-line-size = <32>; // 32 bytes
> > + d-cache-size = <32768>; // L1, 32K
> > + i-cache-size = <32768>; // L1, 32K
> > + timebase-frequency = <0>; // From uboot
> > + bus-frequency = <0>;// From uboot
> > + clock-frequency = <0>; // From uboot
> > + l2cr = <0x8000>;// Enable L2
>
> do you expect the 'l2cr' prop to do anything? Not sure if this is
> something apple invented or you did?
>
TBH, it was in the dts file that I based this on - I thought it was in the
others as well - my mistake, I shall remove it.
>
> >
> > + i2c1: [EMAIL PROTECTED] {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "i2c";
>
> drop device_type.
>
Ah - _all_ device_type!
> >
> > + };
> > + };
> > +
> > + enet0: [EMAIL PROTECTED] {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
> there is no need for #add/size cells here.
>
Will remove.
> >
> > + device_type = "network";
> > + model = "eTSEC";
> > + compatible = "gianfar";
> > + reg = <0x00024000 0x1000>;
> > + mac-address = [ 00 00 00 00 00 00 ]; // set by u-boot
> > + interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>;
> > + interrupt-parent = <&mpic>;
> > + phy-handle = <&phy0>;
> > + phy-connection-type = "gmii";
> > + };
> > +
> > + enet1: [EMAIL PROTECTED] {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
> there is no need for #add/size cells here.
>
ditto.
> >
> > + device_type = "network";
> > + model = "eTSEC";
> > + compatible = "gianfar";
> > + reg = <0x00026000 0x1000>;
> > + mac-address = [ 00 00 00 00 00 00 ]; // set by u-boot
> > + interrupts = <0x1f 0x2 0x20 0x2 0x21 0x2>;
> > + interrupt-parent = <&mpic>;
> > + phy-handle = <&phy2>;
> > + phy-connection-type = "gmii";
> > + };
> > +
>
> You may want to add in msi interrupts for PCIe support (see
> mpc8572ds.dtb)
>
Interrupts are routed on this board - just via a custom interrupt controller.
I have a patch to add this, but I was getting the basics right first...
> > +
> > + mpic: [EMAIL PROTECTED] {
> > + clock-frequency = <0>;
> > + interrupt-controller;
> > + #address-cells = <0>;
> > + #interrupt-cells = <2>;
> > + reg = <0x0004 0x0004>;
> > + compatible = "chrp,open-pic";
> > + device_type = "open-pic";
> > + };
> > +
> > + [EMAIL PROTECTED] {
> > + compatible = "fsl,mpc8641-guts";
> > + reg = <0x000e 0x1000>;
> > + fsl,has-rstcr;
> > + };
> > + };
> > +
> > + pci0: [EMAIL PROTECTED] {
> > + compatible = "fsl,mpc8641-pcie";
> > + device_type = "pci";
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + reg = <0xfef08000 0x1000>;
> > + bus-range = <0x0 0xff>;
> > + ranges = <0x0200 0x0 0x8000 0x8000 0x0 0x4000
> > + 0x0100 0x0 0x 0xfe00 0x0 0x0040>;
> > + clock-frequency = <>;
> > + interrupt-parent = <&mpic>;
> > + interrupts = <0x18 0x2>;
> > + interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> > + interrupt-map = <
> > + 0x 0x0 0x0 0x1 &mpic 0x0 0x1
> > + 0x 0x0 0x0 0x2 &mpic 0x1 0x1
> > + 0x 0x0 0x0 0x3 &mpic 0x2 0x1
> > + 0x 0x0 0x0 0x4 &mpic 0x3 0x1
> > + >;
> > +
> > + [EMAIL PROTECTED] {
> > + reg = <0 0 0 0 0>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + device_type = "pci";
> > + ranges = <0x0200 0x0 0x8000
> > + 0x0200 0x0 0x8000
> > + 0x0 0x4000
> > +
> > + 0x0100 0x0 0x
Re: [PATCH 0/3]: Sparc OF I2C support.
From: Josh Boyer <[EMAIL PROTECTED]> Date: Fri, 22 Aug 2008 06:50:48 -0400 > On Thu, 21 Aug 2008 20:53:05 -0700 (PDT) > David Miller <[EMAIL PROTECTED]> wrote: > > > From: Josh Boyer <[EMAIL PROTECTED]> > > Date: Thu, 21 Aug 2008 21:15:37 -0400 > > > > > Huge? I'd say mistake, but not necessarily huge. I mean nobody other > > > than you (at least in the context of this conversation) had access to > > > the IEEE1275 proposed binding so it wasn't like there was tons to go on. > > > > I guess all the PowerMAC G5 systems out there and their device trees > > were locked up in a highly secure vault somewhere :-) > > Apple has done silly things in their device trees before. I wouldn't > hold them up as an excellent example. Sure, I agree, and Sun has too. But it's always a good idea to go look thoroughly at what existing systems are doing before pulling the switch and inventing one's own OF binding from scratch. Right? > I have no idea who to contact. Simply ask :-) I listen on here too and if I had seen such a query I would have tossed some feelers around tothe people I know. I know various OF ninjas at Sun :) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 2/2] powerpc: Default configuration for GE Fanuc SBC610
Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC MPC8641D). This is the default config file for GE Fanuc's SBC610, a 6U single board computer, based on Freescale's MPC8641D. Signed-off-by: Martyn Welch <[EMAIL PROTECTED]> --- arch/powerpc/configs/gef_sbc610_defconfig | 1654 + 1 files changed, 1654 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/gef_sbc610_defconfig b/arch/powerpc/configs/gef_sbc610_defconfig new file mode 100644 index 000..f589489 --- /dev/null +++ b/arch/powerpc/configs/gef_sbc610_defconfig @@ -0,0 +1,1654 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.26-rc5 +# Wed Jun 11 12:06:53 2008 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_PPC_FPU=y +CONFIG_ALTIVEC=y +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +CONFIG_SMP=y +CONFIG_NR_CPUS=2 +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set +CONFIG_IRQ_PER_CPU=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_GENERIC_LOCKBREAK=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +CONFIG_PPC_UDBG_16550=y +CONFIG_GENERIC_TBSYNC=y +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +CONFIG_DEFAULT_UIMAGE=y +# CONFIG_PPC_DCR_NATIVE is not set +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +CONFIG_RELAY=y +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_SYSCTL_SYSCALL_CHECK=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_COMPAT_BRK=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +# CONFIG_HAVE_DMA_ATTRS is not set +CONFIG_PROC_PAGE_MONITOR=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y +CONFIG_STOP_MACHINE=y +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +# CONFIG_DEFAULT_AS is not set +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_CFQ=y +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="cfq" +CONFIG_CLASSIC_RCU=y + +# +# Platform support +# +# CONFIG_PPC_MULTIPLATFORM is not set +# CONFIG_PPC_82xx is not set +# CONFIG_PPC_83xx is not set +CONFIG_PPC_86xx=y +# CONFIG_PPC_MPC512x is not set +# CONFIG_PPC_MPC5121 is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +# CONFIG_MPC8641_HPCN is not set +# CONFIG_SBC8641D is not set +# CONFIG_MPC8610_HPCD is not set +CONFIG_GEF_SBC610=y +CONFIG_MPC8641=y +# CONFIG_IPIC is not set +CONFIG_MPIC=y +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_P
Re: [PATCH v2 2/2] powerpc: Default configuration for GE Fanuc SBC610
On Fri, 22 Aug 2008 05:57:51 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote: > > On Aug 22, 2008, at 5:46 AM, Martyn Welch wrote: > > > Support for the SBC610 VPX Single Board Computer from GE Fanuc > > (PowerPC > > MPC8641D). > > > > This is the default config file for GE Fanuc's SBC610, a 6U single > > board > > computer, based on Freescale's MPC8641D. > > > > Signed-off-by: Martyn Welch <[EMAIL PROTECTED]> > > --- > > > > arch/powerpc/configs/gef_sbc610_defconfig | 1654 > > + > > 1 files changed, 1654 insertions(+), 0 deletions(-) > > Do you mind putting this under configs/86xx/gef_sbc610_defconfig (I > know it 86xx/ doesn't exist but we are getting enough boards there to > make it useful). > Will do. > - k -- Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748 GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square, Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 729849476 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc: Default configuration for GE Fanuc SBC610
On Aug 22, 2008, at 5:46 AM, Martyn Welch wrote: Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC MPC8641D). This is the default config file for GE Fanuc's SBC610, a 6U single board computer, based on Freescale's MPC8641D. Signed-off-by: Martyn Welch <[EMAIL PROTECTED]> --- arch/powerpc/configs/gef_sbc610_defconfig | 1654 + 1 files changed, 1654 insertions(+), 0 deletions(-) Do you mind putting this under configs/86xx/gef_sbc610_defconfig (I know it 86xx/ doesn't exist but we are getting enough boards there to make it useful). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc: Board support for GE Fanuc SBC610
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0x>;
+ d-cache-line-size = <32>; // 32 bytes
+ i-cache-line-size = <32>; // 32 bytes
+ d-cache-size = <32768>; // L1, 32K
+ i-cache-size = <32768>; // L1, 32K
+ timebase-frequency = <0>; // From uboot
+ bus-frequency = <0>; // From uboot
+ clock-frequency = <0>;// From uboot
+ l2cr = <0x8000>; // Enable L2
do you expect the 'l2cr' prop to do anything? Not sure if this is
something apple invented or you did?
+ i2c1: [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "i2c";
drop device_type.
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x0100>;
+ interrupts = <0x2b 0x2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+
+ [EMAIL PROTECTED] {
+ compatible = "dallas,ds1682";
+ reg = <0x006b>;
+ };
+ };
+
+ i2c2: [EMAIL PROTECTED] {
I recommend having #addr/#size cells here.
+ device_type = "i2c";
ditto
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x0100>;
+ interrupts = <0x2b 0x2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
drop device_type, (see a theme here ;)
+ compatible = "fsl,gianfar-mdio";
+ reg = <0x00024520 0x0020>;
+
+ phy0: [EMAIL PROTECTED] {
+ interrupt-parent = <&mpic>;
+ interrupts = <0x0 0x1>;
+ reg = <0x0001>;
+ device_type = "ethernet-phy";
drop device_type.
+ };
+ phy2: [EMAIL PROTECTED] {
+ interrupt-parent = <&mpic>;
+ interrupts = <0x0 0x1>;
+ reg = <0x0003>;
+ device_type = "ethernet-phy";
ditto
+ };
+ };
+
+ enet0: [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
there is no need for #add/size cells here.
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x00024000 0x1000>;
+ mac-address = [ 00 00 00 00 00 00 ]; // set by u-boot
+ interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "gmii";
+ };
+
+ enet1: [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
there is no need for #add/size cells here.
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x00026000 0x1000>;
+ mac-address = [ 00 00 00 00 00 00 ]; // set by u-boot
+ interrupts = <0x1f 0x2 0x20 0x2 0x21 0x2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy2>;
+ phy-connection-type = "gmii";
+ };
+
You may want to add in msi interrupts for PCIe support (see
mpc8572ds.dtb)
+
+ mpic: [EMAIL PROTECTED] {
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x0004 0x0004>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8641-guts";
+ reg = <0x000e 0x1000>;
+ fsl,has-rstcr;
+ };
+ };
+
+ pci0: [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8
Re: [PATCH 0/3]: Sparc OF I2C support.
On Thu, 21 Aug 2008 20:53:05 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: Josh Boyer <[EMAIL PROTECTED]> > Date: Thu, 21 Aug 2008 21:15:37 -0400 > > > Huge? I'd say mistake, but not necessarily huge. I mean nobody other > > than you (at least in the context of this conversation) had access to > > the IEEE1275 proposed binding so it wasn't like there was tons to go on. > > I guess all the PowerMAC G5 systems out there and their device trees > were locked up in a highly secure vault somewhere :-) Apple has done silly things in their device trees before. I wouldn't hold them up as an excellent example. > > Have patience with the embedded people that are both new to > > OpenFirmware and trying to make stuff work at the same time. I > > think the devicetree-discuss list will help here as new bindings are > > proposed. I hope you're subscribed. > > Why not ask the people who actually work on the standards? That's who > I go to when I want to know something about openfirmware issues. Honestly, I don't know. And from what I can tell, there _aren't_ people who actively work on the standards anymore. Mitch is active elsewhere and could be a great resource but aside from him I have no idea who to contact. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 1/2] powerpc: Board support for GE Fanuc SBC610
Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the basic board support for GE Fanuc's SBC610, a 6U single board
computer, based on Freescale's MPC8641D.
Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/gef_sbc610.dts | 268 ++
arch/powerpc/platforms/86xx/Kconfig |9 +
arch/powerpc/platforms/86xx/Makefile |1
arch/powerpc/platforms/86xx/gef_sbc610.c | 177
4 files changed, 454 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts
b/arch/powerpc/boot/dts/gef_sbc610.dts
new file mode 100644
index 000..598deda
--- /dev/null
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -0,0 +1,268 @@
+/*
+ * GE Fanuc SBC610 Device Tree Source
+ *
+ * Copyright 2008 GE Fanuc Intelligent Platforms Embedded Systems, 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; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * Based on: SBS CM6 Device Tree Source
+ * Copyright 2007 SBS Technologies GmbH & Co. KG
+ * And: mpc8641_hpcn.dts (MPC8641 HPCN Device Tree Source)
+ * Copyright 2006 Freescale Semiconductor Inc.
+ */
+
+/*
+ * Compiled with dtc -I dts -O dtb -o gef_sbc610.dtb gef_sbc610.dts
+ */
+
+/dts-v1/;
+
+/ {
+ model = "GEF_SBC610";
+ compatible = "gef,sbc610";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0x>;
+ d-cache-line-size = <32>; // 32 bytes
+ i-cache-line-size = <32>; // 32 bytes
+ d-cache-size = <32768>; // L1, 32K
+ i-cache-size = <32768>; // L1, 32K
+ timebase-frequency = <0>; // From uboot
+ bus-frequency = <0>;// From uboot
+ clock-frequency = <0>; // From uboot
+ l2cr = <0x8000>;// Enable L2
+ };
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0x0001>;
+ d-cache-line-size = <32>; // 32 bytes
+ i-cache-line-size = <32>; // 32 bytes
+ d-cache-size = <32768>; // L1, 32K
+ i-cache-size = <32768>; // L1, 32K
+ timebase-frequency = <0>; // From uboot
+ bus-frequency = <0>;// From uboot
+ clock-frequency = <0>; // From uboot
+ l2cr = <0x8000>;// Enable L2
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x4000>; // set by u-boot
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "soc";
+ ranges = <0x 0xfef0 0x0010>;
+ reg = <0xfef0 0x0010>; // CCSRBAR 1M
+ bus-frequency = <0>;
+
+ i2c1: [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x0100>;
+ interrupts = <0x2b 0x2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+
+ [EMAIL PROTECTED] {
+ compatible = "dallas,ds1682";
+ reg = <0x006b>;
+ };
+ };
+
+ i2c2: [EMAIL PROTECTED] {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x0100>;
+ interrupts = <0x2b 0x2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8641-dma", "fsl,eloplus-dma";
+ reg = <0x21300 0x4>;
+
[PATCH v2 0/2] powerpc: Board support for GE Fanuc SBC610
The following series implements basic board support for GE Fanuc's SBC610, a 6U single board computer, based on Freescale's MPC8641D. This series provides basic functionality: - The board can boot with a serial console. - Ethernet works, though the phys are polled. - The PCI bus is scanned and sata functions. Signed-off-by: Martyn Welch <[EMAIL PROTECTED]> --- Kumar, Jon & Scott: Thank you for your comments, I hope this revision resolves the issues you highlighted. Martyn Martyn Welch (2): powerpc: Default configuration for GE Fanuc SBC610 powerpc: Board support for GE Fanuc SBC610 arch/powerpc/boot/dts/gef_sbc610.dts | 268 + arch/powerpc/configs/gef_sbc610_defconfig | 1654 + arch/powerpc/platforms/86xx/Kconfig |9 arch/powerpc/platforms/86xx/Makefile |1 arch/powerpc/platforms/86xx/gef_sbc610.c | 187 +++ 5 files changed, 2118 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/boot/dts/gef_sbc610.dts create mode 100644 arch/powerpc/configs/gef_sbc610_defconfig create mode 100644 arch/powerpc/platforms/86xx/gef_sbc610.c ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] kvmppc: add hypercall infrastructure - guest part
On Aug 19, 2008, at 5:36 AM, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt <[EMAIL PROTECTED]> This adds the guest portion of the hypercall infrastructure, basically an illegal instruction with a defined layout. See http://kvm.qumranet.com/kvmwiki/PowerPC_Hypercall_ABI for more detail on the hypercall ABI for powerpc. Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> --- [diffstat] kvm_para.h | 33 + 1 file changed, 33 insertions(+) [diff] Can we make this more generic (naming) and location. I believe there is some interesting in using the same ABI on the Freescale HV so it seems like have the wrappers be a bit more generic saves us. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2][V3] powerpc: add support for dynamic reconfiguration memory in kexec/kdump kernels
Pls let me know the status of this patch.
Thanks,
Chandru
On Thursday 14 August 2008 15:17:32 Chandru wrote:
> kdump kernel needs to use only those memory regions that it is allowed to use
> (crashkernel, rtas, tce ..etc ). Each of these regions have their own sizes
> and are currently added under 'linux,usable-memory' property under each
> memory@ node of the device tree. ibm,dynamic-memory property of
> ibm,dynamic-reconfiguration-memory node now stores in it the representation
> for most of the logical memory blocks with the size of each memory block
> being a constant (lmb_size). If one or more or part of the above mentioned
> regions lie under one of the lmb from ibm,dynamic-memory property, there is a
> need to identify those regions within the given lmb. Following patch
> recognizes a new property 'linux,drconf-usable-memory' property added by
> kexec-tools. Each entry in this property is of the form 'a counter' followed
> by those many (base, size) duple for the above mentioned regions.
>
> Signed-off-by: Chandru Siddalingappa <[EMAIL PROTECTED]>
> ---
>
> These patches were sent earlier but these are V3 of the patches. Pls let me
> know your thoughts. Thanks.
>
> arch/powerpc/kernel/prom.c | 40 +++--
> arch/powerpc/mm/numa.c | 79 +++
> 2 files changed, 96 insertions(+), 23 deletions(-)
>
> diff -Naurp powerpc-orig/arch/powerpc/kernel/prom.c
> powerpc/arch/powerpc/kernel/prom.c
> --- powerpc-orig/arch/powerpc/kernel/prom.c 2008-08-14 08:23:25.0
> +0530
> +++ powerpc/arch/powerpc/kernel/prom.c2008-08-14 14:35:24.0
> +0530
> @@ -888,9 +888,10 @@ static u64 __init dt_mem_next_cell(int s
> */
> static int __init early_init_dt_scan_drconf_memory(unsigned long node)
> {
> - cell_t *dm, *ls;
> + cell_t *dm, *ls, *usm;
> unsigned long l, n, flags;
> u64 base, size, lmb_size;
> + unsigned int is_kexec_kdump = 0, rngs;
>
> ls = (cell_t *)of_get_flat_dt_prop(node, "ibm,lmb-size", &l);
> if (ls == NULL || l < dt_root_size_cells * sizeof(cell_t))
> @@ -905,6 +906,12 @@ static int __init early_init_dt_scan_drc
> if (l < (n * (dt_root_addr_cells + 4) + 1) * sizeof(cell_t))
> return 0;
>
> + /* check if this is a kexec/kdump kernel. */
> + usm = (cell_t *)of_get_flat_dt_prop(node, "linux,drconf-usable-memory",
> + &l);
> + if (usm != NULL)
> + is_kexec_kdump = 1;
> +
> for (; n != 0; --n) {
> base = dt_mem_next_cell(dt_root_addr_cells, &dm);
> flags = dm[3];
> @@ -915,13 +922,34 @@ static int __init early_init_dt_scan_drc
> if ((flags & 0x80) || !(flags & 0x8))
> continue;
> size = lmb_size;
> - if (iommu_is_off) {
> - if (base >= 0x8000ul)
> + rngs = 1;
> + if (is_kexec_kdump) {
> + /*
> + * For each lmb in ibm,dynamic-memory, a corresponding
> + * entry in linux,drconf-usable-memory property contains
> + * a counter 'p' followed by 'p' (base, size) duple.
> + * Now read the counter from
> + * linux,drconf-usable-memory property
> + */
> + rngs = dt_mem_next_cell(dt_root_size_cells, &usm);
> + if (!rngs) /* there are no (base, size) duple */
> continue;
> - if ((base + size) > 0x8000ul)
> - size = 0x8000ul - base;
> }
> - lmb_add(base, size);
> + do {
> + if (is_kexec_kdump) {
> + base = dt_mem_next_cell(dt_root_addr_cells,
> + &usm);
> + size = dt_mem_next_cell(dt_root_size_cells,
> + &usm);
> + }
> + if (iommu_is_off) {
> + if (base >= 0x8000ul)
> + continue;
> + if ((base + size) > 0x8000ul)
> + size = 0x8000ul - base;
> + }
> + lmb_add(base, size);
> + } while (--rngs);
> }
> lmb_dump_all();
> return 0;
> diff -Naurp powerpc-orig/arch/powerpc/mm/numa.c powerpc/arch/powerpc/mm/numa.c
> --- powerpc-orig/arch/powerpc/mm/numa.c 2008-08-14 08:23:25.0
> +0530
> +++ powerpc/arch/powerpc/mm/numa.c2008-08-14 14:35:42.0 +0530
> @@ -150,6 +150,21 @@ static const int *of_get_associativity(s
> return of_get_property(dev, "ibm,associativity", NULL);
> }
>
> +/*
> + * Returns the proper
Re: [PATCH 3/3]: of_i2c: Add Sparc support.
From: David Miller <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 21:21:45 -0700 (PDT)
> of_i2c: Add Sparc support.
>
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Of course, after testing, I noticed that I forgot the all
important shifts here. :-)
Here is a fixed patch:
of_i2c: Add Sparc support.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/arch/sparc/include/asm/of_i2c.h b/arch/sparc/include/asm/of_i2c.h
new file mode 100644
index 000..0fdab1e
--- /dev/null
+++ b/arch/sparc/include/asm/of_i2c.h
@@ -0,0 +1,67 @@
+#ifndef _ASM_SPARC_OF_I2C_H
+#define _ASM_SPARC_OF_I2C_H
+
+/* In my copy of the I2C bindings for IEEE1275 the register value is
+ * encoded as a 2-cell value:
+ *
+ * Bit #3322 1100
+ * 10987654 32109876 54321098 76543210
+ *
+ * bus:
+ * address: 0sss sss0
+ *
+ * where:
+ * 8-bit unsigned number representing
+ * the I2C bus address within this I2C bus
+ * controller node
+ * ss 10-bit unsigned number representing the
+ * slave address
+ *
+ * When doing I2C transfers to a device the low bit of the address
+ * indicates whether the transfer is a read or a write, and the upper
+ * bits indicate the device address.
+ *
+ * The Linux I2C layer wants device addresses which elide this
+ * direction bit. Thus we should shift the OF provided reg property
+ * address down by one bit.
+ */
+static inline int of_i2c_fetch_addr(struct i2c_board_info *bp,
+ struct device_node *client_node,
+ struct device_node *adap_node,
+ int num_addr_cells)
+{
+ const u32 *addr;
+ int len;
+
+ addr = of_get_property(client_node, "reg", &len);
+ if (!addr)
+ goto out_inval;
+
+ if (len < (num_addr_cells * sizeof(int)))
+ goto out_inval;
+
+ if (addr[num_addr_cells - 1] > (1 << 10) - 1)
+ goto out_inval;
+
+ switch (num_addr_cells) {
+ case 1:
+ bp->addr = addr[0] >> 1;
+ break;
+
+ case 2:
+ /* XXX cell 0 contains bus number XXX */
+ bp->addr = addr[1] >> 1;
+ break;
+
+ default:
+ goto out_inval;
+ }
+
+ return 0;
+
+out_inval:
+ printk(KERN_ERR "of-i2c: invalid i2c device entry\n");
+ return -EINVAL;
+}
+
+#endif /* _ASM_SPARC_OF_I2C_H */
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index f821dbc..493c717 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -10,7 +10,7 @@ config OF_GPIO
config OF_I2C
def_tristate I2C
- depends on PPC_OF && I2C
+ depends on I2C
help
OpenFirmware I2C accessors
--
1.5.6.5.GIT
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] New Patchwork beta
On Aug 22, 2008, at 3:55 AM, Jeremy Kerr wrote: Hi Kumar, [trimming CC list] Now that I can log in, can I get "maintainer" privileges (user: galak) Yep, you should already have maintainer privs for linuxppc-dev also is it possible to put the patch controls in a separate frame so they are always visible (dont have to scoll to the bottom to find them). I'm trying to avoid using frames; it makes it hard to link to individual pages, and makes patch updating much more complex. However, there shouldn't be a need for too much scrolling now - to prevent patch lists from growing too long, the results are paginated into groups of 100 patches. Also, when there are more than about 30 patches on a page, you'll get a small link on the left-hand side to scroll straight to the form area. Is this OK? probably, will need to see when we get more patches how this actually looks. I know it was a big annoyance w/v1. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Initrd
Hello, I am using linux 2.6.26 on a powerpc board. I would like to use a initrd. So I set the initrd option in the kernel. But when I boot Linux, it crashes before start_kernel(). And after the configuration of the MMU. The last words of the prompt are : Probing machine type ... MPC7448 on IAD68 ... match ! id mach(): done MMU:enter MMU:hw init hash:enter hash:find piece hash:patch hash:done MMU:mapin MMU:setio MMU:exi Can you help me ? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [machdep_calls] IRQ
Ok thank you, I will begin to implement the irq functions 2008/8/22, Michael Ellerman <[EMAIL PROTECTED]>: > > On Thu, 2008-08-21 at 10:23 +0200, Sébastien Chrétien wrote: > > Exactly, I mean ppc_md.init_IRQ(). > > > Ok. What have I to setup in this function ? I set the mask and other > > registers. Is it right ? How do I chose the mask ? > > > It totally depends on your platform, I really can't tell you. You can > look at similar platform code if there is some, otherwise the reference > manual for your hardware or similar should have what you need. > > > > At the end of this funtion, IRQ are disable. Is that right ? So who > > does enable IRQs ? > > > Yes, irqs get enabled a bit later in start_kernel(). > > > cheers > > -- > Michael Ellerman > OzLabs, IBM Australia Development Lab > > wwweb: http://michael.ellerman.id.au > phone: +61 2 6212 1183 (tie line 70 21183) > > We do not inherit the earth from our ancestors, > we borrow it from our children. - S.M.A.R.T Person > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] New Patchwork beta
Hi Kumar, [trimming CC list] > Now that I can log in, can I get "maintainer" privileges (user: > galak) Yep, you should already have maintainer privs for linuxppc-dev > also is it possible to put the patch controls in a separate frame so > they are always visible (dont have to scoll to the bottom to find > them). I'm trying to avoid using frames; it makes it hard to link to individual pages, and makes patch updating much more complex. However, there shouldn't be a need for too much scrolling now - to prevent patch lists from growing too long, the results are paginated into groups of 100 patches. Also, when there are more than about 30 patches on a page, you'll get a small link on the left-hand side to scroll straight to the form area. Is this OK? Cheers, Jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ppc4xx_pci: necessary fixes for 4GB RAM size
1. total_memory should be phys_addr_t not unsigned long
2. is_power_of_2() works with u32 so I just inlined (size & (size-1)) != 0
instead.
Also this patch fixes default initialization: res->end should be 0x7fff
not 0x8000.
Signed-off-by: Ilya Yanok <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index e1c7df9..645b2c9 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -36,7 +36,7 @@
static int dma_offset_set;
/* Move that to a useable header */
-extern unsigned long total_memory;
+extern phys_addr_t total_memory;
#define U64_TO_U32_LOW(val)((u32)((val) & 0xULL))
#define U64_TO_U32_HIGH(val) ((u32)((val) >> 32))
@@ -105,7 +105,8 @@ static int __init ppc4xx_parse_dma_ranges(struct
pci_controller *hose,
/* Default */
res->start = 0;
- res->end = size = 0x8000;
+ size = 0x8000;
+ res->end = size - 1;
res->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
/* Get dma-ranges property */
@@ -167,13 +168,13 @@ static int __init ppc4xx_parse_dma_ranges(struct
pci_controller *hose,
*/
if (size < total_memory) {
printk(KERN_ERR "%s: dma-ranges too small "
- "(size=%llx total_memory=%lx)\n",
- hose->dn->full_name, size, total_memory);
+ "(size=%llx total_memory=%llx)\n",
+ hose->dn->full_name, size, (u64)total_memory);
return -ENXIO;
}
/* Check we are a power of 2 size and that base is a multiple of size*/
- if (!is_power_of_2(size) ||
+ if ((size & (size - 1)) != 0 ||
(res->start & (size - 1)) != 0) {
printk(KERN_ERR "%s: dma-ranges unaligned\n",
hose->dn->full_name);
--
1.5.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: disable modules and get "multiple definition" errors?
On Thu, 21 Aug 2008, Kevin Diggs wrote:
> I am trying to do some compile testing of my cpufreq driver. If
> I disable modules I am getting multiple definition errors of inline
> functions:
>
> inline volatile unsigned int get_PLL(void)
> {
> unsigned int ret;
>
> __asm__ __volatile__ ("mfspr %0,%1":
> "=r"(ret):
> "i"(SPRN_HID1)
> );
>
> return ret;
> }
>
> arch/powerpc/kernel/cpu/pll_if.o(.text+0x1c): In function `get_PLL':
> : multiple definition of `get_PLL'
> arch/powerpc/kernel/cpu/cpufreq/built-in.o(.text+0x0): first defined here
>
> What am I doing wrong?
You forgot to make the inline functions static?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Aug 22, 2008, at 3:08 AM, Christian Ehrhardt wrote: Scott Wood wrote: On Thu, Aug 21, 2008 at 09:21:39AM -0500, Kumar Gala wrote: Where is the other discussion? I'd like to understand what's going on here.. (especially since I added the wrtee[i] changes to kernel way back when). Presumably, they want to be able to replace wrtee with a store to a hypervisor/guest shared memory area, and there's no store-immediate instruction. -Scott Exactly Scott And for your question Kumar, in the last submission I was asked to split host and guest patches. So the host discussion lives on [EMAIL PROTECTED] as I mentioned (maybe a bit too hidden) in the [0/4] mail of this series. Maybe I'm missing something but it seems like just changing the code to wrtee isn't the best way to ensure you have enough space to put the set of instructions you guys want. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: New Patchwork beta
On Aug 21, 2008, at 5:52 PM, Josh Boyer wrote: On Thu, 2008-08-21 at 15:32 -0500, Kumar Gala wrote: Some feedback: * Can we increase the font size a bit? NOO. Just use CTRL-SHIFT-+. ok * For the list of patches can we change the background of every other line (light gray) That would work well. thanks this looks better, easier to read. * Parsing subject header for determining state -- "[RFC]" That is going to fail miserably because people tend to do silly things like post final patches in the middle of an [RFC] thread. gotcha. Now that I can log in, can I get "maintainer" privileges (user: galak) also is it possible to put the patch controls in a separate frame so they are always visible (dont have to scoll to the bottom to find them). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
Scott Wood wrote: On Thu, Aug 21, 2008 at 09:21:39AM -0500, Kumar Gala wrote: Where is the other discussion? I'd like to understand what's going on here.. (especially since I added the wrtee[i] changes to kernel way back when). Presumably, they want to be able to replace wrtee with a store to a hypervisor/guest shared memory area, and there's no store-immediate instruction. -Scott Exactly Scott And for your question Kumar, in the last submission I was asked to split host and guest patches. So the host discussion lives on [EMAIL PROTECTED] as I mentioned (maybe a bit too hidden) in the [0/4] mail of this series. -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
