[U-Boot] net: designware: set the PS bit when resetting DMA bus in MII configuration

On the SPEAr600 SoC, which has the dwmac1000 variant of the IP block,
the DMA reset never succeeds when a MII PHY is used (no problem with a
GMII PHY). The designware_eth_init() function sets the
DMAMAC_SRST bit in the DMA_BUS_MODE register, and then
polls until this bit clears. When a MII PHY is used, with the current
driver, this bit never clears and the driver therefore doesn't work.

The reason is that the PS bit of the GMAC_CONTROL register should be
correctly configured for the DMA reset to work. When the PS bit is 0,
it tells the MAC we have a GMII PHY, when the PS bit is 1, it tells
the MAC we have a MII PHY.

Doing a DMA reset clears all registers, so the PS bit is cleared as
well. This makes the DMA reset work fine with a GMII PHY. However,
with MII PHY, the PS bit should be set.

We have identified this issue thanks to two SPEAr600 platform:

- One equipped with a GMII PHY, with which the existing driver was
working fine.

- One equipped with a MII PHY, where the current driver fails because
the DMA reset times out.

Note: Taken from https://www.spinics.net/lists/netdev/msg432578.html

Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
---

Note, it looks like dw_adjust_link[1] already tries to handle this.
However, the condition is the speed of the link (if not 1Gbps set
the bit), not the mode of communication between the MAC and the PHY.
We could definitely have a 100Mbps with e.g. a GMII mode, and thus we
should not clear the MII_PORTSELECT bit.

Do you agree with regards to the commit log above?

[1] https://elixir.bootlin.com/u-boot/latest/source/drivers/net/designware.c#L243

 drivers/net/designware.c |  9 +++++++++
 1 file changed, 9 insertions(+)


base-commit: b5351a439088dfffd83bfaac81f604344ee2e3bd

On Mon, Jun 4, 2018 at 5:17 AM, Quentin Schulz
<quentin.schulz@bootlin.com> wrote:
> On the SPEAr600 SoC, which has the dwmac1000 variant of the IP block,
> the DMA reset never succeeds when a MII PHY is used (no problem with a
> GMII PHY). The designware_eth_init() function sets the
> DMAMAC_SRST bit in the DMA_BUS_MODE register, and then
> polls until this bit clears. When a MII PHY is used, with the current
> driver, this bit never clears and the driver therefore doesn't work.
>
> The reason is that the PS bit of the GMAC_CONTROL register should be
> correctly configured for the DMA reset to work. When the PS bit is 0,
> it tells the MAC we have a GMII PHY, when the PS bit is 1, it tells
> the MAC we have a MII PHY.
>
> Doing a DMA reset clears all registers, so the PS bit is cleared as
> well. This makes the DMA reset work fine with a GMII PHY. However,
> with MII PHY, the PS bit should be set.
>
> We have identified this issue thanks to two SPEAr600 platform:
>
> - One equipped with a GMII PHY, with which the existing driver was
> working fine.
>
> - One equipped with a MII PHY, where the current driver fails because
> the DMA reset times out.
>
> Note: Taken from https://www.spinics.net/lists/netdev/msg432578.html
>
> Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> ---
>
> Note, it looks like dw_adjust_link[1] already tries to handle this.
> However, the condition is the speed of the link (if not 1Gbps set
> the bit), not the mode of communication between the MAC and the PHY.
> We could definitely have a 100Mbps with e.g. a GMII mode, and thus we
> should not clear the MII_PORTSELECT bit.
>
> Do you agree with regards to the commit log above?

Yeah, that seems right.

> [1] https://elixir.bootlin.com/u-boot/latest/source/drivers/net/designware.c#L243
>
>  drivers/net/designware.c |  9 +++++++++
>  1 file changed, 9 insertions(+)
>

Acked-by: Joe Hershberger <joe.hershberger@ni.com>

Hi Quentin,

https://patchwork.ozlabs.org/patch/924934/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git

Thanks!
-Joe