* perfmon2 needs hard_irq_disable() for powerpc
From: Sonny Rao @ 2007-11-26 7:44 UTC (permalink / raw)
To: perfmon2-devel
Cc: mikey, miltonm, dwg, linuxppc-dev, paulus, anton, eranian,
cjashfor
Hi, I've been reading through the perfmon2 patch for 2.6.23 and it
dawned on me that in the powerpc architecture we have the notion of
lazy-disabling of interrupts where we don't actually disable
interrupts unless we see one come in and then turn them off. I believe
a notable exception is the performance monitor interrupt which we
allow to break into our critical sections. This is desirable because
we want to profile those sections and right now, no in-kernel user of
the performance monitor interrupt in powerpc does any synchronization
across cpus inside the interrupt handler (oprofile seems to use
per-cpu buffers/state for everything). We use hard_irq_disable() when
we _really_ have to disable interrupts because we're switching out the
kernel stack, etc.
Perfmon2 is more demanding in its synchronization requirements and it
uses spin_lock_irqsave() in the generic arch-neutral code in several
places, I think this will break on powerpc the way we're handling
things now.
I'm copying a few people to solicit opinions on how best to deal with
this. I think it's desirable to keep the property of letting us
profile critical sections in the kernel wherever possible. So we would
need to add hard_irq_disable/enable calls to the generic code, but want to
check with you guys first.
Sonny
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-26 10:24 UTC (permalink / raw)
To: Michel D?nzer, linuxppc-dev
In-Reply-To: <1196068814.22865.108.camel@thor.sulgenrain.local>
[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]
On Mon, Nov 26, 2007 at 10:20:14AM +0100, Michel D?nzer wrote:
> > Regarding the sub-thread on x86 emulation, that is totally out of scope
> > for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I
> > may have minor errors here, ask airlied if you need more
> > clarification):
> > a) Initialization code (I think arch-specific)
> > b) AtomBIOS script interpreter (I think arch-specific)
> > c) AtomBIOS scripts (card-specific, but not arch-specific)
> > d) Data tables (card-specific, but not arch-specific)
> >
> > The AtomBIOS parts of the various drivers need data from c+d primarily,
> > and provide their own script interpreter, or not using the scripts, just
> > the data tables.
> Are you sure the X1900 Mac Edition ROM contains any ATOM data structures
> though? I rather doubt it.
That's what I'm trying to ascertain actually, because it directly
impacts what work needs to be done in the drivers.
If it was me writing the ROMs in the first place (but it's not), from
what I understand of the ATOM, I'd have OpenFirmware versions of a+b,
and then could re-use c+d.
The fact that both Nvidia and ATI OF-powered cards fail when trying to
access their expansion ROMs, I'm inclined to think there is something in
accessing them that we are missing, and that the ROMs must exist (the
sata_mv one existed and was accessible).
On actually accessing the rest of the ATI X1900 card, the avivotool from
git://people.freedesktop.org/~airlied/radeontool.git (avivo branch) can
actually access the rest of the rest of the card registers.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
From: Vitaly Bordug @ 2007-11-26 10:28 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <19DACFA1-05DB-4331-BE71-282590B9DFE5@embeddedalley.com>
On Sun, 25 Nov 2007 13:02:03 -0800
Dan Malek wrote:
>
> On Nov 25, 2007, at 8:18 AM, Vitaly Bordug wrote:
>
> > To prevent using those pointers from within non-GPL modules. kind
> > of policy now...
>
> As the original copyright holder of nearly all of this of
> this code, I do not wish this be done.
In this particular case this is not going to happen anyway, but I will take your opinion into
account for the similar cases.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] ehea: Add kdump support
From: Christoph Raisch @ 2007-11-26 10:45 UTC (permalink / raw)
To: michael
Cc: Michael Neuling, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Paul Mackerras, Marcus Eder, tklein,
Stefan Roscher
In-Reply-To: <1196064988.19855.15.camel@concordia>
Michael Ellerman wrote on 26.11.2007 09:16:28:
> Solutions that might be better:
>
> a) if there are a finite number of handles and we can predict their
> values, just delete them all in the kdump kernel before the driver
> loads.
Guessing the values does not work, because of the handle structure
defined by the hypervisor.
> b) if there are a small & finite number of handles, save their values
> in a device tree property and have the kdump kernel read them and
> delete them before the driver loads.
5*16*nr_ports+1+1= >82. a ML16 has 4 adapters with up to 16 ports, so the
number
is not small anymore....
The device tree functions are currently not exported.
If you crashdump to a new kernel, will it get the device tree
representation
of the crashed kernel or of the initial one of open firmware?
> c) if neither of those work, provide a minimal routine that _only_
> deletes the handles in the crashed kernel.
I would hope this has the highest chance to actually work.
For this we would have to add a proper notifier chain.
Do you agree?
> d) <something else>
Firmware change? But that's not something you will get very soon.
Christoph R.
^ permalink raw reply
* Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
From: Jochen Friedrich @ 2007-11-26 11:15 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20071125191833.1e76f335@kernel.crashing.org>
Hi Vitaly,
>> Maybe this is a stupid question, but why did you choose
>> EXPORT_SYMBOL_GPL and not EXPORT_SYMBOL?
>>
> To prevent using those pointers from within non-GPL modules. kind of policy now...
In particular in this case, as these pointers are currently not exported, at all. They
are currently used by a few drivers and will disappear again once these drivers have
been converted to use the propper accessors, which will also prevent access conflicts
to the CPM registers.
Thanks,
Jochen
^ permalink raw reply
* [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
From: Vitaly Bordug @ 2007-11-26 14:29 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
With that patch fixed.c now fully emulates MDIO bus, thus no need
to duplicate PHY layer functionality. That, in turn, drastically
simplifies the code, and drops down line count.
As an additional bonus, now there is no need to register MDIO bus
for each PHY, all emulated PHYs placed on the platform fixed MDIO bus.
There is also no more need to pre-allocate PHYs via .config option,
this is all now handled dynamically.
p.s. Don't even try to understand patch content! Better: apply patch
and look into resulting drivers/net/phy/fixed.c.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
drivers/net/phy/Kconfig | 32 +--
drivers/net/phy/fixed.c | 427 ++++++++++++++++-----------------------------
include/linux/phy_fixed.h | 49 ++---
3 files changed, 176 insertions(+), 332 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 54b2ba9..a05c614 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -61,34 +61,12 @@ config ICPLUS_PHY
Currently supports the IP175C PHY.
config FIXED_PHY
- tristate "Drivers for PHY emulation on fixed speed/link"
+ tristate "Drivers for MDIO Bus/PHY emulation on fixed speed/link"
---help---
- Adds the driver to PHY layer to cover the boards that do not have any PHY bound,
- but with the ability to manipulate the speed/link in software. The relevant MII
- speed/duplex parameters could be effectively handled in a user-specified function.
- Currently tested with mpc866ads.
-
-config FIXED_MII_10_FDX
- bool "Emulation for 10M Fdx fixed PHY behavior"
- depends on FIXED_PHY
-
-config FIXED_MII_100_FDX
- bool "Emulation for 100M Fdx fixed PHY behavior"
- depends on FIXED_PHY
-
-config FIXED_MII_1000_FDX
- bool "Emulation for 1000M Fdx fixed PHY behavior"
- depends on FIXED_PHY
-
-config FIXED_MII_AMNT
- int "Number of emulated PHYs to allocate "
- depends on FIXED_PHY
- default "1"
- ---help---
- Sometimes it is required to have several independent emulated
- PHYs on the bus (in case of multi-eth but phy-less HW for instance).
- This control will have specified number allocated for each fixed
- PHY type enabled.
+ Adds the platform "fixed" MDIO Bus to cover the boards that use
+ PHYs that are not connected to the real MDIO bus.
+
+ Currently tested with mpc866ads and mpc8349e-mitx.
config MDIO_BITBANG
tristate "Support for bitbanged MDIO buses"
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 5619182..31719b3 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -1,362 +1,237 @@
/*
- * drivers/net/phy/fixed.c
+ * Fixed MDIO bus (MDIO bus emulation with fixed PHYs)
*
- * Driver for fixed PHYs, when transceiver is able to operate in one fixed mode.
+ * Author: Vitaly Bordug <vbordug@ru.mvista.com>
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
*
- * Author: Vitaly Bordug
- *
- * Copyright (c) 2006 MontaVista Software, Inc.
+ * Copyright (c) 2006-2007 MontaVista Software, Inc.
*
* 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/kernel.h>
-#include <linux/string.h>
-#include <linux/errno.h>
-#include <linux/unistd.h>
-#include <linux/slab.h>
-#include <linux/interrupt.h>
-#include <linux/init.h>
-#include <linux/delay.h>
-#include <linux/netdevice.h>
-#include <linux/etherdevice.h>
-#include <linux/skbuff.h>
-#include <linux/spinlock.h>
-#include <linux/mm.h>
#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/list.h>
#include <linux/mii.h>
-#include <linux/ethtool.h>
#include <linux/phy.h>
#include <linux/phy_fixed.h>
-#include <asm/io.h>
-#include <asm/irq.h>
-#include <asm/uaccess.h>
-
-/* we need to track the allocated pointers in order to free them on exit */
-static struct fixed_info *fixed_phy_ptrs[CONFIG_FIXED_MII_AMNT*MAX_PHY_AMNT];
-
-/*-----------------------------------------------------------------------------
- * If something weird is required to be done with link/speed,
- * network driver is able to assign a function to implement this.
- * May be useful for PHY's that need to be software-driven.
- *-----------------------------------------------------------------------------*/
-int fixed_mdio_set_link_update(struct phy_device *phydev,
- int (*link_update) (struct net_device *,
- struct fixed_phy_status *))
-{
- struct fixed_info *fixed;
-
- if (link_update == NULL)
- return -EINVAL;
-
- if (phydev) {
- if (phydev->bus) {
- fixed = phydev->bus->priv;
- fixed->link_update = link_update;
- return 0;
- }
- }
- return -EINVAL;
-}
+#define MII_REGS_NUM 29
-EXPORT_SYMBOL(fixed_mdio_set_link_update);
+struct fixed_mdio_bus {
+ int irqs[PHY_MAX_ADDR];
+ struct mii_bus mii_bus;
+ struct list_head phys;
+};
-struct fixed_info *fixed_mdio_get_phydev (int phydev_ind)
-{
- if (phydev_ind >= MAX_PHY_AMNT)
- return NULL;
- return fixed_phy_ptrs[phydev_ind];
-}
+struct fixed_phy {
+ int id;
+ u16 regs[MII_REGS_NUM];
+ struct phy_device *phydev;
+ struct fixed_phy_status status;
+ int (*link_update)(struct net_device *, struct fixed_phy_status *);
+ struct list_head node;
+};
-EXPORT_SYMBOL(fixed_mdio_get_phydev);
+static struct platform_device *pdev;
+static struct fixed_mdio_bus platform_fmb = {
+ .phys = LIST_HEAD_INIT(platform_fmb.phys),
+};
-/*-----------------------------------------------------------------------------
- * This is used for updating internal mii regs from the status
- *-----------------------------------------------------------------------------*/
-#if defined(CONFIG_FIXED_MII_100_FDX) || defined(CONFIG_FIXED_MII_10_FDX) || defined(CONFIG_FIXED_MII_1000_FDX)
-static int fixed_mdio_update_regs(struct fixed_info *fixed)
+static int fixed_phy_update_regs(struct fixed_phy *fp)
{
- u16 *regs = fixed->regs;
u16 bmsr = 0;
u16 bmcr = 0;
- if (!regs) {
- printk(KERN_ERR "%s: regs not set up", __FUNCTION__);
- return -EINVAL;
- }
-
- if (fixed->phy_status.link)
- bmsr |= BMSR_LSTATUS;
-
- if (fixed->phy_status.duplex) {
+ if (fp->status.duplex) {
bmcr |= BMCR_FULLDPLX;
- switch (fixed->phy_status.speed) {
+ switch (fp->status.speed) {
+ case 1000:
+ bmsr |= BMSR_ESTATEN;
+ bmcr |= BMCR_SPEED1000;
+ break;
case 100:
bmsr |= BMSR_100FULL;
bmcr |= BMCR_SPEED100;
break;
-
case 10:
bmsr |= BMSR_10FULL;
break;
+ default:
+ printk(KERN_WARNING "fixed phy: unknown speed\n");
+ return -EINVAL;
}
} else {
- switch (fixed->phy_status.speed) {
+ switch (fp->status.speed) {
+ case 1000:
+ bmsr |= BMSR_ESTATEN;
+ bmcr |= BMCR_SPEED1000;
+ break;
case 100:
bmsr |= BMSR_100HALF;
bmcr |= BMCR_SPEED100;
break;
-
case 10:
- bmsr |= BMSR_100HALF;
+ bmsr |= BMSR_10HALF;
break;
+ default:
+ printk(KERN_WARNING "fixed phy: unknown speed\n");
+ return -EINVAL;
}
}
- regs[MII_BMCR] = bmcr;
- regs[MII_BMSR] = bmsr | 0x800; /*we are always capable of 10 hdx */
+ if (fp->status.link)
+ bmsr |= BMSR_LSTATUS | BMSR_ANEGCOMPLETE;
+
+ fp->regs[MII_PHYSID1] = fp->id >> 16;
+ fp->regs[MII_PHYSID2] = fp->id;
+
+ fp->regs[MII_BMSR] = bmsr;
+ fp->regs[MII_BMCR] = bmcr;
return 0;
}
-static int fixed_mii_read(struct mii_bus *bus, int phy_id, int location)
+static int fixed_mdio_read(struct mii_bus *bus, int phy_id, int reg_num)
{
- struct fixed_info *fixed = bus->priv;
-
- /* if user has registered link update callback, use it */
- if (fixed->phydev)
- if (fixed->phydev->attached_dev) {
- if (fixed->link_update) {
- fixed->link_update(fixed->phydev->attached_dev,
- &fixed->phy_status);
- fixed_mdio_update_regs(fixed);
+ struct fixed_mdio_bus *fmb = container_of(bus, struct fixed_mdio_bus,
+ mii_bus);
+ struct fixed_phy *fp;
+
+ if (reg_num >= MII_REGS_NUM)
+ return -1;
+
+ list_for_each_entry(fp, &fmb->phys, node) {
+ if (fp->id == phy_id) {
+ /* Issue callback if user registered it. */
+ if (fp->link_update) {
+ fp->link_update(fp->phydev->attached_dev,
+ &fp->status);
+ fixed_phy_update_regs(fp);
}
+ return fp->regs[reg_num];
}
+ }
- if ((unsigned int)location >= fixed->regs_num)
- return -1;
- return fixed->regs[location];
+ return 0xFFFF;
}
-static int fixed_mii_write(struct mii_bus *bus, int phy_id, int location,
- u16 val)
+static int fixed_mdio_write(struct mii_bus *bus, int phy_id, int reg_num,
+ u16 val)
{
- /* do nothing for now */
return 0;
}
-static int fixed_mii_reset(struct mii_bus *bus)
+/*
+ * If something weird is required to be done with link/speed,
+ * network driver is able to assign a function to implement this.
+ * May be useful for PHY's that need to be software-driven.
+ */
+int fixed_phy_set_link_update(struct phy_device *phydev,
+ int (*link_update)(struct net_device *,
+ struct fixed_phy_status *))
{
- /*nothing here - no way/need to reset it */
- return 0;
-}
-#endif
+ struct fixed_mdio_bus *fmb = &platform_fmb;
+ struct fixed_phy *fp;
-static int fixed_config_aneg(struct phy_device *phydev)
-{
- /* :TODO:03/13/2006 09:45:37 PM::
- The full autoneg funcionality can be emulated,
- but no need to have anything here for now
- */
- return 0;
-}
+ if (!link_update || !phydev || !phydev->bus)
+ return -EINVAL;
-/*-----------------------------------------------------------------------------
- * the manual bind will do the magic - with phy_id_mask == 0
- * match will never return true...
- *-----------------------------------------------------------------------------*/
-static struct phy_driver fixed_mdio_driver = {
- .name = "Fixed PHY",
-#ifdef CONFIG_FIXED_MII_1000_FDX
- .features = PHY_GBIT_FEATURES,
-#else
- .features = PHY_BASIC_FEATURES,
-#endif
- .config_aneg = fixed_config_aneg,
- .read_status = genphy_read_status,
- .driver = { .owner = THIS_MODULE, },
-};
+ list_for_each_entry(fp, &fmb->phys, node) {
+ if (fp->id == phydev->phy_id) {
+ fp->link_update = link_update;
+ fp->phydev = phydev;
+ return 0;
+ }
+ }
-static void fixed_mdio_release(struct device *dev)
-{
- struct phy_device *phydev = container_of(dev, struct phy_device, dev);
- struct mii_bus *bus = phydev->bus;
- struct fixed_info *fixed = bus->priv;
-
- kfree(phydev);
- kfree(bus->dev);
- kfree(bus);
- kfree(fixed->regs);
- kfree(fixed);
+ return -ENOENT;
}
+EXPORT_SYMBOL_GPL(fixed_phy_set_link_update);
-/*-----------------------------------------------------------------------------
- * This func is used to create all the necessary stuff, bind
- * the fixed phy driver and register all it on the mdio_bus_type.
- * speed is either 10 or 100 or 1000, duplex is boolean.
- * number is used to create multiple fixed PHYs, so that several devices can
- * utilize them simultaneously.
- *
- * The device on mdio bus will look like [bus_id]:[phy_id],
- * bus_id = number
- * phy_id = speed+duplex.
- *-----------------------------------------------------------------------------*/
-#if defined(CONFIG_FIXED_MII_100_FDX) || defined(CONFIG_FIXED_MII_10_FDX) || defined(CONFIG_FIXED_MII_1000_FDX)
-struct fixed_info *fixed_mdio_register_device(
- int bus_id, int speed, int duplex, u8 phy_id)
+int fixed_phy_add(unsigned int irq, int phy_id,
+ struct fixed_phy_status *status)
{
- struct mii_bus *new_bus;
- struct fixed_info *fixed;
- struct phy_device *phydev;
- int err;
+ int ret;
+ struct fixed_mdio_bus *fmb = &platform_fmb;
+ struct fixed_phy *fp;
- struct device *dev = kzalloc(sizeof(struct device), GFP_KERNEL);
+ fp = kzalloc(sizeof(*fp), GFP_KERNEL);
+ if (!fp)
+ return -ENOMEM;
- if (dev == NULL)
- goto err_dev_alloc;
+ memset(fp->regs, 0xFF, sizeof(fp->regs[0]) * MII_REGS_NUM);
- new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
+ fmb->irqs[phy_id] = irq;
- if (new_bus == NULL)
- goto err_bus_alloc;
+ fp->id = phy_id;
+ fp->status = *status;
- fixed = kzalloc(sizeof(struct fixed_info), GFP_KERNEL);
+ ret = fixed_phy_update_regs(fp);
+ if (ret)
+ goto err_regs;
- if (fixed == NULL)
- goto err_fixed_alloc;
+ list_add_tail(&fp->node, &fmb->phys);
- fixed->regs = kzalloc(MII_REGS_NUM * sizeof(int), GFP_KERNEL);
- if (NULL == fixed->regs)
- goto err_fixed_regs_alloc;
+ return 0;
- fixed->regs_num = MII_REGS_NUM;
- fixed->phy_status.speed = speed;
- fixed->phy_status.duplex = duplex;
- fixed->phy_status.link = 1;
+err_regs:
+ kfree(fp);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(fixed_phy_add);
- new_bus->name = "Fixed MII Bus";
- new_bus->read = &fixed_mii_read;
- new_bus->write = &fixed_mii_write;
- new_bus->reset = &fixed_mii_reset;
- /*set up workspace */
- fixed_mdio_update_regs(fixed);
- new_bus->priv = fixed;
+static int __init fixed_mdio_bus_init(void)
+{
+ struct fixed_mdio_bus *fmb = &platform_fmb;
+ int ret;
- new_bus->dev = dev;
- dev_set_drvdata(dev, new_bus);
+ pdev = platform_device_register_simple("Fixed MDIO bus", 0, NULL, 0);
+ if (!pdev) {
+ ret = -ENOMEM;
+ goto err_pdev;
+ }
- /* create phy_device and register it on the mdio bus */
- phydev = phy_device_create(new_bus, 0, 0);
- if (phydev == NULL)
- goto err_phy_dev_create;
+ fmb->mii_bus.id = 0;
+ fmb->mii_bus.name = "Fixed MDIO Bus";
+ fmb->mii_bus.dev = &pdev->dev;
+ fmb->mii_bus.read = &fixed_mdio_read;
+ fmb->mii_bus.write = &fixed_mdio_write;
+ fmb->mii_bus.irq = fmb->irqs;
- /*
- * Put the phydev pointer into the fixed pack so that bus read/write
- * code could be able to access for instance attached netdev. Well it
- * doesn't have to do so, only in case of utilizing user-specified
- * link-update...
- */
+ ret = mdiobus_register(&fmb->mii_bus);
+ if (ret)
+ goto err_mdiobus_reg;
- fixed->phydev = phydev;
- phydev->speed = speed;
- phydev->duplex = duplex;
+ return 0;
- phydev->irq = PHY_IGNORE_INTERRUPT;
- phydev->dev.bus = &mdio_bus_type;
+err_mdiobus_reg:
+ platform_device_unregister(pdev);
+err_pdev:
+ return ret;
+}
+module_init(fixed_mdio_bus_init);
- snprintf(phydev->dev.bus_id, BUS_ID_SIZE,
- PHY_ID_FMT, bus_id, phy_id);
+static void __exit fixed_mdio_bus_exit(void)
+{
+ struct fixed_mdio_bus *fmb = &platform_fmb;
+ struct fixed_phy *fp;
- phydev->bus = new_bus;
+ mdiobus_unregister(&fmb->mii_bus);
+ platform_device_unregister(pdev);
- phydev->dev.driver = &fixed_mdio_driver.driver;
- phydev->dev.release = fixed_mdio_release;
- err = phydev->dev.driver->probe(&phydev->dev);
- if (err < 0) {
- printk(KERN_ERR "Phy %s: problems with fixed driver\n",
- phydev->dev.bus_id);
- goto err_out;
- }
- err = device_register(&phydev->dev);
- if (err) {
- printk(KERN_ERR "Phy %s failed to register\n",
- phydev->dev.bus_id);
- goto err_out;
+ list_for_each_entry(fp, &fmb->phys, node) {
+ list_del(&fp->node);
+ kfree(fp);
}
- //phydev->state = PHY_RUNNING; /* make phy go up quick, but in 10Mbit/HDX
- return fixed;
-
-err_out:
- kfree(phydev);
-err_phy_dev_create:
- kfree(fixed->regs);
-err_fixed_regs_alloc:
- kfree(fixed);
-err_fixed_alloc:
- kfree(new_bus);
-err_bus_alloc:
- kfree(dev);
-err_dev_alloc:
-
- return NULL;
-
}
-#endif
+module_exit(fixed_mdio_bus_exit);
-MODULE_DESCRIPTION("Fixed PHY device & driver for PAL");
+MODULE_DESCRIPTION("Fixed MDIO bus (MDIO bus emulation with fixed PHYs)");
MODULE_AUTHOR("Vitaly Bordug");
MODULE_LICENSE("GPL");
-
-static int __init fixed_init(void)
-{
- int cnt = 0;
- int i;
-/* register on the bus... Not expected to be matched
- * with anything there...
- *
- */
- phy_driver_register(&fixed_mdio_driver);
-
-/* We will create several mdio devices here, and will bound the upper
- * driver to them.
- *
- * Then the external software can lookup the phy bus by searching
- * for 0:101, to be connected to the virtual 100M Fdx phy.
- *
- * In case several virtual PHYs required, the bus_id will be in form
- * [num]:[duplex]+[speed], which make it able even to define
- * driver-specific link control callback, if for instance PHY is
- * completely SW-driven.
- */
- for (i=1; i <= CONFIG_FIXED_MII_AMNT; i++) {
-#ifdef CONFIG_FIXED_MII_1000_FDX
- fixed_phy_ptrs[cnt++] = fixed_mdio_register_device(0, 1000, 1, i);
-#endif
-#ifdef CONFIG_FIXED_MII_100_FDX
- fixed_phy_ptrs[cnt++] = fixed_mdio_register_device(1, 100, 1, i);
-#endif
-#ifdef CONFIG_FIXED_MII_10_FDX
- fixed_phy_ptrs[cnt++] = fixed_mdio_register_device(2, 10, 1, i);
-#endif
- }
-
- return 0;
-}
-
-static void __exit fixed_exit(void)
-{
- int i;
-
- phy_driver_unregister(&fixed_mdio_driver);
- for (i=0; i < MAX_PHY_AMNT; i++)
- if ( fixed_phy_ptrs[i] )
- device_unregister(&fixed_phy_ptrs[i]->phydev->dev);
-}
-
-module_init(fixed_init);
-module_exit(fixed_exit);
diff --git a/include/linux/phy_fixed.h b/include/linux/phy_fixed.h
index 04ba70d..01669d1 100644
--- a/include/linux/phy_fixed.h
+++ b/include/linux/phy_fixed.h
@@ -1,38 +1,29 @@
#ifndef __PHY_FIXED_H
#define __PHY_FIXED_H
-#define MII_REGS_NUM 29
-
-/* max number of virtual phy stuff */
-#define MAX_PHY_AMNT 10
-/*
- The idea is to emulate normal phy behavior by responding with
- pre-defined values to mii BMCR read, so that read_status hook could
- take all the needed info.
-*/
-
struct fixed_phy_status {
- u8 link;
- u16 speed;
- u8 duplex;
+ int link;
+ int speed;
+ int duplex;
};
-/*-----------------------------------------------------------------------------
- * Private information hoder for mii_bus
- *-----------------------------------------------------------------------------*/
-struct fixed_info {
- u16 *regs;
- u8 regs_num;
- struct fixed_phy_status phy_status;
- struct phy_device *phydev; /* pointer to the container */
- /* link & speed cb */
- int (*link_update) (struct net_device *, struct fixed_phy_status *);
+#ifdef CONFIG_FIXED_PHY
+extern int fixed_phy_add(unsigned int irq, int phy_id,
+ struct fixed_phy_status *status);
+#else
+static inline int fixed_phy_add(unsigned int irq, int phy_id,
+ struct fixed_phy_status *status)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_FIXED_PHY */
-};
-
-
-int fixed_mdio_set_link_update(struct phy_device *,
- int (*link_update) (struct net_device *, struct fixed_phy_status *));
-struct fixed_info *fixed_mdio_get_phydev (int phydev_ind);
+/*
+ * This function issued only by fixed_phy-aware drivers, no need
+ * protect it with #ifdef
+ */
+extern int fixed_phy_set_link_update(struct phy_device *phydev,
+ int (*link_update)(struct net_device *,
+ struct fixed_phy_status *));
#endif /* __PHY_FIXED_H */
^ permalink raw reply related
* [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
From: Vitaly Bordug @ 2007-11-26 14:29 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
In-Reply-To: <20071126142906.19642.45540.stgit@localhost.localdomain>
fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
not connected to the real MDIO bus.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Documentation/powerpc/booting-without-of.txt | 3 +
arch/powerpc/sysdev/fsl_soc.c | 56 ++++++++++++++++++--------
2 files changed, 42 insertions(+), 17 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..cf25070 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1254,6 +1254,9 @@ platforms are moved over to use the flattened-device-tree model.
services interrupts for this device.
- phy-handle : The phandle for the PHY connected to this ethernet
controller.
+ - fixed-link : <a b c> where a is emulated phy id - choose any,
+ but unique to the all specified fixed-links, b is duplex - 0 half,
+ 1 full, c is link speed - d#10/d#100/d#1000.
Recommended properties:
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..e06a5c9 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -24,6 +24,7 @@
#include <linux/platform_device.h>
#include <linux/of_platform.h>
#include <linux/phy.h>
+#include <linux/phy_fixed.h>
#include <linux/spi/spi.h>
#include <linux/fsl_devices.h>
#include <linux/fs_enet_pd.h>
@@ -193,7 +194,6 @@ static const char *gfar_tx_intr = "tx";
static const char *gfar_rx_intr = "rx";
static const char *gfar_err_intr = "error";
-
static int __init gfar_of_init(void)
{
struct device_node *np;
@@ -277,29 +277,51 @@ static int __init gfar_of_init(void)
gfar_data.interface = PHY_INTERFACE_MODE_MII;
ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
+ if (ph == NULL) {
+ struct fixed_phy_status status = {};
+ u32 *fixed_link;
- if (phy == NULL) {
- ret = -ENODEV;
- goto unreg;
- }
+ fixed_link = (u32*)of_get_property(np, "fixed-link",NULL);
+ if (!fixed_link) {
+ ret = -ENODEV;
+ goto unreg;
+ }
- mdio = of_get_parent(phy);
+ status.link = 1;
+ status.duplex = fixed_link[1];
+ status.speed = fixed_link[2];
+
+ ret = fixed_phy_add(PHY_POLL, fixed_link[0], &status);
+ if (ret)
+ goto unreg;
+
+ gfar_data.bus_id = 0;
+ gfar_data.phy_id = fixed_link[0];
+ } else {
+ phy = of_find_node_by_phandle(*ph);
+
+ if (phy == NULL) {
+ ret = -ENODEV;
+ goto unreg;
+ }
+
+ mdio = of_get_parent(phy);
+
+ id = of_get_property(phy, "reg", NULL);
+ ret = of_address_to_resource(mdio, 0, &res);
+ if (ret) {
+ of_node_put(phy);
+ of_node_put(mdio);
+ goto unreg;
+ }
+
+ gfar_data.phy_id = *id;
+ gfar_data.bus_id = res.start;
- id = of_get_property(phy, "reg", NULL);
- ret = of_address_to_resource(mdio, 0, &res);
- if (ret) {
of_node_put(phy);
of_node_put(mdio);
- goto unreg;
}
- gfar_data.phy_id = *id;
- gfar_data.bus_id = res.start;
-
- of_node_put(phy);
- of_node_put(mdio);
-
ret =
platform_device_add_data(gfar_dev, &gfar_data,
sizeof(struct
^ permalink raw reply related
* [PATCH 3/3] [POWERPC] MPC8349E-mITX: Vitesse 7385 PHY is not connected to the MDIO bus
From: Vitaly Bordug @ 2007-11-26 14:29 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
In-Reply-To: <20071126142906.19642.45540.stgit@localhost.localdomain>
...thus use fixed-link to register proper "Fixed PHY"
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 11 ++---------
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 5072f6d..e2d00f1 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -115,14 +115,6 @@
reg = <1c>;
device_type = "ethernet-phy";
};
-
- /* Vitesse 7385 */
- phy1f: ethernet-phy@1f {
- interrupt-parent = < &ipic >;
- interrupts = <12 8>;
- reg = <1f>;
- device_type = "ethernet-phy";
- };
};
ethernet@24000 {
@@ -159,7 +151,8 @@
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <23 8 24 8 25 8>;
interrupt-parent = < &ipic >;
- phy-handle = < &phy1f >;
+ /* Vitesse 7385 isn't on the MDIO bus */
+ fixed-link = <1 1 d#1000>;
linux,network-index = <1>;
};
^ permalink raw reply related
* Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
From: Joakim Tjernlund @ 2007-11-26 15:04 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, linux-kernel, Jeff Garzik, netdev
In-Reply-To: <20071126142915.19642.5842.stgit@localhost.localdomain>
On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote:
> fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> not connected to the real MDIO bus.
>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> ---
>
> Documentation/powerpc/booting-without-of.txt | 3 +
> arch/powerpc/sysdev/fsl_soc.c | 56 ++++++++++++++++++--------
> 2 files changed, 42 insertions(+), 17 deletions(-)
>
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..cf25070 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1254,6 +1254,9 @@ platforms are moved over to use the flattened-device-tree model.
> services interrupts for this device.
> - phy-handle : The phandle for the PHY connected to this ethernet
> controller.
> + - fixed-link : <a b c> where a is emulated phy id - choose any,
> + but unique to the all specified fixed-links, b is duplex - 0 half,
> + 1 full, c is link speed - d#10/d#100/d#1000.
Good work!
May I suggest adding a "d" to <a b c> where d is flow control - 0 no, 1 yes
flow control or not just popped up here today so I got a use for it.
Jocke
^ permalink raw reply
* initramfs and busybox kernel oops
From: fabien @ 2007-11-26 15:16 UTC (permalink / raw)
To: linuxppc-embedded
hi all,
I'm trying to get busybox working on my custom board mpc855t and linux
kernel 2.6.19 (from eldk 4.1 uclibc). I've built an initramfs that i
link directly in kernel. To verify whether the kernel is able to lauch
the init process i've compiled a small hello world program. But no
when i try with busybox 1.8.1 staticaly linked i got an Oops error
kernel access to bad area. I don't know why the former work fine but
no the latter.
If someone have some ideas for where to look for ?
In my initramfs there is :
in /dev :
crw-r--r-- 1 root root 5, 1 nov 22 13:32 console
crw-rw-rw- 1 root root 1, 3 nov 26 10:10 null
crw------- 1 root root 4, 1 nov 26 10:11 tty1
in /bin :
lrwxrwxrwx 1 root root 7 nov 26 10:17 ash -> busybox*
-rwxr-xr-x 1 root root 793804 nov 26 13:57 busybox*
lrwxrwxrwx 1 root root 7 nov 26 10:17 cat -> busybox*
(and others links)
My init script file (/init) :
#!/bin/sh
/bin/ash
...
Serial: CPM driver $Revision: 0.02 $
cpm_uart: WARNING: no UART devices found on platform bus!
cpm_uart: the driver will guess configuration, but this mode is no
longer supported.
ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
TCP cubic registered
Freeing unused kernel memory: 512k init
execute init process
Hello world test bonjour salut
...
...
ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
TCP cubic registered
Freeing unused kernel memory: 504k init
execute init process
Oops
...
(log_buf) when i try with busybox. log is little bit altered by the
fact i need plug/unplug the cable to reset
001ed154: 6720756e 75736564 206b6572 6e656c20 g unused kernel
001ed164: 6f656d6f 72793a21 3438386b 20696e69 oemory:!488k ini
001ed174: 740a3d37 3e43506f 20756172 745b305d t.=7>CPo uart[0]
001ed184: 3a737461 72747570 0a3c373e 4358cd20 :startup.<7>CX.
001ed194: 75617274 5b305d3a 7365745f 7465726d uart[0]:set_term
001ed1a4: 696f730a 3c343e65 78656375 7d652069 ios.<4>execu}e i
001ed1b4: 6e697420 70f26f63 6573730a 3c343e4f nit p.ocess.<4>O
001ed1c4: 7f70733a 206f6572 6e656c20 61636365 .ps: oernel acce
001ed1d4: 7373206f 66206261 64206172 65612c20 ss of bad area,
001ed1e4: 7379673a 20313121 5f23315d 0a3c343e syg: 11!_#1].<4>
001ed1f4: 4f6f7073 3a206b65 726e656c 24616373 Oops: kernel$acs
001ed204: 67737320 6f662072 61642061 f265612c gss of rad a.ea,
001ed214: 20736967 3a203131 205b2332 5d0a3c34 sig: 11 [#2].<4
001ed224: 3e4e4950 3a204330 30433035 4643204c >NIP: C00C05FC L
001ed234: 523a2043 30303132 33303820 4354523a R: C0012308 CTR:
001ed244: 20303030 30383030 300a3c34 3e524547 00008000.<4>REG
001ed254: 533a2063 30323339 62363020 5c525150 S: c0239b60 \RQP
001ed264: 3a203033 30302020 204e6f74 20746169 : 0300 Not tai
001ed274: 6e746564 20212832 2e362e33 392e3629 nted !(2.6.19.6)
001ed284: 0b3c343e 4d53523a 20f13030 303130b3 .<4>MSR: .00010.
001ed294: 32203c4d 452e4952 2c44523e 60204352 2 <ME.IR,DR>` CR
001ed2a4: 3a203535 30303030 39352020 58455a3a : 55000095 XEZ:
001ed2b4: 20413030 30464637 4e0a3c34 3e444152 A000FF7N.<4>DAR
001ed2c4: 3a213346 30303030 30302c22 44534953 :!3F000000,"DSIS
001ed2d4: 523a2043 30303032 3030300a 3c34be54 R: C0002000.<4.T
001ed2e4: 4153cb20 3d206330 32333762 37305b31 AS. = c0237b70[1
001ed2f4: 5d202769 6e697427 205448d2 4549443a ] 'init' TH.EID:
001ed304: a063b032 33383830 b00a3c36 3e475052 .c.23880..<6>GPR
001ed314: b0303a20 30303030 30343733 20433032 .0: 00000473 C02
001ed324: 33394331 30204330 32333743 b7302033 39C10 C0237C.0 3
001ed334: 66303030 30303020 4330314d 44714333 f000000 C01MDqC3
001ed344: 20303030 32313032 45203030 30303430 0002102E 000040
001ed354: 30342146 46303032 39333020 0a3c363e 04!FF002930 .<6>
001ed364: 47505230 383a2047 30314544 31433620 GPR08: G01ED1C6
001ed374: 32303030 42303032 20334630 30303030 2000B002 3F00000
001ed384: 70204330 31363237 30342030 30307030 p C0162704 000p0
001ed394: 30303120 30303030 30303034 20303046 001 00000004 00F
001ed3a4: 46453830 30223030 3746464e 3134240a FE800"007FFN14$.
001ed3b4: 3c363e47 50d231b6 3a203030 30303030 <6>GP.1.: 000000
001ed3c4: 30302030 30b13030 30303120 30303f46 00 00.00001 00?F
001ed3d4: 46463030 204b3031 36303030 30205330 FF00 K0160000 S0
...
thank a lot for help
fab
^ permalink raw reply
* Re: Debugging with gdbserver slow
From: khollan @ 2007-11-26 15:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <13865715.post@talk.nabble.com>
khollan wrote:
>
> Hi everyone,
>
> Im using gdbserver to debug Linux apps on my embedded board, but it takes
> like 3-6 sec to step one line of code. Its about the same to go from
> breakpoint to breakpont. Im using TCP to connect the host to the target.
> Is this typical or is there some setting wrong or was it built wrong. Its
> a PPC405 in a Xilinx FPGA.
>
> Thanks
>
> khollan
>
How long does it take everyone else to step through code serial or TCP?
--
View this message in context: http://www.nabble.com/Debugging-with-gdbserver-slow-tf4846374.html#a13951808
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
From: Kumar Gala @ 2007-11-26 15:41 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200711252322.09370.arnd@arndb.de>
On Nov 25, 2007, at 4:22 PM, Arnd Bergmann wrote:
> On Wednesday 21 November 2007, Kumar Gala wrote:
>> + * Freescale 8xxx/3.0 Gb/s SATA nodes
>> +
>> + SATA nodes are defined to describe on-chip Serial ATA
>> controllers.
>> + Each SATA port should have its own node.
>> +
>> + Required properties:
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,sata-CHIP", where CHIP is the processor
>> + (mpc8315, mpc8379, etc.) and the second is
>> + "fsl,sata-pq2pro"
>> + - interrupts : <interrupt mapping for SATA IRQ>
>> + - interrupt-parent : optional, if needed for interrupt mapping
>> + - reg : <registers mapping>
>> +
>
> Should this maybe also mandate a compatible property that is defined
> in a way to match the generic (p)ata_of_platform driver?
Is there something about the (p)ata_of_platform driver you think we
can use. The SATA controller here is a unique piece of HW and
requires a unique driver so I'm not sure what we get from
(p)ata_of_platform.
- k
^ permalink raw reply
* Re: [PATCH] ehea: Add kdump support
From: Luke Browning @ 2007-11-26 15:41 UTC (permalink / raw)
To: michael
Cc: Michael Neuling, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, Thomas Klein, linux-ppc, Christoph Raisch,
Paul Mackerras, Marcus Eder, Stefan Roscher
In-Reply-To: <1196064988.19855.15.camel@concordia>
On Mon, 2007-11-26 at 19:16 +1100, Michael Ellerman wrote:
>
> Hi Thomas,
>
> I'm sorry, but this patch is all wrong IMHO.
>
> For kdump we have to assume that the kernel is fundamentally broken,
> we've panicked, so something bad has happened - every line of kernel
> code that is run decreases the chance that we'll successfully make it
> into the kdump kernel.
I agree with Michael.
> Solutions that might be better:
>
> a) if there are a finite number of handles and we can predict their
> values, just delete them all in the kdump kernel before the driver
> loads.
This is a good solution if handles are predefined.
> b) if there are a small & finite number of handles, save their values
> in a device tree property and have the kdump kernel read them and
> delete them before the driver loads.
Also good but is more complicated.
> c) if neither of those work, provide a minimal routine that _only_
> deletes the handles in the crashed kernel.
> d) <something else>
Can the driver or configuration method for the driver query PHYP to
determine if there are any pre-existing mappings...
Regards, Luke
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Scott Wood @ 2007-11-26 15:44 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4744D2AE.60902@freescale.com>
Timur Tabi wrote:
> David Gibson wrote:
>
>> Indeed, indexing or writing into shared registers is exactly what
>> cell-index is for.
>
> I don't care whether it's cell-index or device-id, but I need to know
> which DMA controller is #0 and which one is #1, and I need to know which
> channel is #0, which one is #1, etc.
OK, cell-index makes sense there too, then.
-Scott
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Timur Tabi @ 2007-11-26 15:51 UTC (permalink / raw)
To: Grant Likely, Jon Smirl, PowerPC dev list, Timur Tabi
In-Reply-To: <20071120005941.GC3126@localhost.localdomain>
David Gibson wrote:
> 1) We have a "universal" device-tree-based fabric driver which
> parses all the above-described interconnection information in the
> device tree and handles any situation. Cool, but probably a lot of
> work and fiddly to get right.
Definitely a lot of work. I suggest we wait until there are a few PowerPC ASOC
v2 audio drivers in the kernel before we even consider this. And it may not
even be possible. I can easily imagine situations where we need board-specific
code that belongs in a machine-specific fabric driver.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [RFC/PATCHv3] powerpc: Move CPM command handling into the cpm drivers
From: Scott Wood @ 2007-11-26 15:52 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <474886C2.7030609@scram.de>
Jochen Friedrich wrote:
> diff --git a/arch/powerpc/sysdev/commproc.c
> b/arch/powerpc/sysdev/commproc.c
> index f6a6378..2426bcb 100644
> --- a/arch/powerpc/sysdev/commproc.c
> +++ b/arch/powerpc/sysdev/commproc.c
> @@ -240,6 +240,34 @@ void __init cpm_reset(void)
> #endif
> }
>
> +static DEFINE_SPINLOCK(cmd_lock);
> +
> +#define MAX_CR_CMD_LOOPS 10000
> +
> +int cpm_command(u32 command, u8 opcode)
> +{
> + int i, ret;
> + unsigned long flags;
> +
> + if (command & 0xffffff0f)
> + return -EINVAL;
> +
> + spin_lock_irqsave(&cmd_lock, flags);
I'm a little uneasy about this -- what's the longest it can take for the
CPM command to complete (or timeout)? I'd rather use a mutex, if we can
make sure that it's never called from atomic context.
> +
> + ret = 0;
> + out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode << 8));
> + for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
> + if ((in_be16(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
> + goto out;
> +
> + printk(KERN_ERR "%s(): Not able to issue CPM command\n",
> __FUNCTION__);
> + ret = -EIO;
> +out:
> + spin_unlock_irqrestore(&cmd_lock, flags);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(cpm_command);
Can we please not play the GPL DRM game here?
Besides, Documentation/DocBook/kernel-hacking.tmpl explicitly says that
"It implies that the function is considered an internal implementation
issue, and not really an interface."
I don't think this is the case here.
-Scott
^ permalink raw reply
* Sequoia EMAC only works if u-boot initializes it?
From: Steven A. Falco @ 2007-11-26 15:59 UTC (permalink / raw)
To: linuxppc-dev
I have noticed odd behavior on a Sequoia board. Kernel is built from
DENX git, ARCH=powerpc, 2.6.23.1.
Sequence that works:
1) In u-boot, do "dhcp" (this initializes the PHY)
2) Boot linux from flash
3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
Ethernet is now functional, and I can ping the Sequoia (and it can ping
my host)
Sequence that does not work:
1) Boot linux from flash without letting u-boot touch eth0
2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
Ethernet appears to come up, but it is not functional. I.e. I get
"eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board,
and the board cannot ping my host.
So, the kernel appears to be missing some initialization that u-boot
provides.
However, eth1 is more strange. U-boot can use it (via "setenv ethact
ppc_4xx_eth1;dhcp"), however, the kernel cannot use it, whether or not
u-boot first initializes it.
If anyone has suggestions on where to look, I'd appreciate it. I'm
going to look at the PHY register settings and see if there are any
clues there...
Steve
^ permalink raw reply
* Re: The question about the UART on UCC5,UCC6,UCC7,UCC8 for MPC8360?
From: Timur Tabi @ 2007-11-26 15:33 UTC (permalink / raw)
To: ??; +Cc: linuxppc-embedded
In-Reply-To: <396048835.09329@tsinghua.org.cn>
?? wrote:
> after compiled, I download the linux to MPC8360 board, but I cannot find the
> serial device for UCC5,UCC6,UCC7,UCC8. I just find the ttyS0,ttyS1 is OK.
> Could you tell me that what's the name for the serial device of UCC5,6,7,8?
> Whether or not I can use those UART just like the ttyS0,ttyS1?
I don't know why the BSP offers a UART driver for the 8360, because the driver
isn't available yet. I'm working on that, though. I'll post the driver in a
week or so, and it will be included in 2.6.25. You'll have to ask the BSP
support line if they plan on updating the BSP to include the new driver.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
From: Arnd Bergmann @ 2007-11-26 16:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <CAF0919C-0116-403C-A8C5-024B43480D77@kernel.crashing.org>
On Monday 26 November 2007, you wrote:
> On Nov 25, 2007, at 4:22 PM, Arnd Bergmann wrote:
> > Should this maybe also mandate a compatible property that is defined
> > in a way to match the generic (p)ata_of_platform driver?
>=20
> Is there something about the (p)ata_of_platform driver you think we =A0
> can use. =A0The SATA controller here is a unique piece of HW and =A0
> requires a unique driver so I'm not sure what we get from =A0
> (p)ata_of_platform.
All ata controllers I've dealt with so far are to some degree compatible
to the old PC style controllers. My point was that this should ideally
be reflected in the device tree so that you could in theory use the
ata_of_platform driver, even if you normally would prefer the new
driver for performance reasons.
If your controller doesn't have the legacy register set, this clearly
doesn't make any sense and you should not list it as compatible with
something generic.
Arnd <><
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Josh Boyer @ 2007-11-26 16:08 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <474AED67.4020006@harris.com>
On Mon, 26 Nov 2007 10:59:35 -0500
"Steven A. Falco" <sfalco@harris.com> wrote:
> I have noticed odd behavior on a Sequoia board. Kernel is built from
> DENX git, ARCH=powerpc, 2.6.23.1.
>
> Sequence that works:
> 1) In u-boot, do "dhcp" (this initializes the PHY)
> 2) Boot linux from flash
> 3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet is now functional, and I can ping the Sequoia (and it can ping
> my host)
>
> Sequence that does not work:
> 1) Boot linux from flash without letting u-boot touch eth0
> 2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet appears to come up, but it is not functional. I.e. I get
> "eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board,
> and the board cannot ping my host.
>
> So, the kernel appears to be missing some initialization that u-boot
> provides.
There are some PHY patches from Valentine that Ben needs to send to
Jeff Garzik.
josh
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Johannes Berg @ 2007-11-26 16:23 UTC (permalink / raw)
To: Linux Kernel list; +Cc: linuxppc-dev list
In-Reply-To: <1195814816.4149.94.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 207 bytes --]
Contrary to what I claimed later in the thread, my 64-bit powerpc box
(quad-core G5) doesn't suffer from this problem.
Does anybody have any idea? I don't even know how to debug it further.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Stefan Roese @ 2007-11-26 16:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <474AED67.4020006@harris.com>
On Monday 26 November 2007, Steven A. Falco wrote:
> I have noticed odd behavior on a Sequoia board. Kernel is built from
> DENX git, ARCH=powerpc, 2.6.23.1.
>
> Sequence that works:
> 1) In u-boot, do "dhcp" (this initializes the PHY)
> 2) Boot linux from flash
> 3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet is now functional, and I can ping the Sequoia (and it can ping
> my host)
>
> Sequence that does not work:
> 1) Boot linux from flash without letting u-boot touch eth0
> 2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet appears to come up, but it is not functional. I.e. I get
> "eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board,
> and the board cannot ping my host.
Do you have a 100MBit connection? Or Gbit? Could you please send the complete
bootlog.
> So, the kernel appears to be missing some initialization that u-boot
> provides.
>
> However, eth1 is more strange. U-boot can use it (via "setenv ethact
> ppc_4xx_eth1;dhcp"), however, the kernel cannot use it, whether or not
> u-boot first initializes it.
>
> If anyone has suggestions on where to look, I'd appreciate it. I'm
> going to look at the PHY register settings and see if there are any
> clues there...
Again it would be interesting to see the bootlog here.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Scott Wood @ 2007-11-26 16:24 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20071123005121.4d38d877@kernel.crashing.org>
On Fri, Nov 23, 2007 at 12:51:21AM +0300, Vitaly Bordug wrote:
> Even that might be not enough - we may have simultaneous call of this func
> in non-smp case...
Do you really think that every piece of code that uses spinlocks in the
kernel is broken on non-SMP?
> I was thinking of some kind of refcount, so one that is going to issue CPM
> command, must do say pq_cpmp_get() and another driver won't be able to
> mangle with cpcr while it's not done with previous request.
How on earth are you going to effect mutual exclusion using reference
counting?
-Scott
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Jon Smirl @ 2007-11-26 16:33 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev, Michel D?nzer
In-Reply-To: <20071126102414.GF14557@curie-int.orbis-terrarum.net>
On 11/26/07, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Mon, Nov 26, 2007 at 10:20:14AM +0100, Michel D?nzer wrote:
> > > Regarding the sub-thread on x86 emulation, that is totally out of scope
> > > for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I
> > > may have minor errors here, ask airlied if you need more
> > > clarification):
> > > a) Initialization code (I think arch-specific)
> > > b) AtomBIOS script interpreter (I think arch-specific)
> > > c) AtomBIOS scripts (card-specific, but not arch-specific)
> > > d) Data tables (card-specific, but not arch-specific)
> > >
> > > The AtomBIOS parts of the various drivers need data from c+d primarily,
> > > and provide their own script interpreter, or not using the scripts, just
> > > the data tables.
> > Are you sure the X1900 Mac Edition ROM contains any ATOM data structures
> > though? I rather doubt it.
> That's what I'm trying to ascertain actually, because it directly
> impacts what work needs to be done in the drivers.
>
> If it was me writing the ROMs in the first place (but it's not), from
> what I understand of the ATOM, I'd have OpenFirmware versions of a+b,
> and then could re-use c+d.
>
> The fact that both Nvidia and ATI OF-powered cards fail when trying to
> access their expansion ROMs, I'm inclined to think there is something in
> accessing them that we are missing, and that the ROMs must exist (the
> sata_mv one existed and was accessible).
There may well be bugs in the ROM access code on the PowerPC. I don't
own the appropriate hardware nedded to check it out. I'm not sure that
the code has been used on the PowerPC very much. People use it on the
x86 all of the time so it is working fairly well there. But the
generic PowerPC code seems to be working since you can read the
sata_mv ROM.
Did you check out the cards on x86 and ascertain that they have the
standard PCI header in them? 55 AA .... All PCI ROMs are supposed to
have that. If they are missing that the size code in the rom.c isn't
going to work right.
If these are OF ROM and you are booting on OF firmware, the ROM is
getting run. In that case it may not be so simple to turn them back on
if they have been hidden using a proprietary register. That's the
quirk BenH has referred to.
>
> On actually accessing the rest of the ATI X1900 card, the avivotool from
> git://people.freedesktop.org/~airlied/radeontool.git (avivo branch) can
> actually access the rest of the rest of the card registers.
>
> --
> Robin Hugh Johnson
> Gentoo Linux Developer & Infra Guy
> E-Mail : robbat2@gentoo.org
> GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-26 16:38 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <474AEB6A.40408@freescale.com>
On 11/26/07, Timur Tabi <timur@freescale.com> wrote:
> David Gibson wrote:
>
> > 1) We have a "universal" device-tree-based fabric driver which
> > parses all the above-described interconnection information in the
> > device tree and handles any situation. Cool, but probably a lot of
> > work and fiddly to get right.
>
> Definitely a lot of work. I suggest we wait until there are a few PowerPC ASOC
> v2 audio drivers in the kernel before we even consider this. And it may not
> even be possible. I can easily imagine situations where we need board-specific
> code that belongs in a machine-specific fabric driver.
I'm fixing up the asoc v2 code to use MODULE_DEVICE_TABLE() and the
real kernel aliasing/insmod system. Half of why we are having trouble
is because asoc isn't using this mechanism. I've posted patches fixing
i2c to use the same mechanism. I don't have the asoc ones ready yet.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ 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