can_get_echo_skb() is usually called in the TX complete handler.
The stats->tx_packets and stats->tx_bytes should be updated there, too.
This patch simplifies to figure out the size of the sent CAN frame.

Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

Use circle buf to replace old ringbuf mechanism.
Change to use circle buffer in read, write, rx isr and tx isr functions.
In first design of MLB, it's using it's own mechanism to manage ring
buffer, like in mxc_mlb.c.
And then, I saw that kernel already had a serials of circ buffer macros
which can be used to manage ring buffers.
This patch is to use circle buffer macros to manage mlb internal ring
buffers.
For detail of circle buffers, you can refer to
linux-2.6-imx/Documentation/circular-buffers.txt.

Signed-off-by: Terry Lv <r65388@freescale.com>

All of the interrupts from the ENET block are not routed to
the GPC block. Hence ENET interrupts are not able to wake
up the SOC when the system is in WAIT mode. And the ENET
interrupt gets serviced only when another interrupt causes
the SOC to exit WAIT mode. This impacts the ENET performance.

To fix the issue two options:
1. Route the ENET interrupt to a GPIO. Need to enable the
CONFIG_MX6_ENET_IRQ_TO_GPIO in the config.
2. If the GPIO mechanism cannot be used and is not enabled
by the above mentioned config, the patch will disable entry
to WAIT mode until ENET clock is active. When the ENET clock
is disabled, WAIT mode will be automatically enetered.

Signed-off-by: Ranjani Vaidyanathan <ra5478@freescale.com>

During the read of NOR, the kernel actually calls the inline_map_copy_from()
to read the data out. And inline_map_copy_from() will use the memcpy_fromio()
to do the real job.

The memcpy_fromio macro maps _memcpy_fromio() in the current code.
But the _memcpy_fromio() will use readb() to do the copy work one byte
by one byte. This makes the read performance of NOR very slow(about 2~3MB/s).

A similiar discussion could be found in:
http://lists.infradead.org/pipermail/linux-arm-kernel/2009-November/003860.html

This patch replace the memcpy_fromio with memcpy which is optimized by the
kernel.

The following is the result from mtd_speedtest with M29W256GL7AN6E:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: not NAND flash, assume page size is 512 bytes.
mtd_speedtest: MTD device size 4194304, eraseblock size 131072, page size 512,
		count of eraseblocks 32, pages per eraseblock 256, OOB size 0
mtd_speedtest: testing eraseblock write speed
mtd_speedtest: eraseblock write speed is 845 KiB/s
mtd_speedtest: testing eraseblock read speed
mtd_speedtest: eraseblock read speed is 19504 KiB/s
mtd_speedtest: testing page write speed
mtd_speedtest: page write speed is 845 KiB/s
mtd_speedtest: testing page read speed
mtd_speedtest: page read speed is 19140 KiB/s
mtd_speedtest: testing 2 page write speed
mtd_speedtest: 2 page write speed is 846 KiB/s
mtd_speedtest: testing 2 page read speed
mtd_speedtest: 2 page read speed is 19320 KiB/s
mtd_speedtest: Testing erase speed
mtd_speedtest: erase speed is 233 KiB/s
mtd_speedtest: Testing 2x multi-block erase speed
mtd_speedtest: 2x multi-block erase speed is 225 KiB/s
mtd_speedtest: Testing 4x multi-block erase speed
mtd_speedtest: 4x multi-block erase speed is 224 KiB/s
mtd_speedtest: Testing 8x multi-block erase speed
mtd_speedtest: 8x multi-block erase speed is 225 KiB/s
mtd_speedtest: Testing 16x multi-block erase speed
mtd_speedtest: 16x multi-block erase speed is 225 KiB/s
mtd_speedtest: Testing 32x multi-block erase speed
mtd_speedtest: 32x multi-block erase speed is 225 KiB/s
mtd_speedtest: Testing 64x multi-block erase speed
mtd_speedtest: 64x multi-block erase speed is 224 KiB/s
mtd_speedtest: finished
=================================================

Signed-off-by: Huang Shijie <b32955@freescale.com>

This reverts commit 573bab0be2427d6664420eaf9d8e272dbe9d840f.

i.mx6dl/dq sabreauto/sabresd board will boot up failed
randomly with this patch-set, thus revert it. [Jason]

Signed-off-by: Jason Liu <r64343@freescale.com>

All of the interrupts from the ENET block are not routed to
the GPC block. Hence ENET interrupts are not able to wake
up the SOC when the system is in WAIT mode. And the ENET
interrupt gets serviced only when another interrupt causes
the SOC to exit WAIT mode. This impacts the ENET performance.

To fix the issue two options:
1. Route the ENET interrupt to a GPIO. Need to enable the
CONFIG_MX6_ENET_IRQ_TO_GPIO in the config.
This patch provides support for routing the ENET interrupt
to GPIO_1_6. Routing to this GPIO requires no HW board mods.
If the GPIO_1_6 is being used for some other peripheral,
this patch can be followed to route the ENET interrupt to
any other GPIO though a HW mode maybe required.
2. If the GPIO mechanism cannot be used and is not enabled
by the above mentioned config, the patch will disable entry
to WAIT mode until ENET clock is active. When the ENET clock
is disabled, WAIT mode will be automatically enetered.

Signed-off-by: Ranjani Vaidyanathan <ra5478@freescale.com>

Conflicts:
	drivers/net/fec.c