* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Manish Ahuja @ 2008-02-11 18:29 UTC (permalink / raw)
To: Paul Mackerras
Cc: Manish Ahuja, ppc-dev, linasvepstas, Larry Kessler,
Michael Strosaker
In-Reply-To: <18346.21469.512910.93325@cargo.ozlabs.ibm.com>
Sorry,
I think i sent the wrong patch file, it shouldn't have my printk statement in there. Let me re-send
the correct file and let me test it once more to make sure it does the right thing.
-Manish
Paul Mackerras wrote:
> Manish Ahuja writes:
>
>> Initial patch for reserving memory in early boot, and freeing it later.
>> If the previous boot had ended with a crash, the reserved memory would contain
>> a copy of the crashed kernel data.
>
> [snip]
>
>> +static void __init reserve_crashed_mem(void)
>> +{
>> + unsigned long base, size;
>> +
>> + if (phyp_dump_info->phyp_dump_is_active) {
>> + /* Reserve *everything* above RMR. We'll free this real soon.*/
>> + base = PHYP_DUMP_RMR_END;
>> + size = lmb_end_of_DRAM() - base;
>> +
>> + /* XXX crashed_ram_end is wrong, since it may be beyond
>> + * the memory_limit, it will need to be adjusted. */
>> + lmb_reserve(base, size);
>> +
>> + phyp_dump_info->init_reserve_start = base;
>> + phyp_dump_info->init_reserve_size = size;
>> + }
>> + else {
>> + size = phyp_dump_info->cpu_state_size +
>> + phyp_dump_info->hpte_region_size +
>> + PHYP_DUMP_RMR_END;
>> + base = lmb_end_of_DRAM() - size;
>> + printk(KERN_ERR "Manish reserve regular kernel space is %ld %ld\n", base, size);
>> + lmb_reserve(base, size);
>
> This is still reserving memory even on systems that aren't running on
> pHyp at all. Please rework this so that no memory is reserved if the
> system doesn't support phyp-assisted dump.
>
> Paul.
^ permalink raw reply
* looking for 3U system with FPGA support
From: Nicholas Mc Guire @ 2008-02-11 19:31 UTC (permalink / raw)
To: linuxppc-embedded
Hi !
hope this is ok for this list - after searching quite some time for a
3U board with a PPC on it + more or less any FPGA - I only could find the
MEN F12 (5200) and F13 (8540) - does naybody know of other 3U systems ?
Basically a FPGA based system like an ML405 would be of interest but I
could not locate any 3U products.
Roughly:
PPC roughly equivalent to a 500 MHz PIII/Celeron
2++ Ethernets
2 Seriell
4++ GPIO (via FPGA)
Linux available
U-boot if posible
Any pointers would be appreciated.
thx!
hofrat
^ permalink raw reply
* [PATCH 1/5 v3] Tsi108_eth: add missing linking to driver data
From: Alex Bounine @ 2008-02-11 19:33 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Bug fix for tsi108_eth network driver.
This patch adds missing linking to driver data.
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
14:30:04.000000000 -0500
@@ -1629,6 +1629,7 @@ tsi108_init_one(struct platform_device *
goto register_fail;
}
+ platform_set_drvdata(pdev, dev);
printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n",
dev->name, print_mac(mac, dev->dev_addr));
#ifdef DEBUG
^ permalink raw reply
* [PATCH 2/5 v3] Tsi108_eth: fix detection of 1000Mb mode
From: Alex Bounine @ 2008-02-11 19:35 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Bug fix for tsi108_eth network driver.
This patch fixes a problem with detection of 1000Mb speed.
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06 15:09:19.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
15:34:12.000000000 -0500
@@ -1287,6 +1287,7 @@ static void tsi108_init_phy(struct net_d
spin_lock_irqsave(&phy_lock, flags);
}
+ data->mii_if.supports_gmii = mii_check_gmii_support(&data->mii_if);
printk(KERN_DEBUG "PHY_STAT reg contains %08x\n", phyval);
data->phy_ok = 1;
data->init_media = 1;
@@ -1584,7 +1585,6 @@ tsi108_init_one(struct platform_device *
data->mii_if.phy_id = einfo->phy;
data->mii_if.phy_id_mask = 0x1f;
data->mii_if.reg_num_mask = 0x1f;
- data->mii_if.supports_gmii = mii_check_gmii_support(&data->mii_if);
data->phy = einfo->phy;
data->phy_type = einfo->phy_type;
^ permalink raw reply
* [PATCH 3/5 v3] Tsi108_eth: remove not needed code
From: Alex Bounine @ 2008-02-11 19:35 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Code clean-up for tsi108_eth network driver.
This patch removes not needed dummy read and the corresponding comment.
The PHY logic requires two reads from the status register to get
current link status. This is done correctly inside mii_check_media().
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06 15:47:35.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
15:54:14.000000000 -0500
@@ -297,18 +297,11 @@ static void tsi108_check_phy(struct net_
u32 speed;
unsigned long flags;
- /* Do a dummy read, as for some reason the first read
- * after a link becomes up returns link down, even if
- * it's been a while since the link came up.
- */
-
spin_lock_irqsave(&phy_lock, flags);
if (!data->phy_ok)
goto out;
- tsi108_read_mii(data, MII_BMSR);
-
duplex = mii_check_media(&data->mii_if, netif_msg_link(data),
data->init_media);
data->init_media = 0;
^ permalink raw reply
* [PATCH 4/5 v3] Tsi108_eth: fix link recovery after disconnect
From: Alex Bounine @ 2008-02-11 19:36 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Bug fix for tsi108_eth network driver.
This patch fixes a problem with link recovery after connection was lost.
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06 16:16:00.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
16:57:41.000000000 -0500
@@ -338,22 +338,21 @@ static void tsi108_check_phy(struct net_
TSI_WRITE(TSI108_MAC_CFG2, mac_cfg2_reg);
TSI_WRITE(TSI108_EC_PORTCTRL, portctrl_reg);
+ }
- if (data->link_up == 0) {
- /* The manual says it can take 3-4 usecs for the speed change
- * to take effect.
- */
- udelay(5);
-
- spin_lock(&data->txlock);
- if (is_valid_ether_addr(dev->dev_addr) && data->txfree)
- netif_wake_queue(dev);
+ if (data->link_up == 0) {
+ /* The manual says it can take 3-4 usecs for the speed change
+ * to take effect.
+ */
+ udelay(5);
- data->link_up = 1;
- spin_unlock(&data->txlock);
- }
- }
+ spin_lock(&data->txlock);
+ if (is_valid_ether_addr(dev->dev_addr) && data->txfree)
+ netif_wake_queue(dev);
+ data->link_up = 1;
+ spin_unlock(&data->txlock);
+ }
} else {
if (data->link_up == 1) {
netif_stop_queue(dev);
@@ -1267,12 +1266,11 @@ static void tsi108_init_phy(struct net_d
* PHY_STAT register before the link up status bit is set.
*/
- data->link_up = 1;
+ data->link_up = 0;
while (!((phyval = tsi108_read_mii(data, MII_BMSR)) &
BMSR_LSTATUS)) {
if (i++ > (MII_READ_DELAY / 10)) {
- data->link_up = 0;
break;
}
spin_unlock_irqrestore(&phy_lock, flags);
^ permalink raw reply
* [PATCH 5/5 v3] Tsi108_eth: Add ethtool support
From: Alex Bounine @ 2008-02-11 19:36 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Add ethtool support to tsi108_eth network driver.
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06 17:10:53.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
18:09:43.000000000 -0500
@@ -36,6 +36,7 @@
#include <linux/net.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
@@ -1519,12 +1520,46 @@ static void tsi108_init_mac(struct net_d
TSI_WRITE(TSI108_EC_INTMASK, ~0);
}
+static int tsi108_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct tsi108_prv_data *data = netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ spin_lock_irqsave(&data->txlock, flags);
+ rc = mii_ethtool_gset(&data->mii_if, cmd);
+ spin_unlock_irqrestore(&data->txlock, flags);
+
+ return rc;
+}
+
+static int tsi108_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct tsi108_prv_data *data = netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ spin_lock_irqsave(&data->txlock, flags);
+ rc = mii_ethtool_sset(&data->mii_if, cmd);
+ spin_unlock_irqrestore(&data->txlock, flags);
+
+ return rc;
+}
+
static int tsi108_do_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct tsi108_prv_data *data = netdev_priv(dev);
+ if (!netif_running(dev))
+ return -EINVAL;
return generic_mii_ioctl(&data->mii_if, if_mii(rq), cmd, NULL);
}
+static const struct ethtool_ops tsi108_ethtool_ops = {
+ .get_link = ethtool_op_get_link,
+ .get_settings = tsi108_get_settings,
+ .set_settings = tsi108_set_settings,
+};
+
static int
tsi108_init_one(struct platform_device *pdev)
{
@@ -1589,6 +1624,7 @@ tsi108_init_one(struct platform_device *
dev->get_stats = tsi108_get_stats;
netif_napi_add(dev, &data->napi, tsi108_poll, 64);
dev->do_ioctl = tsi108_do_ioctl;
+ dev->ethtool_ops = &tsi108_ethtool_ops;
/* Apparently, the Linux networking code won't use scatter-gather
* if the hardware doesn't do checksums. However, it's faster
^ permalink raw reply
* Re: looking for 3U system with FPGA support
From: Ron Sass @ 2008-02-11 19:39 UTC (permalink / raw)
To: Nicholas Mc Guire; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.58.0802111025100.1608@vlab.hofr.at>
I'm not sure why you are keen on a 3U form factor but
the Xilinx ML-410 board is an ATX form factor and fits
in various 1U chassis. We have a couple in off-the-shelf
chassis and some in a chassis that Xilinx sells.
http://www.xilinx.com/ml410
The chassis is part number HW-MLX10-RACK-G. Coincidentally,
the board has all of the features you mentioned.
Ron
>
> Hi !
>
> hope this is ok for this list - after searching quite some time for a
> 3U board with a PPC on it + more or less any FPGA - I only could find the
> MEN F12 (5200) and F13 (8540) - does naybody know of other 3U systems ?
>
> Basically a FPGA based system like an ML405 would be of interest but I
> could not locate any 3U products.
>
> Roughly:
>
> PPC roughly equivalent to a 500 MHz PIII/Celeron
> 2++ Ethernets
> 2 Seriell
> 4++ GPIO (via FPGA)
> Linux available
> U-boot if posible
>
> Any pointers would be appreciated.
>
> thx!
> hofrat
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 3/5 v3] Tsi108_eth: remove not needed code
From: Jeff Garzik @ 2008-02-11 19:50 UTC (permalink / raw)
To: Alex Bounine; +Cc: netdev, linuxppc-dev
In-Reply-To: <d5f62df20802111135q36e47070w611291b2cea2253e@mail.gmail.com>
Alex Bounine wrote:
> Code clean-up for tsi108_eth network driver.
> This patch removes not needed dummy read and the corresponding comment.
> The PHY logic requires two reads from the status register to get
> current link status. This is done correctly inside mii_check_media().
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> ---
>
> diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
> linux-2.6.24-fix/drivers/net/tsi108_eth.c
> --- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06 15:47:35.000000000 -0500
> +++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
> 15:54:14.000000000 -0500
> @@ -297,18 +297,11 @@ static void tsi108_check_phy(struct net_
> u32 speed;
> unsigned long flags;
>
> - /* Do a dummy read, as for some reason the first read
> - * after a link becomes up returns link down, even if
> - * it's been a while since the link came up.
> - */
> -
> spin_lock_irqsave(&phy_lock, flags);
>
> if (!data->phy_ok)
> goto out;
>
> - tsi108_read_mii(data, MII_BMSR);
> -
> duplex = mii_check_media(&data->mii_if, netif_msg_link(data),
> data->init_media);
applied all five, but each one was still corrupted according to git-am.
I was able to apply four via patch(1), which is more forgiving, but
there are still email problems.
As as you can see from the above quoted (last) line, your email client
is still word-wrapping patches.
^ permalink raw reply
* MPC8272 FCC2 MDIO on Port D and FS_ENET
From: Show Man @ 2008-02-11 19:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2516 bytes --]
As part of the port of our device (MPC8271 based) from 2.6.23 using arch/ppc to 2.6.24 arch/powerpc, I've hit a road block in the past few days in trying to make FS_ENET (freescale)/CPM2 recognize the BCM5221 PHY, which means I can't get eth0 up and running.
It worked fine in 2.26.23 arch/ppc when configured as FEC_ENET.
As far as I can tell, the "dts" is fine for FCC2 (see below), with the proper pins connected to the device/phy:
mdio@10d60 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <10d60 14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <1d>;
fsl,mdc-pin = <17>;
PHY0: ethernet-phy@0 {
interrupt-parent = <&PIC>;
interrupts = <31 8>;
reg = <4>;
device_type = "ethernet-phy";
};
};
ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11320 20 8500 100 113b0 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <21 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <16200300>;
};
During my debugging, it appears to be that the PHY is not detected during
drivers/net/phy/phy_device.c: get_phy_device(..)
Basically, the phy_id is 0xFFFFFFFF.
I'm going to try to put a probe on the MDIO/MDC lines later on, but I was wondering whether anyone would have any ideas as to what could be wrong.
thanks
---------------------------------
Looking for the perfect gift? Give the gift of Flickr!
[-- Attachment #2: Type: text/html, Size: 7730 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix for Freescale ppc cores: major revision detection
From: Martin Langer @ 2008-02-11 20:29 UTC (permalink / raw)
To: linuxppc-dev
On Mon, Feb 11, 2008 at 09:01:03AM -0600, Kumar Gala wrote:
>
> On Feb 9, 2008, at 11:47 AM, Martin Langer wrote:
>
> >Ppc cores by Freescale are using the configuration field instead of
> >the
> >major revision field for their major revision number. Those field
> >definitions come from include/asm-powerpc/reg.h.
> >
> >Look at the pdf below and you will see that PVR_MAJ() does a wrong
> >shift
> >for ppc cores by Freescale. This patch fixes it.
> >
> >http://www.freescale.com/files/archives/doc/support_info/PPCPVR.pdf
>
> This doc doesn't encompass the e500/book-e cores that don't follow the
> same pattern.
>
> The code should probably be something like:
>
> #ifdef CONFIG_FSL_BOOKE
> maj = PVR_MAJ(pvr);
> #else
> maj = (pvr >> 8) & 0xff;
> #endif
Thanks for the hint. Inspired by that I did the logic the other way
round. So we have the same default cases as we had before and
additionally it will fit for the cores mentioned in the doc.
--- arch/powerpc/kernel/setup-common.c.ORIGINAL 2008-02-08 22:22:56.000000000 +0100
+++ arch/powerpc/kernel/setup-common.c 2008-02-11 20:54:37.000000000 +0100
@@ -241,8 +241,21 @@
/* If we are a Freescale core do a simple check so
* we dont have to keep adding cases in the future */
if (PVR_VER(pvr) & 0x8000) {
- maj = PVR_MAJ(pvr);
- min = PVR_MIN(pvr);
+ switch (PVR_VER(pvr)) {
+ case 0x8000: /* 7441/7450/7451, Vger */
+ case 0x8001: /* 7445/7455, Apollo 6 */
+ case 0x8002: /* 7447/7457, Apollo 7 */
+ case 0x8003: /* 7447A, Apollo 7 PM */
+ case 0x8004: /* 7448, Apollo 8 */
+ case 0x800c: /* 7410, Nitro */
+ maj = ((pvr >> 8) & 0xF);
+ min = PVR_MIN(pvr);
+ break;
+ default: /* e500/book-e */
+ maj = PVR_MAJ(pvr);
+ min = PVR_MIN(pvr);
+ break;
+ }
} else {
switch (PVR_VER(pvr)) {
case 0x0020: /* 403 family */
^ permalink raw reply
* [PATCH 1/2] powerpc: publish 85xx soc dts entries as of_device
From: Dave Jiang @ 2008-02-11 20:32 UTC (permalink / raw)
To: galak, linuxppc-dev
Publish the devices listed in dts under SOC as of_device just like what
mpc85xx_mds platforms do. The 85xx cds and ads platforms currently do not
export the devices in dts as of_device.
The memory controller, L2 cache-controller, and the PCI controller(s) are
published as of_device so the mpc85xx EDAC driver can claim them for usage.
Signed-off-by: Dave Jiang <djiang@mvista.com>
---
commit 187841bf9dff25e4ac1a7174daa55bb036c724b1
tree 3206ffbbfc5075d195345281f72f7b52f060b41b
parent a99824f327c748b2753f4fa570eb1fefcd6a9c4d
author Dave Jiang <djiang@mvista.com> Mon, 11 Feb 2008 12:51:33 -0700
committer Dave Jiang <djiang@blade.(none)> Mon, 11 Feb 2008 12:51:33 -0700
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 19 +++++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 19 +++++++++++++++++++
2 files changed, 38 insertions(+), 0 deletions(-)
mpc85xx EDAC driver is in mainline kernel now
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index 4e03050..024393c 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -26,6 +26,8 @@
#include <asm/mpic.h>
#include <mm/mmu_decl.h>
#include <asm/udbg.h>
+#include <asm/of_device.h>
+#include <asm/of_platform.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
@@ -249,6 +251,23 @@ static int __init mpc85xx_ads_probe(void)
return of_flat_dt_is_compatible(root, "MPC85xxADS");
}
+static struct of_device_id mpc85xx_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ {},
+};
+
+static int __init mpc85xx_publish_devices(void)
+{
+ if (!machine_is(mpc85xx_ads))
+ return 0;
+
+ of_platform_bus_probe(NULL, mpc85xx_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc85xx_publish_devices);
+
define_machine(mpc85xx_ads) {
.name = "MPC85xx ADS",
.probe = mpc85xx_ads_probe,
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 8b1de78..8525882 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -42,6 +42,8 @@
#include <asm/udbg.h>
#include <asm/mpic.h>
#include <asm/i8259.h>
+#include <asm/of_device.h>
+#include <asm/of_platform.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
@@ -335,6 +337,23 @@ static int __init mpc85xx_cds_probe(void)
return of_flat_dt_is_compatible(root, "MPC85xxCDS");
}
+static struct of_device_id mpc85xx_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ {},
+};
+
+static int __init mpc85xx_publish_devices(void)
+{
+ if (!machine_is(mpc85xx_cds))
+ return 0;
+
+ of_platform_bus_probe(NULL, mpc85xx_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc85xx_publish_devices);
+
define_machine(mpc85xx_cds) {
.name = "MPC85xx CDS",
.probe = mpc85xx_cds_probe,
^ permalink raw reply related
* [PATCH 2/2] powerpc: create mpc85xx pci err platform device for EDAC
From: Dave Jiang @ 2008-02-11 20:34 UTC (permalink / raw)
To: galak, linuxppc-dev
Creating a platform device for the PCI error registers in order for the
mpc85xx EDAC driver to pick up proper resources. This is to prevent the
EDAC driver from monopolizing the of_device and thus preventing future PCI
code from using the PCI of_device(s).
Signed-off-by: Dave Jiang <djiang@mvista.com>
---
commit 9436d0792f1352e9a034436c82b2229622fc3364
tree 0beeed478786b16cdb33be41ac803f781b8ea0cc
parent 187841bf9dff25e4ac1a7174daa55bb036c724b1
author Dave Jiang <djiang@blade.(none)> Mon, 11 Feb 2008 12:55:45 -0700
committer Dave Jiang <djiang@blade.(none)> Mon, 11 Feb 2008 12:55:45 -0700
arch/powerpc/sysdev/fsl_pci.c | 52 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index bf13c21..c064c91 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -19,6 +19,8 @@
#include <linux/string.h>
#include <linux/init.h>
#include <linux/bootmem.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
#include <asm/io.h>
#include <asm/prom.h>
@@ -27,6 +29,56 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
+#ifdef CONFIG_85xx
+/* setting up 85xx PCI error platform device for EDAC consumption */
+static int __init mpc85xx_pcierr_setup(void)
+{
+ struct device_node *np = NULL;
+ struct of_device *of_dev;
+ struct platform_device *pdev;
+ struct resource res[2];
+ int id = 0;
+ int err;
+
+ for_each_compatible_node(np, "pci", "fsl,mpc8540-pci") {
+ memset(res, 0, sizeof(struct resource) * 2);
+ if (of_address_to_resource(np, 0, &res[0])) {
+ printk(KERN_WARNING "Can't get pci register base!\n");
+ continue;
+ }
+
+ /* move start to where the error registers are */
+ res[0].start += 0xe00;
+
+ of_irq_to_resource(np, 0, &res[1]);
+
+ of_dev = of_find_device_by_node(np);
+ if (!of_dev)
+ return -ENODEV;
+
+ pdev = platform_device_alloc("mpc85xx_pci_err", id++);
+ if (!pdev)
+ return -ENOMEM;
+
+ err = platform_device_add_resources(pdev, res, 2);
+ if (err)
+ goto error;
+
+ pdev->dev.parent = &of_dev->dev;
+
+ err = platform_device_add(pdev);
+ if (err)
+ goto error;
+ }
+ return 0;
+
+error:
+ platform_device_put(pdev);
+ return err;
+}
+late_initcall(mpc85xx_pcierr_setup);
+#endif
+
/* atmu setup for fsl pci/pcie controller */
void __init setup_pci_atmu(struct pci_controller *hose, struct resource *rsrc)
{
^ permalink raw reply related
* Re: MPC8272 FCC2 MDIO on Port D and FS_ENET
From: NM @ 2008-02-11 21:26 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <399508.89089.qm@web32709.mail.mud.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
My problem is solved now after probing the lines, MDC was not showing any activity.
So, after explicitly setting the PD23 (MDC) to : OUTPUT/GPIO in mpc8272_ads_pins and it worked in
I'd previously thought about that, but I was sure that this was being taken care of, but now that I'm thinking of it, I'm questioning my belief.
I think in the fs_enet/mii-bitbang.c: mdio_dir(..) it is supposed to take care of this. But why I had to explictly set it initially beats me. I wonder how this works in standard distribution.
thanks
---------------------------------
Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail
[-- Attachment #2: Type: text/html, Size: 770 bytes --]
^ permalink raw reply
* WARN_ON() hit in fsl bitbanged phy driver
From: Rune Torgersen @ 2008-02-11 21:28 UTC (permalink / raw)
To: linuxppc-dev, netdev
I hit the following WARN_ON when using mii-tools agains a ethernet
interface using a bit-banged mii interface
It is only diplayed once, and does not seem to impact usage at all
Does somebody know what is wrong, and how to fix it?
The PHY is an Intel LXT973
Badness at kernel/softirq.c:139
NIP: c001f8bc LR: c0121170 CTR: c01269d8
REGS: dfaa5ce0 TRAP: 0700 Tainted: P (2.6.24-cpu2)
MSR: 00021032 <ME,IR,DR> CR: 20002222 XER: 20000000
TASK =3D de0c2b40[825] 'mii-tool' THREAD: dfaa4000
GPR00: 00000001 dfaa5d90 de0c2b40 0000782d 00000000 00000005 00000001
0ff6a37c
GPR08: 00000000 c0250000 df86bb60 08000000 80000242 1001aa20 00000000
100aa258
GPR16: 10090000 00000000 10090000 00000000 10070000 100aa170 10010000
bff3bd94
GPR24: 00000003 00000000 00000001 c0123234 0000782d dfaa4000 00000000
df003a00
NIP [c001f8bc] local_bh_enable+0x28/0x9c
LR [c0121170] phy_read+0x5c/0x74
Call Trace:
[dfaa5d90] [dfaa4000] 0xdfaa4000 (unreliable)
[dfaa5da0] [c0121170] phy_read+0x5c/0x74
drivers/net/phy/phy.c:80
[dfaa5dc0] [c012140c] phy_mii_ioctl+0x64/0x170
drivers/net/phy/phy.c:368
[dfaa5de0] [c0125394] fs_ioctl+0x4c/0x8c
[dfaa5e00] [c0143744] dev_ifsioc+0x2e8/0x314
[dfaa5e20] [c0144eb8] dev_ioctl+0x6f4/0x8a8
[dfaa5ea0] [c0136aa8] sock_ioctl+0x1fc/0x21c
[dfaa5ec0] [c00742e0] do_ioctl+0x44/0xa8
[dfaa5ee0] [c00746e8] vfs_ioctl+0x3a4/0x3e8
[dfaa5f10] [c007476c] sys_ioctl+0x40/0x70
[dfaa5f40] [c000edc8] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff6a37c
LR =3D 0xffecd58
Instruction dump:
7c0803a6 4e800020 9421fff0 7c0802a6 90010014 7c0000a6 70098000 40a2002c
3d20c025 8009d2a8 7c000034 5400d97e <0f000000> 2f800000 41be0010
38000001
(gdb) list *0xc0121170
0xc0121170 is in phy_read (drivers/net/phy/phy.c:80).
75 spin_lock_bh(&bus->mdio_lock);
76 retval =3D bus->read(bus, phydev->addr, regnum);
77 spin_unlock_bh(&bus->mdio_lock);
78
79 return retval;
80 }
81 EXPORT_SYMBOL(phy_read);
82
83 /**
84 * phy_write - Convenience function for writing a given PHY
register
(gdb) list *0xc012140c
0xc012140c is in phy_mii_ioctl (drivers/net/phy/phy.c:368).
363 switch (cmd) {
364 case SIOCGMIIPHY:
365 mii_data->phy_id =3D phydev->addr;
366 break;
367 case SIOCGMIIREG:
368 mii_data->val_out =3D phy_read(phydev,
mii_data->reg_num);
369 break;
370
371 case SIOCSMIIREG:
372 if (!capable(CAP_NET_ADMIN))
(gdb) list *0xc001f8bc
0xc001f8bc is in local_bh_enable (kernel/softirq.c:139).
134 #ifdef CONFIG_TRACE_IRQFLAGS
135 unsigned long flags;
136
137 WARN_ON_ONCE(in_irq());
138 #endif
139 WARN_ON_ONCE(irqs_disabled());
140
141 #ifdef CONFIG_TRACE_IRQFLAGS
142 local_irq_save(flags);
143 #endif
the relevant part of my device tree is:
ethernet@11340 {
device_type =3D "network";
compatible =3D "fsl,mpc8280-fcc-enet",
"fsl,cpm2-fcc-enet";
reg =3D <11340 20 8600 100 113d0 1>;
interrupts =3D <22 8>;
interrupt-parent =3D <&PIC>;
phy-handle =3D <&PHY1>;
linux,network-index =3D <1>;
fsl,cpm-command =3D <1a400300>;
local-mac-address =3D [00 00 00 00 00 00];
};
mdio@10d40 {
device_type =3D "mdio";
compatible =3D "fsl,pq2fads-mdio-bitbang",
"fsl,mpc8280-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
#address-cells =3D <1>;
#size-cells =3D <0>;
reg =3D <10d40 14>;
fsl,mdio-pin =3D <5>;
fsl,mdc-pin =3D <4>;
PHY1: ethernet-phy@1 {
//interrupt-parent =3D <&PIC>;
//interrupts =3D <19 2>;
reg =3D <1>;
device_type =3D "ethernet-phy";
};
};
^ permalink raw reply
* Re: MPC8272 FCC2 MDIO on Port D and FS_ENET
From: Scott Wood @ 2008-02-11 21:39 UTC (permalink / raw)
To: NM; +Cc: linuxppc-embedded
In-Reply-To: <235903.35949.qm@web32704.mail.mud.yahoo.com>
NM wrote:
> My problem is solved now after probing the lines, MDC was not showing
> any activity.
> So, after explicitly setting the PD23 (MDC) to : OUTPUT/GPIO in
> mpc8272_ads_pins and it worked in
>
> I'd previously thought about that, but I was sure that this was being
> taken care of, but now that I'm thinking of it, I'm questioning my belief.
> I think in the fs_enet/mii-bitbang.c: mdio_dir(..) it is supposed to
> take care of this.
No, the mdc pin is static; only bits which need to be changed
dynamically are dealt with in mii-bitbang.c. Either the firmware or the
platform code should set up static pins.
> But why I had to explictly set it initially beats me.
> I wonder how this works in standard distribution.
It's probably set up by u-boot normally, at least if you boot from ethernet.
-Scott
^ permalink raw reply
* Re: WARN_ON() hit in fsl bitbanged phy driver
From: Scott Wood @ 2008-02-11 21:50 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, netdev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03F931E6@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
> I hit the following WARN_ON when using mii-tools agains a ethernet
> interface using a bit-banged mii interface
> It is only diplayed once, and does not seem to impact usage at all
>
> Does somebody know what is wrong, and how to fix it?
It looks like the kernel thinks it's in an interrupt, even though it
clearly isn't from the backtrace. Presumably, something slept from an
interrupt handler; try turning on sleep-in-spinlock debugging.
The root cause was probably something other than the phy code.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: create mpc85xx pci err platform device for EDAC
From: Kumar Gala @ 2008-02-11 21:56 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev
In-Reply-To: <20080211203445.GB5331@blade.az.mvista.com>
On Feb 11, 2008, at 2:34 PM, Dave Jiang wrote:
> Creating a platform device for the PCI error registers in order for
> the
> mpc85xx EDAC driver to pick up proper resources. This is to prevent
> the
> EDAC driver from monopolizing the of_device and thus preventing
> future PCI
> code from using the PCI of_device(s).
>
> Signed-off-by: Dave Jiang <djiang@mvista.com>
I'd rather we didn't add new platform devices, but do this via
of_platform in the driver itself.
Also, we need to 'rename' the compatible field for some of these
devices.
- k
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: publish 85xx soc dts entries as of_device
From: Jon Loeliger @ 2008-02-11 22:01 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev
In-Reply-To: <20080211203243.GA5331@blade.az.mvista.com>
Dave Jiang wrote:
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> index 4e03050..024393c 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> @@ -26,6 +26,8 @@
> #include <asm/mpic.h>
> #include <mm/mmu_decl.h>
> #include <asm/udbg.h>
> +#include <asm/of_device.h>
> +#include <asm/of_platform.h>
Please use <linux/of_{device,platform}.h> throughout instead.
Thanks.
jdl
^ permalink raw reply
* Re: MPC8272 FCC2 MDIO on Port D and FS_ENET
From: NM @ 2008-02-11 22:04 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <47B0C099.5030205@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]
Thanks Scott,
I do boot from U-BOOT, via Ethernet, but I'd never set the MDIO/MDC in U-BOOT. Actually, looking at the u-boot 's MPC8260ADS.h now, it is still setting the default 8272ADS boards' PC18/19 for MDC/MDIO - and my unit is using PD23/29.
I guess U-BOOT is probably working (for me) since it probably defaults to the defaults of PHY and maybe not checking for PHY errors???
I guess, it is probably worthwhile having the MDIO/MDC pins also set up explicitly in mpc8272_ads_pins as opposed to relying on the boot loader.
Scott Wood <scottwood@freescale.com> wrote: NM wrote:
> My problem is solved now after probing the lines, MDC was not showing
> any activity.
> So, after explicitly setting the PD23 (MDC) to : OUTPUT/GPIO in
> mpc8272_ads_pins and it worked in
>
> I'd previously thought about that, but I was sure that this was being
> taken care of, but now that I'm thinking of it, I'm questioning my belief.
> I think in the fs_enet/mii-bitbang.c: mdio_dir(..) it is supposed to
> take care of this.
No, the mdc pin is static; only bits which need to be changed
dynamically are dealt with in mii-bitbang.c. Either the firmware or the
platform code should set up static pins.
> But why I had to explictly set it initially beats me.
> I wonder how this works in standard distribution.
It's probably set up by u-boot normally, at least if you boot from ethernet.
-Scott
---------------------------------
Looking for the perfect gift? Give the gift of Flickr!
[-- Attachment #2: Type: text/html, Size: 1823 bytes --]
^ permalink raw reply
* RE: WARN_ON() hit in fsl bitbanged phy driver
From: Rune Torgersen @ 2008-02-11 22:12 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, netdev
In-Reply-To: <47B0C30A.1030801@freescale.com>
Scott Wood wrote:
> Rune Torgersen wrote:
>> I hit the following WARN_ON when using mii-tools agains a ethernet
>> interface using a bit-banged mii interface
>=20
> It looks like the kernel thinks it's in an interrupt, even though it
> clearly isn't from the backtrace. Presumably, something
> slept from an
> interrupt handler; try turning on sleep-in-spinlock debugging.
I turned on sleep-in-spinlock and it did not reveal anything. I'm trying
some other debug options.
> The root cause was probably something other than the phy code.
I'm not so sure, because it only happens when I run mii-tool agains the
interface useing the bit-banged driver, and then only the first time.
^ permalink raw reply
* Re: WARN_ON() hit in fsl bitbanged phy driver
From: Scott Wood @ 2008-02-11 22:26 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, netdev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03F9325F@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
> Scott Wood wrote:
>> Rune Torgersen wrote:
>>> I hit the following WARN_ON when using mii-tools agains a ethernet
>>> interface using a bit-banged mii interface
>> It looks like the kernel thinks it's in an interrupt, even though it
>> clearly isn't from the backtrace. Presumably, something
>> slept from an
>> interrupt handler; try turning on sleep-in-spinlock debugging.
>
> I turned on sleep-in-spinlock and it did not reveal anything. I'm trying
> some other debug options.
>
>> The root cause was probably something other than the phy code.
> I'm not so sure, because it only happens when I run mii-tool agains the
> interface useing the bit-banged driver, and then only the first time.
OK, it seems I should have checked 2.6.24 instead of head-of-tree;
softirq.c:139 is a different assertion than I thought. It's not
in_irq(), but irqs_disabled(). fs_ioctl() is disabling interrupts, and
spin_unlock_bh() doesn't like that. The current use of mutexes likes it
even less. The locking should be moved inside the phy bus
implementation, if it's needed at all.
It only happens once because it's a WARN_ON_ONCE(). :-)
-Scott
^ permalink raw reply
* [PATCH] powerpc: Marvell 64x60 EDAC platform devices setup
From: Dave Jiang @ 2008-02-11 22:50 UTC (permalink / raw)
To: paulus, linuxppc-dev
Creating platform devices (memory controller, sram error registers, cpu
error registers, PCI error registers) for Error Detection and Correction
(EDAC) driver.
The platform devices allow the mv64x60 EDAC driver to detect errors from
the memory controller (ECC erorrs), SRAM controller, CPU data path error
registers, and PCI error registers. The errors are reported to syslog.
Software ECC scrubbing is provided. These replace the mv64x60 error
handlers in the ppc branch. They are being moved to EDAC subsystem in
order to centralize error reporting.
The error reporting can be triggered via interrupts from the mv64x60 bridge
chip or via polling mechanism provided by the EDAC core code.
Signed-off-by: Dave Jiang <djiang@mvista.com>
Acked-by: Dale Farnsworth <dale@farnsworth.org>
---
commit 0acbcb74052fbd5823bfb262619db52dedc85a86
tree 905f2c324a4d55bbcde78d60f2537a5027a831fa
parent da914292a37172fa14ec8080d2a71bf014672b58
author Dave Jiang <djiang@blade.(none)> Mon, 11 Feb 2008 15:43:22 -0700
committer Dave Jiang <djiang@blade.(none)> Mon, 11 Feb 2008 15:43:22 -0700
arch/powerpc/sysdev/mv64x60_dev.c | 94 +++++++++++++++++++++++++++++++++++++
1 files changed, 94 insertions(+), 0 deletions(-)
The mv64x60 EDAC driver is in mainline now
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c
index efda002..c9edd66 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -17,6 +17,7 @@
#include <linux/platform_device.h>
#include <asm/prom.h>
+#include <asm/io.h>
/*
* These functions provide the necessary setup for the mv64x60 drivers.
@@ -439,6 +440,69 @@ error:
return err;
}
+static int __init mv64x60_edac_pdev_init(struct device_node *np,
+ int id,
+ int num_addr,
+ char *pdev_name)
+{
+ struct resource *r;
+ struct platform_device *pdev;
+ int i, ret;
+
+ r = kzalloc(num_addr * sizeof(*r) + sizeof(*r), GFP_KERNEL);
+ if (!r)
+ return -ENOMEM;
+
+ for (i = 0; i < num_addr; i++) {
+ ret = of_address_to_resource(np, i, &r[i]);
+ if (ret) {
+ kfree(r);
+ return ret;
+ }
+ }
+
+ of_irq_to_resource(np, 0, &r[i]);
+
+ pdev = platform_device_register_simple(pdev_name, id, r, num_addr + 1);
+
+ kfree(r);
+
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PCI
+/*
+ * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
+ * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
+ * well. IOW, don't set bit 0.
+ */
+#define MV64X60_PCIx_ERR_MASK_VAL 0x00a50c24
+
+/* Erratum FEr PCI-#16: clear bit 0 of PCI SERRn Mask reg. */
+static int __init mv64x60_pci_fixup(struct device_node *np)
+{
+ struct resource res;
+ void __iomem *pci_serr;
+ int ret;
+
+ ret = of_address_to_resource(np, 1, &res);
+ if (ret)
+ return ret;
+
+ pci_serr = ioremap(res.start, res.end - res.start + 1);
+ if (!pci_serr)
+ return -ENOMEM;
+
+ out_le32(pci_serr, in_le32(pci_serr) & ~0x1);
+ iounmap(pci_serr);
+
+ return 0;
+}
+#endif /* CONFIG_PCI */
+
static int __init mv64x60_device_setup(void)
{
struct device_node *np = NULL;
@@ -460,6 +524,36 @@ static int __init mv64x60_device_setup(void)
if ((err = mv64x60_i2c_device_setup(np, id++)))
goto error;
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-mem-ctrl")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_mc_err")))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-cpu-error")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 2,
+ "mv64x60_cpu_err")))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-sram-ctrl")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_sram_err")))
+ goto error;
+
+#ifdef CONFIG_PCI
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-pci-error") {
+ if ((err = mv64x60_pci_fixup(np)))
+ goto error;
+
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_pci_err")))
+ goto error;
+ }
+#endif
+
/* support up to one watchdog timer */
np = of_find_compatible_node(np, NULL, "marvell,mv64x60-wdt");
if (np) {
^ permalink raw reply related
* [PATCH] fix swim3.c modular build
From: Kyle McMartin @ 2008-02-11 22:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-ide
While updating Fedora to 2.6.25-rc1, I noticed this little gem...
This swim3 and mediabay dependancy is pretty grody. Commit
34394e45c3387bd66619d9a51b4be507e4222b02 moved the ifdef around, which
meant the EXPORT_SYMBOL wasn't happening, which was bad, since if swim3
is built modularly, and CONFIG_PMAC_MEDIABAY is defined the internal
replacement isn't used.
Anyway, a powerpc person should probably look at making this less than
completely broken, but at least it will now build.
I'm not entirely sure why this is conditional at all, really.
diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
index 9367882..635a140 100644
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -416,9 +416,9 @@ static void poll_media_bay(struct media_bay_info* bay)
}
}
-#ifdef CONFIG_MAC_FLOPPY
int check_media_bay(struct device_node *which_bay, int what)
{
+#ifdef CONFIG_MAC_FLOPPY
int i;
for (i=0; i<media_bay_count; i++)
@@ -428,10 +428,10 @@ int check_media_bay(struct device_node *which_bay, int what)
media_bays[i].cd_index = -1;
return -EINVAL;
}
+#endif /* CONFIG_MAC_FLOPPY */
return -ENODEV;
}
EXPORT_SYMBOL(check_media_bay);
-#endif /* CONFIG_MAC_FLOPPY */
#ifdef CONFIG_BLK_DEV_IDE_PMAC
int check_media_bay_by_base(unsigned long base, int what)
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc: publish 85xx soc dts entries as of_device
From: Grant Likely @ 2008-02-11 23:12 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev
In-Reply-To: <20080211203243.GA5331@blade.az.mvista.com>
On Feb 11, 2008 1:32 PM, Dave Jiang <djiang@mvista.com> wrote:
> Publish the devices listed in dts under SOC as of_device just like what
> mpc85xx_mds platforms do. The 85xx cds and ads platforms currently do not
> export the devices in dts as of_device.
>
> The memory controller, L2 cache-controller, and the PCI controller(s) are
> published as of_device so the mpc85xx EDAC driver can claim them for usage.
>
> Signed-off-by: Dave Jiang <djiang@mvista.com>
>
> ---
> commit 187841bf9dff25e4ac1a7174daa55bb036c724b1
> tree 3206ffbbfc5075d195345281f72f7b52f060b41b
> parent a99824f327c748b2753f4fa570eb1fefcd6a9c4d
> author Dave Jiang <djiang@mvista.com> Mon, 11 Feb 2008 12:51:33 -0700
> committer Dave Jiang <djiang@blade.(none)> Mon, 11 Feb 2008 12:51:33 -0700
>
> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 19 +++++++++++++++++++
> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 19 +++++++++++++++++++
> 2 files changed, 38 insertions(+), 0 deletions(-)
>
> mpc85xx EDAC driver is in mainline kernel now
>
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> index 4e03050..024393c 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> @@ -26,6 +26,8 @@
> #include <asm/mpic.h>
> #include <mm/mmu_decl.h>
> #include <asm/udbg.h>
> +#include <asm/of_device.h>
> +#include <asm/of_platform.h>
>
> #include <sysdev/fsl_soc.h>
> #include <sysdev/fsl_pci.h>
> @@ -249,6 +251,23 @@ static int __init mpc85xx_ads_probe(void)
> return of_flat_dt_is_compatible(root, "MPC85xxADS");
> }
>
> +static struct of_device_id mpc85xx_ids[] = {
> + { .type = "soc", },
> + { .compatible = "soc", },
> + {},
> +};
> +
> +static int __init mpc85xx_publish_devices(void)
> +{
> + if (!machine_is(mpc85xx_ads))
> + return 0;
> +
> + of_platform_bus_probe(NULL, mpc85xx_ids, NULL);
> +
> + return 0;
> +}
> +device_initcall(mpc85xx_publish_devices);
machine_device_initcall() please. (which lets you eliminate the
machine_is() test).
> +
> +static int __init mpc85xx_publish_devices(void)
> +{
> + if (!machine_is(mpc85xx_cds))
> + return 0;
> +
> + of_platform_bus_probe(NULL, mpc85xx_ids, NULL);
> +
> + return 0;
> +}
> +device_initcall(mpc85xx_publish_devices);
> +
ditto
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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