* [PATCH 12/13] sdhci: Add quirk for controllers with max. block size up to 4096 bytes
From: Anton Vorontsov @ 2009-02-20 17:33 UTC (permalink / raw)
To: Pierre Ossman
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090220173228.GA5091@oksana.dev.rtsoft.ru>
FSL eSDHC controllers can support maximum block size up to 4096
bytes. The MBL (Maximum Block Length) field in the capabilities
register extended by one bit, and bits 13:15 in the block size
register reserved.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mmc/host/sdhci.c | 28 ++++++++++++++++++++--------
drivers/mmc/host/sdhci.h | 2 ++
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 91f021d..4397694 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -682,6 +682,7 @@ static void sdhci_set_transfer_irqs(struct sdhci_host *host)
static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
{
+ u16 blksz;
u8 count;
u8 ctrl;
int ret;
@@ -831,7 +832,12 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
sdhci_set_transfer_irqs(host);
/* We do not handle DMA boundaries, so set it to max (512 KiB) */
- sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, data->blksz), SDHCI_BLOCK_SIZE);
+ if (host->quirks & SDHCI_QUIRK_MAX_BLK_SZ_4096)
+ blksz = data->blksz;
+ else
+ blksz = SDHCI_MAKE_BLKSZ(7, data->blksz);
+
+ sdhci_writew(host, blksz, SDHCI_BLOCK_SIZE);
sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
}
@@ -1840,13 +1846,19 @@ int sdhci_add_host(struct sdhci_host *host)
* Maximum block size. This varies from controller to controller and
* is specified in the capabilities register.
*/
- mmc->max_blk_size = (caps & SDHCI_MAX_BLOCK_MASK) >> SDHCI_MAX_BLOCK_SHIFT;
- if (mmc->max_blk_size >= 3) {
- printk(KERN_WARNING "%s: Invalid maximum block size, "
- "assuming 512 bytes\n", mmc_hostname(mmc));
- mmc->max_blk_size = 512;
- } else
- mmc->max_blk_size = 512 << mmc->max_blk_size;
+ if (host->quirks & SDHCI_QUIRK_MAX_BLK_SZ_4096) {
+ mmc->max_blk_size = 3;
+ } else {
+ mmc->max_blk_size = (caps & SDHCI_MAX_BLOCK_MASK) >>
+ SDHCI_MAX_BLOCK_SHIFT;
+ if (mmc->max_blk_size >= 3) {
+ printk(KERN_WARNING "%s: Invalid maximum block size, "
+ "assuming 512 bytes\n", mmc_hostname(mmc));
+ mmc->max_blk_size = 0;
+ }
+ }
+
+ mmc->max_blk_size = 512 << mmc->max_blk_size;
/*
* Maximum block count.
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 5c5a950..c8628b4 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -231,6 +231,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_PIO_NEEDS_DELAY (1<<20)
/* Controller losing signal/interrupt enable states after reset */
#define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET (1<<21)
+/* Controller supports nonstandard maximum block length of 4096 bytes */
+#define SDHCI_QUIRK_MAX_BLK_SZ_4096 (1<<22)
int irq; /* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
^ permalink raw reply related
* [PATCH 09/13] sdhci: Add set_clock callback and a quirk for nonstandard clocks
From: Anton Vorontsov @ 2009-02-20 17:33 UTC (permalink / raw)
To: Pierre Ossman
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090220173228.GA5091@oksana.dev.rtsoft.ru>
FSL eSDHC hosts have incompatible register map to manage the SDCLK.
This patch adds set_clock callback so that drivers could overwrite
set_clock behaviour.
Similar patch[1] was posted by Ben Dooks, though in Ben's version the
callback is named change_clock, plus the patch has some unrelated bits
that makes the patch difficult to reuse.
[1] http://lkml.org/lkml/2008/12/2/160
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mmc/host/sdhci.c | 6 ++++++
drivers/mmc/host/sdhci.h | 4 ++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 96a0482..f63db25 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1013,6 +1013,12 @@ static void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
if (clock == host->clock)
return;
+ if (host->ops->set_clock) {
+ host->ops->set_clock(host, clock);
+ if (host->quirks & SDHCI_QUIRK_NONSTANDARD_CLOCK)
+ return;
+ }
+
sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
if (clock == 0)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index ef70900..63b436a 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -225,6 +225,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_INVERTED_WRITE_PROTECT (1<<17)
/* Controller has all registers of 32 bit width */
#define SDHCI_QUIRK_32BIT_REGISTERS (1<<18)
+/* Controller has nonstandard clock management */
+#define SDHCI_QUIRK_NONSTANDARD_CLOCK (1<<19)
int irq; /* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
@@ -288,6 +290,8 @@ struct sdhci_ops {
void (*writew)(struct sdhci_host *host, u16 val, int reg);
void (*writeb)(struct sdhci_host *host, u8 val, int reg);
+ void (*set_clock)(struct sdhci_host *host, unsigned int clock);
+
int (*enable_dma)(struct sdhci_host *host);
unsigned int (*get_max_clock)(struct sdhci_host *host);
unsigned int (*get_timeout_clock)(struct sdhci_host *host);
--
1.5.6.5
^ permalink raw reply related
* [PATCH 13/13] mmc: Add OpenFirmware bindings for SDHCI driver
From: Anton Vorontsov @ 2009-02-20 17:33 UTC (permalink / raw)
To: Pierre Ossman
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090220173228.GA5091@oksana.dev.rtsoft.ru>
This patch adds a new driver: sdhci-of. The driver is similar to
the sdhci-pci, it contains common probe code, and controller-specific
ops and quirks.
So far there are only Freescale eSDHC ops and quirks.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/mmc/host/Kconfig | 10 ++
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-of.c | 287 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 298 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/host/sdhci-of.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 99d4b28..73b79e1 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -65,6 +65,16 @@ config MMC_RICOH_MMC
If unsure, say Y.
+config MMC_SDHCI_OF
+ tristate "SDHCI support on OpenFirmware platforms"
+ depends on MMC_SDHCI && PPC_OF
+ help
+ This selects the OF support for Secure Digital Host Controller
+ Interfaces. So far, only the Freescale eSDHC controller is known
+ to exist on OF platforms.
+
+ If unsure, say N.
+
config MMC_OMAP
tristate "TI OMAP Multimedia Card Interface support"
depends on ARCH_OMAP
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index dedec55..dd512d9 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_MMC_MXC) += mxcmmc.o
obj-$(CONFIG_MMC_SDHCI) += sdhci.o
obj-$(CONFIG_MMC_SDHCI_PCI) += sdhci-pci.o
obj-$(CONFIG_MMC_RICOH_MMC) += ricoh_mmc.o
+obj-$(CONFIG_MMC_SDHCI_OF) += sdhci-of.o
obj-$(CONFIG_MMC_WBSD) += wbsd.o
obj-$(CONFIG_MMC_AU1X) += au1xmmc.o
obj-$(CONFIG_MMC_OMAP) += omap.o
diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
new file mode 100644
index 0000000..22bf006
--- /dev/null
+++ b/drivers/mmc/host/sdhci-of.c
@@ -0,0 +1,287 @@
+/*
+ * OpenFirmware bindings for Secure Digital Host Controller Interface.
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2009 MontaVista Software, Inc.
+ *
+ * Authors: Xiaobo Xie <X.Xie@freescale.com>
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/mmc/host.h>
+#include "sdhci.h"
+
+struct sdhci_of_data {
+ unsigned int quirks;
+ struct sdhci_ops ops;
+};
+
+struct sdhci_of_host {
+ unsigned int clock;
+};
+
+/*
+ * Ops and quirks for the Freescale eSDHC controller.
+ */
+
+#define ESDHC_DMA_SYSCTL 0x40c
+#define ESDHC_DMA_SNOOP 0x00000040
+
+#define ESDHC_SYSTEM_CONTROL 0x2c
+#define ESDHC_CLOCK_MASK 0x0000fff0
+#define ESDHC_PREDIV_SHIFT 8
+#define ESDHC_DIVIDER_SHIFT 4
+#define ESDHC_CLOCK_PEREN 0x00000004
+#define ESDHC_CLOCK_HCKEN 0x00000002
+#define ESDHC_CLOCK_IPGEN 0x00000001
+
+static u32 esdhc_readl(struct sdhci_host *host, int reg)
+{
+ return in_be32(host->ioaddr + reg);
+}
+
+static u16 esdhc_readw(struct sdhci_host *host, int reg)
+{
+ return in_be16(host->ioaddr + (reg ^ 0x2));
+}
+
+static u8 esdhc_readb(struct sdhci_host *host, int reg)
+{
+ return in_8(host->ioaddr + (reg ^ 0x3));
+}
+
+static void esdhc_writel(struct sdhci_host *host, u32 val, int reg)
+{
+ out_be32(host->ioaddr + reg, val);
+}
+
+static void esdhc_writew(struct sdhci_host *host, u16 val, int reg)
+{
+ int base = reg & ~0x3;
+ int shift = (reg & 0x2) * 8;
+
+ clrsetbits_be32(host->ioaddr + base, 0xffff << shift, val << shift);
+}
+
+static void esdhc_writeb(struct sdhci_host *host, u8 val, int reg)
+{
+ int base = reg & ~0x3;
+ int shift = (reg & 0x3) * 8;
+
+ clrsetbits_be32(host->ioaddr + base , 0xff << shift, val << shift);
+}
+
+static void esdhc_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+ int div;
+ int pre_div = 2;
+
+ clrbits32(host->ioaddr + ESDHC_SYSTEM_CONTROL, ESDHC_CLOCK_IPGEN |
+ ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN | ESDHC_CLOCK_MASK);
+
+ if (clock == 0)
+ goto out;
+
+ if (host->max_clk / 16 > clock) {
+ for (; pre_div < 256; pre_div *= 2) {
+ if (host->max_clk / pre_div < clock * 16)
+ break;
+ }
+ }
+
+ for (div = 1; div <= 16; div++) {
+ if (host->max_clk / (div * pre_div) <= clock)
+ break;
+ }
+
+ pre_div >>= 1;
+
+ setbits32(host->ioaddr + ESDHC_SYSTEM_CONTROL, ESDHC_CLOCK_IPGEN |
+ ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN |
+ div << ESDHC_DIVIDER_SHIFT | pre_div << ESDHC_PREDIV_SHIFT);
+ mdelay(100);
+out:
+ host->clock = clock;
+}
+
+static int esdhc_enable_dma(struct sdhci_host *host)
+{
+ setbits32(host->ioaddr + ESDHC_DMA_SYSCTL, ESDHC_DMA_SNOOP);
+ return 0;
+}
+
+static unsigned int esdhc_get_max_clock(struct sdhci_host *host)
+{
+ struct sdhci_of_host *of_host = sdhci_priv(host);
+
+ return of_host->clock;
+}
+
+static unsigned int esdhc_get_timeout_clock(struct sdhci_host *host)
+{
+ struct sdhci_of_host *of_host = sdhci_priv(host);
+
+ return of_host->clock / 1000;
+}
+
+static struct sdhci_of_data sdhci_esdhc = {
+ .quirks = SDHCI_QUIRK_32BIT_REGISTERS |
+ SDHCI_QUIRK_BROKEN_CARD_DETECTION |
+ SDHCI_QUIRK_INVERTED_WRITE_PROTECT |
+ SDHCI_QUIRK_NO_BUSY_IRQ |
+ SDHCI_QUIRK_NONSTANDARD_CLOCK |
+ SDHCI_QUIRK_PIO_NEEDS_DELAY |
+ SDHCI_QUIRK_MAX_BLK_SZ_4096 |
+ SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET |
+ SDHCI_QUIRK_NO_CARD_NO_RESET,
+ .ops = {
+ .readl = esdhc_readl,
+ .readw = esdhc_readw,
+ .readb = esdhc_readb,
+ .writel = esdhc_writel,
+ .writew = esdhc_writew,
+ .writeb = esdhc_writeb,
+ .set_clock = esdhc_set_clock,
+ .enable_dma = esdhc_enable_dma,
+ .get_max_clock = esdhc_get_max_clock,
+ .get_timeout_clock = esdhc_get_timeout_clock,
+ },
+};
+
+#ifdef CONFIG_PM
+
+static int sdhci_of_suspend(struct of_device *ofdev, pm_message_t state)
+{
+ struct sdhci_host *host = dev_get_drvdata(&ofdev->dev);
+
+ return mmc_suspend_host(host->mmc, state);
+}
+
+static int sdhci_of_resume(struct of_device *ofdev)
+{
+ struct sdhci_host *host = dev_get_drvdata(&ofdev->dev);
+
+ return mmc_resume_host(host->mmc);
+}
+
+#else
+
+#define sdhci_of_suspend NULL
+#define sdhci_of_resume NULL
+
+#endif
+
+static int __devinit sdhci_of_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device_node *np = ofdev->node;
+ struct sdhci_of_data *sdhci_of_data = match->data;
+ struct sdhci_host *host;
+ struct sdhci_of_host *of_host;
+ const u32 *clk;
+ int size;
+ int ret;
+
+ if (!of_device_is_available(np))
+ return -ENODEV;
+
+ host = sdhci_alloc_host(&ofdev->dev, sizeof(*of_host));
+ if (!host)
+ return -ENOMEM;
+
+ of_host = sdhci_priv(host);
+ dev_set_drvdata(&ofdev->dev, host);
+
+ host->ioaddr = of_iomap(np, 0);
+ if (!host->ioaddr) {
+ ret = -ENOMEM;
+ goto err_addr_map;
+ }
+
+ host->irq = irq_of_parse_and_map(np, 0);
+ if (!host->irq) {
+ ret = -EINVAL;
+ goto err_no_irq;
+ }
+
+ host->hw_name = dev_name(&ofdev->dev);
+ if (sdhci_of_data) {
+ host->quirks = sdhci_of_data->quirks;
+ host->ops = &sdhci_of_data->ops;
+ }
+
+ clk = of_get_property(np, "clock-frequency", &size);
+ if (clk && size == sizeof(*clk) && *clk)
+ of_host->clock = *clk;
+
+ ret = sdhci_add_host(host);
+ if (ret)
+ goto err_add_host;
+
+ return 0;
+
+err_add_host:
+ irq_dispose_mapping(host->irq);
+err_no_irq:
+ iounmap(host->ioaddr);
+err_addr_map:
+ sdhci_free_host(host);
+ return ret;
+}
+
+static int __devexit sdhci_of_remove(struct of_device *ofdev)
+{
+ struct sdhci_host *host = dev_get_drvdata(&ofdev->dev);
+
+ sdhci_remove_host(host, 0);
+ sdhci_free_host(host);
+ irq_dispose_mapping(host->irq);
+ iounmap(host->ioaddr);
+ return 0;
+}
+
+static const struct of_device_id sdhci_of_match[] = {
+ { .compatible = "fsl,mpc8379-esdhc", .data = &sdhci_esdhc, },
+ { .compatible = "fsl,mpc8536-esdhc", .data = &sdhci_esdhc, },
+ { .compatible = "generic-sdhci", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sdhci_of_match);
+
+static struct of_platform_driver sdhci_of_driver = {
+ .driver.name = "sdhci-of",
+ .match_table = sdhci_of_match,
+ .probe = sdhci_of_probe,
+ .remove = __devexit_p(sdhci_of_remove),
+ .suspend = sdhci_of_suspend,
+ .resume = sdhci_of_resume,
+};
+
+static int __init sdhci_of_init(void)
+{
+ return of_register_platform_driver(&sdhci_of_driver);
+}
+module_init(sdhci_of_init);
+
+static void __exit sdhci_of_exit(void)
+{
+ of_unregister_platform_driver(&sdhci_of_driver);
+}
+module_exit(sdhci_of_exit);
+
+MODULE_DESCRIPTION("Secure Digital Host Controller Interface OF driver");
+MODULE_AUTHOR("Xiaobo Xie <X.Xie@freescale.com>, "
+ "Anton Vorontsov <avorontsov@ru.mvista.com>");
+MODULE_LICENSE("GPL");
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] powerpc/83xx: Add power management support for MPC837x boards
From: Anton Vorontsov @ 2009-02-20 17:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <499EE8DD.2030709@freescale.com>
On Fri, Feb 20, 2009 at 11:31:09AM -0600, Scott Wood wrote:
> Anton Vorontsov wrote:
>> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/boot/dts/mpc8377_mds.dts
>> index 3e3ec8f..c54b90d 100644
>> --- a/arch/powerpc/boot/dts/mpc8377_mds.dts
>> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
>> @@ -137,6 +137,7 @@
>> reg = <0x3000 0x100>;
>> interrupts = <14 0x8>;
>> interrupt-parent = <&ipic>;
>> + sleep = <&pmc 0x0c000000>;
>> dfsrr;
>
> [snip]
>
>> @@ -318,6 +325,7 @@
>> reg = <0x2e000 0x1000>;
>> interrupts = <42 0x8>;
>> interrupt-parent = <&ipic>;
>> + sleep = <&pmc 0x0c000000>;
>
> You have two different nodes with the same bits referenced.
Yes, I2C1 and eSDHC are using the same clock source.
> These nodes
> cannot be put to sleep independently, and as such need to be under a
> common sleep-nexus node.
Ah, that's what the sleep-nexus nodes are for... ;-)
Thank you Scott, I'll add the sleep-nexus nodes.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 10/13] sdhci: Add quirk for controllers that need small delays for PIO
From: Anton Vorontsov @ 2009-02-20 17:33 UTC (permalink / raw)
To: Pierre Ossman
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090220173228.GA5091@oksana.dev.rtsoft.ru>
Small udelay is needed to make eSDHC work in PIO mode. Without
the delay reading causes endless interrupt storm, and writing
corrupts data. The first guess would be that we must wait for
some bit in some register, but I didn't find any reliable bits
that change before and after the delay.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mmc/host/sdhci.c | 3 +++
drivers/mmc/host/sdhci.h | 2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f63db25..eff615d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -391,6 +391,9 @@ static void sdhci_transfer_pio(struct sdhci_host *host)
mask = ~0;
while (sdhci_readl(host, SDHCI_PRESENT_STATE) & mask) {
+ if (host->quirks & SDHCI_QUIRK_PIO_NEEDS_DELAY)
+ udelay(100);
+
if (host->data->flags & MMC_DATA_READ)
sdhci_read_block_pio(host);
else
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 63b436a..44c820a 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -227,6 +227,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_32BIT_REGISTERS (1<<18)
/* Controller has nonstandard clock management */
#define SDHCI_QUIRK_NONSTANDARD_CLOCK (1<<19)
+/* Controller does not like fast PIO transfers */
+#define SDHCI_QUIRK_PIO_NEEDS_DELAY (1<<20)
int irq; /* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
^ permalink raw reply related
* eTSEC queries on 8548E
From: sunder ramani @ 2009-02-20 18:30 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]
Hi,
I am a newbie to PowerPC architecture and eTSEC. I have some queries:
1. Is there a way for me to configure different eTSECs in different media
modes? I understand that the MII interface does the same thing; yet do I
have to take some explicit care in the drivers for the eTSEC to
differentiate between a copper and fiber interface? Is this task of the SW
or is this configuration basically by the HW.
2. My custom board has the TSECs connected to a Marvell switch; one of the
ports being connected via the RGMII interface to a copper media; whilst the
other connected via the RGMII interface to another port on the switch via
the SGMII interface. Do I need to make any changes in the driver to effect
this configuration. I referred the gianfar, mdio, phy, mii drivers; but
couldnt find any specific code which would enable me to differentiate the
media interfaces.
3. My HW team tells me to write specific values to the PHY registers which
will differentiate the media interfaces to the Marvell switch via the
MDIO/MDCTL configuration lines from the MPC. If this is the case,
a. Would it be recommended to implement a PHY-ID specific implementation for
writing to the PHY registers in the gfar_enet_open when the phy_connect
function is called? OR
b. Would it be recommended to pass some kind of member through the DTS file
to the kernel, therbey affecting a change in the platform specific file.
Can any one please help me clear off these queries?
Thanx!
Sundar
[-- Attachment #2: Type: text/html, Size: 1709 bytes --]
^ permalink raw reply
* PCI reading without endian conversion
From: Matt Sealey @ 2009-02-20 18:57 UTC (permalink / raw)
To: PowerPC dev list
Hi guys,
What's the correct way to read from PCI address space (basically it's
guaranteed to be non-coherent memory bar) without flipping bits like
ioread32() does?
I need to be able to copy a bank of registers from PCI address space
into a temporary buffer so I can compare them in userspace through
UIO. Because of the flipping and the difference between the original
kernel driver (which used ioread32() and therefore "saw" big endian)
and the userspace app (which has a direct view of the PCI space, and
therefore "sees" little endian) I decided to give userspace an
absolutely consistent little-endian view seeing as this may get ported
to ARM in the coming months.
I want to put as little code in there as possible and not laboriously
manually flip from my ioread32() big endian values to little endian
again (waste of time and code) if I can help it. Being able to read
the raw value would help a lot, and if I need to do calculations on a
small portion of the data then I can do the flips manually then (using
le32_to_cpu and cpu_to_le32 which will be a noop on ARM), reducing the
amount of porting I need to do in both kernel and userspace alike.
So, is there something like a direct ioread32le() or so, which will
not change behaviour across architectures, is present on ARM and PPC,
and will handle both PCI address space, and "normal" "ioremapped"
memory?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: PCI reading without endian conversion
From: Ira Snyder @ 2009-02-20 19:11 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <b5e2fc790902201057of113946yea9ccc7405e31926@mail.gmail.com>
On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
> Hi guys,
>
> What's the correct way to read from PCI address space (basically it's
> guaranteed to be non-coherent memory bar) without flipping bits like
> ioread32() does?
>
> I need to be able to copy a bank of registers from PCI address space
> into a temporary buffer so I can compare them in userspace through
> UIO. Because of the flipping and the difference between the original
> kernel driver (which used ioread32() and therefore "saw" big endian)
> and the userspace app (which has a direct view of the PCI space, and
> therefore "sees" little endian) I decided to give userspace an
> absolutely consistent little-endian view seeing as this may get ported
> to ARM in the coming months.
>
> I want to put as little code in there as possible and not laboriously
> manually flip from my ioread32() big endian values to little endian
> again (waste of time and code) if I can help it. Being able to read
> the raw value would help a lot, and if I need to do calculations on a
> small portion of the data then I can do the flips manually then (using
> le32_to_cpu and cpu_to_le32 which will be a noop on ARM), reducing the
> amount of porting I need to do in both kernel and userspace alike.
>
> So, is there something like a direct ioread32le() or so, which will
> not change behaviour across architectures, is present on ARM and PPC,
> and will handle both PCI address space, and "normal" "ioremapped"
> memory?
>
I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you
want. They don't change byte ordering.
Ira
^ permalink raw reply
* RE: Gianfar tx-babbling-errors
From: Haruki Dai-R35557 @ 2009-02-20 19:16 UTC (permalink / raw)
To: Scott Coulter, linuxppc-dev; +Cc: Gala Kumar-B11780
In-Reply-To: <43EB80E07C42E1408726E4905FB96B04C0769D@CYBORG3.cyclone.com>
Hi Scott,
Is this your own board? If so, what PHY chip are you using? Are you
using the PHY driver?
If the generic PHY driver is used and polling the MDIO periodically for
the link check, you may truncate the packet. I hope this is not the
case.=20
Regards
Dai
> -----Original Message-----
> From: linuxppc-dev-bounces+dai.haruki=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+dai.haruki=3Dfreescale.com@ozlabs.org] On
Behalf Of
> Scott Coulter
> Sent: Wednesday, February 18, 2009 10:16 AM
> To: linuxppc-dev@ozlabs.org
> Subject: Gianfar tx-babbling-errors
>=20
>=20
> Hi all,
>=20
> As a simple stress test for my board with an MPC8572E and an MPC8568E
on
> it, I setup both processors to boot linux 2.6.27.6 with an NFS root
and
> then perform repeated native compiles of a linux kernel over NFS.
After
> running for 4 days straight or so with between 250-300 build cycles
per
> processor, I stopped the builds and ran ethtool to look for any odd
> statistics. Both processors reported non-zero values for
> tx-babbling-errors. Both processors reported around 1300
> tx-babbling-errors out of about 80,000,000 Tx packets. Should I be
> concerned about the tx-babbling-errors? What conditions would cause
> these errors to be reported?
>=20
> Thanks,
> Scott
>=20
>=20
>=20
>=20
>=20
> ___________________________________________________________________
>=20
> Scott N. Coulter
> Senior Software Engineer
>=20
> Cyclone Microsystems
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
> ___________________________________________________________________
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PCI reading without endian conversion
From: Matt Sealey @ 2009-02-20 20:05 UTC (permalink / raw)
To: Ira Snyder; +Cc: PowerPC dev list
In-Reply-To: <20090220191108.GA21163@ovro.caltech.edu>
On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder <iws@ovro.caltech.edu> wrote:
> On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
>
> I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you
> want. They don't change byte ordering.
Are they guaranteed to only do 32-bit, aligned accesses?
I made some cheats on my CPLD to ignore byte enables and so on,
because it makes the design cleaner and easier to read (for students)
plus, saves a ton of logic cells. It's totally within the PCI
standard, but it means if you do a byte read memcpy() you get.. very
weird results (i.e. not great).
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/pci: Default to dma_direct_ops for pci dma_ops
From: Becky Bruce @ 2009-02-20 20:44 UTC (permalink / raw)
To: Benjamin Krill; +Cc: linuxppc-dev, arnd
In-Reply-To: <20090219220800.GG12204@codiert.org>
On Feb 19, 2009, at 4:08 PM, Benjamin Krill wrote:
> * Kumar Gala | 2009-02-19 14:49:15 [-0600]:
>
>> This will allow us to remove the ppc32 specific checks in
>> get_dma_ops()
>> that defaults to dma_direct_ops if the archdata is NULL. We really
>> should always have archdata set to something going forward.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> Acked-by: Benjamin Krill <ben@codiert.org>
Tested on ppc 86xx, looks good.
Acked-by: Becky Bruce <beckyb@kernel.crashing.org>
-B
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: setup archdata for {of_}platform via a single platform_notify
From: Becky Bruce @ 2009-02-20 20:44 UTC (permalink / raw)
To: Benjamin Krill; +Cc: linuxppc-dev, arnd
In-Reply-To: <20090219220820.GH12204@codiert.org>
On Feb 19, 2009, at 4:08 PM, Benjamin Krill wrote:
> * Kumar Gala | 2009-02-19 14:49:16 [-0600]:
>
>> Since a number of powerpc chips are SoCs we end up having dma-able
>> devices that are registered as platform or of_platform devices. We
>> need
>> to hook the archdata to setup proper dma_ops for these devices.
>>
>> In the short term the majority of these devices only need the
>> direct_dma_ops as the platforms don't have any IOMMUs.
>>
>> In the future to enable >4G DMA support on ppc32 we can hook
>> swiotlb ops.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> Acked-by: Benjamin Krill <ben@codiert.org>
Tested on ppc 86xx, looks good.
Acked-by: Becky Bruce <beckyb@kernel.crashing.org>
-B
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: expect all devices calling dma ops to have archdata set
From: Becky Bruce @ 2009-02-20 20:45 UTC (permalink / raw)
To: Benjamin Krill; +Cc: linuxppc-dev, arnd
In-Reply-To: <20090219220835.GI12204@codiert.org>
On Feb 19, 2009, at 4:08 PM, Benjamin Krill wrote:
> * Kumar Gala | 2009-02-19 14:49:17 [-0600]:
>
>> Now that we set archdata for of_platform and platform devices via
>> platform_notify() we no longer need to special case having a NULL
>> device
>> pointer or NULL archdata. It should be a driver error if this
>> condition
>> shows up and the driver should be fixed.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> Acked-by: Benjamin Krill <ben@codiert.org>
Tested on ppc 86xx, looks good.
Acked-by: Becky Bruce <beckyb@kernel.crashing.org>
-B
^ permalink raw reply
* RE: Gianfar tx-babbling-errors
From: Scott Coulter @ 2009-02-20 20:59 UTC (permalink / raw)
To: Haruki Dai-R35557, linuxppc-dev; +Cc: Gala Kumar-B11780
In-Reply-To: <18AEF66AFDF06F4CAAA1D419D000FD3302B1EAB1@az33exm24.fsl.freescale.net>
Dai,
> Is this your own board? If so, what PHY chip are you using? Are you
> using the PHY driver?
> If the generic PHY driver is used and polling the MDIO periodically
for
> the link check, you may truncate the packet. I hope this is not the
> case.
Yes this is our own board. Both the 8568E and 8572E processors each
expose two TSECs. The 4 TSECs are each connected to a separate
interface of a Broadcom 5464 Quad PHY in RGMII mode. I am pretty sure
that there is no interrupt connected (I'll have to check with the
hardware engineer) and I know that I didn't configure one in the DTS
file. My kernel is configured to use the Broadcomm 54xx driver, but I'm
not sure if it polls when no interrupt is configured.
Thanks,
Scott
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
> -----Original Message-----
> From: Haruki Dai-R35557 [mailto:Dai.Haruki@freescale.com]
> Sent: February 20, 2009 2:16PM
> To: Scott Coulter; linuxppc-dev@ozlabs.org
> Cc: Gala Kumar-B11780
> Subject: RE: Gianfar tx-babbling-errors
>=20
> Hi Scott,
>=20
>=20
> Regards
> Dai
>=20
> > -----Original Message-----
> > From: linuxppc-dev-bounces+dai.haruki=3Dfreescale.com@ozlabs.org
> > [mailto:linuxppc-dev-bounces+dai.haruki=3Dfreescale.com@ozlabs.org] =
On
> Behalf Of
> > Scott Coulter
> > Sent: Wednesday, February 18, 2009 10:16 AM
> > To: linuxppc-dev@ozlabs.org
> > Subject: Gianfar tx-babbling-errors
> >
> >
> > Hi all,
> >
> > As a simple stress test for my board with an MPC8572E and an
MPC8568E
> on
> > it, I setup both processors to boot linux 2.6.27.6 with an NFS root
> and
> > then perform repeated native compiles of a linux kernel over NFS.
> After
> > running for 4 days straight or so with between 250-300 build cycles
> per
> > processor, I stopped the builds and ran ethtool to look for any odd
> > statistics. Both processors reported non-zero values for
> > tx-babbling-errors. Both processors reported around 1300
> > tx-babbling-errors out of about 80,000,000 Tx packets. Should I be
> > concerned about the tx-babbling-errors? What conditions would cause
> > these errors to be reported?
> >
> > Thanks,
> > Scott
> >
> >
> >
> >
> >
> > ___________________________________________________________________
> >
> > Scott N. Coulter
> > Senior Software Engineer
> >
> > Cyclone Microsystems
> > 370 James Street Phone: 203.786.5536 ext. 118
> > New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> > U.S.A. Web: http://www.cyclone.com
> > ___________________________________________________________________
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PCI reading without endian conversion
From: Ira Snyder @ 2009-02-20 21:07 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <b5e2fc790902201205t4bd03373w7e7624fce60f5eb0@mail.gmail.com>
On Fri, Feb 20, 2009 at 02:05:08PM -0600, Matt Sealey wrote:
> On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder <iws@ovro.caltech.edu> wrote:
> > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
> >
> > I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you
> > want. They don't change byte ordering.
>
> Are they guaranteed to only do 32-bit, aligned accesses?
>
I don't think so. I certainly wouldn't count on anything better than a
byte-by-byte memcpy.
> I made some cheats on my CPLD to ignore byte enables and so on,
> because it makes the design cleaner and easier to read (for students)
> plus, saves a ton of logic cells. It's totally within the PCI
> standard, but it means if you do a byte read memcpy() you get.. very
> weird results (i.e. not great).
>
Right, I understand how that works :)
Some usage of cscope shows that __raw_readl() might be what you want,
as well as __raw_writel() for writing. I'm not sure it is universally
available, but maybe they are.
The comment on PowerPC says "Non ordered and non-swapping "raw"
accessors". Looks about right. ARM's implementation uses them to
implement ioread32() and friends by adding byteswapping.
Hope it helps,
Ira
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
^ permalink raw reply
* RE: Gianfar tx-babbling-errors
From: Haruki Dai-R35557 @ 2009-02-20 21:32 UTC (permalink / raw)
To: Scott Coulter, linuxppc-dev; +Cc: Gala Kumar-B11780
In-Reply-To: <43EB80E07C42E1408726E4905FB96B04C0774E@CYBORG3.cyclone.com>
Scott,
I am not so sure about your PHY, but if you access to PHY while packet
transmission through MDIO bus, the packet might be corrupted. Do you
have "phy_interrupt" in the /proc/interrupts? What is your dmesg around
the eTSEC look like (there is phy driver info surrounded).
Regards
Dai
> -----Original Message-----
> From: Scott Coulter [mailto:scott.coulter@cyclone.com]
> Sent: Friday, February 20, 2009 3:00 PM
> To: Haruki Dai-R35557; linuxppc-dev@ozlabs.org
> Cc: Gala Kumar-B11780
> Subject: RE: Gianfar tx-babbling-errors
>=20
>=20
>=20
>=20
> Dai,
>=20
> > Is this your own board? If so, what PHY chip are you using? Are you
> > using the PHY driver?
> > If the generic PHY driver is used and polling the MDIO periodically
> for
> > the link check, you may truncate the packet. I hope this is not the
> > case.
>=20
> Yes this is our own board. Both the 8568E and 8572E processors each
> expose two TSECs. The 4 TSECs are each connected to a separate
> interface of a Broadcom 5464 Quad PHY in RGMII mode. I am pretty
sure
> that there is no interrupt connected (I'll have to check with the
> hardware engineer) and I know that I didn't configure one in the DTS
> file. My kernel is configured to use the Broadcomm 54xx driver, but
I'm
> not sure if it polls when no interrupt is configured.
>=20
> Thanks,
> Scott
> ___________________________________________________________________
>=20
> Scott N. Coulter
> Senior Software Engineer
>=20
> Cyclone Microsystems
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
> ___________________________________________________________________
>=20
> > -----Original Message-----
> > From: Haruki Dai-R35557 [mailto:Dai.Haruki@freescale.com]
> > Sent: February 20, 2009 2:16PM
> > To: Scott Coulter; linuxppc-dev@ozlabs.org
> > Cc: Gala Kumar-B11780
> > Subject: RE: Gianfar tx-babbling-errors
> >
> > Hi Scott,
> >
> >
> > Regards
> > Dai
> >
> > > -----Original Message-----
> > > From: linuxppc-dev-bounces+dai.haruki=3Dfreescale.com@ozlabs.org
> > > =
[mailto:linuxppc-dev-bounces+dai.haruki=3Dfreescale.com@ozlabs.org]
On
> > Behalf Of
> > > Scott Coulter
> > > Sent: Wednesday, February 18, 2009 10:16 AM
> > > To: linuxppc-dev@ozlabs.org
> > > Subject: Gianfar tx-babbling-errors
> > >
> > >
> > > Hi all,
> > >
> > > As a simple stress test for my board with an MPC8572E and an
> MPC8568E
> > on
> > > it, I setup both processors to boot linux 2.6.27.6 with an NFS
root
> > and
> > > then perform repeated native compiles of a linux kernel over NFS.
> > After
> > > running for 4 days straight or so with between 250-300 build
cycles
> > per
> > > processor, I stopped the builds and ran ethtool to look for any
odd
> > > statistics. Both processors reported non-zero values for
> > > tx-babbling-errors. Both processors reported around 1300
> > > tx-babbling-errors out of about 80,000,000 Tx packets. Should I
be
> > > concerned about the tx-babbling-errors? What conditions would
cause
> > > these errors to be reported?
> > >
> > > Thanks,
> > > Scott
> > >
> > >
> > >
> > >
> > >
> > >
___________________________________________________________________
> > >
> > > Scott N. Coulter
> > > Senior Software Engineer
> > >
> > > Cyclone Microsystems
> > > 370 James Street Phone: 203.786.5536 ext. 118
> > > New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> > > U.S.A. Web: http://www.cyclone.com
> > >
___________________________________________________________________
> > >
> > > _______________________________________________
> > > Linuxppc-dev mailing list
> > > Linuxppc-dev@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: PCI reading without endian conversion
From: Matt Sealey @ 2009-02-20 21:56 UTC (permalink / raw)
To: Ira Snyder; +Cc: PowerPC dev list
In-Reply-To: <20090220210744.GB21163@ovro.caltech.edu>
On Fri, Feb 20, 2009 at 3:07 PM, Ira Snyder <iws@ovro.caltech.edu> wrote:
> On Fri, Feb 20, 2009 at 02:05:08PM -0600, Matt Sealey wrote:
>> On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder <iws@ovro.caltech.edu> wrote:
>> > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
>> >
>> > I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you
>> > want. They don't change byte ordering.
>>
>> Are they guaranteed to only do 32-bit, aligned accesses?
>>
>
> I don't think so. I certainly wouldn't count on anything better than a
> byte-by-byte memcpy.
>
>> I made some cheats on my CPLD to ignore byte enables and so on,
>> because it makes the design cleaner and easier to read (for students)
>> plus, saves a ton of logic cells. It's totally within the PCI
>> standard, but it means if you do a byte read memcpy() you get.. very
>> weird results (i.e. not great).
>>
>
> Right, I understand how that works :)
>
> Some usage of cscope shows that __raw_readl() might be what you want,
> as well as __raw_writel() for writing. I'm not sure it is universally
> available, but maybe they are.
>
> The comment on PowerPC says "Non ordered and non-swapping "raw"
> accessors". Looks about right. ARM's implementation uses them to
> implement ioread32() and friends by adding byteswapping.
Am I correct in saying that cpu_to_le32 and le32_to_cpu are the
functions/macros I need to use to do byte swapping to make everything
go little endian (and back again when I read them back in the kernel)?
Or is there some cleverer way already implemented in the kernel?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: PCI reading without endian conversion
From: Benjamin Herrenschmidt @ 2009-02-20 22:37 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <b5e2fc790902201057of113946yea9ccc7405e31926@mail.gmail.com>
On Fri, 2009-02-20 at 12:57 -0600, Matt Sealey wrote:
> Hi guys,
>
> What's the correct way to read from PCI address space (basically it's
> guaranteed to be non-coherent memory bar) without flipping bits like
> ioread32() does?
ioread32be() ? :-) But from what you say below, it seems the wrong
approach.
> I need to be able to copy a bank of registers from PCI address space
> into a temporary buffer so I can compare them in userspace through
> UIO. Because of the flipping and the difference between the original
> kernel driver (which used ioread32() and therefore "saw" big endian)
> and the userspace app (which has a direct view of the PCI space, and
> therefore "sees" little endian) I decided to give userspace an
> absolutely consistent little-endian view seeing as this may get ported
> to ARM in the coming months.
Your sentence above doesn't seem to make much sense to me ... Why don't
you just have your userspace use lwbrx and "see" the same thing as the
kernel ? Which would also happen to be the same thing as an ARM in LE
mode would see...
> I want to put as little code in there as possible and not laboriously
> manually flip from my ioread32() big endian values to little endian
> again (waste of time and code) if I can help it. Being able to read
> the raw value would help a lot, and if I need to do calculations on a
> small portion of the data then I can do the flips manually then (using
> le32_to_cpu and cpu_to_le32 which will be a noop on ARM), reducing the
> amount of porting I need to do in both kernel and userspace alike.
>
> So, is there something like a direct ioread32le() or so, which will
> not change behaviour across architectures, is present on ARM and PPC,
> and will handle both PCI address space, and "normal" "ioremapped"
> memory?
Little of what you say above make sense, you mix unrelated concepts and
all other weirdness mangled with purely false assumptions but from what
I can tell, what you should do is something along the line of:
- kernel uses normal ioread32 on all platforms
- userspace use lwbrx on powerpc and normal loads on LE platforms via
some kind of macro you define for that
That will give you a consistent view accross the board.
Cheers,
Ben.
^ permalink raw reply
* Re: PCI reading without endian conversion
From: Ira Snyder @ 2009-02-20 23:50 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <b5e2fc790902201356v7e01b17al3ecd7e06ac59af3d@mail.gmail.com>
On Fri, Feb 20, 2009 at 03:56:39PM -0600, Matt Sealey wrote:
> On Fri, Feb 20, 2009 at 3:07 PM, Ira Snyder <iws@ovro.caltech.edu> wrote:
> > On Fri, Feb 20, 2009 at 02:05:08PM -0600, Matt Sealey wrote:
> >> On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder <iws@ovro.caltech.edu> wrote:
> >> > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
> >> >
> >> > I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you
> >> > want. They don't change byte ordering.
> >>
> >> Are they guaranteed to only do 32-bit, aligned accesses?
> >>
> >
> > I don't think so. I certainly wouldn't count on anything better than a
> > byte-by-byte memcpy.
> >
> >> I made some cheats on my CPLD to ignore byte enables and so on,
> >> because it makes the design cleaner and easier to read (for students)
> >> plus, saves a ton of logic cells. It's totally within the PCI
> >> standard, but it means if you do a byte read memcpy() you get.. very
> >> weird results (i.e. not great).
> >>
> >
> > Right, I understand how that works :)
> >
> > Some usage of cscope shows that __raw_readl() might be what you want,
> > as well as __raw_writel() for writing. I'm not sure it is universally
> > available, but maybe they are.
> >
> > The comment on PowerPC says "Non ordered and non-swapping "raw"
> > accessors". Looks about right. ARM's implementation uses them to
> > implement ioread32() and friends by adding byteswapping.
>
> Am I correct in saying that cpu_to_le32 and le32_to_cpu are the
> functions/macros I need to use to do byte swapping to make everything
> go little endian (and back again when I read them back in the kernel)?
>
> Or is there some cleverer way already implemented in the kernel?
>
I would say that the __raw_readl() reads in cpu order. If you wanted to
convert that to le32, you'd use cpu_to_le32().
Ira
^ permalink raw reply
* ioremap fails for a device in PCI-E slot on AMCC katmai board
From: Shubhada Pugaonkar @ 2009-02-21 1:35 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 13338 bytes --]
Hi
I am trying to get Chelsio's 10G T3 adapter working on Katmai board.
When I load the driver (or have it built in to the kernel) I get
following error.
-bash-3.2# insmod cxgb3.ko
__ioremap(): phys addr 0x8000000 is RAM lr e2f21030
cxgb3 0000:11:00.0: cannot map device registers
cxgb3: probe of 0000:11:00.0 failed with error -12
I also tried another pci-e card just as an experiment and that also
failed
myri10ge: Version 1.4.3-1.378
myri10ge 0000:11:00.0: enabling device (0000 -> 0002)
myri10ge 0000:11:00.0: ioremap failed for 16777216 bytes at 0x0
I am using 2.6.28 kernel with katmai config file from kernel.
I have also tried the latest denx kernel which gave same results.
Following are the values when I added some printks.
cxgb3: mmio_start 0x08000000, mmio_len 4096, dev reg addr
0x00000000
kernel: __ioremap:high mem, virtual 0xe0000000 physical 0x20000000
Looks like the mmio_start value is low hence the call fails. This does
not seem to be a driver issue.
Is there something that I am missing in kernel config? any other hints
on how to overcome this problem?
Below is the boot log, lspci output, and the snippets of the code where
failure happens. config file is attached.
Please let me know if any other information is required.
Thanks
Shubhada
****************************************************
cxgb3_main.c:
mmio_start = pci_resource_start(pdev, 0);
mmio_len = pci_resource_len(pdev, 0);
ai = t3_get_adapter_info(ent->driver_data);
.....................
adapter->regs = ioremap_nocache(mmio_start, mmio_len);
if (!adapter->regs) {
dev_err(&pdev->dev,
"cannot map device registers\n");
err = -ENOMEM;
}
****************************************************
arch/powerpc/mm/pgtable_32.c
/*
* Don't allow anybody to remap normal RAM that we're using.
* mem_init() sets high_memory so only do the check after that.
*/
if (mem_init_done && (p < virt_to_phys(high_memory))) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %p\n",
(unsigned long long)p,
__builtin_return_address(0));
return NULL;
}
****************************************************
lspci output
0000:11:00.0 Class 0200: Unknown device 1425:0030
Subsystem: Unknown device 1425:0001
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 18
Region 0: Memory at e08000000 (64-bit, non-prefetchable)
[size=4K]
Region 2: Memory at e00000000 (64-bit, non-prefetchable)
[size=128M]
Region 4: Memory at e08001000 (64-bit, non-prefetchable)
[size=4K]
[virtual] Expansion ROM at e0c000000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] Message Signalled Interrupts: Mask- 64bit+
Queue=0/5 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [58] Express Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0,
ExtTag+
Device: Latency L0s <64ns, L1 <1us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal-
Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x8, ASPM L0s L1,
Port 0
Link: Latency L0s unlimited, L1 unlimited
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x8
Capabilities: [94] Vital Product Data
Capabilities: [9c] MSI-X: Enable- Mask- TabSize=32
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [100] Device Serial Number 01-00-00-00-01-00-00-00
Capabilities: [300] Advanced Error Reporting
****************************************************
Following is the log while booting the kernel.
Using PowerPC 44x Platform machine description
Linux version 2.6.28 (root@california) (gcc version 4.2.2) #22 Fri Feb
20 15:48:41 PST 2009
console [udbg0] enabled
setup_arch: bootmem
arch: exit
Zone PFN ranges:
DMA 0x00000000 -> 0x00020000
Normal 0x00020000 -> 0x00020000
HighMem 0x00020000 -> 0x00020000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00020000
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
130048
Kernel command line: root=/dev/nfs rw
nfsroot=10.192.165.106:/opt/eldk4.1/eldk4.2/ppc_4xx,tcp,v3
ip=10.192.164.166:10.192.165.106:10.192.160.10
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
UIC3 (32 IRQ sources) at DCR 0xf0
PID hash table entries: 2048 (order: 11, 8192 bytes)
clocksource: timebase mult[500000] shift[22] registered
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 516224k/524288k available (2796k kernel code, 7640k reserved,
128k data, 129k bss, 144k init)
SLUB: Genslabs=10, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Calibrating delay loop... 1597.44 BogoMIPS (lpj=3194880)
Mount-cache hash table entries: 512
net_namespace: 288 bytes
NET: Registered protocol family 16
PCIE0: Checking link...
PCIE0: Device detected, waiting for link...
PCIE0: link is up !
PCI host bridge /plb/pciex@d00000000 (primary) ranges:
MEM 0x0000000e00000000..0x0000000e7fffffff -> 0x0000000080000000
IO 0x0000000f80000000..0x0000000f8000ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCIE0: successfully set as root-complex
PCIE1: Checking link...
PCIE1: No device detected.
PCI host bridge /plb/pciex@d20000000 (primary) ranges:
MEM 0x0000000e80000000..0x0000000effffffff -> 0x0000000080000000
IO 0x0000000f80010000..0x0000000f8001ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCIE1: successfully set as root-complex
PCIE2: Checking link...
PCIE2: No device detected.
PCI host bridge /plb/pciex@d40000000 (primary) ranges:
MEM 0x0000000f00000000..0x0000000f7fffffff -> 0x0000000080000000
IO 0x0000000f80020000..0x0000000f8002ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCIE2: successfully set as root-complex
PCI host bridge /plb/pci@c0ec00000 (primary) ranges:
MEM 0x0000000d80000000..0x0000000dffffffff -> 0x0000000080000000
IO 0x0000000c08000000..0x0000000c0800ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:10:00.0
pci 0000:11:00.0: PME# supported from D0 D3hot
pci 0000:11:00.0: PME# disabled
PCI: Hiding 4xx host bridge resources 0001:20:00.0
PCI: Hiding 4xx host bridge resources 0002:30:00.0
pci 0000:10:00.0: PCI bridge, secondary bus 0000:11
pci 0000:10:00.0: IO window: disabled
pci 0000:10:00.0: MEM window: 0x80000000-0x8bffffff
pci 0000:10:00.0: PREFETCH window: 0x0000008c000000-0x0000008c0fffff
pci 0001:20:00.0: PCI bridge, secondary bus 0001:21
pci 0001:20:00.0: IO window: disabled
pci 0001:20:00.0: MEM window: disabled
pci 0001:20:00.0: PREFETCH window: disabled
pci 0002:30:00.0: PCI bridge, secondary bus 0002:31
pci 0002:30:00.0: IO window: disabled
pci 0002:30:00.0: MEM window: disabled
pci 0002:30:00.0: PREFETCH window: disabled
bus: 10 index 0 io port: [0xff080000-0xff08ffff]
bus: 10 index 1 mmio: [0xe00000000-0xe7fffffff]
bus: 11 index 0 mmio: [0xff080000-0xff080fff]
bus: 11 index 1 mmio: [0xe00000000-0xe0bffffff]
bus: 11 index 2 mmio: [0xe0c000000-0xe0c0fffff]
bus: 11 index 3 mmio: [0x0-0x0]
bus: 20 index 0 io port: [0xff0a0000-0xff0affff]
bus: 20 index 1 mmio: [0xe80000000-0xeffffffff]
bus: 21 index 0 mmio: [0xff0a0000-0xff0a0fff]
bus: 21 index 1 mmio: [0xe00000000-0xe000fffff]
bus: 21 index 2 mmio: [0xe00000000-0xe000fffff]
bus: 21 index 3 mmio: [0x0-0x0]
bus: 30 index 0 io port: [0xff0c0000-0xff0cffff]
bus: 30 index 1 mmio: [0xf00000000-0xf7fffffff]
bus: 31 index 0 mmio: [0xff0c0000-0xff0c0fff]
bus: 31 index 1 mmio: [0xe80000000-0xe800fffff]
bus: 31 index 2 mmio: [0xe80000000-0xe800fffff]
bus: 31 index 3 mmio: [0x0-0x0]
bus: 00 index 0 io port: [0x00-0xffff]
bus: 00 index 1 mmio: [0xd80000000-0xdffffffff]
NET: Registered protocol family 2
IP route cache hash table entries: 16384 (order: 4, 65536 bytes)
TCP established hash table entries: 65536 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
NET: Registered protocol family 1
msgmni has been set to 1009
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
pcieport-driver 0000:10:00.0: found MSI capability
pcieport-driver 0001:20:00.0: found MSI capability
pcieport-driver 0002:30:00.0: found MSI capability
aer: probe of 0000:10:00.0:pcie01 failed with error -38
aer: probe of 0001:20:00.0:pcie01 failed with error -38
aer: probe of 0002:30:00.0:pcie01 failed with error -38
Serial: 8250/16550 driver4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4f0000200 (irq = 19) is a 16550A
console
handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0x4f0000300 (irq = 20) is a 16550A
serial8250.0: ttyS2 at MMIO 0x4f0000600 (irq = 21) is a 16550A
4f0000200.serial: ttyS0 at MMIO 0x4f0000200 (irq = 19) is a 16550A
4f0000300.serial: ttyS1 at MMIO 0x4f0000300 (irq = 20) is a 16550A
4f0000600.serial: ttyS2 at MMIO 0x4f0000600 (irq = 21) is a 16550A
brd: module loaded
Intel(R) PRO/1000 Network Driver - version 7.3.20-k3-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6
e1000e: Copyright (c) 1999-2008 Intel Corporation.
PPC 4xx OCP EMAC driver, version 3.54
MAL v2 /plb/mcmal, 2 TX channels, 1 RX channels
eth0: EMAC-0 /plb/opb/ethernet@10000800, MAC 00:01:73:77:56:64
eth0: found Generic MII PHY (0x01)
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
eth0: link is down
IP-Config: Complete:
device=eth0, addr=10.192.164.166, mask=255.255.240.0,
gw=10.192.160.1,
host=ppcb1, domain=, nis-domain=(none),
bootserver=10.192.165.106, rootserver=10.192.165.106, rootpath=
Looking up port of RPC 100003/3 on 10.192.165.106
eth0: link is up, 100 FDX, pause enabled
Looking up port of RPC 100005/3 on 10.192.165.106
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 144k init
modprobe: FATAL: Could not load /lib/modules/2.6.28/modules.dep: No such
file or directory
modprobe: FATAL: Could not load /lib/modules/2.6.28/modules.dep: No such
file or directory
INIT: version 2.86 booting
Welcome to DENX Embedded Linux Environment
Press 'I' to enter interactive startup.
modprobe: FATAL: Could not load /lib/modules/2.6.28/modules.dep: No such
file or directory
modprobe: FATAL: Could not load /lib/modules/2.6.28/modules.dep: No such
file or directory
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access
method.
Setting clock : Thu Jan 1 01:00:06 CET 1970 [ OK ]
Building the cache [ OK ]
Setting hostname ppcb1: [ OK ]
Mounting local filesystems: [ OK ]
Enabling /etc/fstab swaps: [ OK ]
INIT: Entering runlevel: 3
Entering non-interactive startup
FATAL: Could not load /lib/modules/2.6.28/modules.dep: No such file or
directory
Bringing up loopback interface: [ OK ]
FATAL: Could not load /lib/modules/2.6.28/modules.dep: No such file or
directory
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
Starting rpcbind: [ OK ]
Mounting NFS filesystems: [ OK ]
Mounting other filesystems: [ OK ]
Starting xinetd: [ OK ]
DENX ELDK version 4.2 build 2008-04-01
Linux 2.6.28 on a ppc
[-- Attachment #1.2: Type: text/html, Size: 66233 bytes --]
[-- Attachment #2: config-2.6.28-katmai --]
[-- Type: application/octet-stream, Size: 22967 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.28
# Fri Feb 20 17:18:39 2009
#
# CONFIG_PPC64 is not set
#
# Processor support
#
# CONFIG_6xx is not set
# CONFIG_PPC_85xx is not set
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
CONFIG_44x=y
# CONFIG_E200 is not set
CONFIG_4xx=y
CONFIG_BOOKE=y
CONFIG_PTE_64BIT=y
CONFIG_PHYS_64BIT=y
# CONFIG_PPC_MM_SLICES is not set
CONFIG_NOT_COHERENT_CACHE=y
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
CONFIG_IRQ_PER_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_GPIO=y
# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_PPC_DCR_NATIVE=y
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_PPC_DCR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
CONFIG_CLASSIC_RCU=y
# CONFIG_FREEZER is not set
CONFIG_PPC4xx_PCI_EXPRESS=y
#
# Platform support
#
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PQ2ADS is not set
# CONFIG_BAMBOO is not set
# CONFIG_EBONY is not set
# CONFIG_SAM440EP is not set
# CONFIG_SEQUOIA is not set
# CONFIG_TAISHAN is not set
CONFIG_KATMAI=y
# CONFIG_RAINIER is not set
# CONFIG_WARP is not set
# CONFIG_ARCHES is not set
# CONFIG_CANYONLANDS is not set
# CONFIG_GLACIER is not set
# CONFIG_YOSEMITE is not set
# CONFIG_XILINX_VIRTEX440_GENERIC_BOARD is not set
CONFIG_PPC44x_SIMPLE=y
CONFIG_PPC4xx_GPIO=y
CONFIG_440SPe=y
# CONFIG_IPIC is not set
# CONFIG_MPIC is not set
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
# CONFIG_PPC_RTAS is not set
# CONFIG_MMIO_NVRAM is not set
# CONFIG_PPC_MPC106 is not set
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
# CONFIG_GENERIC_IOMAP is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_FSL_ULI1575 is not set
#
# Kernel options
#
# CONFIG_HIGHMEM is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_SCHED_HRTICK is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_IOMMU_HELPER is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_HAS_WALK_MEMORY=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
CONFIG_RESOURCES_64BIT=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_UNEVICTABLE_LRU=y
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_PROC_DEVICETREE=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="root=/dev/nfs rw nfsroot=10.192.165.106:/opt/eldk4.1/eldk4.2/ppc_4xx,tcp,v3 ip=10.192.164.166:10.192.165.106:10.192.160.1:255.255.240.0:ppcb1:eth0:off console=ttyS0,115200"
CONFIG_EXTRA_TARGETS=""
CONFIG_SECCOMP=y
CONFIG_ISA_DMA_API=y
#
# Bus options
#
CONFIG_ZONE_DMA=y
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_4xx_SOC=y
CONFIG_PPC_PCI_CHOICE=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_SYSCALL=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
# CONFIG_PCIEASPM is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY=y
CONFIG_PCI_DEBUG=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
# CONFIG_HAS_RAPIDIO is not set
#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set
#
# Default settings for advanced configuration options are used
#
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_PAGE_OFFSET=0xc0000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_PHYSICAL_START=0x00000000
CONFIG_TASK_SIZE=0xc0000000
CONFIG_CONSISTENT_START=0xff100000
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_PHONET is not set
# CONFIG_WIRELESS is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
CONFIG_OF_DEVICE=y
CONFIG_OF_GPIO=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=35000
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_XILINX_SYSACE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_PHANTOM is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_C2PORT is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# Enable only one of the two stacks, unless you know what you are doing
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
# CONFIG_MAC_EMUMOUSEBTN is not set
# CONFIG_WINDFARM is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_IBM_NEW_EMAC=y
CONFIG_IBM_NEW_EMAC_RXB=128
CONFIG_IBM_NEW_EMAC_TXB=64
CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32
CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256
CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0
# CONFIG_IBM_NEW_EMAC_DEBUG is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
CONFIG_IBM_NEW_EMAC_EMAC4=y
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
# CONFIG_NET_PCI is not set
CONFIG_B44=y
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_B44_PCI=y
# CONFIG_ATL2 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
CONFIG_E1000E=y
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_JME is not set
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_ENIC is not set
# CONFIG_IXGBE is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
CONFIG_MYRI10GE=y
# CONFIG_NETXEN_NIC is not set
# CONFIG_NIU is not set
# CONFIG_MLX4_EN is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_TEHUTI is not set
# CONFIG_BNX2X is not set
# CONFIG_QLGE is not set
# CONFIG_SFC is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_IWLWIFI_LEDS is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
# CONFIG_INPUT is not set
#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
# CONFIG_VT is not set
CONFIG_DEVKMEM=y
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_PCI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_GEN_RTC is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
# CONFIG_I2C is not set
# CONFIG_SPI is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
# CONFIG_DEBUG_GPIO is not set
# CONFIG_GPIO_SYSFS is not set
#
# Memory mapped GPIO expanders:
#
# CONFIG_GPIO_XILINX is not set
#
# I2C GPIO expanders:
#
#
# PCI GPIO expanders:
#
# CONFIG_GPIO_BT8XX is not set
#
# SPI GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_THERMAL_HWMON is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
CONFIG_SSB=y
CONFIG_SSB_SPROM=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
# CONFIG_SSB_B43_PCI_BRIDGE is not set
# CONFIG_SSB_SILENT is not set
# CONFIG_SSB_DEBUG is not set
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_REGULATOR is not set
#
# Multimedia devices
#
#
# Multimedia core support
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_VIDEO_MEDIA is not set
#
# Multimedia drivers
#
CONFIG_DAB=y
#
# Graphics support
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_SOUND is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
#
# Enable Host or Gadget support to see Inventra options
#
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may also be needed;
#
# CONFIG_USB_GADGET is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_UIO is not set
# CONFIG_STAGING is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_FILE_LOCKING=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_REGISTER_V4 is not set
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_NLS is not set
# CONFIG_DLM is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_HAVE_LMB=y
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_HAVE_FUNCTION_TRACER=y
#
# Tracers
#
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_CONTEXT_SWITCH_TRACER is not set
# CONFIG_BOOT_TRACER is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_DYNAMIC_PRINTK_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_CODE_PATCHING_SELFTEST is not set
# CONFIG_FTR_FIXUP_SELFTEST is not set
# CONFIG_MSI_BITMAP_SELFTEST is not set
# CONFIG_XMON is not set
# CONFIG_IRQSTACKS is not set
# CONFIG_BDI_SWITCH is not set
# CONFIG_PPC_EARLY_DEBUG is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
# CONFIG_CRYPTO_FIPS is not set
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
CONFIG_CRYPTO_PCBC=y
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_LZO is not set
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
# CONFIG_PPC_CLOCK is not set
# CONFIG_VIRTUALIZATION is not set
^ permalink raw reply
* how to fix 405ex SDR0_MFR_ECS
From: zhong wang @ 2009-02-21 3:30 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
hello all
SDR0_MFR_ECS is defined for 440xx,now want to change it for 405ex ,but i donnot known what means in /drivers/net/ibm_newemac/core.c line 2374 to 2385 ? plese help me
leo
2009:02:21
___________________________________________________________
好玩贺卡等你发，邮箱贺卡全新上线！
http://card.mail.cn.yahoo.com/
[-- Attachment #2: Type: text/html, Size: 1275 bytes --]
^ permalink raw reply
* Re: PCI reading without endian conversion
From: Benjamin Herrenschmidt @ 2009-02-21 4:33 UTC (permalink / raw)
To: Ira Snyder; +Cc: PowerPC dev list
In-Reply-To: <20090220235054.GA27349@ovro.caltech.edu>
> > Am I correct in saying that cpu_to_le32 and le32_to_cpu are the
> > functions/macros I need to use to do byte swapping to make everything
> > go little endian (and back again when I read them back in the kernel)?
> >
> > Or is there some cleverer way already implemented in the kernel?
> >
>
> I would say that the __raw_readl() reads in cpu order. If you wanted to
> convert that to le32, you'd use cpu_to_le32().
Beware that __raw_* forms also don't have memory barriers.
In general, you know what byte order your device uses (which is often
little endian) and you use the appropriate ioread32{be}. Now, for
userspace, you simply need to mimmic those accessors.
Ben.
^ permalink raw reply
* Re: ioremap fails for a device in PCI-E slot on AMCC katmai board
From: Benjamin Herrenschmidt @ 2009-02-21 4:38 UTC (permalink / raw)
To: Shubhada Pugaonkar; +Cc: linuxppc-dev
In-Reply-To: <8A71B368A89016469F72CD08050AD33402D57562@maui.asicdesigners.com>
On Fri, 2009-02-20 at 17:35 -0800, Shubhada Pugaonkar wrote:
> ****************************************************
>
> cxgb3_main.c:
>
> mmio_start = pci_resource_start(pdev, 0);
>
> mmio_len = pci_resource_len(pdev, 0);
>
> ai = t3_get_adapter_info(ent->driver_data);
>
My bet is that mmio_start is an unsigned long instead of a
resource_size_t and thus gets cropped (ie, driver bug).
(/me goes read the source)
Yes, indeed, that's the problem. Change the definition
of mmio_start and mmio_len to resource_size_t, that should
fix it. I suspect the other driver has the same problem.
Note: They will still get cropped, I suspect, when copied
to netdev->mem_start, nothing much to do here, but fortunately
those fields aren't used.
BTW. If you do patches to fix those drivers, please send them
to the netdev@vger.kernel.org mailing list too.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 02/11] sdhci: Add support for bus-specific IO memory accessors
From: Pierre Ossman @ 2009-02-21 15:57 UTC (permalink / raw)
To: avorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090213144039.GA19572@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]
On Fri, 13 Feb 2009 17:40:39 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> No, on eSDHC the registers are big-endian, 32-bit width, with, for
> example, two 16-bit "logical" registers packed into it.
>
> That is,
>
> 0x4 0x5 0x6 0x7
> |~~~~~~~~:~~~~~~~~|
> | BLKCNT : BLKSZ |
> |________:________|
> 31 0
>
> ( The register looks wrong, right? BLKSZ should be at 0x4. But imagine
> that you swapped bytes in this 32 bit register... then the registers
> and their byte addresses will look normal. )
>
> So if we try to issue readw(SDHCI_BLOCK_SIZE), i.e. readw(0x4):
>
> - We'll read BLKCNT, while we wanted BLKSZ. This is because the
> address bits should be translated before we try word or byte
> reads/writes.
> - On powerpc read{l,w}() convert the read value from little-endian
> to big-endian byte order, which is wrong for our case (the
> register is big-endian already).
>
> That means that we have to convert address, but we don't want to
> convert the result of read/write ops.
>
*cries*
Now this is just incredibly horrible. Why the hell did they try to use
the sdhci interface and then do stupid things like this?
> > > +static inline void sdhci_writel(struct sdhci_host *host, u32 val, int reg)
> > > +{
> > > + host->writel(host, val, reg);
> > > +}
> >
> > Having to override these are worst case scenario
>
> Hm. It's not a worst case scenario, it's a normal scenario for
> eSDHC. Why should we treat eSDHC as a second-class citizen?
>
Because it's complete and utter crap. Freescale has completely ignored
the basic register interface requirements of the SDHCI spec. Treating
eSDHC as a second-class citizen is generous IMO.
> > as far as I'm
> > concerned, so I'd prefer something like:
> >
> > if (!host->ops->writel)
> > writel(host->ioaddr + reg, val);
> > else
> > host->ops->writel(host, val, reg);
>
> Surely the overhead isn't measurable... but why we purposely make
> things worse?
>
We can most likely do some micro-optimisation do make the compare part
cheaper, but the point was to avoid a function call for all the
properly implemented controllers out there. We could have a flag so
that it only has to check host->flags, which will most likely be in the
cache anyway.
Overhead for eSDHC is not a concern in my book, what is interesting is
how much this change slows things down for other controllers.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 03/13] sdhci: Split card-detection IRQs management from sdhci_init()
From: Pierre Ossman @ 2009-02-21 15:58 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel, Pierre Ossman
In-Reply-To: <20090213144715.GC23889@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]
On Fri, 13 Feb 2009 17:47:15 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> Card detection interrupts should be handled separately as they should
> not be enabled before mmc_add_host() returns and should be disabled
> before calling mmc_remove_host(). The same is for suspend and resume
> routines.
>
> sdhci_init() no longer enables card-detection irqs. Instead, two new
> functions implemented: sdhci_enable_card_detection() and
> sdhci_disable_card_detection().
>
> New sdhci_reinit() call implemented to behave the same way as the old
> sdhci_init().
>
> Also, this patch implements and uses few new helpers to manage IRQs in
> a more conveinient way, that is:
>
> - sdhci_clear_set_irqs()
> - sdhci_unmask_irqs()
> - sdhci_mask_irqs()
> - SDHCI_INT_ALL_MASK constant
>
> sdhci_enable_sdio_irq() converted to these new helpers, plus the
> helpers will be used by the subsequent patches.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
That's a lot of indirection, but fair enough. :)
> @@ -1792,6 +1832,8 @@ int sdhci_add_host(struct sdhci_host *host)
>
> mmc_add_host(mmc);
>
> + sdhci_enable_card_detection(host);
> +
> printk(KERN_INFO "%s: SDHCI controller on %s [%s] using %s%s\n",
> mmc_hostname(mmc), host->hw_name, dev_name(mmc_dev(mmc)),
> (host->flags & SDHCI_USE_ADMA)?"A":"",
There is a small race here, but I'm not sure it's worth dealing with.
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index e907441..45c8309 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -124,6 +124,10 @@
> SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL | \
> SDHCI_INT_DATA_TIMEOUT | SDHCI_INT_DATA_CRC | \
> SDHCI_INT_DATA_END_BIT)
> +#define SDHCI_INT_ALL_MASK (SDHCI_INT_CMD_MASK | SDHCI_INT_DATA_MASK | \
> + SDHCI_INT_CARD_INSERT | SDHCI_INT_CARD_REMOVE | \
> + SDHCI_INT_CARD_INT | SDHCI_INT_ERROR | SDHCI_INT_BUS_POWER | \
> + SDHCI_INT_ACMD12ERR | SDHCI_INT_ADMA_ERROR)
>
In the context this is used, why not just use (unsigned)-1?
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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