[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 21-03-16 18:30, Karsten Merker wrote:
> On Mon, Mar 21, 2016 at 04:47:15PM +0100, Karsten Merker wrote:
>> On Sun, Mar 20, 2016 at 07:51:20PM +0100, Hans de Goede wrote:
>>> On 20-03-16 16:28, Michael Haas wrote:
>>>> On 03/20/2016 02:45 PM, Hans de Goede wrote:
>>>>> On 19-03-16 14:40, Michael Haas wrote:
>
>>>>>> 0xA was set to 7800 for working runs and 3800 for broken runs. The
>>>>>> difference is bit 14 in the GBSR: 'MASTER/SLAVE Configuration
>>>>>> Resolution'. In the broken runs, the autonegotation configured the
>>>>>> OlinuXino to 'slave'. I have whipped up a quick patch which disable the
>>>>>> master/slave part of the autonegotiation and force master mode.
>
>>>>>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>>>>>> index 51b5746..484b2be 100644
>>>>>> --- a/drivers/net/phy/phy.c
>>>>>> +++ b/drivers/net/phy/phy.c
>>>>>> @@ -170,6 +170,7 @@ int genphy_restart_aneg(struct phy_device *phydev)
>>>>>>    int genphy_config_aneg(struct phy_device *phydev)
>>>>>>    {
>>>>>>           int result;
>>>>>> +       phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1A00);
>>>>>>
>>>>>>           if (AUTONEG_ENABLE != phydev->autoneg)
>>>>>>                   return genphy_setup_forced(phydev);
>>>>>>
>
>>>> I was going to add that in realtek.c, not in phy.c - as soon as I figure
>>>> out which section there is applicable.
>
> Unfortunately the issue is now split over two threads - this one and the
> "Which entry in drivers/net/phy/realtek.c matches my device?" thread.
>
> It looks like we have three related but separate issues here:
>
> a) The sunxi config doesn't actually build the phy drivers:
>
>     include/configs/sunxi-common.h contains:
>
>     302 /* Ethernet support */
>     303 #ifdef CONFIG_SUNXI_EMAC
>     304 #define CONFIG_PHY_ADDR         1
>     305 #define CONFIG_MII                      /* MII PHY management           */
>     306 #define CONFIG_PHYLIB
>     307 #endif
>     308
>     309 #ifdef CONFIG_SUNXI_GMAC
>     310 #define CONFIG_PHY_GIGE                 /* GMAC can use gigabit PHY     */
>     311 #define CONFIG_PHY_ADDR         1
>     312 #define CONFIG_MII                      /* MII PHY management           */
>     313 #endif
>
>     For the sunxi EMAC case (which is AFAIK only used on A10/A13)
>     CONFIG_PHYLIB is enabled, but for the CONFIG_SUNXI_GMAC case (all
>     other sunxi-based systems) we don't enable any PHY driver.

We do enable phylib for gmac based systems, we have CONFIG_ETH_DESIGNWARE=y
in defconfigs using GMAC and drivers/net/Kconfig has:

config ETH_DESIGNWARE
         bool "Synopsys Designware Ethernet MAC"
         select PHYLIB

We do however only enable the generic (vendor neutral phy) phylib support
and not any vendor specific drivers, I've a commit in my tree enabling
realtek phy support.

https://github.com/jwrdegoede/u-boot-sunxi/commit/8121866aa55b010d31fe75c1eb5d2372c1e27a62

So it looks like a) is already covered :)

>     So we
>     either need to enable CONFIG_PHYLIB for CONFIG_SUNXI_GMAC as well
>     or enable the relevant PHY drivers (do we actually have anything
>     besides realtek on sunxi-based systems?) separately, i.e.
>     something like
>
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index b26363d..ea15e37 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -310,6 +310,7 @@ extern int soft_i2c_gpio_scl;
>   #define CONFIG_PHY_GIGE			/* GMAC can use gigabit PHY	*/
>   #define CONFIG_PHY_ADDR		1
>   #define CONFIG_MII			/* MII PHY management		*/
> +#define CONFIG_PHY_REALTEK
>   #endif
>
>   #ifdef CONFIG_USB_EHCI_HCD
>
>
> b) The realtek PHY driver (drivers/net/phy/realtek.c) doesn't match
>     on the RTL8211CL PHY ID, so even if it is compiled in, it still
>     doesn't work. For more details on this issue, see the "Which entry
>     in drivers/net/phy/realtek.c matches my device?" thread.
>
>
> c) The master/slave mode problem that can be worked around by forcing
>     master mode on the RTL8211CL.

Regards,

Hans