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 11:56:01 +08:00
|
|
|
/*
|
2012-01-27 21:36:01 +08:00
|
|
|
* drivers/net/ethernet/ibm/emac/tah.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 11:56:01 +08:00
|
|
|
*
|
|
|
|
* Driver for PowerPC 4xx on-chip ethernet controller, TAH support.
|
|
|
|
*
|
2007-12-05 08:14:33 +08: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 11:56:01 +08:00
|
|
|
* Copyright 2004 MontaVista Software, Inc.
|
|
|
|
* Matt Porter <mporter@kernel.crashing.org>
|
|
|
|
*
|
|
|
|
* Copyright (c) 2005 Eugene Surovegin <ebs@ebshome.net>
|
|
|
|
*
|
|
|
|
* 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_TAH_H
|
|
|
|
#define __IBM_NEWEMAC_TAH_H
|
|
|
|
|
|
|
|
/* TAH */
|
|
|
|
struct tah_regs {
|
|
|
|
u32 revid;
|
|
|
|
u32 pad[3];
|
|
|
|
u32 mr;
|
|
|
|
u32 ssr0;
|
|
|
|
u32 ssr1;
|
|
|
|
u32 ssr2;
|
|
|
|
u32 ssr3;
|
|
|
|
u32 ssr4;
|
|
|
|
u32 ssr5;
|
|
|
|
u32 tsr;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/* TAH device */
|
|
|
|
struct tah_instance {
|
|
|
|
struct tah_regs __iomem *base;
|
|
|
|
|
|
|
|
/* Only one EMAC whacks us at a time */
|
|
|
|
struct mutex lock;
|
|
|
|
|
|
|
|
/* number of EMACs using this TAH */
|
|
|
|
int users;
|
|
|
|
|
|
|
|
/* OF device instance */
|
2010-08-06 23:25:50 +08: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 11:56:01 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/* TAH engine */
|
|
|
|
#define TAH_MR_CVR 0x80000000
|
|
|
|
#define TAH_MR_SR 0x40000000
|
|
|
|
#define TAH_MR_ST_256 0x01000000
|
|
|
|
#define TAH_MR_ST_512 0x02000000
|
|
|
|
#define TAH_MR_ST_768 0x03000000
|
|
|
|
#define TAH_MR_ST_1024 0x04000000
|
|
|
|
#define TAH_MR_ST_1280 0x05000000
|
|
|
|
#define TAH_MR_ST_1536 0x06000000
|
|
|
|
#define TAH_MR_TFS_16KB 0x00000000
|
|
|
|
#define TAH_MR_TFS_2KB 0x00200000
|
|
|
|
#define TAH_MR_TFS_4KB 0x00400000
|
|
|
|
#define TAH_MR_TFS_6KB 0x00600000
|
|
|
|
#define TAH_MR_TFS_8KB 0x00800000
|
|
|
|
#define TAH_MR_TFS_10KB 0x00a00000
|
|
|
|
#define TAH_MR_DTFP 0x00100000
|
|
|
|
#define TAH_MR_DIG 0x00080000
|
|
|
|
|
2011-08-19 12:33:49 +08:00
|
|
|
#ifdef CONFIG_IBM_EMAC_TAH
|
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 11:56:01 +08:00
|
|
|
|
2013-09-24 02:37:59 +08:00
|
|
|
int tah_init(void);
|
|
|
|
void tah_exit(void);
|
|
|
|
int tah_attach(struct platform_device *ofdev, int channel);
|
|
|
|
void tah_detach(struct platform_device *ofdev, int channel);
|
|
|
|
void tah_reset(struct platform_device *ofdev);
|
|
|
|
int tah_get_regs_len(struct platform_device *ofdev);
|
|
|
|
void *tah_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 11:56:01 +08:00
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
# define tah_init() 0
|
|
|
|
# define tah_exit() do { } while(0)
|
|
|
|
# define tah_attach(x,y) (-ENXIO)
|
|
|
|
# define tah_detach(x,y) do { } while(0)
|
|
|
|
# define tah_reset(x) do { } while(0)
|
|
|
|
# define tah_get_regs_len(x) 0
|
|
|
|
# define tah_dump_regs(x,buf) (buf)
|
|
|
|
|
2011-08-19 12:33:49 +08:00
|
|
|
#endif /* !CONFIG_IBM_EMAC_TAH */
|
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 11:56:01 +08:00
|
|
|
|
|
|
|
#endif /* __IBM_NEWEMAC_TAH_H */
|