[U-Boot] [u-boot] AR8033 SerDes Test and System Mode Control setting issue

[Ken.Lin <ken.lin@advantech.com>]

> -----Original Message-----
> From: Sekhar Nori [mailto:nsekhar at ti.com]
> Sent: Tuesday, January 17, 2017 3:23 AM
> To: Ken.Lin; joe.hershberger at ni.com
> Cc: Peter.Stretz; mugunthanvnm at ti.com; Peter.Chiang; Chiming.Lee; u-
> boot at lists.denx.de; albert.u.uboot at aribaud.net; wd at denx.de
> Subject: Re: [u-boot] AR8033 SerDes Test and System Mode Control setting issue
> 
> Hi Ken Lin,
> 
> On Tuesday 17 January 2017 03:44 AM, Ken.Lin wrote:
> > Hi Joe and Mugunthan,
> >
> > We encountered the voltage peak issue while doing the IEEE PHY conformance
> test, which has to do with the AR8033 register (SetDes Test and System Mode
> Control) setting in u-boot.
> > In your commit change info, you tried to enable tx clock delay by setting bit 8
> to 1 (filling in 0x100, setting the reserved bits to 0) for solving the auto
> negotiation failure issue.
> > https://patchwork.ozlabs.org/patch/681801/
> >
> > After we checked with Qualcomm (Atheros) and they responded that on their
> platform, the register should be set to 0x2C47 (for the reserved bits) and this
> would solve the voltage peak issue we experienced.
> > Could you please help check if it's appropriate to set the reserved bits
> according to Qualcomm's setting since your commit breaks the original setting
> (see https://community.nxp.com/message/868898 for more details info)?
> > Please let me know if you have any suggestions/comments on this.
> 
> I guess the right thing to do would be to readback this registers, modify only bit
> 8 and write the value back.
> 
> Is that something you can try? You can check that the value you read back for
> the reserved bits is indeed what Qualcomm recommends you to set.
> 

I added some code statements following your source to read back the register setting then to apply the reserved bit settings used in the NXP u-boot codebase.
If you have no objections on this fix (the register turned out to set be 0x3D47 and it passed the PHY conformance test), I'll submit it as a RFC patch. 

@@ -28,6 +28,8 @@ static int ar8021_config(struct phy_device *phydev)

 static int ar8031_config(struct phy_device *phydev)
 {
+       int regval;
+
        if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
            phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
                phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG,
@@ -44,6 +46,10 @@ static int ar8031_config(struct phy_device *phydev)
                          AR803x_RGMII_RX_CLK_DLY);
        }

+        phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG, AR803x_DEBUG_REG_5);
+        regval = phy_read(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG);
+        phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG, regval | 0x3C47);
+
        phydev->supported = phydev->drv->features;

        genphy_config_aneg(phydev);


Thanks,
Ken Lin


> Thanks,
> Sekhar
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drivers-net-phy-atheros-apply-the-previous-register-.patch
Type: application/octet-stream
Size: 1448 bytes
Desc: 0001-drivers-net-phy-atheros-apply-the-previous-register-.patch
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170131/066cfac9/attachment.obj>