* [U-Boot] [PATCH 1/6] davinci_emac: move arch-independent defines to separate header
2011-10-05 23:36 [U-Boot] [RFC PATCH 0/0] Support for DaVinci EMAC on TI AM35xx Ilya Yanok
@ 2011-10-05 23:36 ` Ilya Yanok
2011-10-06 21:02 ` Wolfgang Denk
2011-10-05 23:36 ` [U-Boot] [PATCH 2/6] davinci_emac: use internal addresses in buffer descriptors Ilya Yanok
` (4 subsequent siblings)
5 siblings, 1 reply; 35+ messages in thread
From: Ilya Yanok @ 2011-10-05 23:36 UTC (permalink / raw)
To: u-boot
DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs
also. This patch moves common defines from arch-davinci/emac_defs.h to
drivers/net/davinci_emac.h
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
arch/arm/include/asm/arch-davinci/emac_defs.h | 293 -----------------------
drivers/net/davinci_emac.c | 1 +
drivers/net/davinci_emac.h | 317 +++++++++++++++++++++++++
3 files changed, 318 insertions(+), 293 deletions(-)
create mode 100644 drivers/net/davinci_emac.h
diff --git a/arch/arm/include/asm/arch-davinci/emac_defs.h b/arch/arm/include/asm/arch-davinci/emac_defs.h
index 294a9a8..8a17de9 100644
--- a/arch/arm/include/asm/arch-davinci/emac_defs.h
+++ b/arch/arm/include/asm/arch-davinci/emac_defs.h
@@ -84,299 +84,6 @@
#define EMAC_MDIO_CLOCK_FREQ 2000000 /* 2.0 MHz */
#endif
-/* PHY mask - set only those phy number bits where phy is/can be connected */
-#define EMAC_MDIO_PHY_NUM CONFIG_EMAC_MDIO_PHY_NUM
-#define EMAC_MDIO_PHY_MASK (1 << EMAC_MDIO_PHY_NUM)
-
-/* Ethernet Min/Max packet size */
-#define EMAC_MIN_ETHERNET_PKT_SIZE 60
-#define EMAC_MAX_ETHERNET_PKT_SIZE 1518
-#define EMAC_PKT_ALIGN 18 /* 1518 + 18 = 1536 (packet aligned on 32 byte boundry) */
-
-/* Number of RX packet buffers
- * NOTE: Only 1 buffer supported as of now
- */
-#define EMAC_MAX_RX_BUFFERS 10
-
-
-/***********************************************
- ******** Internally used macros ***************
- ***********************************************/
-
-#define EMAC_CH_TX 1
-#define EMAC_CH_RX 0
-
-/* Each descriptor occupies 4 words, lets start RX desc's@0 and
- * reserve space for 64 descriptors max
- */
-#define EMAC_RX_DESC_BASE 0x0
-#define EMAC_TX_DESC_BASE 0x1000
-
-/* EMAC Teardown value */
-#define EMAC_TEARDOWN_VALUE 0xfffffffc
-
-/* MII Status Register */
-#define MII_STATUS_REG 1
-
-/* Number of statistics registers */
-#define EMAC_NUM_STATS 36
-
-
-/* EMAC Descriptor */
-typedef volatile struct _emac_desc
-{
- u_int32_t next; /* Pointer to next descriptor in chain */
- u_int8_t *buffer; /* Pointer to data buffer */
- u_int32_t buff_off_len; /* Buffer Offset(MSW) and Length(LSW) */
- u_int32_t pkt_flag_len; /* Packet Flags(MSW) and Length(LSW) */
-} emac_desc;
-
-/* CPPI bit positions */
-#define EMAC_CPPI_SOP_BIT (0x80000000)
-#define EMAC_CPPI_EOP_BIT (0x40000000)
-#define EMAC_CPPI_OWNERSHIP_BIT (0x20000000)
-#define EMAC_CPPI_EOQ_BIT (0x10000000)
-#define EMAC_CPPI_TEARDOWN_COMPLETE_BIT (0x08000000)
-#define EMAC_CPPI_PASS_CRC_BIT (0x04000000)
-
-#define EMAC_CPPI_RX_ERROR_FRAME (0x03fc0000)
-
-#define EMAC_MACCONTROL_MIIEN_ENABLE (0x20)
-#define EMAC_MACCONTROL_FULLDUPLEX_ENABLE (0x1)
-#define EMAC_MACCONTROL_GIGABIT_ENABLE (1 << 7)
-#define EMAC_MACCONTROL_GIGFORCE (1 << 17)
-#define EMAC_MACCONTROL_RMIISPEED_100 (1 << 15)
-
-#define EMAC_MAC_ADDR_MATCH (1 << 19)
-#define EMAC_MAC_ADDR_IS_VALID (1 << 20)
-
-#define EMAC_RXMBPENABLE_RXCAFEN_ENABLE (0x200000)
-#define EMAC_RXMBPENABLE_RXBROADEN (0x2000)
-
-
-#define MDIO_CONTROL_IDLE (0x80000000)
-#define MDIO_CONTROL_ENABLE (0x40000000)
-#define MDIO_CONTROL_FAULT_ENABLE (0x40000)
-#define MDIO_CONTROL_FAULT (0x80000)
-#define MDIO_USERACCESS0_GO (0x80000000)
-#define MDIO_USERACCESS0_WRITE_READ (0x0)
-#define MDIO_USERACCESS0_WRITE_WRITE (0x40000000)
-#define MDIO_USERACCESS0_ACK (0x20000000)
-
-/* Ethernet MAC Registers Structure */
-typedef struct {
- dv_reg TXIDVER;
- dv_reg TXCONTROL;
- dv_reg TXTEARDOWN;
- u_int8_t RSVD0[4];
- dv_reg RXIDVER;
- dv_reg RXCONTROL;
- dv_reg RXTEARDOWN;
- u_int8_t RSVD1[100];
- dv_reg TXINTSTATRAW;
- dv_reg TXINTSTATMASKED;
- dv_reg TXINTMASKSET;
- dv_reg TXINTMASKCLEAR;
- dv_reg MACINVECTOR;
- u_int8_t RSVD2[12];
- dv_reg RXINTSTATRAW;
- dv_reg RXINTSTATMASKED;
- dv_reg RXINTMASKSET;
- dv_reg RXINTMASKCLEAR;
- dv_reg MACINTSTATRAW;
- dv_reg MACINTSTATMASKED;
- dv_reg MACINTMASKSET;
- dv_reg MACINTMASKCLEAR;
- u_int8_t RSVD3[64];
- dv_reg RXMBPENABLE;
- dv_reg RXUNICASTSET;
- dv_reg RXUNICASTCLEAR;
- dv_reg RXMAXLEN;
- dv_reg RXBUFFEROFFSET;
- dv_reg RXFILTERLOWTHRESH;
- u_int8_t RSVD4[8];
- dv_reg RX0FLOWTHRESH;
- dv_reg RX1FLOWTHRESH;
- dv_reg RX2FLOWTHRESH;
- dv_reg RX3FLOWTHRESH;
- dv_reg RX4FLOWTHRESH;
- dv_reg RX5FLOWTHRESH;
- dv_reg RX6FLOWTHRESH;
- dv_reg RX7FLOWTHRESH;
- dv_reg RX0FREEBUFFER;
- dv_reg RX1FREEBUFFER;
- dv_reg RX2FREEBUFFER;
- dv_reg RX3FREEBUFFER;
- dv_reg RX4FREEBUFFER;
- dv_reg RX5FREEBUFFER;
- dv_reg RX6FREEBUFFER;
- dv_reg RX7FREEBUFFER;
- dv_reg MACCONTROL;
- dv_reg MACSTATUS;
- dv_reg EMCONTROL;
- dv_reg FIFOCONTROL;
- dv_reg MACCONFIG;
- dv_reg SOFTRESET;
- u_int8_t RSVD5[88];
- dv_reg MACSRCADDRLO;
- dv_reg MACSRCADDRHI;
- dv_reg MACHASH1;
- dv_reg MACHASH2;
- dv_reg BOFFTEST;
- dv_reg TPACETEST;
- dv_reg RXPAUSE;
- dv_reg TXPAUSE;
- u_int8_t RSVD6[16];
- dv_reg RXGOODFRAMES;
- dv_reg RXBCASTFRAMES;
- dv_reg RXMCASTFRAMES;
- dv_reg RXPAUSEFRAMES;
- dv_reg RXCRCERRORS;
- dv_reg RXALIGNCODEERRORS;
- dv_reg RXOVERSIZED;
- dv_reg RXJABBER;
- dv_reg RXUNDERSIZED;
- dv_reg RXFRAGMENTS;
- dv_reg RXFILTERED;
- dv_reg RXQOSFILTERED;
- dv_reg RXOCTETS;
- dv_reg TXGOODFRAMES;
- dv_reg TXBCASTFRAMES;
- dv_reg TXMCASTFRAMES;
- dv_reg TXPAUSEFRAMES;
- dv_reg TXDEFERRED;
- dv_reg TXCOLLISION;
- dv_reg TXSINGLECOLL;
- dv_reg TXMULTICOLL;
- dv_reg TXEXCESSIVECOLL;
- dv_reg TXLATECOLL;
- dv_reg TXUNDERRUN;
- dv_reg TXCARRIERSENSE;
- dv_reg TXOCTETS;
- dv_reg FRAME64;
- dv_reg FRAME65T127;
- dv_reg FRAME128T255;
- dv_reg FRAME256T511;
- dv_reg FRAME512T1023;
- dv_reg FRAME1024TUP;
- dv_reg NETOCTETS;
- dv_reg RXSOFOVERRUNS;
- dv_reg RXMOFOVERRUNS;
- dv_reg RXDMAOVERRUNS;
- u_int8_t RSVD7[624];
- dv_reg MACADDRLO;
- dv_reg MACADDRHI;
- dv_reg MACINDEX;
- u_int8_t RSVD8[244];
- dv_reg TX0HDP;
- dv_reg TX1HDP;
- dv_reg TX2HDP;
- dv_reg TX3HDP;
- dv_reg TX4HDP;
- dv_reg TX5HDP;
- dv_reg TX6HDP;
- dv_reg TX7HDP;
- dv_reg RX0HDP;
- dv_reg RX1HDP;
- dv_reg RX2HDP;
- dv_reg RX3HDP;
- dv_reg RX4HDP;
- dv_reg RX5HDP;
- dv_reg RX6HDP;
- dv_reg RX7HDP;
- dv_reg TX0CP;
- dv_reg TX1CP;
- dv_reg TX2CP;
- dv_reg TX3CP;
- dv_reg TX4CP;
- dv_reg TX5CP;
- dv_reg TX6CP;
- dv_reg TX7CP;
- dv_reg RX0CP;
- dv_reg RX1CP;
- dv_reg RX2CP;
- dv_reg RX3CP;
- dv_reg RX4CP;
- dv_reg RX5CP;
- dv_reg RX6CP;
- dv_reg RX7CP;
-} emac_regs;
-
-/* EMAC Wrapper Registers Structure */
-typedef struct {
-#ifdef DAVINCI_EMAC_VERSION2
- dv_reg idver;
- dv_reg softrst;
- dv_reg emctrl;
- dv_reg c0rxthreshen;
- dv_reg c0rxen;
- dv_reg c0txen;
- dv_reg c0miscen;
- dv_reg c1rxthreshen;
- dv_reg c1rxen;
- dv_reg c1txen;
- dv_reg c1miscen;
- dv_reg c2rxthreshen;
- dv_reg c2rxen;
- dv_reg c2txen;
- dv_reg c2miscen;
- dv_reg c0rxthreshstat;
- dv_reg c0rxstat;
- dv_reg c0txstat;
- dv_reg c0miscstat;
- dv_reg c1rxthreshstat;
- dv_reg c1rxstat;
- dv_reg c1txstat;
- dv_reg c1miscstat;
- dv_reg c2rxthreshstat;
- dv_reg c2rxstat;
- dv_reg c2txstat;
- dv_reg c2miscstat;
- dv_reg c0rximax;
- dv_reg c0tximax;
- dv_reg c1rximax;
- dv_reg c1tximax;
- dv_reg c2rximax;
- dv_reg c2tximax;
-#else
- u_int8_t RSVD0[4100];
- dv_reg EWCTL;
- dv_reg EWINTTCNT;
-#endif
-} ewrap_regs;
-
-/* EMAC MDIO Registers Structure */
-typedef struct {
- dv_reg VERSION;
- dv_reg CONTROL;
- dv_reg ALIVE;
- dv_reg LINK;
- dv_reg LINKINTRAW;
- dv_reg LINKINTMASKED;
- u_int8_t RSVD0[8];
- dv_reg USERINTRAW;
- dv_reg USERINTMASKED;
- dv_reg USERINTMASKSET;
- dv_reg USERINTMASKCLEAR;
- u_int8_t RSVD1[80];
- dv_reg USERACCESS0;
- dv_reg USERPHYSEL0;
- dv_reg USERACCESS1;
- dv_reg USERPHYSEL1;
-} mdio_regs;
-
-int davinci_eth_phy_read(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t *data);
-int davinci_eth_phy_write(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t data);
-
-typedef struct
-{
- char name[64];
- int (*init)(int phy_addr);
- int (*is_phy_connected)(int phy_addr);
- int (*get_link_speed)(int phy_addr);
- int (*auto_negotiate)(int phy_addr);
-} phy_t;
-
#define PHY_KSZ8873 (0x00221450)
int ksz8873_is_phy_connected(int phy_addr);
int ksz8873_get_link_speed(int phy_addr);
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index a8905b8..0e980ec 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -43,6 +43,7 @@
#include <malloc.h>
#include <asm/arch/emac_defs.h>
#include <asm/io.h>
+#include "davinci_emac.h"
unsigned int emac_dbg = 0;
#define debug_emac(fmt,args...) if (emac_dbg) printf(fmt,##args)
diff --git a/drivers/net/davinci_emac.h b/drivers/net/davinci_emac.h
new file mode 100644
index 0000000..c50f10a
--- /dev/null
+++ b/drivers/net/davinci_emac.h
@@ -0,0 +1,317 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Based on: mach-davinci/emac_defs.h
+ * Copyright (C) 2007 Sergey Kubushyn <ksi@koi8.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.
+ *
+ * This program is distributed in the hope that 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef _DAVINCI_EMAC_H_
+#define _DAVINCI_EMAC_H_
+/* PHY mask - set only those phy number bits where phy is/can be connected */
+#define EMAC_MDIO_PHY_NUM CONFIG_EMAC_MDIO_PHY_NUM
+#define EMAC_MDIO_PHY_MASK (1 << EMAC_MDIO_PHY_NUM)
+
+/* Ethernet Min/Max packet size */
+#define EMAC_MIN_ETHERNET_PKT_SIZE 60
+#define EMAC_MAX_ETHERNET_PKT_SIZE 1518
+#define EMAC_PKT_ALIGN 18 /* 1518 + 18 = 1536 (packet aligned on 32 byte boundry) */
+
+/* Number of RX packet buffers
+ * NOTE: Only 1 buffer supported as of now
+ */
+#define EMAC_MAX_RX_BUFFERS 10
+
+
+/***********************************************
+ ******** Internally used macros ***************
+ ***********************************************/
+
+#define EMAC_CH_TX 1
+#define EMAC_CH_RX 0
+
+/* Each descriptor occupies 4 words, lets start RX desc's@0 and
+ * reserve space for 64 descriptors max
+ */
+#define EMAC_RX_DESC_BASE 0x0
+#define EMAC_TX_DESC_BASE 0x1000
+
+/* EMAC Teardown value */
+#define EMAC_TEARDOWN_VALUE 0xfffffffc
+
+/* MII Status Register */
+#define MII_STATUS_REG 1
+
+/* Number of statistics registers */
+#define EMAC_NUM_STATS 36
+
+
+/* EMAC Descriptor */
+typedef volatile struct _emac_desc
+{
+ u_int32_t next; /* Pointer to next descriptor in chain */
+ u_int8_t *buffer; /* Pointer to data buffer */
+ u_int32_t buff_off_len; /* Buffer Offset(MSW) and Length(LSW) */
+ u_int32_t pkt_flag_len; /* Packet Flags(MSW) and Length(LSW) */
+} emac_desc;
+
+/* CPPI bit positions */
+#define EMAC_CPPI_SOP_BIT (0x80000000)
+#define EMAC_CPPI_EOP_BIT (0x40000000)
+#define EMAC_CPPI_OWNERSHIP_BIT (0x20000000)
+#define EMAC_CPPI_EOQ_BIT (0x10000000)
+#define EMAC_CPPI_TEARDOWN_COMPLETE_BIT (0x08000000)
+#define EMAC_CPPI_PASS_CRC_BIT (0x04000000)
+
+#define EMAC_CPPI_RX_ERROR_FRAME (0x03fc0000)
+
+#define EMAC_MACCONTROL_MIIEN_ENABLE (0x20)
+#define EMAC_MACCONTROL_FULLDUPLEX_ENABLE (0x1)
+#define EMAC_MACCONTROL_GIGABIT_ENABLE (1 << 7)
+#define EMAC_MACCONTROL_GIGFORCE (1 << 17)
+#define EMAC_MACCONTROL_RMIISPEED_100 (1 << 15)
+
+#define EMAC_MAC_ADDR_MATCH (1 << 19)
+#define EMAC_MAC_ADDR_IS_VALID (1 << 20)
+
+#define EMAC_RXMBPENABLE_RXCAFEN_ENABLE (0x200000)
+#define EMAC_RXMBPENABLE_RXBROADEN (0x2000)
+
+
+#define MDIO_CONTROL_IDLE (0x80000000)
+#define MDIO_CONTROL_ENABLE (0x40000000)
+#define MDIO_CONTROL_FAULT_ENABLE (0x40000)
+#define MDIO_CONTROL_FAULT (0x80000)
+#define MDIO_USERACCESS0_GO (0x80000000)
+#define MDIO_USERACCESS0_WRITE_READ (0x0)
+#define MDIO_USERACCESS0_WRITE_WRITE (0x40000000)
+#define MDIO_USERACCESS0_ACK (0x20000000)
+
+/* Ethernet MAC Registers Structure */
+typedef struct {
+ dv_reg TXIDVER;
+ dv_reg TXCONTROL;
+ dv_reg TXTEARDOWN;
+ u_int8_t RSVD0[4];
+ dv_reg RXIDVER;
+ dv_reg RXCONTROL;
+ dv_reg RXTEARDOWN;
+ u_int8_t RSVD1[100];
+ dv_reg TXINTSTATRAW;
+ dv_reg TXINTSTATMASKED;
+ dv_reg TXINTMASKSET;
+ dv_reg TXINTMASKCLEAR;
+ dv_reg MACINVECTOR;
+ u_int8_t RSVD2[12];
+ dv_reg RXINTSTATRAW;
+ dv_reg RXINTSTATMASKED;
+ dv_reg RXINTMASKSET;
+ dv_reg RXINTMASKCLEAR;
+ dv_reg MACINTSTATRAW;
+ dv_reg MACINTSTATMASKED;
+ dv_reg MACINTMASKSET;
+ dv_reg MACINTMASKCLEAR;
+ u_int8_t RSVD3[64];
+ dv_reg RXMBPENABLE;
+ dv_reg RXUNICASTSET;
+ dv_reg RXUNICASTCLEAR;
+ dv_reg RXMAXLEN;
+ dv_reg RXBUFFEROFFSET;
+ dv_reg RXFILTERLOWTHRESH;
+ u_int8_t RSVD4[8];
+ dv_reg RX0FLOWTHRESH;
+ dv_reg RX1FLOWTHRESH;
+ dv_reg RX2FLOWTHRESH;
+ dv_reg RX3FLOWTHRESH;
+ dv_reg RX4FLOWTHRESH;
+ dv_reg RX5FLOWTHRESH;
+ dv_reg RX6FLOWTHRESH;
+ dv_reg RX7FLOWTHRESH;
+ dv_reg RX0FREEBUFFER;
+ dv_reg RX1FREEBUFFER;
+ dv_reg RX2FREEBUFFER;
+ dv_reg RX3FREEBUFFER;
+ dv_reg RX4FREEBUFFER;
+ dv_reg RX5FREEBUFFER;
+ dv_reg RX6FREEBUFFER;
+ dv_reg RX7FREEBUFFER;
+ dv_reg MACCONTROL;
+ dv_reg MACSTATUS;
+ dv_reg EMCONTROL;
+ dv_reg FIFOCONTROL;
+ dv_reg MACCONFIG;
+ dv_reg SOFTRESET;
+ u_int8_t RSVD5[88];
+ dv_reg MACSRCADDRLO;
+ dv_reg MACSRCADDRHI;
+ dv_reg MACHASH1;
+ dv_reg MACHASH2;
+ dv_reg BOFFTEST;
+ dv_reg TPACETEST;
+ dv_reg RXPAUSE;
+ dv_reg TXPAUSE;
+ u_int8_t RSVD6[16];
+ dv_reg RXGOODFRAMES;
+ dv_reg RXBCASTFRAMES;
+ dv_reg RXMCASTFRAMES;
+ dv_reg RXPAUSEFRAMES;
+ dv_reg RXCRCERRORS;
+ dv_reg RXALIGNCODEERRORS;
+ dv_reg RXOVERSIZED;
+ dv_reg RXJABBER;
+ dv_reg RXUNDERSIZED;
+ dv_reg RXFRAGMENTS;
+ dv_reg RXFILTERED;
+ dv_reg RXQOSFILTERED;
+ dv_reg RXOCTETS;
+ dv_reg TXGOODFRAMES;
+ dv_reg TXBCASTFRAMES;
+ dv_reg TXMCASTFRAMES;
+ dv_reg TXPAUSEFRAMES;
+ dv_reg TXDEFERRED;
+ dv_reg TXCOLLISION;
+ dv_reg TXSINGLECOLL;
+ dv_reg TXMULTICOLL;
+ dv_reg TXEXCESSIVECOLL;
+ dv_reg TXLATECOLL;
+ dv_reg TXUNDERRUN;
+ dv_reg TXCARRIERSENSE;
+ dv_reg TXOCTETS;
+ dv_reg FRAME64;
+ dv_reg FRAME65T127;
+ dv_reg FRAME128T255;
+ dv_reg FRAME256T511;
+ dv_reg FRAME512T1023;
+ dv_reg FRAME1024TUP;
+ dv_reg NETOCTETS;
+ dv_reg RXSOFOVERRUNS;
+ dv_reg RXMOFOVERRUNS;
+ dv_reg RXDMAOVERRUNS;
+ u_int8_t RSVD7[624];
+ dv_reg MACADDRLO;
+ dv_reg MACADDRHI;
+ dv_reg MACINDEX;
+ u_int8_t RSVD8[244];
+ dv_reg TX0HDP;
+ dv_reg TX1HDP;
+ dv_reg TX2HDP;
+ dv_reg TX3HDP;
+ dv_reg TX4HDP;
+ dv_reg TX5HDP;
+ dv_reg TX6HDP;
+ dv_reg TX7HDP;
+ dv_reg RX0HDP;
+ dv_reg RX1HDP;
+ dv_reg RX2HDP;
+ dv_reg RX3HDP;
+ dv_reg RX4HDP;
+ dv_reg RX5HDP;
+ dv_reg RX6HDP;
+ dv_reg RX7HDP;
+ dv_reg TX0CP;
+ dv_reg TX1CP;
+ dv_reg TX2CP;
+ dv_reg TX3CP;
+ dv_reg TX4CP;
+ dv_reg TX5CP;
+ dv_reg TX6CP;
+ dv_reg TX7CP;
+ dv_reg RX0CP;
+ dv_reg RX1CP;
+ dv_reg RX2CP;
+ dv_reg RX3CP;
+ dv_reg RX4CP;
+ dv_reg RX5CP;
+ dv_reg RX6CP;
+ dv_reg RX7CP;
+} emac_regs;
+
+/* EMAC Wrapper Registers Structure */
+typedef struct {
+#ifdef DAVINCI_EMAC_VERSION2
+ dv_reg idver;
+ dv_reg softrst;
+ dv_reg emctrl;
+ dv_reg c0rxthreshen;
+ dv_reg c0rxen;
+ dv_reg c0txen;
+ dv_reg c0miscen;
+ dv_reg c1rxthreshen;
+ dv_reg c1rxen;
+ dv_reg c1txen;
+ dv_reg c1miscen;
+ dv_reg c2rxthreshen;
+ dv_reg c2rxen;
+ dv_reg c2txen;
+ dv_reg c2miscen;
+ dv_reg c0rxthreshstat;
+ dv_reg c0rxstat;
+ dv_reg c0txstat;
+ dv_reg c0miscstat;
+ dv_reg c1rxthreshstat;
+ dv_reg c1rxstat;
+ dv_reg c1txstat;
+ dv_reg c1miscstat;
+ dv_reg c2rxthreshstat;
+ dv_reg c2rxstat;
+ dv_reg c2txstat;
+ dv_reg c2miscstat;
+ dv_reg c0rximax;
+ dv_reg c0tximax;
+ dv_reg c1rximax;
+ dv_reg c1tximax;
+ dv_reg c2rximax;
+ dv_reg c2tximax;
+#else
+ u_int8_t RSVD0[4100];
+ dv_reg EWCTL;
+ dv_reg EWINTTCNT;
+#endif
+} ewrap_regs;
+
+/* EMAC MDIO Registers Structure */
+typedef struct {
+ dv_reg VERSION;
+ dv_reg CONTROL;
+ dv_reg ALIVE;
+ dv_reg LINK;
+ dv_reg LINKINTRAW;
+ dv_reg LINKINTMASKED;
+ u_int8_t RSVD0[8];
+ dv_reg USERINTRAW;
+ dv_reg USERINTMASKED;
+ dv_reg USERINTMASKSET;
+ dv_reg USERINTMASKCLEAR;
+ u_int8_t RSVD1[80];
+ dv_reg USERACCESS0;
+ dv_reg USERPHYSEL0;
+ dv_reg USERACCESS1;
+ dv_reg USERPHYSEL1;
+} mdio_regs;
+
+int davinci_eth_phy_read(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t *data);
+int davinci_eth_phy_write(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t data);
+
+typedef struct
+{
+ char name[64];
+ int (*init)(int phy_addr);
+ int (*is_phy_connected)(int phy_addr);
+ int (*get_link_speed)(int phy_addr);
+ int (*auto_negotiate)(int phy_addr);
+} phy_t;
+
+#endif /* _DAVINCI_EMAC_H_ */
--
1.7.6.2
^ permalink raw reply related [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 1/6] davinci_emac: move arch-independent defines to separate header
2011-10-05 23:36 ` [U-Boot] [PATCH 1/6] davinci_emac: move arch-independent defines to separate header Ilya Yanok
@ 2011-10-06 21:02 ` Wolfgang Denk
2011-10-10 21:23 ` Ilya Yanok
0 siblings, 1 reply; 35+ messages in thread
From: Wolfgang Denk @ 2011-10-06 21:02 UTC (permalink / raw)
To: u-boot
Dear Ilya Yanok,
In message <1317857806-16549-2-git-send-email-yanok@emcraft.com> you wrote:
> DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs
> also. This patch moves common defines from arch-davinci/emac_defs.h to
> drivers/net/davinci_emac.h
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> arch/arm/include/asm/arch-davinci/emac_defs.h | 293 -----------------------
> drivers/net/davinci_emac.c | 1 +
> drivers/net/davinci_emac.h | 317 +++++++++++++++++++++++++
> 3 files changed, 318 insertions(+), 293 deletions(-)
> create mode 100644 drivers/net/davinci_emac.h
Checkpatch says:
total: 1 errors, 8 warnings, 623 lines checked
Please clean up and resubmit. Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Here is an Appalachian version of management's answer to those who
are concerned with the fate of the project: "Don't worry about the
mule. Just load the wagon." - Mike Dennison's hillbilly uncle
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 1/6] davinci_emac: move arch-independent defines to separate header
2011-10-06 21:02 ` Wolfgang Denk
@ 2011-10-10 21:23 ` Ilya Yanok
0 siblings, 0 replies; 35+ messages in thread
From: Ilya Yanok @ 2011-10-10 21:23 UTC (permalink / raw)
To: u-boot
Dear Wolfgang,
On 07.10.2011 01:02, Wolfgang Denk wrote:
>> arch/arm/include/asm/arch-davinci/emac_defs.h | 293 -----------------------
>> drivers/net/davinci_emac.c | 1 +
>> drivers/net/davinci_emac.h | 317 +++++++++++++++++++++++++
>> 3 files changed, 318 insertions(+), 293 deletions(-)
>> create mode 100644 drivers/net/davinci_emac.h
> Checkpatch says:
>
> total: 1 errors, 8 warnings, 623 lines checked
Uh.. I'm not adding anything myself by this patch, just spliting the
existing header into two. Do I really have to fix all these style errors?
Regards, Ilya.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 2/6] davinci_emac: use internal addresses in buffer descriptors
2011-10-05 23:36 [U-Boot] [RFC PATCH 0/0] Support for DaVinci EMAC on TI AM35xx Ilya Yanok
2011-10-05 23:36 ` [U-Boot] [PATCH 1/6] davinci_emac: move arch-independent defines to separate header Ilya Yanok
@ 2011-10-05 23:36 ` Ilya Yanok
2011-10-06 21:02 ` Wolfgang Denk
2011-10-05 23:36 ` [U-Boot] [PATCH 3/6] davinci_emac: conditionally compile specific PHY support Ilya Yanok
` (3 subsequent siblings)
5 siblings, 1 reply; 35+ messages in thread
From: Ilya Yanok @ 2011-10-05 23:36 UTC (permalink / raw)
To: u-boot
On AM35xx CPPI RAM had different addresses when accessed from the CPU
and from the EMAC. We need to account this to deal with the buffer
descriptors correctly.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
drivers/net/davinci_emac.c | 28 +++++++++++++++++++---------
1 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 0e980ec..7eb37c7 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -48,6 +48,16 @@
unsigned int emac_dbg = 0;
#define debug_emac(fmt,args...) if (emac_dbg) printf(fmt,##args)
+#ifdef EMAC_HW_RAM_ADDR
+#define BD_TO_HW(x) \
+ ( ( (x) == 0) ? 0 : ( (x) - EMAC_WRAPPER_RAM_ADDR + EMAC_HW_RAM_ADDR ))
+#define HW_TO_BD(x) \
+ ( ( (x) == 0) ? 0 : ( (x) - EMAC_HW_RAM_ADDR + EMAC_WRAPPER_RAM_ADDR ))
+#else
+#define BD_TO_HW(x) (x)
+#define HW_TO_BD(x) (x)
+#endif
+
#ifdef DAVINCI_EMAC_GIG_ENABLE
#define emac_gigabit_enable() davinci_eth_gigabit_enable()
#else
@@ -389,7 +399,7 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis)
/* Create RX queue and set receive process in place */
emac_rx_active_head = emac_rx_desc;
for (cnt = 0; cnt < EMAC_MAX_RX_BUFFERS; cnt++) {
- rx_desc->next = (u_int32_t)(rx_desc + 1);
+ rx_desc->next = BD_TO_HW((u_int32_t)(rx_desc + 1));
rx_desc->buffer = &emac_rx_buffers[cnt * (EMAC_MAX_ETHERNET_PKT_SIZE + EMAC_PKT_ALIGN)];
rx_desc->buff_off_len = EMAC_MAX_ETHERNET_PKT_SIZE;
rx_desc->pkt_flag_len = EMAC_CPPI_OWNERSHIP_BIT;
@@ -441,7 +451,7 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis)
emac_gigabit_enable();
/* Start receive process */
- writel((u_int32_t)emac_rx_desc, &adap_emac->RX0HDP);
+ writel(BD_TO_HW((u_int32_t)emac_rx_desc), &adap_emac->RX0HDP);
debug_emac("- emac_open\n");
@@ -559,7 +569,7 @@ static int davinci_eth_send_packet (struct eth_device *dev,
EMAC_CPPI_OWNERSHIP_BIT |
EMAC_CPPI_EOP_BIT);
/* Send the packet */
- writel((unsigned long)emac_tx_desc, &adap_emac->TX0HDP);
+ writel(BD_TO_HW((unsigned long)emac_tx_desc), &adap_emac->TX0HDP);
/* Wait for packet to complete or link down */
while (1) {
@@ -603,14 +613,14 @@ static int davinci_eth_rcv_packet (struct eth_device *dev)
}
/* Ack received packet descriptor */
- writel((unsigned long)rx_curr_desc, &adap_emac->RX0CP);
+ writel(BD_TO_HW((unsigned long)rx_curr_desc), &adap_emac->RX0CP);
curr_desc = rx_curr_desc;
emac_rx_active_head =
- (volatile emac_desc *) rx_curr_desc->next;
+ (volatile emac_desc *) (HW_TO_BD(rx_curr_desc->next));
if (status & EMAC_CPPI_EOQ_BIT) {
if (emac_rx_active_head) {
- writel((unsigned long)emac_rx_active_head,
+ writel(BD_TO_HW((unsigned long)emac_rx_active_head),
&adap_emac->RX0HDP);
} else {
emac_rx_queue_active = 0;
@@ -628,7 +638,7 @@ static int davinci_eth_rcv_packet (struct eth_device *dev)
emac_rx_active_head = curr_desc;
emac_rx_active_tail = curr_desc;
if (emac_rx_queue_active != 0) {
- writel((unsigned long)emac_rx_active_head,
+ writel(BD_TO_HW((unsigned long)emac_rx_active_head),
&adap_emac->RX0HDP);
printf ("INFO: emac_rcv_pkt: active queue head = 0, HDP fired\n");
emac_rx_queue_active = 1;
@@ -636,10 +646,10 @@ static int davinci_eth_rcv_packet (struct eth_device *dev)
} else {
tail_desc = emac_rx_active_tail;
emac_rx_active_tail = curr_desc;
- tail_desc->next = (unsigned int) curr_desc;
+ tail_desc->next = BD_TO_HW((unsigned int) curr_desc);
status = tail_desc->pkt_flag_len;
if (status & EMAC_CPPI_EOQ_BIT) {
- writel((unsigned long)curr_desc,
+ writel(BD_TO_HW((unsigned long)curr_desc),
&adap_emac->RX0HDP);
status &= ~EMAC_CPPI_EOQ_BIT;
tail_desc->pkt_flag_len = status;
--
1.7.6.2
^ permalink raw reply related [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 2/6] davinci_emac: use internal addresses in buffer descriptors
2011-10-05 23:36 ` [U-Boot] [PATCH 2/6] davinci_emac: use internal addresses in buffer descriptors Ilya Yanok
@ 2011-10-06 21:02 ` Wolfgang Denk
0 siblings, 0 replies; 35+ messages in thread
From: Wolfgang Denk @ 2011-10-06 21:02 UTC (permalink / raw)
To: u-boot
Dear Ilya Yanok,
In message <1317857806-16549-3-git-send-email-yanok@emcraft.com> you wrote:
> On AM35xx CPPI RAM had different addresses when accessed from the CPU
> and from the EMAC. We need to account this to deal with the buffer
> descriptors correctly.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> drivers/net/davinci_emac.c | 28 +++++++++++++++++++---------
> 1 files changed, 19 insertions(+), 9 deletions(-)
Checkpatch says:
total: 5 errors, 4 warnings, 77 lines checked
Please clean up and resubmit. Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Some programming languages manage to absorb change, but withstand
progress. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 3/6] davinci_emac: conditionally compile specific PHY support
2011-10-05 23:36 [U-Boot] [RFC PATCH 0/0] Support for DaVinci EMAC on TI AM35xx Ilya Yanok
2011-10-05 23:36 ` [U-Boot] [PATCH 1/6] davinci_emac: move arch-independent defines to separate header Ilya Yanok
2011-10-05 23:36 ` [U-Boot] [PATCH 2/6] davinci_emac: use internal addresses in buffer descriptors Ilya Yanok
@ 2011-10-05 23:36 ` Ilya Yanok
2011-10-05 23:36 ` [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled Ilya Yanok
` (2 subsequent siblings)
5 siblings, 0 replies; 35+ messages in thread
From: Ilya Yanok @ 2011-10-05 23:36 UTC (permalink / raw)
To: u-boot
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
drivers/net/davinci_emac.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 7eb37c7..222a0d0 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -725,6 +725,7 @@ int davinci_emac_initialize(void)
phy_id |= tmp & 0x0000ffff;
switch (phy_id) {
+#ifdef PHY_KSZ8873
case PHY_KSZ8873:
sprintf(phy.name, "KSZ8873 @ 0x%02x", active_phy_addr);
phy.init = ksz8873_init_phy;
@@ -732,6 +733,8 @@ int davinci_emac_initialize(void)
phy.get_link_speed = ksz8873_get_link_speed;
phy.auto_negotiate = ksz8873_auto_negotiate;
break;
+#endif
+#ifdef PHY_LXT972
case PHY_LXT972:
sprintf(phy.name, "LXT972 @ 0x%02x", active_phy_addr);
phy.init = lxt972_init_phy;
@@ -739,6 +742,8 @@ int davinci_emac_initialize(void)
phy.get_link_speed = lxt972_get_link_speed;
phy.auto_negotiate = lxt972_auto_negotiate;
break;
+#endif
+#ifdef PHY_DP83848
case PHY_DP83848:
sprintf(phy.name, "DP83848 @ 0x%02x", active_phy_addr);
phy.init = dp83848_init_phy;
@@ -746,6 +751,8 @@ int davinci_emac_initialize(void)
phy.get_link_speed = dp83848_get_link_speed;
phy.auto_negotiate = dp83848_auto_negotiate;
break;
+#endif
+#ifdef PHY_ET1011C
case PHY_ET1011C:
sprintf(phy.name, "ET1011C @ 0x%02x", active_phy_addr);
phy.init = gen_init_phy;
@@ -753,6 +760,7 @@ int davinci_emac_initialize(void)
phy.get_link_speed = et1011c_get_link_speed;
phy.auto_negotiate = gen_auto_negotiate;
break;
+#endif
default:
sprintf(phy.name, "GENERIC @ 0x%02x", active_phy_addr);
phy.init = gen_init_phy;
--
1.7.6.2
^ permalink raw reply related [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-05 23:36 [U-Boot] [RFC PATCH 0/0] Support for DaVinci EMAC on TI AM35xx Ilya Yanok
` (2 preceding siblings ...)
2011-10-05 23:36 ` [U-Boot] [PATCH 3/6] davinci_emac: conditionally compile specific PHY support Ilya Yanok
@ 2011-10-05 23:36 ` Ilya Yanok
2011-10-07 17:34 ` Mike Frysinger
2011-10-10 12:35 ` Stefano Babic
2011-10-05 23:36 ` [U-Boot] [PATCH 5/6] davinci_emac: hardcode 100Mbps for AM35xx and RMII Ilya Yanok
2011-10-05 23:36 ` [U-Boot] [PATCH 6/6] AM35xx: add EMAC defines Ilya Yanok
5 siblings, 2 replies; 35+ messages in thread
From: Ilya Yanok @ 2011-10-05 23:36 UTC (permalink / raw)
To: u-boot
DaVinci EMAC is present on TI AM35xx SoCs (ARMv7) which run with D-Cache
enabled by default. So we have to take care and flush/invalidate the
cache before/after the DMA operations.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
drivers/net/davinci_emac.c | 47 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 222a0d0..b787213 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -96,6 +96,40 @@ static volatile u_int8_t active_phy_addr = 0xff;
phy_t phy;
+#ifdef DAVINCI_EMAC_DCACHE
+static inline void davinci_flush(void *addr, int size)
+{
+ flush_dcache_range((unsigned long)addr,
+ (unsigned long)addr + size);
+}
+
+static inline void davinci_invalidate(void *addr, int size)
+{
+ invalidate_dcache_range((unsigned long)addr,
+ (unsigned long)addr + size);
+}
+#else
+#define davinci_flush(addr, size) do {} while (0)
+#define davinci_invalidate(addr, size) do {} while (0)
+#endif
+
+static inline void davinci_flush_rx_descs(void)
+{
+ davinci_flush((void *)emac_rx_desc, EMAC_MAX_RX_BUFFERS *
+ sizeof(emac_desc));
+}
+
+static inline void davinci_invalidate_rx_descs(void)
+{
+ davinci_invalidate((void *)emac_rx_desc, EMAC_MAX_RX_BUFFERS *
+ sizeof(emac_desc));
+}
+
+static inline void davinci_flush_desc(emac_desc *desc)
+{
+ davinci_flush((void *)desc, sizeof(*desc));
+}
+
static int davinci_eth_set_mac_addr(struct eth_device *dev)
{
unsigned long mac_hi;
@@ -412,6 +446,8 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis)
emac_rx_active_tail = rx_desc;
emac_rx_queue_active = 1;
+ davinci_flush_rx_descs();
+
/* Enable TX/RX */
writel(EMAC_MAX_ETHERNET_PKT_SIZE, &adap_emac->RXMAXLEN);
writel(0, &adap_emac->RXBUFFEROFFSET);
@@ -568,6 +604,10 @@ static int davinci_eth_send_packet (struct eth_device *dev,
EMAC_CPPI_SOP_BIT |
EMAC_CPPI_OWNERSHIP_BIT |
EMAC_CPPI_EOP_BIT);
+
+ davinci_flush((void *)packet, length);
+ davinci_flush_desc(emac_tx_desc);
+
/* Send the packet */
writel(BD_TO_HW((unsigned long)emac_tx_desc), &adap_emac->TX0HDP);
@@ -600,6 +640,8 @@ static int davinci_eth_rcv_packet (struct eth_device *dev)
volatile emac_desc *tail_desc;
int status, ret = -1;
+ davinci_invalidate_rx_descs();
+
rx_curr_desc = emac_rx_active_head;
status = rx_curr_desc->pkt_flag_len;
if ((rx_curr_desc) && ((status & EMAC_CPPI_OWNERSHIP_BIT) == 0)) {
@@ -607,6 +649,8 @@ static int davinci_eth_rcv_packet (struct eth_device *dev)
/* Error in packet - discard it and requeue desc */
printf ("WARN: emac_rcv_pkt: Error in packet\n");
} else {
+ davinci_invalidate(rx_curr_desc->buffer,
+ rx_curr_desc->buff_off_len & 0xffff);
NetReceive (rx_curr_desc->buffer,
(rx_curr_desc->buff_off_len & 0xffff));
ret = rx_curr_desc->buff_off_len & 0xffff;
@@ -632,6 +676,7 @@ static int davinci_eth_rcv_packet (struct eth_device *dev)
rx_curr_desc->buff_off_len = EMAC_MAX_ETHERNET_PKT_SIZE;
rx_curr_desc->pkt_flag_len = EMAC_CPPI_OWNERSHIP_BIT;
rx_curr_desc->next = 0;
+ davinci_flush_desc(rx_curr_desc);
if (emac_rx_active_head == 0) {
printf ("INFO: emac_rcv_pkt: active queue head = 0\n");
@@ -649,11 +694,13 @@ static int davinci_eth_rcv_packet (struct eth_device *dev)
tail_desc->next = BD_TO_HW((unsigned int) curr_desc);
status = tail_desc->pkt_flag_len;
if (status & EMAC_CPPI_EOQ_BIT) {
+ davinci_flush_desc(tail_desc);
writel(BD_TO_HW((unsigned long)curr_desc),
&adap_emac->RX0HDP);
status &= ~EMAC_CPPI_EOQ_BIT;
tail_desc->pkt_flag_len = status;
}
+ davinci_flush_desc(tail_desc);
}
return (ret);
}
--
1.7.6.2
^ permalink raw reply related [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-05 23:36 ` [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled Ilya Yanok
@ 2011-10-07 17:34 ` Mike Frysinger
2011-10-09 10:41 ` Ilya Yanok
2011-10-10 12:35 ` Stefano Babic
1 sibling, 1 reply; 35+ messages in thread
From: Mike Frysinger @ 2011-10-07 17:34 UTC (permalink / raw)
To: u-boot
On Wednesday 05 October 2011 19:36:44 Ilya Yanok wrote:
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
>
> +#ifdef DAVINCI_EMAC_DCACHE
> +static inline void davinci_flush(void *addr, int size)
> +{
> + flush_dcache_range((unsigned long)addr,
> + (unsigned long)addr + size);
> +}
> +
> +static inline void davinci_invalidate(void *addr, int size)
> +{
> + invalidate_dcache_range((unsigned long)addr,
> + (unsigned long)addr + size);
> +}
> +#else
> +#define davinci_flush(addr, size) do {} while (0)
> +#define davinci_invalidate(addr, size) do {} while (0)
> +#endif
does it really make sense to have this be conditional ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111007/af40ca92/attachment.pgp
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-07 17:34 ` Mike Frysinger
@ 2011-10-09 10:41 ` Ilya Yanok
2011-10-09 13:21 ` Laurence Withers
2011-10-09 15:56 ` Mike Frysinger
0 siblings, 2 replies; 35+ messages in thread
From: Ilya Yanok @ 2011-10-09 10:41 UTC (permalink / raw)
To: u-boot
Hi Mike,
On 07.10.2011 21:34, Mike Frysinger wrote:
>> +#ifdef DAVINCI_EMAC_DCACHE
>> +static inline void davinci_flush(void *addr, int size)
>> +{
>> + flush_dcache_range((unsigned long)addr,
>> + (unsigned long)addr + size);
>> +}
>> +
>> +static inline void davinci_invalidate(void *addr, int size)
>> +{
>> + invalidate_dcache_range((unsigned long)addr,
>> + (unsigned long)addr + size);
>> +}
>> +#else
>> +#define davinci_flush(addr, size) do {} while (0)
>> +#define davinci_invalidate(addr, size) do {} while (0)
>> +#endif
>
> does it really make sense to have this be conditional ?
arm926ejs doesn't have {invalidate,flush}_dcache_range(), so we have to
add this not to break the driver on DaVinci boards (maybe we need to add
empty cache functions on arm926ejs instead?)
Regards, Ilya.
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-09 10:41 ` Ilya Yanok
@ 2011-10-09 13:21 ` Laurence Withers
2011-10-09 15:56 ` Mike Frysinger
1 sibling, 0 replies; 35+ messages in thread
From: Laurence Withers @ 2011-10-09 13:21 UTC (permalink / raw)
To: u-boot
On Sun, Oct 09, 2011 at 02:41:47PM +0400, Ilya Yanok wrote:
> arm926ejs doesn't have {invalidate,flush}_dcache_range(), so we have to
> add this not to break the driver on DaVinci boards (maybe we need to add
> empty cache functions on arm926ejs instead?)
Even better would be working cache functions, so that DA8xx boards (and
presumably other DaVinci processors) can run with Ethernet and cache enabled.
There have been a few proposals floating around to do this, but I'm not sure
whether they've stalled or are continuing quietly along.
Bye for now,
--
Laurence Withers, <lwithers@guralp.com> http://www.guralp.com/
Direct tel:+447753988197 or tel:+443333408643 Software Engineer
General support queries: <support@guralp.com> CMG-DCM CMG-EAM CMG-NAM
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-09 10:41 ` Ilya Yanok
2011-10-09 13:21 ` Laurence Withers
@ 2011-10-09 15:56 ` Mike Frysinger
2011-10-13 22:18 ` Ilya Yanok
1 sibling, 1 reply; 35+ messages in thread
From: Mike Frysinger @ 2011-10-09 15:56 UTC (permalink / raw)
To: u-boot
On Sunday 09 October 2011 06:41:47 Ilya Yanok wrote:
> On 07.10.2011 21:34, Mike Frysinger wrote:
> >> +#ifdef DAVINCI_EMAC_DCACHE
> >> +static inline void davinci_flush(void *addr, int size)
> >> +{
> >> + flush_dcache_range((unsigned long)addr,
> >> + (unsigned long)addr + size);
> >> +}
> >> +
> >> +static inline void davinci_invalidate(void *addr, int size)
> >> +{
> >> + invalidate_dcache_range((unsigned long)addr,
> >> + (unsigned long)addr + size);
> >> +}
> >> +#else
> >> +#define davinci_flush(addr, size) do {} while (0)
> >> +#define davinci_invalidate(addr, size) do {} while (0)
> >> +#endif
> >
> > does it really make sense to have this be conditional ?
>
> arm926ejs doesn't have {invalidate,flush}_dcache_range(), so we have to
> add this not to break the driver on DaVinci boards (maybe we need to add
> empty cache functions on arm926ejs instead?)
if the prototype is in include/common.h, then code may assume it exists. if
it doesn't exist for a particular cpu, then that cpu is broken and common code
(which is what drivers/ is) should not be adding hacks to workaround broken
cpus. please add stubs to the cpu you're referring to and drop the
DAVINCI_EMAC_DCACHE define. or let whoever cares about that cpu add the
defines, but still drop DAVINCI_EMAC_DCACHE.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111009/a7bd825d/attachment.pgp
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-09 15:56 ` Mike Frysinger
@ 2011-10-13 22:18 ` Ilya Yanok
0 siblings, 0 replies; 35+ messages in thread
From: Ilya Yanok @ 2011-10-13 22:18 UTC (permalink / raw)
To: u-boot
Hi Mike,
On 09.10.2011 19:56, Mike Frysinger wrote:
>> arm926ejs doesn't have {invalidate,flush}_dcache_range(), so we have to
>> add this not to break the driver on DaVinci boards (maybe we need to add
>> empty cache functions on arm926ejs instead?)
>
> if the prototype is in include/common.h, then code may assume it exists. if
> it doesn't exist for a particular cpu, then that cpu is broken and common code
> (which is what drivers/ is) should not be adding hacks to workaround broken
> cpus. please add stubs to the cpu you're referring to and drop the
> DAVINCI_EMAC_DCACHE define. or let whoever cares about that cpu add the
> defines, but still drop DAVINCI_EMAC_DCACHE.
Ok, I've dropped DAVINCI_EMAC_DCACHE (please see my v2 patches) but now
all DaVinci boards using this driver are broken...
Regards, Ilya.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-05 23:36 ` [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled Ilya Yanok
2011-10-07 17:34 ` Mike Frysinger
@ 2011-10-10 12:35 ` Stefano Babic
2011-10-10 13:03 ` Ilya Yanok
1 sibling, 1 reply; 35+ messages in thread
From: Stefano Babic @ 2011-10-10 12:35 UTC (permalink / raw)
To: u-boot
On 10/06/2011 01:36 AM, Ilya Yanok wrote:
> DaVinci EMAC is present on TI AM35xx SoCs (ARMv7) which run with D-Cache
> enabled by default. So we have to take care and flush/invalidate the
> cache before/after the DMA operations.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Hi Ilya,
> ---
> drivers/net/davinci_emac.c | 47 ++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 47 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 222a0d0..b787213 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -96,6 +96,40 @@ static volatile u_int8_t active_phy_addr = 0xff;
>
> phy_t phy;
>
> +#ifdef DAVINCI_EMAC_DCACHE
> +static inline void davinci_flush(void *addr, int size)
> +{
> + flush_dcache_range((unsigned long)addr,
> + (unsigned long)addr + size);
> +}
There is no check with the cache linesize. I get this error:
ERROR: v7_dcache_inval_range - stop address is not aligned - 0x5c0200a0
Should we not be sure that size is rounded up to align with the cache
line size ?
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 12:35 ` Stefano Babic
@ 2011-10-10 13:03 ` Ilya Yanok
2011-10-10 13:17 ` Stefano Babic
0 siblings, 1 reply; 35+ messages in thread
From: Ilya Yanok @ 2011-10-10 13:03 UTC (permalink / raw)
To: u-boot
Hi Stefano,
On 10.10.2011 16:35, Stefano Babic wrote:
>> +#ifdef DAVINCI_EMAC_DCACHE
>> +static inline void davinci_flush(void *addr, int size)
>> +{
>> + flush_dcache_range((unsigned long)addr,
>> + (unsigned long)addr + size);
>> +}
>
> There is no check with the cache linesize. I get this error:
>
> ERROR: v7_dcache_inval_range - stop address is not aligned - 0x5c0200a0
>
> Should we not be sure that size is rounded up to align with the cache
> line size ?
Surely we should. Actually it's not the size that has to be aligned but
the buffer itself. Is there any generic API to get the cache line size?
For now I've just hardcoded the 64 byte alignment but this seems to be
not perfect solution...
Regards, Ilya.
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 13:03 ` Ilya Yanok
@ 2011-10-10 13:17 ` Stefano Babic
2011-10-10 13:39 ` Wolfgang Denk
2011-10-13 22:22 ` Ilya Yanok
0 siblings, 2 replies; 35+ messages in thread
From: Stefano Babic @ 2011-10-10 13:17 UTC (permalink / raw)
To: u-boot
On 10/10/2011 03:03 PM, Ilya Yanok wrote:
> Hi Stefano,
>
Hi Ilya,
> On 10.10.2011 16:35, Stefano Babic wrote:
>>> +#ifdef DAVINCI_EMAC_DCACHE
>>> +static inline void davinci_flush(void *addr, int size)
>>> +{
>>> + flush_dcache_range((unsigned long)addr,
>>> + (unsigned long)addr + size);
>>> +}
>>
>> There is no check with the cache linesize. I get this error:
>>
>> ERROR: v7_dcache_inval_range - stop address is not aligned - 0x5c0200a0
>>
>> Should we not be sure that size is rounded up to align with the cache
>> line size ?
>
> Surely we should. Actually it's not the size that has to be aligned but
> the buffer itself. Is there any generic API to get the cache line size?
There is a CONFIG_SYS_CACHELINE_SIZE. However, I see recent patches that
can help in our case ( cache: add ALLOC_CACHE_ALIGN_BUFFER macro):
http://patchwork.ozlabs.org/patch/117698/
Wolfgang replied he has already applied, but I have not yet seen on
u-boot TOT.
Regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 13:17 ` Stefano Babic
@ 2011-10-10 13:39 ` Wolfgang Denk
2011-10-10 15:24 ` Mike Frysinger
2011-10-13 22:22 ` Ilya Yanok
1 sibling, 1 reply; 35+ messages in thread
From: Wolfgang Denk @ 2011-10-10 13:39 UTC (permalink / raw)
To: u-boot
Dear Stefano Babic,
In message <4E92F05F.4030501@denx.de> you wrote:
>
> There is a CONFIG_SYS_CACHELINE_SIZE. However, I see recent patches that
> can help in our case ( cache: add ALLOC_CACHE_ALIGN_BUFFER macro):
>
> http://patchwork.ozlabs.org/patch/117698/
>
> Wolfgang replied he has already applied, but I have not yet seen on
> u-boot TOT.
See the rest of the thread. I had applied this patch set to a loal
tree, but it was breaking hundreds of systems, so had to back out the
patches again.
I'm eager to get this code in myself, but it needs to be compile-clean
at least and harmless to all boards that don't actually reference that
code.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A modem is a baudy house.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 13:39 ` Wolfgang Denk
@ 2011-10-10 15:24 ` Mike Frysinger
2011-10-10 17:44 ` Wolfgang Denk
0 siblings, 1 reply; 35+ messages in thread
From: Mike Frysinger @ 2011-10-10 15:24 UTC (permalink / raw)
To: u-boot
On Monday 10 October 2011 09:39:16 Wolfgang Denk wrote:
> Stefano Babic wrote:
> > There is a CONFIG_SYS_CACHELINE_SIZE. However, I see recent patches that
> > can help in our case ( cache: add ALLOC_CACHE_ALIGN_BUFFER macro):
> >
> > http://patchwork.ozlabs.org/patch/117698/
> >
> > Wolfgang replied he has already applied, but I have not yet seen on
> > u-boot TOT.
>
> See the rest of the thread. I had applied this patch set to a loal
> tree, but it was breaking hundreds of systems, so had to back out the
> patches again.
>
> I'm eager to get this code in myself, but it needs to be compile-clean
> at least and harmless to all boards that don't actually reference that
> code.
sorry, but the rest of what thread ? i missed that there were issues and was
wondering why they weren't in the published master branch yet ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111010/f735c4a1/attachment.pgp
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 15:24 ` Mike Frysinger
@ 2011-10-10 17:44 ` Wolfgang Denk
2011-10-10 17:55 ` Mike Frysinger
2011-10-10 17:58 ` Anton Staaf
0 siblings, 2 replies; 35+ messages in thread
From: Wolfgang Denk @ 2011-10-10 17:44 UTC (permalink / raw)
To: u-boot
Dear Mike Frysinger,
In message <201110101124.22548.vapier@gentoo.org> you wrote:
>
> > See the rest of the thread. I had applied this patch set to a loal
> > tree, but it was breaking hundreds of systems, so had to back out the
> > patches again.
> >
> > I'm eager to get this code in myself, but it needs to be compile-clean
> > at least and harmless to all boards that don't actually reference that
> > code.
>
> sorry, but the rest of what thread ? i missed that there were issues and was
> wondering why they weren't in the published master branch yet ...
There are actually three parts to this storey:
Thisi s the original patch series, which I applied to a local test
branch with the intention to pull into mainline:
10/04 Anton Staaf [U-Boot] [PATCH v2 0/7] Add cache line alignment support
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/111026
Then I noticed that this broke all PPC4xx boards, and asked Stefan to
fix this problem. Stefan did:
10/07 Stefan Roese [PATCH 1/2] ppc: Include <asm/cache.h> in common.h
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/111482
When PPC was building again, I tested it on ARM (which I assumed was
OK, given that this was Anton's primary architecture). That was when
I finally gave up, see
10/09 To:Anton Staaf Re: [U-Boot] [PATCH v2 0/7] Add cache line alignment support
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/111713
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Maintain an awareness for contribution -- to your schedule, your
project, our company." - A Group of Employees
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 17:44 ` Wolfgang Denk
@ 2011-10-10 17:55 ` Mike Frysinger
2011-10-10 17:58 ` Anton Staaf
1 sibling, 0 replies; 35+ messages in thread
From: Mike Frysinger @ 2011-10-10 17:55 UTC (permalink / raw)
To: u-boot
On Monday 10 October 2011 13:44:21 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > See the rest of the thread. I had applied this patch set to a loal
> > > tree, but it was breaking hundreds of systems, so had to back out the
> > > patches again.
> > >
> > > I'm eager to get this code in myself, but it needs to be compile-clean
> > > at least and harmless to all boards that don't actually reference that
> > > code.
> >
> > sorry, but the rest of what thread ? i missed that there were issues and
> > was wondering why they weren't in the published master branch yet ...
>
> There are actually three parts to this storey:
>
> Thisi s the original patch series, which I applied to a local test
> branch with the intention to pull into mainline:
>
> 10/04 Anton Staaf [U-Boot] [PATCH v2 0/7] Add cache line alignment
> support http://article.gmane.org/gmane.comp.boot-loaders.u-boot/111026
>
> Then I noticed that this broke all PPC4xx boards, and asked Stefan to
> fix this problem. Stefan did:
>
> 10/07 Stefan Roese [PATCH 1/2] ppc: Include <asm/cache.h> in common.h
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/111482
>
> When PPC was building again, I tested it on ARM (which I assumed was
> OK, given that this was Anton's primary architecture). That was when
> I finally gave up, see
>
> 10/09 To:Anton Staaf Re: [U-Boot] [PATCH v2 0/7] Add cache line
> alignment support
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/111713
blah, this is the one e-mail in that thread that went into my trash somehow.
i'll follow up in the original posting; thanks.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111010/ef4c5559/attachment.pgp
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 17:44 ` Wolfgang Denk
2011-10-10 17:55 ` Mike Frysinger
@ 2011-10-10 17:58 ` Anton Staaf
2011-10-10 18:31 ` Wolfgang Denk
1 sibling, 1 reply; 35+ messages in thread
From: Anton Staaf @ 2011-10-10 17:58 UTC (permalink / raw)
To: u-boot
On Mon, Oct 10, 2011 at 10:44 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Mike Frysinger,
>
> In message <201110101124.22548.vapier@gentoo.org> you wrote:
>>
>> > See the rest of the thread. ?I had applied this patch set to a loal
>> > tree, but it was breaking hundreds of systems, so had to back out the
>> > patches again.
>> >
>> > I'm eager to get this code in myself, but it needs to be compile-clean
>> > at least and harmless to all boards that don't actually reference that
>> > code.
>>
>> sorry, but the rest of what thread ? ?i missed that there were issues and was
>> wondering why they weren't in the published master branch yet ...
>
> There are actually three parts to this storey:
>
> Thisi s the original patch series, which I applied to a local test
> branch with the intention to pull into mainline:
>
> 10/04 Anton Staaf ? ? ? ?[U-Boot] [PATCH v2 0/7] Add cache line alignment support
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/111026
>
> Then I noticed that this broke all PPC4xx boards, and asked Stefan to
> fix this problem. ?Stefan did:
>
> 10/07 Stefan Roese ? ? ? [PATCH 1/2] ppc: Include <asm/cache.h> in common.h
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/111482
>
> When PPC was building again, I tested it on ARM (which I assumed was
> OK, given that this was Anton's primary architecture). ?That was when
> I finally gave up, see
Yes, the patches expose the fact that almost no boards define
CONFIG_SYS_CACHELINE_SIZE.
I am working on a "solution" for this. My first thought is to add defines for
CONFIG_SYS_CACHELINE_SIZE in all of the arch cache.h files that
currently do not have them.
This would be all cache.h files other than the PPC one. But this
could be a huge amount of work
to look up all of the arch cacheline sizes. So I am thinking of
putting in a wrong, but large power
of two so that boards will build and probably work. But will
certainly need to be fixed up...
Another solution would be to do the above and define
CONFIG_SYS_CACHELINE_SIZE as a
large (128?) value and then indicate that that config is to deprecated
in favor of Mikes suggestion
of using the Linux CACHE BITS defines. Then we can move boards over
to that mechanism
over time, and in the mean time all boards will compile, and
architectures/boards that correctly
define their cacheline size will function correctly, and
architectures/boards that use the large default
will most likely function correctly...
-Anton
> 10/09 To:Anton Staaf ? ? Re: [U-Boot] [PATCH v2 0/7] Add cache line alignment support
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/111713
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> "Maintain an awareness for contribution -- ?to ?your ?schedule, ?your
> project, our company." ? ? ? ? ? ? ? ? ? ? ? ? - A Group of Employees
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 17:58 ` Anton Staaf
@ 2011-10-10 18:31 ` Wolfgang Denk
2011-10-10 18:45 ` Anton Staaf
0 siblings, 1 reply; 35+ messages in thread
From: Wolfgang Denk @ 2011-10-10 18:31 UTC (permalink / raw)
To: u-boot
Dear Anton Staaf,
In message <CAF6FioWbLz9JKBnj5sJGALtj=bJyLNbFvunNa6FE62y42t6-hw@mail.gmail.com> you wrote:
>
> > When PPC was building again, I tested it on ARM (which I assumed was
> > OK, given that this was Anton's primary architecture). =A0That was when
> > I finally gave up, see
>
> Yes, the patches expose the fact that almost no boards define
> CONFIG_SYS_CACHELINE_SIZE.
Um...
-> ls include/configs/* | wc -l
577
-> grep CONFIG_SYS_CACHELINE_SIZE include/configs/* | wc -l
199
So that's more than one third of all boards - most of them PPC...
> I am working on a "solution" for this. My first thought is to add defines
> for
> CONFIG_SYS_CACHELINE_SIZE in all of the arch cache.h files that
> currently do not have them.
> This would be all cache.h files other than the PPC one. But this
> could be a huge amount of work
> to look up all of the arch cacheline sizes. So I am thinking of
> putting in a wrong, but large power
> of two so that boards will build and probably work. But will
> certainly need to be fixed up...
Please don't - bogus stuff that appears to be working is known to
never get fixed. Let's rather break the boards - this enforces the
needed clean-up.
> Another solution would be to do the above and define
> CONFIG_SYS_CACHELINE_SIZE as a
> large (128?) value and then indicate that that config is to deprecated
> in favor of Mikes suggestion
> of using the Linux CACHE BITS defines. Then we can move boards over
> to that mechanism
> over time, and in the mean time all boards will compile, and
> architectures/boards that correctly
> define their cacheline size will function correctly, and
> architectures/boards that use the large default
> will most likely function correctly...
At least a big, dfat build warning must be issued, then (but only one,
not a loooooong list).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We don't have to protect the environment -- the Second Coming is at
hand." - James Watt
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 18:31 ` Wolfgang Denk
@ 2011-10-10 18:45 ` Anton Staaf
2011-10-10 23:29 ` Anton Staaf
2011-10-13 20:03 ` Wolfgang Denk
0 siblings, 2 replies; 35+ messages in thread
From: Anton Staaf @ 2011-10-10 18:45 UTC (permalink / raw)
To: u-boot
On Mon, Oct 10, 2011 at 11:31 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Anton Staaf,
>
> In message <CAF6FioWbLz9JKBnj5sJGALtj=bJyLNbFvunNa6FE62y42t6-hw@mail.gmail.com> you wrote:
>>
>> > When PPC was building again, I tested it on ARM (which I assumed was
>> > OK, given that this was Anton's primary architecture). =A0That was when
>> > I finally gave up, see
>>
>> Yes, the patches expose the fact that almost no boards define
>> CONFIG_SYS_CACHELINE_SIZE.
>
> Um...
>
> -> ls include/configs/* | wc -l
> 577
> -> grep CONFIG_SYS_CACHELINE_SIZE include/configs/* | wc -l
> 199
>
> So that's more than one third of all boards - most of them PPC...
Yes, sorry, I should have said almost no architectures define it, PPC being
the exception.
>> I am working on a "solution" for this. ?My first thought is to add defines
>> for
>> CONFIG_SYS_CACHELINE_SIZE in all of the arch cache.h files that
>> currently do not have them.
>> This would be all cache.h files other than the PPC one. ?But this
>> could be a huge amount of work
>> to look up all of the arch cacheline sizes. ?So I am thinking of
>> putting in a wrong, but large power
>> of two so that boards will build and probably work. ?But will
>> certainly need to be fixed up...
>
> Please don't - bogus stuff that appears to be working is known to
> never get fixed. ?Let's rather break the boards - this enforces the
> needed clean-up.
Yes, that's my feeling as well.
>> Another solution would be to do the above and define
>> CONFIG_SYS_CACHELINE_SIZE as a
>> large (128?) value and then indicate that that config is to deprecated
>> in favor of Mikes suggestion
>> of using the Linux CACHE BITS defines. ?Then we can move boards over
>> to that mechanism
>> over time, and in the mean time all boards will compile, and
>> architectures/boards that correctly
>> define their cacheline size will function correctly, and
>> architectures/boards that use the large default
>> will most likely function correctly...
>
> At least a big, dfat build warning must be issued, then (but only one,
> not a loooooong list).
Would you be OK with a build warning for the lack of definition of
CONFIG_SYS_CACHELINE_SIZE like I have now if it only happened
once per board? I could move it from common.h to a c file that is always
built. Perhaps I could add a checks.c file to libgeneric? I'm not really sure
if that's the right place for it. Do you have a suggestion?
This new file would include asm/cache.h and then common.h. It would then
have a #ifdef to check for CONFIG_SYS_CACHELINE_SIZE. So any arch
that defined it in it's asm/cache.h or any board that defined it in
it's config file
would be OK. All other boards would generate a single compiler warning
when building that file.
What do you think?
I would have to add a couple of empty asm/cache.h files for the architectures
that don't currently have them.
Thanks,
Anton
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> "We don't have to protect the environment -- the Second Coming is ?at
> hand." ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? - James Watt
>
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 18:45 ` Anton Staaf
@ 2011-10-10 23:29 ` Anton Staaf
2011-10-13 20:03 ` Wolfgang Denk
1 sibling, 0 replies; 35+ messages in thread
From: Anton Staaf @ 2011-10-10 23:29 UTC (permalink / raw)
To: u-boot
On Mon, Oct 10, 2011 at 11:45 AM, Anton Staaf <robotboy@chromium.org> wrote:
> On Mon, Oct 10, 2011 at 11:31 AM, Wolfgang Denk <wd@denx.de> wrote:
>> Dear Anton Staaf,
>>
>> In message <CAF6FioWbLz9JKBnj5sJGALtj=bJyLNbFvunNa6FE62y42t6-hw@mail.gmail.com> you wrote:
>>>
>>> > When PPC was building again, I tested it on ARM (which I assumed was
>>> > OK, given that this was Anton's primary architecture). =A0That was when
>>> > I finally gave up, see
>>>
>>> Yes, the patches expose the fact that almost no boards define
>>> CONFIG_SYS_CACHELINE_SIZE.
>>
>> Um...
>>
>> -> ls include/configs/* | wc -l
>> 577
>> -> grep CONFIG_SYS_CACHELINE_SIZE include/configs/* | wc -l
>> 199
>>
>> So that's more than one third of all boards - most of them PPC...
>
> Yes, sorry, I should have said almost no architectures define it, PPC being
> the exception.
>
>>> I am working on a "solution" for this. ?My first thought is to add defines
>>> for
>>> CONFIG_SYS_CACHELINE_SIZE in all of the arch cache.h files that
>>> currently do not have them.
>>> This would be all cache.h files other than the PPC one. ?But this
>>> could be a huge amount of work
>>> to look up all of the arch cacheline sizes. ?So I am thinking of
>>> putting in a wrong, but large power
>>> of two so that boards will build and probably work. ?But will
>>> certainly need to be fixed up...
>>
>> Please don't - bogus stuff that appears to be working is known to
>> never get fixed. ?Let's rather break the boards - this enforces the
>> needed clean-up.
>
> Yes, that's my feeling as well.
>
>>> Another solution would be to do the above and define
>>> CONFIG_SYS_CACHELINE_SIZE as a
>>> large (128?) value and then indicate that that config is to deprecated
>>> in favor of Mikes suggestion
>>> of using the Linux CACHE BITS defines. ?Then we can move boards over
>>> to that mechanism
>>> over time, and in the mean time all boards will compile, and
>>> architectures/boards that correctly
>>> define their cacheline size will function correctly, and
>>> architectures/boards that use the large default
>>> will most likely function correctly...
>>
>> At least a big, dfat build warning must be issued, then (but only one,
>> not a loooooong list).
>
> Would you be OK with a build warning for the lack of definition of
> CONFIG_SYS_CACHELINE_SIZE like I have now if it only happened
> once per board? ?I could move it from common.h to a c file that is always
> built. ?Perhaps I could add a checks.c file to libgeneric? ?I'm not really sure
> if that's the right place for it. ?Do you have a suggestion?
>
> This new file would include asm/cache.h and then common.h. ?It would then
> have a #ifdef to check for CONFIG_SYS_CACHELINE_SIZE. ?So any arch
> that defined it in it's asm/cache.h or any board that defined it in
> it's config file
> would be OK. ?All other boards would generate a single compiler warning
> when building that file.
>
> What do you think?
>
> I would have to add a couple of empty asm/cache.h files for the architectures
> that don't currently have them.
So I broke down and am reading all the specs I can find to determine the L1
data cache line sizes for all of the supported architectures in
U-Boot. But this
means that my patch when it comes will need a good bit of review from people
with more experience from each of these architectures. In most cases I am
opting to have cache.h define the CONFIG_SYS_CACHELINE_SIZE macro
only if it is not already defined by the board config. And then only if I can
determine a reasonable upper bound for it's value for an architecture.
This also
means that my patch will take a little longer to show up, probably tomorrow or
Wednesday would be my guess.
I plan to submit this as a separate patch set from the one that uses the value
of CONFIG_SYS_CACHELINE_SIZE to define the stack allocation macro and
it's use.
Thanks,
Anton
> Thanks,
> ? ? Anton
>
>> Best regards,
>>
>> Wolfgang Denk
>>
>> --
>> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>> "We don't have to protect the environment -- the Second Coming is ?at
>> hand." ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? - James Watt
>>
>
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 18:45 ` Anton Staaf
2011-10-10 23:29 ` Anton Staaf
@ 2011-10-13 20:03 ` Wolfgang Denk
2011-10-13 20:19 ` Anton Staaf
2011-10-13 20:36 ` Mike Frysinger
1 sibling, 2 replies; 35+ messages in thread
From: Wolfgang Denk @ 2011-10-13 20:03 UTC (permalink / raw)
To: u-boot
Dear Anton Staaf,
In message <CAF6FioWHpeA8_nPA85e3SPc17ZDCkzqkV2ROs_EAaB_9wV9vEA@mail.gmail.com> you wrote:
>
> Would you be OK with a build warning for the lack of definition of
> CONFIG_SYS_CACHELINE_SIZE like I have now if it only happened
> once per board? ...
Yes, that would be great.
> ... I could move it from common.h to a c file that is always
> built. Perhaps I could add a checks.c file to libgeneric? I'm not really sure
> if that's the right place for it. Do you have a suggestion?
I'd like to avoid a new file. But I don't have a good idea either.
Well, heck, go and add the test to the top of common/main.c .
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What can it profit a man to gain the whole world and to come to his
property with a gastric ulcer, a blown prostate, and bifocals?
-- John Steinbeck, _Cannery Row_
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-13 20:03 ` Wolfgang Denk
@ 2011-10-13 20:19 ` Anton Staaf
2011-10-13 20:31 ` Wolfgang Denk
2011-10-13 20:36 ` Mike Frysinger
1 sibling, 1 reply; 35+ messages in thread
From: Anton Staaf @ 2011-10-13 20:19 UTC (permalink / raw)
To: u-boot
On Thu, Oct 13, 2011 at 1:03 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Anton Staaf,
>
> In message <CAF6FioWHpeA8_nPA85e3SPc17ZDCkzqkV2ROs_EAaB_9wV9vEA@mail.gmail.com> you wrote:
>>
>> Would you be OK with a build warning for the lack of definition of
>> CONFIG_SYS_CACHELINE_SIZE like I have now if it only happened
>> once per board? ...
>
> Yes, that would be great.
Turns out I was able to define ARCH_DMA_MINALIGN for all U-Boot
architectures and use that
instead of the actual cache line size to generate correctly aligned
buffers. My latest
patch set implements this. So we shouldn't have any warnings being
generated and we should
have no need for the extra file (or addition to main.c) to generate
said warnings. :)
Thanks,
Anton
>> ? ? ? ? ? ? ?... I could move it from common.h to a c file that is always
>> built. ?Perhaps I could add a checks.c file to libgeneric? ?I'm not really sure
>> if that's the right place for it. ?Do you have a suggestion?
>
> I'd like to avoid a new file. ?But I don't have a good idea either.
> Well, heck, go and add the test to the top of common/main.c .
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> What can it profit a man to gain the whole world and to come ?to ?his
> property with a gastric ulcer, a blown prostate, and bifocals?
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -- John Steinbeck, _Cannery Row_
>
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-13 20:19 ` Anton Staaf
@ 2011-10-13 20:31 ` Wolfgang Denk
2011-10-13 20:40 ` Anton Staaf
0 siblings, 1 reply; 35+ messages in thread
From: Wolfgang Denk @ 2011-10-13 20:31 UTC (permalink / raw)
To: u-boot
Dear Anton Staaf,
In message <CAF6FioWnYJNBz0+4Af3-0vLCoGrgGgcN10z=K0df8Yv87GUVjw@mail.gmail.com> you wrote:
>
> Turns out I was able to define ARCH_DMA_MINALIGN for all U-Boot
> architectures and use that
> instead of the actual cache line size to generate correctly aligned
> buffers. My latest
> patch set implements this. So we shouldn't have any warnings being
> generated and we should
> have no need for the extra file (or addition to main.c) to generate
> said warnings. :)
Great. So this latest patch set is the final one?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Hokey religions and ancient weapons are no substitute for a good
blaster at your side. - Han Solo
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-13 20:31 ` Wolfgang Denk
@ 2011-10-13 20:40 ` Anton Staaf
2011-10-13 20:47 ` Wolfgang Denk
0 siblings, 1 reply; 35+ messages in thread
From: Anton Staaf @ 2011-10-13 20:40 UTC (permalink / raw)
To: u-boot
On Thu, Oct 13, 2011 at 1:31 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Anton Staaf,
>
> In message <CAF6FioWnYJNBz0+4Af3-0vLCoGrgGgcN10z=K0df8Yv87GUVjw@mail.gmail.com> you wrote:
>>
>> Turns out I was able to define ARCH_DMA_MINALIGN for all U-Boot
>> architectures and use that
>> instead of the actual cache line size to generate correctly aligned
>> buffers. ?My latest
>> patch set implements this. ?So we shouldn't have any warnings being
>> generated and we should
>> have no need for the extra file (or addition to main.c) to generate
>> said warnings. ?:)
>
> Great. ?So this latest patch set is the final one?
I believe it is correct yes. But it would be good to have each
architecture custodian
weigh in on the architectures I couldn't test directly. Also, Mike
has submitted a
patch that adds the asm/cache.h file for blackfin from the Linux
kernel. This patch
obsoletes one of the patches in my series. My thinking is that we
should wait a bit to
hear from other custodians, and then I'll send a second version of the
patch set that
addresses any comments. But I am also pretty confident that we could submit the
existing patch set (minus the blackfin asm/cache.h patch) and we would be safe.
Thanks,
Anton
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Hokey religions and ancient weapons are ?no ?substitute ?for ?a ?good
> blaster at your side. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?- Han Solo
>
^ permalink raw reply [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-13 20:40 ` Anton Staaf
@ 2011-10-13 20:47 ` Wolfgang Denk
0 siblings, 0 replies; 35+ messages in thread
From: Wolfgang Denk @ 2011-10-13 20:47 UTC (permalink / raw)
To: u-boot
Dear Anton Staaf,
In message <CAF6FioXcAAP=QOF3a5s_L6zUB5ArEUAQYutruAx=bPmt7rG9dQ@mail.gmail.com> you wrote:
>
> I believe it is correct yes. But it would be good to have each
> architecture custodian
> weigh in on the architectures I couldn't test directly. Also, Mike
> has submitted a
> patch that adds the asm/cache.h file for blackfin from the Linux
> kernel. This patch
> obsoletes one of the patches in my series. My thinking is that we
> should wait a bit to
> hear from other custodians, and then I'll send a second version of the
> patch set that
> addresses any comments. But I am also pretty confident that we could submit the
> existing patch set (minus the blackfin asm/cache.h patch) and we would be safe.
OK. so I'll wait for your next version patch set. Thanks!!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The more data I punch in this card, the lighter it becomes, and the
lower the mailing cost."
- Stan Kelly-Bootle, "The Devil's DP Dictionary"
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-13 20:03 ` Wolfgang Denk
2011-10-13 20:19 ` Anton Staaf
@ 2011-10-13 20:36 ` Mike Frysinger
2011-10-13 20:44 ` Anton Staaf
1 sibling, 1 reply; 35+ messages in thread
From: Mike Frysinger @ 2011-10-13 20:36 UTC (permalink / raw)
To: u-boot
On Thursday 13 October 2011 16:03:37 Wolfgang Denk wrote:
> Anton Staaf wrote:
> > ... I could move it from common.h to a c file that is always
> >
> > built. Perhaps I could add a checks.c file to libgeneric? I'm not
> > really sure if that's the right place for it. Do you have a suggestion?
>
> I'd like to avoid a new file. But I don't have a good idea either.
> Well, heck, go and add the test to the top of common/main.c .
fwiw, we added a dummy file in the Blackfin linux port called "arch_checks.c"
where we kept all of our #ifdef sanity checks. that way it got checked once
(rather than in every header include), and we didn't have to clutter up semi-
related files with it.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111013/5b6478b4/attachment.pgp
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-13 20:36 ` Mike Frysinger
@ 2011-10-13 20:44 ` Anton Staaf
0 siblings, 0 replies; 35+ messages in thread
From: Anton Staaf @ 2011-10-13 20:44 UTC (permalink / raw)
To: u-boot
On Thu, Oct 13, 2011 at 1:36 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday 13 October 2011 16:03:37 Wolfgang Denk wrote:
>> Anton Staaf wrote:
>> > ? ? ? ? ? ? ?... I could move it from common.h to a c file that is always
>> >
>> > built. ?Perhaps I could add a checks.c file to libgeneric? ?I'm not
>> > really sure if that's the right place for it. ?Do you have a suggestion?
>>
>> I'd like to avoid a new file. ?But I don't have a good idea either.
>> Well, heck, go and add the test to the top of common/main.c .
>
> fwiw, we added a dummy file in the Blackfin linux port called "arch_checks.c"
> where we kept all of our #ifdef sanity checks. ?that way it got checked once
> (rather than in every header include), and we didn't have to clutter up semi-
> related files with it.
This makes sense to me, as it is pretty much what I did initially. I ended up
not sending that patch up because I was able to define ARCH_DMA_MINALIGN for
all architectures we care about. But in the future it might be a good pattern
for static checking configs.
Thanks,
Anton
> -mike
>
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled
2011-10-10 13:17 ` Stefano Babic
2011-10-10 13:39 ` Wolfgang Denk
@ 2011-10-13 22:22 ` Ilya Yanok
1 sibling, 0 replies; 35+ messages in thread
From: Ilya Yanok @ 2011-10-13 22:22 UTC (permalink / raw)
To: u-boot
Hi Stefano,
On 10.10.2011 17:17, Stefano Babic wrote:
>>> Should we not be sure that size is rounded up to align with the cache
>>> line size ?
>>
>> Surely we should. Actually it's not the size that has to be aligned but
>> the buffer itself. Is there any generic API to get the cache line size?
>
> There is a CONFIG_SYS_CACHELINE_SIZE. However, I see recent patches that
Yes, that's what I need. But it looks like it's defined mostly for the
PPC boards..
> can help in our case ( cache: add ALLOC_CACHE_ALIGN_BUFFER macro):
>
> http://patchwork.ozlabs.org/patch/117698/
Hm.. Well, actually I need to align the static buffer, so I don't need
this, __aligned(CONFIG_SYS_CACHELINE_SIZE) does the trick.
Regards, Ilya.
^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH 5/6] davinci_emac: hardcode 100Mbps for AM35xx and RMII
2011-10-05 23:36 [U-Boot] [RFC PATCH 0/0] Support for DaVinci EMAC on TI AM35xx Ilya Yanok
` (3 preceding siblings ...)
2011-10-05 23:36 ` [U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled Ilya Yanok
@ 2011-10-05 23:36 ` Ilya Yanok
2011-10-05 23:36 ` [U-Boot] [PATCH 6/6] AM35xx: add EMAC defines Ilya Yanok
5 siblings, 0 replies; 35+ messages in thread
From: Ilya Yanok @ 2011-10-05 23:36 UTC (permalink / raw)
To: u-boot
For some reason code setting the speed based on the PHY feedback causes
troubles on AM3517 so hardcode 100Mbps for now.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
drivers/net/davinci_emac.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index b787213..bac3279 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -462,7 +462,8 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis)
writel(1, &adap_emac->RXUNICASTSET);
/* Enable MII interface and Full duplex mode */
-#ifdef CONFIG_SOC_DA8XX
+#if defined(CONFIG_SOC_DA8XX) || \
+ (defined(CONFIG_OMAP34XX) && defined(CONFIG_DRIVER_TI_EMAC_USE_RMII))
writel((EMAC_MACCONTROL_MIIEN_ENABLE |
EMAC_MACCONTROL_FULLDUPLEX_ENABLE |
EMAC_MACCONTROL_RMIISPEED_100),
--
1.7.6.2
^ permalink raw reply related [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 6/6] AM35xx: add EMAC defines
2011-10-05 23:36 [U-Boot] [RFC PATCH 0/0] Support for DaVinci EMAC on TI AM35xx Ilya Yanok
` (4 preceding siblings ...)
2011-10-05 23:36 ` [U-Boot] [PATCH 5/6] davinci_emac: hardcode 100Mbps for AM35xx and RMII Ilya Yanok
@ 2011-10-05 23:36 ` Ilya Yanok
2011-10-06 21:01 ` Wolfgang Denk
5 siblings, 1 reply; 35+ messages in thread
From: Ilya Yanok @ 2011-10-05 23:36 UTC (permalink / raw)
To: u-boot
AM35xx has DaVinci-compatible EMAC.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
arch/arm/include/asm/arch-omap3/emac_defs.h | 57 +++++++++++++++++++++++++++
1 files changed, 57 insertions(+), 0 deletions(-)
create mode 100755 arch/arm/include/asm/arch-omap3/emac_defs.h
diff --git a/arch/arm/include/asm/arch-omap3/emac_defs.h b/arch/arm/include/asm/arch-omap3/emac_defs.h
new file mode 100755
index 0000000..cd54bd0
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap3/emac_defs.h
@@ -0,0 +1,57 @@
+/*
+ * Copyright (C) 2007 Sergey Kubushyn <ksi@koi8.net>
+ *
+ * Based on:
+ *
+ * ----------------------------------------------------------------------------
+ *
+ * dm644x_emac.h
+ *
+ * TI DaVinci (DM644X) EMAC peripheral driver header for DV-EVM
+ *
+ * Copyright (C) 2005 Texas Instruments.
+ *
+ * ----------------------------------------------------------------------------
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * ----------------------------------------------------------------------------
+
+ * Modifications:
+ * ver. 1.0: Sep 2005, TI PSP Team - Created EMAC version for uBoot.
+ *
+ */
+
+#ifndef _AM3517_EMAC_H_
+#define _AM3517_EMAC_H_
+
+#define EMAC_BASE_ADDR 0x5C010000
+#define EMAC_WRAPPER_BASE_ADDR 0x5C000000
+#define EMAC_WRAPPER_RAM_ADDR 0x5C020000
+#define EMAC_MDIO_BASE_ADDR 0x5C030000
+#define EMAC_HW_RAM_ADDR 0x01E20000
+
+#define EMAC_MDIO_BUS_FREQ 166000000 /* 166 MHZ check */
+#define EMAC_MDIO_CLOCK_FREQ 1000000 /* 2.0 MHz */
+
+/* SOFTRESET macro definition interferes with emac_regs structure definition */
+#undef SOFTRESET
+
+typedef volatile unsigned int dv_reg;
+typedef volatile unsigned int * dv_reg_p;
+
+#define DAVINCI_EMAC_VERSION2
+#define DAVINCI_EMAC_DCACHE
+
+#endif /* _AM3517_EMAC_H_ */
--
1.7.6.2
^ permalink raw reply related [flat|nested] 35+ messages in thread* [U-Boot] [PATCH 6/6] AM35xx: add EMAC defines
2011-10-05 23:36 ` [U-Boot] [PATCH 6/6] AM35xx: add EMAC defines Ilya Yanok
@ 2011-10-06 21:01 ` Wolfgang Denk
0 siblings, 0 replies; 35+ messages in thread
From: Wolfgang Denk @ 2011-10-06 21:01 UTC (permalink / raw)
To: u-boot
Dear Ilya Yanok,
In message <1317857806-16549-7-git-send-email-yanok@emcraft.com> you wrote:
> AM35xx has DaVinci-compatible EMAC.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> arch/arm/include/asm/arch-omap3/emac_defs.h | 57 +++++++++++++++++++++++++++
> 1 files changed, 57 insertions(+), 0 deletions(-)
> create mode 100755 arch/arm/include/asm/arch-omap3/emac_defs.h
Checkpatch says:
total: 2 errors, 4 warnings, 57 lines checked
Please clean up and resubmit. Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The day-to-day travails of the IBM programmer are so amusing to most
of us who are fortunate enough never to have been one - like watching
Charlie Chaplin trying to cook a shoe.
^ permalink raw reply [flat|nested] 35+ messages in thread