summaryrefslogtreecommitdiff
path: root/drivers/net/ibm_newemac/core.h
AgeCommit message (Collapse)Author
2008-04-25ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaroundValentine Barshak
This patch adds ibm_newemac PHY clock workaround for 440EP/440GR EMAC attached to a PHY which doesn't generate RX clock if there is no link. The code is based on the previous ibm_emac driver stuff. The 440EP/440GR allows controlling each EMAC clock separately as opposed to global clock selection for 440GX. BenH: Made that #ifdef CONFIG_PPC_DCR_NATIVE for now as dcri_* stuff doesn't exist for MMIO type DCRs like Cell. Some future rework & improvements of the DCR infrastructure will make that cleaner but for now, this makes it work. Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-04-25ibm_newemac: PowerPC 440GX EMAC PHY clock workaroundValentine Barshak
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error) if there's no link. Because of that it fails to find PHY chip. The older ibm_emac driver had a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL macros, which toggle the Ethernet Clock Select bit in the SDR0_MFR register. This patch does the same for "ibm,emac-440gx" compatible chips. The workaround forces clock on -all- EMACs, so we select clock under global emac_phy_map_lock. BenH: Made that #ifdef CONFIG_PPC_DCR_NATIVE for now as dcri_* stuff doesn't exist for MMIO type DCRs like Cell. Some future rework & improvements of the DCR infrastructure will make that cleaner but for now, this makes it work. Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2007-12-07ibm_newemac: Update file headers copyright noticesBenjamin Herrenschmidt
This updates the copyright notices of the new EMAC driver to avoid confusion as who is to be blamed for new bugs. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-12-07ibm_newemac: Cleanup/fix support for STACR register variantsBenjamin Herrenschmidt
There are a few variants of the STACR register that affect more than just the "AXON" version of EMAC. Replace the current test of various chip models with tests for generic properties in the device-tree. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Stefan Roese <sr@denx.de> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-11-23ibm_newemac: Fix possible lockup on closeBenjamin Herrenschmidt
It's a bad idea to call flush_scheduled_work from within a netdev->stop because the linkwatch will occasionally take the rtnl lock from a workqueue context, and thus that can deadlock. This reworks things a bit in that area to avoid the problem. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-10Device tree aware EMAC driverDavid Gibson
Based on BenH's earlier work, this is a new version of the EMAC driver for the built-in ethernet found on PowerPC 4xx embedded CPUs. The same ASIC is also found in the Axon bridge chip. This new version is designed to work in the arch/powerpc tree, using the device tree to probe the device, rather than the old and ugly arch/ppc OCP layer. This driver is designed to sit alongside the old driver (that lies in drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The old driver is left in place to support arch/ppc until arch/ppc itself reaches its final demise (not too long now, with luck). This driver still has a number of things that could do with cleaning up, but I think they can be fixed up after merging. Specifically: - Should be adjusted to properly use the dma mapping API. Axon needs this. - Probe logic needs reworking, in conjuction with the general probing code for of_platform devices. The dependencies here between EMAC, MAL, ZMII etc. make this complicated. At present, it usually works, because we initialize and register the sub-drivers before the EMAC driver itself, and (being in driver code) runs after the devices themselves have been instantiated from the device tree. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Jeff Garzik <jeff@garzik.org>