LL TEMAC V7 refactored

Xilinx LocalLink Tri-Mode Ether MAC driver can be used by Xilinx Microblaze or Xilinx ppc405/440 in SDMA and FIFO mode. DCR or XPS bus can be used.

The driver uses and requires MII and PHYLIB.

CP: 4 warnings: 'Use of volatile is usually wrong' I won't fix this, because it depends on the network driver subsystem.

Signed-off-by Stephan Linz <[email protected]>

Dear Stephan Linz,

Quoted 6 lines · In message <[email protected]> you wrote:

Xilinx LocalLink Tri-Mode Ether MAC driver can be used by Xilinx Microblaze or Xilinx ppc405/440 in SDMA and FIFO mode. DCR or XPS bus can be used.

The driver uses and requires MII and PHYLIB.

Quoted 5 lines

CP: 4 warnings: 'Use of volatile is usually wrong' I won't fix this, because it depends on the network driver subsystem.

Signed-off-by Stephan Linz <[email protected]>

Are there going to be any users for this code?

Dear Stephan Linz,

Quoted 6 lines · In message <[email protected]> you wrote:

Xilinx LocalLink Tri-Mode Ether MAC driver can be used by Xilinx Microblaze or Xilinx ppc405/440 in SDMA and FIFO mode. DCR or XPS bus can be used.

The driver uses and requires MII and PHYLIB.

Quoted 5 lines

CP: 4 warnings: 'Use of volatile is usually wrong' I won't fix this, because it depends on the network driver subsystem.

Signed-off-by Stephan Linz <[email protected]>

Are there going to be any users for this code?

Quoted 2 lines

Are there going to be any users for this code?

Sure. This driver lies out of mainline code for quite some times. ll_temac is IP core which is used by Microblaze and xilinx ppc. There are two options for network IP. The first is emaclite driver which is in the mainline and high speed and especially 1Gb/s LAN ll_temac driver.

Dear Michal Simek,

Quoted 1 line · In message <[email protected]> you wrote:

Quoted 6 lines

Quoted 1 line

Are there going to be any users for this code?

Sure. This driver lies out of mainline code for quite some times. ll_temac is IP core which is used by Microblaze and xilinx ppc. There are two options for network IP. The first is emaclite driver which is in the mainline and high speed and especially 1Gb/s LAN ll_temac driver.

Then let's add it when the first board gets submitted that uses it.

Michals latest Microblaze platform patches will enable this driver for board/xilinx/microblaze-generic and we know about a success story on a propietary Virtex5 FX board (ppc440) -- tested by Ricardo Ribalda.

So it could be save to add the driver together with Michals platform patches. It works fine to me on different ML605 (Virtex 6) and SP3ADSP1800 (Spartan 3) Microblaze systems but ...

Last week, I received hints from Andy Fleming to improve the PHYLIB handling and avoid deprecated code. So I'll rework the driver and present a new v8 patch as soon as possible.

Dear Stephan Linz,

Quoted 5 lines · In message <1325783490.7827.45.camel@keto> you wrote:

Michals latest Microblaze platform patches will enable this driver for board/xilinx/microblaze-generic and we know about a success story on a propietary Virtex5 FX board (ppc440) -- tested by Ricardo Ribalda.

Quoted 1 line

-- snip --

So I'll rework the driver and

Quoted 1 line

present a new v8 patch as soon as possible.

OK. Please submit it only if it comes with code that references the driver.

Am Donnerstag, den 05.01.2012, 20:19 +0100 schrieb Wolfgang Denk:

Quoted 7 lines

Dear Stephan Linz,

Quoted 4 lines · In message <1325783490.7827.45.camel@keto> you wrote:

Michals latest Microblaze platform patches will enable this driver for board/xilinx/microblaze-generic and we know about a success story on a propietary Virtex5 FX board (ppc440) -- tested by Ricardo Ribalda.

Quoted 5 lines

Quoted 1 line

-- snip --

So I'll rework the driver and

Quoted 1 line

present a new v8 patch as soon as possible.

OK. Please submit it only if it comes with code that references the driver.

Hi Wolfgang,

I understand your opinions to stick together all the different code fragments. Unfortunately, this driver will be used by systems with synthesized hardware (FPGA SoftCPU systems). The target board (hardware around the FPGA) will be fixed but the content (CPU, controller, busses, interfacess, addresses, ...) will be variable and not fixed. That's why we use a so named microblaze-generic board configuration controlled by the header xparameters.h in board directory. The default content of xparameters.h is really only basic and enables not nearly half of all possibilities. For example the default configuration in xparameters.h will enable the Xilinx EMAC-Lite driver (with XILINX_EMACLITE_BASEADDR) but do nothing to enable the Xilinx AXI-EMAC driver (with XILINX_AXIEMAC_BASEADDR) -- it makes no sense to enable both at the same time.

I'll provide the same way for the Xilinx LL_TEMAC driver as for the Xilinx AXI-EMAC driver. I prepare the microblaze-generic board code to support all potential Ethernet drivers but leave out the specific usage. You are right when you say that there is no code that refere to the new driver code -- there are also no configuration for this. And yes we adapt/change the xparameters.h out of mainline tree to enable the driver code -- but I think, that is not really a "out of tree port".

But what would be the best implementation for unspecified targets here?

@Michal: Is there anybody who use the current default configuration from microblaze-generic/xparameters.h on a real FPGA system design? If not we could expand xparameters.h with a fantasy configuration to enable all potential drivers used on a Microblaze system. So we have a reference to driver code and can test the rebuild again and again with a simple 'make microblaze-generic'. What do you mean?

I'll provide the same way for the Xilinx LL_TEMAC driver as for the Xilinx AXI-EMAC driver. I prepare the microblaze-generic board code to support all potential Ethernet drivers but leave out the specific usage. You are right when you say that there is no code that refere to the new driver code -- there are also no configuration for this. And yes we adapt/change the xparameters.h out of mainline tree to enable the driver code -- but I think, that is not really a "out of tree port".

But what would be the best implementation for unspecified targets here?

Dear Stephan Linz,

Quoted 9 lines · In message <1325956366.18981.47.camel@keto> you wrote:

I'll provide the same way for the Xilinx LL_TEMAC driver as for the Xilinx AXI-EMAC driver. I prepare the microblaze-generic board code to support all potential Ethernet drivers but leave out the specific usage. You are right when you say that there is no code that refere to the new driver code -- there are also no configuration for this. And yes we adapt/change the xparameters.h out of mainline tree to enable the driver code -- but I think, that is not really a "out of tree port".

But what would be the best implementation for unspecified targets here?

The question is actually a very simple one here: is there any board configuration in mainline that will actually compile and link against this driver? If yes, then everything is fine. If not, we would not even know if there were gross syntax errors in that code, and we would never notce when changes to other parts break compatibility with it.

This is why I will not add any code that is not used in mainline - out-of-tree users don't help a bit.

Quoted 4 lines · Wolfgang Denk

Dear Stephan Linz,

Quoted 1 line

Quoted 1 line

But what would be the best implementation for unspecified targets here?

Quoted 8 lines

The question is actually a very simple one here: is there any board configuration in mainline that will actually compile and link against this driver? If yes, then everything is fine. If not, we would not even know if there were gross syntax errors in that code, and we would never notce when changes to other parts break compatibility with it.

This is why I will not add any code that is not used in mainline - out-of-tree users don't help a bit.

OK. Stephan, please send v8 with suggested changes with all patches or link to patches which are necessary to use.
Please also define fake address XILINX_LLTEMAC_BASEADDR in xparameters.h to be compiled. The same we will do for axi emac driver.

Stephan if you like I can add that changes to my custodian git tree and do final testing before we ask Wolfgang to merge.

drivers/net/xilinx_ll_temac.c new file +17 -0

+static int phywrite(struct eth_device *dev, u8 phy_addr,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u8 reg_addr, u16 phy_data)
+{
+ ? ? ? struct temac_reg *regs = (struct temac_reg *)dev->iobase;
+
+ ? ? ? out_be32(&regs->lsw, (phy_data & LSW_REGDAT_MASK));
+ ? ? ? out_be32(&regs->ctl, CTL_WEN | TEMAC_MIIMWD);
+
+ ? ? ? out_be32(&regs->lsw,
+ ? ? ? ? ? ? ? ((phy_addr << LSW_PHYAD_POS) & LSW_PHYAD_MASK) |
+ ? ? ? ? ? ? ? (reg_addr & LSW_REGAD_MASK));
+ ? ? ? out_be32(&regs->ctl, CTL_WEN | TEMAC_MIIMAI);
+
+ ? ? ? if (check_status(regs, RSE_MIIM_WR))
+ ? ? ? ? ? ? ? return 1;
+
+ ? ? ? return 0;

(quoted diff) +9 -0

+static int ll_temac_miiphy_read(const char *devname, unsigned char addr,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned char reg, unsigned short *value)
+{
+ ? ? ? int ret;
+ ? ? ? struct eth_device *dev = eth_get_dev();
+
+ ? ? ? ret = phyread(dev, addr, reg, value);
+ ? ? ? debug("%s 0x%x, 0x%x, 0x%x\n", __func__, addr, reg, *value);
+ ? ? ? return ret;

(quoted diff) +62 -0

+
+/*
+ * bis: ? ? ? ? ? ? ? ?board information
+ * base_addr: ?LL TEMAC register bank
+ * ctrl_addr: ?LL TEMAC sub-controller register bank (FIFO or SDMA)
+ * mode: ? ? ? driver mode bit flags (see xilinx_ll_temac.h)
+ */
+int xilinx_ll_temac_initialize(bd_t *bis, unsigned long base_addr,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? int mode, unsigned long ctrl_addr)
+{
+ ? ? ? struct eth_device *dev;
+ ? ? ? struct ll_temac *ll_temac;
+
+ ? ? ? dev = calloc(1, sizeof(*dev));
+ ? ? ? if (dev == NULL)
+ ? ? ? ? ? ? ? return -1;
+
+ ? ? ? dev->priv = calloc(1, sizeof(struct ll_temac));
+ ? ? ? if (dev->priv == NULL) {
+ ? ? ? ? ? ? ? free(dev);
+ ? ? ? ? ? ? ? return -1;
+ ? ? ? }
+
+ ? ? ? ll_temac = dev->priv;
+
+ ? ? ? sprintf(dev->name, "Xlltem.%lx", base_addr);
+
+ ? ? ? dev->iobase = base_addr;
+ ? ? ? ll_temac->ctrladdr = ctrl_addr;
+ ? ? ? ll_temac->rx_bp = rx_buffer;
+ ? ? ? ll_temac->tx_bp = tx_buffer;
+ ? ? ? ll_temac->rx_dp = &rx_descr;
+ ? ? ? ll_temac->tx_dp = &tx_descr;
+ ? ? ? ll_temac->phyaddr = CONFIG_PHY_ADDR;
+
+ ? ? ? dev->init = ll_temac_init;
+ ? ? ? dev->halt = ll_temac_halt;
+ ? ? ? dev->write_hwaddr = ll_temac_addr_setup;
+
+ ? ? ? if (mode & M_SDMA) {
+#if defined(CONFIG_XILINX_440) || defined(CONFIG_XILINX_405)
+ ? ? ? ? ? ? ? if (mode & M_DCR) {
+ ? ? ? ? ? ? ? ? ? ? ? ll_temac_collect_xldcr_sdma_reg_addr(dev);
+ ? ? ? ? ? ? ? ? ? ? ? ll_temac->in32 = ll_temac_xldcr_in32;
+ ? ? ? ? ? ? ? ? ? ? ? ll_temac->out32 = ll_temac_xldcr_out32;
+ ? ? ? ? ? ? ? } else
+#endif
+ ? ? ? ? ? ? ? {
+ ? ? ? ? ? ? ? ? ? ? ? ll_temac_collect_xlplb_sdma_reg_addr(dev);
+ ? ? ? ? ? ? ? ? ? ? ? ll_temac->in32 = ll_temac_xlplb_in32;
+ ? ? ? ? ? ? ? ? ? ? ? ll_temac->out32 = ll_temac_xlplb_out32;
+ ? ? ? ? ? ? ? }
+ ? ? ? ? ? ? ? ll_temac->ctrlinit = ll_temac_init_sdma;
+ ? ? ? ? ? ? ? ll_temac->ctrlhalt = ll_temac_halt_sdma;
+ ? ? ? ? ? ? ? ll_temac->ctrlreset = ll_temac_reset_sdma;
+ ? ? ? ? ? ? ? dev->recv = ll_temac_recv_sdma;
+ ? ? ? ? ? ? ? dev->send = ll_temac_send_sdma;
+ ? ? ? } else {
+ ? ? ? ? ? ? ? ll_temac->in32 = NULL;
+ ? ? ? ? ? ? ? ll_temac->out32 = NULL;
+ ? ? ? ? ? ? ? ll_temac->ctrlinit = NULL;
+ ? ? ? ? ? ? ? ll_temac->ctrlhalt = NULL;