[U-Boot] [PATCH v2 2/2] net: fec_mxc: Do not error out when FEC_TBD_READY

Marek Vasut marex at denx.de
Thu Aug 21 05:47:18 CEST 2014


On Wednesday, August 20, 2014 at 11:34:30 PM, Otavio Salvador wrote:
> On Wed, Aug 20, 2014 at 6:24 PM, Fabio Estevam <festevam at gmail.com> wrote:
> > From: Fabio Estevam <fabio.estevam at freescale.com>
> > 
> > Do not indicate an error when the buffer ready flag (FEC_TBD_READY) is
> > set.
> > 
> > Without this change, mx6solox is not capable of doing TFTP transfers.
> > 
> > Succesfully tested on mx25, mx28, mx51, mx53, mx6q, mx6sl and mx6sx.
> > 
> > Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> 
> As you explicitly tested it in several SoC types it seems right
> however Marek has explicitly add this code in:
> 
>     FEC: Rework the TX wait mechanism
> 
>     The mechanism waiting for transmission to finish in fec_send() now
>     relies on the E-bit being cleared in the TX buffer descriptor. In
>     case of data cache being on, this means invalidation of data cache
>     above this TX buffer descriptor on each test for the E-bit being
>     cleared.
> 
>     Apparently, there is another way to check if the transmission did
>     complete. This is by checking the TDAR bit in the X_DES_ACTIVE
>     register. Reading a register does not need any data cache invalidation,
>     which is beneficial.
> 
>     Rework the sequence that wait for completion of the transmission so
> that the TDAR bit is tested first and afterwards check the E-bit being
> clear. This cuts down the number of cache invalidation calls to one.

It would come very helpful if you also provided the commit hash, so people can 
observe what was the contents of the patch. So let me fill it in:

Commit: 67449098a86be18cbdb27345bebe8da57e5d8899

> May Marek recall why this was need?

It's explained in the commit message above, quote:

'In case of data cache being on, this means invalidation of data cache above 
this TX buffer descriptor on each test for the E-bit being cleared.'

This means that it avoids the constant ping-pong between cache and DRAM. That is 
a loop consisting of:
- invalidating D-cache
- doing memory access to re-load the DMA descriptor from DRAM
- checking the E-bit in the DMA descriptor.
Instead, it reads the status from uncached register space of the FEC.

Best regards,
Marek Vasut


More information about the U-Boot mailing list