[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200504092034.GS1375924@vkoul-mobl>
Date: Mon, 4 May 2020 14:50:34 +0530
From: Vinod Koul <vkoul@...nel.org>
To: Dilip Kota <eswara.kota@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, kishon@...com,
devicetree@...r.kernel.org, lee.jones@...aro.org, arnd@...db.de,
robh@...nel.org, andriy.shevchenko@...el.com,
cheol.yong.kim@...el.com, chuanhua.lei@...ux.intel.com,
qi-ming.wu@...el.com, yixin.zhu@...el.com
Subject: Re: [PATCH v7 3/3] phy: intel: Add driver support for ComboPhy
On 04-05-20, 16:26, Dilip Kota wrote:
>
> On 5/4/2020 3:29 PM, Vinod Koul wrote:
> > On 30-04-20, 15:15, Dilip Kota wrote:
> >
> > > +enum {
> > > + PHY_0,
> > > + PHY_1,
> > > + PHY_MAX_NUM
> > PHY_MAX_NUM = PHY_1?
> Driver is using it for no. of PHYs/maximum PHY id.
Ok
> > > +static inline void combo_phy_w32_off_mask(void __iomem *base, unsigned int reg,
> > > + u32 mask, u32 val)
> > > +{
> > > + u32 reg_val;
> > > +
> > > + reg_val = readl(base + reg);
> > > + reg_val &= ~mask;
> > > + reg_val |= FIELD_PREP(mask, val);
> > > + writel(reg_val, base + reg);
> > bypassing regmap here... why?
> It is not regmap address, one of the below two addresses are passed to this
> function.
okay, perhaps add a comment somewhere that regmap is not used for this
base?
> struct intel_combo_phy {
> ...
> void __iomem *app_base;
> void __iomem *cr_base;
> ...
> }
> > > +static int intel_cbphy_calibrate(struct phy *phy)
> > > +{
> > > + struct intel_cbphy_iphy *iphy = phy_get_drvdata(phy);
> > > + struct intel_combo_phy *cbphy = iphy->parent;
> > > + void __iomem *cr_base = cbphy->cr_base;
> > > + int val, ret, id;
> > > +
> > > + if (cbphy->phy_mode != PHY_XPCS_MODE)
> > > + return 0;
> > > +
> > > + id = PHY_ID(iphy);
> > > +
> > > + /* trigger auto RX adaptation */
> > > + combo_phy_w32_off_mask(cr_base, CR_ADDR(PCS_XF_ATE_OVRD_IN_2, id),
> > > + ADAPT_REQ_MSK, 3);
> > > + /* Wait RX adaptation to finish */
> > > + ret = readl_poll_timeout(cr_base + CR_ADDR(PCS_XF_RX_ADAPT_ACK, id),
> > > + val, val & RX_ADAPT_ACK_BIT, 10, 5000);
> > > + if (ret)
> > > + dev_err(cbphy->dev, "RX Adaptation failed!\n");
> > you want to continue her and not return error?
>
> Next step is stopping the Adaptation, it should be done in both error and
> success case.
Again documenting this helps, pls add some comments on this behaviour
--
~Vinod
Powered by blists - more mailing lists