Re: [machdep_calls] IRQ
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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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 . ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: new copy_4K_page()
This new copy_4K_page() function was originally tuned for the best performance on the Cell processor, but after testing on more 64bit powerpc chips it was found that with a small modification it either matched the performance offered by the current mainline version or bettered it by a small amount. It was found that on a Cell-based QS22 blade the amount of system time measured when compiling a 2.6.26 pseries_defconfig decreased by 4%. Using the same test, a 4-way 970MP machine saw a decrease of 2% in system time. No noticeable change was seen on Power4, Power5 or Power6. The 4096 byte page is copied in thirty-two 128 byte strides. An initial setup loop executes dcbt instructions for the whole source page and dcbz instructions for the whole destination page. To do this, the cache line size is retrieved from ppc64_caches. A new CPU feature bit, CPU_FTR_CP_USE_DCBTZ, (introduced in the previous patch) is used to make the modification to this new copy routine - on Power4, 970 and Cell the feature bit is set so the setup loop is executed, but on all other 64bit chips the setup loop is nop'ed out. Signed-off-by: Mark Nelson <[EMAIL PROTECTED]> --- arch/powerpc/lib/copypage_64.S | 198 +++-- 1 file changed, 93 insertions(+), 105 deletions(-) Index: upstream/arch/powerpc/lib/copypage_64.S === --- upstream.orig/arch/powerpc/lib/copypage_64.S +++ upstream/arch/powerpc/lib/copypage_64.S @@ -1,5 +1,5 @@ /* - * Copyright (C) 2002 Paul Mackerras, IBM Corp. + * Copyright (C) 2008 Mark Nelson, IBM Corp. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -8,112 +8,100 @@ */ #include #include +#include + +.section".toc","aw" +PPC64_CACHES: +.tc ppc64_caches[TC],ppc64_caches +.section".text" + _GLOBAL(copy_4K_page) - std r31,-8(1) - std r30,-16(1) - std r29,-24(1) - std r28,-32(1) - std r27,-40(1) - std r26,-48(1) - std r25,-56(1) - std r24,-64(1) - std r23,-72(1) - std r22,-80(1) - std r21,-88(1) - std r20,-96(1) - li r5,4096/32 - 1 + li r5,4096 /* 4K page size */ +BEGIN_FTR_SECTION + ld r10,[EMAIL PROTECTED](r2) + lwz r11,DCACHEL1LOGLINESIZE(r10)/* log2 of cache line size */ + lwz r12,DCACHEL1LINESIZE(r10) /* get cache line size */ + li r9,0 + srd r8,r5,r11 + + mtctr r8 +setup: + dcbtr9,r4 + dcbzr9,r3 + add r9,r9,r12 + bdnzsetup +END_FTR_SECTION_IFSET(CPU_FTR_CP_USE_DCBTZ) addir3,r3,-8 - li r12,5 -0: addir5,r5,-24 - mtctr r12 - ld r22,640(4) - ld r21,512(4) - ld r20,384(4) - ld r11,256(4) - ld r9,128(4) - ld r7,0(4) - ld r25,648(4) - ld r24,520(4) - ld r23,392(4) - ld r10,264(4) - ld r8,136(4) - ldu r6,8(4) - cmpwi r5,24 -1: std r22,648(3) - std r21,520(3) - std r20,392(3) - std r11,264(3) - std r9,136(3) - std r7,8(3) - ld r28,648(4) - ld r27,520(4) - ld r26,392(4) - ld r31,264(4) - ld r30,136(4) - ld r29,8(4) - std r25,656(3) - std r24,528(3) - std r23,400(3) - std r10,272(3) - std r8,144(3) - std r6,16(3) - ld r22,656(4) - ld r21,528(4) - ld r20,400(4) - ld r11,272(4) - ld r9,144(4) - ld r7,16(4) - std r28,664(3) - std r27,536(3) - std r26,408(3) - std r31,280(3) - std r30,152(3) - stdur29,24(3) - ld r25,664(4) - ld r24,536(4) - ld r23,408(4) - ld r10,280(4) - ld r8,152(4) - ldu r6,24(4) + srdir8,r5,7 /* page is copied in 128 byte strides */ + addir8,r8,-1/* one stride copied outside loop */ + + mtctr r8 + + ld r5,0(r4) + ld r6,8(r4) + ld r7,16(r4) + ldu r8,24(r4) +1: std r5,8(r3) + ld r9,8(r4) + std r6,16(r3) + ld r10,16(r4) + std r7,24(r3) + ld r11,24(r4) + std r8,32(r3) + ld r12,32(r4) + std r9,40(r3) + ld r5,40(r4) + std r10,48(r3) + ld r6,48(r4) + std r11,56(r3) + ld r7,56(r4) + std r12,64(r3) + ld r8,64(r4) + std r5,72(r3) + ld r9,72(r4) + std r6,80(r3) + ld r10,80(r4) +
[PATCH 1/2] powerpc: add new CPU feature: CPU_FTR_CP_USE_DCBTZ
Add a new CPU feature bit, CPU_FTR_CP_USE_DCBTZ, to be added to the 64bit powerpc chips that benefit from having dcbt and dcbz instructions used in their memory copy routines. This will be used in a subsequent patch that updates copy_4K_page(). The new bit is added to Cell, PPC970 and Power4 because they show better performance with the new copy_4K_page() when dcbt and dcbz instructions are used. Signed-off-by: Mark Nelson <[EMAIL PROTECTED]> --- arch/powerpc/include/asm/cputable.h |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) Index: upstream/arch/powerpc/include/asm/cputable.h === --- upstream.orig/arch/powerpc/include/asm/cputable.h +++ upstream/arch/powerpc/include/asm/cputable.h @@ -192,6 +192,7 @@ extern const char *powerpc_base_platform #define CPU_FTR_NO_SLBIE_B LONG_ASM_CONST(0x0008) #define CPU_FTR_VSXLONG_ASM_CONST(0x0010) #define CPU_FTR_SAOLONG_ASM_CONST(0x0020) +#define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040) #ifndef __ASSEMBLY__ @@ -387,10 +388,11 @@ extern const char *powerpc_base_platform CPU_FTR_MMCRA | CPU_FTR_CTRL) #define CPU_FTRS_POWER4(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ - CPU_FTR_MMCRA) + CPU_FTR_MMCRA | CPU_FTR_CP_USE_DCBTZ) #define CPU_FTRS_PPC970(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ - CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA) + CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA | \ + CPU_FTR_CP_USE_DCBTZ) #define CPU_FTRS_POWER5(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ CPU_FTR_MMCRA | CPU_FTR_SMT | \ @@ -411,7 +413,8 @@ extern const char *powerpc_base_platform #define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \ - CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE | CPU_FTR_CELL_TB_BUG) + CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE | \ + CPU_FTR_CELL_TB_BUG | CPU_FTR_CP_USE_DCBTZ) #define CPU_FTRS_PA6T (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \ CPU_FTR_ALTIVEC_COMP | CPU_FTR_CI_LARGE_PAGE | \ ___ 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: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. 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
[PATCH 0/2] powerpc: new copy_4K_page()
On Thu, 14 Aug 2008 04:17:32 pm Mark Nelson wrote:
> Hi All,
>
> What follows is an updated version of copy_4K_page that has been tuned
> for the Cell processor. With this new routine it was found that the
> system time measured when compiling a 2.6.26 pseries_defconfig was
> reduced by ~10s:
>
> mainline (2.6.27-rc1-00632-g2e1e921):
>
> real17m8.727s
> user59m48.693s
> sys 3m56.089s
>
> real17m9.350s
> user59m44.822s
> sys 3m56.666s
>
> new routine:
>
> real17m7.311s
> user59m51.339s
> sys 3m47.043s
>
> real17m7.863s
> user59m49.028s
> sys 3m46.608s
>
> This same routine was also found to improve performance on 970 CPUs
> too (but by a much smaller amount):
>
> mainline (2.6.27-rc1-00632-g2e1e921):
>
> real16m8.545s
> user14m38.134s
> sys 1m55.156s
>
> real16m7.089s
> user14m37.974s
> sys 1m55.010s
>
> new routine:
>
> real16m11.641s
> user14m37.251s
> sys 1m52.618s
>
> real16m6.139s
> user14m38.282s
> sys 1m53.184s
>
>
> I also did testing on Power{3..6} and I found that Power3, Power5 and
> Power6 did better with this new routine when the dcbt and dcbz
> weren't used (in which case they achieved performance comparable to
> the existing kernel copy_4K_page routine). Power4 on other hand
> performed slightly better with the dcbt and dcbz included (still
> comparable to the current kernel copy_4K_page).
>
> So in order to get the best performance across the board I created a
> new CPU feature that will govern whether the dcbt and dcbz are used
> (and un-creatively named it CPU_FTR_CP_USE_DCBTZ). I added it to the
> CPU features of Cell, Power4 and 970.
> Unfortunately I don't have access to a PA6T but judging by the
> marketing material I could find, it looks like it has a strong enough
> hardware prefetcher that it probably wouldn't benefit from the dcbt
> and dcbz...
>
> Okay, that's probably enough prattling along - you can all go and look
> at the code now.
>
> All comments appreciated
>
> [I decided to post the whole copy routine rather than a diff between
> it and the current one because I found the diff quite unreadable. I'll post
> a real patchset after I've addressed any comments.]
>
> Many thanks!
>
The actual patches for the new copy_4K_page() follow this.
Note: I changed the order of the patches so that the new CPU feature
bit is introduced in the first patch and then the new copy_4K_page
is introduced in the second patch.
___
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: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 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 0/3]: Sparc OF I2C support.
Hi, I wrote most of 1275. Mitch Bradley ([EMAIL PROTECTED]) David Miller wrote: From: "Grant Likely" <[EMAIL PROTECTED]> Date: Thu, 21 Aug 2008 22:18:56 -0600 On Thu, Aug 21, 2008 at 9:53 PM, David Miller <[EMAIL PROTECTED]> wrote: 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. You mean email them privately? Outside of a public forum? That doesn't help much when it comes to discussing/debating issues and learning from other peoples conversations. You can CC: them on the discussion to get their input, whatever is appropriate. ___ devicetree-discuss mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/devicetree-discuss ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
From: "Grant Likely" <[EMAIL PROTECTED]> Date: Thu, 21 Aug 2008 22:18:56 -0600 > On Thu, Aug 21, 2008 at 9:53 PM, David Miller <[EMAIL PROTECTED]> wrote: > >> 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. > > You mean email them privately? Outside of a public forum? That > doesn't help much when it comes to discussing/debating issues and > learning from other peoples conversations. You can CC: them on the discussion to get their input, whatever is appropriate. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3]: of_i2c: Abstract out register property interpretation.
of_i2c: Abstract out register property interpretation.
Pull out client I2C device address calculation into a
helper function, of_i2c_fetch_addr.
At the top level we try to determine the reported
#address-cells property in the I2C bus adapter node,
and default to "1" if the property is not found.
We pass this down to of_i2c_fetch_addr() so that it does
not have to do this probe every iteration.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/of_i2c.h | 24
drivers/of/of_i2c.c | 26 --
2 files changed, 40 insertions(+), 10 deletions(-)
create mode 100644 arch/powerpc/include/asm/of_i2c.h
diff --git a/arch/powerpc/include/asm/of_i2c.h
b/arch/powerpc/include/asm/of_i2c.h
new file mode 100644
index 000..501a24b
--- /dev/null
+++ b/arch/powerpc/include/asm/of_i2c.h
@@ -0,0 +1,24 @@
+#ifndef _ASM_POWERPC_OF_I2C_H
+#define _ASM_POWERPC_OF_I2C_H
+
+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 || len < (num_addr_cells * sizeof(int)) ||
+ addr[num_addr_cells - 1] > (1 << 10) - 1) {
+ printk(KERN_ERR "of-i2c: invalid i2c device entry\n");
+ return -EINVAL;
+ }
+
+ bp->addr = addr[num_addr_cells - 1];
+
+ return 0;
+}
+
+#endif /* _ASM_POWERPC_OF_I2C_H */
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index 6a98dc8..387c74e 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -16,31 +16,37 @@
#include
#include
+#include
+
void of_register_i2c_devices(struct i2c_adapter *adap,
struct device_node *adap_node)
{
- void *result;
struct device_node *node;
+ int num_addr_cells = 1;
+ const int *n_cells;
+ void *result;
+
+ n_cells = of_get_property(adap_node, "#address-cells", NULL);
+ if (n_cells)
+ num_addr_cells = *n_cells;
+
+ if (num_addr_cells != 1 && num_addr_cells != 2) {
+ printk(KERN_ERR "of-i2c: invalid address cells %d\n",
+ num_addr_cells);
+ return;
+ }
for_each_child_of_node(adap_node, node) {
struct i2c_board_info info = {};
- const u32 *addr;
- int len;
if (of_modalias_node(node, info.type, sizeof(info.type)) < 0)
continue;
- addr = of_get_property(node, "reg", &len);
- if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
- printk(KERN_ERR
- "of-i2c: invalid i2c device entry\n");
+ if (of_i2c_fetch_addr(&info, node, adap_node, num_addr_cells))
continue;
- }
info.irq = irq_of_parse_and_map(node, 0);
- info.addr = *addr;
-
request_module(info.type);
result = i2c_new_device(adap, &info);
--
1.5.6.5.GIT
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3]: of_i2c: Add Sparc support.
of_i2c: Add Sparc support.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
arch/sparc/include/asm/of_i2c.h | 67 +++
drivers/of/Kconfig |2 +-
2 files changed, 68 insertions(+), 1 deletions(-)
create mode 100644 arch/sparc/include/asm/of_i2c.h
diff --git a/arch/sparc/include/asm/of_i2c.h b/arch/sparc/include/asm/of_i2c.h
new file mode 100644
index 000..93c7c05
--- /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];
+ break;
+
+ case 2:
+ /* XXX cell 0 contains bus number XXX */
+ bp->addr = addr[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
[PATCH 1/3]: sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
This allows more OF layer code to be shared between powerpc and
sparc.
With feedback and suggestions from Anton Vorontsov.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
arch/sparc/include/asm/prom.h | 10 ++
arch/sparc/kernel/of_device.c | 11 +++
arch/sparc64/kernel/of_device.c | 11 +++
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/sparc/include/asm/prom.h b/arch/sparc/include/asm/prom.h
index fd55522..b44e0c7 100644
--- a/arch/sparc/include/asm/prom.h
+++ b/arch/sparc/include/asm/prom.h
@@ -94,6 +94,16 @@ static inline void of_node_put(struct device_node *node)
{
}
+/* These routines are here to provide compatibility with how powerpc
+ * handles IRQ mapping for OF device nodes. We precompute and permanently
+ * register them in the of_device objects, whereas powerpc computes them
+ * on request.
+ */
+extern unsigned int irq_of_parse_and_map(struct device_node *node, int index);
+static inline void irq_dispose_mapping(unsigned int virq)
+{
+}
+
/*
* NB: This is here while we transition from using asm/prom.h
* to linux/of.h
diff --git a/arch/sparc/kernel/of_device.c b/arch/sparc/kernel/of_device.c
index cc4c235..aace71f 100644
--- a/arch/sparc/kernel/of_device.c
+++ b/arch/sparc/kernel/of_device.c
@@ -29,6 +29,17 @@ struct of_device *of_find_device_by_node(struct device_node
*dp)
}
EXPORT_SYMBOL(of_find_device_by_node);
+unsigned int irq_of_parse_and_map(struct device_node *node, int index)
+{
+ struct of_device *op = of_find_device_by_node(node);
+
+ if (!op || index >= op->num_irqs)
+ return 0;
+
+ return op->irqs[index];
+}
+EXPORT_SYMBOL(irq_of_parse_and_map);
+
#ifdef CONFIG_PCI
struct bus_type ebus_bus_type;
EXPORT_SYMBOL(ebus_bus_type);
diff --git a/arch/sparc64/kernel/of_device.c b/arch/sparc64/kernel/of_device.c
index f8b50cb..a30f2af 100644
--- a/arch/sparc64/kernel/of_device.c
+++ b/arch/sparc64/kernel/of_device.c
@@ -55,6 +55,17 @@ struct of_device *of_find_device_by_node(struct device_node
*dp)
}
EXPORT_SYMBOL(of_find_device_by_node);
+unsigned int irq_of_parse_and_map(struct device_node *node, int index)
+{
+ struct of_device *op = of_find_device_by_node(node);
+
+ if (!op || index >= op->num_irqs)
+ return 0;
+
+ return op->irqs[index];
+}
+EXPORT_SYMBOL(irq_of_parse_and_map);
+
#ifdef CONFIG_PCI
struct bus_type ebus_bus_type;
EXPORT_SYMBOL(ebus_bus_type);
--
1.5.6.5.GIT
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3]: Sparc OF I2C support v2.
Ok, I've integrated the feedback I got from various reviewers and for now I'm going to handle the sparc vs. powerpc aspects with a helper asm/of_i2c.h header file that implements the address fetching. I think for the time being this is the best solution. If the semantics converge, we can merge the logic back into the generic code. Signed-off-by: David S. Miller <[EMAIL PROTECTED]> ___ 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 9:53 PM, David Miller <[EMAIL PROTECTED]> wrote: >> 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. You mean email them privately? Outside of a public forum? That doesn't help much when it comes to discussing/debating issues and learning from other peoples conversations. As far as I can tell there aren't any other active mailing lists purposed for discussing device tree bindings. http://openfirmware.org, http://firmworks.com, and http://playground.sun.com/1275/ don't list any mailing lists and the last meeting shown on playground.sun.com was scheduled for 1999. openbios.org has a mailing list which seems to be idle except for SVN commit messages and doesn't seem to be used for discussing bindings. We need a place to discuss these issues that I don't see anywhere else. Please correct me if I'm missing a list. 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 0/3]: Sparc OF I2C support.
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 :-) > 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
On 8/21/08, Grant Likely <[EMAIL PROTECTED]> wrote: > On Thu, Aug 21, 2008 at 5:45 PM, Jon Smirl <[EMAIL PROTECTED]> wrote: > > On 8/21/08, Grant Likely <[EMAIL PROTECTED]> wrote: > > >> Ugh, more like loads of pain. There are deployed platforms using the > >> embedded 'invented' bindings. I don't think it is an option to break > >> compatibility with older trees. If there is some backwards > >> compatibility code then I'm all for migrating to the same binding as > >> Sparc and PowerMac > > > > Has anything really been deployed? These bindings are only a few months > old. > > > 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. > > See commit id d13ae8620dfdedfa7e9ab6d1eec294adc0516065. > > > g. > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > -- Jon Smirl [EMAIL PROTECTED] ___ 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 5:45 PM, Jon Smirl <[EMAIL PROTECTED]> wrote: > On 8/21/08, Grant Likely <[EMAIL PROTECTED]> wrote: >> Ugh, more like loads of pain. There are deployed platforms using the >> embedded 'invented' bindings. I don't think it is an option to break >> compatibility with older trees. If there is some backwards >> compatibility code then I'm all for migrating to the same binding as >> Sparc and PowerMac > > Has anything really been deployed? These bindings are only a few months old. It was over a year ago when support for i2c devices in the device tree was merged. See commit id d13ae8620dfdedfa7e9ab6d1eec294adc0516065. 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
disable modules and get "multiple definition" errors?
Hi,
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?
kevin
___
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, 2008-08-21 at 16:32 -0700, David Miller wrote: > From: "Grant Likely" <[EMAIL PROTECTED]> > Date: Thu, 21 Aug 2008 17:14:57 -0600 > > > On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <[EMAIL PROTECTED]> wrote: > > > David Miller wrote: > > >>> > > >>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote: > > >> If you guys created this format in your compressed openfirmware > > >> trees, is it possible for you to "fix" it to match what Sparc > > >> systems following the proper bindings do? > > > > > > Possibly, though it'll cause some pain when old trees are used with a > > > kernel > > > that expects the new binding. > > > > Ugh, more like loads of pain. There are deployed platforms using the > > embedded 'invented' bindings. I don't think it is an option to break > > compatibility with older trees. If there is some backwards > > compatibility code then I'm all for migrating to the same binding as > > Sparc and PowerMac > > You could even put the detection and reg property fixups in the device > tree expander. This way generic code in drivers/of/of_i2c.c doesn't > need to know about this huge mistake. 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. 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. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
On 8/21/08, Grant Likely <[EMAIL PROTECTED]> wrote: > On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <[EMAIL PROTECTED]> wrote: > > David Miller wrote: > >>> > >>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote: > > >> If you guys created this format in your compressed openfirmware > >> trees, is it possible for you to "fix" it to match what Sparc > >> systems following the proper bindings do? > > > > Possibly, though it'll cause some pain when old trees are used with a > kernel > > that expects the new binding. > > > Ugh, more like loads of pain. There are deployed platforms using the > embedded 'invented' bindings. I don't think it is an option to break > compatibility with older trees. If there is some backwards > compatibility code then I'm all for migrating to the same binding as > Sparc and PowerMac Has anything really been deployed? These bindings are only a few months old. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
From: "Grant Likely" <[EMAIL PROTECTED]> Date: Thu, 21 Aug 2008 17:14:57 -0600 > On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <[EMAIL PROTECTED]> wrote: > > David Miller wrote: > >>> > >>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote: > >> If you guys created this format in your compressed openfirmware > >> trees, is it possible for you to "fix" it to match what Sparc > >> systems following the proper bindings do? > > > > Possibly, though it'll cause some pain when old trees are used with a kernel > > that expects the new binding. > > Ugh, more like loads of pain. There are deployed platforms using the > embedded 'invented' bindings. I don't think it is an option to break > compatibility with older trees. If there is some backwards > compatibility code then I'm all for migrating to the same binding as > Sparc and PowerMac You could even put the detection and reg property fixups in the device tree expander. This way generic code in drivers/of/of_i2c.c doesn't need to know about this huge mistake. ___ 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 3:35 PM, Scott Wood <[EMAIL PROTECTED]> wrote: > David Miller wrote: >>> >>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote: >> If you guys created this format in your compressed openfirmware >> trees, is it possible for you to "fix" it to match what Sparc >> systems following the proper bindings do? > > Possibly, though it'll cause some pain when old trees are used with a kernel > that expects the new binding. Ugh, more like loads of pain. There are deployed platforms using the embedded 'invented' bindings. I don't think it is an option to break compatibility with older trees. If there is some backwards compatibility code then I'm all for migrating to the same binding as Sparc and PowerMac 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 3/3]: of: Add some I2C mod aliases table entries for sparc64 systems.
From: "Grant Likely" <[EMAIL PROTECTED]> Date: Thu, 21 Aug 2008 16:52:32 -0600 > On Thu, Aug 21, 2008 at 1:10 AM, David Miller <[EMAIL PROTECTED]> wrote: > > > > of: Add some I2C mod aliases table entries for sparc64 systems. > > > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > > I'd like to see a comment above these three lines stating that they > appear in Sparc systems, but otherwise... > > Acked-by: Grant Likely <[EMAIL PROTECTED]> Ok, I'll add that. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: New Patchwork beta
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-+. > * For the list of patches can we change the background of every other > line (light gray) That would work well. > * 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. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3]: of: Add some I2C mod aliases table entries for sparc64 systems.
On Thu, Aug 21, 2008 at 1:10 AM, David Miller <[EMAIL PROTECTED]> wrote:
>
> of: Add some I2C mod aliases table entries for sparc64 systems.
>
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
I'd like to see a comment above these three lines stating that they
appear in Sparc systems, but otherwise...
Acked-by: Grant Likely <[EMAIL PROTECTED]>
g.
> ---
> drivers/of/base.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index ad8ac1a..e849f69 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -410,7 +410,9 @@ struct of_modalias_table {
>char *modalias;
> };
> static struct of_modalias_table of_modalias_table[] = {
> - /* Empty for now; add entries as needed */
> + { "i2c-adm1031", "adm1031" },
> + { "i2c-at24c64", "24c64" },
> + { "i2c-at34c02", "spd" },
> };
>
> /**
> --
> 1.5.6.5.GIT
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
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 0/3]: Sparc OF I2C support.
On Thu, 2008-08-21 at 15:28 -0700, David Miller wrote: > From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Date: Fri, 22 Aug 2008 08:05:02 +1000 > > > Apple additionally have different ways of representing multiple busses > > on one controller though. On some machines, they just use bits 0xF00 of > > the address as the bus number, which is a bit gross, and on some, they > > have sub-nodes [EMAIL PROTECTED] under the controller. > > Ok, Sun uses a 2-cell scheme. We can handle both cases of reg > encoding quite easily: > > 1) If there is a single cell, tread bits 8 and above as bus number. >They will be zero on Sparc. Depends if you want also to handle 10-bit addresses... though the support for that could be enabled by an explicit property 10-bit-addresses in the controller node... But as I said before, I wouldn't worry too much about powermac for now, it's not using this code and may never do. > 2) If there are two cells, first cell is bus number. > > For the hierarchical case, I'm not so sure how to handle it. > > Also, last night, I posted patches to the I2C list to add bus > addressing support to the I2C code and the PCF algo implementation. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
> Thanks for the clarification. The bus encoding seems different > but we can solve that too. > > I've started a dialogue between Scott and the openfirmware Sun > folks I know so that hopefully Scott can get a copy of the I2C > bindings Sun uses and we can sort all of this out. Sure. Currently the powermac stuff isn't too relevant because I use my own infrastructure (not a huge thing, but I have a special layer of low level polled i2c drivers that I can use early during boot or during low level suspend/resume with IRQs off etc... that hooks up on to the main linux i2c stack etc...) So I'll let you guys come up with something, and we can later see if there's any interest in moving some of the pmac stuff over to it. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Date: Fri, 22 Aug 2008 08:05:02 +1000 > Apple additionally have different ways of representing multiple busses > on one controller though. On some machines, they just use bits 0xF00 of > the address as the bus number, which is a bit gross, and on some, they > have sub-nodes [EMAIL PROTECTED] under the controller. Ok, Sun uses a 2-cell scheme. We can handle both cases of reg encoding quite easily: 1) If there is a single cell, tread bits 8 and above as bus number. They will be zero on Sparc. 2) If there are two cells, first cell is bus number. For the hierarchical case, I'm not so sure how to handle it. Also, last night, I posted patches to the I2C list to add bus addressing support to the I2C code and the PCF algo implementation. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Date: Fri, 22 Aug 2008 08:05:50 +1000 > On Thu, 2008-08-21 at 14:45 -0700, David Miller wrote: > > > As far as I can tell from poking around > > > http://penguinppc.org/historical/dev-trees-html/, they don't include > > reg > > > at all for i2c clients. > > > > That actually simplifies things for us, thanks for checking. > > Unfortunately, while that may be true for old stuff, most recent > powermacs do. Encoding is mostly like sparc though (see other mails). Thanks for the clarification. The bus encoding seems different but we can solve that too. I've started a dialogue between Scott and the openfirmware Sun folks I know so that hopefully Scott can get a copy of the I2C bindings Sun uses and we can sort all of this out. ___ 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 Tue, 2008-08-19 at 13:28 +0200, Arnd Bergmann wrote:
> On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote:
> > +static inline long kvm_hypercall1(unsigned int nr, unsigned long p1)
> > +{
> > + register unsigned long hcall asm ("r0") = nr;
> > + register unsigned long arg1 asm ("r3") = p1;
> > + register long ret asm ("r11");
> > +
> > + asm volatile(".long %1"
> > + : "=r"(ret)
> > + : "i"(KVM_HYPERCALL_BIN), "r"(hcall), "r"(arg1)
> > + : "r4", "r5", "r6", "r7", "r8",
> > + "r9", "r10", "r12", "cc");
> > + return ret;
> > +}
>
> What is the reasoning for making the calling convention different from
> all the existing hcall interfaces here?
>
> pseries uses r3 for the hcall number, lv1 and beat use r11, so using
> r0 just for the sake of being different seems counterintuitive.
There was a really good reason at the time, but I can't seem to remember
it now. ;) We're thinking about it.
--
Hollis Blanchard
IBM Linux Technology Center
___
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, 2008-08-21 at 14:45 -0700, David Miller wrote: > > As far as I can tell from poking around > > http://penguinppc.org/historical/dev-trees-html/, they don't include > reg > > at all for i2c clients. > > That actually simplifies things for us, thanks for checking. Unfortunately, while that may be true for old stuff, most recent powermacs do. Encoding is mostly like sparc though (see other mails). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
> It's not really an instruction-set architecture issue, it's a binding > issue. What if a non-OF embedded SPARC comes along that copies i2c from > a PowerPC DTS file, or we come across a real-OF PowerPC that does it the > SPARC way? Like PowerMac ? :-) Apple additionally have different ways of representing multiple busses on one controller though. On some machines, they just use bits 0xF00 of the address as the bus number, which is a bit gross, and on some, they have sub-nodes [EMAIL PROTECTED] under the controller. But at least the address encoding (shifted by 1 bit) is common with sparc and I think is a fairly common way of representing i2c addresses. > As far as I can tell from poking around > http://penguinppc.org/historical/dev-trees-html/, they don't include reg > at all for i2c clients. Most of the device-trees on penguinppc.org are obsolete. i2c is mostly used in the device-tree for newer stuff such as G5s. Ben. ___ 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, 2008-08-21 at 11:32 -0500, Scott Wood wrote: > On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote: > > Mostly straightforward stuff _except_ for the I2C address encoding. > > > > What I2C IEEE1275 device binding was used to write that code in > > of_i2c.c? Is it some PowerPC specific thing? Was it "invented" > > by the embedded folks (I hope not)? > > Yes, it was "invented". There was no documented i2c OF binding that I > could find, and AFAIR nobody came forward with examples of existing > practice at the time. Well, there were examples in the powermac code :-) > > And, furthermore, the device address is shifted up 1 bit higher > > than the Linux I2C layer expects. It includes the low direction > > bit, bit 0, so we have to shift it down by 1 bit before we give > > it to the Linux I2C layer. > > Yuck. Apple does the same. IE. I take the address from "reg" and shift it right by one bit before passing it to linux. > > 2) When CONFIG_SPARC, shift the device address down by one bit before > >giving it to the Linux I2C layer. > > Maybe we should distinguish by the type of I2C bus node instead. Or fix the embedded stuff :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] math-emu: Fix compiler warnings
On Aug 21, 2008, at 4:03 PM, David Miller wrote: From: Kumar Gala <[EMAIL PROTECTED]> Date: Thu, 21 Aug 2008 07:50:20 -0500 Fix warnings of the form: arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f1' may be used uninitialized in this function arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f0' may be used uninitialized in this function Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> You should look at the compiler options we use on sparc to build this stuff :-) EXTRA_CFLAGS = -Iinclude/math-emu -w Yeah, I plan on doing that on PPC once I move over the global include/ math-emu files. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3]: sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
From: Anton Vorontsov <[EMAIL PROTECTED]>
Date: Fri, 22 Aug 2008 01:56:11 +0400
> On Thu, Aug 21, 2008 at 12:10:17AM -0700, David Miller wrote:
> > @@ -96,6 +96,14 @@ static inline void of_node_put(struct device_node *node)
> > {
> > }
> >
> > +/* These routines are here to provide compatibility with how powerpc
> > + * handles IRQ mapping for OF device nodes. We precompute and permanently
> > + * register them in the of_device objects, whereas powerpc computes them
> > + * on request.
> > + */
> > +extern int irq_of_parse_and_map(struct device_node *node, int index);
>
> On powerpc irq_of_parse_and_map() returns unsigned type.
>
> > +#define irq_dispose_mapping(irq) do { } while (0)
>
> I'd rather write it as a static inline function, for type checking,
> plus, I think with this macros gcc may generate warnings about
> defined but unused variables.
Thanks, I'll fix that.
> > +
> > /*
> > * NB: This is here while we transition from using asm/prom.h
> > * to linux/of.h
> > diff --git a/arch/sparc/kernel/of_device.c b/arch/sparc/kernel/of_device.c
> > index cc4c235..56e9a71 100644
> > --- a/arch/sparc/kernel/of_device.c
> > +++ b/arch/sparc/kernel/of_device.c
> > @@ -29,6 +29,17 @@ struct of_device *of_find_device_by_node(struct
> > device_node *dp)
> > }
> > EXPORT_SYMBOL(of_find_device_by_node);
> >
> > +int irq_of_parse_and_map(struct device_node *node, int index)
> > +{
> > + struct of_device *op = of_find_device_by_node(node);
> > +
> > + if (!op || index >= op->num_irqs)
> > + return 0x;
>
> This is valid virq, unfortunately. There is only one invalid virq: 0.
> With this most drivers will fail to identify 'there is no irq' case.
> Does virq0 has special meaning on sparc?
No, I'll fix this up, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
From: "Jon Smirl" <[EMAIL PROTECTED]> Date: Thu, 21 Aug 2008 17:53:02 -0400 > > 2) When CONFIG_SPARC, shift the device address down by one bit before > >giving it to the Linux I2C layer. > > How do you deal with a 10-bit address i2c device? Is it multiplied by two too? Yes. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3]: sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
On Thu, Aug 21, 2008 at 12:10:17AM -0700, David Miller wrote:
>
> sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
>
> This allows more OF layer code to be shared between powerpc and
> sparc.
>
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
> ---
> arch/sparc/include/asm/prom.h |8
> arch/sparc/kernel/of_device.c | 11 +++
> arch/sparc64/kernel/of_device.c | 11 +++
> 3 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/arch/sparc/include/asm/prom.h b/arch/sparc/include/asm/prom.h
> index b5efc4d..58b85fa 100644
> --- a/arch/sparc/include/asm/prom.h
> +++ b/arch/sparc/include/asm/prom.h
> @@ -96,6 +96,14 @@ static inline void of_node_put(struct device_node *node)
> {
> }
>
> +/* These routines are here to provide compatibility with how powerpc
> + * handles IRQ mapping for OF device nodes. We precompute and permanently
> + * register them in the of_device objects, whereas powerpc computes them
> + * on request.
> + */
> +extern int irq_of_parse_and_map(struct device_node *node, int index);
On powerpc irq_of_parse_and_map() returns unsigned type.
> +#define irq_dispose_mapping(irq) do { } while (0)
I'd rather write it as a static inline function, for type checking,
plus, I think with this macros gcc may generate warnings about
defined but unused variables.
> +
> /*
> * NB: This is here while we transition from using asm/prom.h
> * to linux/of.h
> diff --git a/arch/sparc/kernel/of_device.c b/arch/sparc/kernel/of_device.c
> index cc4c235..56e9a71 100644
> --- a/arch/sparc/kernel/of_device.c
> +++ b/arch/sparc/kernel/of_device.c
> @@ -29,6 +29,17 @@ struct of_device *of_find_device_by_node(struct
> device_node *dp)
> }
> EXPORT_SYMBOL(of_find_device_by_node);
>
> +int irq_of_parse_and_map(struct device_node *node, int index)
> +{
> + struct of_device *op = of_find_device_by_node(node);
> +
> + if (!op || index >= op->num_irqs)
> + return 0x;
This is valid virq, unfortunately. There is only one invalid virq: 0.
With this most drivers will fail to identify 'there is no irq' case.
Does virq0 has special meaning on sparc?
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
On 8/21/08, David Miller <[EMAIL PROTECTED]> wrote: > > I'm working on some drivers for I2C bus support on some of my sparc64 > workstations (for lm-sensor and eeprom type devices sitting behind > them) so I went back to trying to get of_i2c.c usable on sparc. > > Mostly straightforward stuff _except_ for the I2C address encoding. > > What I2C IEEE1275 device binding was used to write that code in > of_i2c.c? Is it some PowerPC specific thing? Was it "invented" > by the embedded folks (I hope not)? > > On sparc, the encoding is either 1 cell or 2 cell. > > If it's one cell, it's just the device address. > > If it's two cells, it's a bus number (for I2C controllers that > can manage multiple I2C bus segments, think PCI domains) in the > first cell and the device address in the second cell. > > And, furthermore, the device address is shifted up 1 bit higher > than the Linux I2C layer expects. It includes the low direction > bit, bit 0, so we have to shift it down by 1 bit before we give > it to the Linux I2C layer. > > Does PowerPC really encode these things differently? And if so what > IEEE1275 I2C device binding specification covers that? > > If PowerPC really does encode the device address in the same format as > the Linux I2C layer expects, that's OK and I used some property tests > and ifdefs to make it all work out. What I did in these patches is: > > 1) Check the #address-cells property. If not present, assume the value >is "1". Only accept values of "1" and "2". > > 2) When CONFIG_SPARC, shift the device address down by one bit before >giving it to the Linux I2C layer. How do you deal with a 10-bit address i2c device? Is it multiplied by two too? Here's the i2c spec, http://www.semiconductors.philips.com/acrobat_download/literature/9398/39340011.pdf It says the basic addresses are 7 bit. > I haven't added support to the I2C layer for the bus number yet, that > will come later. > > The first patch in this series add the powerpc-compat IRQ probing > interfaces, mostly straightforward stuff as we precompute these > IRQs in of_device objects so we just search for the of_device corresponding > to the device node and return the interrupt, if any. Dispost is a NOP. > > The second patch deals with the addressing issues described above and > lets it be compiled on non-ppc systems. > > The third patch adds device modaliases for a couple of I2C chip devices > I've seen on my SunBlade2500 workstation. More will come later as I > flesh out my I2C sparc64 drivers which are not being posted here yet. > I have a fully functional Sun pcf8584 I2C bus driver. > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
From: Scott Wood <[EMAIL PROTECTED]> Date: Thu, 21 Aug 2008 16:35:02 -0500 > David Miller wrote: > > If you guys created this format in your compressed openfirmware > > trees, is it possible for you to "fix" it to match what Sparc > > systems following the proper bindings do? > > Possibly, though it'll cause some pain when old trees are used with a > kernel that expects the new binding. > > You mentioned having an actual binding document for I2C on Open > Firmware; is it available online anywhere? It's a Sun internal document I got from a Sun employee, I'll ask if there is a way I can at least share it with you privately so you can use it as a reference. > > Don't PowerMACs and such have I2C controllers and devices? > > How do they encode these I2C client device reg properties? > > As far as I can tell from poking around > http://penguinppc.org/historical/dev-trees-html/, they don't include reg > at all for i2c clients. That actually simplifies things for us, thanks for checking. ___ 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
#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
+#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)
/*
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?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
David Miller wrote: On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote: 2) When CONFIG_SPARC, shift the device address down by one bit before giving it to the Linux I2C layer. Maybe we should distinguish by the type of I2C bus node instead. How so? If a Sparc and a PowerPC system use similar I2C controllers, we risk double matches. It's not really an instruction-set architecture issue, it's a binding issue. What if a non-OF embedded SPARC comes along that copies i2c from a PowerPC DTS file, or we come across a real-OF PowerPC that does it the SPARC way? If we do come across two systems that claim their i2c bus nodes are compatible but use different bindings, *then* we'll find some out-of-band information to disambiguate. If you guys created this format in your compressed openfirmware trees, is it possible for you to "fix" it to match what Sparc systems following the proper bindings do? Possibly, though it'll cause some pain when old trees are used with a kernel that expects the new binding. You mentioned having an actual binding document for I2C on Open Firmware; is it available online anywhere? Don't PowerMACs and such have I2C controllers and devices? How do they encode these I2C client device reg properties? As far as I can tell from poking around http://penguinppc.org/historical/dev-trees-html/, they don't include reg at all for i2c clients. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
From: Scott Wood <[EMAIL PROTECTED]> Date: Thu, 21 Aug 2008 11:32:56 -0500 > On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote: > > 2) When CONFIG_SPARC, shift the device address down by one bit before > >giving it to the Linux I2C layer. > > Maybe we should distinguish by the type of I2C bus node instead. How so? If a Sparc and a PowerPC system use similar I2C controllers, we risk double matches. If you guys created this format in your compressed openfirmware trees, is it possible for you to "fix" it to match what Sparc systems following the proper bindings do? This way we won't need any of these ifdefs at all. Don't PowerMACs and such have I2C controllers and devices? How do they encode these I2C client device reg properties? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Allow 32-bit pgtable code to support 36-bit physical
This rearranges a bit of code, and adds support for
36-bit physical addressing for configs that use a
hashed page table. The 36b physical support is not
enabled by default on any config - it must be
explicitly enabled via the config system.
This patch *only* expands the page table code to accomodate
large physical addresses on 32-bit systems and enables the
PHYS_64BIT config option for 6xx. It does *not*
allow you to boot a board with more than about 3.5GB of
RAM - for that, SWIOTLB support is also required (and
coming soon).
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/io.h|2 +-
arch/powerpc/include/asm/page_32.h | 10 -
arch/powerpc/include/asm/pgtable-ppc32.h | 35 +-
arch/powerpc/include/asm/types.h |2 +-
arch/powerpc/kernel/head_32.S|4 +-
arch/powerpc/kernel/head_fsl_booke.S |2 -
arch/powerpc/mm/hash_low_32.S| 78 +++--
arch/powerpc/mm/pgtable_32.c |4 +-
arch/powerpc/platforms/Kconfig.cputype | 14 --
9 files changed, 120 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 77c7fa0..08266d2 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -711,7 +711,7 @@ static inline void * phys_to_virt(unsigned long address)
/*
* Change "struct page" to physical address.
*/
-#define page_to_phys(page) (page_to_pfn(page) << PAGE_SHIFT)
+#define page_to_phys(page) ((phys_addr_t)page_to_pfn(page) << PAGE_SHIFT)
/* We do NOT want virtual merging, it would put too much pressure on
* our iommu allocator. Instead, we want drivers to be smart enough
diff --git a/arch/powerpc/include/asm/page_32.h
b/arch/powerpc/include/asm/page_32.h
index ebfae53..0b253f6 100644
--- a/arch/powerpc/include/asm/page_32.h
+++ b/arch/powerpc/include/asm/page_32.h
@@ -13,10 +13,18 @@
#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES
#endif
+#ifdef CONFIG_PTE_64BIT
+#define PTE_FLAGS_OFFSET 4 /* offset of PTE flags, in bytes */
+#define LNX_PTE_SIZE 8 /* size of a linux PTE, in bytes */
+#else
+#define PTE_FLAGS_OFFSET 0
+#define LNX_PTE_SIZE 4
+#endif
+
#ifndef __ASSEMBLY__
/*
* The basic type of a PTE - 64 bits for those CPUs with > 32 bit
- * physical addressing. For now this just the IBM PPC440.
+ * physical addressing.
*/
#ifdef CONFIG_PTE_64BIT
typedef unsigned long long pte_basic_t;
diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h
b/arch/powerpc/include/asm/pgtable-ppc32.h
index 6fe39e3..bf21a05 100644
--- a/arch/powerpc/include/asm/pgtable-ppc32.h
+++ b/arch/powerpc/include/asm/pgtable-ppc32.h
@@ -363,7 +363,12 @@ extern int icache_44x_need_flush;
#define _PAGE_EXEC 0x200 /* software: i-cache coherency required */
#define _PAGE_RW 0x400 /* software: user write access allowed */
+#ifdef CONFIG_PTE_64BIT
+/* We never clear the high word of the pte, mask those off */
+#define _PTE_NONE_MASK (0xULL | _PAGE_HASHPTE)
+#else
#define _PTE_NONE_MASK _PAGE_HASHPTE
+#endif
#define _PMD_PRESENT 0
#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)
+#else
#define pte_clear(mm,addr,ptep)do { set_pte_at((mm), (addr), (ptep),
__pte(0)); } while (0)
+#endif
#define pmd_none(pmd) (!pmd_val(pmd))
#definepmd_bad(pmd)(pmd_val(pmd) & _PMD_BAD)
@@ -656,10 +667,32 @@ static inline void set_pte_at(struct mm_struct *mm,
unsigned long addr,
pte_t *ptep, pte_t pte)
{
#if _PAGE_HASHPTE != 0
+#ifndef CONFIG_PTE_64BIT
pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) & ~_PAGE_HASHPTE);
#else
+ /*
+* We have to do the write of the 64b pte as 2 stores. This
+* code assumes that the entry we're storing to is currently
+* not valid and that all callers have the page table lock.
+* Having the entry be not valid protects readers who might read
+* between the first and second stores.
+*/
+ unsigned int tmp;
+
+ __asm__ __volatile__("\
+1: lwarx %0,0,%4\n\
+ rlwimi %L2,%0,0,30,30\n\
+ stw %2,0(%3)\n\
+ eieio\n\
+ stwcx. %L2,0,%4\n\
+ bne-1b"
+ : "=&r" (tmp), "=m" (*ptep)
+ : "r" (pte), "r" (ptep), "r" ((unsigned long)(ptep) + 4), "m" (*ptep)
+ : "cc");
+#endif /* CONFIG_PTE_64BIT */
+#else
*ptep = pte;
-#endif
+#endif /* _PAGE_HASHPTE */
}
/*
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/
Re: [PATCH] math-emu: Add support for reporting exact invalid exception
From: Kumar Gala <[EMAIL PROTECTED]> Date: Thu, 21 Aug 2008 07:50:21 -0500 > Some architectures (like powerpc) provide status information on the exact > type of invalid exception. This is pretty straight forward as we already > report invalid exceptions via FP_SET_EXCEPTION. > > We add new flags (FP_EX_INVALID_*) the architecture code can define if it > wants the exact invalid exception reported. > > We had to split out the INF/INF and 0/0 cases for divide to allow reporting > the two invalid forms properly. > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> Acked-by: David S. Miller <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] math-emu: Fix compiler warnings
From: Kumar Gala <[EMAIL PROTECTED]> Date: Thu, 21 Aug 2008 07:50:20 -0500 > Fix warnings of the form: > arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f1' may be used uninitialized > in this function > arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f0' may be used uninitialized > in this function > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> You should look at the compiler options we use on sparc to build this stuff :-) EXTRA_CFLAGS = -Iinclude/math-emu -w ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] I2C driver
Stefan Roese wrote: > On Thursday 21 August 2008, Sean MacLennan wrote: >> On Thu, 21 Aug 2008 13:06:24 -0400 >> >> "Steven A. Falco" <[EMAIL PROTECTED]> wrote: >>> However, while the i2c-ibm_of.c driver works with the sequoia .dts, >>> i2c-ibm_iic.c does not, because it is looking for an "index" property, >>> which is not in the .dts file. I added one: >> I don't know where i2c-ibm_of.c came from > > It's a temporary DENX version for arch/powerpc which we created, since it > took > too long to get something accepted upstream (I remember endless discussions > about index properties...). And we needed something functional quite a while > ago. > >> but in the 2.6.26 kernel >> you need the index property. >> >> The 2.6.27 kernel has a fully OF aware i2c-ibm_iic driver. You do >> not need the index. And it will walk the device tree and setup the >> devices for you. > > Yes. Since 2.6.27 the "original" IBM I2C driver should be enough. We will > drop > our local special version soon. > > Best regards, > 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: [EMAIL PROTECTED] > = > I was able to cherry-pick the i2c-ibm_iic driver from .27 into .26, so I withdraw my comments regarding the soon-to-be-discarded i2c-ibm_of driver. Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: New Patchwork beta
Some feedback: * Can we increase the font size a bit? * For the list of patches can we change the background of every other line (light gray) * Parsing subject header for determining state -- "[RFC]" w/o being able to log in that's my initial two cents. Both otherwise it looks good and seem much faster than the old version. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Change total_memory to phys_addr_t
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] 85xx: fix build warning, remove silly cast
On Aug 21, 2008, at 1:50 PM, Becky Bruce wrote: This fixes a build warning when PHYS_64BIT is enabled, and removes an unnecessary cast to phys_addr_t (the variable being cast is already a phys_addr_t) Signed-off-by: Becky Bruce <[EMAIL PROTECTED]> --- arch/powerpc/mm/fsl_booke_mmu.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) applied to powerpc-next. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: Board support for GE Fanuc SBC610
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts b/arch/powerpc/
boot/dts/gef_sbc610.dts
new file mode 100644
index 000..32168c6
--- /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
+ */
+
+/*
+ * Compiled with dtc -I dts -O dtb -o gef_sbc610.dtb gef_sbc610.dts
+ */
+
+/dts-v1/;
Look at fixing whitespace (using tabs instead of spaces)
+
+/ {
+ model = "GEF_SBC610";
+ compatible = "gef,sbc610";
+ #address-cells = <1>;
+ #size-cells = <1>;
You should add an aliases node and references as newer u-boots expect
that to setup various properties.
+
+ cpus {
+ #cpus = <2>;
+ #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
+ 32-bit;
+ };
+ 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
+ 32-bit;
+ };
+ };
+
+ 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] {
+ device_type = "dram-controller";
+ compatible = "mpc86xx";
+ reg = <0x2000 0x1000>;
+ interrupts = <0x12 0x2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ [EMAIL PROTECTED] {
+ device_type = "dram-controller";
+ compatible = "mpc86xx";
+ reg = <0x6000 0x1000>;
+ interrupts = <0x12 0x2>;
+ interrupt-parent = <&mpic>;
+ };
+
Take a look at the mpc8572ds.dts for examples of the memctrl device
nodes
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ co
Re: [RFC][PATCH] I2C driver
On Thursday 21 August 2008, Sean MacLennan wrote: > On Thu, 21 Aug 2008 13:06:24 -0400 > > "Steven A. Falco" <[EMAIL PROTECTED]> wrote: > > However, while the i2c-ibm_of.c driver works with the sequoia .dts, > > i2c-ibm_iic.c does not, because it is looking for an "index" property, > > which is not in the .dts file. I added one: > > I don't know where i2c-ibm_of.c came from It's a temporary DENX version for arch/powerpc which we created, since it took too long to get something accepted upstream (I remember endless discussions about index properties...). And we needed something functional quite a while ago. > but in the 2.6.26 kernel > you need the index property. > > The 2.6.27 kernel has a fully OF aware i2c-ibm_iic driver. You do > not need the index. And it will walk the device tree and setup the > devices for you. Yes. Since 2.6.27 the "original" IBM I2C driver should be enough. We will drop our local special version soon. Best regards, 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: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] 85xx: fix build warning, remove silly cast
This fixes a build warning when PHYS_64BIT is enabled, and removes an unnecessary cast to phys_addr_t (the variable being cast is already a phys_addr_t) Signed-off-by: Becky Bruce <[EMAIL PROTECTED]> --- arch/powerpc/mm/fsl_booke_mmu.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c index ce10e2b..23cee39 100644 --- a/arch/powerpc/mm/fsl_booke_mmu.c +++ b/arch/powerpc/mm/fsl_booke_mmu.c @@ -202,7 +202,7 @@ adjust_total_lowmem(void) cam_max_size = max_lowmem_size; /* adjust lowmem size to max_lowmem_size */ - ram = min(max_lowmem_size, (phys_addr_t)total_lowmem); + ram = min(max_lowmem_size, total_lowmem); /* Calculate CAM values */ __cam0 = 1UL << 2 * (__ilog2(ram) / 2); @@ -225,7 +225,8 @@ adjust_total_lowmem(void) printk(KERN_INFO "Memory CAM mapping: CAM0=%ldMb, CAM1=%ldMb," " CAM2=%ldMb residual: %ldMb\n", __cam0 >> 20, __cam1 >> 20, __cam2 >> 20, - (total_lowmem - __cam0 - __cam1 - __cam2) >> 20); + (long int)((total_lowmem - __cam0 - __cam1 - __cam2) + >> 20)); __max_low_memory = __cam0 + __cam1 + __cam2; __initial_memory_limit_addr = memstart_addr + __max_low_memory; } -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
Dear Valentine Barshak, In message <[EMAIL PROTECTED]> you wrote: > > U-boot thinks that all memory above the first 8MB is out of reach for > the kernel and puts kernel bootargs and boardinfo structure below 8MB as > close as possible to this limit. Including the i2c driver into the > kernel increases the kernel image size. So when u-boot unpacks the > kernel to 0x40 (Load Address: 0040) it overwrites the kernel > parameters. So when the kernel actually starts, it reads zeros instead > of boardinfo (and mac addresses) > > The 8MB limit is set for all AMCC boards in include/configs/amcc-common.h: > #define CFG_BOOTMAPSZ (8 << 20) /* Initial Memory map for Linux */ See also the initrd_high environment variable to adjust the limits without need for recompiling U-Boot. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] The complexity of software is an essential property, not an acciden- tal one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence.- Fred Brooks, Jr. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
Dear Geert, In message <[EMAIL PROTECTED]> you wrote: > > Can you actually boot a plain uImage from U-Boot? yes, of course you can (you will need a device tree, too). > I've just gave it a try. While arch/powerpc/boot/cuImage.sequoia boots fine, > after `make uImage', I get arch/powerpc/boot/uImage, but it doesn't boot: > > | ## Booting image at 0010 ... > |Image Name: Linux-2.6.27-rc4-dirty > |Image Type: PowerPC Linux Kernel Image (gzip compressed) > |Data Size:1398827 Bytes = 1.3 MB > |Load Address: > |Entry Point: > |Verifying Checksum ... OK > |Uncompressing Kernel Image ... Error: inflate() returned -3 > | GUNZIP ERROR - must RESET board to recover > | > | U-Boot 1.2.0-gc0c292b2 (Jun 5 2007 - 07:16:12) > > and I'm back to U-Boot... See the FAQ: http://www.denx.de/wiki/view/DULG/LinuxUncompressingError Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] A conservative is a man who believes that nothing should be done for the first time. - Alfred E. Wiggam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: Board support for GE Fanuc SBC610
Jon Loeliger wrote:
+mpic: [EMAIL PROTECTED] {
+clock-frequency = <0>;
+interrupt-controller;
+#address-cells = <0>;
+#interrupt-cells = <2>;
+reg = <0x0004 0x0004>;
+built-in;
+compatible = "chrp,open-pic";
+device_type = "open-pic";
+big-endian;
IIRC, we dropped "big-endian" too. (?)
And "built-in".
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: Board support for GE Fanuc SBC610
Martyn Welch wrote:
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 | 187 +
4 files changed, 464 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/gef_sbc610.dts
create mode 100644 arch/powerpc/platforms/86xx/gef_sbc610.c
+ [EMAIL PROTECTED] {
No "8641" in this name, please.
Oh, and drop the ""32-bit" in the CPU sections too.
+ [EMAIL PROTECTED] {
+ device_type = "dram-controller";
Hmmm, I suspect that should be dropped.
+ compatible = "mpc86xx";
And that changed to indicate some form of controller thing.
Using "mpc86xx" here is just not right at all.
+
+serial0: [EMAIL PROTECTED] {
+cell-index = <0>;
+device_type = "serial";
+compatible = "ns16550";
+reg = <0x4500 0x0100>;
+ clock-frequency = <0>;
+interrupts = <0x2a 0x2>;
+interrupt-parent = <&mpic>;
+};
+
+serial1: [EMAIL PROTECTED] {
+cell-index = <1>;
+device_type = "serial";
+compatible = "ns16550";
+reg = <0x4600 0x0100>;
+ clock-frequency = <0>;
+interrupts = <0x1c 0x2>;
+interrupt-parent = <&mpic>;
+};
There's some form of indenting issue there...
+ mpic: [EMAIL PROTECTED] {
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x0004 0x0004>;
+ built-in;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+big-endian;
IIRC, we dropped "big-endian" too. (?)
diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c
b/arch/powerpc/platforms/86xx/gef_sbc610.c
new file mode 100644
index 000..6b92876
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
@@ -0,0 +1,187 @@
+
+/*
+ * Based on: mpc86xx_hpcn.c
+ *
+ * MPC86xx HPCN board specific routines
+ *
+ * Recode: ZHANG WEI <[EMAIL PROTECTED]>
+ * Initial author: Xianghua Xiao <[EMAIL PROTECTED]>
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ *
+ */
This seems misleading some. Sure, state your attributions
and derivation sources, but this also still looks like it
is stating that it *is* the MPC86xx HPCN board code.
Thanks,
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] I2C driver
On Thu, 21 Aug 2008 13:06:24 -0400 "Steven A. Falco" <[EMAIL PROTECTED]> wrote: > However, while the i2c-ibm_of.c driver works with the sequoia .dts, > i2c-ibm_iic.c does not, because it is looking for an "index" property, > which is not in the .dts file. I added one: I don't know where i2c-ibm_of.c came from but in the 2.6.26 kernel you need the index property. The 2.6.27 kernel has a fully OF aware i2c-ibm_iic driver. You do not need the index. And it will walk the device tree and setup the devices for you. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] I2C driver
On Thu, 21 Aug 2008 13:06:24 -0400 "Steven A. Falco" <[EMAIL PROTECTED]> wrote: > Josh Boyer wrote: > > On Thu, 2008-08-21 at 12:21 -0400, Steven A. Falco wrote: > >> The following patch enables building the I2C driver for 4xx chips. > >> Tested on a Sequoia board. Comments invited. > >> > >> Signed-off-by: Steven A. Falco <[EMAIL PROTECTED]> > >> --- > >> drivers/i2c/busses/Kconfig |7 +++ > >> drivers/i2c/busses/i2c-ibm_of.c |5 ++--- > >> 2 files changed, 9 insertions(+), 3 deletions(-) > > > > That file doesn't even exist in the mainline kernel: > > > > [EMAIL PROTECTED] linux-2.6]$ find drivers/i2c/ -name *ibm* > > drivers/i2c/busses/i2c-ibm_iic.c > > drivers/i2c/busses/i2c-ibm_iic.h > > [EMAIL PROTECTED] linux-2.6]$ > > > > josh > > > > > > Interesting. Ok - I found the problem with the driver you *did* find: .26 doesn't have what can be considered awesome i2c support. But the latest git trees are much better. See git commits: d3dc685eb5ef64aa695dabb74f00440ec3ab6796 and b1204e6ec16468ebf89d9d818bfe425ca7adcdf3 They deal with the problems you highlighted with the listing and index stuff. There might be more issues outstanding, but using the latest kernel is going to get you better support and prevent you from finding problems that are already fixed :) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] I2C driver
Josh Boyer wrote:
> On Thu, 2008-08-21 at 12:21 -0400, Steven A. Falco wrote:
>> The following patch enables building the I2C driver for 4xx chips.
>> Tested on a Sequoia board. Comments invited.
>>
>> Signed-off-by: Steven A. Falco <[EMAIL PROTECTED]>
>> ---
>> drivers/i2c/busses/Kconfig |7 +++
>> drivers/i2c/busses/i2c-ibm_of.c |5 ++---
>> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> That file doesn't even exist in the mainline kernel:
>
> [EMAIL PROTECTED] linux-2.6]$ find drivers/i2c/ -name *ibm*
> drivers/i2c/busses/i2c-ibm_iic.c
> drivers/i2c/busses/i2c-ibm_iic.h
> [EMAIL PROTECTED] linux-2.6]$
>
> josh
>
>
Interesting. Ok - I found the problem with the driver you *did* find:
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 85dbf34..569161d 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -989,6 +989,7 @@ static int __devexit iic_remove(struct of_device *ofdev)
static const struct of_device_id ibm_iic_match[] = {
{ .compatible = "ibm,iic-405ex", },
{ .compatible = "ibm,iic-405gp", },
+ { .compatible = "ibm,iic-440epx", },
{ .compatible = "ibm,iic-440gp", },
{ .compatible = "ibm,iic-440gpx", },
{ .compatible = "ibm,iic-440grx", },
However, while the i2c-ibm_of.c driver works with the sequoia .dts,
i2c-ibm_iic.c does not, because it is looking for an "index" property,
which is not in the .dts file. I added one:
diff --git a/arch/powerpc/boot/dts/sequoia.dts
b/arch/powerpc/boot/dts/sequoia.dts
index 72d6756..538aadb 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -248,6 +248,7 @@
reg = ;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
+ index = <0>;
};
IIC1: [EMAIL PROTECTED] {
@@ -255,6 +256,7 @@
reg = ;
interrupt-parent = <&UIC0>;
interrupts = <7 4>;
+ index = <1>;
};
ZMII0: [EMAIL PROTECTED] {
However, something is still not right. Using the mystery i2c-ibm_of.c
driver, I get:
i2c /dev entries driver
IBM IIC driver v2.1
m41t80_probe called
rtc-m41t80 0-0068: chip found, driver version 0.05
rtc-m41t80 0-0068: rtc core: registered m41t80 as rtc0
ibm-iic(/plb/opb/[EMAIL PROTECTED]): using standard (100 kHz) mode
ibm-iic(/plb/opb/[EMAIL PROTECTED]): using standard (100 kHz) mode
But with the i2c-ibm_iic.c driver, I get:
i2c /dev entries driver
ibm-iic 1ef600700.i2c: using standard (100 kHz) mode
ibm-iic 1ef600800.i2c: using standard (100 kHz) mode
I.e. it doesn't find the rtc (which I added to my sequoia board).
Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot cuImage on an old u-boot
On Wed, Aug 20, 2008 at 05:09:58PM +0200, Sebastian Siewior wrote: > I have here a mpc8540ads board and a u-boot 1.0.0. I've build the > defconfig for the board and I tried to boot the genarated > cuImage.mpc8540ads image. After the bootm command I see just > > |8540> bootm 100 > |## Booting image at 0100 ... > | Image Name: Linux-2.6.26 > | Image Type: PowerPC Linux Kernel Image (gzip compressed) > | Data Size:1232711 Bytes = 1.2 MB > | Load Address: 0040 > | Entry Point: 004005ac > | Verifying Checksum ... OK > | Uncompressing Kernel Image ... OK > | > > I don't see the device tree fixups printfs, so crash happend quite > early. Anyone an idea what I could have done wrong? Make sure the device tree contains /chosen/linux,stdout-path. -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 Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote: > Mostly straightforward stuff _except_ for the I2C address encoding. > > What I2C IEEE1275 device binding was used to write that code in > of_i2c.c? Is it some PowerPC specific thing? Was it "invented" > by the embedded folks (I hope not)? Yes, it was "invented". There was no documented i2c OF binding that I could find, and AFAIR nobody came forward with examples of existing practice at the time. > And, furthermore, the device address is shifted up 1 bit higher > than the Linux I2C layer expects. It includes the low direction > bit, bit 0, so we have to shift it down by 1 bit before we give > it to the Linux I2C layer. Yuck. > 2) When CONFIG_SPARC, shift the device address down by one bit before >giving it to the Linux I2C layer. Maybe we should distinguish by the type of I2C bus node instead. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] I2C driver
On Thu, 2008-08-21 at 12:21 -0400, Steven A. Falco wrote: > The following patch enables building the I2C driver for 4xx chips. > Tested on a Sequoia board. Comments invited. > > Signed-off-by: Steven A. Falco <[EMAIL PROTECTED]> > --- > drivers/i2c/busses/Kconfig |7 +++ > drivers/i2c/busses/i2c-ibm_of.c |5 ++--- > 2 files changed, 9 insertions(+), 3 deletions(-) That file doesn't even exist in the mainline kernel: [EMAIL PROTECTED] linux-2.6]$ find drivers/i2c/ -name *ibm* drivers/i2c/busses/i2c-ibm_iic.c drivers/i2c/busses/i2c-ibm_iic.h [EMAIL PROTECTED] linux-2.6]$ josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC][PATCH] I2C driver
The following patch enables building the I2C driver for 4xx chips.
Tested on a Sequoia board. Comments invited.
Signed-off-by: Steven A. Falco <[EMAIL PROTECTED]>
---
drivers/i2c/busses/Kconfig |7 +++
drivers/i2c/busses/i2c-ibm_of.c |5 ++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e9f88fe..6444030 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -247,6 +247,13 @@ config I2C_PIIX4
This driver can also be built as a module. If so, the module
will be called i2c-piix4.
+config I2C_IBM_OF
+ tristate "IBM PPC 4xx open-firmware driver"
+ depends on 4xx
+ help
+ Say Y here if you want to use the open-firmware driver for
+ IIC peripheral found on embedded IBM PPC 4xx based systems.
+
config I2C_IBM_IIC
tristate "IBM PPC 4xx on-chip I2C interface"
depends on 4xx
diff --git a/drivers/i2c/busses/i2c-ibm_of.c b/drivers/i2c/busses/i2c-ibm_of.c
index 08440ab..caa895d 100644
--- a/drivers/i2c/busses/i2c-ibm_of.c
+++ b/drivers/i2c/busses/i2c-ibm_of.c
@@ -699,9 +699,7 @@ static int __init of_find_i2c_driver(struct device_node
*node,
for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
if (!of_device_is_compatible(node, i2c_devices[i].of_device))
continue;
- if (strlcpy(info->driver_name, i2c_devices[i].i2c_driver,
- KOBJ_NAME_LEN) >= KOBJ_NAME_LEN ||
- strlcpy(info->type, i2c_devices[i].i2c_type,
+ if (strlcpy(info->type, i2c_devices[i].i2c_type,
I2C_NAME_SIZE) >= I2C_NAME_SIZE)
return -ENOMEM;
return 0;
@@ -906,6 +904,7 @@ static const struct of_device_id ibm_iic_match[] = {
{ .compatible = "ibm,iic-405ex", },
{ .compatible = "ibm,iic-405exr", },
{ .compatible = "ibm,iic-405gp", },
+ { .compatible = "ibm,iic-440epx", },
{ .compatible = "ibm,iic-440gp", },
{ .compatible = "ibm,iic-440gpx", },
{ .compatible = "ibm,iic-440grx", },
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
libfreevec benchmarks
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 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). 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). Regards Konstantinos Margaritis Codex http://www.codex.gr ___ 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 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add a simple 405EP based board
On Thu, 2008-08-21 at 15:42 +0200, Arnd Bergmann wrote: > On Thursday 21 August 2008, Josh Boyer wrote: > > On Thu, 2008-08-21 at 10:07 +0200, Markus Brunner wrote: > > > This adds support for a simple ppc405ep board. > > > At the moment, there are no 405ep boards in arch/powerpc, so this can be > > > used as a template > > > for new boards, or migrating them from arch/ppc. > > > I2c, UART and EMAC are working. PCI could not be tested, so it was not > > > included in the dts. > > > > I plan on adding more 405 board support very soon. When I do, it'll be > > along the lines of the patch series I just sent out for 44x. There's > > really no reason to have a per CPU/board file if we can avoid it. > > > > This may be a stupid question, but is there really a reason to keep 40x and > 44x > setup files separate? AFAICT, the ppc_md structures are the same, so even you > can never have a common binary between 40x and 44x, you may have the same > platform > file. arch/ppc had them all lumped under platforms/4xx, but this was split in the original arch/powerpc port when arch/powerpc/platforms/44x was created. That left arch/powerpc/platforms/4xx for 40x which didn't really make sense, so it was renamed to 40x. I can understand why, as they are really two different platforms. So logically it makes sense to have them separate. I'm not overly motivated to convert it back to the old way but I might be able to be convinced. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
I2C probe not happening
I'm using DENX-2.6.26, and I've enabled the I2C_IBM_IIC on a Sequoia board,
but I don't see any probes happening.
It looks like of_register_i2c_devices is never being called. According to
cscope, it would be called in i2c-ibm_of.c, but that file is not part of
the build.
i2c-ibm_of.c would be compiled if CONFIG_I2C_IBM_OF was selected, but there
is no place in the Kconfig files that I2C_IBM_OF is mentioned. So, I added
it like so:
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e9f88fe..a221b15 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -247,9 +247,16 @@ config I2C_PIIX4
This driver can also be built as a module. If so, the module
will be called i2c-piix4.
+config I2C_IBM_OF
+ tristate "IBM PPC 4xx open-firmware driver"
+ depends on 4xx
+ help
+ Use openfirmware driver mechanism.
+
config I2C_IBM_IIC
tristate "IBM PPC 4xx on-chip I2C interface"
depends on 4xx
+ select I2C_IBM_OF
help
Say Y here if you want to use IIC peripheral found on
embedded IBM PPC 4xx based systems.
Also, I noticed that i2c-ibm_of.c doesn't have an entry for the 440EPx, so
I added one:
diff --git a/drivers/i2c/busses/i2c-ibm_of.c b/drivers/i2c/busses/i2c-ibm_of.c
index 08440ab..df35686 100644
--- a/drivers/i2c/busses/i2c-ibm_of.c
+++ b/drivers/i2c/busses/i2c-ibm_of.c
@@ -906,6 +906,7 @@ static const struct of_device_id ibm_iic_match[] = {
{ .compatible = "ibm,iic-405ex", },
{ .compatible = "ibm,iic-405exr", },
{ .compatible = "ibm,iic-405gp", },
+ { .compatible = "ibm,iic-440epx", },
{ .compatible = "ibm,iic-440gp", },
{ .compatible = "ibm,iic-440gpx", },
{ .compatible = "ibm,iic-440grx", },
However, the file does not compile. I get:
linux-2.6-denx/drivers/i2c/busses/i2c-ibm_of.c:702:
error: 'struct i2c_board_info' has no member named 'driver_name'
make[4]: *** [drivers/i2c/busses/i2c-ibm_of.o] Error 1
So perhaps it should not be part of the build. But in that case, I see
no way for the probes to run.
I must be missing something - hints gratefully accepted.
Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] powerpc/cell/oprofile: fix mutex locking for spu-oprofile
On Thu, 2008-08-21 at 20:20 +1000, Michael Ellerman wrote: > On Thu, 2008-08-21 at 10:14 +0200, Arnd Bergmann wrote: > > On Thursday 21 August 2008, Paul Mackerras wrote: > > > Arnd Bergmann writes: > > > > > > > Paul, any chance we can still get this into 2.6.27? > > > > > > Possibly. We'll need a really good explanation for Linus as to why > > > this is needed (what regression or serious bug this fixes) and why it > > > is late. Can you send me something explaining that? > > > > The patch does not fix a regression, the spu-oprofile code basically never > > worked. With the current code in Linux, samples in the profile buffer > > can get corrupted because reader and writer to that buffer use different > > locks for accessing it. > > Actually for me it worked[1] a reasonable amount of the time, enough to > be useful. So the spu-oprofile code has always been broken in this way, > but it's not always fatal. So the patch doesn't fix a regression, but it > fixes a serious user-visible bug, which makes it legit rc4 material > IMHO. > > [1] that was late last year, so possibly a kernel or two ago. The bug came in the original OProfile SPU support that was put out about 2 years ago. The way the code was there was a window in which you may get corruption. It was not until Jan 08 when we got the first report of the bug from Michael and identified it. Since then there have been three or four more people who have hit and reported the bug. I am seeing the bug show up more frequently with the latest couple of weekly SDK 3.1 kernels. It would seem that the kernel may have changed such that the timing is more likely to hit the bug. For the Beta SDK 3.1 release the IVT team was not able to complete their OProfile testing due to the bug. > > cheers > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ oprofile-list mailing list > [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oprofile-list ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 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(-) create mode 100644 arch/powerpc/configs/gef_sbc610_defconfig 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_MM
Re: Strange behavior with I2C on Sequoia board
On Thursday 21 August 2008, Geert Uytterhoeven wrote: > On Thu, 21 Aug 2008, Steven A. Falco wrote: > > I would like to switch over to using a uImage rather than the > > cuboot.uImage. > > Can you actually boot a plain uImage from U-Boot? Sure. We did this all the time in arch/ppc. Now in arch/powerpc all you need is an device-tree enabled U-Boot version. This is standard for most targets since a few months. > I've just gave it a try. While arch/powerpc/boot/cuImage.sequoia boots > fine, > > after `make uImage', I get arch/powerpc/boot/uImage, but it doesn't boot: > | ## Booting image at 0010 ... > |Image Name: Linux-2.6.27-rc4-dirty > |Image Type: PowerPC Linux Kernel Image (gzip compressed) > |Data Size:1398827 Bytes = 1.3 MB > |Load Address: > |Entry Point: > |Verifying Checksum ... OK > |Uncompressing Kernel Image ... Error: inflate() returned -3 > | GUNZIP ERROR - must RESET board to recover Try a higher load address for the kernel. 4MB is a good value. > | U-Boot 1.2.0-gc0c292b2 (Jun 5 2007 - 07:16:12) Ups. This is most likely too old and can't boot arch/powerpc uImage files. Best regards, 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: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 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 | 187 +
4 files changed, 464 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/gef_sbc610.dts
create mode 100644 arch/powerpc/platforms/86xx/gef_sbc610.c
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts
b/arch/powerpc/boot/dts/gef_sbc610.dts
new file mode 100644
index 000..32168c6
--- /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
+ */
+
+/*
+ * 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>;
+
+ cpus {
+ #cpus = <2>;
+ #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
+ 32-bit;
+ };
+ 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
+ 32-bit;
+ };
+ };
+
+ 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] {
+ device_type = "dram-controller";
+ compatible = "mpc86xx";
+ reg = <0x2000 0x1000>;
+ interrupts = <0x12 0x2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ [EMAIL PROTECTED] {
+
Re: Strange behavior with I2C on Sequoia board
On Thu, 21 Aug 2008, Steven A. Falco wrote: > I would like to switch over to using a uImage rather than the cuboot.uImage. Can you actually boot a plain uImage from U-Boot? I've just gave it a try. While arch/powerpc/boot/cuImage.sequoia boots fine, after `make uImage', I get arch/powerpc/boot/uImage, but it doesn't boot: | ## Booting image at 0010 ... |Image Name: Linux-2.6.27-rc4-dirty |Image Type: PowerPC Linux Kernel Image (gzip compressed) |Data Size:1398827 Bytes = 1.3 MB |Load Address: |Entry Point: |Verifying Checksum ... OK |Uncompressing Kernel Image ... Error: inflate() returned -3 | GUNZIP ERROR - must RESET board to recover | | U-Boot 1.2.0-gc0c292b2 (Jun 5 2007 - 07:16:12) and I'm back to U-Boot... 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: Strange behavior with I2C on Sequoia board
On Thursday 21 August 2008, Steven A. Falco wrote: > Your diagnosis is correct! I changed the define from 8<<20 to 8<<21 and it > now boots. Previously the parameters were at 7ffe70, and this change moved > them to fffe70. Good. > I would like to switch over to using a uImage rather than the > cuboot.uImage. But I have not figured out whether it is the U-boot build > that converts the .dts to a .dtb or if the kernel build should do that. The dts is part of the kernel source, so its part of the kernel build procedure. You can either do this by hand or use the "make kilauea.dtb" target. See also: http://www.denx.de/wiki/DULG/LinuxFDTBlob > Also, I have not figured out whether the .dtb can remain part of the kernel > image, as it is with the cuboot kernel, or if the .dtb must be a separate > image in a different part of the rom. When you use uImage, then U-Boot needs the dtb additionally to the kernel image. Those two images (and more) can be combined to a single image using the new U-Boot image format FIT (Flattened Image Tree) though. Best regards, Stefan ___ 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 21, 2008, at 9:13 AM, Christian Ehrhardt wrote: Kumar Gala wrote: On Aug 19, 2008, at 5:36 AM, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt <[EMAIL PROTECTED]> Dependent on the already existing CONFIG_KVM_GUEST config option this patch changes wrteei to wrtee allowing the hypervisor to rewrite those to nontrapping instructions. Maybe we should split the kvm guest otpimizations in two parts one for the overhead free optimizations and on for the rest that might add some complexity for non virtualized execution (like this one). Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> --- So this commit message doesnt explain why 'wrtee' facilities doing whatever optimization and 'wrteei' doesnt. yep I only explained it elsewhere. I'll add it here too in the next version - thanks Kumar (and fix the word otpimizations) 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). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] math-emu: Fix compiler warnings
On Aug 21, 2008, at 8:49 AM, Stephen Rothwell wrote: Hi Kumar, On Thu, 21 Aug 2008 07:50:20 -0500 Kumar Gala <[EMAIL PROTECTED] > wrote: Fix warnings of the form: arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f1' may be used uninitialized in this function arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f0' may be used uninitialized in this function Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- I intend these patches to go via the powerpc.git tree if no one has issues. - k include/math-emu/op-2.h |2 +- Are you modifying the right file here? There is also arch/powerpc/math-emu/op-2.h which contains the same construct. I forgot to mention this is a precursor to moving arch/powerpc to using the generic math-emu code in include/math-emu/ I don't see any reason to fixup the old code. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
On Thursday 21 August 2008, Valentine Barshak wrote: > > It seems that your bootwrapper is somehow not copying the correct MAC > > address to the device-tree. Not sure what's going wrong here. We usually > > don't use the bootwrapper but boot the uImage directly from U-Boot on all > > 4xx systems. > > > > You might want to debug the bootwrapper code, if possible drop the > > bootwrapper and use the uImage with a newer, device-tree enabled U-Boot > > version. > > U-boot thinks that all memory above the first 8MB is out of reach for > the kernel and puts kernel bootargs and boardinfo structure below 8MB as > close as possible to this limit. Including the i2c driver into the > kernel increases the kernel image size. So when u-boot unpacks the > kernel to 0x40 (Load Address: 0040) it overwrites the kernel > parameters. So when the kernel actually starts, it reads zeros instead > of boardinfo (and mac addresses) > > The 8MB limit is set for all AMCC boards in include/configs/amcc-common.h: > #define CFG_BOOTMAPSZ (8 << 20) /* Initial Memory map for Linux */ > > I think this limit is obsolete and can be moved to at least 64MB. > But you'll need to rebuild u-boot. > > Stefan, what do you think? Can we increase the default initial memory > map for AMCC boards in the next u-boot release, since u-boot has all > memory identity-mapped on ppc 44x? Yes, it was our intention to increase the default map to a higher value a few weeks ago. I just forgot to really do it. I'll do this shortly. Thanks. Best regards, 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: [EMAIL PROTECTED] = ___ 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
Kumar Gala wrote: On Aug 19, 2008, at 5:36 AM, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt <[EMAIL PROTECTED]> Dependent on the already existing CONFIG_KVM_GUEST config option this patch changes wrteei to wrtee allowing the hypervisor to rewrite those to nontrapping instructions. Maybe we should split the kvm guest otpimizations in two parts one for the overhead free optimizations and on for the rest that might add some complexity for non virtualized execution (like this one). Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> --- So this commit message doesnt explain why 'wrtee' facilities doing whatever optimization and 'wrteei' doesnt. yep I only explained it elsewhere. I'll add it here too in the next version - thanks Kumar (and fix the word otpimizations) -- 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
Re: [PATCH] math-emu: Fix compiler warnings
Hi Kumar, On Thu, 21 Aug 2008 07:50:20 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote: > > Fix warnings of the form: > arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f1' may be used uninitialized > in this function > arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f0' may be used uninitialized > in this function > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > --- > > I intend these patches to go via the powerpc.git tree if no one has issues. > > - k > > include/math-emu/op-2.h |2 +- Are you modifying the right file here? There is also arch/powerpc/math-emu/op-2.h which contains the same construct. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpaFxaHptOdD.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 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]> --- 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 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Aug 19, 2008, at 5:36 AM, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt <[EMAIL PROTECTED]> Dependent on the already existing CONFIG_KVM_GUEST config option this patch changes wrteei to wrtee allowing the hypervisor to rewrite those to nontrapping instructions. Maybe we should split the kvm guest otpimizations in two parts one for the overhead free optimizations and on for the rest that might add some complexity for non virtualized execution (like this one). Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> --- So this commit message doesnt explain why 'wrtee' facilities doing whatever optimization and 'wrteei' doesnt. - k ___ 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: > On Thu, 2008-08-21 at 10:07 +0200, Markus Brunner wrote: > > This adds support for a simple ppc405ep board. > > At the moment, there are no 405ep boards in arch/powerpc, so this can be > > used as a template > > for new boards, or migrating them from arch/ppc. > > I2c, UART and EMAC are working. PCI could not be tested, so it was not > > included in the dts. > > I plan on adding more 405 board support very soon. When I do, it'll be > along the lines of the patch series I just sent out for 44x. There's > really no reason to have a per CPU/board file if we can avoid it. > This may be a stupid question, but is there really a reason to keep 40x and 44x setup files separate? AFAICT, the ppc_md structures are the same, so even you can never have a common binary between 40x and 44x, you may have the same platform file. Arnd <>< ___ 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
Josh Boyer wrote:
On Wed, 20 Aug 2008 14:06:51 -0500
Hollis Blanchard <[EMAIL PROTECTED]> wrote:
To be honest I unfortunately don't know how big the impact for
non-virtualized systems is. I would like to test it, but without
hardware performance counters on the core I have I'm not sure (yet)
how
to measure that in a good way - any suggestion welcome.
I don't see why we need performance counters. Can't we just compare any
bare metal benchmark results with the patch both applied and not?
Do you know of one that causes a large amount of
local_irq_{disable,enable}s to be called?
I think *every* workload causes a large number of
local_irq_{disable,enable} calls... :)
Well, sure. I was just going for "test the change as specifically as
possible." One could write a module that did X number of
disable/enable pairs and reported the timebase at start and end to
compare. X could even be a module parameter. Just to try and
eliminate noise or whatever from the testing.
/me shrugs.
josh
yeah I thought of something like that too, because I expect the
difference to be very small.
Instead of a module I wanted to put this somewhere prior to the kernel
mounting root-fs to avoid interferences from whatever userspace is doing
(e.g. causing thousands of interrupts come back while the module
perform that test.).
Eventually we need a synthetic benchmark like that AND a check how it
affects a common system to be sure.
--
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
Re: Strange behavior with I2C on Sequoia board
Valentine Barshak wrote: > > Stefan Roese wrote: >> On Thursday 21 August 2008, Sean MacLennan wrote: That's all output from the wrapper, not the kernel. And the kernel config doesn't make a difference at all to the wrapper. I wonder if there is some weird size issue going on there or if whatever U-Boot version you are using is doing odd things... >>> Any chance something in the DTS could affect it? Maybe try commenting >>> out the second IIC controller? >> >> Yes, I2C is generally working and should make a difference in Linux >> kernel booting. >> >> It seems that your bootwrapper is somehow not copying the correct MAC >> address to the device-tree. Not sure what's going wrong here. We >> usually don't use the bootwrapper but boot the uImage directly from >> U-Boot on all 4xx systems. >> >> You might want to debug the bootwrapper code, if possible drop the >> bootwrapper and use the uImage with a newer, device-tree enabled >> U-Boot version. >> > > U-boot thinks that all memory above the first 8MB is out of reach for > the kernel and puts kernel bootargs and boardinfo structure below 8MB as > close as possible to this limit. Including the i2c driver into the > kernel increases the kernel image size. So when u-boot unpacks the > kernel to 0x40 (Load Address: 0040) it overwrites the kernel > parameters. So when the kernel actually starts, it reads zeros instead > of boardinfo (and mac addresses) > > The 8MB limit is set for all AMCC boards in include/configs/amcc-common.h: > #define CFG_BOOTMAPSZ(8 << 20) /* Initial Memory map for Linux */ > > I think this limit is obsolete and can be moved to at least 64MB. > But you'll need to rebuild u-boot. > > Stefan, what do you think? Can we increase the default initial memory > map for AMCC boards in the next u-boot release, since u-boot has all > memory identity-mapped on ppc 44x? > Your diagnosis is correct! I changed the define from 8<<20 to 8<<21 and it now boots. Previously the parameters were at 7ffe70, and this change moved them to fffe70. I would like to switch over to using a uImage rather than the cuboot.uImage. But I have not figured out whether it is the U-boot build that converts the .dts to a .dtb or if the kernel build should do that. Also, I have not figured out whether the .dtb can remain part of the kernel image, as it is with the cuboot kernel, or if the .dtb must be a separate image in a different part of the rom. So basically, I understand the components, but I'm not yet sure how to glue it all together. Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Initrd
Hello, I am trying to setup a initrd on my board. I selected initrd support in the 2.6.26 kernel. But when my boad boots, it crashes affet MMU:exit. What is the process in order to use a initrd ? Thanks Sébastien Chrétien ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add a simple 405EP based board
On 8/21/08, Josh Boyer <[EMAIL PROTECTED]> wrote: > I plan on adding more 405 board support very soon. When I do, it'll be > along the lines of the patch series I just sent out for 44x. There's > really no reason to have a per CPU/board file if we can avoid it. > > Your code is simple enough overall, so I might even use it as a starting > I've seen your patches for 44x support and I like the idea of a general board setup. I wanted to make the dts public, because I needed some help to figure out the "mdio-device" tag. So if you have further use for this you're welcome. > Though it's incomplete > in that you have a DTS that requires something to poke values into it, > and nothing readily apparent to do so. A cuImage wrapper is probably > warranted here. The missing values in the dts get filled in by ft_cpu_setup(...) from uboot, it's generic code and not board specific, but the board setup in u-boot must call it, so it won't work for all boards. Best regards Markus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] math-emu: Add support for reporting exact invalid exception
Some architectures (like powerpc) provide status information on the exact
type of invalid exception. This is pretty straight forward as we already
report invalid exceptions via FP_SET_EXCEPTION.
We add new flags (FP_EX_INVALID_*) the architecture code can define if it
wants the exact invalid exception reported.
We had to split out the INF/INF and 0/0 cases for divide to allow reporting
the two invalid forms properly.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
I intend these patches to go via the powerpc.git tree if no one has issues.
- k
include/math-emu/op-common.h | 12
include/math-emu/soft-fp.h | 19 +++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/include/math-emu/op-common.h b/include/math-emu/op-common.h
index bb46e76..cc1ec39 100644
--- a/include/math-emu/op-common.h
+++ b/include/math-emu/op-common.h
@@ -73,7 +73,7 @@ do {
\
X##_c = FP_CLS_NAN; \
/* Check for signaling NaN */ \
if (!(_FP_FRAC_HIGH_RAW_##fs(X) & _FP_QNANBIT_##fs))\
- FP_SET_EXCEPTION(FP_EX_INVALID); \
+ FP_SET_EXCEPTION(FP_EX_INVALID | FP_EX_INVALID_SNAN); \
}
\
break; \
}\
@@ -324,7 +324,7 @@ do {
\
_FP_FRAC_SET_##wc(R, _FP_NANFRAC_##fs); \
R##_s = _FP_NANSIGN_##fs;\
R##_c = FP_CLS_NAN; \
- FP_SET_EXCEPTION(FP_EX_INVALID); \
+ FP_SET_EXCEPTION(FP_EX_INVALID | FP_EX_INVALID_ISI); \
break; \
}
\
/* FALLTHRU */ \
@@ -431,7 +431,7 @@ do {
\
R##_s = _FP_NANSIGN_##fs; \
R##_c = FP_CLS_NAN;\
_FP_FRAC_SET_##wc(R, _FP_NANFRAC_##fs);\
-FP_SET_EXCEPTION(FP_EX_INVALID); \
+FP_SET_EXCEPTION(FP_EX_INVALID | FP_EX_INVALID_IMZ);\
break; \
\
default: \
@@ -490,11 +490,15 @@ do {
\
break; \
\
case _FP_CLS_COMBINE(FP_CLS_INF,FP_CLS_INF): \
+R##_s = _FP_NANSIGN_##fs; \
+R##_c = FP_CLS_NAN;\
+_FP_FRAC_SET_##wc(R, _FP_NANFRAC_##fs);\
+FP_SET_EXCEPTION(FP_EX_INVALID | FP_EX_INVALID_IDI);\
case _FP_CLS_COMBINE(FP_CLS_ZERO,FP_CLS_ZERO): \
R##_s = _FP_NANSIGN_##fs; \
R##_c = FP_CLS_NAN;\
_FP_FRAC_SET_##wc(R, _FP_NANFRAC_##fs);\
-FP_SET_EXCEPTION(FP_EX_INVALID); \
+FP_SET_EXCEPTION(FP_EX_INVALID | FP_EX_INVALID_ZDZ);\
break; \
\
default: \
diff --git a/include/math-emu/soft-fp.h b/include/math-emu/soft-fp.h
index a6f873b..3f284bc 100644
--- a/include/math-emu/soft-fp.h
+++ b/include/math-emu/soft-fp.h
@@ -51,6 +51,25 @@
#ifndef FP_EX_INVALID
#define FP_EX_INVALID 0
#endif
+#ifndef FP_EX_INVALID_SNAN
+#define FP_EX_INVALID_SNAN 0
+#endif
+/* inf - inf */
+#ifndef FP_EX_INVALID_ISI
+#define FP_EX_INVALID_ISI 0
+#endif
+/* inf / inf */
+#ifndef FP_EX_INVALID_IDI
+#define FP_EX_INVALID_IDI 0
+#endif
+/* 0 / 0 */
+#ifndef FP_EX_INVALID_ZDZ
+#define FP_EX_INVALID_ZDZ 0
+#endif
+/* inf * 0 */
+#ifndef FP_EX_INVALID_IMZ
+#define FP_EX_INVALID_IMZ 0
+#endif
#ifndef FP_EX_OVERFLOW
#define FP_EX_OVERFLOW 0
#endif
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] math-emu: Fix compiler warnings
Fix warnings of the form: arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f1' may be used uninitialized in this function arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f0' may be used uninitialized in this function Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- I intend these patches to go via the powerpc.git tree if no one has issues. - k include/math-emu/op-2.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/math-emu/op-2.h b/include/math-emu/op-2.h index e193fb0..4f26ecc 100644 --- a/include/math-emu/op-2.h +++ b/include/math-emu/op-2.h @@ -25,7 +25,7 @@ #ifndef __MATH_EMU_OP_2_H__ #define __MATH_EMU_OP_2_H__ -#define _FP_FRAC_DECL_2(X) _FP_W_TYPE X##_f0, X##_f1 +#define _FP_FRAC_DECL_2(X) _FP_W_TYPE X##_f0 = 0, X##_f1 = 0 #define _FP_FRAC_COPY_2(D,S) (D##_f0 = S##_f0, D##_f1 = S##_f1) #define _FP_FRAC_SET_2(X,I)__FP_FRAC_SET_2(X, I) #define _FP_FRAC_HIGH_2(X) (X##_f1) -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.27' (updated)
Please pull from 'for-2.6.27' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.27 to receive the following updates: This is bug fixes and defconfig updates. I dropped the Kconfig cpm serial patch for 2.6.27 since its not really a bug fix and put it into my powerpc-next branch for .28. (I also moved 2 defconfigs since we were already touching them). - k arch/powerpc/boot/dts/mpc8641_hpcn.dts|2 arch/powerpc/boot/dts/tqm8548-bigflash.dts|8 arch/powerpc/boot/dts/tqm8548.dts |3 arch/powerpc/boot/wrapper |2 arch/powerpc/configs/83xx/asp8347_defconfig | 1334 + arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 188 +- arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 188 +- arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 172 +- arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 176 +- arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 175 +- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 172 +- arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 168 +- arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 172 +- arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 183 +- arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 351 arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 340 arch/powerpc/configs/83xx/sbc834x_defconfig | 239 ++- arch/powerpc/configs/85xx/ksi8560_defconfig | 95 - arch/powerpc/configs/85xx/mpc8536_ds_defconfig| 1654 ++ arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 71 arch/powerpc/configs/85xx/mpc8544_ds_defconfig| 178 +- arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 98 - arch/powerpc/configs/85xx/mpc8568mds_defconfig| 121 + arch/powerpc/configs/85xx/mpc8572_ds_defconfig| 177 +- arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 85 - arch/powerpc/configs/85xx/sbc8548_defconfig | 63 arch/powerpc/configs/85xx/sbc8560_defconfig | 69 arch/powerpc/configs/85xx/stx_gp3_defconfig | 163 +- arch/powerpc/configs/85xx/tqm8540_defconfig | 112 + arch/powerpc/configs/85xx/tqm8541_defconfig | 139 + arch/powerpc/configs/85xx/tqm8548_defconfig | 129 + arch/powerpc/configs/85xx/tqm8555_defconfig | 139 + arch/powerpc/configs/85xx/tqm8560_defconfig | 139 + arch/powerpc/configs/adder875_defconfig | 55 arch/powerpc/configs/asp8347_defconfig| 1214 arch/powerpc/configs/c2k_defconfig| 245 +-- arch/powerpc/configs/ep8248e_defconfig| 198 ++ arch/powerpc/configs/ep88xc_defconfig | 57 arch/powerpc/configs/linkstation_defconfig| 133 + arch/powerpc/configs/mpc7448_hpc2_defconfig | 72 arch/powerpc/configs/mpc8272_ads_defconfig| 132 + arch/powerpc/configs/mpc83xx_defconfig| 389 - arch/powerpc/configs/mpc8536_ds_defconfig | 1637 - arch/powerpc/configs/mpc85xx_defconfig| 207 +- arch/powerpc/configs/mpc8610_hpcd_defconfig | 165 +- arch/powerpc/configs/mpc8641_hpcn_defconfig | 215 +- arch/powerpc/configs/mpc866_ads_defconfig | 61 arch/powerpc/configs/mpc885_ads_defconfig | 57 arch/powerpc/configs/pq2fads_defconfig| 147 + arch/powerpc/configs/prpmc2800_defconfig | 125 + arch/powerpc/configs/sbc8641d_defconfig | 173 +- arch/powerpc/configs/storcenter_defconfig | 113 + arch/powerpc/sysdev/cpm_common.c | 37 arch/powerpc/sysdev/qe_lib/ucc_fast.c |4 arch/powerpc/sysdev/qe_lib/ucc_slow.c |8 55 files changed, 8093 insertions(+), 4656 deletions(-) Kumar Gala (2): powerpc: Fix whitespace merge in mpc8641 hpcn device tree powerpc: Update defconfigs for FSL PPC boards Laurent Pinchart (1): cpm2: Fix race condition in CPM2 GPIO library. Scott Wood (1): powerpc: Add cuImage.mpc866ads to the bootwrapper as a cuboot-8xx target Timur Tabi (1): powerpc: fix memory leaks in QE library Wolfgang Grandegger (1): powerpc/85xx: TQM8548: DTS file fixes and cleanup ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
Stefan Roese wrote: On Thursday 21 August 2008, Sean MacLennan wrote: That's all output from the wrapper, not the kernel. And the kernel config doesn't make a difference at all to the wrapper. I wonder if there is some weird size issue going on there or if whatever U-Boot version you are using is doing odd things... Any chance something in the DTS could affect it? Maybe try commenting out the second IIC controller? Yes, I2C is generally working and should make a difference in Linux kernel booting. It seems that your bootwrapper is somehow not copying the correct MAC address to the device-tree. Not sure what's going wrong here. We usually don't use the bootwrapper but boot the uImage directly from U-Boot on all 4xx systems. You might want to debug the bootwrapper code, if possible drop the bootwrapper and use the uImage with a newer, device-tree enabled U-Boot version. U-boot thinks that all memory above the first 8MB is out of reach for the kernel and puts kernel bootargs and boardinfo structure below 8MB as close as possible to this limit. Including the i2c driver into the kernel increases the kernel image size. So when u-boot unpacks the kernel to 0x40 (Load Address: 0040) it overwrites the kernel parameters. So when the kernel actually starts, it reads zeros instead of boardinfo (and mac addresses) The 8MB limit is set for all AMCC boards in include/configs/amcc-common.h: #define CFG_BOOTMAPSZ (8 << 20) /* Initial Memory map for Linux */ I think this limit is obsolete and can be moved to at least 64MB. But you'll need to rebuild u-boot. Stefan, what do you think? Can we increase the default initial memory map for AMCC boards in the next u-boot release, since u-boot has all memory identity-mapped on ppc 44x? Thanks, Valentine. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add a simple 405EP based board
On Thu, 2008-08-21 at 10:07 +0200, Markus Brunner wrote: > This adds support for a simple ppc405ep board. > At the moment, there are no 405ep boards in arch/powerpc, so this can be used > as a template > for new boards, or migrating them from arch/ppc. > I2c, UART and EMAC are working. PCI could not be tested, so it was not > included in the dts. I plan on adding more 405 board support very soon. When I do, it'll be along the lines of the patch series I just sent out for 44x. There's really no reason to have a per CPU/board file if we can avoid it. Your code is simple enough overall, so I might even use it as a starting point. If I do, I'll certainly give you credit. Though it's incomplete in that you have a DTS that requires something to poke values into it, and nothing readily apparent to do so. A cuImage wrapper is probably warranted here. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] mtd: add OF2PDEV convertor for the NDFC driver
On Thursday 21 August 2008, Sebastian Siewior wrote: > Yes, I heard of it. tglx told me that the IP-Core might show up in > non-IBM HW and it would be better not to drop the platform support. Thomas, any example of that? I would guess that all powerpc and microblaze systems would use the of_platform drivers now, so is there any other architecture that might get an ndfc? Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
New Patchwork beta
Hi all, I've just put up a new beta of patchwork: http://patchwork2.ozlabs.org/ I intend to replace the existing patchwork with the new code, but would like to get it tested first. There aren't many patches in the system at the moment, but it'll receive patches from the relevant lists. I'll also import a set of existing mails tomorrow, to give some sample data to test with. One important note - after beta testing, I'm planning to clear the test database and start from scratch. So, don't go spending too much time updating patches! However, have a play with the new site, let me know what breaks, and any suggestions for changing, and we can work towards a full replacement for the current site. Some differences from the old patchwork: * Patches can now be 'delegated' to other maintainers - this means that maintainers can offload subsystem-specific patches to other maintainers. * Anyone can create an account, and work with bundles, and manage their own patches. * Pagination. No more 10MB patch lists! * Bundles can be made public, allow users to share patchsets * Better filtering interface Project Maintainers: Create an account, then send me your username, and I'll add maintainer privileges to your account. Again, don't go too crazy with the maintaining work, as it'll all be cleared out once we replace patchwork.ozlabs.org Also: bazaar-ng, linux-mtd and linux-embedded folks: are you still using patchwork? Existing patches: After talking to the powerpc maintainers, we've decided that we're going to start with a clean slate, and not import patches from the existing patchwork database. If you'd prefer to keep current patches for your project, let me know. This will be a bit of work, but I'm sure we can work something out. Happy patchworking, Jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] powerpc/cell/oprofile: fix mutex locking for spu-oprofile
On Thu, 2008-08-21 at 10:14 +0200, Arnd Bergmann wrote: > On Thursday 21 August 2008, Paul Mackerras wrote: > > Arnd Bergmann writes: > > > > > Paul, any chance we can still get this into 2.6.27? > > > > Possibly. We'll need a really good explanation for Linus as to why > > this is needed (what regression or serious bug this fixes) and why it > > is late. Can you send me something explaining that? > > The patch does not fix a regression, the spu-oprofile code basically never > worked. With the current code in Linux, samples in the profile buffer > can get corrupted because reader and writer to that buffer use different > locks for accessing it. Actually for me it worked[1] a reasonable amount of the time, enough to be useful. So the spu-oprofile code has always been broken in this way, but it's not always fatal. So the patch doesn't fix a regression, but it fixes a serious user-visible bug, which makes it legit rc4 material IMHO. [1] that was late last year, so possibly a kernel or two ago. 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
On Thursday 21 August 2008, Sean MacLennan wrote: > > That's all output from the wrapper, not the kernel. And the kernel > > config doesn't make a difference at all to the wrapper. I wonder if > > there is some weird size issue going on there or if whatever U-Boot > > version you are using is doing odd things... > > Any chance something in the DTS could affect it? Maybe try commenting > out the second IIC controller? Yes, I2C is generally working and should make a difference in Linux kernel booting. It seems that your bootwrapper is somehow not copying the correct MAC address to the device-tree. Not sure what's going wrong here. We usually don't use the bootwrapper but boot the uImage directly from U-Boot on all 4xx systems. You might want to debug the bootwrapper code, if possible drop the bootwrapper and use the uImage with a newer, device-tree enabled U-Boot version. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add a simple 405EP based board
Hi Markus,
One small nit:
On Thu, 21 Aug 2008 10:07:58 +0200 Markus Brunner <[EMAIL PROTECTED]> wrote:
>
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int __init ppc405ep_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> + if (!of_flat_dt_is_compatible(root, "company,ppc405ep"))
You need to include to use the of_flat ... routines.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpwalGwyPBj9.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allmodconfig in current -mm
Hi Paul, On Thu, 21 Aug 2008 15:01:43 +1000 Paul Mackerras <[EMAIL PROTECTED]> wrote: > > OK. I think we need to export CMO_PrPSP and CMO_SecPSP as well. > (Lovely names. :() These are only used (indirectly) in lparcfg.c which is never a module, so should be OK. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpfRPR65Sm1x.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] mtd: add OF2PDEV convertor for the NDFC driver
* Arnd Bergmann | 2008-08-21 00:40:58 [+0200]: >On Wednesday 20 August 2008, Sebastian Siewior wrote: >> I didn't convert the NDFC driver to support OF because there are >> non-OF-aware platforms with the ndfc chip. >> All settings are mandatory except the oob layout. > >Are you aware of Sean's patch from >http://patchwork.ozlabs.org/linuxppc/patch?id=20183 ? Yes, I heard of it. tglx told me that the IP-Core might show up in non-IBM HW and it would be better not to drop the platform support. > Arnd <>< Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allmodconfig in current -mm
Hi Andrew, On Wed, 20 Aug 2008 18:16:26 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > From: Andrew Morton <[EMAIL PROTECTED]> > > powerpc allmodconfig: > > ERROR: "CMO_PageSize" [arch/powerpc/platforms/pseries/cmm.ko] undefined! > > (needed for 2.6.27) > > Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- > > arch/powerpc/platforms/pseries/setup.c |1 + > 1 file changed, 1 insertion(+) > > diff -puN arch/powerpc/platforms/pseries/setup.c~powerpc-export-cmo_pagesize > arch/powerpc/platforms/pseries/setup.c > --- a/arch/powerpc/platforms/pseries/setup.c~powerpc-export-cmo_pagesize > +++ a/arch/powerpc/platforms/pseries/setup.c > @@ -71,6 +71,7 @@ > int CMO_PrPSP = -1; > int CMO_SecPSP = -1; > unsigned long CMO_PageSize = (ASM_CONST(1) << IOMMU_PAGE_SHIFT); > +EXPORT_SYMBOL(CMO_PageSize); > > int fwnmi_active; /* TRUE if an FWNMI handler is present */ > Added to linux-next for today. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpF3X337Pc4e.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [machdep_calls] IRQ
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 ? At the end of this funtion, IRQ are disable. Is that right ? So who does enable IRQs ? Sorry for all this questions, I am learning the low layer of Linux. 2008/8/21, Michael Ellerman <[EMAIL PROTECTED]>: > > On Thu, 2008-08-21 at 09:13 +0200, Sébastien Chrétien wrote: > > Hello, > > > > What are the constraints in order to implement a irq_init function ? > > > You mean ppc_md.init_IRQ() ? > > If so, it's a hook you can use to setup your interrupt controller. It's > called from init_IRQ() (arch/powerpc/kernel/irq.c), which is called from > start_kernel() (init/main.c). > > Not long after it is called irqs are enabled. I think it is the last > callback into arch code before irqs are enabled. > > When it is called the device tree is unflattened, so you can use the of_ > API. Bootmem is setup so you can use alloc_bootmem(), but you can't > kmalloc yet. ioremap should work. > > > > > What is the aim or get_irq ? Does it retun an information about the > > mask, the states, or... ? > > > The aim of ppc_md.get_irq() ? It's called from do_IRQ() > (arch/powerpc/kernel/irq.c) which is called from assembler in the > appropriate head_x.S > > It just returns the number (virtual number) of the irq that just fired. > If for some reason you took a spurious interrupt it should return > NO_IRQ. > > I'm not sure what you mean about masks or states, someone else might > though. > > 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
