[U-Boot] [RFC PATCH 0/0] Support for DaVinci EMAC on TI AM35xx

[U-Boot] [RFC PATCH 0/0] Support for DaVinci EMAC on TI AM35xx

[Ilya Yanok]

Hi,

These series bring support of DaVinci EMAC interface on TI AM35xx
processors.
Changes:
 1. Common defines and register definitions moved to
drivers/net/davinci_emac.h
 2. Added coding/decoding of internal RAM addresses.
 3. DaVinci-specific PHY parts moved under #ifdefs.
 4. Added support for running with D-Cache enabled. Actually
this part is broken as of cabe287 commit and I need your guidance how
to proceed there. Should I check the cache line size and care about
alignment from the driver? Shouldn't this be abstracted by some sort
of API?
 5. Speed is hardcoded to 100Mbps. This definetely needs a better
solution but somehow existing code causes troubles.
 6. AM35xx-specific defines added into the separate header.

I'm not sure if I should just squash all the patches into one.

Thanks.

Signed-off-by: Ilya Yanok <yanok@emcraft.com>

[U-Boot] [PATCH 1/6] davinci_emac: move arch-independent defines to separate header

[Ilya Yanok]

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

[U-Boot] [PATCH 2/6] davinci_emac: use internal addresses in buffer descriptors

[Ilya Yanok]

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

[U-Boot] [PATCH 3/6] davinci_emac: conditionally compile specific PHY support

[Ilya Yanok]

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

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Ilya Yanok]

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

[U-Boot] [PATCH 5/6] davinci_emac: hardcode 100Mbps for AM35xx and RMII

[Ilya Yanok]

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

[U-Boot] [PATCH 6/6] AM35xx: add EMAC defines

[Ilya Yanok]

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

[U-Boot] [PATCH 6/6] AM35xx: add EMAC defines

[Wolfgang Denk]

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.

[U-Boot] [PATCH 2/6] davinci_emac: use internal addresses in buffer descriptors

[Wolfgang Denk]

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

[U-Boot] [PATCH 1/6] davinci_emac: move arch-independent defines to separate header

[Wolfgang Denk]

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

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Mike Frysinger]

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 

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Ilya Yanok]

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.

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Laurence Withers]

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

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Mike Frysinger]

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 

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Stefano Babic]

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
=====================================================================

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Ilya Yanok]

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.

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Stefano Babic]

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
=====================================================================

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Wolfgang Denk]

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.

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Mike Frysinger]

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 

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Wolfgang Denk]

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

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Mike Frysinger]

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 

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Anton Staaf]

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
>

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Wolfgang Denk]

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

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Anton Staaf]

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
>

[U-Boot] [PATCH 1/6] davinci_emac: move arch-independent defines to separate header

[Ilya Yanok]

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.

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Anton Staaf]

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
>>
>

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Wolfgang Denk]

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_

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Anton Staaf]

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_
>

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Wolfgang Denk]

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

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Mike Frysinger]

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 

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Anton Staaf]

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
>

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Anton Staaf]

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
>

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Wolfgang Denk]

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"

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Ilya Yanok]

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.

[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Ilya Yanok]

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.