Device tree aware EMAC driver
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>
2007-08-23 13:56:01 +10:00
|
|
|
/*
|
2012-01-27 13:36:01 +00:00
|
|
|
* drivers/net/ethernet/ibm/emac/zmii.h
|
Device tree aware EMAC driver
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>
2007-08-23 13:56:01 +10:00
|
|
|
*
|
|
|
|
|
* Driver for PowerPC 4xx on-chip ethernet controller, ZMII bridge support.
|
|
|
|
|
*
|
2007-12-05 11:14:33 +11:00
|
|
|
* Copyright 2007 Benjamin Herrenschmidt, IBM Corp.
|
|
|
|
|
* <benh@kernel.crashing.org>
|
|
|
|
|
*
|
|
|
|
|
* Based on the arch/ppc version of the driver:
|
|
|
|
|
*
|
Device tree aware EMAC driver
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>
2007-08-23 13:56:01 +10:00
|
|
|
* Copyright (c) 2004, 2005 Zultys Technologies.
|
|
|
|
|
* Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
|
|
|
|
|
*
|
|
|
|
|
* Based on original work by
|
|
|
|
|
* Armin Kuster <akuster@mvista.com>
|
|
|
|
|
* Copyright 2001 MontaVista Softare 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.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
#ifndef __IBM_NEWEMAC_ZMII_H
|
|
|
|
|
#define __IBM_NEWEMAC_ZMII_H
|
|
|
|
|
|
|
|
|
|
/* ZMII bridge registers */
|
|
|
|
|
struct zmii_regs {
|
|
|
|
|
u32 fer; /* Function enable reg */
|
|
|
|
|
u32 ssr; /* Speed select reg */
|
|
|
|
|
u32 smiirs; /* SMII status reg */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* ZMII device */
|
|
|
|
|
struct zmii_instance {
|
|
|
|
|
struct zmii_regs __iomem *base;
|
|
|
|
|
|
|
|
|
|
/* Only one EMAC whacks us at a time */
|
|
|
|
|
struct mutex lock;
|
|
|
|
|
|
|
|
|
|
/* subset of PHY_MODE_XXXX */
|
|
|
|
|
int mode;
|
|
|
|
|
|
|
|
|
|
/* number of EMACs using this ZMII bridge */
|
|
|
|
|
int users;
|
|
|
|
|
|
|
|
|
|
/* FER value left by firmware */
|
|
|
|
|
u32 fer_save;
|
|
|
|
|
|
|
|
|
|
/* OF device instance */
|
2010-08-06 09:25:50 -06:00
|
|
|
struct platform_device *ofdev;
|
Device tree aware EMAC driver
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>
2007-08-23 13:56:01 +10:00
|
|
|
};
|
|
|
|
|
|
2011-08-18 21:33:49 -07:00
|
|
|
#ifdef CONFIG_IBM_EMAC_ZMII
|
Device tree aware EMAC driver
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>
2007-08-23 13:56:01 +10:00
|
|
|
|
|
|
|
|
extern int zmii_init(void);
|
|
|
|
|
extern void zmii_exit(void);
|
2010-08-06 09:25:50 -06:00
|
|
|
extern int zmii_attach(struct platform_device *ofdev, int input, int *mode);
|
|
|
|
|
extern void zmii_detach(struct platform_device *ofdev, int input);
|
|
|
|
|
extern void zmii_get_mdio(struct platform_device *ofdev, int input);
|
|
|
|
|
extern void zmii_put_mdio(struct platform_device *ofdev, int input);
|
|
|
|
|
extern void zmii_set_speed(struct platform_device *ofdev, int input, int speed);
|
|
|
|
|
extern int zmii_get_regs_len(struct platform_device *ocpdev);
|
|
|
|
|
extern void *zmii_dump_regs(struct platform_device *ofdev, void *buf);
|
Device tree aware EMAC driver
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>
2007-08-23 13:56:01 +10:00
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
# define zmii_init() 0
|
|
|
|
|
# define zmii_exit() do { } while(0)
|
|
|
|
|
# define zmii_attach(x,y,z) (-ENXIO)
|
|
|
|
|
# define zmii_detach(x,y) do { } while(0)
|
|
|
|
|
# define zmii_get_mdio(x,y) do { } while(0)
|
|
|
|
|
# define zmii_put_mdio(x,y) do { } while(0)
|
|
|
|
|
# define zmii_set_speed(x,y,z) do { } while(0)
|
|
|
|
|
# define zmii_get_regs_len(x) 0
|
|
|
|
|
# define zmii_dump_regs(x,buf) (buf)
|
2011-08-18 21:33:49 -07:00
|
|
|
#endif /* !CONFIG_IBM_EMAC_ZMII */
|
Device tree aware EMAC driver
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>
2007-08-23 13:56:01 +10:00
|
|
|
|
|
|
|
|
#endif /* __IBM_NEWEMAC_ZMII_H */
|