Re: I2C on mpc8248 / device tree
On Nov 13, 2007, at 5:39 PM, Alan Bennett wrote: > I've got four devices on i2c that I need to read. Simple thermal > and voltage monitors. I2c works fine in uboot, and now I'm trying > to get things to work in linux. > > In the kernel .config I enable > I2C > and > I2C_MPC This driver isn't for the I2C on 8248. You need a cpm2 i2c driver for that controller. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
On Tue, 13 Nov 2007 07:48:50 -0600 Jon Loeliger <[EMAIL PROTECTED]> wrote: > > I'm assuming I can chip away at _all_ of these, > including the ones in the drivers/ directories as well. Knock yourself out! :-) > I haven't a clue who will really pick all these up. > We could arrange for Paul to grab the arch/powerpc. > But the rest? Mr Morton perhaps? Just keep in mind that some of these changes may affect Sparc and Sparc64, so Dave Miller is you man for those. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpfvH7kM9Rc0.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] pSeries: make pseries_defconfig minus PCI build again
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- arch/powerpc/platforms/pseries/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index 16e4e40..306a9d0 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -21,7 +21,7 @@ config PPC_SPLPAR config EEH bool "PCI Extended Error Handling (EEH)" if EMBEDDED - depends on PPC_PSERIES + depends on PPC_PSERIES && PCI default y if !EMBEDDED config SCANLOG -- 1.5.3.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] PowerPC: 4xx uic updates
On Tue, 2007-11-13 at 20:05 -0600, Josh Boyer wrote: > On Tue, 13 Nov 2007 23:15:59 +0300 > Valentine Barshak <[EMAIL PROTECTED]> wrote: > > > These patches update 4xx uic code. The first one > > fixes a minor issue with edge-triggered interrupts, > > while the second one makes it use generic level and edge irq > > handlers. I've added irq ack'ing to the unmask callback for > > level-triggered interrupts, because to de-assert them we have > > to do 2 things is the exact order as below: > > 1. de-assert the external source in the ISR. > > 2. ack the IRQ on the UIC. > > So, ack'ing level interrupts before unmasking them makes possible > > to use generic level irq handler and it doesn't hurt, cause > > we can never miss a level-triggered interrupt. It always stays > > asserted untill the external source is removed and ack'ed on UIC. > > > > These have been tested on Sequoia PowerPC 440EPx board. > > Is my mail server slow, or did patch 2 of 2 never make it out? It never reached me neither. Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
On Wed, 2007-11-14 at 13:13 +1100, David Gibson wrote: > Hrm. I *think* I'm convinced this is safe, although acking in a > callback which doesn't say it acks is rather yucky. Essentially this > code is trading flow readability (because just reading > handle_level_irq will tell you something other than what it does in > our case) for smaller code size. I'm not sure if this is a good trade > or not. > > There's also one definite problem: according to the discussions I had > with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what > we want for edge interrupts. > > Apparently handle_edge_irq is only for edge interrupts on "broken" > PICs which won't latch new interrupts while the irq is masked. UIC is > not in this category, so handle_level_irq is actually what we want, > even for an edge irq. > > Yes, I thought the naming was more than a little confusing, too. Hrm... handle_edge_irq works for both and you have a small performance benefit in not masking, and thus using handle_edge_irq, so I don't totally agree here. Basically, what handle_edge_irq() does is lazy masking. Now there -is- an issue here is that if you do lazy masking, you need to be able to re-emit in some convenient way. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pci hotplug: fix rpaphp directory naming
On Tue, Nov 13, 2007 at 06:34:55PM -0600, Linas Vepstas wrote: > > > Fix presentation of the slot number in the /sys/bus/pci/slots > directory to match that used in the majority of other drivers. We need a signed-off-by: to be able to apply this... thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: printk/console_init - baud rate setting
Thanks a lot Geert and Benjamin for your response. Code is indeed calling register_console from three different places 1) con_init()[name-tty], 2) serial8250_console_init()[name-ttyS], 3) early_uart_console_init()[name-uart]. Among these, 8250 must be the active one. Also serial8250_console_write() keeps hitting the BDI2000 break point with same address and count again and again. I am getting garbage on the screen. So, I presume this must be some sort of baud rate issue. Can some one help me out understand how this baud is set for serial drivers? I want to run at 115200. Thanks Siva -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geert Uytterhoeven Sent: Tuesday, November 13, 2007 12:17 AM To: Siva Prasad Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: printk/console_init On Mon, 12 Nov 2007, Siva Prasad wrote: > I am using 2.6.19 Linux on 8641D based system. > > I am using early printk's and it works fine until console_init() is > executed. After that it does not, as the early printk's get disabled, > which is fine. However, I don't see any prints after that at all, that > are based on regular printk statements. I looked directly into the > memory at __log_buf and found all the print messages. It is just not > coming out to the serial port properly. > > It would be great if some one can tell me various parameters that I need > to consider changing, to successfully port the serial driver for a new > board. > > Based on the early printk's, I am getting the following messages... > > Using MPC86xx HPCN machine description > Total memory = 1024MB; using 2048kB for hash table (at cfe0) > Linux version 2.6.19 ([EMAIL PROTECTED]) (gcc version 4.1.1 > 20060525 (Red Hat 4.1.1-1)) #115 SMP Mon Nov 12 18:21:43 PST 2007 > Found legacy serial port 0 for /[EMAIL PROTECTED]/[EMAIL PROTECTED] > mem=ff704500, taddr=ff704500, irq=1a, clk=1496250, speed=0 > Found MPC86xx PCIE host bridge at 0xff708000. Firmware bus > number: 0->254 > Found MPC86xx PCIE host bridge at 0xff709000. Firmware bus > number: 0->255 > MPC86xx HPCN board from Freescale Semiconductor > Zone PFN ranges: > DMA 0 -> 196608 > Normal 196608 -> 196608 > HighMem196608 -> 262144 > early_node_map[1] active PFN ranges > 0:0 -> 262144 > start_kernel: 8 2200. > Built 1 zonelists. Total pages: 260096 > Kernel command line: console=ttyS0,115200 root=/dev/sda8 > mpic: Setting up MPIC " MPIC " version 1.2 at ff74, max 2 CPUs > mpic: ISU size: 16, shift: 4, mask: f > mpic: Initializing for 80 sources > PID hash table entries: 4096 (order: 12, 16384 bytes) > time_init: decrementer frequency = 150.00 MHz > time_init: processor frequency = 1496.25 MHz > < Nothing gets printed after this ...> Did your serial driver (a) call register_console() (b) using the correct name? With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center 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/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 * B-1840 Londerzeel * Belgium VAT BE 0413.825.160 * RPR Brussels Fortis Bank Zaventem * Swift GEBABEBB08A * IBAN BE39001382358619 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] PowerPC: 4xx uic updates
On Tue, Nov 13, 2007 at 08:05:14PM -0600, Josh Boyer wrote: > On Tue, 13 Nov 2007 23:15:59 +0300 > Valentine Barshak <[EMAIL PROTECTED]> wrote: > > > These patches update 4xx uic code. The first one > > fixes a minor issue with edge-triggered interrupts, > > while the second one makes it use generic level and edge irq > > handlers. I've added irq ack'ing to the unmask callback for > > level-triggered interrupts, because to de-assert them we have > > to do 2 things is the exact order as below: > > 1. de-assert the external source in the ISR. > > 2. ack the IRQ on the UIC. > > So, ack'ing level interrupts before unmasking them makes possible > > to use generic level irq handler and it doesn't hurt, cause > > we can never miss a level-triggered interrupt. It always stays > > asserted untill the external source is removed and ack'ed on UIC. > > > > These have been tested on Sequoia PowerPC 440EPx board. > > Is my mail server slow, or did patch 2 of 2 never make it out? It reached me eventually, but only to my ibm address, not via the list (whereas I got both copies of 0 and 1). -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
On Tue, Nov 13, 2007 at 11:27:31PM +0300, Valentine Barshak wrote: > This patch makes PowerPC 4xx UIC use generic edge and level irq handlers > instead of a custom handle_uic_irq() function. Acking a level irq on UIC > has no effect if the interrupt is still asserted by the device, even if > the interrupt is already masked. So, to really de-assert the interrupt > we need to de-assert the external source first *and* ack it on UIC then. > The handle_level_irq() function masks and ack's the interrupt with mask_ack > callback prior to calling the actual ISR and unmasks it at the end. > So, to use it with UIC level interrupts we need to ack in the unmask > callback instead, after the ISR has de-asserted the external interrupt source. > Even if we ack the interrupt that we didn't handle (unmask/ack it at > the end of the handler, while next irq is already pending) it will not > de-assert the irq, untill we de-assert its exteral source. Hrm. I *think* I'm convinced this is safe, although acking in a callback which doesn't say it acks is rather yucky. Essentially this code is trading flow readability (because just reading handle_level_irq will tell you something other than what it does in our case) for smaller code size. I'm not sure if this is a good trade or not. There's also one definite problem: according to the discussions I had with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what we want for edge interrupts. Apparently handle_edge_irq is only for edge interrupts on "broken" PICs which won't latch new interrupts while the irq is masked. UIC is not in this category, so handle_level_irq is actually what we want, even for an edge irq. Yes, I thought the naming was more than a little confusing, too. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] PowerPC: 4xx uic updates
On Tue, 13 Nov 2007 23:15:59 +0300 Valentine Barshak <[EMAIL PROTECTED]> wrote: > These patches update 4xx uic code. The first one > fixes a minor issue with edge-triggered interrupts, > while the second one makes it use generic level and edge irq > handlers. I've added irq ack'ing to the unmask callback for > level-triggered interrupts, because to de-assert them we have > to do 2 things is the exact order as below: > 1. de-assert the external source in the ISR. > 2. ack the IRQ on the UIC. > So, ack'ing level interrupts before unmasking them makes possible > to use generic level irq handler and it doesn't hurt, cause > we can never miss a level-triggered interrupt. It always stays > asserted untill the external source is removed and ack'ed on UIC. > > These have been tested on Sequoia PowerPC 440EPx board. Is my mail server slow, or did patch 2 of 2 never make it out? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Xilinx Linux git server available
Hi all, I'm happy to announce that the Xilinx Linux Kernel git server is finally up and running and available to the public. The Xilinx Linux Kernel is based on the mainline Linux Kernel from kernel.org and adds driver support for various Xilinx IP cores and Xilinx reference boards. It contains many (but not all) of the MicroBlaze contributions and enhancements from John Williams' PetaLogix Linux distribution and some PPC work from Grant Likely. It also contains contributions from Stephen Neuendorffer, Joachim Foerster and Brian Hill, to name a few. The kernel includes drivers to support the following Xilinx IP cores: * EMAC, EMACLITE, TEMAC, LLTEMAC * UART, UARTLITE * SYSACE * SPI, GPIO, FB, GPIO, HWICAP, AC97 and support for the following boards: * ML40x, ML4x0 * Spartan 3E 1600, XUPV2P In a couple weeks we will be adding MicroBlaze v7 MMU support. The kernel is licensed under the GPL version 2 and is provided AS IS. It is _not_ supported in any way or form by the Xilinx Support Center. If you call the Xilinx Support center, they will not be able to help you. For those interested in a supported Linux distribution, please contact one of the many partner companies at: http://www.xilinx.com/ise/embedded/epartners/listing.htm Please, also keep in mind that the kernel is not actively being tested and will may set your house on fire. The git URL for the Xilinx Linux Kernel sources is: git://git.xilinx.com/linux-2.6-xlnx.git The Web front-end for this server can be found at: http://git.xilinx.com At this time there are two branches available: * lin26-xlnx This branch is based on the latest stable kernel release (currently 2.6.23) * lin26-xlnx-rc This branch tracks the leading edge mainline (currently 2.6.24-rc2) The git server also hosts a clone of Grant Likely's OF device tree generation tool with additions by Stephen Neuendorffer to support MicroBlaze systems. The git URL for this repository is: git://git.xilinx.com/gen-mhs-devtree.git If you have suggestions or want to contribute to the Xilinx Linux Kernel, please send your feedback, patches or other contributions to: git _at_ xilinx.com Hope to hear from you soon :-) Thanks, Wolfgang ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
On 11/13/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > That's why Dominic wants to get OpenOCD running on the PowerPC. All we > > need is the programming documentation for controlling the CPU via the > > debug hardware. > > Note that this is basically different for every CPU around. I'd like to get it for the MPC5200 because of the project I am working on, an open source audio device. It would be nice if there was a cheap hardware debugger available for hackers to use on it. Maybe one of the Freescale developers will see this and send me the right docs. Is it radically different? Dominic has been able to support every ARM 7/9 chip he can get his hands on without too much trouble once the core support was written. I don't think he has ARM 11 working yet. > > > Obviously this documentation exist, all of the commercial vendors had > > to have it to develop their debuggers. Maybe it is already out there > > and we just don't know where to look. > > Ben. > > > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] pci hotplug: rm bogus item in rpaphp struct
Remove unused struct element.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/pci/hotplug/rpaphp.h |1 -
drivers/pci/hotplug/rpaphp_pci.c |1 -
2 files changed, 2 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h
===
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp.h 2007-11-13
18:37:31.0 -0600
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h 2007-11-13
19:00:42.0 -0600
@@ -76,7 +76,6 @@ struct slot {
char *name;
struct device_node *dn;
struct pci_bus *bus;
- struct list_head *pci_devs;
struct hotplug_slot *hotplug_slot;
};
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c
===
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13
18:37:31.0 -0600
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13
19:00:13.0 -0600
@@ -100,7 +100,6 @@ int rpaphp_enable_slot(struct slot *slot
info->adapter_status = EMPTY;
slot->bus = bus;
- slot->pci_devs = &bus->devices;
/* if there's an adapter in the slot, go add the pci devices */
if (state == PRESENT) {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
> That's why Dominic wants to get OpenOCD running on the PowerPC. All we > need is the programming documentation for controlling the CPU via the > debug hardware. Note that this is basically different for every CPU around. > Obviously this documentation exist, all of the commercial vendors had > to have it to develop their debuggers. Maybe it is already out there > and we just don't know where to look. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
On Tue, 2007-11-13 at 23:21 +0100, Gerhard Pircher wrote: > Original-Nachricht > > Datum: Tue, 13 Nov 2007 17:10:29 -0500 > > Von: "Jon Smirl" <[EMAIL PROTECTED]> > > An: "Grant Likely" <[EMAIL PROTECTED]> > > CC: "Gerhard Pircher" <[EMAIL PROTECTED]>, linuxppc-dev@ozlabs.org > > Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs > > > On 11/13/07, Grant Likely <[EMAIL PROTECTED]> wrote: > > > On 11/13/07, Grant Likely <[EMAIL PROTECTED]> wrote: > > > > Abatron BDI-2000. > > > > > > Oops, but that's not all that cheap. ($2750USD). You might try > > > looking at the Macraigor Wiggler > > > (http://www.macraigor.com/wiggler.htm), but it has limited powerpc > > > support. > > > > Here are the choices: > > http://www.macraigor.com/cpus.htm > Looks like the Abatron BDI-2000 is the cheapest hardware debugger that > supports 74xx G4 CPUs. :-( Do you have the appropriate connector for it on the motherboard as well ? If not, then you are out of luck... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] PowerPC: 4xx uic: add mask_ack callback
On Tue, Nov 13, 2007 at 11:25:21PM +0300, Valentine Barshak wrote: > This adds uic_mask_ack_irq() callback to PowerPC 4xx uic code > to avoid kernel crash. It is used for edge-triggered interrupts > by handle_uic_irq(). Oops. Obviously never caught this obvious bug, because I've never used an edge-triggered interrupt on the Ebony yet. > Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> Acked-by: David Gibson <[EMAIL PROTECTED]> -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] pci hotplug: fix rpaphp directory naming
Fix presentation of the slot number in the /sys/bus/pci/slots
directory to match that used in the majority of other drivers.
--
On Tue, Nov 13, 2007 at 02:58:30PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote:
> > /sys/bus/pci/slots
> > /sys/bus/pci/slots/control
> > /sys/bus/pci/slots/control/remove_slot
> > /sys/bus/pci/slots/control/add_slot
> > /sys/bus/pci/slots/0001:00:02.0
> > /sys/bus/pci/slots/0001:00:02.0/phy_location
>
> Ugh. Almost two years ago, paulus promised me he was going to fix the
> slot name for rpaphp. Guess he didn't.
You have to ask the right person. :-) I've been defacto mainaining
the rpaphp code for unpteen years now. On the other hand, I am also
much, much better at promising than delivering.
> This is one of the hateful things about the current design -- hotplug
> drivers do too much. Instead of being just the interface between the
> Linux PCI code and the hardware, they create sysfs directories, add
> files,
> and generally have far too much freedom.
I chopped out several hundred LOC from rpaphp a year ago,
and hopefuly that might make furthre simplification easier
someday.
> We have four different schemes currently for naming in slots/,
> 1. slot number. Used by cpqphp, ibmphp, acpiphp, pciehp, shpc.
> 2. domain:bus:dev:fn. Used by fakephp.
> 3a. domain:bus:dev. Used by rpaphp and sgihp.
> 3b. Except that rpaphp uses phy_location to present the information
> that
> should be in the name and sgihp uses path.
>
> ... I've forgotten what cpci uses. And yenta doesn't use it.
>
> How is anyone supposed to write sane managability tools in the
> presence
> of such anarchy?
>
> > ~ # cat /sys/bus/pci/slots/:00:02.2/phy_location
> > U787A.001.DNZ00Z5-P1-C2
>
> Right. This should look like:
>
> # cat /sys/bus/pci/slots/U787A.001.DNZ00Z5-P1-C2/address
> :00:02
This patch implements exactly what you describe. Boot tested.
I assume you really mean it -- if so, then please review and
ack the patch !?
I have absolutely no clue if this breaks any existing IBM tools.
I'm pretty sure it doesn't ... but attention Mike Strosaker! does it?
drivers/pci/hotplug/rpaphp.h |1
drivers/pci/hotplug/rpaphp_pci.c | 14 ---
drivers/pci/hotplug/rpaphp_slot.c | 47 +++---
3 files changed, 24 insertions(+), 38 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c
===
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_pci.c 2007-07-08
18:32:17.0 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13
17:52:10.0 -0600
@@ -64,19 +64,6 @@ int rpaphp_get_sensor_state(struct slot
return rc;
}
-static void set_slot_name(struct slot *slot)
-{
- struct pci_bus *bus = slot->bus;
- struct pci_dev *bridge;
-
- bridge = bus->self;
- if (bridge)
- strcpy(slot->name, pci_name(bridge));
- else
- sprintf(slot->name, "%04x:%02x:00.0", pci_domain_nr(bus),
- bus->number);
-}
-
/**
* rpaphp_enable_slot - record slot state, config pci device
*
@@ -114,7 +101,6 @@ int rpaphp_enable_slot(struct slot *slot
info->adapter_status = EMPTY;
slot->bus = bus;
slot->pci_devs = &bus->devices;
- set_slot_name(slot);
/* if there's an adapter in the slot, go add the pci devices */
if (state == PRESENT) {
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c
===
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_slot.c 2007-07-08
18:32:17.0 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c 2007-11-13
18:05:13.0 -0600
@@ -33,23 +33,31 @@
#include
#include "rpaphp.h"
-static ssize_t location_read_file (struct hotplug_slot *php_slot, char *buf)
+static ssize_t address_read_file (struct hotplug_slot *php_slot, char *buf)
{
- char *value;
- int retval = -ENOENT;
+ int retval;
struct slot *slot = (struct slot *)php_slot->private;
+ struct pci_bus *bus;
if (!slot)
- return retval;
+ return -ENOENT;
- value = slot->location;
- retval = sprintf (buf, "%s\n", value);
+ bus = slot->bus;
+ if (!bus)
+ return -ENOENT;
+
+ if (bus->self)
+ retval = sprintf(buf, pci_name(bus->self));
+ else
+ retval = sprintf(buf, "%04x:%02x:00.0",
+ pci_domain_nr(bus), bus->number);
+
return retval;
}
-static struct hotplug_slot_attribute php_attr_location = {
- .attr = {.name = "phy_location", .mode = S_IFREG | S_IRUGO},
- .show = location_read_file,
+static struct hotplug_slot_attribute php_attr_address = {
+ .attr = {.name = "address", .mode
Re: I2C on mpc8248 / device tree
I am working on a patch for i2c and device tree. I attached the current version.
DTC entry looks like this.
[EMAIL PROTECTED] {
compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
[EMAIL PROTECTED] {
compatible = "epson,rtc8564";
reg = <51>;
};
};
--
Jon Smirl
[EMAIL PROTECTED]
jds-i2c-list
Description: Binary data
jds-mpc-i2c
Description: Binary data
jds-pfc-rtc
Description: Binary data
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
On 11/13/07, Olof Johansson <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 03:23:29PM -0800, Dan Malek wrote: > > > > On Nov 13, 2007, at 1:59 PM, Grant Likely wrote: > > > > >> Abatron BDI-2000. > > > > > > Oops, but that's not all that cheap. ($2750USD). > > > > If you place any value on your time or development > > schedule, it's a bargain. > > That only applies for cases where time means money, i.e. professional > work. Spending three thousand dollars to debug a board that you spent > a few hundred dollars buying just for a hobby is pretty crazy. That's why Dominic wants to get OpenOCD running on the PowerPC. All we need is the programming documentation for controlling the CPU via the debug hardware. Obviously this documentation exist, all of the commercial vendors had to have it to develop their debuggers. Maybe it is already out there and we just don't know where to look. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
I2C on mpc8248 / device tree
I've got four devices on i2c that I need to read. Simple thermal and
voltage monitors. I2c works fine in uboot, and now I'm trying to get things
to work in linux.
In the kernel .config I enable
I2C
and
I2C_MPC
During the platform boot code:
I init the IO ports for i2c, (same as ep8248e code)
{3, 14, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
{3, 15, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
__Do I need to configure a brg for the i2c along with the other devices ?
i.e. cpm2_clk_setup ?
Next, I'm sure my device tree needs work, but my first stab adds i2c onto
the SOC @ 11860 (immr+11860= I2c mode register) and interrupt 1.
[EMAIL PROTECTED] {
...
[EMAIL PROTECTED] {
...
[EMAIL PROTECTED] {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <11860 18>;
interrupts = <1 3>;
interrupt-parent = <&PIC>;
};
After Cleaning up these routines and descriptions, would I be expected to
continue using the /dev/i2c- entries?
-Alan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
On Tue, Nov 13, 2007 at 03:23:29PM -0800, Dan Malek wrote: > > On Nov 13, 2007, at 1:59 PM, Grant Likely wrote: > > >> Abatron BDI-2000. > > > > Oops, but that's not all that cheap. ($2750USD). > > If you place any value on your time or development > schedule, it's a bargain. That only applies for cases where time means money, i.e. professional work. Spending three thousand dollars to debug a board that you spent a few hundred dollars buying just for a hobby is pretty crazy. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel locks up after calling kernel_execve()
On Tue, 2007-11-13 at 23:06 +0100, Gerhard Pircher wrote: > Well, I only disabled power saving with powersave=off. Are there any > other > ways to disable idle? What do you mean with instrumenting locks or > irq enable/disable? Add printk's to things :-) It's a UP kernel so there should be no spinlocks anyway. Best is to try to get a 100% reprocase and printk your way toward the origin of the problem if you don't have a HW debugger. Unless you manage to sneak in an irq to xmon but if you are totally locked up, you probably can't. Could also be something you do that your buggy northbridge doesn't like. For example, maybe it dislikes M bit in the hash table and you end up with it set due to other reasons (I know we had changes in this area). > > Also, did you try booting with all kernel debug options enabled ? > I compiled in almost all kernel debugging options and booted the > kernel > with driver_debug, initcall_debug and debug. I didn't notice any > serious > error messages so far. Not sure however, if I missed a debug option. > > > Finally, since the problem seem to have started around a specific > kernel > > version, can you try to bisect the patch that causes it ? > Hmm, I'm not sure how to do this (only worked on platform code so > far). > I guess you think about checking out a kernel version from the git > repository, which doesn't contain the patch for kernel_execve(). > I still suspect the kernel_execve() function (which was introduced in > 2.6.17) because the kernel locks up after starting the first user > program. > AFAIK kernel threads should be running much earlier. They are but they cause a lot less MMU pressure, could be an indication... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
On Nov 13, 2007, at 1:59 PM, Grant Likely wrote: >> Abatron BDI-2000. > > Oops, but that's not all that cheap. ($2750USD). If you place any value on your time or development schedule, it's a bargain. Just plug it in, and it works. Choose any of your favorite debugger front ends, from none with just a telnet interface, to remote gdb, ddd, or several Eclipse options. Several choices of host OS. It will pay you back in development and debugging time savings over and over. -- Dan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix 2nd UCC entry in mpc832x_mds.dts
correct the reg property, remove duplicate io port entry, whitespace fixes.
Thanks to Peter Van Ackeren for pointing this out.
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc832x_mds.dts |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts
b/arch/powerpc/boot/dts/mpc832x_mds.dts
index fcd333c..eeafa8b 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -104,7 +104,7 @@
reg = <700 100>;
device_type = "ipic";
};
-
+
[EMAIL PROTECTED] {
reg = <1400 100>;
device_type = "par_io";
@@ -117,7 +117,6 @@
3 5 1 0 2 0 /* MDC */
0 d 2 0 1 0/* RX_CLK
(CLK9) */
3 18 2 0 1 0/* TX_CLK
(CLK10) */
- 1 1 1 0 1 0/* TxD1 */
1 0 1 0 1 0/* TxD0 */
1 1 1 0 1 0/* TxD1 */
1 2 1 0 1 0/* TxD2 */
@@ -165,11 +164,11 @@
reg = ;
brg-frequency = <0>;
bus-frequency = ;
-
+
[EMAIL PROTECTED] {
device_type = "muram";
ranges = <0 0001 4000>;
-
+
[EMAIL PROTECTED] {
reg = <0 4000>;
};
@@ -228,7 +227,7 @@
compatible = "ucc_geth";
model = "UCC";
device-id = <4>;
- reg = <3000 200>;
+ reg = <3200 200>;
interrupts = <23>;
interrupt-parent = < &qeic >;
/*
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
Original-Nachricht > Datum: Tue, 13 Nov 2007 17:10:29 -0500 > Von: "Jon Smirl" <[EMAIL PROTECTED]> > An: "Grant Likely" <[EMAIL PROTECTED]> > CC: "Gerhard Pircher" <[EMAIL PROTECTED]>, linuxppc-dev@ozlabs.org > Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs > On 11/13/07, Grant Likely <[EMAIL PROTECTED]> wrote: > > On 11/13/07, Grant Likely <[EMAIL PROTECTED]> wrote: > > > Abatron BDI-2000. > > > > Oops, but that's not all that cheap. ($2750USD). You might try > > looking at the Macraigor Wiggler > > (http://www.macraigor.com/wiggler.htm), but it has limited powerpc > > support. > > Here are the choices: > http://www.macraigor.com/cpus.htm Looks like the Abatron BDI-2000 is the cheapest hardware debugger that supports 74xx G4 CPUs. :-( Thanks! Gerhard -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
On 11/13/07, Grant Likely <[EMAIL PROTECTED]> wrote: > On 11/13/07, Grant Likely <[EMAIL PROTECTED]> wrote: > > On 11/13/07, Gerhard Pircher <[EMAIL PROTECTED]> wrote: > > > I'm trying to debug a kernel lockup that occurs on my machine with all > > > kernel > > > versions >2.6.16. I don't have a clue what the root cause of this lockup > > > is, > > > thus I'm thinking about using a hardware debugger. Can anybody recommend a > > > reasonably cheap hardware debugger that works with G4 CPUs and can > > > interact > > > with GDB/DDD? > > > > Abatron BDI-2000. > > Oops, but that's not all that cheap. ($2750USD). You might try > looking at the Macraigor Wiggler > (http://www.macraigor.com/wiggler.htm), but it has limited powerpc > support. Here are the choices: http://www.macraigor.com/cpus.htm > > Cheers, > g. > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > [EMAIL PROTECTED] > (403) 399-0195 > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel locks up after calling kernel_execve()
Original-Nachricht > Datum: Wed, 14 Nov 2007 08:43:38 +1100 > Von: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > An: Gerhard Pircher <[EMAIL PROTECTED]> > CC: linuxppc-dev@ozlabs.org > Betreff: Re: Kernel locks up after calling kernel_execve() > Well, at least the above tells is it's not DMA related. > > I don't know of any deeply hidden problem, so you are probably hitting > something else ... if you have disabled idle, then it may be useful to > try instrumenting locks or irq enable/disable. Well, I only disabled power saving with powersave=off. Are there any other ways to disable idle? What do you mean with instrumenting locks or irq enable/disable? > Also, did you try booting with all kernel debug options enabled ? I compiled in almost all kernel debugging options and booted the kernel with driver_debug, initcall_debug and debug. I didn't notice any serious error messages so far. Not sure however, if I missed a debug option. > Finally, since the problem seem to have started around a specific kernel > version, can you try to bisect the patch that causes it ? Hmm, I'm not sure how to do this (only worked on platform code so far). I guess you think about checking out a kernel version from the git repository, which doesn't contain the patch for kernel_execve(). I still suspect the kernel_execve() function (which was introduced in 2.6.17) because the kernel locks up after starting the first user program. AFAIK kernel threads should be running much earlier. Thanks! regards, Gerhard -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.24-rc2-git3 powerpc link failure
Hi Kamalesh, On Tue, 13 Nov 2007 16:35:06 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > > The 2.6.24-rc2-git3 kernel build fails during linking > > KSYM.tmp_kallsyms1.S > AS .tmp_kallsyms1.o > LD .tmp_vmlinux2 > KSYM.tmp_kallsyms2.S > AS .tmp_kallsyms2.o > LD .tmp_vmlinux3 > KSYM.tmp_kallsyms3.S > AS .tmp_kallsyms3.o > LD vmlinux.o > ld: TOC section size exceeds 64k > make: *** [vmlinux.o] Error 1 You need the following patch. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] From: Stephen Rothwell <[EMAIL PROTECTED]> Date: Wed, 7 Nov 2007 11:56:48 +1100 Subject: [PATCH] [POWERPC] Stop the TOC overflowing for large builds. Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- arch/powerpc/kernel/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index ca51f0c..9374bc9 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -3,7 +3,7 @@ # ifeq ($(CONFIG_PPC64),y) -EXTRA_CFLAGS += -mno-minimal-toc +CFLAGS_prom_init.o += -mno-minimal-toc endif ifeq ($(CONFIG_PPC32),y) CFLAGS_prom_init.o += -fPIC -- 1.5.3.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
On 11/13/07, Grant Likely <[EMAIL PROTECTED]> wrote: > On 11/13/07, Gerhard Pircher <[EMAIL PROTECTED]> wrote: > > I'm trying to debug a kernel lockup that occurs on my machine with all > > kernel > > versions >2.6.16. I don't have a clue what the root cause of this lockup is, > > thus I'm thinking about using a hardware debugger. Can anybody recommend a > > reasonably cheap hardware debugger that works with G4 CPUs and can interact > > with GDB/DDD? > > Abatron BDI-2000. Does anyone have the detailed doc needed to implement the software for a PPC hardware debugger? Dominic, the author of OpenOCD, has said he will take a look at adding PPC support if someone can supply him with the right doc. I've requested it from my Freescale rep. They sent me all of the hardware info but none of the software info. They can't seem to figure out what I'm asking for. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.24-rc1 freezes on powerbook at first boot stage
On Sat, 03 Nov 2007 the mental interface of Nathan Lynch told: [...] > Does 2.6.23 (or any earlier kernel) work? > 2.6.24-rc2 works so lala :) Machine: processor : 0 cpu : 7447A, altivec supported clock : 833.333000MHz revision: 0.2 (pvr 8003 0102) bogomips: 36.32 timebase: 18432000 platform: PowerMac machine : PowerBook5,6 motherboard : PowerBook5,6 MacRISC3 Power Macintosh detected as : 287 (PowerBook G4 15") pmac flags : 001b L2 cache: 512K unified pmac-generation : NewWorld b43 doesn't authenticate via wpa (bluetooth isn't loaded): WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Operation not supported WEXT auth param 5 value 0x1 - Internet Systems Consortium DHCP Client V3.1.0 dmesg: .. TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered sysctl table check failed: /kernel .1 Writable sysctl directory Call Trace: [c1061e60] [c0008b28] show_stack+0x4c/0x1ac (unreliable) [c1061ea0] [c0047354] set_fail+0x50/0x68 [c1061ec0] [c0047784] sysctl_check_table+0x418/0x714 [c1061f30] [c00335b8] register_sysctl_table+0x64/0xb4 [c1061f50] [c033fd5c] register_powersave_nap_sysctl+0x18/0x2c [c1061f60] [c03391e4] kernel_init+0xc0/0x2a0 [c1061ff0] [c0011a58] kernel_thread+0x44/0x60 setup_kcore: restrict size=3fff Registering PowerMac CPU frequency driver .. ohci_hcd: Unknown symbol usb_hcd_pci_suspend ohci_hcd: Unknown symbol usb_hcd_resume_root_hub ohci_hcd: Unknown symbol usb_hcd_pci_probe ohci_hcd: Unknown symbol usb_hcd_unlink_urb_from_ep ohci_hcd: Unknown symbol usb_disabled ohci_hcd: Unknown symbol usb_hcd_check_unlink_urb ohci_hcd: Unknown symbol usb_calc_bus_time ohci_hcd: Unknown symbol usb_hcd_pci_shutdown ohci_hcd: Unknown symbol usb_hcd_link_urb_to_ep ohci_hcd: Unknown symbol usb_hcd_pci_resume ohci_hcd: Unknown symbol usb_put_hcd ohci_hcd: Unknown symbol usb_hcd_giveback_urb ohci_hcd: Unknown symbol usb_hcd_poll_rh_status ohci_hcd: Unknown symbol usb_create_hcd ohci_hcd: Unknown symbol usb_hcd_pci_remove ohci_hcd: Unknown symbol usb_remove_hcd ohci_hcd: Unknown symbol usb_add_hcd ohci_hcd: Unknown symbol usb_root_hub_lost_power ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver . console-tools (kbd) doesn't work correct (No DPMS Blank on console) (Using radeonfb) Boottime font isn't loaded on every vt. There is a lot to do, but it seems to be a big, big code change in that version. This impressed me by looking at the git changes and the size of patches. And the rc's don't seem to be frozend versions. A lot of new code comes in Let me know whether a complete dmesg is needed. Thanks Elimar -- The path to source is always uphill! -unknown- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
On 11/13/07, Grant Likely <[EMAIL PROTECTED]> wrote: > On 11/13/07, Gerhard Pircher <[EMAIL PROTECTED]> wrote: > > I'm trying to debug a kernel lockup that occurs on my machine with all > > kernel > > versions >2.6.16. I don't have a clue what the root cause of this lockup is, > > thus I'm thinking about using a hardware debugger. Can anybody recommend a > > reasonably cheap hardware debugger that works with G4 CPUs and can interact > > with GDB/DDD? > > Abatron BDI-2000. Oops, but that's not all that cheap. ($2750USD). You might try looking at the Macraigor Wiggler (http://www.macraigor.com/wiggler.htm), but it has limited powerpc support. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
On 11/13/07, Gerhard Pircher <[EMAIL PROTECTED]> wrote: > I'm trying to debug a kernel lockup that occurs on my machine with all kernel > versions >2.6.16. I don't have a clue what the root cause of this lockup is, > thus I'm thinking about using a hardware debugger. Can anybody recommend a > reasonably cheap hardware debugger that works with G4 CPUs and can interact > with GDB/DDD? Abatron BDI-2000. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hardware debuggers for PPC74xx G4 CPUs
I'm trying to debug a kernel lockup that occurs on my machine with all kernel versions >2.6.16. I don't have a clue what the root cause of this lockup is, thus I'm thinking about using a hardware debugger. Can anybody recommend a reasonably cheap hardware debugger that works with G4 CPUs and can interact with GDB/DDD? regards, Gerhard -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel locks up after calling kernel_execve()
On Tue, 2007-11-13 at 22:23 +0100, Gerhard Pircher wrote: > > There are ways, sure, which probably involve adding prink's all over > the > > place to figure it out... could be some DMA issue for example, could > be > > pretty much anything. Have you tried booting an initrd with no disk > > access ? > I tried to boot with a ramdisk, but that didn't help much. I still > locks up > while loading an init program or after entering some commands in > sh shell. Looks like the problem is hidden deep in the kernel. Well, at least the above tells is it's not DMA related. I don't know of any deeply hidden problem, so you are probably hitting something else ... if you have disabled idle, then it may be useful to try instrumenting locks or irq enable/disable. Also, did you try booting with all kernel debug options enabled ? Finally, since the problem seem to have started around a specific kernel version, can you try to bisect the patch that causes it ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Makefile and COMMON_UIMAGE target
I meant DEFAULT_UIMAGE, not COMMON_UIMAGE in the previous message. The patch is right. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Makefile and COMMON_UIMAGE target
If I select Efika (zImage.chrp) and my target (uImage, COMMON_UIMAGE) at the same time. The chrp image doesn't get built. This fixes it, but is it the right fix? What the right to compare CONFIG_DEVICE_TREE to "" if it isn't defined? diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 4e16534..b291f53 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -149,7 +149,7 @@ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/ # Default to zImage, override when needed defaultimage-y := zImage -defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage +#defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage KBUILD_IMAGE := $(defaultimage-y) all: $(KBUILD_IMAGE) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 18e3271..cbbc4ab 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -147,6 +147,7 @@ image-$(CONFIG_PPC_PRPMC2800) += zImage.prpmc2800 image-$(CONFIG_PPC_ISERIES)+= zImage.iseries image-$(CONFIG_DEFAULT_UIMAGE) += uImage +ifdef CONFIG_DEVICE_TREE ifneq ($(CONFIG_DEVICE_TREE),"") image-$(CONFIG_PPC_8xx)+= cuImage.8xx image-$(CONFIG_PPC_EP88XC) += zImage.ep88xc @@ -160,6 +161,7 @@ image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo image-$(CONFIG_SEQUOIA)+= cuImage.sequoia image-$(CONFIG_WALNUT) += treeImage.walnut endif +endif # For 32-bit powermacs, build the COFF and miboot images # as well as the ELF images. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel locks up after calling kernel_execve()
Original-Nachricht > Datum: Sun, 11 Nov 2007 14:55:40 +1100 > Von: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > An: Gerhard Pircher <[EMAIL PROTECTED]> > CC: linuxppc-dev@ozlabs.org > Betreff: Re: Kernel locks up after calling kernel_execve() > > On Sat, 2007-11-10 at 18:11 +0100, Gerhard Pircher wrote: > > Original-Nachricht > > > Datum: Fri, 09 Nov 2007 18:50:29 +1100 > > > Von: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > > > An: Gerhard Pircher <[EMAIL PROTECTED]> > > > CC: linuxppc-dev@ozlabs.org > > > Betreff: Re: Kernel locks up after calling kernel_execve() > > > > Is there a way to debug it without a hardware debugger or can you > > recommend a cheap hardware debugger? > > There are ways, sure, which probably involve adding prink's all over the > place to figure it out... could be some DMA issue for example, could be > pretty much anything. Have you tried booting an initrd with no disk > access ? I tried to boot with a ramdisk, but that didn't help much. I still locks up while loading an init program or after entering some commands in sh shell. Looks like the problem is hidden deep in the kernel. Thanks! Gerhard -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] PowerPC: 4xx uic: add mask_ack callback
This adds uic_mask_ack_irq() callback to PowerPC 4xx uic code
to avoid kernel crash. It is used for edge-triggered interrupts
by handle_uic_irq().
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/uic.c | 18 +-
1 files changed, 17 insertions(+), 1 deletion(-)
--- linux-2.6.orig/arch/powerpc/sysdev/uic.c2007-11-13 18:42:33.0
+0300
+++ linux-2.6/arch/powerpc/sysdev/uic.c 2007-11-13 22:28:01.0 +0300
@@ -97,6 +97,22 @@ static void uic_ack_irq(unsigned int vir
spin_unlock_irqrestore(&uic->lock, flags);
}
+static void uic_mask_ack_irq(unsigned int virq)
+{
+ struct uic *uic = get_irq_chip_data(virq);
+ unsigned int src = uic_irq_to_hw(virq);
+ unsigned long flags;
+ u32 er, sr;
+
+ sr = 1 << (31-src);
+ spin_lock_irqsave(&uic->lock, flags);
+ er = mfdcr(uic->dcrbase + UIC_ER);
+ er &= ~sr;
+ mtdcr(uic->dcrbase + UIC_ER, er);
+ mtdcr(uic->dcrbase + UIC_SR, sr);
+ spin_unlock_irqrestore(&uic->lock, flags);
+}
+
static int uic_set_irq_type(unsigned int virq, unsigned int flow_type)
{
struct uic *uic = get_irq_chip_data(virq);
@@ -152,7 +168,7 @@ static struct irq_chip uic_irq_chip = {
.typename = " UIC ",
.unmask = uic_unmask_irq,
.mask = uic_mask_irq,
-/* .mask_ack = uic_mask_irq_and_ack, */
+ .mask_ack = uic_mask_ack_irq,
.ack= uic_ack_irq,
.set_type = uic_set_irq_type,
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] PowerPC: 4xx uic updates
These patches update 4xx uic code. The first one fixes a minor issue with edge-triggered interrupts, while the second one makes it use generic level and edge irq handlers. I've added irq ack'ing to the unmask callback for level-triggered interrupts, because to de-assert them we have to do 2 things is the exact order as below: 1. de-assert the external source in the ISR. 2. ack the IRQ on the UIC. So, ack'ing level interrupts before unmasking them makes possible to use generic level irq handler and it doesn't hurt, cause we can never miss a level-triggered interrupt. It always stays asserted untill the external source is removed and ack'ed on UIC. These have been tested on Sequoia PowerPC 440EPx board. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Clean out asm/of_{platform, device}.h from sysdev/.
Convert #include of asm/of_{platform, device}.h into
linux/of_{platform,device}.h for remaining arch/powerpc files.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/axonram.c |5 +++--
arch/powerpc/sysdev/pmi.c |4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index 5eaf3e3..d359d6e 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -42,8 +42,9 @@
#include
#include
#include
-#include
-#include
+#include
+#include
+
#include
#include
diff --git a/arch/powerpc/sysdev/pmi.c b/arch/powerpc/sysdev/pmi.c
index 20edd1e..c858749 100644
--- a/arch/powerpc/sysdev/pmi.c
+++ b/arch/powerpc/sysdev/pmi.c
@@ -28,9 +28,9 @@
#include
#include
#include
+#include
+#include
-#include
-#include
#include
#include
#include
--
1.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Clean out asm/of_{platform, device}.h
Convert #include of asm/of_{platform, device}.h into
linux/of_{platform,device}.h for a few scattered platforms.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/embedded6xx/holly.c |2 +-
arch/powerpc/platforms/pasemi/gpio_mdio.c |2 +-
arch/powerpc/platforms/pasemi/setup.c |2 +-
arch/powerpc/platforms/powermac/setup.c|4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/holly.c
b/arch/powerpc/platforms/embedded6xx/holly.c
index b6de2b5..ce91787 100644
--- a/arch/powerpc/platforms/embedded6xx/holly.c
+++ b/arch/powerpc/platforms/embedded6xx/holly.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -39,7 +40,6 @@
#include
#include
#include
-#include
#undef DEBUG
diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c
b/arch/powerpc/platforms/pasemi/gpio_mdio.c
index dae9f65..33409a2 100644
--- a/arch/powerpc/platforms/pasemi/gpio_mdio.c
+++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -30,7 +30,7 @@
#include
#include
#include
-#include
+#include
#define DELAY 1
diff --git a/arch/powerpc/platforms/pasemi/setup.c
b/arch/powerpc/platforms/pasemi/setup.c
index 3a5d112..a4e6b53 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -35,7 +36,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/powerpc/platforms/powermac/setup.c
b/arch/powerpc/platforms/powermac/setup.c
index 02c5330..3acb59d 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -51,6 +51,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -68,8 +70,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
--
1.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
>From b26c62af41b28f87ae2cdf525477670a5ac623fd Mon Sep 17 00:00:00 2001
From: Jon Loeliger <[EMAIL PROTECTED]>
Date: Mon, 12 Nov 2007 14:23:16 -0600
Subject: [PATCH] cell: Convert #include of asm/of_{platform, device}.h into
linux/of_{platform, device}.h.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
Acked-by: Stephen Rothwell <[EMAIL PROTECTED]> Built a ppc64_defconfig
---
This version picks up the celleb/ files too.
Stephen, notice that you tacitly ACK'ed this pickup too... :-)
arch/powerpc/platforms/cell/cbe_cpufreq.c |3 ++-
arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c |3 ++-
arch/powerpc/platforms/cell/cbe_regs.c|4 ++--
arch/powerpc/platforms/cell/iommu.c |2 +-
arch/powerpc/platforms/cell/setup.c |2 +-
arch/powerpc/platforms/celleb/iommu.c |3 +--
arch/powerpc/platforms/celleb/setup.c |2 +-
7 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.c
b/arch/powerpc/platforms/cell/cbe_cpufreq.c
index 13d5a87..ec7c8f4 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ b/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -21,8 +21,9 @@
*/
#include
+#include
+
#include
-#include
#include
#include
#include "cbe_cpufreq.h"
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
b/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
index 6a2c1b0..69288f6 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
+++ b/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
@@ -23,7 +23,8 @@
#include
#include
#include
-#include
+#include
+
#include
#include
#include
diff --git a/arch/powerpc/platforms/cell/cbe_regs.c
b/arch/powerpc/platforms/cell/cbe_regs.c
index 16a9b07..a839c6c 100644
--- a/arch/powerpc/platforms/cell/cbe_regs.c
+++ b/arch/powerpc/platforms/cell/cbe_regs.c
@@ -9,13 +9,13 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
#include
-#include
-#include
#include
/*
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index faabc3f..179ba2e 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -26,13 +26,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
#include
#include
diff --git a/arch/powerpc/platforms/cell/setup.c
b/arch/powerpc/platforms/cell/setup.c
index 98e7ef8..4f6347c 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -51,7 +52,6 @@
#include
#include
#include
-#include
#include
#include "interrupt.h"
diff --git a/arch/powerpc/platforms/celleb/iommu.c
b/arch/powerpc/platforms/celleb/iommu.c
index 755d869..f00396a 100644
--- a/arch/powerpc/platforms/celleb/iommu.c
+++ b/arch/powerpc/platforms/celleb/iommu.c
@@ -22,8 +22,7 @@
#include
#include
#include
-
-#include
+#include
#include "beat_wrapper.h"
diff --git a/arch/powerpc/platforms/celleb/setup.c
b/arch/powerpc/platforms/celleb/setup.c
index 1769d75..116c30b 100644
--- a/arch/powerpc/platforms/celleb/setup.c
+++ b/arch/powerpc/platforms/celleb/setup.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
@@ -51,7 +52,6 @@
#include
#include
#include
-#include
#include "interrupt.h"
#include "beat_wrapper.h"
--
1.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] [POWERPC] mpc832x_rdb_defconfig: enable SPI_MPC83xx and MMC-over-SPI
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/configs/mpc832x_rdb_defconfig | 43 1 files changed, 37 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/configs/mpc832x_rdb_defconfig b/arch/powerpc/configs/mpc832x_rdb_defconfig index 16d54c0..fcda7cc 100644 --- a/arch/powerpc/configs/mpc832x_rdb_defconfig +++ b/arch/powerpc/configs/mpc832x_rdb_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc2 -# Tue Nov 13 19:33:24 2007 +# Tue Nov 13 19:36:27 2007 # # CONFIG_PPC64 is not set @@ -679,8 +679,21 @@ CONFIG_I2C_MPC=y # # SPI support # -# CONFIG_SPI is not set -# CONFIG_SPI_MASTER is not set +CONFIG_SPI=y +CONFIG_SPI_MASTER=y + +# +# SPI Master Controller Drivers +# +CONFIG_SPI_BITBANG=y +CONFIG_SPI_MPC83xx=y + +# +# SPI Protocol Masters +# +# CONFIG_SPI_AT25 is not set +# CONFIG_SPI_SPIDEV is not set +# CONFIG_SPI_TLE62X0 is not set # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set CONFIG_HWMON=y @@ -702,6 +715,7 @@ CONFIG_HWMON=y # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set +# CONFIG_SENSORS_LM70 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set @@ -916,7 +930,24 @@ CONFIG_USB_MON=y # USB Gadget Support # # CONFIG_USB_GADGET is not set -# CONFIG_MMC is not set +CONFIG_MMC=y +# CONFIG_MMC_DEBUG is not set +# CONFIG_MMC_UNSAFE_RESUME is not set + +# +# MMC/SD Card Drivers +# +CONFIG_MMC_BLOCK=y +CONFIG_MMC_BLOCK_BOUNCE=y +# CONFIG_SDIO_UART is not set + +# +# MMC/SD Host Controller Drivers +# +# CONFIG_MMC_SDHCI is not set +# CONFIG_MMC_WBSD is not set +# CONFIG_MMC_TIFM_SD is not set +CONFIG_MMC_SPI=y # CONFIG_NEW_LEDS is not set # CONFIG_INFINIBAND is not set # CONFIG_EDAC is not set @@ -1095,9 +1126,9 @@ CONFIG_UCC=y CONFIG_BITREVERSE=y # CONFIG_CRC_CCITT is not set # CONFIG_CRC16 is not set -# CONFIG_CRC_ITU_T is not set +CONFIG_CRC_ITU_T=y CONFIG_CRC32=y -# CONFIG_CRC7 is not set +CONFIG_CRC7=y # CONFIG_LIBCRC32C is not set CONFIG_PLIST=y CONFIG_HAS_IOMEM=y -- 1.5.2.2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] [POWERPC] mpc832x_rdb_defconfig: update using silentoldconfig
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/configs/mpc832x_rdb_defconfig | 167 ++-- 1 files changed, 84 insertions(+), 83 deletions(-) diff --git a/arch/powerpc/configs/mpc832x_rdb_defconfig b/arch/powerpc/configs/mpc832x_rdb_defconfig index 4f39102..16d54c0 100644 --- a/arch/powerpc/configs/mpc832x_rdb_defconfig +++ b/arch/powerpc/configs/mpc832x_rdb_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc4 -# Tue Aug 28 21:27:19 2007 +# Linux kernel version: 2.6.24-rc2 +# Tue Nov 13 19:33:24 2007 # # CONFIG_PPC64 is not set @@ -21,8 +21,13 @@ CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set # CONFIG_SMP is not set 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_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y @@ -65,6 +70,10 @@ CONFIG_SYSVIPC_SYSCTL=y # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +# CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y @@ -83,7 +92,6 @@ CONFIG_FUTEX=y CONFIG_ANON_INODES=y # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y -CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y @@ -123,7 +131,6 @@ CONFIG_DEFAULT_IOSCHED="anticipatory" # Platform support # # CONFIG_PPC_MULTIPLATFORM is not set -# CONFIG_EMBEDDED6xx is not set # CONFIG_PPC_82xx is not set CONFIG_PPC_83xx=y # CONFIG_PPC_86xx is not set @@ -157,6 +164,10 @@ CONFIG_QUICC_ENGINE=y # Kernel options # # CONFIG_HIGHMEM is not set +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set @@ -178,6 +189,7 @@ CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set +# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 @@ -186,6 +198,8 @@ CONFIG_VIRT_TO_BUS=y CONFIG_PROC_DEVICETREE=y # CONFIG_CMDLINE_BOOL is not set # CONFIG_PM is not set +CONFIG_SUSPEND_UP_POSSIBLE=y +CONFIG_HIBERNATION_UP_POSSIBLE=y CONFIG_SECCOMP=y CONFIG_WANT_DEVICE_TREE=y CONFIG_DEVICE_TREE="" @@ -204,10 +218,7 @@ CONFIG_PCI_SYSCALL=y # CONFIG_PCIEPORTBUS is not set CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set - -# -# PCCARD (PCMCIA/CardBus) support -# +CONFIG_PCI_LEGACY=y # CONFIG_PCCARD is not set # CONFIG_HOTPLUG_PCI is not set @@ -222,7 +233,7 @@ CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE=0x3000 CONFIG_KERNEL_START=0xc000 -CONFIG_TASK_SIZE=0x8000 +CONFIG_TASK_SIZE=0xc000 CONFIG_BOOT_LOAD=0x0080 # @@ -262,6 +273,7 @@ CONFIG_SYN_COOKIES=y CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y CONFIG_INET_XFRM_MODE_BEET=y +# CONFIG_INET_LRO is not set CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set @@ -287,10 +299,6 @@ CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set - -# -# QoS and/or fair queueing -# # CONFIG_NET_SCHED is not set # @@ -319,6 +327,7 @@ CONFIG_DEFAULT_TCP_CONG="cubic" # # Generic Driver Options # +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_FW_LOADER is not set @@ -388,6 +397,7 @@ CONFIG_SCSI_WAIT_SCAN=m # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set +# CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y # CONFIG_ISCSI_TCP is not set # CONFIG_BLK_DEV_3W__RAID is not set @@ -399,6 +409,7 @@ CONFIG_SCSI_LOWLEVEL=y # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_DPT_I2O is not set +# CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set @@ -425,14 +436,7 @@ CONFIG_SCSI_LOWLEVEL=y # CONFIG_SCSI_SRP is not set # CONFIG_ATA is not set # CONFIG_MD is not set - -# -# Fusion MPT device support -# # CONFIG_FUSION is not set -# CONFIG_FUSION_SPI is not set -# CONFIG_FUSION_FC is not set -# CONFIG_FUSION_SAS is not set # # IEEE 1394 (FireWire) support @@ -448,6 +452,8 @@ CONFIG_NETDEVICES=y # CONFIG_MACVLAN is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set +# CONFIG_VETH is not set +# CONFIG_IP1000 is not set # CONFIG_ARCNET is not set CONFIG_PHYLIB=y @@ -464,6 +470,7 @@ CONFIG_PHYLIB=y # CONFIG_BROADCOM_PHY is not set CONFIG_ICPLUS_PHY=y # CONFIG_FIXED_PHY is not set +# CONFIG_M
[PATCH 1/3] [POWERPC] mpc832x_rdb: remove spidev stub, use mmc_spi
mmc_spi has hit the mainline, so we can start using it.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index fbca336..d4bd040 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -15,7 +15,10 @@
*/
#include
+#include
#include
+#include
+#include
#include
#include
@@ -46,15 +49,16 @@ static void mpc83xx_spi_deactivate_cs(u8 cs, u8 polarity)
par_io_data_set(3, 13, !polarity);
}
+static struct mmc_spi_platform_data mpc832x_mmc_pdata = {
+ .ocr_mask = MMC_VDD_33_34,
+};
+
static struct spi_board_info mpc832x_spi_boardinfo = {
.bus_num = 0x4c0,
.chip_select = 0,
.max_speed_hz = 5000,
- /*
-* XXX: This is spidev (spi in userspace) stub, should
-* be replaced by "mmc_spi" when mmc_spi will hit mainline.
-*/
- .modalias = "spidev",
+ .modalias = "mmc_spi",
+ .platform_data = &mpc832x_mmc_pdata,
};
static int __init mpc832x_spi_init(void)
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3] MPC8323E-RDB now using MMC-over-SPI
Hi all, Here are three well-split patches for the easier review. I can fold them into one for the merge, if you like. I've tested the functionality using SD 128MB Kingston (MMC SanDisk 16MB refused to work, but it's definitely not a powerpc issue. Also I'm not sure that that particular card worked at all ;-). Patches should apply cleanly on paulus/powerpc.git and/or galak/powerpc.git, master branches. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup 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] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
On Mon, 2007-11-12 at 19:02, Stephen Rothwell wrote: > Hi Jon, > > Thanks for this. > > On Mon, 12 Nov 2007 14:26:51 -0600 Jon Loeliger <[EMAIL PROTECTED]> wrote: > > > > From: Jon Loeliger <[EMAIL PROTECTED]> > > > > Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]> > > Acked-by: Stephen Rothwell <[EMAIL PROTECTED]> Built a ppc64_defconfig Feh. I'll respin this particular patch to include the platforms/celleb pair of files too. Sorry, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] [POWERPC] Optimize counting distinct entries in the relocation sections
When a module has relocation sections with tens of thousands worth of entries,
counting the distinct/unique entries only (i.e. no duplicates) at load time can
take tens of seconds and up to minutes. The sore point is the count_relocs()
function which is called as part of the architecture specific module loading
processing path:
-> load_module()generic
-> module_frob_arch_sections() arch specific
-> get_plt_size() 32-bit
-> get_stubs_size() 64-bit
-> count_relocs()
(Not sure why the relocation tables could contain lots of duplicates and why
they are not trimmed at compile time by the linker. In some test cases, out of
35K relocation entries only 1.5K were distinct/unique)
The previous counting algorithm was having O(n^2) complexity. Basically two
solutions were proposed on the e-mail list: a hash based approach and a sort
based approach
The hash based approach is the fastest (O(n)) but the has it needs additional
memory and for certain corner cases it could take lots of memory due to the
degeneration of the hash. One such proposal was submitted here:
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html
In this proposal, the symbol + addendum are hashed to generate a key and a
pointer to the relocation entry will be stored in it. The hash is implemented as
a linked list of memory pages with PAGE_SIZE / sizeof(Elfxx_Rela *) entries. In
case of collisions in all the existing pages, a new page is added to the list to
accommodate the new distinct relocation entry
For 32-bit PowerPCs with 4K pages, a page can accommodate 1K worth of pointers
to relocation entries. In the 35K entries scenario, as much/little of six (6)
pages could be allocated using 24K of extra memory during the module load
The sort based approach is slower (O(n * log n + n)) but if the sorting is done
"in place" it doesn't need additional memory. A proposal was submitted here:
http://ozlabs.org/pipermail/linuxppc-dev/2007-November/045854.html
(http://patchwork.ozlabs.org/linuxppc/patch?filter=default&id=14573)
In this proposal an array of pointers to the relocation entries is built and
then is sorted using the kernel sort() utility function. This is basically a
heap
sort algorithm with a stable O(n * log n) complexity. With this counting the
distinct/unique entries is just linear (O(n)) complexity. The problem is the
extra memory needed in this proposal, which in the 35K relocation entries test
case it can be as much as 140K (for 32-bit PowerPCs; double for 64-bit). This is
much more then the memory needed by the hash based approach described
above/earlier but it doesn't hide potential degenerative corner cases
The current patch is a happy compromise between the two proposals above:
O(n + n * log n) performance with no additional memory requirements due to
sorting in place the relocation table itself
Signed-off-by: Emil Medve <[EMAIL PROTECTED]>
---
This patch only tries to address counting the distinct R_PPC_REL24 entries for
the purpose of sizing the PLT. This operation was/can be detected by the proper
kernel logic as a soft lockup for large relocation tables
A related optimization (that could cause rewriting the this patch) is to
optimize the PLT search from do_plt_call() but that doesn't seem to be a
problem right now
The errors below are false positives due to the fact that Elfxx_Rela are
falsely assumed to be variables/operands instead of types:
linux-2.6> scripts/checkpatch.pl
0001-POWERPC-Optimize-counting-distinct-entries-in-the.patch
ERROR: need consistent spacing around '*' (ctx:WxV)
#116: FILE: arch/powerpc/kernel/module_32.c:78:
+ const Elf32_Rela *x, *y;
^
ERROR: need consistent spacing around '*' (ctx:WxV)
#228: FILE: arch/powerpc/kernel/module_64.c:122:
+ const Elf64_Rela *x, *y;
^
total: 2 errors, 0 warnings, 218 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
arch/powerpc/kernel/module_32.c | 77 ++---
arch/powerpc/kernel/module_64.c | 81 ++
2 files changed, 127 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/kernel/module_32.c b/arch/powerpc/kernel/module_32.c
index 07a89a3..eab3138 100644
--- a/arch/powerpc/kernel/module_32.c
+++ b/arch/powerpc/kernel/module_32.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "setup.h"
@@ -54,22 +55,60 @@ void module_free(struct module *mod, void *module_region)
addend) */
static unsigned int count_relocs(const Elf32_Rela *rela, unsigned int num)
{
- unsigned int i, j, ret = 0;
-
- /* Sure, this is order(n^2), but it's usually short, and not
- time critical */
- for (i = 0; i < num; i++) {
- for (j = 0; j < i; j++) {
-
Re: [PATCH v3] fix multiple bugs in rtas_ibm_suspend_me code
Nathan Lynch wrote: > > 3.) H_JOIN must be called with MSR[EE] off, but lazy interrupt > disabling may cause the caller of rtas_ibm_suspend_me to call H_JOIN > with it on; the local_irq_disable() in on_each_cpu() is not > sufficient. > > Fix this by explicitly saving the MSR and clearing the EE bit before > calling H_JOIN. ... > + atomic_inc(&data->working); > + > + /* really need to ensure MSR.EE is off for H_JOIN */ > + msr_save = mfmsr(); > + mtmsr(msr_save & ~(MSR_EE)); > + > + rc = plpar_hcall_norets(H_JOIN); > + > + mtmsr(msr_save); BTW, I'm wondering if this is the right way to do this. I think there's the possibility that we could enter this routine hard-enabled and take take an interrupt between the mfmsr and the first mtmsr, but I haven't worked out all the implications. Would hard_irq_disable be better? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] fix multiple bugs in rtas_ibm_suspend_me code
There are several issues with the rtas_ibm_suspend_me code, which
enables platform-assisted suspension of an LPAR for migration or
hibernation as covered in PAPR 2.2.
1.) rtas_ibm_suspend_me uses on_each_cpu() to invoke
rtas_percpu_suspend_me on all cpus via IPI:
if (on_each_cpu(rtas_percpu_suspend_me, &data, 1, 0))
...
'data' is on the calling task's stack, but rtas_ibm_suspend_me takes
no measures to ensure that all instances of rtas_percpu_suspend_me are
finished accessing 'data' before returning. This can result in the
IPI'd cpus accessing random stack data and getting stuck in H_JOIN.
This is addressed by using an atomic count of workers and a completion
on the stack.
2.) rtas_percpu_suspend_me is needlessly calling H_JOIN in a loop.
The only event that can cause a cpu to return from H_JOIN is an H_PROD
from another cpu or a NMI/system reset. Each cpu need call H_JOIN
only once per suspend operation.
Remove the loop and the now unnecessary 'waiting' state variable.
3.) H_JOIN must be called with MSR[EE] off, but lazy interrupt
disabling may cause the caller of rtas_ibm_suspend_me to call H_JOIN
with it on; the local_irq_disable() in on_each_cpu() is not
sufficient.
Fix this by explicitly saving the MSR and clearing the EE bit before
calling H_JOIN.
4.) H_PROD is being called with the Linux logical cpu number as the
parameter, not the platform interrupt server value. (It's also being
called for all possible cpus, which is harmless, but unnecessary.)
This is fixed by calling H_PROD for each online cpu using
get_hard_smp_processor_id(cpu) for the argument.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
---
Paul Mackerras wrote:
>
> On a uniprocessor configuration, with this patch I get:
>
> CC arch/powerpc/kernel/rtas.o
> /home/paulus/kernel/powerpc/arch/powerpc/kernel/rtas.c: In function
> ‘rtas_percpu_suspend_me’:
> /home/paulus/kernel/powerpc/arch/powerpc/kernel/rtas.c:702: error: implicit
> declaration of function ‘get_hard_smp_processor_id
> make[2]: *** [arch/powerpc/kernel/rtas.o] Error 1
>
> I think you need to #include in rtas.c.
Rather sloppy of me, sorry.
Changes since v2:
- Add appropriate #includes for APIs used, fixing SMP=n build
Changes since v1:
- the completion is adequate for ensuring that all IPIs have
completed, so there's no need for a mutex and rtas_suspend_me_data
can be on the stack as before.
- add fix for hard-disabling interrupts before H_JOIN
- remove unnecessary H_JOIN loop and state machinery
arch/powerpc/kernel/rtas.c | 99 ++--
1 files changed, 58 insertions(+), 41 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 2147807..52e95c2 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -19,6 +19,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -34,6 +37,8 @@
#include
#include
#include
+#include
+#include
struct rtas_t rtas = {
.lock = SPIN_LOCK_UNLOCKED
@@ -41,8 +46,10 @@ struct rtas_t rtas = {
EXPORT_SYMBOL(rtas);
struct rtas_suspend_me_data {
- long waiting;
- struct rtas_args *args;
+ atomic_t working; /* number of cpus accessing this struct */
+ int token; /* ibm,suspend-me */
+ int error;
+ struct completion *complete; /* wait on this until working == 0 */
};
DEFINE_SPINLOCK(rtas_data_buf_lock);
@@ -657,50 +664,62 @@ static int ibm_suspend_me_token = RTAS_UNKNOWN_SERVICE;
#ifdef CONFIG_PPC_PSERIES
static void rtas_percpu_suspend_me(void *info)
{
- int i;
long rc;
- long flags;
+ unsigned long msr_save;
+ int cpu;
struct rtas_suspend_me_data *data =
(struct rtas_suspend_me_data *)info;
- /*
-* We use "waiting" to indicate our state. As long
-* as it is >0, we are still trying to all join up.
-* If it goes to 0, we have successfully joined up and
-* one thread got H_CONTINUE. If any error happens,
-* we set it to <0.
-*/
- local_irq_save(flags);
- do {
- rc = plpar_hcall_norets(H_JOIN);
- smp_rmb();
- } while (rc == H_SUCCESS && data->waiting > 0);
- if (rc == H_SUCCESS)
- goto out;
+ atomic_inc(&data->working);
+
+ /* really need to ensure MSR.EE is off for H_JOIN */
+ msr_save = mfmsr();
+ mtmsr(msr_save & ~(MSR_EE));
+
+ rc = plpar_hcall_norets(H_JOIN);
+
+ mtmsr(msr_save);
- if (rc == H_CONTINUE) {
- data->waiting = 0;
- data->args->args[data->args->nargs] =
- rtas_call(ibm_suspend_me_token, 0, 1, NULL);
- for_each_possible_cpu(i)
- plpar_hcall_norets(H_PROD,i);
+ if (rc == H_SUCCESS) {
+ /* This cpu was prodded and the suspend is complete. */
+ goto out;
+ } else if (rc == H_CONTI
Re: [PATCH] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
So, like, the other day Stephen Rothwell mumbled: > > Hi Jon, > > Thanks for this. Most welcome. I'm assuming I can chip away at _all_ of these, including the ones in the drivers/ directories as well. I haven't a clue who will really pick all these up. We could arrange for Paul to grab the arch/powerpc. But the rest? Mr Morton perhaps? jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2/2] dtc: Add testcase for dtc references
So, like, the other day David Gibson mumbled: > This patch adds a testcase for dtc's reference-to-phandle > functionality. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [1/2] libfdt: Add phandle related functions
So, like, the other day David Gibson mumbled: > This patch adds fdt_get_phandle() and fdt_node_offset_by_phandle() > functions to libfdt. fdt_get_phandle() will retreive the phandle > value of a given node, and fdt_node_offset_by_phandle() will locate a > node given a phandle. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Add missing dependencies for tests
So, like, the other day David Gibson mumbled: > At present, the Makefiles will not rebuild trees.o or the dtb files > derived from it if testdata.h is updated. This is incorrect, and is > because of missing dependency information. > > This patch fixes the problem by making sure that dependency > information is generated from trees.S and dumptrees.c. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
> Isn't it true that the freezer _already_ isn't enabled on PPC? So > leaving it off wouldn't break anything more than it is broken now. Indeed. johannes 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: [RFC] PMU: replace information ioctls and schedule for removal
On Tue, 2007-11-13 at 10:15 +1100, Paul Mackerras wrote: > Johannes Berg writes: > > > Does anybody need that? I'm not against adding it but we never showed it > > and I haven't seen anyone ask for it. > > pmud uses the PMU version, but I think it gets it by issuing a PMU > command. Yeah, it probably has to since I don't see us exporting it anywhere. Do we want to change pmud to read it from elsewhere? I guess I'll just add it to sysfs and it can use it if it wants. johannes 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
Please pull powerpc.git merge branch
Linus, Please do git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get a few more bug-fixes for powerpc. (OK, two of the commits are cosmetic printk changes and one is a workaround for a hardware erratum, but they are all reasonable 2.6.24 material.) Thanks, Paul. arch/powerpc/Makefile|3 +++ arch/powerpc/kernel/btext.c |4 +++- arch/powerpc/kernel/entry_32.S |6 ++ arch/powerpc/kernel/time.c |2 +- arch/powerpc/mm/init_64.c| 16 arch/powerpc/mm/tlb_64.c |2 -- arch/powerpc/sysdev/cpm_common.c |4 +--- arch/ppc/kernel/entry.S |6 ++ include/asm-powerpc/cputable.h | 22 -- include/asm-powerpc/tlbflush.h |4 ++-- 10 files changed, 38 insertions(+), 31 deletions(-) Becky Bruce (1): [POWERPC] Avoid unpaired stwcx. on some processors Benjamin Herrenschmidt (1): [POWERPC] Fix early btext debug on PowerMac Kumar Gala (2): [POWERPC] Add -mno-spe for ARCH=powerpc builds [POWERPC] Fix oops related to 4xx flush_tlb_page modification Olof Johansson (1): [POWERPC] Fix CONFIG_SMP=n build error on ppc64 Scott Wood (1): [POWERPC] cpm: Fix a couple minor issues in cpm_common.c. Stephen Rothwell (1): [POWERPC] Silence an annoying boot message Tony Breeds (1): [POWERPC] Demote clockevent printk to KERN_DEBUG ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: printk/console_init
On Mon, 2007-11-12 at 18:54 -0800, Siva Prasad wrote: > Hi, > > I am using 2.6.19 Linux on 8641D based system. > > I am using early printk's and it works fine until console_init() is > executed. After that it does not, as the early printk's get disabled, > which is fine. However, I don't see any prints after that at all, that > are based on regular printk statements. I looked directly into the > memory at __log_buf and found all the print messages. It is just not > coming out to the serial port properly. > > It would be great if some one can tell me various parameters that I need > to consider changing, to successfully port the serial driver for a new > board. > > Based on the early printk's, I am getting the following messages... You can use udbg-immortal to force the udbg early printk to stay around, and then use printk to see what's going on with your serial driver. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Merge pci_process_bridge_OF_ranges()
On Tue, 2007-11-13 at 01:06 -0600, Olof Johansson wrote: > On Tue, Nov 13, 2007 at 03:43:51PM +1100, Benjamin Herrenschmidt wrote: > > > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > > --- > > > > Tested on a few pSeries, PowerMac G5, and a 32 bits PowerMacs and > > a BriQ. Please let me know if it misbehaves anywhere else. > > Looks good on the eval boards I tested here. > > Acked-by: Olof Johansson <[EMAIL PROTECTED]> Thanks for testing. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: Make isa_mem_base common to 32 and 64 bits
> > +/* ISA Memory physical address (or 0 if none) */ > > > +resource_size_t isa_mem_base= 0; > > Let's hope this doesn't confuse too many people, as 0 is the valid value on > legacy PC hardware ;-) True, but that's been our default so far so I'm just not changing existing behaviour. If it's bogus, it will need a separate fix. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: Make isa_mem_base common to 32 and 64 bits
On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote: > This defines isa_mem_base on both 32 and 64 bits (it used to be 32 bits > only). This avoids a few ifdef's in later patches and potentially can > allow support for VGA text mode on 64 bits powerpc. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > > Small cleanup pre-requisite for my next patch > > arch/powerpc/kernel/pci-common.c |4 > arch/powerpc/kernel/pci_32.c |1 - > include/asm-powerpc/io.h |5 +++-- > 3 files changed, 7 insertions(+), 3 deletions(-) > > Index: linux-work/arch/powerpc/kernel/pci-common.c > === > --- linux-work.orig/arch/powerpc/kernel/pci-common.c 2007-11-13 > 14:11:11.0 +1100 > +++ linux-work/arch/powerpc/kernel/pci-common.c 2007-11-13 > 14:15:43.0 +1100 > @@ -52,6 +52,10 @@ int global_phb_number; /* Global phb co > > extern struct list_head hose_list; > > +/* ISA Memory physical address (or 0 if none) */ > +resource_size_t isa_mem_base= 0; Let's hope this doesn't confuse too many people, as 0 is the valid value on legacy PC hardware ;-) With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center 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/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: printk/console_init
On Mon, 12 Nov 2007, Siva Prasad wrote: > I am using 2.6.19 Linux on 8641D based system. > > I am using early printk's and it works fine until console_init() is > executed. After that it does not, as the early printk's get disabled, > which is fine. However, I don't see any prints after that at all, that > are based on regular printk statements. I looked directly into the > memory at __log_buf and found all the print messages. It is just not > coming out to the serial port properly. > > It would be great if some one can tell me various parameters that I need > to consider changing, to successfully port the serial driver for a new > board. > > Based on the early printk's, I am getting the following messages... > > Using MPC86xx HPCN machine description > Total memory = 1024MB; using 2048kB for hash table (at cfe0) > Linux version 2.6.19 ([EMAIL PROTECTED]) (gcc version 4.1.1 > 20060525 (Red Hat 4.1.1-1)) #115 SMP Mon Nov 12 18:21:43 PST 2007 > Found legacy serial port 0 for /[EMAIL PROTECTED]/[EMAIL PROTECTED] > mem=ff704500, taddr=ff704500, irq=1a, clk=1496250, speed=0 > Found MPC86xx PCIE host bridge at 0xff708000. Firmware bus > number: 0->254 > Found MPC86xx PCIE host bridge at 0xff709000. Firmware bus > number: 0->255 > MPC86xx HPCN board from Freescale Semiconductor > Zone PFN ranges: > DMA 0 -> 196608 > Normal 196608 -> 196608 > HighMem196608 -> 262144 > early_node_map[1] active PFN ranges > 0:0 -> 262144 > start_kernel: 8 2200. > Built 1 zonelists. Total pages: 260096 > Kernel command line: console=ttyS0,115200 root=/dev/sda8 > mpic: Setting up MPIC " MPIC " version 1.2 at ff74, max 2 CPUs > mpic: ISU size: 16, shift: 4, mask: f > mpic: Initializing for 80 sources > PID hash table entries: 4096 (order: 12, 16384 bytes) > time_init: decrementer frequency = 150.00 MHz > time_init: processor frequency = 1496.25 MHz > < Nothing gets printed after this ...> Did your serial driver (a) call register_console() (b) using the correct name? With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center 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/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] consolidate struct pci_controller
On Nov 13, 2007, at 2:06 AM, Olof Johansson wrote: > On Tue, Nov 13, 2007 at 04:37:07PM +1100, Stephen Rothwell wrote: > >> This one clashes slightly with Benh's "Merge >> pci_process_bridge_OF_ranges()" >> patch. > > Hi Stephen, > > For the small fields that use standard types, you should just be able > to still define them for ppc32 and just not use them. Alternatively, > if the 32-bit guys complain about wasted bytes of memory, bunch up the > ppc64-only fields together for a single ifdef. I doubt we'll complain too much for a struct that might have one or two instances at most. But I think the ifdef's might be useful to people to see what code still needs to get merged between ppc32 & ppc64. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] consolidate struct pci_controller
On Tue, Nov 13, 2007 at 04:37:07PM +1100, Stephen Rothwell wrote: > This one clashes slightly with Benh's "Merge pci_process_bridge_OF_ranges()" > patch. Hi Stephen, For the small fields that use standard types, you should just be able to still define them for ppc32 and just not use them. Alternatively, if the 32-bit guys complain about wasted bytes of memory, bunch up the ppc64-only fields together for a single ifdef. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
