* Re: ppc Floating Point support status
From: Kumar Gala @ 2007-09-05 14:11 UTC (permalink / raw)
To: Ben Buchli; +Cc: linuxppc-dev
In-Reply-To: <200709040940.04801.bbuchli@xes-inc.com>
On Sep 4, 2007, at 9:40 AM, Ben Buchli wrote:
> On Wednesday 22 August 2007 15:52:09 Kumar Gala wrote:
>> On Aug 22, 2007, at 1:37 PM, Ben Buchli wrote:
>>> Hello everybody,
>>> I was wondering what the status was on supporting floating-point
>>> instructions
>>> for the mpc8548. I found the suggested patch:
>>> http://patchwork.ozlabs.org/linuxppc/patch?
>>> order=patch&filter=none&id=9455,
>>> but I'm not sure for what kernel version this is and when it will be
>>> officially supported.
>>>
>>> Thanks a lot for your help!
>>>
>>> Please CC to me (bbuchli at xes-inc.com) as I haven't subscribed to
>>> this list.
>>
>> I thing these are still up in the air based on having some sense of
>> testing related to them.
>>
>> - k
>
> Kumar,
> thanks for getting back with me.
> We're doing some early performance testing on one of our boards
> with an
> mpc8548e. I was wondering if there's a snapshot available that we
> could use
> and maybe do some working/testing on.
> Thanks a lot.
I'm confused as to what you are looking for. Is 2.6.23-rc5 not
sufficient?
- k
^ permalink raw reply
* Re: PCI:cannot allocate resource region 0 of device 0001:01:00.0?
From: Kumar Gala @ 2007-09-05 14:14 UTC (permalink / raw)
To: dnl; +Cc: linuxppc-embedded
In-Reply-To: <F3D55679E1DCFF49A57570501B70475F070D83BB@CL5EXBE04.ad2.softcom.biz>
On Sep 3, 2007, at 8:45 AM, dnl wrote:
>
> Hi all,
>
> I using Montavista kernel for custom MPC8555CDS board and one PCI
> slot on the Board.
>
> When my kernel boots i am getting the following Messages :
>
> PCI: Probing PCI hardware
> PCI: Cannot allocate resource region 0 of device 0001:01:00.0
> PCI: Cannot allocate resource region 1 of device 0001:01:00.0
> PCI: Failed to allocate mem resource #1:80000000@0 for 0001:01:00.
>
> please find attached Kernel boot messages and corresponding pci
> directory after kernel boots.
> could anyone face similar problem?
You'll need to take up MV kernel issues up with MV.
- k
^ permalink raw reply
* [PATCH] pcmcia: Convert io_req_t to use kio_addr_t
From: Olof Johansson @ 2007-09-05 14:27 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, akpm, linux-pcmcia, hch
Convert the io_req_t members to kio_addr_t, to allow use on machines with
more than 16 bits worth of IO port address space (ppc64 in this case,
but it applies to others as well).
Signed-off-by: Olof Johansson <olof@lixom.net>
---
I'm not at home in the PCMCIA stack, so I'd appreciate some extra eyes
on it to avoid regressions. As far as I can tell, the io_req_t structure
is not exported through any userspace interface and only used internally.
This supersedes the earlier (rejected) "increase ioaddr_t to 32-bits"
patch (http://patchwork.ozlabs.org/linuxppc/patch?id=11908) for ppc64,
since with this change that would not be needed.
Thanks,
Olof
diff --git a/drivers/pcmcia/pcmcia_resource.c b/drivers/pcmcia/pcmcia_resource.c
index 0ce39de..585c14b 100644
--- a/drivers/pcmcia/pcmcia_resource.c
+++ b/drivers/pcmcia/pcmcia_resource.c
@@ -65,8 +65,8 @@ extern int ds_pc_debug;
* Special stuff for managing IO windows, because they are scarce
*/
-static int alloc_io_space(struct pcmcia_socket *s, u_int attr, ioaddr_t *base,
- ioaddr_t num, u_int lines)
+static int alloc_io_space(struct pcmcia_socket *s, u_int attr, kio_addr_t *base,
+ kio_addr_t num, u_int lines)
{
int i;
kio_addr_t try, align;
@@ -74,14 +74,14 @@ static int alloc_io_space(struct pcmcia_socket *s, u_int attr, ioaddr_t *base,
align = (*base) ? (lines ? 1<<lines : 0) : 1;
if (align && (align < num)) {
if (*base) {
- ds_dbg(s, 0, "odd IO request: num %#x align %#lx\n",
+ ds_dbg(s, 0, "odd IO request: num %#lx align %#lx\n",
num, align);
align = 0;
} else
while (align && (align < num)) align <<= 1;
}
if (*base & ~(align-1)) {
- ds_dbg(s, 0, "odd IO request: base %#x align %#lx\n",
+ ds_dbg(s, 0, "odd IO request: base %#lx align %#lx\n",
*base, align);
align = 0;
}
@@ -132,8 +132,8 @@ static int alloc_io_space(struct pcmcia_socket *s, u_int attr, ioaddr_t *base,
} /* alloc_io_space */
-static void release_io_space(struct pcmcia_socket *s, ioaddr_t base,
- ioaddr_t num)
+static void release_io_space(struct pcmcia_socket *s, kio_addr_t base,
+ kio_addr_t num)
{
int i;
diff --git a/include/pcmcia/cs.h b/include/pcmcia/cs.h
index d5838c3..657d653 100644
--- a/include/pcmcia/cs.h
+++ b/include/pcmcia/cs.h
@@ -147,11 +147,11 @@ typedef struct config_req_t {
/* For RequestIO and ReleaseIO */
typedef struct io_req_t {
- ioaddr_t BasePort1;
- ioaddr_t NumPorts1;
+ kio_addr_t BasePort1;
+ kio_addr_t NumPorts1;
u_int Attributes1;
- ioaddr_t BasePort2;
- ioaddr_t NumPorts2;
+ kio_addr_t BasePort2;
+ kio_addr_t NumPorts2;
u_int Attributes2;
u_int IOAddrLines;
} io_req_t;
^ permalink raw reply related
* Re: Breakpoint is not hitting for Kernel Debugging
From: Dan Malek @ 2007-09-05 16:31 UTC (permalink / raw)
To: Detlev Zundel; +Cc: linuxppc-embedded
In-Reply-To: <m2wsv58cp1.fsf@ohwell.denx.de>
On Sep 5, 2007, at 6:27 AM, Detlev Zundel wrote:
> Hi,
>
>> ;; Following is to clear the page table base address
>> WM32 0x000000f0 0x00000000
>
> Did you really need this under any circumstance? To only hit a
> breakpoint?
No, you don't. For the identify mapped kernel
space, only the MMU XLAT is required, which
covers nearly all kernel. This is only necessary for
tracking vmalloc()'ed space, like for loadable
modules.
However, this WM32 should not be necessary
in any case, as the page table pointers for
BDI information tracking are set up by the
kernel initialization functions.
> I am asking because recent experiences with BDI debugging showed that
> there are some pitfalls that one can fall into (and these are only the
> ones that I got aware of):
Yes, and I apologize for not allocating the
time to work with Abatron to make this
work better. The page tables changes
that have taken (and still take) place in
2.6 caused our original 2.4 implementation
to not work well. Abatron has made updates
that work well, but there are still some edge
cases that may not work well. I need to find
those and provide some assistance.
The whole of the Linux BDI configuration
has been abused as well, the BDI_SWITCH
should not be used as it is today. That
was not the intention for this particular
configuration option.
> So for the original poster I would say a PTBASE 0x0 would be in
> order.
It changes a little among the processor variants,
in particular traditional Power versus Book E.
Check the release notes and manuals for the
BDI2000, along with the information from
Ultimate Solutions to determine what is best.
> b) Moreover even with a _wrong_ PTBASE on a 440EPx the BDI translated
> start_kernel just fine by only subtracting 0xc0000000 (using a
> "default" translation) - it was only later (debugging dynamic
> modules) that the wrong PTBASE hit me hard.
That's correct. If the BDI firmware can find the
translation in the TLB, it will just use that. In the
case of many processors, this is either a wired
entry or a BAT. If the BDI firmware can't find
a valid translation, it walks the page tables.
For 8xx and some 40x, the PTBASE is required
as there may be no wired entries by default.
Just remember that the values for both MMU XLAT
and PTBASE must match the kernel software and
configuration. This is the only correct answer :-)
Documentation will describe the public source,
default configuration at the time of the writing,
but it's very easy to change and will cause
debugging problems.
Thanks.
-- Dan
^ permalink raw reply
* Re: disable interrput under ppc?
From: Scott Wood @ 2007-09-05 16:31 UTC (permalink / raw)
To: Wang, Baojun; +Cc: linuxppc-embedded
In-Reply-To: <200709051000.46281.wangbj@lzu.edu.cn>
On Wed, Sep 05, 2007 at 10:00:46AM +0800, Wang, Baojun wrote:
> hw_enable_irq() and hw_disable_irq() is exactly the same as
> local_irq_enable()/local_irq_disable(), but the output shows while running
> hw_eable_irq() (at that point irq is disabled), the rest of the code is
> blocked, and I don't know why:
>
> output:
> [ 172.049381] sync_root_events: looping!
> [ 172.053159] sync_root_events: looping 2!
> [ 172.057094] sync_root_events: looping 3!
> [ 172.061027] hw_irq_disabled?: 1
> [ 172.997338] sync_root_events: looping!
> [ 173.001095] sync_root_events: looping 2!
> [ 173.005028] sync_root_events: looping 3!
> [ 173.008961] hw_irq_disabled?: 1
What did you expect the output to be? I assume that you're taking an
interrupt after you enable interrupts?
-Scott
^ permalink raw reply
* [patch 3/6] Walnut DTS
From: Josh Boyer @ 2007-09-05 16:33 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <412bb2e63637100c8d47595a19f888ae@kernel.crashing.org>
Updated DTS below
Device tree source file for the PPC405 Walnut evaluation board.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/dts/walnut.dts | 183 +++++++++++++++++++++++++++++++++++++++
1 file changed, 183 insertions(+)
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/dts/walnut.dts
@@ -0,0 +1,183 @@
+/*
+ * Device Tree Source for IBM Walnut
+ *
+ * Copyright 2007 IBM Corp.
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "ibm,walnut";
+ compatible = "ibm,walnut";
+ dcr-parent = <&/cpus/PowerPC,405GP@0>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,405GP@0 {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <bebc200>; /* Filled in by zImage */
+ timebase-frequency = <0>; /* Filled in by zImage */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <4000>;
+ d-cache-size = <4000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0>; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 9>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ plb {
+ compatible = "ibm,plb3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ SDRAM0: memory-controller {
+ compatible = "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ MAL: mcmal {
+ compatible = "ibm,mcmal-405gp", "ibm,mcmal";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <1>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <a 4 b 4 c 4 d 4 e 4>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-405gp", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <ef600000 ef600000 a00000>;
+ dcr-reg = <0a0 5>;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ current-speed = <2580>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ current-speed = <2580>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ IIC: i2c@ef600500 {
+ compatible = "ibm,iic-405gp", "ibm,iic";
+ reg = <ef600500 11>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ GPIO: gpio@ef600700 {
+ compatible = "ibm,gpio-405gp";
+ reg = <ef600700 20>;
+ };
+
+ EMAC: ethernet@ef600800 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-405gp", "ibm,emac";
+ interrupt-parent = <&UIC0>;
+ interrupts = <9 4 f 4>;
+ reg = <ef600800 70>;
+ mal-device = <&MAL>;
+ mal-tx-channel = <0 1>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rmii";
+ phy-map = <00000001>;
+ };
+
+ };
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-405gp", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ sram@0,0 {
+ reg = <0 0 80000>;
+ };
+
+ flash@0,80000 {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ probe-type = "JEDEC";
+ bank-width = <1>;
+ partitions = <0 80000>;
+ partition-names = "OpenBIOS";
+ reg = <0 80000 80000>;
+ };
+
+ ds1743@1,0 {
+ /* NVRAM and RTC */
+ compatible = "ds1743";
+ reg = <1 0 2000>;
+ };
+
+ keyboard@2,0 {
+ compatible = "intel,82C42PC";
+ reg = <2 0 2>;
+ };
+
+ ir@3,0 {
+ compatible = "ti,TIR2000PAG";
+ reg = <3 0 10>;
+ };
+
+ fpga@7,0 {
+ compatible = "Walnut-FPGA";
+ reg = <7 0 10>;
+ virtual-reg = <f0300005>;
+ };
+ };
+ };
+
+ chosen {
+ linux,stdout-path = "/plb/opb/serial@ef600300";
+ };
+};
^ permalink raw reply
* [patch 6/6] Walnut zImage wrapper
From: Josh Boyer @ 2007-09-05 16:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <1188741519.3772.3.camel@localhost.localdomain>
Updated patch below
Add zImage wrapper for walnut board
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/Makefile | 3
arch/powerpc/boot/dcr.h | 5 +
arch/powerpc/boot/treeboot-walnut.c | 131 ++++++++++++++++++++++++++++++++++++
3 files changed, 138 insertions(+), 1 deletion(-)
--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -49,7 +49,7 @@ src-wlib := string.S crt0.S stdio.c main
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-bamboo.c
+ cuboot-pq2.c cuboot-bamboo.c treeboot-walnut.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -147,6 +147,7 @@ image-$(CONFIG_PPC_83xx) += cuImage.83x
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
+image-$(CONFIG_WALNUT) += treeImage.walnut
endif
# For 32-bit powermacs, build the COFF and miboot images
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/treeboot-walnut.c
@@ -0,0 +1,131 @@
+/*
+ * Old U-boot compatibility for Walnut
+ *
+ * Author: Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * Copyright 2007 IBM Corporation
+ * Based on cuboot-83xx.c, which is:
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "dcr.h"
+#include "4xx.h"
+#include "io.h"
+
+BSS_STACK(4096);
+
+void ibm405gp_fixup_clocks(unsigned int sysclk, unsigned int ser_clk)
+{
+ u32 pllmr = mfdcr(DCRN_CPC0_PLLMR);
+ u32 cpc0_cr0 = mfdcr(DCRN_405_CPC0_CR0);
+ u32 cpc0_cr1 = mfdcr(DCRN_405_CPC0_CR1);
+ u32 cpu, plb, opb, ebc, tb, uart0, uart1, m;
+ u32 fwdv, fbdv, cbdv, opdv, epdv, udiv;
+
+ fwdv = (8 - ((pllmr & 0xe0000000) >> 29));
+ fbdv = (pllmr & 0x1e000000) >> 25;
+ cbdv = ((pllmr & 0x00060000) >> 17) + 1;
+ opdv = ((pllmr & 0x00018000) >> 15) + 1;
+ epdv = ((pllmr & 0x00001800) >> 13) + 2;
+ udiv = ((cpc0_cr0 & 0x3e) >> 1) + 1;
+
+ m = fwdv * fbdv * cbdv;
+
+ cpu = sysclk * m / fwdv;
+ plb = cpu / cbdv;
+ opb = plb / opdv;
+ ebc = plb / epdv;
+
+ if (cpc0_cr0 & 0x80) {
+ /* uart0 uses the external clock */
+ uart0 = ser_clk;
+ } else {
+ uart0 = cpu / udiv;
+ }
+
+ if (cpc0_cr0 & 0x40) {
+ /* uart1 uses the external clock */
+ uart1 = ser_clk;
+ } else {
+ uart1 = cpu / udiv;
+ }
+
+ /* setup the timebase clock to tick at the cpu frequency */
+ cpc0_cr1 = cpc0_cr1 & ~ 0x00800000;
+ mtdcr(DCRN_CPC0_CR1, cpc0_cr1);
+ tb = cpu;
+
+ dt_fixup_cpu_clocks(cpu, tb, 0);
+ dt_fixup_clock("/plb", plb);
+ dt_fixup_clock("/plb/opb", opb);
+ dt_fixup_clock("/plb/ebc", ebc);
+ dt_fixup_clock("/plb/opb/serial@ef600300", uart0);
+ dt_fixup_clock("/plb/opb/serial@ef600400", uart1);
+}
+
+static void walnut_flashsel_fixup(void)
+{
+ void *devp, *sram;
+ u32 reg_flash[3] = {0x0, 0x0, 0x80000};
+ u32 reg_sram[3] = {0x0, 0x0, 0x80000};
+ u8 *fpga;
+ u8 fpga_brds1 = 0x0;
+
+ devp = finddevice("/plb/ebc/fpga");
+ if (!devp)
+ fatal("Couldn't locate FPGA node\n\r");
+
+ if (getprop(devp, "virtual-reg", &fpga, sizeof(fpga)) != sizeof(fpga))
+ fatal("no virtual-reg property\n\r");
+
+ fpga_brds1 = in_8(fpga);
+
+ devp = finddevice("/plb/ebc/flash");
+ if (!devp)
+ fatal("Couldn't locate flash node\n\r");
+
+ if (getprop(devp, "reg", reg_flash, sizeof(reg_flash)) != sizeof(reg_flash))
+ fatal("flash reg property has unexpected size\n\r");
+
+ sram = finddevice("/plb/ebc/sram");
+ if (!sram)
+ fatal("Couldn't locate sram node\n\r");
+
+ if (getprop(sram, "reg", reg_sram, sizeof(reg_sram)) != sizeof(reg_sram))
+ fatal("sram reg property has unexpected size\n\r");
+
+ if (fpga_brds1 & 0x1) {
+ reg_flash[1] ^= 0x80000;
+ reg_sram[1] ^= 0x80000;
+ }
+
+ setprop(devp, "reg", reg_flash, sizeof(reg_flash));
+ setprop(sram, "reg", reg_sram, sizeof(reg_sram));
+}
+
+static void walnut_fixups(void)
+{
+ ibm4xx_fixup_memsize();
+ ibm405gp_fixup_clocks(33330000, 0xa8c000);
+ ibm4xx_quiesce_eth((u32 *)0xef600800, NULL);
+ ibm4xx_fixup_ebc_ranges("/plb/ebc");
+ walnut_flashsel_fixup();
+}
+
+void platform_init(void)
+{
+ unsigned long end_of_ram = 0x2000000;
+ unsigned long avail_ram = end_of_ram - (unsigned long) _end;
+
+ simple_alloc_init(_end, avail_ram, 32, 32);
+ platform_ops.fixups = walnut_fixups;
+ platform_ops.exit = ibm40x_dbcr_reset;
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ serial_console_init();
+}
--- linux-2.6.orig/arch/powerpc/boot/dcr.h
+++ linux-2.6/arch/powerpc/boot/dcr.h
@@ -134,4 +134,9 @@ static const unsigned long sdram_bxcr[]
#define CPR0_SCPID 0x120
#define CPR0_PLLC0 0x40
+/* 405GP Clocking/Power Management/Chip Control regs */
+#define DCRN_CPC0_PLLMR 0xb0
+#define DCRN_405_CPC0_CR0 0xb1
+#define DCRN_405_CPC0_CR1 0xb2
+
#endif /* _PPC_BOOT_DCR_H_ */
^ permalink raw reply
* [patch 2/6] cuimage for Bamboo board
From: Josh Boyer @ 2007-09-05 16:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <1188971635.3223.9.camel@localhost.localdomain>
Updated patch below. NOTE: This relies on Scott Wood's strtoull patch
as PIBS stores the MAC addresses as ASCII strings in flash.
Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
linker declarations that have been moved into ops.h
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/44x.h | 2 +-
arch/powerpc/boot/Makefile | 5 +++--
arch/powerpc/boot/bamboo.c | 8 +++++---
arch/powerpc/boot/cuboot-bamboo.c | 30 ++++++++++++++++++++++++++++++
arch/powerpc/boot/treeboot-bamboo.c | 22 +++++++++++++++++++---
5 files changed, 58 insertions(+), 9 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -48,7 +48,8 @@ src-wlib := string.S crt0.S stdio.c main
cpm-serial.c stdlib.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
- ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c cuboot-pq2.c
+ ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
+ cuboot-pq2.c cuboot-bamboo.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -145,7 +146,7 @@ image-$(CONFIG_8260) += cuImage.pq2
image-$(CONFIG_PPC_83xx) += cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
-image-$(CONFIG_BAMBOO) += treeImage.bamboo
+image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
endif
# For 32-bit powermacs, build the COFF and miboot images
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/cuboot-bamboo.c
@@ -0,0 +1,30 @@
+/*
+ * Old U-boot compatibility for Ebony
+ *
+ * Author: Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * Copyright 2007 IBM Corporation
+ *
+ * Based on cuboot-ebony.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "44x.h"
+#include "cuboot.h"
+
+#define TARGET_44x
+#include "ppcboot.h"
+
+static bd_t bd;
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ bamboo_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
+}
--- linux-2.6.orig/arch/powerpc/boot/44x.h
+++ linux-2.6/arch/powerpc/boot/44x.h
@@ -11,6 +11,6 @@
#define _PPC_BOOT_44X_H_
void ebony_init(void *mac0, void *mac1);
-void bamboo_init(void);
+void bamboo_init(void *mac0, void *mac1);
#endif /* _PPC_BOOT_44X_H_ */
--- linux-2.6.orig/arch/powerpc/boot/bamboo.c
+++ linux-2.6/arch/powerpc/boot/bamboo.c
@@ -24,8 +24,7 @@
#include "4xx.h"
#include "44x.h"
-extern char _dtb_start[];
-extern char _dtb_end[];
+static u8 *bamboo_mac0, *bamboo_mac1;
static void bamboo_fixups(void)
{
@@ -34,12 +33,15 @@ static void bamboo_fixups(void)
ibm440ep_fixup_clocks(sysclk, 11059200);
ibm4xx_fixup_memsize();
ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
+ dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
}
-void bamboo_init(void)
+void bamboo_init(void *mac0, void *mac1)
{
platform_ops.fixups = bamboo_fixups;
platform_ops.exit = ibm44x_dbcr_reset;
+ bamboo_mac0 = mac0;
+ bamboo_mac1 = mac1;
ft_init(_dtb_start, 0, 32);
serial_console_init();
}
--- linux-2.6.orig/arch/powerpc/boot/treeboot-bamboo.c
+++ linux-2.6/arch/powerpc/boot/treeboot-bamboo.c
@@ -12,16 +12,32 @@
#include "ops.h"
#include "stdio.h"
#include "44x.h"
-
-extern char _end[];
+#include "stdlib.h"
BSS_STACK(4096);
+#define PIBS_MAC0 0xfffc0400
+#define PIBS_MAC1 0xfffc0500
+char pibs_mac0[6];
+char pibs_mac1[6];
+
+static void read_pibs_mac(void)
+{
+ unsigned long long mac64;
+
+ mac64 = strtoull((char *)PIBS_MAC0, 0, 16);
+ memcpy(&pibs_mac0, (char *)&mac64+2, 6);
+
+ mac64 = strtoull((char *)PIBS_MAC1, 0, 16);
+ memcpy(&pibs_mac1, (char *)&mac64+2, 6);
+}
+
void platform_init(void)
{
unsigned long end_of_ram = 0x8000000;
unsigned long avail_ram = end_of_ram - (unsigned long)_end;
simple_alloc_init(_end, avail_ram, 32, 64);
- bamboo_init();
+ read_pibs_mac();
+ bamboo_init((u8 *)&pibs_mac0, (u8 *)&pibs_mac1);
}
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Andrew Morton @ 2007-09-05 17:07 UTC (permalink / raw)
To: Tim Teulings, Stefan Richter
Cc: michal.k.k.piotrowski, rbrito, linux-kernel, rjw, linuxppc-dev,
debian-powerpc, linux-pm
In-Reply-To: <46D72BC6.3020809@edge.ping.de>
> On 30 Aug 2007 22:42:46 +0200 "Tim Teulings" <rael@edge.ping.de> wrote:
> Hello!
>
> > I don't have traces at hand and due to lack of time cannot reproduce it
> > up to tomorrow. However this hint may speed up your analysis!
>
> Sorry for the delay, but my desktop PC had an urgent hard disk problem I
> had to fix ASASP.
>
> So here is the output from dmesg that suggested to me that firewire
> might be a problem:
Straightforward regression, two reporters, nothing happening.
> > usb_endpoint usbdev2.2_ep81: PM: suspend 0->2, parent 2-1:1.0 already 2
> > usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
> > usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
> > hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
> > usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
> > eth2: Airport entering sleep mode
> > eth0: suspending, WakeOnLan disabled
> > pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
> > firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
> > suspend_device(): pci_device_suspend+0x0/0x98() returns -22
> > Could not suspend device 0002:20:0e.0: error -22
> > eth0: resuming
> > PHY ID: 4061e4, addr: 0
> > eth2: Airport waking up
> > eth2: New link status: Connected (0001)
> > hda: Enabling Ultra DMA 2
> > eth0: Link is up at 100 Mbps, full-duplex.
> > eth0: Pause is disabled
> > ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > hdb: Enabling Ultra DMA 2
> > usb_endpoint usbdev1.1_ep00: PM: resume from 0, parent usb1 still 2
> > usb_endpoint usbdev1.1_ep81: PM: resume from 0, parent 1-0:1.0 still 2
> > usb_device usbdev1.1: PM: resume from 0, parent usb1 still 2
> > Driver sleep failed
> > Sleep rejected by devices
> > adb: starting probe task...
> > adb devices: [2]: 2 c4 [3]: 3 1 [7]: 7 1f
> > ADB keyboard at 2, handler 1
> > ADB mouse at 3, handler set to 4 (trackpad)
> > adb: finished probe task...
> > usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
> > usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
> > hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
> > usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
> > eth2: Airport entering sleep mode
> > eth0: suspending, WakeOnLan disabled
> > Trying to free already-free IRQ 40
> > pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
> > firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
I grepped the whole tree for firewire_ohci and came up blank. What is it?
But yes, a failed pci_set_power_state() will hurt. Perhaps this is
a result of some recently-added return-value checking fix but as I
cannot find the dang code I cannot tell.
> > suspend_device(): pci_device_suspend+0x0/0x98() returns -22
> > Could not suspend device 0002:20:0e.0: error -22
> > eth0: resuming
> > PHY ID: 4061e4, addr: 0
> > eth2: Airport waking up
> > eth2: New link status: Connected (0001)
> > hda: Enabling Ultra DMA 2
> > hdb: Enabling Ultra DMA 2
> > eth0: Link is up at 100 Mbps, full-duplex.
> > eth0: Pause is disabled
>
> The problem wa sinitiated by closing the lid. The iBook then seems to
> permanetly try to go to sleep (I can hear the cd-rom drive get
> periodically initialized). So above contains more than one iteration.
>
> The kernel is:
> > Linux kismet 2.6.22-1-powerpc #1 Sun Jul 29 13:58:06 CEST 2007 ppc GNU/Linux
>
> The relveant debian package:
> > linux-image-2.6.22-1-powerpc_2.6.22-3_powerpc.deb
>
> I'm running a mixture of debian testing/unstable.
>
> The firewire and the USB connector were unused, the network connector
> was used.
>
> If there are questions regarding other packages, or somebody wants me to
> test a fix (I would prever a debian package), don't hesitate - I would
> like to get the bug fixed :-)
>
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add PCI support for AMCC 440EPx (sequoia)
From: Valentine Barshak @ 2007-09-05 17:28 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070825093001.4087.18160.stgit@localhost.localdomain>
Vitaly Bordug wrote:
> In fact, loosely move of arch/ppc bits, though regions are
> set up using values from ranges property. This also adds
> setup_indirect_pci_noremap() function to handle indirect
> PCI without one more ioremap.
>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> ---
>
> arch/powerpc/platforms/44x/44x.h | 28 ++++
> arch/powerpc/platforms/44x/Makefile | 4 +
> arch/powerpc/platforms/44x/ppc440epx-pci.c | 192 ++++++++++++++++++++++++++++
> arch/powerpc/platforms/44x/sequoia.c | 14 ++
> arch/powerpc/sysdev/indirect_pci.c | 14 ++
> include/asm-powerpc/pci-bridge.h | 2
> 6 files changed, 254 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/44x/44x.h b/arch/powerpc/platforms/44x/44x.h
> index 42eabf8..d3845f9 100644
> --- a/arch/powerpc/platforms/44x/44x.h
> +++ b/arch/powerpc/platforms/44x/44x.h
> @@ -1,8 +1,36 @@
> #ifndef __POWERPC_PLATFORMS_44X_44X_H
> #define __POWERPC_PLATFORMS_44X_44X_H
> +#include <asm/pci-bridge.h>
> +
> +/* PCI support */
> +#define PPC4xx_PCI_CFGA_OFFSET 0
> +#define PPC4xx_PCI_CFGD_OFFSET 0x4
> +
> +#define PPC4xx_PCIL0_PMM0LA 0x000
> +#define PPC4xx_PCIL0_PMM0MA 0x004
> +#define PPC4xx_PCIL0_PMM0PCILA 0x008
> +#define PPC4xx_PCIL0_PMM0PCIHA 0x00C
> +#define PPC4xx_PCIL0_PMM1LA 0x010
> +#define PPC4xx_PCIL0_PMM1MA 0x014
> +#define PPC4xx_PCIL0_PMM1PCILA 0x018
> +#define PPC4xx_PCIL0_PMM1PCIHA 0x01C
> +#define PPC4xx_PCIL0_PMM2LA 0x020
> +#define PPC4xx_PCIL0_PMM2MA 0x024
> +#define PPC4xx_PCIL0_PMM2PCILA 0x028
> +#define PPC4xx_PCIL0_PMM2PCIHA 0x02C
> +#define PPC4xx_PCIL0_PTM1MS 0x030
> +#define PPC4xx_PCIL0_PTM1LA 0x034
> +#define PPC4xx_PCIL0_PTM2MS 0x038
> +#define PPC4xx_PCIL0_PTM2LA 0x03C
>
> extern u8 as1_readb(volatile u8 __iomem *addr);
> extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
> extern void ppc44x_reset_system(char *cmd);
>
> +#ifdef CONFIG_PCI
> +int ppc440epx_exclude_device(struct pci_controller *hose,
> + u_char bus, u_char devfn);
> +int ppc440epx_add_bridge(struct device_node *dev);
> +#endif
> +
> #endif /* __POWERPC_PLATFORMS_44X_44X_H */
> diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
> index 10ce674..d2a5278 100644
> --- a/arch/powerpc/platforms/44x/Makefile
> +++ b/arch/powerpc/platforms/44x/Makefile
> @@ -2,3 +2,7 @@ obj-$(CONFIG_44x) := misc_44x.o
> obj-$(CONFIG_EBONY) += ebony.o
> obj-$(CONFIG_BAMBOO) += bamboo.o
> obj-$(CONFIG_SEQUOIA) += sequoia.o
> +
> +ifeq ($(CONFIG_PCI),y)
> +obj-$(CONFIG_440EPX) += ppc440epx-pci.o
> +endif
> diff --git a/arch/powerpc/platforms/44x/ppc440epx-pci.c b/arch/powerpc/platforms/44x/ppc440epx-pci.c
> new file mode 100644
> index 0000000..bd4a352
> --- /dev/null
> +++ b/arch/powerpc/platforms/44x/ppc440epx-pci.c
> @@ -0,0 +1,192 @@
> +/*
> + * PPC44x PCI host support
> + *
> + * Vitaly Bordug <vitb@kernel.crashing.org>
> + * Stefan Roese <sr@denx.de>
> + *
> + * Based on arch/ppc sequoia pci bits, that are
> + * Copyright 2006-2007 DENX Software Engineering, Stefan Roese <sr@denx.de>
> + *
> + * Based on bamboo.c from Wade Farnsworth <wfarnsworth@mvista.com>
> + * Copyright 2004 MontaVista Software Inc.
> + * Copyright 2006 AMCC
> + * 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.
> + */
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/pci.h>
> +#include <linux/delay.h>
> +#include <linux/irq.h>
> +#include <linux/module.h>
> +#include <linux/io.h>
> +
> +#include <mm/mmu_decl.h>
> +
> +#include <asm/system.h>
> +#include <asm/atomic.h>
> +#include <asm/pci-bridge.h>
> +#include <asm/prom.h>
> +
> +#include "44x.h"
> +
> +#undef DEBUG
> +
> +#ifdef DEBUG
> +#define DBG(x...) printk(x)
> +#else
> +#define DBG(x...)
> +#endif
> +
> +#ifdef CONFIG_PCI
> +
> +int ppc440epx_exclude_device(struct pci_controller *hose, u_char bus,
> + u_char devfn)
> +{
> + if ((bus == hose->first_busno) && PCI_SLOT(devfn) == 0)
> + return PCIBIOS_DEVICE_NOT_FOUND;
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> +inline void pci_writel(void *pci_reg_base, u32 offset, unsigned int val)
> +{
> + writel(val, pci_reg_base + offset);
> +}
> +
> +inline void pci_cfg_out(void *cfg, u32 offset, unsigned int value)
> +{
> + out_le32((void *)((u32) cfg + offset), value);
> +}
> +
> +inline u32 pci_cfg_in(void *cfg, u32 offset)
> +{
> + return in_le32((void *)((u32) cfg + offset));
> +}
> +
> +static void __init ppc440epx_setup_pci(struct pci_controller *hose,
> + void *pci_reg_base, void *pci_cfg_base)
> +{
> + unsigned long memory_size, pci_size = 0;
> + phys_addr_t pci_phys_base = 0;
> + phys_addr_t pci_pci_base = 0;
> + int i;
> +
> + memory_size = total_memory;
> +
> + /*
> + * 440EPx has single memory region, we'll use it to configure phb
> + */
> + for (i = 0; i < 3; i++)
> + if (hose->mem_resources[i].start) {
> + pci_phys_base = hose->mem_resources[i].start;
> + pci_pci_base = pci_phys_base - hose->pci_mem_offset;
> + pci_size =
> + hose->mem_resources[i].end -
> + hose->mem_resources[i].start;
> + }
> +
> + if (pci_phys_base == 0) {
> + printk(KERN_ERR "PHB bridge memory region is not defined!\n");
> + return;
> + }
> +
> + pci_cfg_out(pci_cfg_base, PPC4xx_PCI_CFGA_OFFSET,
> + (pci_pci_base & 0xFFFFFFFF) | (PCI_COMMAND & 0xfc));
> + pci_cfg_out(pci_cfg_base, PPC4xx_PCI_CFGD_OFFSET,
> + (pci_cfg_in(pci_cfg_base, PPC4xx_PCI_CFGD_OFFSET) |
> + PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER));
> +
> + /* Disable region first */
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM0MA, 0);
> +
> + /* PLB starting addr: 0x0000000180000000
> + * We need just lower word to get the things work
> + */
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM0LA,
> + pci_phys_base & 0xFFFFFFFF);
> +
> + /* PCI start addr, 0x80000000 (PCI Address) */
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM0PCILA,
> + pci_pci_base & 0xFFFFFFFF);
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM0PCIHA, 0);
> +
> + /* Enable no pre-fetch, enable region */
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM0MA,
> + ((0xffffffff - pci_size) | 0x01));
> +
> + /* Disable region one */
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM1MA, 0);
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM1LA, 0);
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM1PCILA, 0);
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM1PCIHA, 0);
> +
> + /* Disable region two */
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM1MA, 0);
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM1LA, 0);
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM1PCILA, 0);
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PMM1PCIHA, 0);
> +
> + /* Now configure the PCI->PLB windows, we only use PTM1
> + *
> + * For Inbound flow, set the window size to all available memory
> + * This is required because if size is smaller,
> + * then Eth/PCI DD would fail as PCI card not able to access
> + * the memory allocated by DD.
> + */
> +
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PTM1MS, 0);
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PTM1LA, 0);
> +
> + memory_size = 1 << fls(memory_size - 1);
> +
> + /* Size low + Enabled */
> + pci_writel(pci_reg_base, PPC4xx_PCIL0_PTM1MS,
> + (0xffffffff - (memory_size - 1)) | 0x1);
> + eieio();
> +}
> +
> +int __init ppc440epx_add_bridge(struct device_node *dev)
> +{
> + int len;
> + struct pci_controller *hose;
> + const int *bus_range;
> + int primary = 1;
> + void *reg, *cfg;
> +
> + /* Fetch host bridge registers address */
> + reg = of_iomap(dev, 1);
> + cfg = of_iomap(dev, 0);
> +
> + DBG("Adding PCI host bridge %s\n reg %p cfg %p\n", dev->full_name, reg,
> + cfg);
> +
> + /* Get bus range if any */
> + bus_range = of_get_property(dev, "bus-range", &len);
> + if (bus_range == NULL || len < 2 * sizeof(int))
> + printk(KERN_WARNING "Can't get bus-range for %s, assume"
> + " bus 0\n", dev->full_name);
> +
> + pci_assign_all_buses = 1;
> + hose = pcibios_alloc_controller(dev);
> + if (!hose)
> + return -ENOMEM;
> +
> + hose->first_busno = bus_range ? bus_range[0] : 0;
> + hose->last_busno = bus_range ? bus_range[1] : 0xff;
> +
> + setup_indirect_pci_noremap(hose, (u32) cfg,
> + (u32) (cfg + PPC4xx_PCI_CFGD_OFFSET), 0);
> +
> + /* Interpret the "ranges" property */
> + /* This also maps the I/O region and sets isa_io/mem_base */
> + pci_process_bridge_OF_ranges(hose, dev, primary);
> + ppc440epx_setup_pci(hose, reg, cfg);
> +
> + return 0;
> +}
> +#endif
> diff --git a/arch/powerpc/platforms/44x/sequoia.c b/arch/powerpc/platforms/44x/sequoia.c
> index ca3c9cc..c3a638b 100644
> --- a/arch/powerpc/platforms/44x/sequoia.c
> +++ b/arch/powerpc/platforms/44x/sequoia.c
> @@ -52,6 +52,20 @@ static int __init sequoia_probe(void)
>
> static void __init sequoia_setup_arch(void)
> {
> +#ifdef CONFIG_PCI
> + struct device_node *np;
> +#endif
> +
> + if (ppc_md.progress)
> + ppc_md.progress("ppc44x_setup_arch()", 0);
> +
> +#ifdef CONFIG_PCI
> + for (np = NULL; (np = of_find_compatible_node(np,
> + "pci", "ibm, 440epx")) != NULL;)
> + ppc440epx_add_bridge(np);
> + ppc_md.pci_exclude_device = ppc440epx_exclude_device;
> +#endif
> +
> }
>
> define_machine(sequoia) {
> diff --git a/arch/powerpc/sysdev/indirect_pci.c b/arch/powerpc/sysdev/indirect_pci.c
> index b5d0682..9dab751 100644
> --- a/arch/powerpc/sysdev/indirect_pci.c
> +++ b/arch/powerpc/sysdev/indirect_pci.c
> @@ -162,3 +162,17 @@ setup_indirect_pci(struct pci_controller* hose, u32 cfg_addr, u32 cfg_data, u32
> hose->ops = &indirect_pci_ops;
> hose->indirect_type = flags;
> }
> +
> +/*
> + * For some reason, ioremap does not handle 2-nd way mapping well,
> + * causing system check while trying to access config space later
> + */
> +void __init
> +setup_indirect_pci_noremap(struct pci_controller *hose, u32 cfg_addr,
> + u32 cfg_data, u32 flags)
> +{
> + hose->cfg_addr = (void *)cfg_addr;
> + hose->cfg_data = (void *)cfg_data;
> + hose->ops = &indirect_pci_ops;
> + hose->indirect_type = flags;
> +}
> diff --git a/include/asm-powerpc/pci-bridge.h b/include/asm-powerpc/pci-bridge.h
> index e909769..4bde6e5 100644
> --- a/include/asm-powerpc/pci-bridge.h
> +++ b/include/asm-powerpc/pci-bridge.h
> @@ -99,6 +99,8 @@ extern int early_find_capability(struct pci_controller *hose, int bus,
>
> extern void setup_indirect_pci(struct pci_controller* hose,
> u32 cfg_addr, u32 cfg_data, u32 flags);
> +extern void setup_indirect_pci_noremap(struct pci_controller *hose,
> + u32 cfg_addr, u32 cfg_data, u32 flags);
> extern void setup_grackle(struct pci_controller *hose);
> extern void __init update_bridge_resource(struct pci_dev *dev,
> struct resource *res);
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
The patches seem to work fine on Sequoia, just
pci_iomap() function has to be fixed to support 64-bit resources.
I'll submit a couple of patches soon.
Thanks,
Valentine.
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Randy Dunlap @ 2007-09-05 17:28 UTC (permalink / raw)
To: Andrew Morton
Cc: debian-powerpc, michal.k.k.piotrowski, rbrito, linux-kernel, rjw,
linuxppc-dev, Stefan Richter, linux-pm, Tim Teulings
In-Reply-To: <20070905100754.57ab4e3e.akpm@linux-foundation.org>
On Wed, 5 Sep 2007 10:07:54 -0700 Andrew Morton wrote:
> > On 30 Aug 2007 22:42:46 +0200 "Tim Teulings" <rael@edge.ping.de> wrote:
> > Hello!
> >
> > > I don't have traces at hand and due to lack of time cannot reproduce it
> > > up to tomorrow. However this hint may speed up your analysis!
> >
> > Sorry for the delay, but my desktop PC had an urgent hard disk problem I
> > had to fix ASASP.
> >
> > So here is the output from dmesg that suggested to me that firewire
> > might be a problem:
>
> Straightforward regression, two reporters, nothing happening.
(material for ksummit discussion, e.g.)
> > > usb_endpoint usbdev2.2_ep81: PM: suspend 0->2, parent 2-1:1.0 already 2
> > > usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
> > > usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
> > > hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
> > > usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
> > > eth2: Airport entering sleep mode
> > > eth0: suspending, WakeOnLan disabled
> > > pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
> > > firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
> > > suspend_device(): pci_device_suspend+0x0/0x98() returns -22
> > > Could not suspend device 0002:20:0e.0: error -22
> > > eth0: resuming
> > > PHY ID: 4061e4, addr: 0
> > > eth2: Airport waking up
> > > eth2: New link status: Connected (0001)
> > > hda: Enabling Ultra DMA 2
> > > eth0: Link is up at 100 Mbps, full-duplex.
> > > eth0: Pause is disabled
> > > ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > > hdb: Enabling Ultra DMA 2
> > > usb_endpoint usbdev1.1_ep00: PM: resume from 0, parent usb1 still 2
> > > usb_endpoint usbdev1.1_ep81: PM: resume from 0, parent 1-0:1.0 still 2
> > > usb_device usbdev1.1: PM: resume from 0, parent usb1 still 2
> > > Driver sleep failed
> > > Sleep rejected by devices
> > > adb: starting probe task...
> > > adb devices: [2]: 2 c4 [3]: 3 1 [7]: 7 1f
> > > ADB keyboard at 2, handler 1
> > > ADB mouse at 3, handler set to 4 (trackpad)
> > > adb: finished probe task...
> > > usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
> > > usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
> > > hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
> > > usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
> > > eth2: Airport entering sleep mode
> > > eth0: suspending, WakeOnLan disabled
> > > Trying to free already-free IRQ 40
> > > pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
> > > firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
>
> I grepped the whole tree for firewire_ohci and came up blank. What is it?
See drivers/firewire/Makefile
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* [PATCH] PowerPC: Add 64-bit resources support to pci_iomap
From: Valentine Barshak @ 2007-09-05 17:30 UTC (permalink / raw)
To: linuxppc-dev
The patch adds support for the 64-bit resources to the PCI
iomap code.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
--- linux-2.6.orig/arch/powerpc/kernel/iomap.c 2007-09-04 21:15:13.000000000 +0400
+++ linux-2.6.bld/arch/powerpc/kernel/iomap.c 2007-09-05 21:06:39.000000000 +0400
@@ -119,8 +119,8 @@
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
{
- unsigned long start = pci_resource_start(dev, bar);
- unsigned long len = pci_resource_len(dev, bar);
+ resource_size_t start = pci_resource_start(dev, bar);
+ resource_size_t len = pci_resource_len(dev, bar);
unsigned long flags = pci_resource_flags(dev, bar);
if (!len)
^ permalink raw reply
* [PATCH] PCI e100 interrupt quirk fix
From: Valentine Barshak @ 2007-09-05 17:31 UTC (permalink / raw)
To: linuxppc-dev
PCI memory space may have a 64-bit offset on some architectures
and the actual PCI memory address has to fixed up before remapping.
So, pci_iomap should be used instead of reading and remapping PCI BAR
directly.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
--- linux-2.6.orig/drivers/pci/quirks.c 2007-09-04 21:15:43.000000000 +0400
+++ linux-2.6.bld/drivers/pci/quirks.c 2007-09-05 20:46:14.000000000 +0400
@@ -1432,9 +1432,9 @@
static void __devinit quirk_e100_interrupt(struct pci_dev *dev)
{
u16 command;
- u32 bar;
u8 __iomem *csr;
u8 cmd_hi;
+ int rc;
switch (dev->device) {
/* PCI IDs taken from drivers/net/e100.c */
@@ -1464,16 +1464,17 @@
* re-enable them when it's ready.
*/
pci_read_config_word(dev, PCI_COMMAND, &command);
- pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &bar);
- if (!(command & PCI_COMMAND_MEMORY) || !bar)
+ rc = pci_request_region(dev, 0, "e100_quirk");
+
+ if (!(command & PCI_COMMAND_MEMORY) || (rc < 0))
return;
- csr = ioremap(bar, 8);
+ csr = pci_iomap(dev, 0, 8);
if (!csr) {
printk(KERN_WARNING "PCI: Can't map %s e100 registers\n",
pci_name(dev));
- return;
+ goto e100_quirk_exit;
}
cmd_hi = readb(csr + 3);
@@ -1483,7 +1484,9 @@
writeb(1, csr + 3);
}
- iounmap(csr);
+ pci_iounmap(dev, csr);
+e100_quirk_exit:
+ pci_release_region(dev, 0);
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, quirk_e100_interrupt);
^ permalink raw reply
* Re: [PATCH 3/9] 8xx: Add pin and clock setting functions.
From: Scott Wood @ 2007-09-05 17:37 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070905113957.2ed9e498@localhost.localdomain>
On Wed, Sep 05, 2007 at 11:39:57AM +0400, Vitaly Bordug wrote:
> > Note that this code is mostly duplicated from the existing CPM2
> > version.
> >
> Then it would be good to mention that in short comment block before function.
The code would very quickly become unreadable if we kept comments around
for every movement of code. Given the current state of things, it's
pretty much a given that most functions in commproc.c have a
corresponding function in cpm2_common.c, and vice versa.
I'd like to merge some of it at some point.
> > > We're adding helper functions and should be ready that something
> > > somewhere won't work as expected.
> >
> > Could you elaborate on what you expect to possibly not work, or what
> > we should do to "be ready"?
> Some new PQ-like board being added to powerpc. I mean, each newly-added
> non-static function should have some sort of description unless
> it(function) is completely self-explanatory.
I thought it was completely self-explanatory.
> Just a few words either here as a comment or in patch description, what
> the function supposed to do and which way, so that someone not familiar
> with cpm/cpm2, would quickly understand what's happening in there.
If they're not familiar with CPM, and want to understand how hardware
setup for it works, the user's manual for one of the chips would be a
good place to start... As it is, it's pretty clear without knowledge of
the CPM that it's a helper function that sets and clears bits in certain
registers.
Since we seem to have differing views of the target audience, could you
suggest a specific wording that you're looking for?
-Scott
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC 440EPx: Initial Sequoia support
From: Josh Boyer @ 2007-09-05 17:41 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070829133520.GA19925@ru.mvista.com>
On Wed, 29 Aug 2007 17:35:20 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> The following patches add initial PowerPC 440EPx Sequoia board support.
> The code is based mainly on the Bamboo board support by Josh Boyer.
> These patches have been modified according the comments for the previous
> 440EPx Sequoia patch series.
FYI, I'll be pulling this series into my git tree this week.
josh
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Stefan Richter @ 2007-09-05 17:43 UTC (permalink / raw)
To: Randy Dunlap
Cc: michal.k.k.piotrowski, rbrito, linux-kernel, rjw, linuxppc-dev,
debian-powerpc, Andrew Morton, linux-pm, Tim Teulings
In-Reply-To: <20070905102824.a481060c.randy.dunlap@oracle.com>
Randy Dunlap wrote:
> On Wed, 5 Sep 2007 10:07:54 -0700 Andrew Morton wrote:
>>> So here is the output from dmesg that suggested to me that firewire
>>> might be a problem:
>> Straightforward regression, two reporters, nothing happening.
>
> (material for ksummit discussion, e.g.)
It's a simple thing in this incident: I don't read all posts on LKML.
But I typically catch everything where I am in the CC list thanks to the
wonders of sieve. Andrew, thanks for putting me in the CCs.
--
Stefan Richter
-=====-=-=== =--= --=-=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Stefan Richter @ 2007-09-05 17:47 UTC (permalink / raw)
To: Andrew Morton
Cc: michal.k.k.piotrowski, rbrito, g, linux-kernel, rjw, linuxppc-dev,
debian-powerpc, linux-pm, Tim Teulings
In-Reply-To: <20070905100754.57ab4e3e.akpm@linux-foundation.org>
Andrew Morton wrote:
>> On 30 Aug 2007 22:42:46 +0200 "Tim Teulings" <rael@edge.ping.de> wrote:
>> Hello!
>>
>>> I don't have traces at hand and due to lack of time cannot reproduce it
>>> up to tomorrow. However this hint may speed up your analysis!
>> Sorry for the delay, but my desktop PC had an urgent hard disk problem I
>> had to fix ASASP.
>>
>> So here is the output from dmesg that suggested to me that firewire
>> might be a problem:
>
> Straightforward regression, two reporters, nothing happening.
Thanks for CCing me. I'm also adding the CC of Kristian, author and
other maintainer of the code in question.
>>> usb_endpoint usbdev2.2_ep81: PM: suspend 0->2, parent 2-1:1.0 already 2
>>> usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
>>> usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
>>> hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
>>> usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
>>> eth2: Airport entering sleep mode
>>> eth0: suspending, WakeOnLan disabled
>>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
>>> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
>>> suspend_device(): pci_device_suspend+0x0/0x98() returns -22
>>> Could not suspend device 0002:20:0e.0: error -22
>>> eth0: resuming
>>> PHY ID: 4061e4, addr: 0
>>> eth2: Airport waking up
>>> eth2: New link status: Connected (0001)
>>> hda: Enabling Ultra DMA 2
>>> eth0: Link is up at 100 Mbps, full-duplex.
>>> eth0: Pause is disabled
>>> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>> hdb: Enabling Ultra DMA 2
>>> usb_endpoint usbdev1.1_ep00: PM: resume from 0, parent usb1 still 2
>>> usb_endpoint usbdev1.1_ep81: PM: resume from 0, parent 1-0:1.0 still 2
>>> usb_device usbdev1.1: PM: resume from 0, parent usb1 still 2
>>> Driver sleep failed
>>> Sleep rejected by devices
>>> adb: starting probe task...
>>> adb devices: [2]: 2 c4 [3]: 3 1 [7]: 7 1f
>>> ADB keyboard at 2, handler 1
>>> ADB mouse at 3, handler set to 4 (trackpad)
>>> adb: finished probe task...
>>> usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
>>> usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
>>> hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
>>> usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
>>> eth2: Airport entering sleep mode
>>> eth0: suspending, WakeOnLan disabled
>>> Trying to free already-free IRQ 40
>>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
>>> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
>
> I grepped the whole tree for firewire_ohci and came up blank. What is it?
drivers/firewire/fw-ohci.c -> fw-ohci.o -> firewire-ohci.o ->
firewire-ohci.ko
> But yes, a failed pci_set_power_state() will hurt. Perhaps this is
> a result of some recently-added return-value checking fix but as I
> cannot find the dang code I cannot tell.
The old ohci1394.c used to ignore pci_set_power_state's return value.
In the pre 2.6.19-rc1 commit ea6104c22468239083857fa07425c312b1ecb424, I
added a fail-on-error. This was toned down to a printk-on-err by pre
2.6.19-rc4 commit 346f5c7ee7fa4ebee0e4c96415a7e59716bfa1d0.
This was because of Benjamin Herrenschmidt's regression report:
http://lkml.org/lkml/2006/10/24/13
So, we went into the same trap again with fw-ohci. I should have
noticed how fw-ohci treats pci_set_power_state when I signed off the
commit which added the suspend/resume methods to fw-ohci --- but somehow
I didn't.
>>> suspend_device(): pci_device_suspend+0x0/0x98() returns -22
>>> Could not suspend device 0002:20:0e.0: error -22
>>> eth0: resuming
>>> PHY ID: 4061e4, addr: 0
>>> eth2: Airport waking up
>>> eth2: New link status: Connected (0001)
>>> hda: Enabling Ultra DMA 2
>>> hdb: Enabling Ultra DMA 2
>>> eth0: Link is up at 100 Mbps, full-duplex.
>>> eth0: Pause is disabled
>> The problem wa sinitiated by closing the lid. The iBook then seems to
>> permanetly try to go to sleep (I can hear the cd-rom drive get
>> periodically initialized). So above contains more than one iteration.
>>
>> The kernel is:
>>> Linux kismet 2.6.22-1-powerpc #1 Sun Jul 29 13:58:06 CEST 2007 ppc GNU/Linux
>> The relveant debian package:
>>> linux-image-2.6.22-1-powerpc_2.6.22-3_powerpc.deb
>> I'm running a mixture of debian testing/unstable.
>>
>> The firewire and the USB connector were unused, the network connector
>> was used.
>>
>> If there are questions regarding other packages, or somebody wants me to
>> test a fix (I would prever a debian package), don't hesitate - I would
>> like to get the bug fixed :-)
>>
A trivial post -rc1 compatible fix is coming in a minute.
--
Stefan Richter
-=====-=-=== =--= --=-=
http://arcgraph.de/sr/
^ permalink raw reply
* [PATCH] Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Stefan Richter @ 2007-09-05 18:06 UTC (permalink / raw)
To: Andrew Morton
Cc: michal.k.k.piotrowski, rbrito, Kristian Høgsberg,
linux-kernel, rjw, linuxppc-dev, debian-powerpc, linux-pm,
Tim Teulings
In-Reply-To: <46DEEBBE.4070201@s5r6.in-berlin.de>
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Subject: firewire: fw-ohci: ignore failure of pci_set_power_state (fix suspend regression)
Fixes "Sleep problems with kernels >= 2.6.21 on powerpc",
http://lkml.org/lkml/2007/8/25/155.
Like it was suggested earlier in http://lkml.org/lkml/2006/10/24/13,
we do *not* fail .suspend anymore if pci_set_power_state failed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/firewire/fw-ohci.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6.23-rc4/drivers/firewire/fw-ohci.c
===================================================================
--- linux-2.6.23-rc4.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.23-rc4/drivers/firewire/fw-ohci.c
@@ -1946,8 +1946,11 @@ static int pci_suspend(struct pci_dev *p
}
err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
if (err) {
+ /*
+ * Some Apple onboard controllers are known to fail here.
+ * Ignore it and let the machine proceed to suspend.
+ */
fw_error("pci_set_power_state failed\n");
- return err;
}
return 0;
--
Stefan Richter
-=====-=-=== =--= --=-=
http://arcgraph.de/sr/
^ permalink raw reply
* OF NDFC
From: Valentine Barshak @ 2007-09-05 18:17 UTC (permalink / raw)
To: linuxppc-dev
Is anybody working on the device-tree-aware ppc 44x NAND flash controller (ndfc) driver?
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH] Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Stefan Richter @ 2007-09-05 18:24 UTC (permalink / raw)
To: Rogério Brito
Cc: michal.k.k.piotrowski, g, linux-kernel, rjw, linuxppc-dev,
debian-powerpc, Andrew Morton, linux-pm, Tim Teulings
In-Reply-To: <tkrat.7174534bdd0ddaff@s5r6.in-berlin.de>
Rogério Brito wrote on 2007-08-27:
> If things progress well, I will incrementally include features on the
> kernel that I need (I left out, for instance, the Firewire subsystem, so
> that compilation wouldn't take more than an hour here, despite the fact
> that I do need Firewire support on the kernel) and see the point where
> things are not normal.
The trivial pci_set_power_state issue aside, resume is currently
defective with the new firewire-ohci driver:
- The version in Linus' tree doesn't restore a certain detail of
IEEE 1394 state during resume, hence some protocols like SBP-2 don't
work after resume unless you unload and reload the drivers.
- The version in -mm restores everything but panics soon after resume
on an APM notebook in combination with some SBP-2 targets. I have
yet to try netconsole or so to gather more information.
--
Stefan Richter
-=====-=-=== =--= --=-=
http://arcgraph.de/sr/
^ permalink raw reply
* Xilinx FX60
From: Robert Woodworth @ 2007-09-05 18:42 UTC (permalink / raw)
To: linuxppc-embedded
After achieving complete success with my Linux kernel on the ML403, I've
now started to build a kernel for my real target board with a
Virtex4-FX60 (dual PPC cores)
Has anyone built a kernel for a dual core PPC Virtex? I have found very
little docs on how to architect software for the dual-core PPC's.
Will SMP Linux work on this platform? What would the bus setup be?
My kernel is partially booting, some of the time... I'm mystified by the
situation. One time, I get all the happy boot messages through the
UARTLite port, then the next reboot it stops at "Now booting the kernel"
I'm only getting about 10% successful boots......
My EDK setup is as follows; I've disconnected the second PPC from the
PLB to have a single PPC system, 32MB DDR on PLB, TEMAC on PLB, UARTLite
on OPB.
^ permalink raw reply
* Re: Problems enabling NTP on ELDK
From: Wolfgang Denk @ 2007-09-05 18:48 UTC (permalink / raw)
To: Johan Borkhuis; +Cc: linuxppc-embedded
In-Reply-To: <46DE9322.7080901@dutchspace.nl>
In message <46DE9322.7080901@dutchspace.nl> you wrote:
>
> I tried enabling NTP on my embedded machine (using ELDK 4.1, ppc_85xx,
> kernel version 2.6.14 with Xenomai 2.3.2). After I did that I noticed
> that ksoftirqd/0 suddenly took almost all processor time (> 95%). What
> is causing this? Is there a way around this, or is this something that
> does not cause any problems?
You probably have some poroblems in your kernel port - check the RTC
driver and related modules like I2C etc. Of course this depends on
the NTP configuration you use, but the only kernel interaction I can
think of that could cause this is if you interact with the RTC. [I
guess that normal network traffic is working fine on your board.]
BTW: ELDK 4.1 comes with a 2.6.19.2 kernel - is there a special
reason that you use such an obsoletel kernel tree?
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: wd@denx.de
Bankers do it with interest (penalty for early withdrawal).
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Randy Dunlap @ 2007-09-05 17:58 UTC (permalink / raw)
To: Stefan Richter
Cc: michal.k.k.piotrowski, rbrito, linux-kernel, rjw, linuxppc-dev,
debian-powerpc, Andrew Morton, linux-pm, Tim Teulings
In-Reply-To: <46DEEAC1.7020900@s5r6.in-berlin.de>
Stefan Richter wrote:
> Randy Dunlap wrote:
>> On Wed, 5 Sep 2007 10:07:54 -0700 Andrew Morton wrote:
>>>> So here is the output from dmesg that suggested to me that firewire
>>>> might be a problem:
>>> Straightforward regression, two reporters, nothing happening.
>> (material for ksummit discussion, e.g.)
>
> It's a simple thing in this incident: I don't read all posts on LKML.
> But I typically catch everything where I am in the CC list thanks to the
> wonders of sieve. Andrew, thanks for putting me in the CCs.
I understand. I just meant the general trend, nothing specific
to this thread.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* firewire in prebuilt kernel packages (was Re: Sleep problems with kernels >= 2.6.21 on powerpc)
From: Stefan Richter @ 2007-09-05 19:01 UTC (permalink / raw)
To: debian-powerpc
Cc: michal.k.k.piotrowski, rbrito, g, linux-kernel, rjw, linuxppc-dev,
Andrew Morton, linux-pm, Tim Teulings
In-Reply-To: <46DEEBBE.4070201@s5r6.in-berlin.de>
>>> On 30 Aug 2007 22:42:46 +0200 "Tim Teulings" <rael@edge.ping.de> wrote:
>>> The kernel is:
>>>> Linux kismet 2.6.22-1-powerpc #1 Sun Jul 29 13:58:06 CEST 2007 ppc GNU/Linux
>>> The relveant debian package:
>>>> linux-image-2.6.22-1-powerpc_2.6.22-3_powerpc.deb
>>> I'm running a mixture of debian testing/unstable.
At the moment, distributors should not provide the experimental
firewire-* drivers as the only or primary FireWire drivers, unless they
know exactly what the gotchas are. As a hint, CONFIG_FIREWIRE currently
depends on EXPERIMENTAL, CONFIG_IEEE1394 does not. Some basic
information can be found at http://wiki.linux1394.org/JujuMigration.
--
Stefan Richter
-=====-=-=== =--= --=-=
http://arcgraph.de/sr/
^ permalink raw reply
* RE: Xilinx FX60
From: Wood, Robert (GE Indust, GE Fanuc) @ 2007-09-05 18:56 UTC (permalink / raw)
To: Robert Woodworth, linuxppc-embedded
In-Reply-To: <1189017748.6185.49.camel@PisteOff>
We've been using Virtex 2 PRO with dual cores. We found it necessary to
very tightly constrain clocks and resets. Also, constrain the reset
block to adjacent to the ports on the PPC.
Another lightly documented feature is that the core clock must be an
integer multiple of the PLB clock, say 300MHz/100MHz.
Robert Wood
GEFanuc Sensor Processing
5430 Canotek Road
Ottawa, Ontario
Canada K1J 9G2
613-749-9241 x270
=20
-----Original Message-----
From: linuxppc-embedded-bounces+rwood=3Dics-ltd.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+rwood=3Dics-ltd.com@ozlabs.org] On
Behalf Of Robert Woodworth
Sent: Wednesday, September 05, 2007 2:42 PM
To: linuxppc-embedded@ozlabs.org
Subject: Xilinx FX60
After achieving complete success with my Linux kernel on the ML403, I've
now started to build a kernel for my real target board with a
Virtex4-FX60 (dual PPC cores)
Has anyone built a kernel for a dual core PPC Virtex? I have found very
little docs on how to architect software for the dual-core PPC's. =20
Will SMP Linux work on this platform? What would the bus setup be?
My kernel is partially booting, some of the time... I'm mystified by the
situation. One time, I get all the happy boot messages through the
UARTLite port, then the next reboot it stops at "Now booting the kernel"
I'm only getting about 10% successful boots......
My EDK setup is as follows; I've disconnected the second PPC from the
PLB to have a single PPC system, 32MB DDR on PLB, TEMAC on PLB, UARTLite
on OPB.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox