topic FEC driver problem on i.mx25 in i.MX Processors

FEC driver problem on i.mx25

sethbollinger — Wed, 12 Oct 2011 21:02:36 GMT

Hello All,

Sometimes the FEC driver will stall with a descriptor in the DMA ring that's ready for transmit but FEC_X_DES_ACTIVE bit is not enabled. This buffer will remain jammed in the ring until another transmit request is queued.

Has anyone else seen this issue? Is there a known solution?

We have worked around the problem by keeping a count of tx ready descriptor, then we check that count at the end of fec_enet_rx(). If we have at least one tx descriptor ready, but the DMA TX controller is not active, we give it a bump.

We would like to avoid this situation rather than work around it.

Thanks,

Seth

Re: FEC driver problem on i.mx25

fabio_estevam — Thu, 13 Oct 2011 17:37:13 GMT

Could you please try a 3.0 kernel and let us know if you face the same issue?

If you do, please list the steps on how to reproduce this problem.

Regards,

Fabio Estevam

Re: FEC driver problem on i.mx25

sethbollinger — Fri, 14 Oct 2011 17:05:22 GMT

We don't have a BSP for the 3.0 kernel. It will take some time to get that working. I will let you know when I gather that data.

Is there a reason you think this is fixed in kernels beyond 2.6.35.14?

Thanks,

Seth

Re: FEC driver problem on i.mx25

fabio_estevam — Fri, 14 Oct 2011 19:09:37 GMT

I don't have any details about the problem you mention. 2.6.35 kernel does not receive any more updates, so it is a good idea to try 3.0 to check if the problem still exists or not.

If you see the problem, then the drivers/net folks would be interested in fixing it.

Re: FEC driver problem on i.mx25

wolfgang_gaerbe — Tue, 22 May 2012 11:30:09 GMT

Comment found in actual u-boot driver:

================================================================

When only one BD is in
* use it must be marked with the WRAP bit to use it for every transmitt.
* This bit in combination with the READY bit results into double transmit
* of each data buffer. It seems the state machine checks READY earlier then
* resetting it after the first transfer.
* Using two BDs solves this issue.

========================================================

We observed similar problems on processing the last descriptor in a ringbuffer.....

What´s even more scary - is that is obvious race condition depends somehow on chip revisions.

Identical code failed on our board - but not on the evk. So be careful with the last descriptor ;-))