Re: [PATCH] kexec memory ranges dynamic allocation
2008/10/31 Simon Horman [EMAIL PROTECTED]
Hi,
Could someone please comment on the satus of this patch?
Hello, Simon
I can not reproduce error which you wrote before on my target. So it is a
little bit
difficult to say what was wrong exactly.
On Wed, Oct 15, 2008 at 12:46:24PM +0400, Maxim Uvarov wrote:
Patch corrected. ( git_kexec_powerpc_v2.patch is attached.)
I tested it on ppc64 pasemi electra board. Both kexec -l and kexec -p
works.
Maxim.
2008/10/15 Simon Horman [EMAIL PROTECTED]
On Tue, Oct 14, 2008 at 07:11:19PM +0400, Maxim Uvarov wrote:
Hello all,
As you all know it is not easy to count exact value of memory ranges
from
device tree on powerpc.
It very depends on how dts file was written. What do you think about
really
dynamic allocation buffers
for this buffers?
Conceptually I have no objections to the change,
though I would like to get some review from ppc people.
(linuxppc-dev@ozlabs.org CCed)
Patch is attached.
This patch doesn't seem to compile for me.
# powerpc64-unknown-linux-gnu-gcc --version
powerpc64-unknown-linux-gnu-gcc (GCC) 4.1.1
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
#make
[snip]
kexec/arch/ppc64/kexec-ppc64.c:100: warning: function declaration isn't
a
prototype
kexec/arch/ppc64/kexec-ppc64.c: In function 'realloc_memory_ranges':
kexec/arch/ppc64/kexec-ppc64.c:107: warning: passing argument 1 of
'realloc' makes pointer from integer without a cast
kexec/arch/ppc64/kexec-ppc64.c:107: error: too few arguments to
function
'realloc'
kexec/arch/ppc64/kexec-ppc64.c:102: warning: unused variable 'tmp'
--
Simon Horman
VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
H: www.vergenet.net/~horms/ http://www.vergenet.net/%7Ehorms/
http://www.vergenet.net/%7Ehorms/
W: www.valinux.co.jp/en
--
Best regards,
Maxim Uvarov
diff --git a/kexec/arch/ppc64/kexec-ppc64.c
b/kexec/arch/ppc64/kexec-ppc64.c
index 069a9fc..0ad40fa 100644
--- a/kexec/arch/ppc64/kexec-ppc64.c
+++ b/kexec/arch/ppc64/kexec-ppc64.c
@@ -96,96 +96,46 @@ err1:
}
-static int count_dyn_reconf_memory_ranges(void)
+static int realloc_memory_ranges()
{
- char device_tree[] = /proc/device-tree/;
- char fname[128];
- char buf[32];
- FILE *file;
-
- strcpy(fname, device_tree);
- strcat(fname, ibm,dynamic-reconfiguration-memory/ibm,lmb-size);
- if ((file = fopen(fname, r)) == NULL) {
- perror(fname);
- return -1;
- }
+ size_t memory_range_len;
- if (fread(buf, 1, 8, file) 0) {
- perror(fname);
- fclose(file);
- return -1;
- }
-
- lmb_size = ((uint64_t *)buf)[0];
- fclose(file);
+ max_memory_ranges++;
+ memory_range_len = sizeof(struct memory_range) * max_memory_ranges;
- /* Get number of lmbs from ibm,dynamic-memory */
- strcpy(fname, device_tree);
- strcat(fname,
ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory);
- if ((file = fopen(fname, r)) == NULL) {
- perror(fname);
- return -1;
- }
- /*
- * first 4 bytes provide number of entries(lmbs)
- */
- if (fread(buf, 1, 4, file) 0) {
- perror(fname);
- fclose(file);
- return -1;
- }
- num_of_lmbs = ((unsigned int *)buf)[0];
- max_memory_ranges += num_of_lmbs;
- fclose(file);
+ memory_range = (struct memory_range *) realloc(memory_range,
memory_range_len);
+ if (!memory_range)
+ goto err;
- return 0;
-}
+ base_memory_range = (struct memory_range *) realloc(memory_range,
memory_range_len);
+ if (!base_memory_range)
+ goto err;
-/*
- * Count the memory nodes under /proc/device-tree and populate the
- * max_memory_ranges variable. This variable replaces MAX_MEMORY_RANGES
- * macro used earlier.
- */
-static int count_memory_ranges(void)
-{
- char device_tree[256] = /proc/device-tree/;
- struct dirent *dentry;
- DIR *dir;
+ exclude_range = (struct memory_range *) realloc(exclude_range,
memory_range_len);
+ if (!exclude_range)
+ goto err;
- if ((dir = opendir(device_tree)) == NULL) {
- perror(device_tree);
- return -1;
- }
+ usablemem_rgns.ranges = (struct memory_range *)
+ realloc(usablemem_rgns.ranges,
memory_range_len);
+ if (!(usablemem_rgns.ranges))
+ goto err;
- while ((dentry = readdir(dir)) != NULL) {
- if (!strncmp(dentry-d_name,
-
Please pull from 'merge' (updated)(for 2.6.28)
Please pull from 'merge' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge to receive the following updates: arch/powerpc/boot/dts/mpc8313erdb.dts| 39 --- arch/powerpc/configs/linkstation_defconfig | 11 ++ arch/powerpc/platforms/embedded6xx/linkstation.c | 14 3 files changed, 19 insertions(+), 45 deletions(-) Guennadi Liakhovetski (1): powerpc: fix i2c on PPC linkstation / kurobox machines Mike Dyer (1): powerpc: Remove duplicate DMA entry from mpc8313erdb device tree Rogério Brito (2): powerpc: compile kernel for linkstations optimized for size powerpc: enable heap randomization for linkstations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
CONFIG_PCI_LEGACY and defconfigs
Hi all, As you are updating the defconfigs, please have a look at removing CONFIG_PCI_LEGACY. It should be able to be removed from all powerpc defconfigs with little, if any effect, I think. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpcnqWiFVBhp.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] spi: Add PPC4xx SPI driver
On Wednesday 29 October 2008, Josh Boyer wrote:
Looks pretty good. Just a few minor comments/questions below.
Thanks. I also added some comments below.
Also, do you have a patch for a DTS file that gives an example of how to
instantiate the SPI stuff in the device tree?
OK, I'll add a DTS patch to the next version.
diff --git a/drivers/spi/spi_ppc4xx.c b/drivers/spi/spi_ppc4xx.c
new file mode 100644
index 000..6f94acc
--- /dev/null
+++ b/drivers/spi/spi_ppc4xx.c
+#include linux/module.h
+#include linux/init.h
+#include linux/sched.h
+#include linux/errno.h
+#include linux/wait.h
+#include linux/of_platform.h
+#include linux/of_spi.h
+#include linux/of_gpio.h
+#include linux/interrupt.h
+#include linux/delay.h
+
+#include linux/gpio.h
+#include linux/spi/spi.h
+#include linux/spi/spi_bitbang.h
+
+#include asm/io.h
+#include asm/dcr-native.h
Should maybe just be asm/dcr.h
Fixed.
+#include asm/dcr-regs.h
+
snip
+/* SPI Controller driver's private data. */
+struct ppc4xx_spi {
+/* bitbang has to be first */
+struct spi_bitbang bitbang;
+struct completion done;
+
+u64 mapbase;
+u64 mapsize;
+int irqnum;
+/* need this to set the SPI clock */
+unsigned int opb_freq;
+
+/* for transfers */
+int len;
+int count;
+/* data buffers */
+const unsigned char *tx;
+unsigned char *rx;
+
+int *gpios;
+unsigned int num_gpios;
+
+volatile struct spi_ppc4xx_regs __iomem *regs; /* pointer to the
registers */
volatile?
Fixed.
+struct spi_master *master;
+struct device *dev;
+};
snip
+static int spi_ppc4xx_txrx(struct spi_device *spi, struct spi_transfer
*t) +{
+struct ppc4xx_spi *hw;
+u8 data;
+
+dev_dbg(spi-dev, txrx: tx %p, rx %p, len %d\n,
+t-tx_buf, t-rx_buf, t-len);
+
+hw = spi_master_get_devdata(spi-master);
+
+hw-tx = t-tx_buf;
+hw-rx = t-rx_buf;
+hw-len = t-len;
+hw-count = 0;
+
+/* send the first byte */
+data = hw-tx ? hw-tx[0] : 0;
+out_8(hw-regs-txd, data);
+out_8(hw-regs-cr, SPI_PPC4XX_CR_STR);
Maybe iowrite8? Same comment elsewhere.
Why? We use the in_/out_xxx() accessor function for all other 4xx driver as
well.
+wait_for_completion(hw-done);
+
+return hw-count;
+}
+
snip
+static struct of_device_id spi_ppc4xx_of_match[] = {
+{ .compatible = ibm,spi, },
+{},
+};
I'm wondering if that is too generic of a match. In theory,
IBM could have another SPI controller that isn't for 4xx.
Maybe ibm,spi-4xx ?
Right. I was doing it the same way as already done before, e.g. ibm,iic. For
the gpio driver we already switched to ibm,ppc4xx-gpio. So how
about ibm,ppc4xx-spi?
Thanks.
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] spi: Add PPC4xx SPI driver
On Fri, 31 Oct 2008 09:31:19 +0100
Stefan Roese [EMAIL PROTECTED] wrote:
On Wednesday 29 October 2008, Josh Boyer wrote:
Looks pretty good. Just a few minor comments/questions below.
Thanks. I also added some comments below.
Also, do you have a patch for a DTS file that gives an example of how to
instantiate the SPI stuff in the device tree?
OK, I'll add a DTS patch to the next version.
Ok thanks.
+ /* send the first byte */
+ data = hw-tx ? hw-tx[0] : 0;
+ out_8(hw-regs-txd, data);
+ out_8(hw-regs-cr, SPI_PPC4XX_CR_STR);
Maybe iowrite8? Same comment elsewhere.
Why? We use the in_/out_xxx() accessor function for all other 4xx driver as
well.
Yeah. We used to have all of 4xx in arch/ppc too. ;)
Seriously though, it doesn't really bother me too much. The
io{read,write} functions do have a bit better clarity as to endian-ness
though.
+ wait_for_completion(hw-done);
+
+ return hw-count;
+}
+
snip
+static struct of_device_id spi_ppc4xx_of_match[] = {
+ { .compatible = ibm,spi, },
+ {},
+};
I'm wondering if that is too generic of a match. In theory,
IBM could have another SPI controller that isn't for 4xx.
Maybe ibm,spi-4xx ?
Right. I was doing it the same way as already done before, e.g. ibm,iic.
For
the gpio driver we already switched to ibm,ppc4xx-gpio. So how
about ibm,ppc4xx-spi?
Sounds fine to me.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rc1: NVRAM being corrupted on ppc64 preventing boot (bisected)
On Fri, Oct 31, 2008 at 07:52:02AM +1100, Paul Mackerras wrote: Mel Gorman writes: On some ppc64 machines, NVRAM is being corrupted very early in boot (before console is initialised). The machine reboots and then fails to find yaboot printing the error PReP-BOOT: Unable to load PRep image. It's nowhere near as serious as the ftrace+e1000 problem as the machine is not bricked but it's fairly scary looking, the machine cannot boot and the fix is non-obvious. To fix the machine; 1. Go to OpenFirmware prompt 2. type dev nvram 3. type wipe-nvram The machine will reboot, reconstruct the NVRAM using some magic and yaboot work again allowing an older kernel to be used. I bisected the problem down to this commit. Eek! Which ppc64 machines has this been seen on, and how were they being booted (netboot, yaboot, etc.)? Yaboot in my case and I've heard it affected a DVD installation. I don't know for sure if it affects netboot but as I think it's something the kernel is doing, it probably doesn't matter how it gets loaded? Is it just the Powerstations with their SLOF-based firmware, or is it IBM pSeries machines as well? To be honest, I haven't been brave enough to try this on a Powerstation yet as I only have the one and I don't know if it's a) affected or b) fixable with the same workaround. It was an IBM pSeries that was affected in my case and a few people have hit the problem on pSeries AFARIK. It's been pointed out that it can be fixed by upgrading the firmware but surely we can avoid breaking the machine in the first place? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] spi: Add PPC4xx SPI driver
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Signed-off-by: Wolfgang Ocker [EMAIL PROTECTED]
---
Changes in v4:
- Added fixes suggested by Josh Boyer
- Changed compatible property from ibm,spi to ibm,ppc4xx-spi
Changes in v3:
- When the device is removed the GPIOs are released. The memory
for the GPIO array is freed.
Changes in v2:
- Now the gpios property is correctly decoded and the
resulting gpio numbers are used as the devices chip
selects.
So we can describe the SPI node like this:
SPI0: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
...
/* two GPIOs, representing two chip selects: 0 and 1 */
gpios = GPIO0 5 0 GPIO1 16 0;
[EMAIL PROTECTED] {
reg = 0;
...
};
[EMAIL PROTECTED] {
reg = 1;
...
};
}
Special thanks to Wolfgang Ocker and Anton Vorontsov for their input.
drivers/spi/Kconfig |7 +
drivers/spi/Makefile |1 +
drivers/spi/spi_ppc4xx.c | 594 ++
3 files changed, 602 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/spi_ppc4xx.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b9d0efb..69d5fee 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -155,6 +155,13 @@ config SPI_ORION
help
This enables using the SPI master controller on the Orion chips.
+config SPI_PPC4xx
+ tristate PPC4xx SPI Controller
+ depends on 4xx SPI_MASTER
+ select SPI_BITBANG
+ help
+ This selects a driver for the PPC4xx SPI Controller.
+
config SPI_PXA2XX
tristate PXA2xx SSP SPI master
depends on ARCH_PXA EXPERIMENTAL
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index ccf18de..a2e5816 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_SPI_OMAP24XX)+= omap2_mcspi.o
obj-$(CONFIG_SPI_ORION)+= orion_spi.o
obj-$(CONFIG_SPI_MPC52xx_PSC) += mpc52xx_psc_spi.o
obj-$(CONFIG_SPI_MPC83xx) += spi_mpc83xx.o
+obj-$(CONFIG_SPI_PPC4xx) += spi_ppc4xx.o
obj-$(CONFIG_SPI_S3C24XX_GPIO) += spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
obj-$(CONFIG_SPI_TXX9) += spi_txx9.o
diff --git a/drivers/spi/spi_ppc4xx.c b/drivers/spi/spi_ppc4xx.c
new file mode 100644
index 000..cfdb57d
--- /dev/null
+++ b/drivers/spi/spi_ppc4xx.c
@@ -0,0 +1,594 @@
+/*
+ * SPI_PPC4XX SPI controller driver.
+ *
+ * Copyright (C) 2007 Gary Jennejohn [EMAIL PROTECTED]
+ * Copyright 2008 Stefan Roese [EMAIL PROTECTED], DENX Software Engineering
+ *
+ * Based in part on drivers/spi/spi_s3c24xx.c
+ *
+ * Copyright (c) 2006 Ben Dooks
+ * Copyright (c) 2006 Simtec Electronics
+ * Ben Dooks [EMAIL PROTECTED]
+ *
+ * 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 linux/module.h
+#include linux/init.h
+#include linux/sched.h
+#include linux/errno.h
+#include linux/wait.h
+#include linux/of_platform.h
+#include linux/of_spi.h
+#include linux/of_gpio.h
+#include linux/interrupt.h
+#include linux/delay.h
+
+#include linux/gpio.h
+#include linux/spi/spi.h
+#include linux/spi/spi_bitbang.h
+
+#include asm/io.h
+#include asm/dcr.h
+#include asm/dcr-regs.h
+
+/* bits in mode register - bit 0 ist MSb */
+/* data latched on leading edge of clock, else trailing edge */
+#define SPI_PPC4XX_MODE_SCP(0x80 3)
+/* port enabled */
+#define SPI_PPC4XX_MODE_SPE(0x80 4)
+/* MSB first, else LSB first */
+#define SPI_PPC4XX_MODE_RD (0x80 5)
+/* clock invert - idle clock = 1, active clock = 0; else reversed */
+#define SPI_PPC4XX_MODE_CI (0x80 6)
+/* loopback enable */
+#define SPI_PPC4XX_MODE_IL (0x80 7)
+/* bits in control register */
+/* starts a transfer when set */
+#define SPI_PPC4XX_CR_STR (0x80 7)
+/* bits in status register */
+/* port is busy with a transfer */
+#define SPI_PPC4XX_SR_BSY (0x80 6)
+/* RxD ready */
+#define SPI_PPC4XX_SR_RBR (0x80 7)
+
+/* the spi-mode bits understood by this driver: */
+#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST)
+
+/* clock settings (SCP and CI) for various SPI modes */
+#define SPI_CLK_MODE0 SPI_PPC4XX_MODE_SCP
+#define SPI_CLK_MODE1 0
+#define SPI_CLK_MODE2 SPI_PPC4XX_MODE_CI
+#define SPI_CLK_MODE3 (SPI_PPC4XX_MODE_SCP | SPI_PPC4XX_MODE_CI)
+
+#define DRIVER_NAMEspi_ppc4xx_of
+
+struct spi_ppc4xx_regs {
+ u8 mode;
+ u8 rxd;
+ u8 txd;
+ u8 cr;
+ u8 sr;
+ u8 dummy;
+ /*
+
[PATCH] powerpc/4xx: Add GPIO, SPI and MMC suport to the Arches
This patch adds GPIO, SPI MMC (for onboard uSD) support to the
Arches dts
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/arches.dts | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/arches.dts b/arch/powerpc/boot/dts/arches.dts
index d9113b1..c568095 100644
--- a/arch/powerpc/boot/dts/arches.dts
+++ b/arch/powerpc/boot/dts/arches.dts
@@ -195,6 +195,38 @@
interrupts = 0x3 0x4;
};
+ SPI0: [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = spi;
+ compatible = ibm,spi-460gt, ibm,ppc4xx-spi;
+ reg = 0xef600900 7;
+ interrupt-parent = UIC1;
+ interrupts = 2 4;
+
+ /* gpio(s) representing chip select(s) */
+ gpios = GPIO1 11 0;
+
+ [EMAIL PROTECTED] {
+ compatible = linux,mmc-spi, mmc-spi;
+ reg = 0;
+ spi-max-frequency = 1000;
+ voltage-range = 3300 3300;
+ };
+ };
+
+ GPIO0: [EMAIL PROTECTED] {
+ #gpio-cells = 2;
+ compatible = ibm,460gt-gpio,ibm,ppc4xx-gpio;
+ reg = 0xef600b00 38;
+ };
+
+ GPIO1: [EMAIL PROTECTED] {
+ #gpio-cells = 2;
+ compatible = ibm,460gt-gpio,ibm,ppc4xx-gpio;
+ reg = 0xef600c00 38;
+ };
+
TAH0: [EMAIL PROTECTED] {
compatible = ibm,tah-460gt, ibm,tah;
reg = 0xef601350 0x0030;
--
1.6.0.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rc1: NVRAM being corrupted on ppc64 preventing boot (bisected)
Mel Gorman writes: Yaboot in my case and I've heard it affected a DVD installation. I don't know for sure if it affects netboot but as I think it's something the kernel is doing, it probably doesn't matter how it gets loaded? What changed in that commit was the contents of a couple of structures that the firmware looks at to see what the kernel wants from firmware. Specifically the change was to say that the kernel (or really the zImage wrapper) would like the firmware to be based at the 32MB point (which is what AIX uses) rather than 12MB (which was the default on older machines). So, as I understand it, it's not anything the kernel is actively doing, it's how the firmware is reacting to what the kernel says it wants. And since we are requesting the same value as AIX (as far as I know) I'm really surprised it caused problems. We can revert that commit, but I still need to solve the problem that the distros are facing, namely that their installer kernel + initramfs images are now bigger than 12MB and can't be loaded if the firmware is based at 12MB. That's why I really want to understand the problem in more detail. It's been pointed out that it can be fixed by upgrading the firmware but surely we can avoid breaking the machine in the first place? Have you upgraded the firmware on the machine you saw this problem on? If not, would you be willing to run some tests for me? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rc1: NVRAM being corrupted on ppc64 preventing boot (bisected)
Mel Gorman writes: Yaboot in my case and I've heard it affected a DVD installation. I don't know for sure if it affects netboot but as I think it's something the kernel is doing, it probably doesn't matter how it gets loaded? I do need to know whether it was the vmlinux or the zImage.pseries that you were loading with yaboot. That commit you identified affects the contents of an ELF note in the zImage.pseries that firmware looks at, as well as a structure in the kernel itself that gets passed as an argument to a call to firmware. If you were loading a vmlinux with yaboot when you saw the corruption occur then that narrows things down a bit. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rc1: NVRAM being corrupted on ppc64 preventing boot (bisected)
On Fri, Oct 31, 2008 at 10:10:55PM +1100, Paul Mackerras wrote: Mel Gorman writes: Yaboot in my case and I've heard it affected a DVD installation. I don't know for sure if it affects netboot but as I think it's something the kernel is doing, it probably doesn't matter how it gets loaded? What changed in that commit was the contents of a couple of structures that the firmware looks at to see what the kernel wants from firmware. Specifically the change was to say that the kernel (or really the zImage wrapper) would like the firmware to be based at the 32MB point (which is what AIX uses) rather than 12MB (which was the default on older machines). So, as I understand it, it's not anything the kernel is actively doing, it's how the firmware is reacting to what the kernel says it wants. And since we are requesting the same value as AIX (as far as I know) I'm really surprised it caused problems. Same here, it sounds like an innocent change. While it is possible that AIX could not work on this machine, it seems a bit unlikely. We can revert that commit, but I still need to solve the problem that the distros are facing, namely that their installer kernel + initramfs images are now bigger than 12MB and can't be loaded if the firmware is based at 12MB. That's why I really want to understand the problem in more detail. It's been pointed out that it can be fixed by upgrading the firmware but surely we can avoid breaking the machine in the first place? Have you upgraded the firmware on the machine you saw this problem on? No. Luckily for us, it was scheduled to be upgraded but it got delayed :). I've asked the guy to go somewhere else for a while so I should be able to keep the machine in the state it's currently in. If not, would you be willing to run some tests for me? Of course. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
Linus, Since I sent the pull request, I have added one more commit to my merge branch, which reverts the commit that Mel Gorman identified as causing NVRAM corruption (plus another commit that depended on it). So when you do this: Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge you'll see this commit in addition: Paul Mackerras (1): Revert powerpc: Sync RPA note in zImage with kernel's RPA note I have included the overall diffstat below. Thanks, Paul. arch/powerpc/boot/addnote.c | 175 ++ arch/powerpc/boot/dts/mpc8313erdb.dts| 39 - arch/powerpc/boot/libfdt/fdt_ro.c|9 + arch/powerpc/boot/main.c |2 arch/powerpc/boot/wrapper|9 - arch/powerpc/configs/40x/acadia_defconfig| 59 +-- arch/powerpc/configs/40x/ep405_defconfig | 83 +++--- arch/powerpc/configs/40x/hcu4_defconfig | 125 +++- arch/powerpc/configs/40x/kilauea_defconfig | 69 ++--- arch/powerpc/configs/40x/makalu_defconfig| 69 ++--- arch/powerpc/configs/40x/walnut_defconfig| 77 +++--- arch/powerpc/configs/44x/arches_defconfig| 51 -- arch/powerpc/configs/44x/bamboo_defconfig| 77 +++--- arch/powerpc/configs/44x/canyonlands_defconfig | 61 +--- arch/powerpc/configs/44x/ebony_defconfig | 77 +++--- arch/powerpc/configs/44x/katmai_defconfig| 77 +++--- arch/powerpc/configs/44x/rainier_defconfig | 73 ++--- arch/powerpc/configs/44x/sam440ep_defconfig | 110 ++ arch/powerpc/configs/44x/sequoia_defconfig | 78 +++--- arch/powerpc/configs/44x/taishan_defconfig | 77 +++--- arch/powerpc/configs/44x/warp_defconfig | 82 +++--- arch/powerpc/configs/linkstation_defconfig | 11 + arch/powerpc/configs/ppc40x_defconfig| 106 +++-- arch/powerpc/configs/ppc44x_defconfig| 125 arch/powerpc/include/asm/iommu.h | 15 +- arch/powerpc/include/asm/kdump.h |8 - arch/powerpc/include/asm/mpic.h |2 arch/powerpc/include/asm/pci.h |2 arch/powerpc/kernel/dma-iommu.c | 34 ++-- arch/powerpc/kernel/head_64.S| 30 ++-- arch/powerpc/kernel/ibmebus.c| 27 ++- arch/powerpc/kernel/iommu.c | 25 ++- arch/powerpc/kernel/machine_kexec_64.c |9 - arch/powerpc/kernel/misc_64.S|9 - arch/powerpc/kernel/of_device.c |1 arch/powerpc/kernel/pci-common.c | 110 +++--- arch/powerpc/kernel/pci_64.c |2 arch/powerpc/kernel/prom_init.c | 10 + arch/powerpc/kernel/setup_64.c |6 - arch/powerpc/kernel/signal_32.c | 36 ++--- arch/powerpc/kernel/signal_64.c | 33 ++-- arch/powerpc/kernel/vio.c| 25 ++- arch/powerpc/kernel/vmlinux.lds.S|5 - arch/powerpc/oprofile/op_model_cell.c| 13 +- arch/powerpc/platforms/40x/Kconfig |2 arch/powerpc/platforms/85xx/mpc85xx_ds.c |3 arch/powerpc/platforms/86xx/pic.c|3 arch/powerpc/platforms/cell/iommu.c | 37 ++--- arch/powerpc/platforms/cell/ras.c|6 - arch/powerpc/platforms/embedded6xx/linkstation.c | 14 ++ arch/powerpc/platforms/iseries/iommu.c |7 + arch/powerpc/platforms/ps3/system-bus.c | 36 ++--- arch/powerpc/platforms/pseries/iommu.c |4 - arch/powerpc/platforms/pseries/pci_dlpar.c |2 arch/powerpc/sysdev/mpic.c | 59 +++ arch/powerpc/xmon/xmon.c |2 drivers/of/device.c | 11 + 57 files changed, 1444 insertions(+), 865 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rc1: NVRAM being corrupted on ppc64 preventing boot (bisected)
Benjamin Herrenschmidt writes: Unless missed something, I think it's narrowed already. When loaded from yaboot, there is no relevant difference between zImage and vmlinux here. IE. yaboot parses the ELF header of the zImage itself and ignores the special notes anyway so only the CAS firmware call is relevant in both cases, no ? Good point. However, it would be the parse-elf-header firmware call, rather than the CAS firmware call, since 91a00302 modified the fake_elf structure (to make it consistent with the CAS structure) but not the CAS structure. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Linus, Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get a collection of fixes for various regressions, compile failures and oops-causing bugs on powerpc, plus some defconfig updates (which form the bulk of the lines changed). The 3 commits from Milton Miller partially revert some changes we did since 2.6.27 to the way the kernel is invoked and the way it invokes a kexec/kdump kernel, and subsequently decided was a bad idea. I put them in so that we didn't end up having one kernel release with odd interface conventions. I'm sending this pull request rather than Ben because Ben's wife just had a baby and Ben is otherwise occupied. :) Thanks, Paul. arch/powerpc/boot/dts/mpc8313erdb.dts| 39 --- arch/powerpc/boot/libfdt/fdt_ro.c|9 +- arch/powerpc/boot/main.c |2 arch/powerpc/configs/40x/acadia_defconfig| 59 +++--- arch/powerpc/configs/40x/ep405_defconfig | 83 ++- arch/powerpc/configs/40x/hcu4_defconfig | 125 -- arch/powerpc/configs/40x/kilauea_defconfig | 69 arch/powerpc/configs/40x/makalu_defconfig| 69 arch/powerpc/configs/40x/walnut_defconfig| 77 ++ arch/powerpc/configs/44x/arches_defconfig| 51 ++--- arch/powerpc/configs/44x/bamboo_defconfig| 77 ++ arch/powerpc/configs/44x/canyonlands_defconfig | 61 +++ arch/powerpc/configs/44x/ebony_defconfig | 77 ++ arch/powerpc/configs/44x/katmai_defconfig| 77 ++ arch/powerpc/configs/44x/rainier_defconfig | 73 + arch/powerpc/configs/44x/sam440ep_defconfig | 110 ++- arch/powerpc/configs/44x/sequoia_defconfig | 78 ++ arch/powerpc/configs/44x/taishan_defconfig | 77 ++ arch/powerpc/configs/44x/warp_defconfig | 82 ++ arch/powerpc/configs/linkstation_defconfig | 11 +- arch/powerpc/configs/ppc40x_defconfig| 106 +++ arch/powerpc/configs/ppc44x_defconfig| 125 +- arch/powerpc/include/asm/iommu.h | 15 +-- arch/powerpc/include/asm/kdump.h |8 - arch/powerpc/include/asm/mpic.h |2 arch/powerpc/include/asm/pci.h |2 arch/powerpc/kernel/dma-iommu.c | 34 +++--- arch/powerpc/kernel/head_64.S| 30 +++-- arch/powerpc/kernel/ibmebus.c| 27 ++--- arch/powerpc/kernel/iommu.c | 25 ++-- arch/powerpc/kernel/machine_kexec_64.c |9 -- arch/powerpc/kernel/misc_64.S|9 +- arch/powerpc/kernel/of_device.c |1 arch/powerpc/kernel/pci-common.c | 110 ++- arch/powerpc/kernel/pci_64.c |2 arch/powerpc/kernel/setup_64.c |6 + arch/powerpc/kernel/signal_32.c | 36 +++--- arch/powerpc/kernel/signal_64.c | 33 +++--- arch/powerpc/kernel/vio.c| 25 ++-- arch/powerpc/kernel/vmlinux.lds.S|2 arch/powerpc/oprofile/op_model_cell.c| 13 ++ arch/powerpc/platforms/40x/Kconfig |2 arch/powerpc/platforms/85xx/mpc85xx_ds.c |3 - arch/powerpc/platforms/86xx/pic.c|3 - arch/powerpc/platforms/cell/iommu.c | 37 +++ arch/powerpc/platforms/cell/ras.c|6 + arch/powerpc/platforms/embedded6xx/linkstation.c | 14 ++ arch/powerpc/platforms/iseries/iommu.c |7 + arch/powerpc/platforms/ps3/system-bus.c | 36 +++--- arch/powerpc/platforms/pseries/iommu.c |4 - arch/powerpc/platforms/pseries/pci_dlpar.c |2 arch/powerpc/sysdev/mpic.c | 59 ++ arch/powerpc/xmon/xmon.c |2 drivers/of/device.c | 11 ++ 54 files changed, 1392 insertions(+), 720 deletions(-) Benjamin Herrenschmidt (1): powerpc/pci: Fix unmapping of IO space on 64-bit Carl Love (1): powerpc/cell/OProfile: Fix on-stack array size in activate spu profiling function David Gibson (1): powerpc: Fix bug in kernel copy of libfdt's fdt_subnode_offset_namelen() Guennadi Liakhovetski (1): powerpc: fix i2c on PPC linkstation / kurobox machines Jeremy Kerr (1): OF-device: Don't overwrite numa_node in device registration Jon Smirl (1): powerpc: Fix format string warning in arch/powerpc/boot/main.c Josh Boyer (3): powerpc/40x: Don't enable HCU4 board by default powerpc/40x: Update 40x defconfigs powerpc/44x: Update 44x defconfigs Kumar Gala
Re: 2.6.28-rc1: NVRAM being corrupted on ppc64 preventing boot (bisected)
On Fri, Oct 31, 2008 at 10:18:38PM +1100, Paul Mackerras wrote: Mel Gorman writes: Yaboot in my case and I've heard it affected a DVD installation. I don't know for sure if it affects netboot but as I think it's something the kernel is doing, it probably doesn't matter how it gets loaded? I do need to know whether it was the vmlinux or the zImage.pseries that you were loading with yaboot. That commit you identified affects the contents of an ELF note in the zImage.pseries that firmware looks at, as well as a structure in the kernel itself that gets passed as an argument to a call to firmware. If you were loading a vmlinux with yaboot when you saw the corruption occur then that narrows things down a bit. It's the vmlinux file I am seeing problems with. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-cpm: Add flexibility for I2C clock frequency and filter.
Hi Mike, This patch adds the ability to enable the digital filter in the device tree (with the clock-filter boolean property) and automates the predivider selection according to the clock-frequency and clock-filter properties. looks good. David, is clock-filter an appropriate dts property for this purpose or would you prefer a different name? What needs to be done though is to document this change in Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/4xx: Add GPIO, SPI and MMC suport to the Arches
Hi Stefan,
On Fri, Oct 31, 2008 at 12:11:46PM +0100, Stefan Roese wrote:
This patch adds GPIO, SPI MMC (for onboard uSD) support to the
Arches dts
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/arches.dts | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/arches.dts
b/arch/powerpc/boot/dts/arches.dts
index d9113b1..c568095 100644
--- a/arch/powerpc/boot/dts/arches.dts
+++ b/arch/powerpc/boot/dts/arches.dts
@@ -195,6 +195,38 @@
interrupts = 0x3 0x4;
};
+ SPI0: [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = spi;
device_type isn't needed.
+ compatible = ibm,spi-460gt, ibm,ppc4xx-spi;
+ reg = 0xef600900 7;
+ interrupt-parent = UIC1;
+ interrupts = 2 4;
+
+ /* gpio(s) representing chip select(s) */
+ gpios = GPIO1 11 0;
+
+ [EMAIL PROTECTED] {
+ compatible = linux,mmc-spi, mmc-spi;
According to new (though still not approved) bindings, this should
be board-specific-mmc-slot, mmc-spi-slot.
+ reg = 0;
+ spi-max-frequency = 1000;
+ voltage-range = 3300 3300;
For new bindings I changed this to voltage-ranges, so that we
could specify discontinuous range.
+ };
+ };
+
+ GPIO0: [EMAIL PROTECTED] {
+ #gpio-cells = 2;
+ compatible = ibm,460gt-gpio,ibm,ppc4xx-gpio;
+ reg = 0xef600b00 38;
+ };
+
+ GPIO1: [EMAIL PROTECTED] {
+ #gpio-cells = 2;
+ compatible = ibm,460gt-gpio,ibm,ppc4xx-gpio;
+ reg = 0xef600c00 38;
+ };
+
TAH0: [EMAIL PROTECTED] {
compatible = ibm,tah-460gt, ibm,tah;
reg = 0xef601350 0x0030;
--
1.6.0.3
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
mmc_spi with GPIO_MODE_3
Hello Anton, could you say me please, would the mmc_spi-driver function with GPIO_MODE_3? I have seen in mmc_spi_probe() this spi-mode = SPI_MODE_0. What should come back if i have CI and CP other then in SPI_MODE_0? Thank you for any advice. Sergej. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mmc_spi with GPIO_MODE_3
On Fri, Oct 31, 2008 at 01:49:31PM +0100, Stepanov, Sergej wrote: Hello Anton, could you say me please, would the mmc_spi-driver function with GPIO_MODE_3? You mean SPI_MODE_3? Well, it should work, or even better it shouldn't matter if it is 3 or 0. See Pierre's answer: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00160.html But in reality MODE_0 works better. http://www.mail-archive.com/[EMAIL PROTECTED]/msg00155.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg00231.html IIRC nobody knows why exactly this happens, or better, nobody bothered to investigate, since MODE_0 works OK. ;-) I have seen in mmc_spi_probe() this spi-mode = SPI_MODE_0. What should come back if i have CI and CP other then in SPI_MODE_0? Something like this I suppose: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00153.html -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
QE in MPC8360MDS
Hi All, Anyone know the difference of QE between MPC8360 and MPC8568? I am using the QE code working for MPC8568 on a MPC8360MDS board. However there is no interrupt generated by UCC0. I set the QE working under loopback mode. The flag of TxBD got changed, but the UCCE remains the same value. Here is the logs and register value. Thanks, Mike ===ucc_geth_start_xmit: Set status queue=0 TxBD[cf48a488].status=982a ucce=10001 uccm=7f010001 ucc_geth_start_xmit: Different value for TxBD after Xmit TxBD[cf48a488].status=182a ase address: 0xfdf02000 gumr : addr - 0xfdf02000, val - 0x400c upsmr : addr - 0xfdf02004, val - 0x2000 utodr : addr - 0xfdf02008, val - 0x udsr : addr - 0xfdf0200c, val - 0x7e7e ucce : addr - 0xfdf02010, val - 0x uccm : addr - 0xfdf02014, val - 0x7f010001 uccs : addr - 0xfdf02018, val - 0x00 urfb : addr - 0xfdf02020, val - 0x3488 urfs : addr - 0xfdf02024, val - 0x1000 urfet : addr - 0xfdf02028, val - 0x0800 urfset: addr - 0xfdf0202a, val - 0x0c00 utfb : addr - 0xfdf0202c, val - 0x1480 utfs : addr - 0xfdf02030, val - 0x2000 utfet : addr - 0xfdf02034, val - 0x1000 utftt : addr - 0xfdf02038, val - 0x0400 utpt : addr - 0xfdf0203c, val - 0x0100 urtry : addr - 0xfdf02040, val - 0x guemr : addr - 0xfdf02090, val - 0x13 UCC0 Geth registers: Base address: 0xfdf02000 maccfg1: addr - 0xfdf02100, val - 0x0035 maccfg2: addr - 0xfdf02104, val - 0x0020 ipgifg : addr - 0xfdf02108, val - 0x40605060 hafdup : addr - 0xfdf0210c, val - 0x00a1f037 ifctl : addr - 0xfdf02138, val - 0x0100 ifstat : addr - 0xfdf0213c, val - 0x macstnaddr1: addr - 0xfdf02140, val - 0x macstnaddr2: addr - 0xfdf02144, val - 0x uempr : addr - 0xfdf02150, val - 0x utbipar: addr - 0xfdf02154, val - 0x0010 uescr : addr - 0xfdf02158, val - 0x0804 tx64 : addr - 0xfdf02180, val - 0x tx127 : addr - 0xfdf02184, val - 0x tx255 : addr - 0xfdf02188, val - 0x rx64 : addr - 0xfdf0218c, val - 0x rx127 : addr - 0xfdf02190, val - 0x rx255 : addr - 0xfdf02194, val - 0x txok : addr - 0xfdf02198, val - 0x txcf : addr - 0xfdf0219c, val - 0x tmca : addr - 0xfdf021a0, val - 0x tbca : addr - 0xfdf021a4, val - 0x rxfok : addr - 0xfdf021a8, val - 0x rxbok : addr - 0xfdf021ac, val - 0x rbyt : addr - 0xfdf021b0, val - 0x rmca : addr - 0xfdf021b4, val - 0x rbca : addr - 0xfdf021b8, val - 0x scar : addr - 0xfdf021bc, val - 0x scam : addr - 0xfdf021c0, val - 0x Thread data TXs: Base address: 0xfdf14600 Thread data TX[0]: Base address: 0xfdf14600 0xfdf14600: 3800 3880002a 1800 1880002a 0xfdf14610: 1800 1880002a 1800 1880002a 0xfdf14620: 1800 1880002a 1800 1880002a 0xfdf14630: 1800 1880002a 1800 1880002a 0xfdf14640: 800017c8 3a2a 0f48a4f8 0c094242 0xfdf14650: 80001678 1a2a 0f48a4c8 0c0b4e22 0xfdf14660: 800016e8 1a2a Thread data TX[1]: Base address: 0xfdf14668 0xfdf14668: 0f48a4d8 0c0b4f22 80001758 1a2a 0xfdf14678: 0f48a4e8 0c094142 80001790 1a2a 0xfdf14688: 0f48a4f0 0c0941c2 80001640 1a2a 0xfdf14698: 0f48a4c0 0c0b4da2 800016b0 1a2a 0xfdf146a8: 0f48a4d0 0c0b4ea2 80001720 1a2a 0xfdf146b8: 0f48a4e0 0c0940c2 0d004dc0 0xfdf146c8: 14004e40 0001 Thread data RX: Base address: 0xfdf14a00 Thread data RX[0]: Base address: 0xfdf14a00 0xfdf14a00: 0xfdf14a10: 0xfdf14a20: Thread data RX[1]: Base address: 0xfdf14a28 0xfdf14a28: 0xfdf14a38: 4c00 0005 0xfdf14a48: 4d00 000c TX global param: Base address: 0xfdf14500 temoder : addr - 0xfdf14500, val - 0xc000 sqptr: addr - 0xfdf14538, val - 0x4780 schedulerbasepointer: addr - 0xfdf1453c, val - 0x txrmonbaseptr: addr - 0xfdf14540, val - 0x tstate : addr - 0xfdf14544, val - 0x3000 iphoffset[0] : addr - 0xfdf14548, val - 0x00 iphoffset[1] : addr - 0xfdf14549, val - 0x00 iphoffset[2] : addr - 0xfdf1454a, val - 0x00 iphoffset[3] : addr - 0xfdf1454b, val - 0x00 iphoffset[4] : addr - 0xfdf1454c, val - 0x00 iphoffset[5] : addr - 0xfdf1454d, val - 0x00 iphoffset[6] : addr - 0xfdf1454e, val - 0x00 iphoffset[7] : addr - 0xfdf1454f, val - 0x00 vtagtable[0] : addr - 0xfdf14550, val - 0x vtagtable[1] : addr - 0xfdf14554, val - 0x vtagtable[2] : addr - 0xfdf14558, val - 0x vtagtable[3] : addr - 0xfdf1455c, val - 0x vtagtable[4] : addr - 0xfdf14560, val - 0x vtagtable[5] : addr - 0xfdf14564, val - 0x vtagtable[6] : addr - 0xfdf14568, val - 0x vtagtable[7] : addr - 0xfdf1456c, val - 0x tqptr: addr - 0xfdf14570, val -
Re: QE in MPC8360MDS
On Fri, Oct 31, 2008 at 09:47:18AM -0400, mike zheng wrote: Hi All, Anyone know the difference of QE between MPC8360 and MPC8568? I am using the QE code working for MPC8568 on a MPC8360MDS board. However there is no interrupt generated by UCC0. I set the QE working under loopback mode. The flag of TxBD got changed, but the UCCE remains the same value. Here is the logs and register value. I recalling these differences: QEIC to MPIC vs. IPIC cascading (may be the cause of interrupts issues). http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cccd21027c17c27ad275093c22475354b4495814 QE ParIO layout (you may have pins misconfigured): http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=321872dcc07f83f9b60af1be41c6bafbaddf9bf6 -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/4xx: Add GPIO, SPI and MMC suport to the Arches
Hi Anton,
thanks for your comments.
On Friday 31 October 2008, Anton Vorontsov wrote:
diff --git a/arch/powerpc/boot/dts/arches.dts
b/arch/powerpc/boot/dts/arches.dts index d9113b1..c568095 100644
--- a/arch/powerpc/boot/dts/arches.dts
+++ b/arch/powerpc/boot/dts/arches.dts
@@ -195,6 +195,38 @@
interrupts = 0x3 0x4;
};
+ SPI0: [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = spi;
device_type isn't needed.
OK, will remove.
+ compatible = ibm,spi-460gt, ibm,ppc4xx-spi;
+ reg = 0xef600900 7;
+ interrupt-parent = UIC1;
+ interrupts = 2 4;
+
+ /* gpio(s) representing chip select(s) */
+ gpios = GPIO1 11 0;
+
+ [EMAIL PROTECTED] {
+ compatible = linux,mmc-spi, mmc-spi;
According to new (though still not approved) bindings, this should
be board-specific-mmc-slot, mmc-spi-slot.
So I will wait a while with re-sending until this is approved.
+ reg = 0;
+ spi-max-frequency = 1000;
+ voltage-range = 3300 3300;
For new bindings I changed this to voltage-ranges, so that we
could specify discontinuous range.
OK, will change in next version.
Thanks.
Best regards,
Stefan
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED]
=
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [UPDATED PATCH VER2] Cell OProfile: Incorrect local array size in activate spu profiling function
On 29.10.08 08:06:45, Carl Love wrote: Updated the patch to address comments by Michael Ellerman. Specifically, changed upper limit in for loop to ARRAY_SIZE() macro and added a check to make sure the number of events specified by the user, which is used as the max for indexing various arrays, is no bigger then the declared size of the arrays. The size of the pm_signal_local array should be equal to the number of SPUs being configured in the array. Currently, the array is of size 4 (NR_PHYS_CTRS) but being indexed by a for loop from 0 to 7 (NUM_SPUS_PER_NODE). Signed-off-by: Carl Love [EMAIL PROTECTED] I applied your patch to oprofile/oprofile-for-tip. Thanks Carl. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
AW: mmc_spi with GPIO_MODE_3
Thanks for answer somewhere i have seen: For a while it seemed like MMC cards worked OK but not SD cards! Hm... I have a SD card: Transcend, 512Mb... may it be the problem?.. Sergej. Von: Anton Vorontsov [EMAIL PROTECTED] Gesendet: Freitag, 31. Oktober 2008 14:45 An: Stepanov, Sergej Cc: linuxppc-dev@ozlabs.org Betreff: Re: mmc_spi with GPIO_MODE_3 On Fri, Oct 31, 2008 at 01:49:31PM +0100, Stepanov, Sergej wrote: Hello Anton, could you say me please, would the mmc_spi-driver function with GPIO_MODE_3? You mean SPI_MODE_3? Well, it should work, or even better it shouldn't matter if it is 3 or 0. See Pierre's answer: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00160.html But in reality MODE_0 works better. http://www.mail-archive.com/[EMAIL PROTECTED]/msg00155.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg00231.html IIRC nobody knows why exactly this happens, or better, nobody bothered to investigate, since MODE_0 works OK. ;-) I have seen in mmc_spi_probe() this spi-mode = SPI_MODE_0. What should come back if i have CI and CP other then in SPI_MODE_0? Something like this I suppose: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00153.html -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] a little disassembly infrastructure
On Sat, 2008-10-25 at 13:55 +1100, Paul Mackerras wrote: Hollis Blanchard writes: I've also found xmon's ppc-opc.c. That parses the opcode and operands, so could use some shared macros. That's a direct copy from GNU binutils. I'm reluctant to modify it because then maintenance becomes more than just copying in the latest version. OK, makes sense. Can I get an Acked-by on this patch, or should I move the code to a KVM-specific header? Either way I'll submit it via the KVM tree as usual. -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rc1: NVRAM being corrupted on ppc64 preventing boot (bisected)
On Fri, Oct 31, 2008 at 10:10:55PM +1100, Paul Mackerras wrote:
Mel Gorman writes:
Yaboot in my case and I've heard it affected a DVD installation. I don't
know for sure if it affects netboot but as I think it's something the
kernel is doing, it probably doesn't matter how it gets loaded?
What changed in that commit was the contents of a couple of structures
that the firmware looks at to see what the kernel wants from
firmware. Specifically the change was to say that the kernel (or
really the zImage wrapper) would like the firmware to be based at the
32MB point (which is what AIX uses) rather than 12MB (which was the
default on older machines).
So, as I understand it, it's not anything the kernel is actively
doing, it's how the firmware is reacting to what the kernel says it
wants. And since we are requesting the same value as AIX (as far as I
know) I'm really surprised it caused problems.
We can revert that commit, but I still need to solve the problem that
the distros are facing, namely that their installer kernel + initramfs
images are now bigger than 12MB and can't be loaded if the firmware is
based at 12MB. That's why I really want to understand the problem in
more detail.
It's been pointed out that it can be fixed by upgrading the firmware but
surely we can avoid breaking the machine in the first place?
Have you upgraded the firmware on the machine you saw this problem on?
If not, would you be willing to run some tests for me?
As per an off-line suggestion, I was able to get past the NVRAM problem
using the following patch. The machine still fails to fully boot but it's
due to some modules problem and unrelated to this issue.
From 7e54016ce29eb80026d7ff9a8310cf9c3a7e17a9 Mon Sep 17 00:00:00 2001
From: Mel Gorman [EMAIL PROTECTED]
Date: Fri, 31 Oct 2008 17:12:46 +
Subject: [PATCH] Partial revert of 91a00302, set new_mem_def back to 0
On the suggestion of Paul McKerras, I tried the following patch. It partially
reverts a change made by commit 91a00302 by setting new_mem_def back to 0.
Once applied, IBM pSeries with old firmware do not corrupt their NVRAM early
in boot.
I do not know why this change fixes the problem. A structure like this is
also in arch/powerpc/boot/addnote.c but it's not clear if it needs to be
similarly changed or not. Paul?
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
---
arch/powerpc/kernel/prom_init.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 23e0db2..d6c8128 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -719,7 +719,7 @@ static struct fake_elf {
.max_pft_size = 46, /* 2^46 bytes max PFT size */
.splpar = 1,
.min_load = ~0U,
- .new_mem_def = 1
+ .new_mem_def = 0
}
}
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/44x: declare tlb_44x_index for use in C code
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Date 1225479768 18000
# Node ID 59bd162a744af080479fedffa97d01e26dceee6a
# Parent 635f3f74befc230d93f79dc3198c509394247ee8
powerpc/44x: declare tlb_44x_index for use in C code
KVM currently ignores the host's round robin TLB eviction selection, instead
maintaining its own TLB state and its own round robin index. However, by
participating in the normal 44x TLB selection, we can drop the alternate TLB
processing in KVM. This results in a significant performance improvement,
since that processing currently must be done on *every* guest exit.
Accordingly, KVM needs to be able to access and increment tlb_44x_index.
(KVM on 440 cannot be a module, so there is no need to export this symbol.)
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
---
Josh, can I get your ack? I'll submit through the KVM tree as usual.
diff --git a/arch/powerpc/include/asm/mmu-44x.h
b/arch/powerpc/include/asm/mmu-44x.h
--- a/arch/powerpc/include/asm/mmu-44x.h
+++ b/arch/powerpc/include/asm/mmu-44x.h
@@ -54,6 +54,7 @@
#ifndef __ASSEMBLY__
extern unsigned int tlb_44x_hwater;
+extern unsigned int tlb_44x_index;
typedef struct {
unsigned long id;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-cpm: Add flexibility for I2C clock frequency and filter.
Jochen Friedrich wrote: What needs to be done though is to document this change in Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt. How about the below? I'll wait for David to comment on the property name and for any suggestions on the documentation below, then I'll submit a new patch. --- linux/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt 11 Oct 2008 02:49:31 - 1.1.1.1 +++ linux/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt 31 Oct 2008 21:15:06 - @@ -10,8 +10,12 @@ - #address-cells : Should be one. The cell is the i2c device address with the r/w bit set to zero. - #size-cells : Should be zero. -- clock-frequency : Can be used to set the i2c clock frequency. If - unspecified, a default frequency of 60kHz is being used. +- clock-frequency : Can be used to set the desired i2c clock frequency (in Hz). + If unspecified, a default of 60 kHz is being used. The actual frequency may + be somewhat higher than this value, depending on how the BRG_CLK and dividers + work out. +- clock-filter : boolean; if defined, indicates that this controller + should enable the SCL digital filter. The following two properties are deprecated. They are only used by legacy i2c drivers to find the bus to probe: - linux,i2c-index : Can be used to hard code an i2c bus number. By default, ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-cpm: Add flexibility for I2C clock frequency and filter.
[redirecting again to the new i2c mailing list] Jochen Friedrich wrote: What needs to be done though is to document this change in Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt. How about the below? I'll wait for David to comment on the property name and for any suggestions on the documentation below, then I'll submit a new patch. -=] Mike [=- --- linux/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt 11 Oct 2008 02:49:31 - 1.1.1.1 +++ linux/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt 31 Oct 2008 21:15:06 - @@ -10,8 +10,12 @@ - #address-cells : Should be one. The cell is the i2c device address with the r/w bit set to zero. - #size-cells : Should be zero. -- clock-frequency : Can be used to set the i2c clock frequency. If - unspecified, a default frequency of 60kHz is being used. +- clock-frequency : Can be used to set the desired i2c clock frequency (in Hz). + If unspecified, a default of 60 kHz is being used. The actual frequency may + be somewhat higher than this value, depending on how the BRG_CLK and dividers + work out. +- clock-filter : boolean; if defined, indicates that this controller + should enable the SCL digital filter. The following two properties are deprecated. They are only used by legacy i2c drivers to find the bus to probe: - linux,i2c-index : Can be used to hard code an i2c bus number. By default, ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
On Wed, Oct 22, 2008 at 9:28 AM, Christian Ehrhardt
[EMAIL PROTECTED] wrote:
Hi Ilya,
I just tried your patch on my 440 board because it would help us in our
environment.
Unfortunately I run into a bug on early boot (mark_bootmem).
A log can be found in this mail, this is the bug when running with 64k page
size.
I tried this with and without your 2/2 265k patch and also with page size
configured to 16k, the error is the same in all cases.
I used an earlier version of your patch in the past and it worked fine.
Applying this old patch causes the same problem.
Therefore I expect that there was some other code changed that breaks with
page size != 4k.
This patch seems to solve the problem for me, but I have to run and
haven't yet worked out if it's the right fix.
diff --git a/mm/bootmem.c b/mm/bootmem.c
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -300,7 +300,7 @@ static int __init mark_bootmem(unsigned
unsigned long max;
if (pos bdata-node_min_pfn ||
- pos = bdata-node_low_pfn) {
+ pos bdata-node_low_pfn) {
BUG_ON(pos != start);
continue;
}
@@ -399,7 +399,7 @@ int __init reserve_bootmem(unsigned long
unsigned long start, end;
start = PFN_DOWN(addr);
- end = PFN_UP(addr + size);
+ end = PFN_DOWN(addr + size);
return mark_bootmem(start, end, 1, flags);
}
Looks like the breakage may have been accidentally introduced by
Johannes Weiner [EMAIL PROTECTED] on Jul 24 (post 2.6.26).
FWIW, the boards Christian and I are hitting the problem on are
Sequoias with 256MB of RAM. cuImage is reporting only 0x000 bytes
of RAM though, which may be exacerbating the situation.
-Hollis
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] i2c-cpm: Detect and report NAK right away instead of timing out.
Make the driver report an ENXIO error immediately upon NAK instead of waiting for another interrupt and getting a timeout. Signed-off-by: Mike Ditto [EMAIL PROTECTED] --- When reading from a device that is not present or declines to respond to, e.g., a non-existent register address, CPM immediately reports a NAK condition in the TxBD, but the driver kept waiting until a timeout, which takes 1 second and causes an ugly console error message. Index: linux/drivers/i2c/busses/i2c-cpm.c === retrieving revision 1.3 diff -u -p -r1.3 i2c-cpm.c --- linux/drivers/i2c/busses/i2c-cpm.c 31 Oct 2008 06:36:08 - 1.3 +++ linux/drivers/i2c/busses/i2c-cpm.c 1 Nov 2008 00:12:45 - @@ -369,6 +369,7 @@ static int cpm_i2c_xfer(struct i2c_adapt pmsg = msgs[tptr]; if (pmsg-flags I2C_M_RD) ret = wait_event_interruptible_timeout(cpm-i2c_wait, + (in_be16(tbdf[tptr].cbd_sc) BD_SC_NAK) || !(in_be16(rbdf[rptr].cbd_sc) BD_SC_EMPTY), 1 * HZ); else ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] kexec memory ranges dynamic allocation
On Fri, Oct 31, 2008 at 09:53:23AM +0300, Maxim Uvarov wrote:
2008/10/31 Simon Horman [EMAIL PROTECTED]
Hi,
Could someone please comment on the satus of this patch?
Hello, Simon
I can not reproduce error which you wrote before on my target. So it is a
little bit
difficult to say what was wrong exactly.
Hi,
the version of the patch below (which I think is the latest)
compiles fine for me. I wanted to confirm that you
and Chandru are happy for it to be merged.
If so, could you please provide a short descripton for the change-log
and a Signed-off-by line.
Thanks
On Wed, Oct 15, 2008 at 12:46:24PM +0400, Maxim Uvarov wrote:
Patch corrected. ( git_kexec_powerpc_v2.patch is attached.)
I tested it on ppc64 pasemi electra board. Both kexec -l and kexec -p
works.
Maxim.
diff --git a/kexec/arch/ppc64/kexec-ppc64.c
b/kexec/arch/ppc64/kexec-ppc64.c
index 069a9fc..0ad40fa 100644
--- a/kexec/arch/ppc64/kexec-ppc64.c
+++ b/kexec/arch/ppc64/kexec-ppc64.c
@@ -96,96 +96,46 @@ err1:
}
-static int count_dyn_reconf_memory_ranges(void)
+static int realloc_memory_ranges()
{
- char device_tree[] = /proc/device-tree/;
- char fname[128];
- char buf[32];
- FILE *file;
-
- strcpy(fname, device_tree);
- strcat(fname, ibm,dynamic-reconfiguration-memory/ibm,lmb-size);
- if ((file = fopen(fname, r)) == NULL) {
- perror(fname);
- return -1;
- }
+ size_t memory_range_len;
- if (fread(buf, 1, 8, file) 0) {
- perror(fname);
- fclose(file);
- return -1;
- }
-
- lmb_size = ((uint64_t *)buf)[0];
- fclose(file);
+ max_memory_ranges++;
+ memory_range_len = sizeof(struct memory_range) * max_memory_ranges;
- /* Get number of lmbs from ibm,dynamic-memory */
- strcpy(fname, device_tree);
- strcat(fname,
ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory);
- if ((file = fopen(fname, r)) == NULL) {
- perror(fname);
- return -1;
- }
- /*
- * first 4 bytes provide number of entries(lmbs)
- */
- if (fread(buf, 1, 4, file) 0) {
- perror(fname);
- fclose(file);
- return -1;
- }
- num_of_lmbs = ((unsigned int *)buf)[0];
- max_memory_ranges += num_of_lmbs;
- fclose(file);
+ memory_range = (struct memory_range *) realloc(memory_range,
memory_range_len);
+ if (!memory_range)
+ goto err;
- return 0;
-}
+ base_memory_range = (struct memory_range *) realloc(memory_range,
memory_range_len);
+ if (!base_memory_range)
+ goto err;
-/*
- * Count the memory nodes under /proc/device-tree and populate the
- * max_memory_ranges variable. This variable replaces MAX_MEMORY_RANGES
- * macro used earlier.
- */
-static int count_memory_ranges(void)
-{
- char device_tree[256] = /proc/device-tree/;
- struct dirent *dentry;
- DIR *dir;
+ exclude_range = (struct memory_range *) realloc(exclude_range,
memory_range_len);
+ if (!exclude_range)
+ goto err;
- if ((dir = opendir(device_tree)) == NULL) {
- perror(device_tree);
- return -1;
- }
+ usablemem_rgns.ranges = (struct memory_range *)
+ realloc(usablemem_rgns.ranges,
memory_range_len);
+ if (!(usablemem_rgns.ranges))
+ goto err;
- while ((dentry = readdir(dir)) != NULL) {
- if (!strncmp(dentry-d_name,
- ibm,dynamic-reconfiguration-memory, 35)){
- if (count_dyn_reconf_memory_ranges() != 0)
- return -1;
- continue;
- }
+ return 0;
- if (strncmp(dentry-d_name, memory@, 7)
- strcmp(dentry-d_name, memory)
- strncmp(dentry-d_name, pci@, 4))
- continue;
- max_memory_ranges++;
- }
- /* need to add extra region for retained initrd */
- if (reuse_initrd) {
- max_memory_ranges++;
- }
+err:
+ fprintf(stderr, memory range structure re-allocation failure\n);
+ return -1;
+}
- closedir(dir);
- return 0;
-}
static void add_base_memory_range(uint64_t start, uint64_t end)
{
base_memory_range[nr_memory_ranges].start = start;
base_memory_range[nr_memory_ranges].end = end;
base_memory_range[nr_memory_ranges].type = RANGE_RAM;
nr_memory_ranges++;
+ if (nr_memory_ranges = max_memory_ranges)
+ realloc_memory_ranges();
