hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
linux-sg2042/include/linux/stmmac.h

116 lines
3.8 KiB
C
Raw Normal View History

stmmac: add the new Header file for stmmac platform data Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-07 07:07:13 +08:00
/*******************************************************************************
Header file for stmmac platform data
Copyright (C) 2009 STMicroelectronics Ltd
This program is free software; you can redistribute it and/or modify it
under the terms and conditions of the GNU General Public License,
version 2, as published by the Free Software Foundation.
This program is distributed in the hope it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
The full GNU General Public License is included in this distribution in
the file called "COPYING".
Author: Giuseppe Cavallaro <peppe.cavallaro@st.com>
*******************************************************************************/
#ifndef __STMMAC_PLATFORM_DATA
#define __STMMAC_PLATFORM_DATA
net/stmmac: Move "#include <linux/platform_device.h>" to linux/stmmac.h stmmac.h uses struct platform_device and doesn't include <linux/platform_device.h>. Whereas drivers/net/stmmac/stmmac.h includes it, but doesn't directly use it. And so we get following compilation warning while using this file: warning: ‘struct platform_device’ declared inside parameter list This patch includes <linux/platform_device.h> in linux/stmmac.h and removes it from drivers/net/stmmac/stmmac.h Signed-off-by: Viresh Kumar <viresh.kumar@st.com> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-05-03 02:36:45 +08:00
#include <linux/platform_device.h>
stmmac: Define CSUM offload engine Types This patch explicitly defines the CSUM offload engine type which need (not mandatory) to be passed from the platform code. STMMAC core supports two check sum offload engine types- Type-1 & Type-2. Also, there are STMMAC cores that do not have the check sum offload capabilities. The behaviour of Type-1 & Type-2 cores related to provision of checksum increases the packet length for Type-1 cores by 2, as the checksum is appended at the end of data packet and the same is made accountable in the DMA status. The STMMAC cores beyond Version-3.5 provide HW interface registers which allows the user to read the HW capabilities, while to support the previous cores the information related to HW capabilities has to be provided from the platform code. The Type-1 cores which do not have the HW register interface need this information. This patch also updates the driver's doc. Signed-off-by: Deepak Sikri <deepak.sikri@st.com> Hacked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:20 +08:00
#define STMMAC_RX_COE_NONE 0
#define STMMAC_RX_COE_TYPE1 1
#define STMMAC_RX_COE_TYPE2 2
stmmac: Define MDC clock selection macros The patch adds the macros to be used for MDC clock selection. The MDC clock frequency is based on scaled system clock, and has to be confined to a range of 1-2.5 MHz. Based on the input CSR clock, the scaling factor has to be selected. The platform specific code will provide the default value of this scaling factor, based on the input CSR clock. There is an option to set MDC clock higher than the IEEE 802.3 specified frequency limit of 2.5 MHz. This applies for the interfacing chips that support higher MDC clocks. The resultant higher clock of 12.5 MHz requires additional Macros to be defined for the clock divider corresponding to the to the following selection. ----------------------------------------- Selection MDC Clock ----------------------------------------- 1000 clk_csr_i/4 1001 clk_csr_i/6 1010 clk_csr_i/8 1011 clk_csr_i/10 1100 clk_csr_i/12 1101 clk_csr_i/14 1110 clk_csr_i/16 1111 clk_csr_i/18 This support has to be added both in the include file, as well as driver. The driver need to program the registers based on the interfacing chips. This would be more board specific information and needs to be passed through the platform code to the driver. This work would be carried out in the future patch set release. Signed-off-by: Deepak Sikri <deepak.sikri@st.com> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:22 +08:00
/* Define the macros for CSR clock range parameters to be passed by
* platform code.
* This could also be configured at run time using CPU freq framework. */
/* MDC Clock Selection define*/
stmmac: extend CSR Clock Range programming The CSR Clock Range has been reworked and new macros has been added in the platform header to allow the CSR Clock Range selection in the GMII Address Register. The previous work didn't add the other fields that can be used to achieve MDC clock of frequency higher than the IEEE 802.3 specified frequency limit of 2.5 MHz and program a clock divider of lower value. On such platforms, these are used indeed so this patch adds them. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:26 +08:00
#define STMMAC_CSR_60_100M 0x0 /* MDC = clk_scr_i/42 */
#define STMMAC_CSR_100_150M 0x1 /* MDC = clk_scr_i/62 */
#define STMMAC_CSR_20_35M 0x2 /* MDC = clk_scr_i/16 */
#define STMMAC_CSR_35_60M 0x3 /* MDC = clk_scr_i/26 */
#define STMMAC_CSR_150_250M 0x4 /* MDC = clk_scr_i/102 */
#define STMMAC_CSR_250_300M 0x5 /* MDC = clk_scr_i/122 */
stmmac: Define MDC clock selection macros The patch adds the macros to be used for MDC clock selection. The MDC clock frequency is based on scaled system clock, and has to be confined to a range of 1-2.5 MHz. Based on the input CSR clock, the scaling factor has to be selected. The platform specific code will provide the default value of this scaling factor, based on the input CSR clock. There is an option to set MDC clock higher than the IEEE 802.3 specified frequency limit of 2.5 MHz. This applies for the interfacing chips that support higher MDC clocks. The resultant higher clock of 12.5 MHz requires additional Macros to be defined for the clock divider corresponding to the to the following selection. ----------------------------------------- Selection MDC Clock ----------------------------------------- 1000 clk_csr_i/4 1001 clk_csr_i/6 1010 clk_csr_i/8 1011 clk_csr_i/10 1100 clk_csr_i/12 1101 clk_csr_i/14 1110 clk_csr_i/16 1111 clk_csr_i/18 This support has to be added both in the include file, as well as driver. The driver need to program the registers based on the interfacing chips. This would be more board specific information and needs to be passed through the platform code to the driver. This work would be carried out in the future patch set release. Signed-off-by: Deepak Sikri <deepak.sikri@st.com> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:22 +08:00
stmmac: extend CSR Clock Range programming The CSR Clock Range has been reworked and new macros has been added in the platform header to allow the CSR Clock Range selection in the GMII Address Register. The previous work didn't add the other fields that can be used to achieve MDC clock of frequency higher than the IEEE 802.3 specified frequency limit of 2.5 MHz and program a clock divider of lower value. On such platforms, these are used indeed so this patch adds them. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:26 +08:00
/* The MDC clock could be set higher than the IEEE 802.3
stmmac: Define MDC clock selection macros The patch adds the macros to be used for MDC clock selection. The MDC clock frequency is based on scaled system clock, and has to be confined to a range of 1-2.5 MHz. Based on the input CSR clock, the scaling factor has to be selected. The platform specific code will provide the default value of this scaling factor, based on the input CSR clock. There is an option to set MDC clock higher than the IEEE 802.3 specified frequency limit of 2.5 MHz. This applies for the interfacing chips that support higher MDC clocks. The resultant higher clock of 12.5 MHz requires additional Macros to be defined for the clock divider corresponding to the to the following selection. ----------------------------------------- Selection MDC Clock ----------------------------------------- 1000 clk_csr_i/4 1001 clk_csr_i/6 1010 clk_csr_i/8 1011 clk_csr_i/10 1100 clk_csr_i/12 1101 clk_csr_i/14 1110 clk_csr_i/16 1111 clk_csr_i/18 This support has to be added both in the include file, as well as driver. The driver need to program the registers based on the interfacing chips. This would be more board specific information and needs to be passed through the platform code to the driver. This work would be carried out in the future patch set release. Signed-off-by: Deepak Sikri <deepak.sikri@st.com> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:22 +08:00
* specified frequency limit 0f 2.5 MHz, by programming a clock divider
* of value different than the above defined values. The resultant MDIO
* clock frequency of 12.5 MHz is applicable for the interfacing chips
* supporting higher MDC clocks.
* The MDC clock selection macros need to be defined for MDC clock rate
* of 12.5 MHz, corresponding to the following selection.
stmmac: extend CSR Clock Range programming The CSR Clock Range has been reworked and new macros has been added in the platform header to allow the CSR Clock Range selection in the GMII Address Register. The previous work didn't add the other fields that can be used to achieve MDC clock of frequency higher than the IEEE 802.3 specified frequency limit of 2.5 MHz and program a clock divider of lower value. On such platforms, these are used indeed so this patch adds them. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:26 +08:00
*/
#define STMMAC_CSR_I_4 0x8 /* clk_csr_i/4 */
#define STMMAC_CSR_I_6 0x9 /* clk_csr_i/6 */
#define STMMAC_CSR_I_8 0xA /* clk_csr_i/8 */
#define STMMAC_CSR_I_10 0xB /* clk_csr_i/10 */
#define STMMAC_CSR_I_12 0xC /* clk_csr_i/12 */
#define STMMAC_CSR_I_14 0xD /* clk_csr_i/14 */
#define STMMAC_CSR_I_16 0xE /* clk_csr_i/16 */
#define STMMAC_CSR_I_18 0xF /* clk_csr_i/18 */
stmmac: Define MDC clock selection macros The patch adds the macros to be used for MDC clock selection. The MDC clock frequency is based on scaled system clock, and has to be confined to a range of 1-2.5 MHz. Based on the input CSR clock, the scaling factor has to be selected. The platform specific code will provide the default value of this scaling factor, based on the input CSR clock. There is an option to set MDC clock higher than the IEEE 802.3 specified frequency limit of 2.5 MHz. This applies for the interfacing chips that support higher MDC clocks. The resultant higher clock of 12.5 MHz requires additional Macros to be defined for the clock divider corresponding to the to the following selection. ----------------------------------------- Selection MDC Clock ----------------------------------------- 1000 clk_csr_i/4 1001 clk_csr_i/6 1010 clk_csr_i/8 1011 clk_csr_i/10 1100 clk_csr_i/12 1101 clk_csr_i/14 1110 clk_csr_i/16 1111 clk_csr_i/18 This support has to be added both in the include file, as well as driver. The driver need to program the registers based on the interfacing chips. This would be more board specific information and needs to be passed through the platform code to the driver. This work would be carried out in the future patch set release. Signed-off-by: Deepak Sikri <deepak.sikri@st.com> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:22 +08:00
stmmac: re-work the internal GMAC DMA platf parameters This patch re-works the internal GMAC DMA parameters passed from the platform. In the past, we only passed the pbl but, with new core, other parameters can be passed and are mandatory on some platforms. New parameters are documented in stmmac.txt because this patch has an impact for many platforms. Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com> Signed-off-by: Vikas Manocha <vikas.manocha@st.com> Signed-off-by: Deepak Sikri <deepak.sikri@st.com> Hacked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:23 +08:00
/* AXI DMA Burst length suported */
#define DMA_AXI_BLEN_4 (1 << 1)
#define DMA_AXI_BLEN_8 (1 << 2)
#define DMA_AXI_BLEN_16 (1 << 3)
#define DMA_AXI_BLEN_32 (1 << 4)
#define DMA_AXI_BLEN_64 (1 << 5)
#define DMA_AXI_BLEN_128 (1 << 6)
#define DMA_AXI_BLEN_256 (1 << 7)
#define DMA_AXI_BLEN_ALL (DMA_AXI_BLEN_4 | DMA_AXI_BLEN_8 | DMA_AXI_BLEN_16 \
| DMA_AXI_BLEN_32 | DMA_AXI_BLEN_64 \
| DMA_AXI_BLEN_128 | DMA_AXI_BLEN_256)
stmmac: unify MAC and PHY configuration parameters (V2) Prior to this change, most PHY configuration parameters were passed into the STMMAC device as a separate PHY device. As well as being unusual, this made it difficult to make changes to the MAC/PHY relationship. This patch moves all the PHY parameters into the MAC configuration structure, mainly as a separate structure. This allows us to completely ignore the MDIO bus attached to a stmmac if desired, and not create the PHY bus. It also allows the stmmac driver to use a different PHY from the one it is connected to, for example a fixed PHY or bit banging PHY. Also derive the stmmac/PHY connection type (MII/RMII etc) from the mode can be passed into <platf>_configure_ethernet. STLinux kernel at git://git.stlinux.com/stm/linux-sh4-2.6.32.y.git provides several examples how to use this new infrastructure (that actually is easier to maintain and clearer). Signed-off-by: Stuart Menefy <stuart.menefy@st.com> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-20 08:05:23 +08:00
/* Platfrom data for platform device structure's platform_data field */
struct stmmac_mdio_bus_data {
int (*phy_reset)(void *priv);
unsigned int phy_mask;
int *irqs;
int probed_phy_irq;
};
stmmac: add the new Header file for stmmac platform data Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-07 07:07:13 +08:00
stmmac: re-work the internal GMAC DMA platf parameters This patch re-works the internal GMAC DMA parameters passed from the platform. In the past, we only passed the pbl but, with new core, other parameters can be passed and are mandatory on some platforms. New parameters are documented in stmmac.txt because this patch has an impact for many platforms. Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com> Signed-off-by: Vikas Manocha <vikas.manocha@st.com> Signed-off-by: Deepak Sikri <deepak.sikri@st.com> Hacked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:23 +08:00
struct stmmac_dma_cfg {
int pbl;
int fixed_burst;
stmmac: add mixed burst for DMA In mixed burst (MB) mode, the AHB master always initiates the bursts with fixed-size when the DMA requests transfers of size less than or equal to 16 beats. This patch adds the MB support and the flag that can be passed from the platform to select it. MB mode can also give some benefits in terms of performances on some platforms. v2: fixed Coding Style Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-14 06:18:42 +08:00
int mixed_burst;
stmmac: re-work the internal GMAC DMA platf parameters This patch re-works the internal GMAC DMA parameters passed from the platform. In the past, we only passed the pbl but, with new core, other parameters can be passed and are mandatory on some platforms. New parameters are documented in stmmac.txt because this patch has an impact for many platforms. Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com> Signed-off-by: Vikas Manocha <vikas.manocha@st.com> Signed-off-by: Deepak Sikri <deepak.sikri@st.com> Hacked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:23 +08:00
int burst_len;
};
stmmac: add the new Header file for stmmac platform data Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-07 07:07:13 +08:00
struct plat_stmmacenet_data {
stmmac: Allow stmmac to work with other PHY buses(v3). As stmmac mdio bus name prefix is hardcoded in the driver, this allows only phys on stmmac mdio buses to connect, however stmmac should allow phys on other mdio buses too. This patch adds new variable phy_bus_name to plat_stmmacenet_data struct to let the BSP decide which phy bus to be used by stmmac driver. A typical use-case is to have generic MDIO buses like mdio-gpio on top of stmmac. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Acked-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:19 +08:00
char *phy_bus_name;
stmmac: add the new Header file for stmmac platform data Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-07 07:07:13 +08:00
int bus_id;
stmmac: unify MAC and PHY configuration parameters (V2) Prior to this change, most PHY configuration parameters were passed into the STMMAC device as a separate PHY device. As well as being unusual, this made it difficult to make changes to the MAC/PHY relationship. This patch moves all the PHY parameters into the MAC configuration structure, mainly as a separate structure. This allows us to completely ignore the MDIO bus attached to a stmmac if desired, and not create the PHY bus. It also allows the stmmac driver to use a different PHY from the one it is connected to, for example a fixed PHY or bit banging PHY. Also derive the stmmac/PHY connection type (MII/RMII etc) from the mode can be passed into <platf>_configure_ethernet. STLinux kernel at git://git.stlinux.com/stm/linux-sh4-2.6.32.y.git provides several examples how to use this new infrastructure (that actually is easier to maintain and clearer). Signed-off-by: Stuart Menefy <stuart.menefy@st.com> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-20 08:05:23 +08:00
int phy_addr;
int interface;
struct stmmac_mdio_bus_data *mdio_bus_data;
stmmac: re-work the internal GMAC DMA platf parameters This patch re-works the internal GMAC DMA parameters passed from the platform. In the past, we only passed the pbl but, with new core, other parameters can be passed and are mandatory on some platforms. New parameters are documented in stmmac.txt because this patch has an impact for many platforms. Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com> Signed-off-by: Vikas Manocha <vikas.manocha@st.com> Signed-off-by: Deepak Sikri <deepak.sikri@st.com> Hacked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:23 +08:00
struct stmmac_dma_cfg *dma_cfg;
stmmac: add CSR Clock range selection This patch adds the CSR Clock range selection. Original patch from Johannes Stezenbach fixed the CSR in the stmmac_mdio. We agreed to provide this through the platform instead of. Also thanks to Johannes for having tested it on ARM. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-09-17 11:23:39 +08:00
int clk_csr;
stmmac: add the new Header file for stmmac platform data Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-07 07:07:13 +08:00
int has_gmac;
stmmac: new descriptor field for the driver's platform The new enh_desc is used for selecting the enhanced descriptors structure. There are several scenarios; some chips (mac10/100 or gmac) want to use the enhanced descriptors; others want the normal ones. For example, on ST platforms: MAC10/100 uses the normal desc structure and the GMAC uses the enhanced one. It can be useful to get this information from the platform. This could also be decided at run-time looking at the chip's ID number; but it could happen that chips with the same ID want to use different descriptor structure. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-14 04:21:14 +08:00
int enh_desc;
stmmac: consolidate and tidy-up the COE support The first version of the driver had hard-coded the logic for handling the checksum offloading. This was designed according to the chips included in the STM platforms where: o MAC10/100 supports no COE at all. o GMAC fully supports RX/TX COE. This is not good for other chip configurations where, for example, the mac10/100 supports the tx csum in HW or when the GMAC has no IPC. Thanks to Johannes Stezenbach; he provided me a first draft of this patch that only reviewed the IPC for the GMAC devices. This patch also helps on SPEAr platforms where the MAC10/100 can perform the TX csum in HW. Thanks to Deepak SIKRI for his support on this. In the end, GMAC devices for STM platforms have a bugged Jumbo frame support that needs to have the Tx COE disabled for oversized frames (due to limited buffer sizes). This information is also passed through the driver's platform structure. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: Deepak SIKRI <deepak.sikri@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-09-17 11:23:40 +08:00
int tx_coe;
stmmac: Define CSUM offload engine Types This patch explicitly defines the CSUM offload engine type which need (not mandatory) to be passed from the platform code. STMMAC core supports two check sum offload engine types- Type-1 & Type-2. Also, there are STMMAC cores that do not have the check sum offload capabilities. The behaviour of Type-1 & Type-2 cores related to provision of checksum increases the packet length for Type-1 cores by 2, as the checksum is appended at the end of data packet and the same is made accountable in the DMA status. The STMMAC cores beyond Version-3.5 provide HW interface registers which allows the user to read the HW capabilities, while to support the previous cores the information related to HW capabilities has to be provided from the platform code. The Type-1 cores which do not have the HW register interface need this information. This patch also updates the driver's doc. Signed-off-by: Deepak Sikri <deepak.sikri@st.com> Hacked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-04 12:33:20 +08:00
int rx_coe;
stmmac: consolidate and tidy-up the COE support The first version of the driver had hard-coded the logic for handling the checksum offloading. This was designed according to the chips included in the STM platforms where: o MAC10/100 supports no COE at all. o GMAC fully supports RX/TX COE. This is not good for other chip configurations where, for example, the mac10/100 supports the tx csum in HW or when the GMAC has no IPC. Thanks to Johannes Stezenbach; he provided me a first draft of this patch that only reviewed the IPC for the GMAC devices. This patch also helps on SPEAr platforms where the MAC10/100 can perform the TX csum in HW. Thanks to Deepak SIKRI for his support on this. In the end, GMAC devices for STM platforms have a bugged Jumbo frame support that needs to have the Tx COE disabled for oversized frames (due to limited buffer sizes). This information is also passed through the driver's platform structure. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: Deepak SIKRI <deepak.sikri@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-09-17 11:23:40 +08:00
int bugged_jumbo;
stmmac: review the wake-up support If the PM support is available this is passed through the platform instead to be hard-coded in the core files. WoL on Magic Frame can be enabled by using the ethtool support. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-09-25 12:27:41 +08:00
int pmt;
stmmac: Allow SOCs to use Store forward mode eventhough tx_coe is 0. (V2) This patch adds new field 'force_sf_dma_mode' to plat_stmmacenet_data struct to allow users to specify if they want to use force store forward eventhough tx_coe is not available in hw. without this flag stmmac driver will use cut-thru mode not use store-forward mode. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-18 04:54:09 +08:00
int force_sf_dma_mode;
stmmac: add the new Header file for stmmac platform data Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-07 07:07:13 +08:00
void (*fix_mac_speed)(void *priv, unsigned int speed);
stmmac: make ioaddr 'void __iomem *' rather than unsigned long This avoids unnecessary casting and adds the ioaddr in the private structure. This patch also removes many warning when compile the driver. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-24 04:40:42 +08:00
void (*bus_setup)(void __iomem *ioaddr);
stmmac: add init/exit callback in plat_stmmacenet_data struct This patch adds in the plat_stmmacenet_data the init and exit callbacks that can be used for invoking specific platform functions. For example, on ST targets, these call the PAD manager functions to set PIO lines and syscfg registers. The patch removes the stmmac_claim_resource only used on STM Kernels as well. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-11-24 10:38:05 +08:00
int (*init)(struct platform_device *pdev);
void (*exit)(struct platform_device *pdev);
void *custom_cfg;
stmmac: use custom init/exit functions in pm ops Freeze and restore can call the custom init/exit functions. Also the patch adds a custom data field that can be used for storing platform data useful on restore the embedded setup (e.g. GPIO, SYSCFG). Signed-off-by: Francesco Virlinzi <francesco.virlinzi@st.com> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-19 03:48:19 +08:00
void *custom_data;
stmmac: add the new Header file for stmmac platform data Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-07 07:07:13 +08:00
void *bsp_priv;
};
#endif