* [PATCH 1/3] PowerPC: Add device-tree aware PowerPC 44x NDFC driver
From: Valentine Barshak @ 2007-10-29 20:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tglx, sr, linux-mtd
In-Reply-To: <20071029201738.GA2022@ru.mvista.com>
This adds support of the built-in PowerPC 44x NanD Flash Controller (NDFC)
based on the OF description. This version supports both separate mtd devices on
each NDFC bank and mtd devices spread across identical chips attached to NDFC
banks depending on the device tree settings. This is based on the original NDFC
driver by Thomas Gleixner, but since a lot of things have been reworked it's
been put to a separate ndfc_of file.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/mtd/nand/Kconfig | 7
drivers/mtd/nand/Makefile | 1
drivers/mtd/nand/ndfc_of.c | 599 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/mtd/ndfc.h | 4
4 files changed, 611 insertions(+)
diff -pruN linux-2.6.orig/drivers/mtd/nand/Kconfig linux-2.6/drivers/mtd/nand/Kconfig
--- linux-2.6.orig/drivers/mtd/nand/Kconfig 2007-10-29 16:02:37.000000000 +0300
+++ linux-2.6/drivers/mtd/nand/Kconfig 2007-10-29 19:02:13.000000000 +0300
@@ -158,6 +158,13 @@ config MTD_NAND_NDFC
help
NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
+config MTD_NAND_NDFC_OF
+ tristate "NDFC NanD Flash Controller based on OF"
+ depends on 44x && PPC_MERGE
+ select MTD_NAND_ECC_SMC
+ help
+ NDFC Nand Flash Controllers are integrated in EP44x SoCs
+
config MTD_NAND_S3C2410_CLKSTOP
bool "S3C2410 NAND IDLE clock stop"
depends on MTD_NAND_S3C2410
diff -pruN linux-2.6.orig/drivers/mtd/nand/Makefile linux-2.6/drivers/mtd/nand/Makefile
--- linux-2.6.orig/drivers/mtd/nand/Makefile 2007-10-29 16:02:37.000000000 +0300
+++ linux-2.6/drivers/mtd/nand/Makefile 2007-10-29 18:59:11.000000000 +0300
@@ -24,6 +24,7 @@ obj-$(CONFIG_MTD_NAND_TS7250) += ts7250
obj-$(CONFIG_MTD_NAND_NANDSIM) += nandsim.o
obj-$(CONFIG_MTD_NAND_CS553X) += cs553x_nand.o
obj-$(CONFIG_MTD_NAND_NDFC) += ndfc.o
+obj-$(CONFIG_MTD_NAND_NDFC_OF) += ndfc_of.o
obj-$(CONFIG_MTD_NAND_AT91) += at91_nand.o
obj-$(CONFIG_MTD_NAND_CM_X270) += cmx270_nand.o
obj-$(CONFIG_MTD_NAND_BASLER_EXCITE) += excite_nandflash.o
diff -pruN linux-2.6.orig/drivers/mtd/nand/ndfc_of.c linux-2.6/drivers/mtd/nand/ndfc_of.c
--- linux-2.6.orig/drivers/mtd/nand/ndfc_of.c 1970-01-01 03:00:00.000000000 +0300
+++ linux-2.6/drivers/mtd/nand/ndfc_of.c 2007-10-29 22:07:45.000000000 +0300
@@ -0,0 +1,598 @@
+/*
+ * Overview:
+ * Platform independend driver for NDFC (NanD Flash Controller)
+ * integrated into EP440 cores with OF device tree support
+ *
+ * Based on the original ndfc driver by Thomas Gleixner
+ *
+ * Copyright 2006 IBM
+ *
+ * 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/module.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/ndfc.h>
+#include <linux/mtd/mtd.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+
+#include <asm/io.h>
+
+
+struct of_ndfc {
+ __iomem void *base;
+ struct resource *res;
+ uint32_t bank_mask;
+ struct nand_hw_control control;
+ struct list_head list;
+};
+
+struct of_ndfc_mtd {
+ struct list_head list;
+ struct of_ndfc *ndfc;
+ unsigned char banks[NDFC_MAX_BANKS];
+ unsigned chip_cnt;
+ struct nand_chip chip;
+ struct mtd_info mtd;
+#ifdef CONFIG_MTD_PARTITIONS
+ struct mtd_partition *parts;
+#endif
+};
+
+static inline u32 ndfc_raw_readl(struct of_ndfc *ndfc, u32 off)
+{
+ return __raw_readl(ndfc->base + off);
+}
+
+static inline void ndfc_raw_writel(struct of_ndfc *ndfc, u32 off, u32 val)
+{
+ __raw_writel(val, ndfc->base + off);
+}
+
+static inline void ndfc_writel(struct of_ndfc *ndfc, u32 off, u32 val)
+{
+ writel(val, ndfc->base + off);
+}
+
+static void ndfc_select_chip(struct mtd_info *mtd, int chip)
+{
+ struct nand_chip *this = mtd->priv;
+ struct of_ndfc_mtd *ndfc_mtd = this->priv;
+ struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+ uint32_t ccr;
+
+ ccr = ndfc_raw_readl(ndfc, NDFC_CCR);
+ if ((chip >= 0) && (chip < ndfc_mtd->chip_cnt)) {
+ ccr &= ~NDFC_CCR_BS_MASK;
+ ccr |= NDFC_CCR_BS(ndfc_mtd->banks[chip]);
+ } else
+ ccr |= NDFC_CCR_RESET_CE;
+ ndfc_raw_writel(ndfc, NDFC_CCR, ccr);
+}
+
+static void ndfc_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+ struct nand_chip *this = mtd->priv;
+ struct of_ndfc_mtd *ndfc_mtd = this->priv;
+ struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ if (ctrl & NAND_CLE)
+ ndfc_writel(ndfc, NDFC_CMD, cmd & 0xff);
+ else
+ ndfc_writel(ndfc, NDFC_ALE, cmd & 0xff);
+}
+
+static int ndfc_ready(struct mtd_info *mtd)
+{
+ struct nand_chip *this = mtd->priv;
+ struct of_ndfc_mtd *ndfc_mtd = this->priv;
+ struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+
+ return ndfc_raw_readl(ndfc, NDFC_STAT) & NDFC_STAT_IS_READY;
+}
+
+static void ndfc_enable_hwecc(struct mtd_info *mtd, int mode)
+{
+ struct nand_chip *this = mtd->priv;
+ struct of_ndfc_mtd *ndfc_mtd = this->priv;
+ struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+ uint32_t ccr;
+
+ ccr = ndfc_raw_readl(ndfc, NDFC_CCR);
+ ccr |= NDFC_CCR_RESET_ECC;
+ ndfc_raw_writel(ndfc, NDFC_CCR, ccr);
+ wmb();
+}
+
+
+static int ndfc_calculate_ecc(struct mtd_info *mtd,
+ const u_char *dat, u_char *ecc_code)
+{
+ struct nand_chip *this = mtd->priv;
+ struct of_ndfc_mtd *ndfc_mtd = this->priv;
+ struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+ uint32_t ecc;
+ uint8_t *p = (uint8_t *)&ecc;
+
+ wmb();
+ ecc = ndfc_raw_readl(ndfc, NDFC_ECC);
+ ecc_code[0] = p[1];
+ ecc_code[1] = p[2];
+ ecc_code[2] = p[3];
+
+ return 0;
+}
+
+
+/*
+ * Speedups for buffer read/write/verify
+ *
+ * NDFC allows 32bit read/write of data. So we can speed up the buffer
+ * functions. No further checking, as nand_base will always read/write
+ * page aligned.
+ */
+static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+ struct nand_chip *this = mtd->priv;
+ struct of_ndfc_mtd *ndfc_mtd = this->priv;
+ struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+ uint32_t *p = (uint32_t *) buf;
+
+ for(;len > 0; len -= 4)
+ *p++ = ndfc_raw_readl(ndfc, NDFC_DATA);
+}
+
+static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+ struct nand_chip *this = mtd->priv;
+ struct of_ndfc_mtd *ndfc_mtd = this->priv;
+ struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+ uint32_t *p = (uint32_t *) buf;
+
+ for(;len > 0; len -= 4)
+ ndfc_raw_writel(ndfc, NDFC_DATA, *p++);
+}
+
+static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+ struct nand_chip *this = mtd->priv;
+ struct of_ndfc_mtd *ndfc_mtd = this->priv;
+ struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+ uint32_t *p = (uint32_t *) buf;
+
+ for(;len > 0; len -= 4)
+ if (*p++ != ndfc_raw_readl(ndfc, NDFC_DATA))
+ return -EFAULT;
+ return 0;
+}
+
+
+#ifdef CONFIG_MTD_PARTITIONS
+#define OF_FLASH_PARTS(ndfc_mtd) ((ndfc_mtd)->parts)
+static int __devinit parse_partitions(struct of_ndfc_mtd *ndfc_mtd,
+ struct device_node *dp)
+{
+ const char *partname;
+ static const char *part_probe_types[]
+ = { "cmdlinepart", "RedBoot", NULL };
+ struct device_node *pp;
+ int nr_parts, i;
+
+ /* First look for RedBoot table or partitions on the command
+ * line, these take precedence over device tree information */
+ nr_parts = parse_mtd_partitions(&ndfc_mtd->mtd, part_probe_types,
+ &ndfc_mtd->parts, 0);
+ if (nr_parts > 0)
+ return nr_parts;
+
+ /* First count the subnodes */
+ nr_parts = 0;
+ for (pp = of_get_next_child(dp, NULL); pp;
+ pp = of_get_next_child(dp, pp))
+ nr_parts++;
+
+ if (nr_parts == 0)
+ return 0;
+
+ ndfc_mtd->parts = kzalloc(nr_parts * sizeof(*ndfc_mtd->parts),
+ GFP_KERNEL);
+ if (!ndfc_mtd->parts)
+ return -ENOMEM;
+
+ for (pp = of_get_next_child(dp, NULL), i = 0; pp;
+ pp = of_get_next_child(dp, pp), i++) {
+ const u32 *reg;
+ int len;
+
+ reg = of_get_property(pp, "reg", &len);
+ if (!reg || (len != 2*sizeof(u32))) {
+ of_node_put(pp);
+ printk(KERN_ERR "%s: Invalid 'reg'\n",
+ dp->full_name);
+ kfree(ndfc_mtd->parts);
+ ndfc_mtd->parts = NULL;
+ return -EINVAL;
+ }
+ ndfc_mtd->parts[i].offset = reg[0];
+ ndfc_mtd->parts[i].size = reg[1];
+
+ partname = of_get_property(pp, "label", &len);
+ if (!partname)
+ partname = of_get_property(pp, "name", &len);
+ ndfc_mtd->parts[i].name = (char *)partname;
+
+ if (of_get_property(pp, "read-only", &len))
+ ndfc_mtd->parts[i].mask_flags = MTD_WRITEABLE;
+ }
+
+ return nr_parts;
+}
+#else /* MTD_PARTITIONS */
+#define OF_FLASH_PARTS(ndfc_mtd) (0)
+static inline int parse_partitions(struct of_ndfc *ndfc, struct of_device *dev)
+{
+ return 0;
+}
+#endif /* MTD_PARTITIONS */
+
+
+static inline uint32_t ndfc_mtd_bank_mask(struct of_ndfc_mtd *ndfc_mtd)
+{
+ unsigned i;
+ uint32_t mask = 0;
+
+ for (i = 0; i < ndfc_mtd->chip_cnt; i++)
+ mask |= 1 << ndfc_mtd->banks[i];
+
+ return mask;
+}
+
+
+static inline void ndfc_del_mtd(struct of_ndfc *ndfc, struct of_ndfc_mtd *ndfc_mtd)
+{
+ uint32_t busy;
+
+ list_del(&ndfc_mtd->list);
+ busy = ndfc_mtd_bank_mask(ndfc_mtd);
+ ndfc->bank_mask &= ~busy;
+}
+
+
+static inline void ndfc_add_mtd(struct of_ndfc *ndfc, struct of_ndfc_mtd *ndfc_mtd)
+{
+ uint32_t busy;
+
+ busy = ndfc_mtd_bank_mask(ndfc_mtd);
+ ndfc->bank_mask |= busy;
+ list_add(&ndfc_mtd->list, &ndfc->list);
+}
+
+
+static int of_ndfc_remove(struct of_device *dev)
+{
+ struct of_ndfc_mtd *ndfc_mtd, *ndfc_mtd_next;
+ struct of_ndfc *ndfc;
+
+ ndfc = dev_get_drvdata(&dev->dev);
+ if (!ndfc)
+ return 0;
+
+ /* remove all mtd devices first*/
+ list_for_each_entry_safe(ndfc_mtd, ndfc_mtd_next,
+ &ndfc->list, list) {
+ if (OF_FLASH_PARTS(ndfc_mtd)) {
+ del_mtd_partitions(&ndfc_mtd->mtd);
+ kfree(OF_FLASH_PARTS(ndfc_mtd));
+ } else {
+ del_mtd_device(&ndfc_mtd->mtd);
+ }
+ nand_release(&ndfc_mtd->mtd);
+
+ ndfc_del_mtd(ndfc, ndfc_mtd);
+ kfree(ndfc_mtd);
+ }
+
+ dev_set_drvdata(&dev->dev, NULL);
+
+ if (ndfc->base)
+ iounmap(ndfc->base);
+
+ if (ndfc->res) {
+ release_resource(ndfc->res);
+ kfree(ndfc->res);
+ }
+
+ kfree(ndfc);
+ return 0;
+}
+
+
+static int __devinit ndfc_get_bank_map_prop(struct device_node *dp,
+ unsigned char *map,
+ uint32_t busy)
+{
+ const u32 *prop;
+ u32 val, len, mask;
+ int i;
+
+ prop = of_get_property(dp, "bank-map", &len);
+ if (!prop || (len < sizeof(u32)))
+ return -EFAULT;
+
+ for (i = 0; i < len / sizeof(u32); i++) {
+ val = prop[i];
+ if (val > NDFC_MAX_BANKS) {
+ printk(KERN_ERR "%s: Invalid bank (%i)\n",
+ dp->full_name, val);
+ return -EINVAL;
+ }
+
+ mask = 1 << val;
+ if (busy & mask) {
+ printk(KERN_ERR "%s: Busy bank (%i)\n",
+ dp->full_name, val);
+ return -EBUSY;
+ }
+
+ busy |= mask;
+ map[i] = (unsigned char)val;
+ }
+ return i;
+}
+
+
+static __devinit void ndfc_mtd_chip_init(struct of_ndfc_mtd *ndfc_mtd,
+ struct device_node *dp)
+{
+ struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+ struct nand_chip *chip = &ndfc_mtd->chip;
+ const u32 *prop;
+
+ chip->IO_ADDR_R = ndfc->base + NDFC_DATA;
+ chip->IO_ADDR_W = ndfc->base + NDFC_DATA;
+ chip->cmd_ctrl = ndfc_hwcontrol;
+ chip->dev_ready = ndfc_ready;
+ chip->select_chip = ndfc_select_chip;
+ chip->controller = &ndfc->control;
+ chip->read_buf = ndfc_read_buf;
+ chip->write_buf = ndfc_write_buf;
+ chip->verify_buf = ndfc_verify_buf;
+ chip->ecc.correct = nand_correct_data;
+ chip->ecc.hwctl = ndfc_enable_hwecc;
+ chip->ecc.calculate = ndfc_calculate_ecc;
+ chip->ecc.mode = NAND_ECC_HW;
+ chip->ecc.size = 256;
+ chip->ecc.bytes = 3;
+
+ /* look for chip options */
+ prop = of_get_property(dp, "chip-options", NULL);
+ if (prop)
+ ndfc_mtd->chip.options = *prop;
+
+ /* look for chip delay */
+ prop = of_get_property(dp, "chip-delay", NULL);
+ if (prop)
+ chip->chip_delay = *prop;
+ else
+ chip->chip_delay = 50;
+ chip->priv = ndfc_mtd;
+}
+
+
+static int __devinit ndfc_init_mtd(struct of_ndfc *ndfc, struct device_node *dp)
+{
+ const u32 *prop;
+ uint32_t bcr;
+ struct of_ndfc_mtd *ndfc_mtd;
+ int i, err;
+
+ if (!ndfc || !dp)
+ return -EINVAL;
+
+ ndfc_mtd = kzalloc(sizeof(struct of_ndfc_mtd), GFP_KERNEL);
+ if (!ndfc_mtd)
+ return -ENOMEM;
+
+ ndfc_mtd->ndfc = ndfc;
+
+ /* look for a bank-map */
+ err = ndfc_get_bank_map_prop(dp, ndfc_mtd->banks, ndfc->bank_mask);
+ if (err < 0)
+ goto err_out;
+
+ if (err == 0) {
+ err = -ENODEV;
+ goto err_out;
+ }
+ ndfc_mtd->chip_cnt = err;
+
+ /* look for bank settings */
+ prop = of_get_property(dp, "bank-settings", NULL);
+ if (prop) {
+ bcr = *prop | NDFC_BxCFG_EN;
+ } else {
+ bcr = NDFC_BxCFG_RR(2) | NDFC_BxCFG_RWH(2) |
+ NDFC_BxCFG_RWP(2) | NDFC_BxCFG_CRW(2);
+ }
+
+ /* look for bank width */
+ prop = of_get_property(dp, "bank-width", NULL);
+ if (prop && (*prop == 2))
+ bcr |= NDFC_BxCFG_SZ_16BIT;
+
+ /* setup banks for this mtd device */
+ for (i = 0; i < ndfc_mtd->chip_cnt; i++) {
+ ndfc_raw_writel(ndfc,
+ NDFC_BCFG0 + (ndfc_mtd->banks[i] << 2), bcr);
+ }
+
+ ndfc_mtd_chip_init(ndfc_mtd, dp);
+
+ if (bcr & NDFC_BxCFG_SZ_16BIT)
+ ndfc_mtd->chip.options |= NAND_BUSWIDTH_16;
+
+ ndfc_mtd->mtd.priv = &ndfc_mtd->chip;
+ ndfc_mtd->mtd.owner = THIS_MODULE;
+
+ /* scan for known chips */
+ err = nand_scan(&ndfc_mtd->mtd, ndfc_mtd->chip_cnt);
+ if (err)
+ goto err_out;
+
+ /* get partitions */
+ err = parse_partitions(ndfc_mtd, dp);
+ if (err < 0)
+ goto err_out;
+
+ /* attach mtd device to ndfc */
+ ndfc_add_mtd(ndfc, ndfc_mtd);
+
+ if (err > 0) {
+ add_mtd_partitions(&ndfc_mtd->mtd,
+ OF_FLASH_PARTS(ndfc_mtd), err);
+ } else {
+ add_mtd_device(&ndfc_mtd->mtd);
+ }
+
+ return 0;
+err_out:
+ kfree(ndfc_mtd);
+ return err;
+}
+
+
+static int __devinit ndfc_map_banks(struct of_ndfc *ndfc,
+ struct of_device *dev)
+{
+ int i, err;
+ struct device_node *dp = dev->node, *pp;
+
+ if (!ndfc || !dev)
+ return -EINVAL;
+
+ /* Disable all banks */
+ for (i = 0; i < NDFC_MAX_BANKS; i++)
+ ndfc_raw_writel(ndfc, NDFC_BCFG0 + (i << 2), 0);
+
+ /* Scan device tree for nand devices attached and init them */
+ i = 0;
+ for (pp = of_get_next_child(dp, NULL); pp;
+ pp = of_get_next_child(dp, pp)) {
+ err = ndfc_init_mtd(ndfc, pp);
+ if (err) {
+ printk(KERN_ERR "%s: Failed to map\n",
+ pp->full_name);
+ continue;
+ }
+ i++;
+ }
+ return i;
+}
+
+
+static int __devinit of_ndfc_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ struct device_node *dp = dev->node;
+ struct resource res;
+ struct of_ndfc *ndfc;
+ resource_size_t rlen;
+ int err;
+
+ err = -ENXIO;
+ if (of_address_to_resource(dp, 0, &res)) {
+ dev_err(&dev->dev, "Can't get IO address from device tree\n");
+ goto err_out;
+ }
+
+ dev_dbg(&dev->dev, "of_nand device: %.8llx-%.8llx\n",
+ (unsigned long long)res.start, (unsigned long long)res.end);
+
+ ndfc = kzalloc(sizeof(struct of_ndfc), GFP_KERNEL);
+ if (!ndfc) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+
+ rlen = res.end - res.start + 1;
+ ndfc->res = request_mem_region(res.start, rlen, dev->dev.bus_id);
+ if (!ndfc->res) {
+ err = -EBUSY;
+ goto err_free_out;
+ }
+
+ ndfc->base = ioremap(res.start, rlen);
+ if (!ndfc->base) {
+ err = -ENXIO;
+ goto err_rel_out;
+ }
+
+ spin_lock_init(&ndfc->control.lock);
+ init_waitqueue_head(&ndfc->control.wq);
+ INIT_LIST_HEAD(&ndfc->list);
+
+ err = ndfc_map_banks(ndfc, dev);
+ if (err <= 0) {
+ printk(KERN_ERR "NDFC NAND: (%s) no banks set up\n",
+ dp->full_name);
+ err = -ENODEV;
+ goto err_unmap_out;
+ }
+
+ dev_set_drvdata(&dev->dev, ndfc);
+ printk(KERN_INFO "NDFC NAND Driver initialized. "
+ "Chip-Rev: 0x%08x\n", ndfc_raw_readl(ndfc, NDFC_REVID));
+
+ return 0;
+
+err_unmap_out:
+ iounmap(ndfc->base);
+err_rel_out:
+ release_resource(ndfc->res);
+ kfree(ndfc->res);
+err_free_out:
+ kfree(ndfc);
+err_out:
+ return err;
+}
+
+static struct of_device_id of_ndfc_match[] = {
+ {
+ .compatible = "ibm,ndfc",
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_ndfc_match);
+
+static struct of_platform_driver of_ndfc_driver = {
+ .name = "of-ndfc",
+ .match_table = of_ndfc_match,
+ .probe = of_ndfc_probe,
+ .remove = of_ndfc_remove,
+};
+
+static int __init of_ndfc_init(void)
+{
+ return of_register_platform_driver(&of_ndfc_driver);
+}
+
+static void __exit of_ndfc_exit(void)
+{
+ of_unregister_platform_driver(&of_ndfc_driver);
+}
+
+module_init(of_ndfc_init);
+module_exit(of_ndfc_exit);
+
+MODULE_LICENSE("GPL");
+
+
+MODULE_DESCRIPTION("Platform driver for NDFC");
diff -pruN linux-2.6.orig/include/linux/mtd/ndfc.h linux-2.6/include/linux/mtd/ndfc.h
--- linux-2.6.orig/include/linux/mtd/ndfc.h 2007-10-29 16:03:16.000000000 +0300
+++ linux-2.6/include/linux/mtd/ndfc.h 2007-10-29 18:59:11.000000000 +0300
@@ -52,6 +52,10 @@
#define NDFC_BxCFG_SZ_MASK 0x08000000 /* Bank Size */
#define NDFC_BxCFG_SZ_8BIT 0x00000000 /* 8bit */
#define NDFC_BxCFG_SZ_16BIT 0x08000000 /* 16bit */
+#define NDFC_BxCFG_RR(x) ((x) & 0x3 << 0)
+#define NDFC_BxCFG_RWH(x) ((x) & 0x3 << 4)
+#define NDFC_BxCFG_RWP(x) ((x) & 0x3 << 8)
+#define NDFC_BxCFG_CRW(x) ((x) & 0x3 << 12)
#define NDFC_MAX_BANKS 4
^ permalink raw reply
* [PATCH] [Powerpc] include udbg.h when using udbg_printf
From: Will Schmidt @ 2007-10-29 19:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
[Powerpc] include udbg.h when using udbg_printf
this fixes the error
error: implicit declaration of function ‘udbg_printf’
We have a few spots where we reference udbg_printf() without #including
udbg.h. These are within #ifdef DEBUG blocks, so unnoticed until we do
a #define DEBUG or #define DEBUG_LOW nearby.
Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
---
arch/powerpc/mm/hash_utils_64.c | 1 +
arch/powerpc/mm/slb.c | 1 +
arch/powerpc/platforms/cell/smp.c | 1 +
arch/powerpc/platforms/pseries/firmware.c | 1 +
4 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index c78dc91..94b8ca0 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -51,6 +51,7 @@
#include <asm/cputable.h>
#include <asm/sections.h>
#include <asm/spu.h>
+#include <asm/udbg.h>
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index bbd2c51..637afb2 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -25,6 +25,7 @@
#include <asm/smp.h>
#include <asm/firmware.h>
#include <linux/compiler.h>
+#include <asm/udbg.h>
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
diff --git a/arch/powerpc/platforms/cell/smp.c b/arch/powerpc/platforms/cell/smp.c
index 1c0acba..e443845 100644
--- a/arch/powerpc/platforms/cell/smp.c
+++ b/arch/powerpc/platforms/cell/smp.c
@@ -44,6 +44,7 @@
#include <asm/rtas.h>
#include "interrupt.h"
+#include <asm/udbg.h>
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
diff --git a/arch/powerpc/platforms/pseries/firmware.c b/arch/powerpc/platforms/pseries/firmware.c
index 8b18a1c..b765b7c 100644
--- a/arch/powerpc/platforms/pseries/firmware.c
+++ b/arch/powerpc/platforms/pseries/firmware.c
@@ -25,6 +25,7 @@
#include <asm/firmware.h>
#include <asm/prom.h>
+#include <asm/udbg.h>
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
^ permalink raw reply related
* [PATCH 2/3] PowerPC: 44x NanD Flash Controller (NDFC) bindings
From: Valentine Barshak @ 2007-10-29 20:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tglx, sr, linux-mtd
In-Reply-To: <20071029201738.GA2022@ru.mvista.com>
PowerPC 44x NanD Flash Controller (NDFC) bindings.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
Documentation/powerpc/booting-without-of.txt | 64 +++++++++++++++++++++++++++
1 files changed, 64 insertions(+)
--- linux-2.6.orig/Documentation/powerpc/booting-without-of.txt 2007-10-29 16:02:07.000000000 +0300
+++ linux-2.6/Documentation/powerpc/booting-without-of.txt 2007-10-29 21:34:14.000000000 +0300
@@ -52,6 +52,7 @@ Table of Contents
i) Freescale QUICC Engine module (QE)
j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
+ l) 44x NanD Flash Controller (NDFC)
VII - Specifying interrupt information for devices
1) interrupts property
@@ -2242,6 +2243,69 @@ platforms are moved over to use the flat
available.
For Axon: 0x0000012a
+ l) 44x NanD Flash Controller (NDFC)
+
+ Required properties:
+ - compatible : should be "ibm,ndfc".
+ - reg : should contain address and length of the NDFC registers.
+
+ ndfc node should contain at least one ndfc-mtd sub-node describing
+ chip properties and bank settings for the chip(s) attached to particular
+ ndfc bank(s).
+
+ Required ndfc-mtd properties:
+ - bank-map : at least one value (less than number of NDFC banks available)
+ identifying bank number the chip is attached to. If we have several
+ identical chips and want to spread a single mtd device across all of them,
+ we need to specify here the bank numbers the chips are attached to.
+ E.g. "bank-map = <0 3>;" means a single mtd device will be created
+ for 2 identical NAND chips attached to banks 0 and 3 of the NDFC.
+ Optional ndfc-mtd properties:
+ - chip-options : NAND chip options.
+ - chip-delay : NAND chip delay. Default is 50us.
+ - bank-settings : NDFC bank settings for the chip(s). This value is
+ written to the NDFC Bank Configuration Register.
+ If not specified, the default timings (RR=RWH=RWP=CRW=2) and
+ bank width from the "bank-width" property will be used for the chip.
+ - bank-width : NAND chip bus width. Should be 1 for 8-bit NAND or
+ 2 for 16-bit NAND. By default an 8-bit width is set.
+ - #address-cells, #size-cells : Must be present if the flash has
+ sub-nodes representing partitions (see below). In this case
+ both #address-cells and #size-cells must be equal to 1.
+
+ ndfc_mtd can have partition sub-nodes, which are described the same way
+ as for the CFI or JEDEC memory-mapped NOR flash.
+
+ Example (Sequoia 440EPx):
+ NDFC is relocatable within EBC and should have EBC as a parent node.
+ Here we have NDFC on EBC CS3 bank and one NAND chip attached to bank 3
+ of the NanD Flash Controller:
+
+ ndfc@0,0 {
+ compatible = "ibm,ndfc-440epx", "ibm,ndfc";
+ reg = <3 000000 2000>;
+ ndfc-mtd0 {
+ bank-settings = <80002222>;
+ bank-map = <3>;
+ chip-delay = <32>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "u-boot-nand";
+ reg = <0 0080000>;
+ };
+ partition@80000 {
+ label = "kernel-nand";
+ reg = <0080000 0180000>;
+ };
+ partition@200000 {
+ label = "filesystem";
+ reg = <0200000 1e00000>;
+ };
+ };
+ };
+
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
^ permalink raw reply
* [PATCH 3/3] PowerPC: NDFC entry for 440EPx Sequoia DTS
From: Valentine Barshak @ 2007-10-29 20:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tglx, sr, linux-mtd
In-Reply-To: <20071029201738.GA2022@ru.mvista.com>
NDFC DTS entry for PowerPC 440EPx Sequoia board.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/boot/dts/sequoia.dts | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+)
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts linux-2.6/arch/powerpc/boot/dts/sequoia.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts 2007-10-29 16:02:11.000000000 +0300
+++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-10-29 18:59:11.000000000 +0300
@@ -141,6 +141,29 @@
interrupts = <5 1>;
interrupt-parent = <&UIC1>;
+ ndfc@0,0 {
+ compatible = "ibm,ndfc-440epx", "ibm,ndfc";
+ reg = <3 000000 2000>;
+ ndfc-mtd0 {
+ bank-settings = <80002222>;
+ bank-map = <3>;
+ chip-delay = <32>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "u-boot-nand";
+ reg = <0 0080000>;
+ };
+ partition@80000 {
+ label = "kernel-nand";
+ reg = <0080000 0180000>;
+ };
+ partition@200000 {
+ label = "filesystem";
+ reg = <0200000 1e00000>;
+ };
+ };
+ };
nor_flash@0,0 {
compatible = "amd,s29gl256n", "cfi-flash";
bank-width = <2>;
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Scott Wood @ 2007-10-29 19:30 UTC (permalink / raw)
To: Matt Sealey; +Cc: Linuxppc-dev
In-Reply-To: <47262E36.4030503@genesi-usa.com>
Matt Sealey wrote:
> I don't see how this makes anything any better.
>
> Under Open Firmware, if device_type is "display", then it had better
> act as a display through the client interface, interpose it's framebuffer
> methods properly and suchlike.
>
> In FDT, what is the purpose of the binding but to report devices? It
> does not really define any interface whatsoever. Having it "conform
> to a standards-compliant binding" by reporting standard,display goes
> in the direction of ignoring the simple fact that most displays act
> and are programmed very differently
In that case, it probably make sense to simply not have a binding for
displays.
> I would say the same for USB, where standard,usb would be really
> glossing over the simple fact that *all usb controllers should by
> default be created equal*. OHCI does not act any different, and
> UHCI doesn't act any different, in the specification. If the chip
> does weird things, you do not go around revoking it's status as an
> OHCI controller, do you?
If its weird things are sufficiently non-OHCI, yes. :-)
Good luck fitting a CPM USB controller into some *HCI designation.
> As an addendum to Scott's other mail I came up with a good reason to
> give users readable names but standard device_types. Consider 802.11g,
> which may have a name of "wifi"
This is reasonable.
> but since it is a network adapter, have device_type "ethernet".
This is acceptable as existing practice, but "standard,ethernet" would
be just fine. And there may be additional properties defined for
wireless devices, and an additional "standard,wifi" binding could be
added. You can't have multiple device_types.
> It is ethernet after all, but users would like to know which it is
> compared with the onboard ethernet, given a list of devices on the OF
> console, without knowing the base addresses of registers.
My preferred solution to this particular problem is a label property,
that can go beyond ethernet/wifi and say things like "front panel
ethernet", "back panel ethernet A", "back panel ethernet B", "wireless",
etc., without taking away name's existing use, and without limiting the
label to the characters allowed in a node name.
-Scott
^ permalink raw reply
* [PATCH] MTD: small physmap_of partition parsing fixes
From: Valentine Barshak @ 2007-10-29 20:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-mtd
Use of_get_next_child for proper ref counting as suggested by Stephen Rothwell
and remove add_mtd_partitions from parse_partitions to avoid duplicate
mtd device registration for RedBoot partitions.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/mtd/maps/physmap_of.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff -pruN linux-2.6.orig/drivers/mtd/maps/physmap_of.c linux-2.6/drivers/mtd/maps/physmap_of.c
--- linux-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-10-29 16:02:37.000000000 +0300
+++ linux-2.6/drivers/mtd/maps/physmap_of.c 2007-10-29 22:41:08.000000000 +0300
@@ -94,14 +94,13 @@ static int __devinit parse_partitions(st
* line, these take precedence over device tree information */
nr_parts = parse_mtd_partitions(info->mtd, part_probe_types,
&info->parts, 0);
- if (nr_parts > 0) {
- add_mtd_partitions(info->mtd, info->parts, nr_parts);
- return 0;
- }
+ if (nr_parts > 0)
+ return nr_parts;
/* First count the subnodes */
nr_parts = 0;
- for (pp = dp->child; pp; pp = pp->sibling)
+ for (pp = of_get_next_child(dp, NULL); pp;
+ pp = of_get_next_child(dp, pp))
nr_parts++;
if (nr_parts == 0)
@@ -112,12 +111,14 @@ static int __devinit parse_partitions(st
if (!info->parts)
return -ENOMEM;
- for (pp = dp->child, i = 0; pp; pp = pp->sibling, i++) {
+ for (pp = of_get_next_child(dp, NULL), i = 0; pp;
+ pp = of_get_next_child(dp, pp), i++) {
const u32 *reg;
int len;
reg = of_get_property(pp, "reg", &len);
if (!reg || (len != 2*sizeof(u32))) {
+ of_node_put(pp);
dev_err(&dev->dev, "Invalid 'reg' on %s\n",
dp->full_name);
kfree(info->parts);
^ permalink raw reply
* RE: RFC: replace device_type with new "class" property?
From: Yoder Stuart-B08248 @ 2007-10-29 19:34 UTC (permalink / raw)
To: Matt Sealey, Dale Farnsworth; +Cc: Linuxppc-dev
In-Reply-To: <47262E36.4030503@genesi-usa.com>
Here's an example of what I'm trying to get at-- take=20
a node from a FSL device tree. The ideas I've heard
for expressing the class are like this--
#1 don't express any class at all:
ucc@2200 {
compatible =3D "fsl,ucc_geth";
model =3D "UCC";
device-id =3D <3>;
reg =3D <2200 200>;
interrupts =3D <22>;
interrupt-parent =3D < &qeic >;
mac-address =3D [ 00 00 00 00 00 00 ];
local-mac-address =3D [ 00 00 00 00 00 00 ];
rx-clock =3D <19>;
tx-clock =3D <1a>;
phy-handle =3D < &phy3 >;
pio-handle =3D < &pio3 >;
=20
> This is bad IMHO because the human reader has to
> infer the class of device. Can the human reader
> tell if it implements a standardized binding or
> not??
#2 use device_type
ucc@2200 {
device_type =3D "network";
compatible =3D "fsl,ucc_geth";
model =3D "UCC";
device-id =3D <3>;
reg =3D <2200 200>;
interrupts =3D <22>;
interrupt-parent =3D < &qeic >;
mac-address =3D [ 00 00 00 00 00 00 ];
local-mac-address =3D [ 00 00 00 00 00 00 ];
rx-clock =3D <19>;
tx-clock =3D <1a>;
phy-handle =3D < &phy3 >;
pio-handle =3D < &pio3 >;
};
> This is better...I can tell it implments the network
> binding. The problem is the past abuse and OF
> connotations.
#3 use a new "class" property
ucc@2200 {
class =3D "network";
compatible =3D "fsl,ucc_geth";
model =3D "UCC";
device-id =3D <3>;
reg =3D <2200 200>;
interrupts =3D <22>;
interrupt-parent =3D < &qeic >;
mac-address =3D [ 00 00 00 00 00 00 ];
local-mac-address =3D [ 00 00 00 00 00 00 ];
rx-clock =3D <19>;
tx-clock =3D <1a>;
phy-handle =3D < &phy3 >;
pio-handle =3D < &pio3 >;
};
> This is good...I can tell it implments the "network"
> binding. There is no association with the abused
> OF device_type.
#4 use "compatible"
ucc@2200 {
compatible =3D "fsl,ucc_geth","[official spec],network";
model =3D "UCC";
device-id =3D <3>;
reg =3D <2200 200>;
interrupts =3D <22>;
interrupt-parent =3D < &qeic >;
mac-address =3D [ 00 00 00 00 00 00 ];
local-mac-address =3D [ 00 00 00 00 00 00 ];
rx-clock =3D <19>;
tx-clock =3D <1a>;
phy-handle =3D < &phy3 >;
pio-handle =3D < &pio3 >;
};
> I don't like this...we are overloading "compatible" with
> stuff that is not specifying a programming interface. compatible
> is supposed to be specifying a programming interface which
> the device complies to.
Stuart
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Scott Wood @ 2007-10-29 19:44 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA30359FB6A@az33exm25.fsl.freescale.net>
Yoder Stuart-B08248 wrote:
> Here's an example of what I'm trying to get at-- take
> a node from a FSL device tree. The ideas I've heard
> for expressing the class are like this--
>
> #1 don't express any class at all:
>
> ucc@2200 {
> compatible = "fsl,ucc_geth";
> model = "UCC";
> device-id = <3>;
> reg = <2200 200>;
> interrupts = <22>;
> interrupt-parent = < &qeic >;
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> rx-clock = <19>;
> tx-clock = <1a>;
> phy-handle = < &phy3 >;
> pio-handle = < &pio3 >;
Of course, this should properly be something like
ethernet@2200 {
compatible = "fsl,mpc8360-qe-enet", "fsl,qe-enet";
local-mac-address = [ 00 00 00 00 00 00 ];
...
};
With no "mac-address", and a more useful "model" if any at all.
-Scott
^ permalink raw reply
* Re: [PATCH 0/5 v3] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver.
From: Phil Terry @ 2007-10-29 19:38 UTC (permalink / raw)
To: wei.zhang; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11854393721520-git-send-email-wei.zhang@freescale.com>
Can anyone tell me what the status of these are? What kernel release are
they targetted for? Currently I'm trying to work with 2.6.23 plus these
patches locally.
Cheers
Phil
On Thu, 2007-07-26 at 16:42 +0800, Zhang Wei wrote:
> These patches are the version 3 patches for RapidIO with dts update and some minor fixups.
>
> These patches are used for supporting RapidIO controllers of Freescale. I ported them from ppc architecture to powerpc architecture and added some new features, such as memory mapped driver.
>
> [PATCH 1/5] Add the explanation and sample of RapidIO DTS OF-node to the document of booting-without-of.txt file.
> [PATCH 2/5] Add RapidIO OF-node to MPC8641HPCN board dts file.
> [PATCH 3/5] Add the platform device support with RapidIO to MPC8641HPCN platform.
> [PATCH 4/5] Add RapidIO support to powerpc architecture.
> [PATCH 5/5] Add the memory management driver to RapidIO.
>
> Please see below descriptions of these patches:
> 1. Add the RapidIO driver of-device support.
> 2. Add the RapidIO driver support to MPC8641HPCN board.
> 3. Port the RapidIO from ppc to powerpc architecture.
> 4. Add Memory mapped RapidIO driver.
> 5. Add the support to multi master ports.
> 6. Add a simple bitmap RapidIO space allocator driver.
> 7. Change the RapidIO system size of menuconfig to automatically detection.
>
> Thanks!
>
> Best Regards,
> Zhang Wei
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* [PATCH] [powerpc] update xmon slb code
From: Will Schmidt @ 2007-10-29 19:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
[powerpc] update xmon slb code
adds a bit more detail to the xmon SLB output. When the valid bit is
set, This displays the ESID and VSID values, as well as decoding the
segment size. (1T or 256M). This supresses the output for any slb entries
that contain only zeros.
I debated a bit on whether to check for just (valid) versus checking for
(valid|esid|vsid). By inspection on power5, I do have SLB entries that
contain values but without the valid bit set, so opted to display any
non-zero values.
sample output from power6 (1T segment support):
00 c000000008000000 40004f7ca3000500 1T ESID=c00000 VSID=40004f7ca3
01 d000000008000000 4000eb71b0000400 1T ESID=d00000 VSID=4000eb71b0
24 cf00000008000000 400011b260000500 1T ESID=cf0000 VSID=400011b260
25 0000040008000000 4000a9e949000c80 1T ESID=4 VSID=4000a9e949
26 0000000018000000 00005e93bfd49c80 256M ESID=1 VSID=5e93bfd49
27 00000f0008000000 4000e262a4000c80 1T ESID=f VSID=4000e262a4
28 0000000008000000 00005dd45172ec80 256M ESID=0 VSID=5dd45172e
sample output from power5 (notice the non-valid but non-zero entries)
54 0000000048000000 0000cf33bb059c80 256M ESID=4 VSID=cf33bb059
55 0000000018000000 0000ccf56fe08c80 256M ESID=1 VSID=ccf56fe08
56 0000000010000000 0000dd82ce799c80
57 cf00000008000000 0000d59aca40f500 256M ESID=cf0000000 VSID=d59aca40f
58 c000000078000000 000045cb97751500 256M ESID=c00000007 VSID=45cb97751
59 0000040000000000 000061552db1bc80
Tested on power5 and power6.
Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
---
arch/powerpc/xmon/xmon.c | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 121b04d..97984f3 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2527,16 +2527,24 @@ static void xmon_print_symbol(unsigned long address, const char *mid,
static void dump_slb(void)
{
int i;
- unsigned long tmp;
+ unsigned long esid,vsid,valid;
printf("SLB contents of cpu %x\n", smp_processor_id());
for (i = 0; i < SLB_NUM_ENTRIES; i++) {
- asm volatile("slbmfee %0,%1" : "=r" (tmp) : "r" (i));
- printf("%02d %016lx ", i, tmp);
-
- asm volatile("slbmfev %0,%1" : "=r" (tmp) : "r" (i));
- printf("%016lx\n", tmp);
+ asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (i));
+ asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (i));
+ valid = (esid & SLB_ESID_V);
+ if (valid | esid | vsid) {
+ printf("%02d %016lx %016lx", i, esid, vsid);
+ if (valid) {
+ if (vsid & SLB_VSID_B_1T)
+ printf(" 1T ESID=%lx VSID=%lx \n", GET_ESID_1T(esid),vsid >>SLB_VSID_SHIFT_1T);
+ else
+ printf(" 256M ESID=%lx VSID=%lx \n", GET_ESID(esid),vsid >>SLB_VSID_SHIFT);
+ } else
+ printf("\n");
+ }
}
}
^ permalink raw reply related
* Re: boot/wrap assumes a biarch toolchain?
From: Jan Dittmer @ 2007-10-29 19:44 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Jan Dittmer, Anton Blanchard
In-Reply-To: <jelk9mdj6e.fsf@sykes.suse.de>
Andreas Schwab wrote:
> Jan Dittmer <jdittmer@ppp0.net> writes:
>
>> $ powerpc64-linux-gcc-4.0.4 -v
>> Using built-in specs.
>> Target: powerpc64-linux
>> Configured with: ../configure --prefix=/usr/cc217
>> --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux
>> --disable-shared --disable-werror --disable-nls --disable-threads
>> --disable-werror --disable-libmudflap --with-newlib --with-gnu-as
>> --with-gnu-ld --enable-languages=c
>> Thread model: single
>> gcc version 4.0.4
>>
>> g5_defconfig:
>>
>> $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux-
>> CROSS32_COMPILE=powerpc64-linux-
>
> Your compiler still needs -m32 to generate 32-bit code (or use
> --with-cpu=default32 to make that the default).
4.1.2 exhibits the same behavior. When did it start to work without
additional options? 4.2?
Jan
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: Pass PID argument to _tlbie (WAS: Apparent kernel bug with GDB on ppc405)
From: Josh Boyer @ 2007-10-29 20:15 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list, Matt, Mackall, Kumar Gala, linuxppc-embedded
In-Reply-To: <20071029070824.72854629@weaponx.rchland.ibm.com>
On Mon, 29 Oct 2007 07:08:24 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Sat, 27 Oct 2007 17:32:02 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Allright, so Matt, let me know if that fixes your problem with gdb, and
> > I'll clean the patch up a bit and submit it. I want to double check if
> > something similar may be needed for freescale booke.
> >
> > Basically, the problem is that things like get_user_pages() can cause
> > COW operations which in turn call _tlbie() to be called for translations
> > that aren't in the current address space.
> >
> > The current 40x and 44x implementation of _tlbie doesn't handle that
> > properly as it only invalidates entries in the current PID.
> >
> > This is an attempt at fixing it. Untested, I just checked it builds for
> > arch/powerpc and arch/ppc. I also haven't looked whether the freescale
> > BookE _tlbie needs similar treatement (it will get passed the pid in r4
> > with that patch, so if it needs to do something with it, it can). Kumar,
> > can you have a look ?
>
> This looks pretty good at first glance. I'll try to test it out today,
> but I'd still like to hear if it solves Matt's problem as I doubt I'll
> be able to duplicate it.
Did a boot test on my ebony board with this patch included. It seems
to be happy about things so far. If Matt gets around to trying this
out and it works, we should probably look at getting this into 2.6.24.
Oh, and I'd need a signed-off-by for it Ben :)
josh
^ permalink raw reply
* RE: RFC: replace device_type with new "class" property?
From: Yoder Stuart-B08248 @ 2007-10-29 20:20 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Linuxppc-dev
In-Reply-To: <47263800.8020401@freescale.com>
=20
> -----Original Message-----
> From: Wood Scott-B07421=20
> Sent: Monday, October 29, 2007 2:44 PM
> To: Yoder Stuart-B08248
> Cc: Matt Sealey; Dale Farnsworth; Linuxppc-dev@ozlabs.org
> Subject: Re: RFC: replace device_type with new "class" property?
>=20
> Yoder Stuart-B08248 wrote:
> > Here's an example of what I'm trying to get at-- take=20
> > a node from a FSL device tree. The ideas I've heard
> > for expressing the class are like this--
> >=20
> > #1 don't express any class at all:
> >=20
> > ucc@2200 {
> > compatible =3D "fsl,ucc_geth";
> > model =3D "UCC";
> > device-id =3D <3>;
> > reg =3D <2200 200>;
> > interrupts =3D <22>;
> > interrupt-parent =3D < &qeic >;
> > mac-address =3D [ 00 00 00 00 00 00 ];
> > local-mac-address =3D [ 00 00 00 00 00 00 ];
> > rx-clock =3D <19>;
> > tx-clock =3D <1a>;
> > phy-handle =3D < &phy3 >;
> > pio-handle =3D < &pio3 >;
>=20
> Of course, this should properly be something like
>=20
> ethernet@2200 {
> compatible =3D "fsl,mpc8360-qe-enet", "fsl,qe-enet";
> local-mac-address =3D [ 00 00 00 00 00 00 ];
> ...
> };
>=20
> With no "mac-address", and a more useful "model" if any at all.
That's fine, but as a human reader there is nothing
that would tell me this node implemented a defined
binding that specified required properties.
Stuart
^ permalink raw reply
* Re: [PATCH 0/5 v3] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver.
From: Kumar Gala @ 2007-10-29 20:30 UTC (permalink / raw)
To: pterry; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <1193686720.20377.2.camel@pterry-fc6.micromemory.com>
On Oct 29, 2007, at 2:38 PM, Phil Terry wrote:
> Can anyone tell me what the status of these are? What kernel
> release are
> they targetted for? Currently I'm trying to work with 2.6.23 plus
> these
> patches locally.
hopefully 2.6.25. I'd like to get the documentation updates in
2.6.24 if we have agreement on them.
- k
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: Pass PID argument to _tlbie (WAS: Apparent kernel bug with GDB on ppc405)
From: Benjamin Herrenschmidt @ 2007-10-29 20:35 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, Matt Mackall, Kumar Gala, linuxppc-embedded
In-Reply-To: <20071029151546.5af0e843@weaponx.rchland.ibm.com>
> Did a boot test on my ebony board with this patch included. It seems
> to be happy about things so far. If Matt gets around to trying this
> out and it works, we should probably look at getting this into 2.6.24.
>
> Oh, and I'd need a signed-off-by for it Ben :)
Sure, I'll send you a cleaned up version (the version I posted for test
breaks 64 bits builds :-)
But I'm also waiting for Matt to test first.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] [powerpc] update xmon slb code
From: Olof Johansson @ 2007-10-29 20:52 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071029195925.9773.94394.stgit@farscape.rchland.ibm.com>
On Mon, Oct 29, 2007 at 02:59:27PM -0500, Will Schmidt wrote:
>
> [powerpc] update xmon slb code
>
> adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the output for any slb entries
> that contain only zeros.
>
> I debated a bit on whether to check for just (valid) versus checking for
> (valid|esid|vsid). By inspection on power5, I do have SLB entries that
> contain values but without the valid bit set, so opted to display any
> non-zero values.
Yeah, newer versions of the architecture specify that invalid entries
must read as 0, while POWER5 doesn't. Printing them doesn't hurt.
> sample output from power6 (1T segment support):
>
> 00 c000000008000000 40004f7ca3000500 1T ESID=c00000 VSID=40004f7ca3
> 01 d000000008000000 4000eb71b0000400 1T ESID=d00000 VSID=4000eb71b0
> 24 cf00000008000000 400011b260000500 1T ESID=cf0000 VSID=400011b260
> 25 0000040008000000 4000a9e949000c80 1T ESID=4 VSID=4000a9e949
> 26 0000000018000000 00005e93bfd49c80 256M ESID=1 VSID=5e93bfd49
> 27 00000f0008000000 4000e262a4000c80 1T ESID=f VSID=4000e262a4
> 28 0000000008000000 00005dd45172ec80 256M ESID=0 VSID=5dd45172e
>
> sample output from power5 (notice the non-valid but non-zero entries)
>
> 54 0000000048000000 0000cf33bb059c80 256M ESID=4 VSID=cf33bb059
> 55 0000000018000000 0000ccf56fe08c80 256M ESID=1 VSID=ccf56fe08
> 56 0000000010000000 0000dd82ce799c80
> 57 cf00000008000000 0000d59aca40f500 256M ESID=cf0000000 VSID=d59aca40f
> 58 c000000078000000 000045cb97751500 256M ESID=c00000007 VSID=45cb97751
> 59 0000040000000000 000061552db1bc80
>
> Tested on power5 and power6.
Nice, I like it! I wonder if it would make sense to (space) pad the
ESID/VSID fields so they line up, it'd make output just a little tidier.
(If you end up changing that, please also break the long printf lines
in two.)
Beside that it looks good to me! :)
-Olof
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Olof Johansson @ 2007-10-29 21:22 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA30359F9BB@az33exm25.fsl.freescale.net>
On Mon, Oct 29, 2007 at 07:37:04AM -0700, Yoder Stuart-B08248 wrote:
>
> We've had some discussions internally here at Freescale among
> various PPC Linux developers about the device_type property
> and how 'classes' of devices should be represented in the
> device tree.
>
> Taking a long term view, the question I'd like to pose is
> how should classes of device should be identified in the
> flat device tree model? A device class, as I'm using it,
> refers basically to general categories of devices-- devices
> that share common properties. Examples in current device
> would be "cpu", "memory", "pci", "network", "serial".
>
> Today the device_type property serves this purpose to some
> degree. However, the original meaning of device_type in
> Open Firmware is related to the method interface of a node
> it has a recent history of abuse in the Linux kernel DTS
> files, with a plethora of types made up in an ad hoc way.
> In addition, an OS can match on "compatible" and in the
> absence of method interfaces really doesn't need
> device_type anyway.
>
> However, one good thing about device_type (if properly used)
> is that it could identify which device nodes follow an official
> binding, vs proprietary devices or one-off device node definitions.
> Without something like device_type the _human_ reader of a DTS
> file has to infer from the name or compatible what the device
> type is. So, device class identifiers like "memory", "cpu",
> "serial", "pci", "network" provide that clarity.
>
> So, what should the long term approach be? Here are a couple
> of options:
>
> 1. Keep device_type, with it's use specifically defined to
> mean that the node with that property implements an
> 'official' binding. In the flat device tree model a
> binding is just a defined set of required (and optional
> properties.
>
> 2. Get rid of device_type and create a _new_ property like
> "class". The only nodes permitted to have this property
> are those with 'official' bindings. These nodes would
> have a set of required (and optional) properties.
>
> The benefit of a new property is cutting all baggage
> associated with the old device_type property.
I don't see how switching the property name from "device_type" to
"class" is going to stop people from misunderstanding it's intended
use. There's nothing inherently more understandable in calling it
"class" -- it also invites people to make up their own class names
as they go along, just as what happened to "device_type".
I also don't understand the people wanting to use "compatible"
for _everything_. It's just mashing together two separate pieces of
information into one property, and I seriously don't see how that helps
anything or anyone. It's absolutely useless for a driver to be able to
bind to a compatible field of "standard,network" or whatever it might be,
since there's no way that "standard," will imply that the register layout
and programming model is somehow the same as all other standard-labelled
devices.
So yes, there is a problem with the device trees and how people build
them, and it requires education on how to properly craft one. I don't
think changing the layout to either be flatter (only using compatible),
or changing names of a property (device_type->class) will help anything
at all.
I actually prefer keeping device_type myself, since it means existing
OF-based device trees will already have some of the labels.
-Olof
^ permalink raw reply
* Re: boot/wrap assumes a biarch toolchain?
From: Andreas Schwab @ 2007-10-29 21:15 UTC (permalink / raw)
To: Jan Dittmer; +Cc: linuxppc-dev, Jan Dittmer, Anton Blanchard
In-Reply-To: <47263830.2010009@l4x.org>
Jan Dittmer <jdi@l4x.org> writes:
> Andreas Schwab wrote:
>> Jan Dittmer <jdittmer@ppp0.net> writes:
>>
>>> $ powerpc64-linux-gcc-4.0.4 -v
>>> Using built-in specs.
>>> Target: powerpc64-linux
>>> Configured with: ../configure --prefix=/usr/cc217
>>> --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux
>>> --disable-shared --disable-werror --disable-nls --disable-threads
>>> --disable-werror --disable-libmudflap --with-newlib --with-gnu-as
>>> --with-gnu-ld --enable-languages=c
>>> Thread model: single
>>> gcc version 4.0.4
>>>
>>> g5_defconfig:
>>>
>>> $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux-
>>> CROSS32_COMPILE=powerpc64-linux-
>>
>> Your compiler still needs -m32 to generate 32-bit code (or use
>> --with-cpu=default32 to make that the default).
>
> 4.1.2 exhibits the same behavior.
What do you mean with "the same behavior"?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
From: Luis R. Rodriguez @ 2007-10-29 21:27 UTC (permalink / raw)
To: netdev, linuxppc-dev; +Cc: Tzachi Perelstein, Lennert Buytenhek, Jeff Garzik
This commit made an incorrect assumption:
--
Author: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Fri Oct 19 04:10:10 2007 +0200
mv643xx_eth: Move ethernet register definitions into private header
Move the mv643xx's ethernet-related register definitions from
include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since
they aren't of any use outside the ethernet driver.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Tzachi Perelstein <tzachi@marvell.com>
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
--
arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there.
mcgrof@pogo:~/devel/wireless-2.6$ git-describe
v2.6.24-rc1-138-g0119130
This patch fixes this by internalizing 3 defines onto pegasos which are
simply no longer available elsewhere. Without this your compile will fail
whenever you enable 'Common Hardware Reference Platform (CHRP) based machines',
(CONFIG_PPC_CHRP) as the Makefile for chrp adds it always:
obj-y += setup.o time.o pegasos_eth.o pci.o
If these defines are platform specific then they should later just be added
back to include/linux/mv643xx.h.
Compile error:
CC arch/powerpc/platforms/chrp/pegasos_eth.o
arch/powerpc/platforms/chrp/pegasos_eth.c: In function 'Enable_SRAM':
arch/powerpc/platforms/chrp/pegasos_eth.c:150: error: 'MV643XX_ETH_BAR_4'
undeclared (first use in this function)
arch/powerpc/platforms/chrp/pegasos_eth.c:150: error: (Each undeclared
identifier is reported only once
arch/powerpc/platforms/chrp/pegasos_eth.c:150: error: for each function it
appears in.)
arch/powerpc/platforms/chrp/pegasos_eth.c:152: error:
'MV643XX_ETH_SIZE_REG_4' undeclared (first use in this function)
arch/powerpc/platforms/chrp/pegasos_eth.c:154: error:
'MV643XX_ETH_BASE_ADDR_ENABLE_REG' undeclared (first use in this function)
make[2]: *** [arch/powerpc/platforms/chrp/pegasos_eth.o] Error 1
make[1]: *** [arch/powerpc/platforms/chrp] Error 2
make: *** [arch/powerpc/platforms] Error 2
Signed-off-by: Luis R. Rodriguez <mcgrof@gmail.com>
---
arch/powerpc/platforms/chrp/pegasos_eth.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/powerpc/platforms/chrp/pegasos_eth.c
index 5bcc58d..1fc9e8c 100644
--- a/arch/powerpc/platforms/chrp/pegasos_eth.c
+++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
@@ -24,6 +24,9 @@
#define PEGASOS2_SRAM_BASE_ETH0 (PEGASOS2_SRAM_BASE)
#define PEGASOS2_SRAM_BASE_ETH1 (PEGASOS2_SRAM_BASE_ETH0 + (PEGASOS2_SRAM_SIZE / 2) )
+#define PEGASOS2_ETH_BAR_4 0x2220
+#define PEGASOS2_ETH_SIZE_REG_4 0x2224
+#define PEGASOS2_ETH_BASE_ADDR_ENABLE_REG 0x2290
#define PEGASOS2_SRAM_RXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
#define PEGASOS2_SRAM_TXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
@@ -147,13 +150,13 @@ static int Enable_SRAM(void)
ALong = 0x02;
ALong |= PEGASOS2_SRAM_BASE & 0xffff0000;
- MV_WRITE(MV643XX_ETH_BAR_4, ALong);
+ MV_WRITE(PEGASOS2_ETH_BAR_4, ALong);
- MV_WRITE(MV643XX_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) & 0xffff0000);
+ MV_WRITE(PEGASOS2_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) & 0xffff0000);
- MV_READ(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
+ MV_READ(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong);
ALong &= ~(1 << 4);
- MV_WRITE(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
+ MV_WRITE(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong);
#ifdef BE_VERBOSE
printk("Pegasos II/Marvell MV64361: register unmapped\n");
^ permalink raw reply related
* Re: [PATCH/RFC] powerpc: Pass PID argument to _tlbie (WAS: Apparent kernel bug with GDB on ppc405)
From: Matt Mackall @ 2007-10-29 21:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, gdb, Kumar Gala, linuxppc-embedded
In-Reply-To: <1193690106.9928.32.camel@pasglop>
[adding back gdb list]
On Tue, Oct 30, 2007 at 07:35:06AM +1100, Benjamin Herrenschmidt wrote:
>
> > Did a boot test on my ebony board with this patch included. It seems
> > to be happy about things so far. If Matt gets around to trying this
> > out and it works, we should probably look at getting this into 2.6.24.
> >
> > Oh, and I'd need a signed-off-by for it Ben :)
>
> Sure, I'll send you a cleaned up version (the version I posted for test
> breaks 64 bits builds :-)
>
> But I'm also waiting for Matt to test first.
Ok, just backported the 405 bits of this to my client's sad sad MV
2.6.10 kernel and it appears to work fine. Only tricky bit was
context.id -> context. So:
Tested-by: Matt Mackall <mpm@selenic.com>
And here's my backported patch, just for reference:
Index: k/arch/ppc/kernel/misc.S
===================================================================
--- k.orig/arch/ppc/kernel/misc.S 2007-10-29 15:33:03.000000000 -0500
+++ k/arch/ppc/kernel/misc.S 2007-10-29 15:34:29.000000000 -0500
@@ -496,7 +496,13 @@ _GLOBAL(_tlbia)
*/
_GLOBAL(_tlbie)
#if defined(CONFIG_40x)
+ mfmsr r5
+ mfspr r6,SPRN_PID
+ wrteei 0
+ mtspr SPRN_PID,r4
tlbsx. r3, 0, r3
+ mtspr SPRN_PID,r6
+ wrtee r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64, which means bit 25 is clear.
Index: k/arch/ppc/mm/fault.c
===================================================================
--- k.orig/arch/ppc/mm/fault.c 2007-10-29 15:30:04.000000000 -0500
+++ k/arch/ppc/mm/fault.c 2007-10-29 16:11:10.000000000 -0500
@@ -234,7 +234,7 @@ good_area:
set_bit(PG_arch_1, &page->flags);
}
pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
+ _tlbie(address, mm->context);
pte_unmap(ptep);
up_read(&mm->mmap_sem);
ltt_ev_trap_exit();
Index: k/arch/ppc/mm/mmu_decl.h
===================================================================
--- k.orig/arch/ppc/mm/mmu_decl.h 2007-10-29 15:34:48.000000000 -0500
+++ k/arch/ppc/mm/mmu_decl.h 2007-10-29 16:11:25.000000000 -0500
@@ -54,7 +54,7 @@ extern unsigned int num_tlbcam_entries;
#define mmu_mapin_ram() (0UL)
#elif defined(CONFIG_4xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
Index: k/include/asm-ppc/tlbflush.h
===================================================================
--- k.orig/include/asm-ppc/tlbflush.h 2007-10-29 15:31:29.000000000 -0500
+++ k/include/asm-ppc/tlbflush.h 2007-10-29 16:11:32.000000000 -0500
@@ -13,7 +13,7 @@
#include <linux/config.h>
#include <linux/mm.h>
-extern void _tlbie(unsigned long address);
+extern void _tlbie(unsigned long address, unsigned int pid);
extern void _tlbia(void);
#if defined(CONFIG_4xx)
@@ -28,10 +28,10 @@ static inline void flush_tlb_mm(struct m
{ __tlbia(); }
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
- { _tlbie(vmaddr); }
+ { _tlbie(vmaddr, vma->vm_mm->context); }
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
- { _tlbie(vmaddr); }
+ { _tlbie(vmaddr, vma->vm_mm->context); }
static inline void flush_tlb_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
{ __tlbia(); }
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: boot/wrap assumes a biarch toolchain?
From: Jan Dittmer @ 2007-10-29 21:49 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Jan Dittmer, Anton Blanchard
In-Reply-To: <jebqahei70.fsf@sykes.suse.de>
Andreas Schwab wrote:
> Jan Dittmer <jdi@l4x.org> writes:
>
>> Andreas Schwab wrote:
>>> Jan Dittmer <jdittmer@ppp0.net> writes:
>>>
>>>> $ powerpc64-linux-gcc-4.0.4 -v
>>>> Using built-in specs.
>>>> Target: powerpc64-linux
>>>> Configured with: ../configure --prefix=/usr/cc217
>>>> --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux
>>>> --disable-shared --disable-werror --disable-nls --disable-threads
>>>> --disable-werror --disable-libmudflap --with-newlib --with-gnu-as
>>>> --with-gnu-ld --enable-languages=c
>>>> Thread model: single
>>>> gcc version 4.0.4
>>>>
>>>> g5_defconfig:
>>>>
>>>> $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux-
>>>> CROSS32_COMPILE=powerpc64-linux-
>>> Your compiler still needs -m32 to generate 32-bit code (or use
>>> --with-cpu=default32 to make that the default).
>> 4.1.2 exhibits the same behavior.
>
> What do you mean with "the same behavior"?
Same error, you write above that a newer compiler version should
not need -m32 or --with-cpu=default32 any more? But I still get:
CC arch/powerpc/kernel/signal.o
LDS arch/powerpc/kernel/vdso32/vdso32.lds
VDSO32A arch/powerpc/kernel/vdso32/sigtramp.o
VDSO32A arch/powerpc/kernel/vdso32/gettimeofday.o
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:
Assembler messages:
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33:
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33:
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37:
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37:
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95:
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95:
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103:
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103:
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130:
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130:
Error: junk at end of line: `@local'
make[3]: *** [arch/powerpc/kernel/vdso32/gettimeofday.o] Error 1
make[2]: *** [arch/powerpc/kernel/vdso32] Error 2
make[1]: *** [arch/powerpc/kernel] Error 2
make: *** [sub-make] Error 2
Jan
>
> Andreas.
>
^ permalink raw reply
* Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
From: Dale Farnsworth @ 2007-10-29 22:39 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Tzachi Perelstein, Jeff Garzik, netdev, linuxppc-dev,
Lennert Buytenhek
In-Reply-To: <20071029212729.GA4074@pogo>
On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
> This commit made an incorrect assumption:
> --
> Author: Lennert Buytenhek <buytenh@wantstofly.org>
> Date: Fri Oct 19 04:10:10 2007 +0200
>
> mv643xx_eth: Move ethernet register definitions into private header
>
> Move the mv643xx's ethernet-related register definitions from
> include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since
> they aren't of any use outside the ethernet driver.
>
> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
> Acked-by: Tzachi Perelstein <tzachi@marvell.com>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> --
>
> arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there.
>
> mcgrof@pogo:~/devel/wireless-2.6$ git-describe
>
> v2.6.24-rc1-138-g0119130
>
> This patch fixes this by internalizing 3 defines onto pegasos which are
> simply no longer available elsewhere. Without this your compile will fail
That compile failure was fixed in commit
30e69bf4cce16d4c2dcfd629a60fcd8e1aba9fee by Al Viro.
However, as I examine that commit, I see that it defines offsets from
the eth block in the chip, rather than the full chip registeri block
as the Pegasos 2 code expects. So, I think it fixes the compile
failure, but leaves the Pegasos 2 broken.
Luis, do you have Pegasos 2 hardware? Can you (or anyone) verify that
the following patch is needed for the Pegasos 2?
Thanks,
-Dale
---------------------------------
mv643xx_eth: Fix MV643XX_ETH offsets used by Pegasos 2
In the mv643xx_eth driver, we now use offsets from the ethernet
register block within the chip, but the pegasos 2 platform still
needs offsets from the full chip's register base address.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
include/linux/mv643xx_eth.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h
index 8df230a..30e11aa 100644
--- a/include/linux/mv643xx_eth.h
+++ b/include/linux/mv643xx_eth.h
@@ -8,9 +8,9 @@
#define MV643XX_ETH_NAME "mv643xx_eth"
#define MV643XX_ETH_SHARED_REGS 0x2000
#define MV643XX_ETH_SHARED_REGS_SIZE 0x2000
-#define MV643XX_ETH_BAR_4 0x220
-#define MV643XX_ETH_SIZE_REG_4 0x224
-#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x0290
+#define MV643XX_ETH_BAR_4 0x2220
+#define MV643XX_ETH_SIZE_REG_4 0x2224
+#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x2290
struct mv643xx_eth_platform_data {
int port_number;
^ permalink raw reply related
* [PATCH] powerpc: Fix 4xx flush_tlb_page()
From: Benjamin Herrenschmidt @ 2007-10-29 22:46 UTC (permalink / raw)
To: linuxppc-dev
On 4xx CPUs, the current implementation of flush_tlb_page() uses
a low level _tlbie() assembly function that only works for the
current PID. Thus, invalidations caused by, for example, a COW
fault triggered by get_user_pages() from a different context will
not work properly, causing among other things, gdb breakpoints
to fail.
This patch adds a "pid" argument to _tlbie() on 4xx processors,
and uses it to flush entries in the right context. FSL BookE
also gets the argument but it seems they don't need it (their
tlbivax form ignores the PID when invalidating according to the
document I have).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/misc_32.S | 23 ++++++++++++++++-------
arch/powerpc/mm/fault.c | 2 +-
arch/powerpc/mm/mmu_decl.h | 4 ++--
arch/ppc/kernel/misc.S | 22 +++++++++++++++-------
arch/ppc/mm/fault.c | 2 +-
arch/ppc/mm/mmu_decl.h | 4 ++--
arch/ppc/platforms/4xx/ebony.c | 2 +-
arch/ppc/platforms/4xx/ocotea.c | 2 +-
arch/ppc/platforms/4xx/taishan.c | 2 +-
include/asm-powerpc/tlbflush.h | 12 ++++++------
10 files changed, 46 insertions(+), 29 deletions(-)
Index: linux-work/arch/powerpc/mm/fault.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/fault.c 2007-10-25 13:15:47.000000000 +1000
+++ linux-work/arch/powerpc/mm/fault.c 2007-10-29 10:13:11.000000000 +1100
@@ -309,7 +309,7 @@ good_area:
set_bit(PG_arch_1, &page->flags);
}
pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
+ _tlbie(address, mm->context.id);
pte_unmap_unlock(ptep, ptl);
up_read(&mm->mmap_sem);
return 0;
Index: linux-work/include/asm-powerpc/tlbflush.h
===================================================================
--- linux-work.orig/include/asm-powerpc/tlbflush.h 2007-10-25 13:15:52.000000000 +1000
+++ linux-work/include/asm-powerpc/tlbflush.h 2007-10-29 10:13:57.000000000 +1100
@@ -1,5 +1,6 @@
#ifndef _ASM_POWERPC_TLBFLUSH_H
#define _ASM_POWERPC_TLBFLUSH_H
+
/*
* TLB flushing:
*
@@ -16,9 +17,6 @@
*/
#ifdef __KERNEL__
-struct mm_struct;
-struct vm_area_struct;
-
#if defined(CONFIG_4xx) || defined(CONFIG_8xx) || defined(CONFIG_FSL_BOOKE)
/*
* TLB flushing for software loaded TLB chips
@@ -28,7 +26,9 @@ struct vm_area_struct;
* specific tlbie's
*/
-extern void _tlbie(unsigned long address);
+#include <linux/mm.h>
+
+extern void _tlbie(unsigned long address, unsigned int pid);
#if defined(CONFIG_40x) || defined(CONFIG_8xx)
#define _tlbia() asm volatile ("tlbia; sync" : : : "memory")
@@ -44,13 +44,13 @@ static inline void flush_tlb_mm(struct m
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr);
+ _tlbie(vmaddr, vma->vm_mm->context.id);
}
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr);
+ _tlbie(vmaddr, vma->vm_mm->context.id);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
Index: linux-work/arch/powerpc/kernel/misc_32.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/misc_32.S 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/powerpc/kernel/misc_32.S 2007-10-29 10:13:11.000000000 +1100
@@ -288,7 +288,16 @@ _GLOBAL(_tlbia)
*/
_GLOBAL(_tlbie)
#if defined(CONFIG_40x)
+ /* We run the search with interrupts disabled because we have to change
+ * the PID and I don't want to preempt when that happens.
+ */
+ mfmsr r5
+ mfspr r6,SPRN_PID
+ wrteei 0
+ mtspr SPRN_PID,r4
tlbsx. r3, 0, r3
+ mtspr SPRN_PID,r6
+ wrtee r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64, which means bit 25 is clear.
@@ -297,23 +306,23 @@ _GLOBAL(_tlbie)
tlbwe r3, r3, TLB_TAG
isync
10:
+
#elif defined(CONFIG_44x)
- mfspr r4,SPRN_MMUCR
- mfspr r5,SPRN_PID /* Get PID */
- rlwimi r4,r5,0,24,31 /* Set TID */
+ mfspr r5,SPRN_MMUCR
+ rlwimi r5,r4,0,24,31 /* Set TID */
/* We have to run the search with interrupts disabled, even critical
* and debug interrupts (in fact the only critical exceptions we have
* are debug and machine check). Otherwise an interrupt which causes
* a TLB miss can clobber the MMUCR between the mtspr and the tlbsx. */
- mfmsr r5
+ mfmsr r4
lis r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@ha
addi r6,r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l
- andc r6,r5,r6
+ andc r6,r4,r6
mtmsr r6
- mtspr SPRN_MMUCR,r4
+ mtspr SPRN_MMUCR,r5
tlbsx. r3, 0, r3
- mtmsr r5
+ mtmsr r4
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64,
Index: linux-work/arch/powerpc/mm/mmu_decl.h
===================================================================
--- linux-work.orig/arch/powerpc/mm/mmu_decl.h 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/powerpc/mm/mmu_decl.h 2007-10-29 10:13:11.000000000 +1100
@@ -61,12 +61,12 @@ extern unsigned long total_lowmem;
#define mmu_mapin_ram() (0UL)
#elif defined(CONFIG_4xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
#elif defined(CONFIG_FSL_BOOKE)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
extern void adjust_total_lowmem(void);
Index: linux-work/arch/ppc/kernel/misc.S
===================================================================
--- linux-work.orig/arch/ppc/kernel/misc.S 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/ppc/kernel/misc.S 2007-10-29 10:13:11.000000000 +1100
@@ -224,7 +224,16 @@ _GLOBAL(_tlbia)
*/
_GLOBAL(_tlbie)
#if defined(CONFIG_40x)
+ /* We run the search with interrupts disabled because we have to change
+ * the PID and I don't want to preempt when that happens.
+ */
+ mfmsr r5
+ mfspr r6,SPRN_PID
+ wrteei 0
+ mtspr SPRN_PID,r4
tlbsx. r3, 0, r3
+ mtspr SPRN_PID,r6
+ wrtee r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64, which means bit 25 is clear.
@@ -234,22 +243,21 @@ _GLOBAL(_tlbie)
isync
10:
#elif defined(CONFIG_44x)
- mfspr r4,SPRN_MMUCR
- mfspr r5,SPRN_PID /* Get PID */
- rlwimi r4,r5,0,24,31 /* Set TID */
+ mfspr r5,SPRN_MMUCR
+ rlwimi r5,r4,0,24,31 /* Set TID */
/* We have to run the search with interrupts disabled, even critical
* and debug interrupts (in fact the only critical exceptions we have
* are debug and machine check). Otherwise an interrupt which causes
* a TLB miss can clobber the MMUCR between the mtspr and the tlbsx. */
- mfmsr r5
+ mfmsr r4
lis r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@ha
addi r6,r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l
- andc r6,r5,r6
+ andc r6,r4,r6
mtmsr r6
- mtspr SPRN_MMUCR,r4
+ mtspr SPRN_MMUCR,r5
tlbsx. r3, 0, r3
- mtmsr r5
+ mtmsr r4
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64,
Index: linux-work/arch/ppc/mm/fault.c
===================================================================
--- linux-work.orig/arch/ppc/mm/fault.c 2007-10-25 13:15:47.000000000 +1000
+++ linux-work/arch/ppc/mm/fault.c 2007-10-29 10:13:11.000000000 +1100
@@ -227,7 +227,7 @@ good_area:
set_bit(PG_arch_1, &page->flags);
}
pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
+ _tlbie(address, mm->context.id);
pte_unmap_unlock(ptep, ptl);
up_read(&mm->mmap_sem);
return 0;
Index: linux-work/arch/ppc/mm/mmu_decl.h
===================================================================
--- linux-work.orig/arch/ppc/mm/mmu_decl.h 2007-07-27 13:44:42.000000000 +1000
+++ linux-work/arch/ppc/mm/mmu_decl.h 2007-10-29 10:13:11.000000000 +1100
@@ -54,12 +54,12 @@ extern unsigned int num_tlbcam_entries;
#define mmu_mapin_ram() (0UL)
#elif defined(CONFIG_4xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
#elif defined(CONFIG_FSL_BOOKE)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
extern void adjust_total_lowmem(void);
Index: linux-work/arch/ppc/platforms/4xx/ebony.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/4xx/ebony.c 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/ppc/platforms/4xx/ebony.c 2007-10-29 10:13:11.000000000 +1100
@@ -236,7 +236,7 @@ ebony_early_serial_map(void)
gen550_init(0, &port);
/* Purge TLB entry added in head_44x.S for early serial access */
- _tlbie(UART0_IO_BASE);
+ _tlbie(UART0_IO_BASE, 0);
#endif
port.membase = ioremap64(PPC440GP_UART1_ADDR, 8);
Index: linux-work/arch/ppc/platforms/4xx/ocotea.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/4xx/ocotea.c 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/ppc/platforms/4xx/ocotea.c 2007-10-29 10:13:11.000000000 +1100
@@ -259,7 +259,7 @@ ocotea_early_serial_map(void)
gen550_init(0, &port);
/* Purge TLB entry added in head_44x.S for early serial access */
- _tlbie(UART0_IO_BASE);
+ _tlbie(UART0_IO_BASE, 0);
#endif
port.membase = ioremap64(PPC440GX_UART1_ADDR, 8);
Index: linux-work/arch/ppc/platforms/4xx/taishan.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/4xx/taishan.c 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/ppc/platforms/4xx/taishan.c 2007-10-29 10:13:11.000000000 +1100
@@ -316,7 +316,7 @@ taishan_early_serial_map(void)
gen550_init(0, &port);
/* Purge TLB entry added in head_44x.S for early serial access */
- _tlbie(UART0_IO_BASE);
+ _tlbie(UART0_IO_BASE, 0);
#endif
port.membase = ioremap64(PPC440GX_UART1_ADDR, 8);
^ permalink raw reply
* Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
From: Lennert Buytenhek @ 2007-10-29 22:47 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: netdev, Tzachi Perelstein, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071029212729.GA4074@pogo>
On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
> This commit made an incorrect assumption:
> --
> Author: Lennert Buytenhek <buytenh@wantstofly.org>
> Date: Fri Oct 19 04:10:10 2007 +0200
>
> mv643xx_eth: Move ethernet register definitions into private header
>
> Move the mv643xx's ethernet-related register definitions from
> include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since
> they aren't of any use outside the ethernet driver.
>
> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
> Acked-by: Tzachi Perelstein <tzachi@marvell.com>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> --
>
> arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there.
>
> mcgrof@pogo:~/devel/wireless-2.6$ git-describe
>
> v2.6.24-rc1-138-g0119130
>
> This patch fixes this by internalizing 3 defines onto pegasos which are
> simply no longer available elsewhere. Without this your compile will fail
> whenever you enable 'Common Hardware Reference Platform (CHRP) based machines',
>
> [...]
>
> diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/powerpc/platforms/chrp/pegasos_eth.c
> index 5bcc58d..1fc9e8c 100644
> --- a/arch/powerpc/platforms/chrp/pegasos_eth.c
> +++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
> @@ -24,6 +24,9 @@
> #define PEGASOS2_SRAM_BASE_ETH0 (PEGASOS2_SRAM_BASE)
> #define PEGASOS2_SRAM_BASE_ETH1 (PEGASOS2_SRAM_BASE_ETH0 + (PEGASOS2_SRAM_SIZE / 2) )
>
> +#define PEGASOS2_ETH_BAR_4 0x2220
> +#define PEGASOS2_ETH_SIZE_REG_4 0x2224
> +#define PEGASOS2_ETH_BASE_ADDR_ENABLE_REG 0x2290
>
> #define PEGASOS2_SRAM_RXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
> #define PEGASOS2_SRAM_TXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
> @@ -147,13 +150,13 @@ static int Enable_SRAM(void)
>
> ALong = 0x02;
> ALong |= PEGASOS2_SRAM_BASE & 0xffff0000;
> - MV_WRITE(MV643XX_ETH_BAR_4, ALong);
> + MV_WRITE(PEGASOS2_ETH_BAR_4, ALong);
>
> - MV_WRITE(MV643XX_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) & 0xffff0000);
> + MV_WRITE(PEGASOS2_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) & 0xffff0000);
>
> - MV_READ(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
> + MV_READ(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong);
> ALong &= ~(1 << 4);
> - MV_WRITE(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
> + MV_WRITE(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong);
>
> #ifdef BE_VERBOSE
> printk("Pegasos II/Marvell MV64361: register unmapped\n");
Al Viro sent a patch for this breakage a couple of days ago:
http://marc.info/?l=linux-kernel&m=119351541706811&w=2
(FWIW, I think that code outside of mv643xx_eth.c should not be poking
into the mv643xx's registers directly. Ideally, this info should just
be passed by pegasos_eth into mv643xx_eth via platform data, and then
mv643xx_eth can write the relevant hardware registers.)
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Dale Farnsworth @ 2007-10-29 23:03 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA30359FB6A@az33exm25.fsl.freescale.net>
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote:
> #4 use "compatible"
>
> ucc@2200 {
> compatible = "fsl,ucc_geth","[official spec],network";
> model = "UCC";
> device-id = <3>;
> reg = <2200 200>;
> interrupts = <22>;
> interrupt-parent = < &qeic >;
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> rx-clock = <19>;
> tx-clock = <1a>;
> phy-handle = < &phy3 >;
> pio-handle = < &pio3 >;
> };
>
> > I don't like this...we are overloading "compatible" with
> > stuff that is not specifying a programming interface. compatible
> > is supposed to be specifying a programming interface which
> > the device complies to.
If your proposed class property doesn't specify a programming interface,
then I agree that we shouldn't put that info in compatible. My point
was that compatible is the one and only property that a driver should
look at to find a node with a suitable programming interface.
But, that begs the question: How will the code use your class property?
Another post implied that it's for human-readable purposes. If that's
all, I'd leave it out, or use a comment instead.
-Dale
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox