From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Harvey Date: Thu, 8 Apr 2021 12:55:11 -0700 Subject: [PATCH 4/6] drivers: net: octeontx: fix QSGMII In-Reply-To: References: <20210326000737.9764-1-tharvey@gateworks.com> <20210326000737.9764-5-tharvey@gateworks.com> <8feacec0-1c17-00a6-b270-c0dce781ad86@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Mar 26, 2021 at 9:39 AM Suneel Garapati wrote: > > + Chandra > > On Fri, Mar 26, 2021 at 9:38 AM Tim Harvey wrote: > > > > On Fri, Mar 26, 2021 at 9:09 AM Suneel Garapati wrote: > > > > > > This looks like a workaround than the root cause fix. > > > As this patch just moves the bringup of link from probe stage to on-demand. > > > > > > On Thu, Mar 25, 2021 at 11:46 PM Stefan Roese wrote: > > > > > > > > On 26.03.21 01:07, Tim Harvey wrote: > > > > > Revert a change that occured between the Marvell SDK-10.1.1.0 > > > > > and SDK-10.3.1.1 which broke QSMII phy support. > > > > > > > > > > Signed-off-by: Tim Harvey > > > > > > > > Thanks. > > > > > > > > Suneel, do you have a comment on this? Is this revert the "best way" to > > > > handle this? > > > > > > > > Thanks, > > > > Stefan > > > > > > > > > --- > > > > > drivers/net/octeontx/bgx.c | 20 +++++++------------- > > > > > 1 file changed, 7 insertions(+), 13 deletions(-) > > > > > > > > > > diff --git a/drivers/net/octeontx/bgx.c b/drivers/net/octeontx/bgx.c > > > > > index 2ea54be84d..a5c0c9fe2b 100644 > > > > > --- a/drivers/net/octeontx/bgx.c > > > > > +++ b/drivers/net/octeontx/bgx.c > > > > > @@ -36,7 +36,6 @@ struct lmac { > > > > > int dmac; > > > > > u8 mac[6]; > > > > > bool link_up; > > > > > - bool init_pend; > > > > > int lmacid; /* ID within BGX */ > > > > > int phy_addr; /* ID on board */ > > > > > struct udevice *dev; > > > > > @@ -849,6 +848,7 @@ static int bgx_lmac_enable(struct bgx *bgx, int8_t lmacid) > > > > > u64 cfg; > > > > > > > > > > lmac = &bgx->lmac[lmacid]; > > > > > + lmac->bgx = bgx; > > > > > > > > > > debug("%s: lmac: %p, lmacid = %d\n", __func__, lmac, lmacid); > > > > > > > > > > @@ -895,16 +895,6 @@ int bgx_poll_for_link(int node, int bgx_idx, int lmacid) > > > > > debug("%s: %d, lmac: %d/%d/%d %p\n", > > > > > __FILE__, __LINE__, > > > > > node, bgx_idx, lmacid, lmac); > > > > > - if (lmac->init_pend) { > > > > > - ret = bgx_lmac_enable(lmac->bgx, lmacid); > > > > > - if (ret < 0) { > > > > > - printf("BGX%d LMAC%d lmac_enable failed\n", bgx_idx, > > > > > - lmacid); > > > > > - return ret; > > > > > - } > > > > > - lmac->init_pend = 0; > > > > > - mdelay(100); > > > > > - } > > > > > if (lmac->qlm_mode == QLM_MODE_SGMII || > > > > > lmac->qlm_mode == QLM_MODE_RGMII || > > > > > lmac->qlm_mode == QLM_MODE_QSGMII) { > > > > > @@ -1461,6 +1451,7 @@ int octeontx_bgx_remove(struct udevice *dev) > > > > > > > > > > int octeontx_bgx_probe(struct udevice *dev) > > > > > { > > > > > + int err; > > > > > struct bgx *bgx = dev_get_priv(dev); > > > > > u8 lmac = 0; > > > > > int qlm[4] = {-1, -1, -1, -1}; > > > > > @@ -1540,8 +1531,11 @@ skip_qlm_config: > > > > > struct lmac *tlmac = &bgx->lmac[lmac]; > > > > > > > > > > tlmac->dev = dev; > > > > > - tlmac->init_pend = 1; > > > > > - tlmac->bgx = bgx; > > > > > + err = bgx_lmac_enable(bgx, lmac); > > > > > + if (err) { > > > > > + printf("BGX%d failed to enable lmac%d\n", > > > > > + bgx->bgx_id, lmac); > > > > > + } > > > > > } > > > > > > > > > > return 0; > > > > > > > > > > > > > Suneel, > > > > I agree, it is a workaround and I don't quite understand the reason. > > > > Can you look into the code history of the SDK BDK and see what the > > reason was for introducing this 'pending' state that defers the > > bgx_lmac_enable call that breaks QSGMII? That specific change was made > > between SDK-10.1.1.0 and SDK-10.3.1.1. > > > > What boards and PHY's have you tested octeontx BGX with? > > > > I have the following boards to test with that we designed and support: > > - GW630x: supports both RGMII and SGMII GbE PHY's > > - GW640x: supports both RGMII and QSGMII GbE PHy's > > > > The only issue I have that is worked around by the above is QSGMII. > > Sunell / Chandrakala, Any comments here about what PHY's you have tested octeontx BGX with and what the reasoning was for the code change here between Marvell SDK-10.1.1.0 and SDK-10.3.1.1? Tim