Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Alim Akhtar" <alim.akhtar@samsung.com>
To:     "'Avri Altman'" <Avri.Altman@wdc.com>, <robh+dt@kernel.org>,
        <devicetree@vger.kernel.org>, <linux-scsi@vger.kernel.org>
Cc:     <krzk@kernel.org>, <martin.petersen@oracle.com>,
        <kwmad.kim@samsung.com>, <stanley.chu@mediatek.com>,
        <cang@codeaurora.org>, <linux-samsung-soc@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>
In-Reply-To: <SN6PR04MB4640B92BC9EA5CFEB74BE5EAFCCD0@SN6PR04MB4640.namprd04.prod.outlook.com>
Subject: RE: [PATCH v4 4/5] scsi: ufs-exynos: add UFS host support for
 Exynos SoCs
Date:   Thu, 2 Apr 2020 20:38:15 +0530
Message-ID: <000001d60900$8b6f5e70$a24e1b50$@samsung.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKI+vJzlUBp7WIi19k8pRZBKIHK2gGl+w7dArc8+ogCfXKHn6bJNFzg
Content-Language: en-in
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 105P
References: <20200327170638.17670-1-alim.akhtar@samsung.com>
        <CGME20200327171420epcas5p490e1e6d090a540eaf050e0728a39ba25@epcas5p4.samsung.com>
        <20200327170638.17670-5-alim.akhtar@samsung.com>
        <SN6PR04MB4640B92BC9EA5CFEB74BE5EAFCCD0@SN6PR04MB4640.namprd04.prod.outlook.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Avri

> -----Original Message-----
> From: Avri Altman <Avri.Altman=40wdc.com>
> Sent: 28 March 2020 16:58
> To: Alim Akhtar <alim.akhtar=40samsung.com>; robh+dt=40kernel.org;
> devicetree=40vger.kernel.org; linux-scsi=40vger.kernel.org
> Cc: krzk=40kernel.org; martin.petersen=40oracle.com; kwmad.kim=40samsung.=
com;
> stanley.chu=40mediatek.com; cang=40codeaurora.org; linux-samsung-
> soc=40vger.kernel.org; linux-arm-kernel=40lists.infradead.org; linux-
> kernel=40vger.kernel.org
> Subject: RE: =5BPATCH v4 4/5=5D scsi: ufs-exynos: add UFS host support fo=
r Exynos
> SoCs
>=20
> Hi,
>=20
> > +
> > +long exynos_ufs_calc_time_cntr(struct exynos_ufs *ufs, long period) =
=7B
> > +       const int precise =3D 10;
> > +       long pclk_rate =3D ufs->pclk_rate;
> > +       long clk_period, fraction;
> > +
> > +       clk_period =3D UNIPRO_PCLK_PERIOD(ufs);
> > +       fraction =3D ((NSEC_PER_SEC % pclk_rate) * precise) / pclk_rate=
;
> > +
> > +       return (period * precise) / ((clk_period * precise) +
> > +fraction); =7D
> This helper essentially calculates a factor f, and returns period x f.
> Why not do that regardless of period?
>=20
The period can be different for different timing attributes, so this helper=
 function takes the period and returns the timer counter value based on the=
 pclk_rate.=20

> > +extern long exynos_ufs_calc_time_cntr(struct exynos_ufs *, long);
> Why this factor needed to be exported?
Yes, not needed, will correct this in next version, which I am planning to =
post soon.
Thanks for your time and review, let me know if you have more inputs.