eth0: link down

[mtx512]

On the Hackberry after kernel 3.0.36+ wemac fails to initialise on every subsequent kernel version and reports the following:

[ 15.020000] wemac wemac.0: WARNING: no IRQ resource flags set.

[ 15.130000] wemac wemac.0: eth0: link down

[ 15.130000] ADDRCONF(NETDEV_UP): eth0: link is not ready

For more background you can refer to the issue raised on github.

For the Hackberry emac_power is configured to use PH19 unlike the mele which uses PH15. 

     emac_power = port:PH19<1><default><default><0>

  

From what I can determine based on the latests wemac.c (3.0.42+) PH15 (for mele) must some how get enabled by the kernel prior to wemac is initialised because of :

    #define PHY_POWER 0

For Hackberry we require PHY_POWER = 1 so that the gpio line is enabled by the emac_power setting. With this change ethernet gets enabled, however using a armhf kernel the link is reported as 10Mb half duplex:

    Sending on   Socket/fallback

    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6

    <6>ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

    [   16.880000] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

    <6>wemac wemac.0: eth0: link up, 10Mbps, half-duplex, lpa 0x0021

    [   16.920000] wemac wemac.0: eth0: link up, 10Mbps, half-duplex, lpa 0x0021

Interestingly I can get the link to back to 100Mb full duplex using ethtool.

To get 100Mb full duplex reported by the driver the following changes also have to be reverted:

    @@ -1563,7 +1563,8 @@ static int wemac_phy_read(struct net_device *dev, int phyaddr_unused, int reg)

    writel(0x1, db->emac_vbase + EMAC_MAC_MCMD_REG);

    spin_unlock_irqrestore(&db->lock, flags);

 

    -       wemac_msleep(db, 1); /* Wait read complete */

    +       //wemac_msleep(db, 1); /* Wait read complete */

    +        udelay(150); /* 100 */

 

    /* push down the phy io line and read data */

    spin_lock_irqsave(&db->lock, flags);

    @@ -1596,7 +1597,8 @@ static void wemac_phy_write(struct net_device *dev,

    writel(0x1, db->emac_vbase + EMAC_MAC_MCMD_REG);

    spin_unlock_irqrestore(&db->lock, flags);

    -       wemac_msleep(db, 1);            /* Wait write complete */

    +       // wemac_msleep(db, 1);         /* Wait write complete */

    +        udelay(150); /* 100 */

 

    spin_lock_irqsave(&db->lock, flags);

    /* push down the phy io line */

I tried changing msleep() to  msleep_interruptible() thinking that interrupts weren't ocurring during msleep but that has no effect.

Even though the wemac is reporting a 100Mb actual speeds is a poor 5-6Mb.

 

[Alejandro Mery]

On 04/11/12 19:21, mtx512 wrote:
> On the Hackberry after kernel 3.0.36+ wemac fails to initialise on every
> subsequent kernel version and reports the following:
>
> [ 15.020000] wemac wemac.0: WARNING: no IRQ resource flags set.
> [ 15.130000] wemac wemac.0: eth0: link down
> [ 15.130000] ADDRCONF(NETDEV_UP): eth0: link is not ready
>

> For more background you can refer to the issue<https://github.com/linux-sunxi/linux-sunxi/issues/91>raised on github.

>
> For the Hackberry emac_power is configured to use PH19 unlike the mele
> which uses PH15.
>
> emac_power = port:PH19<1><default><default><0>
>
> From what I can determine based on the latests wemac.c (3.0.42+) PH15 (for
> mele) must some how get enabled by the kernel prior to wemac is initialised
> because of :
>
> #define PHY_POWER 0
>
> For Hackberry we require PHY_POWER = 1 so that the gpio line is enabled by
> the emac_power setting.

I suppose we should get rid of that define and base the related logic in
the existence (or not) of the emac_power GPIO in script.bin

Alejandro

[mtx512]

Yes, could read emac_power once from the script.bin and keep it in a variable for further checks.

We also need to bring back udelay instead of using msleep, unless there is a better way of doing this. What I'm unclear about is how udelay/msleep works if the CPU is frequency scaling?

Has anyone looked at the half commented out DMA code?

[Dmitriy B.]

Before DMA we need to figure out all registers and place info at http://linux-sunxi.org/A10/registers

2012/11/4 mtx512 <mtx5...@gmail.com>

--
 
 

[Oliver Schinagl]

What registers are you ref. too? E,g. What section should i work on after clocking section. I think some irq things are covered in the timrts section, but doubt that will be helpful.

--
Sent from my Android tablet with K-9 Mail. Please excuse my brevity.

[Henrik Nordström]

Working out the wemac register usage

[Siarhei Siamashka]

> On Sunday, November 4, 2012 8:21:04 PM UTC+2, mtx512 wrote:
> >
> > On the Hackberry after kernel 3.0.36+ wemac fails to initialise on every
> > subsequent kernel version and reports the following:
> >
> > [ 15.020000] wemac wemac.0: WARNING: no IRQ resource flags set.
> > [ 15.130000] wemac wemac.0: eth0: link down
> > [ 15.130000] ADDRCONF(NETDEV_UP): eth0: link is not ready
> >
> > For more background you can refer to the issue

> > https://github.com/linux-sunxi/linux-sunxi/issues/91 raised on github.

I can confirm the slow 10Mbps ethernet performance on my Mele A2000
with the current sunxi-3.0 kernel. That's particularly bad in my
case because I'm using nfs root.

The udelay fix/workaround recovers performance to 100Mbps level. Is
there any chance to have it applied at github? Or maybe resolve the
issue in some other way?

--
Best regards,
Siarhei Siamashka

[Dmitriy B.]

I have 10mbps too, thought that was my router or cables issue, but I've checked with other one and I have same 10mbps.

2012/11/19 Siarhei Siamashka <siarhei....@gmail.com>

--