* [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
* Re: RFC: replace device_type with new "class" property?
From: Scott Wood @ 2007-10-29 19:21 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <47262CA9.3070500@genesi-usa.com>
Matt Sealey wrote:
> Scott Wood wrote:
>> On Mon, Oct 29, 2007 at 03:20:56PM +0000, Matt Sealey wrote:
>>> I think device_type, compatible and model properties fulfil this
>>> already, they simply aren't being used correctly.
>>
>> device_type has a few drawbacks, though:
>>
>> 1. You can only specify one type, whereas with a new property we
>> could define it as a list (similar to compatible).
>
> This is the whole point; device_type and compatible are companion
> properties. You specify the exact thing in device_type and give it a
> list of compatible device_types in compatible.
That sounds more like a description of "model", or the original use of
"name", than device_type.
>> 2. We want to avoid any confusion with OF bindings and abused
>> device_type entries that have been allowed to become existing
>> practice.
>
> Creating whole new device type bindings that are not OF standards,
> which puts OF vendors at a sort of impass; do they comply to the Open
> Firmware standard or use the Linux Standard?
We try to stay compatible with OF when practical; however, we have no
choice if an OF device_type implies a method interface that we cannot
provide.
>>> For readability, the name of the device needn't match
>>> device_type; for instance on the 5121E it may be that the 'diu'
>>> unit be called diu, but be of device_type 'display'
>>
>> I don't think that's more readable than setting the name to
>> display. Something containing "diu" will be in the compatible list.
>>
>
> It at least makes the device tree far more human readable.
Unless you're familiar with the hardware, "diu" is likely to be a
meaningless acronym. "display" is obvious, and much more human-friendly.
> While name is derived from device_type on creation of a device (after
> all a display is a display), giving it a human readable name is
> sometimes a boon.
name generally comes from the generic names document, not device_type.
> Remember that Open Firmware is not just a text file you compile with
> U-Boot - the console you get on boot needs to be useful to users too.
> In that sense, 8 USB controllers with names usb@f10001000,
> usb@f10002000 going upwards to infinity is not the greatest thing in
> the world.
And the alternative is?
>>> Selecting the "model" would be no different to, for example,
>>> having a list of PCI IDs that will work with a driver.
>>
>> It's what we currently do with compatible. Why break it into two
>> properties?
>
> Because encoding human-readable descriptions of devices in the
> compatible property is ridiculously long-winded.
Putting something human readable in model is fine. It's not a reason to
force drivers to care about it by failing to include a highly specific
entry in the compatible list.
> Currently it's being terribly misused, in my opinion (USB especially,
> there is no need to tell that it is "compatible" with mpc5200b-usb,
> USB is a well-defined standard with 3 possible host controllers,
> encoding the specific SoC into it is going way overboard)
Well, there are various non-standard registers also present on many
embedded USB controllers.
>> No, you should use compatible for that.
>>
>> No, that goes in name/compatible according to the OF PCI binding.
>
> This is absolutely contrary to your own request for comments; you
> want to implement a new class property, but.. you can use device_type
> and compatible for it, as is evident everywhere and in two already
> existing bus bindings.
It was Stuart's RFC, not mine. :-)
What I originally proposed was deprecating device_type, and using name
and compatible. Stuart wanted something to indicate formal adherence to
a standard binding, so I suggested "class" if such a thing is really needed.
You seem to be confusing name and device_type, BTW.
>>> Perhaps it is a solution though; mark each device with a class
>>> property, for instance on the 5200B give it a unique chip ID
>>> (fsl5200 or soc5200?)
>>
>> No. That's precisely the sort of device_type abuse we want to get
>> away from with class.
>
> It is not an abuse to give a device_type by some very easily
> matchable device type.
That's not a device type, it's a device.
> For devices which do not have a standard binding you run into a
> problem; who arbitrates what class goes where?
The issue that brought all this up was new bindings for device classes
that OF doesn't have bindings for.
> Reusing vendor codes from PCI and USB,
OF already specifies OUI numbers for this, why be different?
We use things like "ibm" and "fsl" for common, unambiguous vendors for
readability sake.
> class codes from PCI and USB,
What do we need the class codes for?
> and implementing a few 'non-standard others' is far more efficient as
> there is plenty of code in the Linux tree for parsing and collecting
> this data.
I highly doubt there's any code in Linux that wants a PCI or USB class
ID for something that isn't a PCI or USB device.
> It is not so far a leap to go from parsing "pci" or "usb"
> device_types
name/compatible, not device_type. Please actually read the PCI binding.
And you shouldn't parse them, that's what the vendor-id and device-id
properties are for. The encoded form is for matching against a
similarly encoded string.
> "soc5121,0c0320" matches a device exactly where "usb" particularly
> does not.
Why are you comparing it to "usb" and not "fsl,mpc5121-usb"?
> Why not;
>
> chickenlittle { device_type = "usb" model = "soc1057,5121,0c0320"
> compatible = "usb-ehci", "soc1057,8349,*" }
Is chickenlittle really a useful description of a USB bus on your
hardware? :-)
And I thought you wanted human readable descriptions in model?
What's wrong with:
usb {
compatible = "fsl,mpc8349-usb", "usb-ehci";
reg = <whatever>;
};
?
^ permalink raw reply
* [PATCH 0/3] Add device-tree aware NDFC driver
From: Valentine Barshak @ 2007-10-29 20:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tglx, sr, linux-mtd
This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
The code is based on the original NDFC driver by Thomas Gleixner, but
since it's been changed much and has initialization/clean-up completely
reworked it's been put into a separate ndfc_of.c file. This version
supports both separate mtd devices on each chip attached to NDFC banks and
single mtd device spread across identical chips (not using mtdconcat) as well.
The choice is selected with device tree settings. This has been tested
on PowerPC 440EPx Sequoia board.
Any comments are greatly appreciated.
Thanks,
Valentine.
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Matt Sealey @ 2007-10-29 19:02 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Linuxppc-dev
In-Reply-To: <20071029172724.11354.qmail@farnsworth.org>
Dale Farnsworth wrote:
> Scott wrote:
>> Personally, I'm fine with just using name and compatible, but others such as
>> Stuart have expressed a desire for something to formally indicate compliance
>> with a standard binding. I don't think we should expand the use of
>> device_type in any case.
>
> I agree that the existing compatible property is sufficient to do
> what Stuart wants. All that is required is to define some standard
> bindings and give them well-known names for the compatible property.
> If needed, we could define a prefix that indicates that a compatible
> entry refers to a standards-compliant binding. For example,
> "standard,network", or "standard,display". I don't see the benefit
> of creating a new property similar to device_type.
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 (with the glorious exception of
potentially giving it a "compatible" of "vga" - on PCI this is
handled very easily by the PCI class code! Which was exactly my
point..).
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?
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" but since it is a network adapter,
have device_type "ethernet". 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.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Matt Sealey @ 2007-10-29 18:55 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <20071029161140.GA4358@loki.buserror.net>
Scott Wood wrote:
> On Mon, Oct 29, 2007 at 03:20:56PM +0000, Matt Sealey wrote:
>> I think device_type, compatible and model properties fulfil
>> this already, they simply aren't being used correctly.
>
> device_type has a few drawbacks, though:
>
> 1. You can only specify one type, whereas with a new property we could
> define it as a list (similar to compatible).
This is the whole point; device_type and compatible are companion
properties. You specify the exact thing in device_type and give
it a list of compatible device_types in compatible.
> 2. We want to avoid any confusion with OF bindings and abused device_type
> entries that have been allowed to become existing practice.
Creating whole new device type bindings that are not OF standards,
which puts OF vendors at a sort of impass; do they comply to the
Open Firmware standard or use the Linux Standard?
Flat device trees are already somewhat of a strange beast, it is
probably best not to make them much stranger.
> 3. It's the only standard property (AFAIK) with an underscore in it. :-)
Petty :D
>> For readability, the name of the device needn't match device_type;
>> for instance on the 5121E it may be that the 'diu' unit be
>> called diu, but be of device_type 'display'
>
> I don't think that's more readable than setting the name to display.
> Something containing "diu" will be in the compatible list.
It at least makes the device tree far more human readable.
"Name" and "Device Type" are not required to be the same thing. A
name is just a human readable marker, device_type is what drivers
need to match on.
While name is derived from device_type on creation of a device (after
all a display is a display), giving it a human readable name is
sometimes a boon.
Remember that Open Firmware is not just a text file you compile
with U-Boot - the console you get on boot needs to be useful to
users too. In that sense, 8 USB controllers with names usb@f10001000,
usb@f10002000 going upwards to infinity is not the greatest thing
in the world.
>> Selecting the "model" would be no different to, for example,
>> having a list of PCI IDs that will work with a driver.
>
> It's what we currently do with compatible. Why break it into two
> properties?
Because encoding human-readable descriptions of devices in the
compatible property is ridiculously long-winded.
Currently it's being terribly misused, in my opinion (USB especially,
there is no need to tell that it is "compatible" with mpc5200b-usb,
USB is a well-defined standard with 3 possible host controllers,
encoding the specific SoC into it is going way overboard)
> No, you should use compatible for that.
>
> No, that goes in name/compatible according to the OF PCI binding.
This is absolutely contrary to your own request for comments; you want
to implement a new class property, but.. you can use device_type
and compatible for it, as is evident everywhere and in two already
existing bus bindings.
If you need more information in the device tree for each device,
I simply recommend we take a hint from the PCI and USB bindings
and add properties of the same names and descriptions (why create
new standards when old ones work fine).
>> Perhaps it is a solution though; mark each device with a
>> class property, for instance on the 5200B give it a unique
>> chip ID (fsl5200 or soc5200?)
>
> No. That's precisely the sort of device_type abuse we want to get away from
> with class.
It is not an abuse to give a device_type by some very easily matchable
device type.
> Personally, I'm fine with just using name and compatible, but others such as
> Stuart have expressed a desire for something to formally indicate compliance
> with a standard binding. I don't think we should expand the use of
> device_type in any case.
You can formally indicate compliance with a standard binding by using
the standard bindings.. be they the USB or PCI standard, be your device
not on USB or PCI, they already exist, and already do what Stuart asks.
For devices which do not have a standard binding you run into a problem;
who arbitrates what class goes where?
Reusing vendor codes from PCI and USB, class codes from PCI and USB,
and implementing a few 'non-standard others' is far more efficient
as there is plenty of code in the Linux tree for parsing and collecting
this data. It is not so far a leap to go from parsing "pci" or "usb"
device_types to collecting "fsl" or "soc" data and a selection of appended
codes.
Therefore, if there is not a standard binding that gives it a neat name
(i2c would be a good example), I suggest following the route of PCI and
USB, and encoding that specific device as a set of matchable codes,
rather than a list of strings.
"soc5121,0c0320" matches a device exactly where "usb" particularly
does not. As with the specification for PCI where such a device may
not have a particular device_type name (not a good example with USB)
simply prefix with the bus type, then vendor code, device code,
class code etc. gives you an identical match.
Why not;
chickenlittle {
device_type = "usb"
model = "soc1057,5121,0c0320"
compatible = "usb-ehci", "soc1057,8349,*"
}
bluesky {
device_type = "i2c"
model = "i2c1057,5121,030000"
compatible = "whatever"
}
ata {
device_type = "ide"
model = "soc1057,5121,01801f"
compatible = "soc1057,5200,01801f"
}
Maybe that is an incredibly bad idea, now I look at it.
If not, simply whacking in the PCI class-code, vendor-id, device-id
and suchlike properties is both easy to add to current firmware
implementations and easy to differentiate a device (far beyond a
simple "class name"). 99% of names, and device_types already exist
and have well-known bindings. i2c being our example of where no
example binding exists, it is easy to report it's existance and
it's programming interface via these values.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* [PATCH] [Powerpc V2] fix switch_slb handling of 1T ESID values
From: Will Schmidt @ 2007-10-29 18:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
[Powerpc V2] fix switch_slb handling of 1T ESID values
Now that we have 1TB segment size support, we need to be using the
GET_ESID_1T macro when comparing ESID values for pc,stack, and
unmapped_base within switch_slb(). A new helper function called
esids_match() contains the logic for deciding when to call GET_ESID
and GET_ESID_1T.
This also happens to fix a duplicate-slb-entry inspired machine-check
exception I was seeing when trying to run java on a power6 partition.
Tested on power6 and power5.
Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
---
arch/powerpc/mm/slb.c | 33 ++++++++++++++++++++++++++++++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index bbd2c51..152f4cd 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -148,6 +148,34 @@ void slb_vmalloc_update(void)
slb_flush_and_rebolt();
}
+/* Helper function to compare esids. There are four cases to handle.
+ * 1. The system is not 1T segment size capable. Use the GET_ESID compare.
+ * 2. The system is 1T capable, both addresses are < 1T, use the GET_ESID compare.
+ * 3. The system is 1T capable, only one of the two addresses is > 1T. This is not a match.
+ * 4. The system is 1T capable, both addresses are > 1T, use the GET_ESID_1T macro to compare.
+ */
+static inline int esids_match(unsigned long addr1, unsigned long addr2)
+{
+ int esid_1t_count;
+
+ /* System is not 1T segment size capable. */
+ if (!cpu_has_feature(CPU_FTR_1T_SEGMENT))
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ esid_1t_count = (((addr1>>SID_SHIFT_1T)!=0) + ((addr2>>SID_SHIFT_1T)!=0));
+
+ /* both addresses are < 1T */
+ if (esid_1t_count == 0)
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ /* One address < 1T, the other > 1T. Not a match */
+ if (esid_1t_count == 1)
+ return 0;
+
+ /* Both addresses are > 1T. */
+ return (GET_ESID_1T(addr1) == GET_ESID_1T(addr2));
+}
+
/* Flush all user entries from the segment table of the current processor. */
void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
{
@@ -193,15 +221,14 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
return;
slb_allocate(pc);
- if (GET_ESID(pc) == GET_ESID(stack))
+ if (esids_match(pc,stack))
return;
if (is_kernel_addr(stack))
return;
slb_allocate(stack);
- if ((GET_ESID(pc) == GET_ESID(unmapped_base))
- || (GET_ESID(stack) == GET_ESID(unmapped_base)))
+ if (esids_match(pc,unmapped_base) || esids_match(stack,unmapped_base))
return;
if (is_kernel_addr(unmapped_base))
^ permalink raw reply related
* Re: RFC: replace device_type with new "class" property?
From: Dale Farnsworth @ 2007-10-29 17:27 UTC (permalink / raw)
To: scottwood, Linuxppc-dev
In-Reply-To: <20071029161140.GA4358@loki.buserror.net>
Scott wrote:
> Personally, I'm fine with just using name and compatible, but others such as
> Stuart have expressed a desire for something to formally indicate compliance
> with a standard binding. I don't think we should expand the use of
> device_type in any case.
I agree that the existing compatible property is sufficient to do
what Stuart wants. All that is required is to define some standard
bindings and give them well-known names for the compatible property.
If needed, we could define a prefix that indicates that a compatible
entry refers to a standards-compliant binding. For example,
"standard,network", or "standard,display". I don't see the benefit
of creating a new property similar to device_type.
-Dale
^ permalink raw reply
* Re: [POWERPC] Fix off-by-one error in setting decrementer on Book E
From: Sergei Shtylyov @ 2007-10-29 16:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18213.19469.827909.663373@cargo.ozlabs.ibm.com>
Hello.
Paul Mackerras wrote:
> The decrementer in Book E and 4xx processors interrupts on the
> transition from 1 to 0, rather than on the 0 to -1 transition as on
> 64-bit server and 32-bit "classic" (6xx/7xx/7xxx) processors.
> This fixes the problem by making set_dec subtract 1 from the count for
> server and classic processors. Since set_dec already had a bunch of
> ifdefs to handle different processor types, there is no net increase
> in ugliness. :)
> This also removes a redundant call to set the decrementer to
> 0x7fffffff - it was already set to that earlier in timer_interrupt.
> Signed-off-by: Paul Mackerras <paulus@samba.org>
Heh, I have alike patch but refrained from posting being busy with other
stuff and nt having any PPC target at hand... so, I'm late as usual
> ---
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 9eb3284..5e253d6 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -586,7 +586,7 @@ void timer_interrupt(struct pt_regs * regs)
> /* not time for this event yet */
> now = per_cpu(decrementer_next_tb, cpu) - now;
> if (now <= DECREMENTER_MAX)
> - set_dec((unsigned int)now - 1);
> + set_dec((int)now);
> return;
> }
> old_regs = set_irq_regs(regs);
> @@ -601,10 +601,8 @@ void timer_interrupt(struct pt_regs * regs)
>
> if (evt->event_handler)
> evt->event_handler(evt);
> - else
> - evt->set_next_event(DECREMENTER_MAX, evt);
>
> #ifdef CONFIG_PPC_ISERIES
> if (firmware_has_feature(FW_FEATURE_ISERIES) && hvlpevent_is_pending())
> @@ -826,9 +824,6 @@ static int decrementer_set_next_event(unsigned long evt,
> struct clock_event_device *dev)
> {
> __get_cpu_var(decrementer_next_tb) = get_tb_or_rtc() + evt;
> - /* The decrementer interrupts on the 0 -> -1 transition */
> - if (evt)
> - --evt;
> set_dec(evt);
> return 0;
> }
> diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h
> index f058955..eed64bd 100644
> --- a/include/asm-powerpc/time.h
> +++ b/include/asm-powerpc/time.h
> @@ -183,6 +183,7 @@ static inline void set_dec(int val)
> #elif defined(CONFIG_8xx_CPU6)
> set_dec_cpu6(val);
> #else
> + --val; /* classic decrementer interrupts when dec goes negative */
I got an impression that set_dec_cpu6() needs the decremented val as well.
Plus for iSeries compiler will complain for iSeries about cur_dec being
declared after val-- statement, C++ style. How about such variant (and the
same for <asm-ppc/time.h>)?
Index: powerpc/include/asm-powerpc/time.h
===================================================================
--- powerpc.orig/include/asm-powerpc/time.h
+++ powerpc/include/asm-powerpc/time.h
@@ -178,16 +178,24 @@ static inline unsigned int get_dec(void)
static inline void set_dec(int val)
{
+ /*
+ * The "classic" decrementer interrupts at 0 to -1 transition, while
+ * 40x and book E decrementers interrupt at 1 to 0 transition.
+ */
#if defined(CONFIG_40x)
mtspr(SPRN_PIT, val);
-#elif defined(CONFIG_8xx_CPU6)
+#else
+#if !defined(CONFIG_BOOKE)
+ val = val ? val - 1 : 0;
+#endif
+#if defined(CONFIG_8xx_CPU6)
set_dec_cpu6(val);
-#ifdef CONFIG_PPC_ISERIES
- int cur_dec;
-
+#if defined(CONFIG_PPC_ISERIES)
if (firmware_has_feature(FW_FEATURE_ISERIES) &&
- get_lppaca()->shared_proc) {
+ get_lppaca()->shared_proc) {
+ int cur_dec;
+
get_lppaca()->virtual_decr = val;
cur_dec = get_dec();
if (cur_dec > val)
@@ -195,7 +203,8 @@ static inline void set_dec(int val)
} else
#endif
mtspr(SPRN_DEC, val);
-#endif /* not 40x or 8xx_CPU6 */
+#endif /* not 8xx_CPU6 */
+#endif /* not 40x */
}
static inline unsigned long tb_ticks_since(unsigned long tstamp)
WBR, Sergei
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Scott Wood @ 2007-10-29 16:11 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <4725FA58.4030505@genesi-usa.com>
On Mon, Oct 29, 2007 at 03:20:56PM +0000, Matt Sealey wrote:
> I think device_type, compatible and model properties fulfil
> this already, they simply aren't being used correctly.
device_type has a few drawbacks, though:
1. You can only specify one type, whereas with a new property we could
define it as a list (similar to compatible). It's possible for one node to
comply with multiple class bindings, such as when there's a binding for
clients of the type of bus it's on as well as the type of device it is, or
when there are multiple levels of detail (such as complying with both
simple-bus and some specific bus binding).
2. We want to avoid any confusion with OF bindings and abused device_type
entries that have been allowed to become existing practice.
3. It's the only standard property (AFAIK) with an underscore in it. :-)
> Remember that, while you may want to make FDTs easier to
> design, OpenFirmware and the requirement on device interfaces
> through the client interface still exist and are still
> implemented (from time to time).
Sure -- and we don't want to risk the code thinking it can call into OF
based on what we put in a flat device tree, right?
> For readability, the name of the device needn't match device_type;
> for instance on the 5121E it may be that the 'diu' unit be
> called diu, but be of device_type 'display'
I don't think that's more readable than setting the name to display.
Something containing "diu" will be in the compatible list.
> Further differentiation should be done through the 'model'
> property in my opinion. This is optional in the OpenFirmware
> spec, but that does not mean it should be important. It is
> currently defined as something to determine the exact model
> of a chip in order to enable quirks, bugfixes and suchlike,
> but most implementations switch on something else entirely
> (like SVR or a heuristic behaviour).
>
> Selecting the "model" would be no different to, for example,
> having a list of PCI IDs that will work with a driver.
It's what we currently do with compatible. Why break it into two
properties?
The PCI ID thing can be quite a headache, BTW, when you get a new PCI device
that won't work with the existing driver, for no reason other than that it
hasn't been updated with the new ID.
> There was a little discussion at bplan once that it would be
> easier to implement a kind of vendor/device id system much
> like PCI, USB etc. implements in hardware in order to match
> hardware. I suppose you could use a "class" property to
> implement this -
No, you should use compatible for that.
> but for instance in the case of USB or PCI, this is already encoded in the
> device_type for anything the firmware cannot work out (pci1106,6062 or
> so).
No, that goes in name/compatible according to the OF PCI binding.
> Perhaps it is a solution though; mark each device with a
> class property, for instance on the 5200B give it a unique
> chip ID (fsl5200 or soc5200?)
No. That's precisely the sort of device_type abuse we want to get away from
with class.
Personally, I'm fine with just using name and compatible, but others such as
Stuart have expressed a desire for something to formally indicate compliance
with a standard binding. I don't think we should expand the use of
device_type in any case.
-Scott
^ permalink raw reply
* Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
From: Grant Likely @ 2007-10-29 15:40 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev, Martin Krause, David Gibson
In-Reply-To: <4725EB9E.1030507@semihalf.com>
On 10/29/07, Marian Balakowicz <m8@semihalf.com> wrote:
> David Gibson wrote:
> > On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote:
> >> Grant Likely wrote:
> >>> On 10/25/07, Martin Krause <Martin.Krause@tqs.de> wrote:
> > [snip]
> >>>> On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc"
> >>>> partition could not be used. "big-fs", because the memory is too small
> >>>> (which is OK) and "misc", because it overlaps 1 MiB over the physikal
> >>>> flash border. So only the first 9 MiB of the flash could be used in Linux.
> >>>> The remaining 7 MiB couldn't be accessed.
> >>> Perhaps it would be better to drop the flash layout from the in-kernel
> >>> dts files entirely since flash layout can be a fluid thing.
> >> Well, but that would not be really user friendly, I'd rather stick
> >> with some default config.
> >
> > Strictly speaking the device-tree is not the right place for flash
> > partitioning information. We put it there because it's preferable to
> > having hardcoded per-board flash layouts in the code itself.
> >
> > It only really works well, though, when there are strong conventions
> > (shared with the firmware) about how to partition the flash.
> >
> > Where it's really up to the user to determine how they want to lay out
> > their flash, putting things in the device tree isn't a really good
> > idea.
>
> In principle, you are right, we should not be putting a user dependent
> configuration into .dts files. But on the other hand, bindings have
> been defined for flash-like devices and their partition layouts and
> physmap_of device driver is expecting to get this information from the
> blob. So, it is the place for it. But if we are not to put partition
> layouts into the default kernel .dts files then we should
> provide/maintain some examples an that may be a even bigger mess.
>
> > Incidentally, it's not required that *all* the flash address space be
> > in partitions, so it is possible only give partitions for those flash
> > chunks which the firmware needs to know about.
>
> That might be nicer solution but different variants of TQM5200 boards
> do not share the same subset of partitions (default u-boot partitions
> at least), so it will not help much.
It's probably more appropriate to have the flash partition layout in
the u-boot environment and have u-boot populate the partition
information in the device tree.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: boot/wrap assumes a biarch toolchain?
From: Andreas Schwab @ 2007-10-29 15:39 UTC (permalink / raw)
To: Jan Dittmer; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <4725F34C.6090904@ppp0.net>
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).
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
* Re: [PATCH v4.3] FEC - fast ethernet controller for mpc52xx
From: Grant Likely @ 2007-10-29 15:37 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, Domen Puncer, netdev
In-Reply-To: <4725AF08.6030309@garzik.org>
On 10/29/07, Jeff Garzik <jeff@garzik.org> wrote:
> Domen Puncer wrote:
> > drivers/net/Kconfig | 24
> > drivers/net/Makefile | 4
> > drivers/net/fec_mpc52xx.c | 1112 ++++++++++++++++++++++++++++++++++++++++++
> > drivers/net/fec_mpc52xx.h | 313 +++++++++++
> > drivers/net/fec_mpc52xx_phy.c | 198 +++++++
> > 5 files changed, 1651 insertions(+)
>
> applied to #upstream-fixes
>
> it's not strictly a fix, but I did not want to hold this back until
> 2.6.25 either
Fantastic! Thanks Jeff.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Matt Sealey @ 2007-10-29 15:20 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA30359F9BB@az33exm25.fsl.freescale.net>
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.
>
> The initial list of official classes would be small--
> "cpu","memory", "cache", "pci", "serial", "network",
> "open-pic"(?). As other types get codified in actual use
> and have official bindings specified (perhaps through
> power.org) new types would be supported--e.g. "i2c",
> "jdec-flash".
>
> Thoughts?
I think device_type, compatible and model properties fulfil
this already, they simply aren't being used correctly.
Remember that, while you may want to make FDTs easier to
design, OpenFirmware and the requirement on device interfaces
through the client interface still exist and are still
implemented (from time to time).
What I would recommend is that the device_type encapsulate
the class of the device as it is currently. This means for
a display, you set device_type to "display".
OF platform devices for displays can then get a list of
all the "displays" available on a system, or "i2c" controllers
available on a system.
For readability, the name of the device needn't match device_type;
for instance on the 5121E it may be that the 'diu' unit be
called diu, but be of device_type 'display' - further information
can be added through the 'compatible' property of devices that
also support the same register model.
Further differentiation should be done through the 'model'
property in my opinion. This is optional in the OpenFirmware
spec, but that does not mean it should be important. It is
currently defined as something to determine the exact model
of a chip in order to enable quirks, bugfixes and suchlike,
but most implementations switch on something else entirely
(like SVR or a heuristic behaviour).
Selecting the "model" would be no different to, for example,
having a list of PCI IDs that will work with a driver.
Basically, I envision that instead device trees should be
a little more verbose, and that OF device probing should be
improved so that drivers can hook in on many levels of
matching.
There was a little discussion at bplan once that it would be
easier to implement a kind of vendor/device id system much
like PCI, USB etc. implements in hardware in order to match
hardware. I suppose you could use a "class" property to
implement this - but for instance in the case of USB or
PCI, this is already encoded in the device_type for anything
the firmware cannot work out (pci1106,6062 or so).
Perhaps it is a solution though; mark each device with a
class property, for instance on the 5200B give it a unique
chip ID (fsl5200 or soc5200?) and each unit a device id and take a big
hint from PCI class codes and programming interfaces here -
USB might be fsl5200,0c0310 (0c, 03 and 10 are all the PCI
class, subclass and progif for USB OHCI).
Additionally you can add more specific information such as
the type of USB controller, for instance in the case of EHCI,
perhaps also differentiate between EHCI with a companion controller,
EHCI with a transaction translator and no companion controller, etc.
with a further code - fsl520B,0c0320.01
References to peek at:
http://www.openbios.org/data/docs/bus.usb.pdf
http://www.openbios.org/data/docs/bus.pci.pdf
Especially take a peek at the PCI docs, page 10 where
"Table 1: Generic Names based upon Class Code" gives a
bunch of really nice name/device_types.
Note that none of this adds any further properties to
the specification for identification - you can do it
all using device_type and compatible.
So, why not start up a registry of vendor, device and
"class-code" numbers for SoC devices for when PCI
numbering cannot adequately fill the gap? In this case,
Freescale, IBM, AMCC and PASemi already have registered
vendor codes, class-codes for 99% of interfaces can
be derived from the PCI specifications?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: boot/wrap assumes a biarch toolchain?
From: Jan Dittmer @ 2007-10-29 14:50 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <jesl3udm0e.fsf@sykes.suse.de>
Andreas Schwab wrote:
> Anton Blanchard <anton@samba.org> writes:
>
>> One way to make this go away would be to build binutils as biarch:
>>
>> # configure --target=powerpc-linux --enable-targets=powerpc64-linux ...
>
> If you configure your toolchain for powerpc64-linux you get a biarch
> toolchain by default.
Hmm:
$ powerpc64-linux-ld -V
GNU ld (Linux/GNU Binutils) 2.17.50.0.17.20070615
Supported emulations:
elf64ppc
elf32ppclinux
elf32ppc
elf32ppcsim
$ 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-
...
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
^ permalink raw reply
* Re: boot/wrap assumes a biarch toolchain?
From: Anton Blanchard @ 2007-10-29 14:57 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, jdittmer
In-Reply-To: <jesl3udm0e.fsf@sykes.suse.de>
Hi,
> If you configure your toolchain for powerpc64-linux you get a biarch
> toolchain by default.
I was wondering about people using pre biarch gcc toolchains. But I take
your point - I'm guessing binutils has been biarch for a long time.
Since we are only calling binutils functions in boot/wrap, maybe we can
just do:
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 18e3271..8961afd 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -121,13 +121,9 @@ wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \
#############
# Bits for building various flavours of zImage
-ifneq ($(CROSS32_COMPILE),)
-CROSSWRAP := -C "$(CROSS32_COMPILE)"
-else
ifneq ($(CROSS_COMPILE),)
CROSSWRAP := -C "$(CROSS_COMPILE)"
endif
-endif
# args (to if_changed): 1 = (this rule), 2 = platform, 3 = dts 4=dtb 5=initrd
quiet_cmd_wrap = WRAP $@
^ permalink raw reply related
* Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
From: Marian Balakowicz @ 2007-10-29 14:18 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Martin Krause
In-Reply-To: <20071026013343.GD457@localhost.localdomain>
David Gibson wrote:
> On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote:
>> Grant Likely wrote:
>>> On 10/25/07, Martin Krause <Martin.Krause@tqs.de> wrote:
> [snip]
>>>> On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc"
>>>> partition could not be used. "big-fs", because the memory is too small
>>>> (which is OK) and "misc", because it overlaps 1 MiB over the physikal
>>>> flash border. So only the first 9 MiB of the flash could be used in Linux.
>>>> The remaining 7 MiB couldn't be accessed.
>>> Perhaps it would be better to drop the flash layout from the in-kernel
>>> dts files entirely since flash layout can be a fluid thing.
>> Well, but that would not be really user friendly, I'd rather stick
>> with some default config.
>
> Strictly speaking the device-tree is not the right place for flash
> partitioning information. We put it there because it's preferable to
> having hardcoded per-board flash layouts in the code itself.
>
> It only really works well, though, when there are strong conventions
> (shared with the firmware) about how to partition the flash.
>
> Where it's really up to the user to determine how they want to lay out
> their flash, putting things in the device tree isn't a really good
> idea.
In principle, you are right, we should not be putting a user dependent
configuration into .dts files. But on the other hand, bindings have
been defined for flash-like devices and their partition layouts and
physmap_of device driver is expecting to get this information from the
blob. So, it is the place for it. But if we are not to put partition
layouts into the default kernel .dts files then we should
provide/maintain some examples an that may be a even bigger mess.
> Incidentally, it's not required that *all* the flash address space be
> in partitions, so it is possible only give partitions for those flash
> chunks which the firmware needs to know about.
That might be nicer solution but different variants of TQM5200 boards
do not share the same subset of partitions (default u-boot partitions
at least), so it will not help much.
Cheers,
m.
^ permalink raw reply
* Re: boot/wrap assumes a biarch toolchain?
From: Andreas Schwab @ 2007-10-29 14:38 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, jdittmer
In-Reply-To: <20071029140719.GA17120@kryten>
Anton Blanchard <anton@samba.org> writes:
> One way to make this go away would be to build binutils as biarch:
>
> # configure --target=powerpc-linux --enable-targets=powerpc64-linux ...
If you configure your toolchain for powerpc64-linux you get a biarch
toolchain by default.
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
* RFC: replace device_type with new "class" property?
From: Yoder Stuart-B08248 @ 2007-10-29 14:37 UTC (permalink / raw)
To: linuxppc-dev
We've had some discussions internally here at Freescale among=20
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.
One other point-- the intent of a device class is not
necessarily to specify a sufficient set of properties
to implement drivers. The "network" class would have
a base set of required properties (e.g. mac-address,etc),
but most likely would need additional properties
to implement a driver for a specific device. The value
in the class is when a developer needs to represent
a new device that fits into an existing class he has a base
set of properties to start with that has had some good
thinking put into defining it. A device class would
facilitate and encourage consistent use of properties
names, which would be a good thing.
The initial list of official classes would be small--
"cpu","memory", "cache", "pci", "serial", "network",
"open-pic"(?). As other types get codified in actual use
and have official bindings specified (perhaps through
power.org) new types would be supported--e.g. "i2c",
"jdec-flash".
Thoughts?
Stuart Yoder
Freescale Semiconductor, Inc.
^ permalink raw reply
* Re: [PATCH 0/2] PowerPC: Add 44x NDFC device-tree aware support
From: Valentine Barshak @ 2007-10-29 15:19 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linuxppc-dev, sr, linux-mtd
In-Reply-To: <alpine.LFD.0.9999.0710262316590.3186@localhost.localdomain>
Thomas Gleixner wrote:
> On Fri, 26 Oct 2007, Valentine Barshak wrote:
>> The major difference is that the original implements each chip connected NDFC banks as a
>> separate MTD device. Here I try to have one MTD device spread on all chips found.
>> However, the chips should have equal ID's and sizes, but I've never seen several different
>> chips attached to single ndfc.
>
> Bamboo has 2 different nand chips. And I'm aware of another board
> which has a 2k-page onboard NAND and sockets for SmartMedia /
> PictureXd cards, which will simply break with your design.
>
> Restricting stuff for no good reason is never a good idea.
>
> mtdconcat can build you a big one if you want, so why adding
> restrictions to a driver ?
>
>> I'm adding ndfc_of as a separate file, since some other changes
>> have also been made (e.g. all i/o is made with ndfc_readl/writel inline functions).
>
> This should be done in the original ndfc driver and not in a separate
> incarnation.
>
>> The original version didn't handle driver removal well (it never calls del_mtd...),it's
>> corrected here.
>
> Why not fixing the original driver ?
>
>> Any comments are greatly appreciated.
>
> NACK.
>
> Please fix the existing driver and convert it to deal with OF and fix
> the other short comings as well.
>
> Duplicate code is not going anywhere near drivers/mtd/nand
>
> tglx
Thanks all for your comments.
Well, let me explain why I did this.
First of all I should have checked twice, since I was thinking bamboo
had identical chips :) I planned to add different chip support later a
bit, just wanted to get a simple OF driver version working first.
Surely, mtd concat can be used, but it adds a slight overhead for
identical chips. Eventually, I wanted to make it support both separate
mtd devices on each chip or spread across identical ones depending on
the device-tree settings. The other thing is that the original driver
lacked a distinct parent-child relationship between ndfc and chips.
Simply registering chip driver only after ndfc is successfully
registered doesn't guarantee we initialize chip device after ndfc is
properly initialized.
Even if we set ndfc parent for the chip platform device as suggested by
Stefan:
static struct platform_device nand_dev = {
.name = "ndfc-chip",
.id = 0,
.num_resources = 1,
.resource = &r,
.dev = {
.platform_data = &nand_chip,
.parent = &ndfc_dev.dev,
}
};
If for some reason ndfc probe fails the kernel will crash on the chip
probe. Of course it would work most of the time, but I think that both
initialization and clean-up has to be reworked in the original driver.
The original driver has a tight connection to the
platform_device/platform_data structures. Stefan suggested a
OF-to-platform device wrapper to make both versions work:
http://ozlabs.org/pipermail/linuxppc-dev/2007-October/044019.html
It's fine to have this glue code, but right now only 1 chip is
supported. To add support for more chips we need an array of at least 4
ndfc-chip platform devices. And this approach looks to me like inventing
something new (OF) and then adding glue and quirks to make it work with
the old stuff. Why invent new stuff then?
To make the original driver work with both "platform device" and new OF
device descriptions need additional rework of the current ndfc code (add
some #ifdefs, or completely split platform/OF and nand core stuff into
separate files). I know that duplicating code is no good either, but
since the original stuff is going to die and be removed anyway should it
be a big problem?
So, these are just my thoughts.
Thanks,
Valentine.
^ permalink raw reply
* boot/wrap assumes a biarch toolchain?
From: Anton Blanchard @ 2007-10-29 14:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jdittmer
Hi,
Jan is seeing the following fail:
WRAP arch/powerpc/boot/zImage.pmac
powerpc-linux-objcopy: vmlinux: File format not recognized
He is using a cross compile toolchain invoked with the following command
line:
# make HOSTCC=gcc-4.0 ARCH=powerpc CROSS_COMPILE=powerpc64-linux- CROSS32_COMPILE=powerpc-linux-
It seems like boot/wrap wants to use both 64bit and 32bit tools, however
it only receives the 32bit path:
ifneq ($(CROSS32_COMPILE),)
CROSSWRAP := -C "$(CROSS32_COMPILE)"
else
ifneq ($(CROSS_COMPILE),)
CROSSWRAP := -C "$(CROSS_COMPILE)"
endif
endif
Thoughts? I guess we have to pass in both cross compile targets.
One way to make this go away would be to build binutils as biarch:
# configure --target=powerpc-linux --enable-targets=powerpc64-linux ...
Anton
^ permalink raw reply
* Re: [POWERPC] Fix duplicate time accounting
From: Sergei Shtylyov @ 2007-10-29 13:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18213.19066.134475.220466@cargo.ozlabs.ibm.com>
Hello.
Paul Mackerras wrote:
> Currently, process user and system times are advancing twice as fast
> as they should because they are being accounted in two places - in the
> generic code and in timer_interrupt. This fixes it by removing the
> call to account_process_time in timer_interrupt.
But will the deterministic accounting option continue to work with such fix?
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 9eb3284..5e253d6 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -599,16 +599,6 @@ void timer_interrupt(struct pt_regs * regs)
> get_lppaca()->int_dword.fields.decr_int = 0;
> #endif
>
> - /*
> - * We cannot disable the decrementer, so in the period
> - * between this cpu's being marked offline in cpu_online_map
> - * and calling stop-self, it is taking timer interrupts.
> - * Avoid calling into the scheduler rebalancing code if this
> - * is the case.
> - */
> - if (!cpu_is_offline(cpu))
> - account_process_time(regs);
> -
> if (evt->event_handler)
> evt->event_handler(evt);
> else
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] ucc_geth: add support for netpoll
From: Anton Vorontsov @ 2007-10-29 12:17 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: netdev, linux-kernel, linuxppc-dev
In-Reply-To: <989B956029373F45A0B8AF0297081890019B61BF@zch01exm26.fsl.freescale.net>
On Mon, Oct 29, 2007 at 02:12:07PM +0800, Li Yang-r58472 wrote:
[...]
> > > > +#ifdef CONFIG_NET_POLL_CONTROLLER
> > > > +/*
> > > > + * Polling 'interrupt' - used by things like netconsole to send
> > > > +skbs
> > > > + * without having to re-enable interrupts. It's not called while
> > > > + * the interrupt routine is executing.
> > > > + */
> > > > +static void ucc_netpoll(struct net_device *dev) {
> > > > + struct ucc_geth_private *ugeth = netdev_priv(dev);
> > > > +
> > > > + disable_irq(ugeth->ug_info->uf_info.irq);
> > > > + ucc_geth_irq_handler(ugeth->ug_info->uf_info.irq, dev);
> > > > + enable_irq(ugeth->ug_info->uf_info.irq);
> > >
> > > Why not make it less complex (for a reader and gcc too :-) ?
> >
> > Yup, I'm agree here but it's too late. Again. ;-)
> >
> > This patch already accepted into the -mm (a week or so after
> > the silence), so.. now I'd rather not bother Andrew with such
> > really cosmetic changes. But if Jeff would directly apply
> > modfied patch, I'll send it. ;-)
>
> Oops. The original patch happened to hit the Junk mail box. :(
That one as well? http://lkml.org/lkml/2007/10/11/128
> I think
> the patch is good to merge after the cosmetic change. I can do it in
> next pull request to Jeff.
Ok, great. Thanks.
Here it is:
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [PATCH] ucc_geth: add support for netpoll
This patch adds netpoll support for the QE UCC Gigabit Ethernet
driver. Tested using netconsole and KGDBoE.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index bec413b..94e78d8 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3678,6 +3678,23 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void *info)
return IRQ_HANDLED;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/*
+ * Polling 'interrupt' - used by things like netconsole to send skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+static void ucc_netpoll(struct net_device *dev)
+{
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+ int irq = ugeth->ug_info->uf_info.irq;
+
+ disable_irq(irq);
+ ucc_geth_irq_handler(irq, dev);
+ enable_irq(irq);
+}
+#endif /* CONFIG_NET_POLL_CONTROLLER */
+
/* Called when something needs to use the ethernet device */
/* Returns 0 for success. */
static int ucc_geth_open(struct net_device *dev)
@@ -3963,6 +3980,9 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
#ifdef CONFIG_UGETH_NAPI
netif_napi_add(dev, &ugeth->napi, ucc_geth_poll, UCC_GETH_DEV_WEIGHT);
#endif /* CONFIG_UGETH_NAPI */
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ dev->poll_controller = ucc_netpoll;
+#endif
dev->stop = ucc_geth_close;
// dev->change_mtu = ucc_geth_change_mtu;
dev->mtu = 1500;
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH/RFC] powerpc: Pass PID argument to _tlbie (WAS: Apparent kernel bug with GDB on ppc405)
From: Josh Boyer @ 2007-10-29 12:08 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list, linuxppc-embedded, Kumar Gala, Matt Mackall
In-Reply-To: <1193470322.18243.63.camel@pasglop>
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.
josh
^ permalink raw reply
* Re: [PATCH v4.3] FEC - fast ethernet controller for mpc52xx
From: Jeff Garzik @ 2007-10-29 9:59 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071026160749.GA21374@nd47.coderock.org>
Domen Puncer wrote:
> On 26/10/07 07:18 -0700, Dale Farnsworth wrote:
>> On Fri, Oct 26, 2007 at 01:59:09PM +0200, Domen Puncer wrote:
>>> +static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
>>> +{
>>> + struct net_device *dev = dev_id;
>>> + struct mpc52xx_fec_priv *priv = netdev_priv(dev);
>>> +
>>> + spin_lock(&priv->lock);
>>> +
>>> + while (bcom_buffer_done(priv->tx_dmatsk)) {
>>> + struct sk_buff *skb;
>>> + struct bcom_fec_bd *bd;
>>> + skb = bcom_retrieve_buffer(priv->tx_dmatsk, NULL,
>>> + (struct bcom_bd **)&bd);
>>> + /* Here (and in rx routines) would be a good place for
>>> + * dma_unmap_single(), but bcom doesn't return bcom_bd of the
>>> + * finished transfer, and _unmap is empty on this platfrom.
>>> + */
>> Oops, you forgot to remove the above comment. :)
>
> Argh!
>
> Repost w/o the comment.
> Sorry for receiving all this almost-spam.
>
>
>> Otherwise,
>> Acked-by: Dale Farnsworth <dale@farnsworth.org>
>>
>> Domen, thanks for all your work on this. It's good to see it finally go in.
>>
>> -Dale
>
> --- again, use your scisors here ;-) ---
>
>
> Driver for ethernet on mpc5200/mpc5200b SoCs (FEC).
>
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
> Acked-by: Dale Farnsworth <dale@farnsworth.org>
>
> ---
> drivers/net/Kconfig | 24
> drivers/net/Makefile | 4
> drivers/net/fec_mpc52xx.c | 1112 ++++++++++++++++++++++++++++++++++++++++++
> drivers/net/fec_mpc52xx.h | 313 +++++++++++
> drivers/net/fec_mpc52xx_phy.c | 198 +++++++
> 5 files changed, 1651 insertions(+)
applied to #upstream-fixes
it's not strictly a fix, but I did not want to hold this back until
2.6.25 either
^ permalink raw reply
* Re: [PATCH] ehea: add kexec support
From: Jeff Garzik @ 2007-10-29 9:47 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200710261437.29117.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> eHEA resources that are allocated via H_CALLs have a unique identifier each.
> These identifiers are necessary to free the resources. A reboot notifier
> is used to free all eHEA resources before the indentifiers get lost, i.e
> before kexec starts a new kernel.
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
applied to #upstream-fixes
^ 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