iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
8ff499e43c
linux/drivers/net/ibm_newemac/mal.h

317 lines
8.8 KiB
C
Raw Normal View History

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 07:56:01 +04:00
/*
* drivers/net/ibm_newemac/mal.h
*
* Memory Access Layer (MAL) support
*
ibm_newemac: Update file headers copyright notices 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-05 03:14:33 +03: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 07:56:01 +04: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 2002 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_MAL_H
#define __IBM_NEWEMAC_MAL_H
/*
* There are some variations on the MAL, we express them in this driver as
* MAL Version 1 and 2 though that doesn't match any IBM terminology.
*
* We call MAL 1 the version in 405GP, 405GPR, 405EP, 440EP, 440GR and
* NP405H.
*
* We call MAL 2 the version in 440GP, 440GX, 440SP, 440SPE and Axon
*
* The driver expects a "version" property in the emac node containing
* a number 1 or 2. New device-trees for EMAC capable platforms are thus
* required to include that when porting to arch/powerpc.
*/
/* MALx DCR registers */
#define MAL_CFG 0x00
#define MAL_CFG_SR 0x80000000
#define MAL_CFG_PLBB 0x00004000
#define MAL_CFG_OPBBL 0x00000080
#define MAL_CFG_EOPIE 0x00000004
#define MAL_CFG_LEA 0x00000002
#define MAL_CFG_SD 0x00000001
/* MAL V1 CFG bits */
#define MAL1_CFG_PLBP_MASK 0x00c00000
#define MAL1_CFG_PLBP_10 0x00800000
#define MAL1_CFG_GA 0x00200000
#define MAL1_CFG_OA 0x00100000
#define MAL1_CFG_PLBLE 0x00080000
#define MAL1_CFG_PLBT_MASK 0x00078000
#define MAL1_CFG_DEFAULT (MAL1_CFG_PLBP_10 | MAL1_CFG_PLBT_MASK)
/* MAL V2 CFG bits */
#define MAL2_CFG_RPP_MASK 0x00c00000
#define MAL2_CFG_RPP_10 0x00800000
#define MAL2_CFG_RMBS_MASK 0x00300000
#define MAL2_CFG_WPP_MASK 0x000c0000
#define MAL2_CFG_WPP_10 0x00080000
#define MAL2_CFG_WMBS_MASK 0x00030000
#define MAL2_CFG_PLBLE 0x00008000
#define MAL2_CFG_DEFAULT (MAL2_CFG_RMBS_MASK | MAL2_CFG_WMBS_MASK | \
MAL2_CFG_RPP_10 | MAL2_CFG_WPP_10)
#define MAL_ESR 0x01
#define MAL_ESR_EVB 0x80000000
#define MAL_ESR_CIDT 0x40000000
#define MAL_ESR_CID_MASK 0x3e000000
#define MAL_ESR_CID_SHIFT 25
#define MAL_ESR_DE 0x00100000
#define MAL_ESR_OTE 0x00040000
#define MAL_ESR_OSE 0x00020000
#define MAL_ESR_PEIN 0x00010000
#define MAL_ESR_DEI 0x00000010
#define MAL_ESR_OTEI 0x00000004
#define MAL_ESR_OSEI 0x00000002
#define MAL_ESR_PBEI 0x00000001
/* MAL V1 ESR bits */
#define MAL1_ESR_ONE 0x00080000
#define MAL1_ESR_ONEI 0x00000008
/* MAL V2 ESR bits */
#define MAL2_ESR_PTE 0x00800000
#define MAL2_ESR_PRE 0x00400000
#define MAL2_ESR_PWE 0x00200000
#define MAL2_ESR_PTEI 0x00000080
#define MAL2_ESR_PREI 0x00000040
#define MAL2_ESR_PWEI 0x00000020
#define MAL_IER 0x02
#define MAL_IER_DE 0x00000010
#define MAL_IER_OTE 0x00000004
#define MAL_IER_OE 0x00000002
#define MAL_IER_PE 0x00000001
/* MAL V1 IER bits */
#define MAL1_IER_NWE 0x00000008
#define MAL1_IER_SOC_EVENTS MAL1_IER_NWE
ibm_newemac: MAL[12]_IER_EVENTS definition: 2x *_OTE -> *_DE MAL[12]_IER_EVENTS definitions have MAL_IER_OTE twice but lack MAL_IER_DE Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-08-31 00:48:24 +04:00
#define MAL1_IER_EVENTS (MAL1_IER_SOC_EVENTS | MAL_IER_DE | \
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 07:56:01 +04:00
MAL_IER_OTE | MAL_IER_OE | MAL_IER_PE)
/* MAL V2 IER bits */
#define MAL2_IER_PT 0x00000080
#define MAL2_IER_PRE 0x00000040
#define MAL2_IER_PWE 0x00000020
#define MAL2_IER_SOC_EVENTS (MAL2_IER_PT | MAL2_IER_PRE | MAL2_IER_PWE)
ibm_newemac: MAL[12]_IER_EVENTS definition: 2x *_OTE -> *_DE MAL[12]_IER_EVENTS definitions have MAL_IER_OTE twice but lack MAL_IER_DE Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-08-31 00:48:24 +04:00
#define MAL2_IER_EVENTS (MAL2_IER_SOC_EVENTS | MAL_IER_DE | \
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 07:56:01 +04:00
MAL_IER_OTE | MAL_IER_OE | MAL_IER_PE)
#define MAL_TXCASR 0x04
#define MAL_TXCARR 0x05
#define MAL_TXEOBISR 0x06
#define MAL_TXDEIR 0x07
#define MAL_RXCASR 0x10
#define MAL_RXCARR 0x11
#define MAL_RXEOBISR 0x12
#define MAL_RXDEIR 0x13
#define MAL_TXCTPR(n) ((n) + 0x20)
#define MAL_RXCTPR(n) ((n) + 0x40)
#define MAL_RCBS(n) ((n) + 0x60)
/* In reality MAL can handle TX buffers up to 4095 bytes long,
* but this isn't a good round number :) --ebs
*/
#define MAL_MAX_TX_SIZE 4080
#define MAL_MAX_RX_SIZE 4080
static inline int mal_rx_size(int len)
{
len = (len + 0xf) & ~0xf;
return len > MAL_MAX_RX_SIZE ? MAL_MAX_RX_SIZE : len;
}
static inline int mal_tx_chunks(int len)
{
return (len + MAL_MAX_TX_SIZE - 1) / MAL_MAX_TX_SIZE;
}
#define MAL_CHAN_MASK(n) (0x80000000 >> (n))
/* MAL Buffer Descriptor structure */
struct mal_descriptor {
u16 ctrl; /* MAL / Commac status control bits */
u16 data_len; /* Max length is 4K-1 (12 bits) */
u32 data_ptr; /* pointer to actual data buffer */
};
/* the following defines are for the MadMAL status and control registers. */
/* MADMAL transmit and receive status/control bits */
#define MAL_RX_CTRL_EMPTY 0x8000
#define MAL_RX_CTRL_WRAP 0x4000
#define MAL_RX_CTRL_CM 0x2000
#define MAL_RX_CTRL_LAST 0x1000
#define MAL_RX_CTRL_FIRST 0x0800
#define MAL_RX_CTRL_INTR 0x0400
#define MAL_RX_CTRL_SINGLE (MAL_RX_CTRL_LAST | MAL_RX_CTRL_FIRST)
#define MAL_IS_SINGLE_RX(ctrl) (((ctrl) & MAL_RX_CTRL_SINGLE) == MAL_RX_CTRL_SINGLE)
#define MAL_TX_CTRL_READY 0x8000
#define MAL_TX_CTRL_WRAP 0x4000
#define MAL_TX_CTRL_CM 0x2000
#define MAL_TX_CTRL_LAST 0x1000
#define MAL_TX_CTRL_INTR 0x0400
struct mal_commac_ops {
void (*poll_tx) (void *dev);
int (*poll_rx) (void *dev, int budget);
int (*peek_rx) (void *dev);
void (*rxde) (void *dev);
};
struct mal_commac {
struct mal_commac_ops *ops;
void *dev;
struct list_head poll_list;
long flags;
#define MAL_COMMAC_RX_STOPPED 0
#define MAL_COMMAC_POLL_DISABLED 1
u32 tx_chan_mask;
u32 rx_chan_mask;
struct list_head list;
};
struct mal_instance {
int version;
dcr_host_t dcr_host;
int num_tx_chans; /* Number of TX channels */
int num_rx_chans; /* Number of RX channels */
int txeob_irq; /* TX End Of Buffer IRQ */
int rxeob_irq; /* RX End Of Buffer IRQ */
int txde_irq; /* TX Descriptor Error IRQ */
int rxde_irq; /* RX Descriptor Error IRQ */
int serr_irq; /* MAL System Error IRQ */
struct list_head poll_list;
ibm_emac: Convert to use napi_struct independent of struct net_device Commit da3dedd9 ("[NET]: Make NAPI polling independent of struct net_device objects.") changed the interface to NAPI polling. Fix up the ibm_newemac driver so that it works with this new interface. This is actually a nice cleanup because ibm_newemac is one of the drivers that wants to have multiple NAPI structures for a single net_device. Compile-tested only as I don't have a system that uses the ibm_newemac driver. This conversion the conversion for the ibm_emac driver that was tested on real PowerPC 440SPe hardware. Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-10 02:48:56 +04:00
struct napi_struct napi;
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 07:56:01 +04:00
struct list_head list;
u32 tx_chan_mask;
u32 rx_chan_mask;
dma_addr_t bd_dma;
struct mal_descriptor *bd_virt;
struct of_device *ofdev;
int index;
spinlock_t lock;
ibm_newemac: Introduce mal_has_feature There are some PowerPC SoCs that do odd things with the MAL handling. In order to accommodate them, we need to introduce a feature mechanism that is similar to the existing emac_has_feature function. This adds a feature variable to the mal_instance structure, and adds a mal_has_feature function. Two features are defined and are guarded by Kconfig options that are selected by the affected platforms. MAL_FTR_CLEAR_ICINSTAT is used for platforms that need to clear the interrupt bits in the ICINTSTAT SDR for txeob/rxeob. This is common on MAL implementations that have interrupt coalescing. MAL_FTR_COMMON_ERR_INT is used for platforms that have SERR, TXDE, and RXDE OR'd into a single interrupt bit. Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
2008-09-04 08:03:45 +04:00
net: Add init_dummy_netdev() and fix EMAC driver using it This adds an init_dummy_netdev() function that gets a network device structure (allocation and lifetime entirely under caller's control) and initialize the minimum amount of fields so it can be used to schedule NAPI polls without registering a full blown interface. This is to be used by drivers that need to tie several hardware interfaces to a single NAPI poll scheduler due to HW limitations. It also updates the ibm_newemac driver to use that, this fixing the oops on 2.6.29 due to passing NULL as "dev" to netif_napi_add() Symbol is exported GPL only a I don't think we want binary drivers doing that sort of acrobatics (if we want them at all). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-15 08:05:05 +03:00
struct net_device dummy_dev;
ibm_newemac: Introduce mal_has_feature There are some PowerPC SoCs that do odd things with the MAL handling. In order to accommodate them, we need to introduce a feature mechanism that is similar to the existing emac_has_feature function. This adds a feature variable to the mal_instance structure, and adds a mal_has_feature function. Two features are defined and are guarded by Kconfig options that are selected by the affected platforms. MAL_FTR_CLEAR_ICINSTAT is used for platforms that need to clear the interrupt bits in the ICINTSTAT SDR for txeob/rxeob. This is common on MAL implementations that have interrupt coalescing. MAL_FTR_COMMON_ERR_INT is used for platforms that have SERR, TXDE, and RXDE OR'd into a single interrupt bit. Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
2008-09-04 08:03:45 +04:00
unsigned int features;
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 07:56:01 +04:00
};
static inline u32 get_mal_dcrn(struct mal_instance *mal, int reg)
{
Add dcr_host_t.base in dcr_read()/dcr_write() Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we can save them the trouble and do it in dcr_read()/dcr_write(). As some background to why we just went through all this jiggery-pokery, benh sayeth: Initially the goal of the dcr_read/dcr_write routines was to operate like mfdcr/mtdcr which take absolute DCR numbers. The reason is that on 4xx hardware, indirect DCR access is a pain (goes through a table of instructions) and it's useful to have the compiler resolve an absolute DCR inline. We decided that wasn't worth the API bastardisation since most places where absolute DCR values are used are low level 4xx-only code which may as well continue using mfdcr/mtdcr, while the new API is designed for device "instances" that can exist on 4xx and Axon type platforms and may be located at variable DCR offsets. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-15 13:34:36 +04:00
return dcr_read(mal->dcr_host, reg);
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 07:56:01 +04:00
}
static inline void set_mal_dcrn(struct mal_instance *mal, int reg, u32 val)
{
Add dcr_host_t.base in dcr_read()/dcr_write() Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we can save them the trouble and do it in dcr_read()/dcr_write(). As some background to why we just went through all this jiggery-pokery, benh sayeth: Initially the goal of the dcr_read/dcr_write routines was to operate like mfdcr/mtdcr which take absolute DCR numbers. The reason is that on 4xx hardware, indirect DCR access is a pain (goes through a table of instructions) and it's useful to have the compiler resolve an absolute DCR inline. We decided that wasn't worth the API bastardisation since most places where absolute DCR values are used are low level 4xx-only code which may as well continue using mfdcr/mtdcr, while the new API is designed for device "instances" that can exist on 4xx and Axon type platforms and may be located at variable DCR offsets. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-15 13:34:36 +04:00
dcr_write(mal->dcr_host, reg, val);
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 07:56:01 +04:00
}
ibm_newemac: Introduce mal_has_feature There are some PowerPC SoCs that do odd things with the MAL handling. In order to accommodate them, we need to introduce a feature mechanism that is similar to the existing emac_has_feature function. This adds a feature variable to the mal_instance structure, and adds a mal_has_feature function. Two features are defined and are guarded by Kconfig options that are selected by the affected platforms. MAL_FTR_CLEAR_ICINSTAT is used for platforms that need to clear the interrupt bits in the ICINTSTAT SDR for txeob/rxeob. This is common on MAL implementations that have interrupt coalescing. MAL_FTR_COMMON_ERR_INT is used for platforms that have SERR, TXDE, and RXDE OR'd into a single interrupt bit. Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
2008-09-04 08:03:45 +04:00
/* Features of various MAL implementations */
/* Set if you have interrupt coalescing and you have to clear the SDR
* register for TXEOB and RXEOB interrupts to work
*/
#define MAL_FTR_CLEAR_ICINTSTAT 0x00000001
/* Set if your MAL has SERR, TXDE, and RXDE OR'd into a single UIC
* interrupt
*/
#define MAL_FTR_COMMON_ERR_INT 0x00000002
enum {
MAL_FTRS_ALWAYS = 0,
MAL_FTRS_POSSIBLE =
#ifdef CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT
MAL_FTR_CLEAR_ICINTSTAT |
#endif
#ifdef CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR
MAL_FTR_COMMON_ERR_INT |
#endif
0,
};
static inline int mal_has_feature(struct mal_instance *dev,
unsigned long feature)
{
return (MAL_FTRS_ALWAYS & feature) ||
(MAL_FTRS_POSSIBLE & dev->features & feature);
}
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 07:56:01 +04:00
/* Register MAL devices */
int mal_init(void);
void mal_exit(void);
int mal_register_commac(struct mal_instance *mal,
struct mal_commac *commac);
void mal_unregister_commac(struct mal_instance *mal,
struct mal_commac *commac);
int mal_set_rcbs(struct mal_instance *mal, int channel, unsigned long size);
/* Returns BD ring offset for a particular channel
(in 'struct mal_descriptor' elements)
*/
int mal_tx_bd_offset(struct mal_instance *mal, int channel);
int mal_rx_bd_offset(struct mal_instance *mal, int channel);
void mal_enable_tx_channel(struct mal_instance *mal, int channel);
void mal_disable_tx_channel(struct mal_instance *mal, int channel);
void mal_enable_rx_channel(struct mal_instance *mal, int channel);
void mal_disable_rx_channel(struct mal_instance *mal, int channel);
void mal_poll_disable(struct mal_instance *mal, struct mal_commac *commac);
void mal_poll_enable(struct mal_instance *mal, struct mal_commac *commac);
/* Add/remove EMAC to/from MAL polling list */
void mal_poll_add(struct mal_instance *mal, struct mal_commac *commac);
void mal_poll_del(struct mal_instance *mal, struct mal_commac *commac);
/* Ethtool MAL registers */
struct mal_regs {
u32 tx_count;
u32 rx_count;
u32 cfg;
u32 esr;
u32 ier;
u32 tx_casr;
u32 tx_carr;
u32 tx_eobisr;
u32 tx_deir;
u32 rx_casr;
u32 rx_carr;
u32 rx_eobisr;
u32 rx_deir;
u32 tx_ctpr[32];
u32 rx_ctpr[32];
u32 rcbs[32];
};
int mal_get_regs_len(struct mal_instance *mal);
void *mal_dump_regs(struct mal_instance *mal, void *buf);
#endif /* __IBM_NEWEMAC_MAL_H */
Reference in New Issue Copy Permalink