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

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

[Ken.Lin]

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.

Thank you

Cheers,
Ken Lin


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

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

[Sekhar Nori]

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.

Thanks,
Sekhar

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

[Ken.Lin]

> -----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>