Re: [PATCH] ucc_geth: use correct UCCE macros
From: Timur Tabi ti...@freescale.com Date: Wed, 7 Jan 2009 14:12:52 -0600 The UCC Event Register (UCCE) already has unambigous macro definitions in qe.h, so we should not be defining our own in the UCC Ethernet driver. Removed unused local variable 'dev' from ucc_geth_poll(), which fixes a warning caused by commit 908a7a16b852ffd618a9127be8d62432182d81b4. Replaced in_be/out_be pairs with setbits32 or clrbits32, where applicable. Signed-off-by: Timur Tabi ti...@freescale.com Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
unsubscribe
unsubscribe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [GIT PULL] LED updates for 2.6.29
On Sat, 2009-01-10 at 21:43 -0800, Trent Piepho wrote: On Sun, 11 Jan 2009, Richard Purdie wrote: On Sat, 2009-01-10 at 04:31 -0800, Trent Piepho wrote: The LED tree makes more sense for what's left I think. There was a openfirmware gpio patch, but that's already gone in. What's left only touches led files and the device tree binding docs. AFAIK, there were no objections to the patches left. Ok, these are now queued in the LED tree: http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/ I did merge the last three patches in one and make some changes to deal with some other outstanding issues. Let me know ASAP if there are any problems. Since the last patch looks like it's just my three patches folded into one, shouldn't I be listed as the author and the primary signed off by? I made changes other than just merging the three together (the syspend/resume change and the bitfield parts in leds.h) so putting you as signed off by/authorship would not have been correct and I credited you in the commit message instead. I wanted to get the missing patches queued ASAP so I went with the way that does fit in the rules as you'd not have been happy if a modified patch was attributed to you. I'll put you as author and a signoff if you confirm thats acceptable. Cheers, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [GIT PULL] LED updates for 2.6.29
On Sun, 11 Jan 2009, Richard Purdie wrote: On Sat, 2009-01-10 at 21:43 -0800, Trent Piepho wrote: On Sun, 11 Jan 2009, Richard Purdie wrote: On Sat, 2009-01-10 at 04:31 -0800, Trent Piepho wrote: The LED tree makes more sense for what's left I think. There was a openfirmware gpio patch, but that's already gone in. What's left only touches led files and the device tree binding docs. AFAIK, there were no objections to the patches left. Ok, these are now queued in the LED tree: http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/ I did merge the last three patches in one and make some changes to deal with some other outstanding issues. Let me know ASAP if there are any problems. Since the last patch looks like it's just my three patches folded into one, shouldn't I be listed as the author and the primary signed off by? I made changes other than just merging the three together (the syspend/resume change and the bitfield parts in leds.h) so putting you as signed off by/authorship would not have been correct and I credited you in the commit message instead. I wanted to get the missing patches queued ASAP so I went with the way that does fit in the rules as you'd not have been happy if a modified patch was attributed to you. I'll put you as author and a signoff if you confirm thats acceptable. It doesn't seem right to merge someone's patches together, make a very small change, and then no longer credit them as the author. Seems like it defeats the purpose of the SOB lines for tracing the train of custody too. If someone looks to see where the code came from, it will look like you wrote it. Maybe Freescale will say Intel stole our code? Without the SOB, what record is there in git that Freescale gave permission to put the code in the kernel? I also put some significant effort into writing informative commit messages, which have been lost. Along with Grant's acks for my patches. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [GIT PULL] LED updates for 2.6.29
On Sun, 2009-01-11 at 04:58 -0800, Trent Piepho wrote: It doesn't seem right to merge someone's patches together, make a very small change, and then no longer credit them as the author. Seems like it defeats the purpose of the SOB lines for tracing the train of custody too. If someone looks to see where the code came from, it will look like you wrote it. Maybe Freescale will say Intel stole our code? Without the SOB, what record is there in git that Freescale gave permission to put the code in the kernel? I also put some significant effort into writing informative commit messages, which have been lost. Along with Grant's acks for my patches. It also doesn't make sense to make three changes adding different interfaces and rearranging the same section of code three different times. I'm dropping the patch, please send me a merged version of those patches with a commit message you're happy with. If you want Acked-by lines, we'll have to wait for them on the new patch as I'm going to do this exactly by the book regardless of time pressures now. Please indicate who you want Ack-ed by lines from so I know who to wait for. Also, you'd better exclude the suspend/resume change and credit me for the bitfield change, just to be 100% sure this is all legally accurate. Regards, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/83xx: Make serial ports work on MPC8315E-RDB w/ FSL U-Boots
FSL U-Boots use /soc8...@e000 node to search and fixup serial nodes' clock-frequency properties. Though in upstream kernels we use new naming convention -- for IMMR address space dts files specify /i...@e000 nodes. This makes FSL U-Boots fail to fixup the clock frequencies, and that leads to serial ports misbehaviour. We can workaround the issue by filling the clock frequency values manually. p.s. For the same reason FSL U-Boots fail to fixup MAC addresses for ethernet nodes, so users should either change the .dts file locally or set MAC address via `ifconfig hw ether' command. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- Leon, With this patch 2.6.28 kernel boots and works fine with the U-Boot I took from this image (downloadable from freescale.com): $ md5sum MPC8315ERDB_20080321-ltib.iso 009730826366d593347b88fa4fdb9be0 MPC8315ERDB_20080321-ltib.iso That is, U-Boot 1.3.0-rc2 (Mar 21 2008 - 13:36:09) MPC83XX arch/powerpc/boot/dts/mpc8315erdb.dts |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts b/arch/powerpc/boot/dts/mpc8315erdb.dts index 9a4fa2a..88d691c 100644 --- a/arch/powerpc/boot/dts/mpc8315erdb.dts +++ b/arch/powerpc/boot/dts/mpc8315erdb.dts @@ -257,7 +257,7 @@ device_type = serial; compatible = ns16550; reg = 0x4500 0x100; - clock-frequency = 0; + clock-frequency = 1; interrupts = 9 0x8; interrupt-parent = ipic; }; @@ -267,7 +267,7 @@ device_type = serial; compatible = ns16550; reg = 0x4600 0x100; - clock-frequency = 0; + clock-frequency = 1; interrupts = 10 0x8; interrupt-parent = ipic; }; -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
unsubscribe
unsubscribe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/chips/
This patch is used to help Jean Delvare to get rid of drivers/i2c/chips/
directory. The new location suggested by Kumar Gala: as the driver is
83xx specific it's placed into arch/powerpc/platforms/83xx/.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
This is git patch.
arch/powerpc/platforms/83xx/Makefile |1 +
.../powerpc/platforms/83xx}/mcu_mpc8349emitx.c |0
arch/powerpc/platforms/Kconfig | 11 +++
drivers/i2c/chips/Kconfig | 11 ---
drivers/i2c/chips/Makefile |1 -
5 files changed, 12 insertions(+), 12 deletions(-)
rename {drivers/i2c/chips = arch/powerpc/platforms/83xx}/mcu_mpc8349emitx.c
(100%)
diff --git a/arch/powerpc/platforms/83xx/Makefile
b/arch/powerpc/platforms/83xx/Makefile
index ba5028e..051777c 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -3,6 +3,7 @@
#
obj-y := misc.o usb.o
obj-$(CONFIG_SUSPEND) += suspend.o suspend-asm.o
+obj-$(CONFIG_MCU_MPC8349EMITX) += mcu_mpc8349emitx.o
obj-$(CONFIG_MPC831x_RDB) += mpc831x_rdb.o
obj-$(CONFIG_MPC832x_RDB) += mpc832x_rdb.o
obj-$(CONFIG_MPC834x_MDS) += mpc834x_mds.o
diff --git a/drivers/i2c/chips/mcu_mpc8349emitx.c
b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
similarity index 100%
rename from drivers/i2c/chips/mcu_mpc8349emitx.c
rename to arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 47fe2be..200b9cb 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -323,4 +323,15 @@ config SIMPLE_GPIO
chip-selects, Ethernet/USB PHY's power and various other small
on-board peripherals.
+config MCU_MPC8349EMITX
+ tristate MPC8349E-mITX MCU driver
+ depends on I2C PPC_83xx
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here to enable soft power-off functionality on the Freescale
+ boards with the MPC8349E-mITX-compatible MCU chips. This driver will
+ also register MCU GPIOs with the generic GPIO API, so you'll able
+ to use MCU pins as GPIOs.
+
endmenu
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 4c35702..d383e81 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -174,15 +174,4 @@ config MENELAUS
and other features that are often used in portable devices like
cell phones and PDAs.
-config MCU_MPC8349EMITX
- tristate MPC8349E-mITX MCU driver
- depends on I2C PPC_83xx
- select GENERIC_GPIO
- select ARCH_REQUIRE_GPIOLIB
- help
- Say Y here to enable soft power-off functionality on the Freescale
- boards with the MPC8349E-mITX-compatible MCU chips. This driver will
- also register MCU GPIOs with the generic GPIO API, so you'll able
- to use MCU pins as GPIOs.
-
endmenu
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 23d2a31..7e769b0 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -22,7 +22,6 @@ obj-$(CONFIG_ISP1301_OMAP)+= isp1301_omap.o
obj-$(CONFIG_TPS65010) += tps65010.o
obj-$(CONFIG_MENELAUS) += menelaus.o
obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
-obj-$(CONFIG_MCU_MPC8349EMITX) += mcu_mpc8349emitx.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/chips/
This patch is used to help Jean Delvare to get rid of drivers/i2c/chips/
directory. The new location suggested by Kumar Gala: as the driver is
83xx specific it's placed into arch/powerpc/platforms/83xx/.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
The same patch but suitable for patch(1).
arch/powerpc/platforms/83xx/Makefile |1 +
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 209
arch/powerpc/platforms/Kconfig | 11 ++
drivers/i2c/chips/Kconfig | 11 --
drivers/i2c/chips/Makefile |1 -
drivers/i2c/chips/mcu_mpc8349emitx.c | 209
6 files changed, 221 insertions(+), 221 deletions(-)
create mode 100644 arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
delete mode 100644 drivers/i2c/chips/mcu_mpc8349emitx.c
diff --git a/arch/powerpc/platforms/83xx/Makefile
b/arch/powerpc/platforms/83xx/Makefile
index ba5028e..051777c 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -3,6 +3,7 @@
#
obj-y := misc.o usb.o
obj-$(CONFIG_SUSPEND) += suspend.o suspend-asm.o
+obj-$(CONFIG_MCU_MPC8349EMITX) += mcu_mpc8349emitx.o
obj-$(CONFIG_MPC831x_RDB) += mpc831x_rdb.o
obj-$(CONFIG_MPC832x_RDB) += mpc832x_rdb.o
obj-$(CONFIG_MPC834x_MDS) += mpc834x_mds.o
diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
new file mode 100644
index 000..82a9bcb
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
@@ -0,0 +1,209 @@
+/*
+ * Power Management and GPIO expander driver for MPC8349E-mITX-compatible MCU
+ *
+ * Copyright (c) 2008 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov avoront...@ru.mvista.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/device.h
+#include linux/mutex.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include asm/prom.h
+#include asm/machdep.h
+
+/*
+ * I don't have specifications for the MCU firmware, I found this register
+ * and bits positions by the trialerror method.
+ */
+#define MCU_REG_CTRL 0x20
+#define MCU_CTRL_POFF 0x40
+
+#define MCU_NUM_GPIO 2
+
+struct mcu {
+ struct mutex lock;
+ struct device_node *np;
+ struct i2c_client *client;
+ struct of_gpio_chip of_gc;
+ u8 reg_ctrl;
+};
+
+static struct mcu *glob_mcu;
+
+static void mcu_power_off(void)
+{
+ struct mcu *mcu = glob_mcu;
+
+ pr_info(Sending power-off request to the MCU...\n);
+ mutex_lock(mcu-lock);
+ i2c_smbus_write_byte_data(glob_mcu-client, MCU_REG_CTRL,
+ mcu-reg_ctrl | MCU_CTRL_POFF);
+ mutex_unlock(mcu-lock);
+}
+
+static void mcu_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_gpio_chip *of_gc = to_of_gpio_chip(gc);
+ struct mcu *mcu = container_of(of_gc, struct mcu, of_gc);
+ u8 bit = 1 (4 + gpio);
+
+ mutex_lock(mcu-lock);
+ if (val)
+ mcu-reg_ctrl = ~bit;
+ else
+ mcu-reg_ctrl |= bit;
+
+ i2c_smbus_write_byte_data(mcu-client, MCU_REG_CTRL, mcu-reg_ctrl);
+ mutex_unlock(mcu-lock);
+}
+
+static int mcu_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ mcu_gpio_set(gc, gpio, val);
+ return 0;
+}
+
+static int mcu_gpiochip_add(struct mcu *mcu)
+{
+ struct device_node *np;
+ struct of_gpio_chip *of_gc = mcu-of_gc;
+ struct gpio_chip *gc = of_gc-gc;
+ int ret;
+
+ np = of_find_compatible_node(NULL, NULL, fsl,mcu-mpc8349emitx);
+ if (!np)
+ return -ENODEV;
+
+ gc-owner = THIS_MODULE;
+ gc-label = np-full_name;
+ gc-can_sleep = 1;
+ gc-ngpio = MCU_NUM_GPIO;
+ gc-base = -1;
+ gc-set = mcu_gpio_set;
+ gc-direction_output = mcu_gpio_dir_out;
+ of_gc-gpio_cells = 2;
+ of_gc-xlate = of_gpio_simple_xlate;
+
+ np-data = of_gc;
+ mcu-np = np;
+
+ /*
+* We don't want to lose the node, its -data and -full_name...
+* So, if succeeded, we don't put the node here.
+*/
+ ret = gpiochip_add(gc);
+ if (ret)
+ of_node_put(np);
+ return ret;
+}
+
+static int mcu_gpiochip_remove(struct mcu *mcu)
+{
+ int ret;
+
+ ret = gpiochip_remove(mcu-of_gc.gc);
+ if (ret)
+ return ret;
+ of_node_put(mcu-np);
+
+ return 0;
+}
+
+static int __devinit mcu_probe(struct i2c_client *client,
+ const struct
Re: [PATCH] powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/chips/
On Sun, Jan 11, 2009 at 06:10:55PM +0100, Jean Delvare wrote: Hi Anton, On Sun, 11 Jan 2009 19:51:36 +0300, Anton Vorontsov wrote: This patch is used to help Jean Delvare to get rid of drivers/i2c/chips/ directory. The new location suggested by Kumar Gala: as the driver is 83xx specific it's placed into arch/powerpc/platforms/83xx/. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com Thanks for doing this. Do you expect me to take this patch in my i2c tree, or will it go in some powerpc tree? As the patch adds some code to arch/powerpc/, I believe Kumar would want to merge it into his powerpc tree. In that case I think we'll need your Acked-by line for formality. But let's wait for Kumar's decision. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/chips/
Hi Anton, On Sun, 11 Jan 2009 19:51:36 +0300, Anton Vorontsov wrote: This patch is used to help Jean Delvare to get rid of drivers/i2c/chips/ directory. The new location suggested by Kumar Gala: as the driver is 83xx specific it's placed into arch/powerpc/platforms/83xx/. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com Thanks for doing this. Do you expect me to take this patch in my i2c tree, or will it go in some powerpc tree? -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Unsubscribe
Hi, I wish to unsubscribe from this list. Best Regards, Nadav Sharabi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards
On Wednesday 07 January 2009, Gerhard Pircher wrote: Original-Nachricht Datum: Wed, 7 Jan 2009 08:13:06 -0700 Von: Grant Likely grant.lik...@secretlab.ca An: Gerhard Pircher gerhard_pirc...@gmx.net CC: linuxppc-dev@ozlabs.org, bzoln...@gmail.com Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards On Wed, Jan 7, 2009 at 7:12 AM, Gerhard Pircher gerhard_pirc...@gmx.net wrote: The AmigaOne uses the onboard VIA IDE controller in legacy mode (like the Pegasos). Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net --- drivers/ide/via82cxxx.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) This patch needs to also be posted on the linux-ide mailing list. Ouch, I only sent it to the maintainer. I'll fix that. [ Please also keep all previous recipients on cc: when doing so. ] diff --git a/drivers/ide/via82cxxx.c b/drivers/ide/via82cxxx.c index 2a812d3..086f476 100644 --- a/drivers/ide/via82cxxx.c +++ b/drivers/ide/via82cxxx.c @@ -450,6 +450,11 @@ static int __devinit via_init_one(struct pci_dev *dev, const struct pci_device_i d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS; #endif +#ifdef CONFIG_AMIGAONE + if (machine_is(amigaone)) + d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS; +#endif + I know you're just following the example of the PEGASOS workaround immediately above; but the #defines are really ugly. I wonder if there is there a cleaner way to manipulate the flags. AFAIK the via82cxxx driver doesn't make use of the pci_get_legacy_ide_irq approach. I applied your patch for 2.6.29 but for 2.6.30 I would ask you to clean up #ifdefs by using ide_pci_is_in_compatibility_mode() helper instead for checking if IDE_HFLAG_FORCE_LEGACY_IRQS should be set. [ Some time ago Pegasos got PCI quirk to put controller in the legacy mode (arch/powerpc/platforms/chrp/pci.c) so it is OK to also remove Pegasos' special case while at it. ] Thanks, Bart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH][v3] powerpc 44x: support for 256KB PAGE_SIZE
This patch adds support for 256KB pages on ppc44x-based boards.
For simplification of implementation with 256KB pages we still assume
2-level paging. As a side effect this leads to wasting extra memory space
reserved for PTE tables: only 1/4 of pages allocated for PTEs are
actually used. But this may be an acceptable trade-off to achieve the
high performance we have with big PAGE_SIZEs in some applications (e.g.
RAID).
Also with 256KB PAGE_SIZE we increase THREAD_SIZE up to 32KB to minimize
the risk of stack overflows in the cases of on-stack arrays, which size
depends on the page size (e.g. multipage BIOs, NTFS, etc.).
With 256KB PAGE_SIZE we need to decrease the PKMAP_ORDER at least down
to 9, otherwise all high memory (2 ^ 10 * PAGE_SIZE == 256MB) we'll be
occupied by PKMAP addresses leaving no place for vmalloc. We do not
separate PKMAP_ORDER for 256K from 16K/64K PAGE_SIZE here; actually that
value of 10 in support for 16K/64K had been selected rather intuitively.
Thus now for all cases of PAGE_SIZE on ppc44x (including the default, 4KB,
one) we have 512 pages for PKMAP.
Because ELF standard supports only page sizes up to 64K, then you should
use binutils later than 2.17.50.0.3 with '-zmax-page-size' set to 256K
for building applications, which are to be run with the 256KB-page sized
kernel. If using the older binutils, then you should patch them like follows:
--- binutils/bfd/elf32-ppc.c.orig
+++ binutils/bfd/elf32-ppc.c
-#define ELF_MAXPAGESIZE0x1
+#define ELF_MAXPAGESIZE0x4
Signed-off-by: Yuri Tikhonov y...@emcraft.com
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
arch/powerpc/Kconfig | 15 +++
arch/powerpc/include/asm/highmem.h | 10 +-
arch/powerpc/include/asm/mmu-44x.h |2 ++
arch/powerpc/include/asm/page.h|6 --
arch/powerpc/include/asm/page_32.h |4
arch/powerpc/include/asm/thread_info.h |4 +++-
arch/powerpc/kernel/head_booke.h | 11 ++-
arch/powerpc/platforms/44x/Kconfig | 12
8 files changed, 55 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 84b8613..ceb402c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -443,6 +443,19 @@ config PPC_64K_PAGES
bool 64k page size if 44x || PPC_STD_MMU_64
select PPC_HAS_HASH_64K if PPC_STD_MMU_64
+config PPC_256K_PAGES
+ bool 256k page size if 44x
+ depends on !STDBINUTILS
+ help
+ Make the page size 256k.
+
+ As the ELF standard only requires alignment to support page
+ sizes up to 64k, you will need to compile all of your user
+ space applications with a non-standard binutils settings
+ (see the STDBINUTILS description for details).
+
+ Say N unless you know what you are doing.
+
endchoice
config FORCE_MAX_ZONEORDER
@@ -455,6 +468,8 @@ config FORCE_MAX_ZONEORDER
default 9 if PPC_STD_MMU_32 PPC_16K_PAGES
range 7 64 if PPC_STD_MMU_32 PPC_64K_PAGES
default 7 if PPC_STD_MMU_32 PPC_64K_PAGES
+ range 5 64 if PPC_STD_MMU_32 PPC_256K_PAGES
+ default 5 if PPC_STD_MMU_32 PPC_256K_PAGES
range 11 64
default 11
help
diff --git a/arch/powerpc/include/asm/highmem.h
b/arch/powerpc/include/asm/highmem.h
index 04e4a62..a290759 100644
--- a/arch/powerpc/include/asm/highmem.h
+++ b/arch/powerpc/include/asm/highmem.h
@@ -39,15 +39,15 @@ extern pte_t *pkmap_page_table;
* chunk of RAM.
*/
/*
- * We use one full pte table with 4K pages. And with 16K/64K pages pte
- * table covers enough memory (32MB and 512MB resp.) that both FIXMAP
- * and PKMAP can be placed in single pte table. We use 1024 pages for
- * PKMAP in case of 16K/64K pages.
+ * We use one full pte table with 4K pages. And with 16K/64K/256K pages pte
+ * table covers enough memory (32MB/512MB/2GB resp.), so that both FIXMAP
+ * and PKMAP can be placed in a single pte table. We use 512 pages for PKMAP
+ * in case of 16K/64K/256K page sizes.
*/
#ifdef CONFIG_PPC_4K_PAGES
#define PKMAP_ORDERPTE_SHIFT
#else
-#define PKMAP_ORDER10
+#define PKMAP_ORDER9
#endif
#define LAST_PKMAP (1 PKMAP_ORDER)
#ifndef CONFIG_PPC_4K_PAGES
diff --git a/arch/powerpc/include/asm/mmu-44x.h
b/arch/powerpc/include/asm/mmu-44x.h
index 27cc6fd..3c86576 100644
--- a/arch/powerpc/include/asm/mmu-44x.h
+++ b/arch/powerpc/include/asm/mmu-44x.h
@@ -83,6 +83,8 @@ typedef struct {
#define PPC44x_TLBE_SIZE PPC44x_TLB_16K
#elif (PAGE_SHIFT == 16)
#define PPC44x_TLBE_SIZE PPC44x_TLB_64K
+#elif (PAGE_SHIFT == 18)
+#define PPC44x_TLBE_SIZE PPC44x_TLB_256K
#else
#error Unsupported PAGE_SIZE
#endif
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 197d569..32cbf16 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -19,12 +19,14 @@
#include asm/kdump.h
Re: [PATCH] powerpc/83xx: Move mcu_mpc8349emitx driver out of drivers/i2c/chips/
On Sun, 11 Jan 2009 20:24:10 +0300, Anton Vorontsov wrote: On Sun, Jan 11, 2009 at 06:10:55PM +0100, Jean Delvare wrote: Hi Anton, On Sun, 11 Jan 2009 19:51:36 +0300, Anton Vorontsov wrote: This patch is used to help Jean Delvare to get rid of drivers/i2c/chips/ directory. The new location suggested by Kumar Gala: as the driver is 83xx specific it's placed into arch/powerpc/platforms/83xx/. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com Thanks for doing this. Do you expect me to take this patch in my i2c tree, or will it go in some powerpc tree? As the patch adds some code to arch/powerpc/, I believe Kumar would want to merge it into his powerpc tree. In that case I think we'll need your Acked-by line for formality. Sure: Acked-by: Jean Delvare kh...@linux-fr.org But let's wait for Kumar's decision. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
unsubscribe
unsubscribe please ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards
Original-Nachricht Datum: Sun, 11 Jan 2009 17:51:55 +0100 Von: Bartlomiej Zolnierkiewicz bzoln...@gmail.com An: Gerhard Pircher gerhard_pirc...@gmx.net CC: Grant Likely grant.lik...@secretlab.ca, linuxppc-dev@ozlabs.org, linux-...@vger.kernel.org Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards On Wednesday 07 January 2009, Gerhard Pircher wrote: Original-Nachricht Datum: Wed, 7 Jan 2009 08:13:06 -0700 Von: Grant Likely grant.lik...@secretlab.ca An: Gerhard Pircher gerhard_pirc...@gmx.net CC: linuxppc-dev@ozlabs.org, bzoln...@gmail.com Betreff: Re: [PATCH 5/5] ide: Force VIA IDE legacy interrupts for AmigaOne boards On Wed, Jan 7, 2009 at 7:12 AM, Gerhard Pircher gerhard_pirc...@gmx.net wrote: The AmigaOne uses the onboard VIA IDE controller in legacy mode (like the Pegasos). Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net --- drivers/ide/via82cxxx.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) This patch needs to also be posted on the linux-ide mailing list. Ouch, I only sent it to the maintainer. I'll fix that. [ Please also keep all previous recipients on cc: when doing so. ] Okay, I'll keep that in mind. diff --git a/drivers/ide/via82cxxx.c b/drivers/ide/via82cxxx.c index 2a812d3..086f476 100644 --- a/drivers/ide/via82cxxx.c +++ b/drivers/ide/via82cxxx.c @@ -450,6 +450,11 @@ static int __devinit via_init_one(struct pci_dev *dev, const struct pci_device_i d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS; #endif +#ifdef CONFIG_AMIGAONE + if (machine_is(amigaone)) + d.host_flags |= IDE_HFLAG_FORCE_LEGACY_IRQS; +#endif + I know you're just following the example of the PEGASOS workaround immediately above; but the #defines are really ugly. I wonder if there is there a cleaner way to manipulate the flags. AFAIK the via82cxxx driver doesn't make use of the pci_get_legacy_ide_irq approach. I applied your patch for 2.6.29 but for 2.6.30 I would ask you to clean up #ifdefs by using ide_pci_is_in_compatibility_mode() helper instead for checking if IDE_HFLAG_FORCE_LEGACY_IRQS should be set. Wouldn't it be better, if I clean this up now? (I have to resend my AmigaOne platform patches anyway). [ Some time ago Pegasos got PCI quirk to put controller in the legacy mode (arch/powerpc/platforms/chrp/pci.c) so it is OK to also remove Pegasos' special case while at it. ] Okay, so the change shouldn't break IDE for Pegasos machines (I don't have a Pegasos for testing). Thanks! Gerhard -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/9] sl82c105: remove dead code
Hello. Bartlomiej Zolnierkiewicz wrote: CONFIG_LOPEC and CONFIG_SANDPOINT config options are gone. So these are gone with arch/ppc/? That's a pity -- MV has spent a lot of efforts on porting the latter to arch/powerpc/ but somehow it haven't got merged upstream. My patches ot this driver were actually due to it being used on Sandpoint. :-) Signed-off-by: Bartlomiej Zolnierkiewicz bzoln...@gmail.com Acked-by: Sergei Shtylyov sshtyl...@ru.mvista.com MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: origin tree build failure
Hi Linus, Today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init': arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init': arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init': arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 (cpumask: convert struct cpufreq_policy to cpumask_var_t) which missed updating all the powerpc (at least) cpufreq drivers. Reverting that one commit required fixups, so I reverted merge commit 4e9b1c184cadbece3694603de5f880b6e35bd7a7 (Merge branch 'cpus4096-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip) instead. I am hoping that this will be fixed soon and that revert doesn't propagate more pain through today's linux-next. This branch was last committed to in the tip tree on Jan 7 (the patch above was committed on Jan 6) but was never propagated to linux-next before being merged into your tree yesterday. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpUf1PcEOiDZ.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote: Hi Linus, Today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init': arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init': arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init': arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 (cpumask: convert struct cpufreq_policy to cpumask_var_t) which missed updating all the powerpc (at least) cpufreq drivers. Yeah, it only updates x86 it seems ... Reverting that one commit required fixups, so I reverted merge commit 4e9b1c184cadbece3694603de5f880b6e35bd7a7 (Merge branch 'cpus4096-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip) instead. I am hoping that this will be fixed soon and that revert doesn't propagate more pain through today's linux-next. I've just made a patch, testing it now, will send it in a few minutes Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix cpufreq drivers after cpufreq core changes
This updates the cpufreq drivers in arch/powerpc so they build again
after the core cpufreq changes that broke them in commit
in835481d9bcd65720b473db6b38746a74a3964218.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
Tested on a G5. Olof, Arnd, any chance you can test the cell and pasemi
drivers still work ?
Linus, you can probably merge this now to fix the build problems.
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.c
b/arch/powerpc/platforms/cell/cbe_cpufreq.c
index ec7c8f4..e6506cd 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ b/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -118,7 +118,7 @@ static int cbe_cpufreq_cpu_init(struct cpufreq_policy
*policy)
policy-cur = cbe_freqs[cur_pmode].frequency;
#ifdef CONFIG_SMP
- policy-cpus = per_cpu(cpu_sibling_map, policy-cpu);
+ cpumask_copy(policy-cpus, per_cpu(cpu_sibling_map, policy-cpu));
#endif
cpufreq_frequency_table_get_attr(cbe_freqs, policy-cpu);
diff --git a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
index a3c6c01..968c1c0 100644
--- a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
+++ b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
@@ -110,7 +110,7 @@ static int spu_gov_govern(struct cpufreq_policy *policy,
unsigned int event)
}
/* initialize spu_gov_info for all affected cpus */
- for_each_cpu_mask(i, policy-cpus) {
+ for_each_cpu(i, policy-cpus) {
affected_info = per_cpu(spu_gov_info, i);
affected_info-policy = policy;
}
@@ -127,7 +127,7 @@ static int spu_gov_govern(struct cpufreq_policy *policy,
unsigned int event)
spu_gov_cancel_work(info);
/* clean spu_gov_info for all affected cpus */
- for_each_cpu_mask (i, policy-cpus) {
+ for_each_cpu (i, policy-cpus) {
info = per_cpu(spu_gov_info, i);
info-policy = NULL;
}
diff --git a/arch/powerpc/platforms/pasemi/cpufreq.c
b/arch/powerpc/platforms/pasemi/cpufreq.c
index 86db47c..be2527a 100644
--- a/arch/powerpc/platforms/pasemi/cpufreq.c
+++ b/arch/powerpc/platforms/pasemi/cpufreq.c
@@ -213,7 +213,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy
*policy)
pr_debug(current astate is at %d\n,cur_astate);
policy-cur = pas_freqs[cur_astate].frequency;
- policy-cpus = cpu_online_map;
+ cpumask_copy(policy-cpus, cpu_online_map);
ppc_proc_freq = policy-cur * 1000ul;
diff --git a/arch/powerpc/platforms/powermac/cpufreq_64.c
b/arch/powerpc/platforms/powermac/cpufreq_64.c
index 4dfb4bc..beb3833 100644
--- a/arch/powerpc/platforms/powermac/cpufreq_64.c
+++ b/arch/powerpc/platforms/powermac/cpufreq_64.c
@@ -362,7 +362,7 @@ static int g5_cpufreq_cpu_init(struct cpufreq_policy
*policy)
/* secondary CPUs are tied to the primary one by the
* cpufreq core if in the secondary policy we tell it that
* it actually must be one policy together with all others. */
- policy-cpus = cpu_online_map;
+ cpumask_copy(policy-cpus, cpu_online_map);
cpufreq_frequency_table_get_attr(g5_cpu_freqs, policy-cpu);
return cpufreq_frequency_table_cpuinfo(policy,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] mb862xx: Restrict compliation of platform driver to PPC
mb862xx: Restrict compliation of platform driver to PPC The OpenFirmware part of this driver is uncompilable on SPARC due to it's dependance on several PPC specific functions. Restricting this to PPC to prevent these build errors. This was found using randconfig builds. Signed-off-by: Julian Calaby julian.cal...@gmail.com --- A couple of notes: 1. After looking at the includes used by this driver, the OF part may not compile cleanly on PPC either as it doesn't appear to pull in the required headers for all the functions and constants it uses. 2. Also, this bug will *not* show up in allmodconfigs or allyesconfigs as the OF part of this driver is prevented from building when the PCI driver is built, and the PCI driver appears first. 3. This patch is over DaveM's sparc-2.6 git tree as of today. 4. I apologise for the massive cross-posting - I am not sure where exactly to send this patch. 5. Please note that I am not a member of any of these lists, so please keep me CC'd. Thanks, Julian Calaby --- drivers/video/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 6372f8b..8f18169 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2111,6 +2111,7 @@ config FB_MB862XX_LIME bool Lime GDC depends on FB_MB862XX depends on OF !FB_MB862XX_PCI_GDC + depends on PPC select FB_FOREIGN_ENDIAN select FB_LITTLE_ENDIAN ---help--- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: rework dma-noncoherent to use generic vmap/vunmap functions
On Sat, Jan 10, 2009 at 05:31:19PM -0700, Grant Likely wrote:
On Fri, Jan 9, 2009 at 5:58 AM, Ilya Yanok ya...@emcraft.com wrote:
This patch rewrites consistent dma allocations support to use vmalloc
layer to allocate virtual memory space from vmalloc pool and get rid
of CONFIG_CONSISTENT_{START,SIZE}.
Impressive patch. I'll pull it into my tree and see how it works on
4xx and 5200.
Doing my job for me now? ;)
BTW, you can drop all the defconfig updates in this patch. The old
config values will just disappear when 'make *_defconfig' is run.
Putting them in the patch makes it far more likely that it won't apply
at a later date.
Yes, totally agreed. I update the 4xx defconfigs every release, so
they will get changed when I do that.
As Ben said, this is probably too late for .29, but definitely seems
like the right way to go.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][v3] powerpc 44x: support for 256KB PAGE_SIZE
On Sun, Jan 11, 2009 at 09:42:30PM +0300, Yuri Tikhonov wrote: This patch adds support for 256KB pages on ppc44x-based boards. For simplification of implementation with 256KB pages we still assume 2-level paging. As a side effect this leads to wasting extra memory space reserved for PTE tables: only 1/4 of pages allocated for PTEs are actually used. But this may be an acceptable trade-off to achieve the high performance we have with big PAGE_SIZEs in some applications (e.g. RAID). Also with 256KB PAGE_SIZE we increase THREAD_SIZE up to 32KB to minimize the risk of stack overflows in the cases of on-stack arrays, which size depends on the page size (e.g. multipage BIOs, NTFS, etc.). With 256KB PAGE_SIZE we need to decrease the PKMAP_ORDER at least down to 9, otherwise all high memory (2 ^ 10 * PAGE_SIZE == 256MB) we'll be occupied by PKMAP addresses leaving no place for vmalloc. We do not separate PKMAP_ORDER for 256K from 16K/64K PAGE_SIZE here; actually that value of 10 in support for 16K/64K had been selected rather intuitively. Thus now for all cases of PAGE_SIZE on ppc44x (including the default, 4KB, one) we have 512 pages for PKMAP. Because ELF standard supports only page sizes up to 64K, then you should use binutils later than 2.17.50.0.3 with '-zmax-page-size' set to 256K for building applications, which are to be run with the 256KB-page sized kernel. If using the older binutils, then you should patch them like follows: --- binutils/bfd/elf32-ppc.c.orig +++ binutils/bfd/elf32-ppc.c -#define ELF_MAXPAGESIZE 0x1 +#define ELF_MAXPAGESIZE 0x4 Signed-off-by: Yuri Tikhonov y...@emcraft.com Signed-off-by: Ilya Yanok ya...@emcraft.com Thanks. I particularly like the additional option you have to disable before 256K pages is an option. I'll do a bit of testing, and barring any unforeseen problems, I'll queue this up for 2.6.30. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
unsubscribe
unsubscribe please ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev Check out the all-new Messenger 9.0! Go to http://in.messenger.yahoo.com/___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Unsubscribe
I wish to unsubscribe from this list. Best Regards, ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powermac: Fix occasional SMP boot failure
The PowerMac kernel occasionally fails to bring up the secondary CPUs on SMP, the trigger factor seem to be fairly random and related to location of code and data. This appears to be due to the initial loading of the TOC value by the secondary processor which now happens before we clear HID4:RM_CI (Real Mode Cache Invalidate). This bit should really be cleared before we do any load or store other than fetching code. This fix works based on the assumption that all SMP 64-bit PowerMacs use variants of the 970, which fortunately is true, by explicitely clearing that bit, adding an slbia for good measure as RM_CI mode is known to create bogus ERAT entries. I also removed some spurrious debug output that was left enabled by mistake while at it. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index b4bcf5a..ebaedaf 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -1518,6 +1518,15 @@ _GLOBAL(pmac_secondary_start) /* turn on 64-bit mode */ bl .enable_64b_mode + li r0,0 + mfspr r3,SPRN_HID4 + rldimi r3,r0,40,23 /* clear bit 23 (rm_ci) */ + sync + mtspr SPRN_HID4,r3 + isync + sync + slbia + /* get TOC pointer (real address) */ bl .relative_toc diff --git a/arch/powerpc/platforms/powermac/smp.c b/arch/powerpc/platforms/powermac/smp.c index 6b0711c..bd8817b 100644 --- a/arch/powerpc/platforms/powermac/smp.c +++ b/arch/powerpc/platforms/powermac/smp.c @@ -53,7 +53,7 @@ #include asm/pmac_low_i2c.h #include asm/pmac_pfunc.h -#define DEBUG +#undef DEBUG #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc: Generic device tree for all AmigaOne boards
On Wed, 2009-01-07 at 09:41 -0700, Grant Likely wrote: For the flattened device tree, I think we've settled on the convention that every node with an IRQ connection should have both the interrupt-parent and interrupts properties. (ie. don't rely on the parent node's interrupt-parent property.) Ah ? I use the trick of relying on the parent node regulary :-) Where did we discuss that ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc: Generic device tree for all AmigaOne boards
Yes, all AmigaOne boards have physical PCI slots (at least 1). The different interrupt routing wasn't a problem so far, as the firmware writes the IRQ number to the interrupt line register of every PCI device. The code in the kernel that retreives the interrupt that way is clearly marked as a fishy workaround for bogus firmwares :-) But I'm not going to reject things based on that, it will work for simple board using really only legacy interrupts like yours... Currently the kernel reads the IRQ number from this register, if there is no interrupt mapping property. I know that it's not a good idea to rely on kernel fallback behavior, but it makes a lot of things easier in this case. Sort-of. As long as it's really 8259 interrupts, I suppose it's acceptable. For the flattened device tree, I think we've settled on the convention that every node with an IRQ connection should have both the interrupt-parent and interrupts properties. (ie. don't rely on the parent node's interrupt-parent property.) Even for ISA devices? I disagree with Grant here. Especially in simple ISA cases like that, there's really no point in bloating the device-tree. Can this PCI device be probed? Typically PCI devices don't get added to the flattened device tree because PCI is a probeable bus. Yes, it can be probed. I thought it would be a good idea to include it, because the IDE controller operates in legacy mode. I planned to specify the two legacy interrupts in this node (as you can see), but the kernel didn't like them. Well, the kernel just didn't make use of them I'd say :-) But that can probably be fixed with the appropriate hacks. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc: Add platform support for AmigaOne
+ /* Flush and disable I/D cache. */ + __asm__ __volatile__ (mfspr3, 1008::: r3); + __asm__ __volatile__ (ori 5, 5, 0xcc00 ::: r5); + __asm__ __volatile__ (ori 4, 3, 0xc00::: r4); + __asm__ __volatile__ (andc 5, 3, 5::: r5); Don't do this; instead, have one multi-line asm statement (or better yet, just use mfspr()/mtspr()/sync()/isync()). GCC is perfectly free to trash your registers in between statements. Also there's already some code around to properly flush disable the caches on those processors. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
unsubscribe
深圳中兴力维技术有限公司 地址：深圳市高新区科技南一路W1-A二楼 电话：0755-26525674-8509（办公室） ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc: Generic device tree for all AmigaOne boards
On Sun, Jan 11, 2009 at 10:07 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2009-01-07 at 09:41 -0700, Grant Likely wrote: For the flattened device tree, I think we've settled on the convention that every node with an IRQ connection should have both the interrupt-parent and interrupts properties. (ie. don't rely on the parent node's interrupt-parent property.) Ah ? I use the trick of relying on the parent node regulary :-) Where did we discuss that ? It is also entirely possible that I'm smoking something exotic. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5 + 2] kexec updates
On Fri, Jan 02, 2009 at 02:42:38PM -0600, Milton Miller wrote: Follwing this mail are 5 patches for kexec userspace and two for the kernel. The first fixes an array overflow and the second updates userspace to the merged 2.6.28 kdump support. The remaining are cleanups and warning fixes, including one for the common code. The two patchs for the kernel are independent. Hi all, sorry to be a bit slow in responding, this email landed just as I was leaving for a weeks holiday. The kexec-tools patches seem reasonable to me and I'm happy to merge what I think are the latest versions - thanks Michael for your review. Milton, here are the Subjects, Dates and Message-Ids of what I have in my queue. If you could confirm this or repost that would be great. #1 Subject: [PATCH kexec-tools v2] ppc64: always check number of ranges when adding them Date: Thu, 08 Jan 2009 06:33:50 -0600 Message-ID: 1231418030_141...@mercury.realtime.net #2 Subject: [PATCH kexec-tools 2/5] ppc64: update kdump for 2.6.28 relocatable kernel Date: Fri, 02 Jan 2009 15:04:42 -0600 Message-Id: kexec-29-1-2r.milt...@bga.com #3 Subject: [PATCH kexec-tools 3/5] ppc64: segments may be reordered Date: Fri, 02 Jan 2009 15:04:45 -0600 Message-Id: kexec-29-1-3r.milt...@bga.com #4 Subject: [PATCH kexec-tools 4/5] ppc64: cleanups Date: Fri, 02 Jan 2009 15:04:48 -0600 Message-Id: kexec-29-1-4r.milt...@bga.com #5 Subject: [PATCH kexec-tools 5/5] entry wants to be void * Date: Fri, 02 Jan 2009 15:04:51 -0600 Message-Id: kexec-29-1-5r.milt...@bga.com -- Simon Horman VA Linux Systems Japan K.K., Sydney, Australia Satellite Office H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
How does map_flash_by_law1 work?
I'm reading the start.S for mpc83xx in u-boot. I couldn't understand how the source code below work: /*** map_flash_by_law1: /* When booting from ROM (Flash or EPROM), clear the */ /* Address Mask in OR0 so ROM appears everywhere */ /**/ lis r3, (CFG_IMMR)@h /* r3 = CFG_IMMR*/ lwz r4, o...@l(r3) li r5, 0x7fff/* r5 = 0x7 */ and r4, r4, r5 stw r4, o...@l(r3) /* OR0 = OR0 0x7 */ /* As MPC8349E User's Manual presented, when RCW[BMS] is set to 0, * system will boot from 0x_0100, and the LBLAWBAR0[BASE_ADDR] * reset value is 0x0; when RCW[BMS] is set to 1, system will boot * from 0xFFF0_0100, and the LBLAWBAR0[BASE_ADDR] reset value is * 0xFF800. From the hard resetting to here, the processor fetched and * executed the instructions one by one. There is not absolutely * jumping happened. Laterly, the u-boot code has to do an absolutely * jumping to tell the CPU instruction fetching component what the * u-boot TEXT base address is. Because the TEXT base resides in the * boot ROM memory space, to garantee the code can run smoothly after * that jumping, we must map in the entire boot ROM by Local Access * Window. Sometimes, we desire an non-0x0 or non-0xFF800 starting * address for boot ROM, such as 0xFE00. In this case, the default * LBIU Local Access Widow 0 will not cover this memory space. So, we * need another wind ow to map in it. */ lis r4, (CFG_FLASH_BASE)@h ori r4, r4, (CFG_FLASH_BASE)@l stw r4, LBLAWBAR1(r3) /* LBLAWBAR1 = CFG_FLASH_BASE */ /* Store 0x8012 + log2(CFG_FLASH_SIZE) into LBLAWAR1 */ /*0x8000_ is used to enable this window*/ /*0x_-0x_0012 is the reserved window size*/ lis r4, (0x8012)@h ori r4, r4, (0x8012)@l li r5, CFG_FLASH_SIZE1: srawi. r5, r5, 1 /* r5 = r5 1 */ addi r4, r4, 1 bne 1b stw r4, LBLAWAR1(r3) /* LBLAWAR1 = Flash Size */ blr / the problem is from this segment: 1: srawi. r5, r5, 1 /* r5 = r5 1 */ addi r4, r4, 1 bne 1b How it adjust the flash size to the fit size? I define the CFG_FLASH_SIZE equal 1 in the MPC8313ERDB.h _ 微软地图率先推出跨城市多点驾车路线查询！ http://ditu.live.com/?form=MRAHABrtp=pos.30.454167_116.308611_%E5%A4%AA%E6%B9%96__~pos.29.554046_115.983427_%E5%BA%90%E5%B1%B1__~pos.29.116111_110.478889_%E5%BC%A0%E5%AE%B6%E7%95%8C__rtop=0~0~0encType=1___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.28-git-4 - powerpc - kernel expection 'c01 at .kernel_thread'
* Rafael J. Wysocki r...@sisk.pl [2009-01-11 01:08:19]: On Friday 02 January 2009, Kamalesh Babulal wrote: Hi, 2.6.28-git4 kernel drops to xmon with kernel expection. Similar kernel expection was seen next-20081230 and next-20081231 and was reported earlier at http://lkml.org/lkml/2008/12/31/157 Is this a regression from 2.6.27? Rafael This is not a regression from 2.6.27, this expection was first seen next-20081230 patches and then was introduced into 2.6.28-git4 and is reproducible with 2.6.28-rc1 kernel. -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc/83xx: Make serial ports work on MPC8315E-RDB w/FSL U-Boots
-Original Message- From: linuxppc-dev-bounces+leoli=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+leoli=freescale@ozlabs.org] On Behalf Of Anton Vorontsov Sent: Sunday, January 11, 2009 11:30 PM To: Kumar Gala Cc: linuxppc-dev@ozlabs.org Subject: [PATCH] powerpc/83xx: Make serial ports work on MPC8315E-RDB w/FSL U-Boots FSL U-Boots use /soc8...@e000 node to search and fixup serial nodes' clock-frequency properties. Though in upstream kernels we use new naming convention -- for IMMR address space dts files specify /i...@e000 nodes. This makes FSL U-Boots fail to fixup the clock frequencies, and that leads to serial ports misbehaviour. We can workaround the issue by filling the clock frequency values manually. Freescale BSP is for customer who needs the out-of-box experience. It's better tested, but doesn't update very frequently. I would suggest the customer to use the upstream u-boot, if they decide to use latest upstream kernel. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
