| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20230713052052.GD3047@thinkpad>
Date: Thu, 13 Jul 2023 10:50:52 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: vireshk@...nel.org, nm@...com, sboyd@...nel.org,
myungjoo.ham@...sung.com, kyungmin.park@...sung.com,
cw00.choi@...sung.com, andersson@...nel.org,
konrad.dybcio@...aro.org, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
quic_asutoshd@...cinc.com, quic_cang@...cinc.com,
quic_nitirawa@...cinc.com, quic_narepall@...cinc.com,
quic_bhaskarv@...cinc.com, quic_richardp@...cinc.com,
quic_nguyenb@...cinc.com, quic_ziqichen@...cinc.com,
bmasney@...hat.com, krzysztof.kozlowski@...aro.org
Subject: Re: [PATCH 14/14] scsi: ufs: qcom: Add support for scaling
interconnects
On Wed, Jul 12, 2023 at 08:23:02PM +0300, Dmitry Baryshkov wrote:
> On 12/07/2023 19:41, Manivannan Sadhasivam wrote:
> > On Wed, Jul 12, 2023 at 04:22:51PM +0300, Dmitry Baryshkov wrote:
> > > On 12/07/2023 13:32, Manivannan Sadhasivam wrote:
> > > > Qcom SoCs require scaling the interconnect paths for proper working of the
> > > > peripherals connected through interconnects. Even for accessing the UFS
> > > > controller, someone should setup the interconnect paths. So far, the
> > > > bootloaders used to setup the interconnect paths before booting linux as
> > > > they need to access the UFS storage for things like fetching boot firmware.
> > > > But with the advent of multi boot options, bootloader nowadays like in
> > > > SA8540p SoC do not setup the interconnect paths at all.
> > > >
> > > > So trying to configure UFS in the absence of the interconnect path
> > > > configuration, results in boot crash.
> > > >
> > > > To fix this issue and also to dynamically scale the interconnects (UFS-DDR
> > > > and CPU-UFS), interconnect API support is added to the Qcom UFS driver.
> > > > With this support, the interconnect paths are scaled dynamically based on
> > > > the gear configuration.
> > > >
> > > > During the early stage of ufs_qcom_init(), ufs_qcom_icc_init() will setup
> > > > the paths to max bandwidth to allow configuring the UFS registers. Touching
> > > > the registers without configuring the icc paths would result in a crash.
> > > > However, we don't really need to set max vote for the icc paths as any
> > > > minimal vote would suffice. But the max value would allow initialization to
> > > > be done faster. After init, the bandwidth will get updated using
> > > > ufs_qcom_icc_update_bw() based on the gear and lane configuration.
> > > >
> > > > The bandwidth values defined in ufs_qcom_bw_table struct are taken from
> > > > Qcom downstream vendor devicetree source and are calculated as per the
> > > > UFS3.1 Spec, Section 6.4.1, HS Gear Rates. So it is fixed across platforms.
> > > >
> > > > Cc: Brian Masney <bmasney@...hat.com>
> > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> > > > ---
> > > > drivers/ufs/host/ufs-qcom.c | 131 +++++++++++++++++++++++++++++++++++-
> > > > drivers/ufs/host/ufs-qcom.h | 3 +
> > > > 2 files changed, 133 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> > > > index 8d6fd4c3324f..8a3132d45a65 100644
> > > > --- a/drivers/ufs/host/ufs-qcom.c
> > > > +++ b/drivers/ufs/host/ufs-qcom.c
> > > > @@ -7,6 +7,7 @@
> > > > #include <linux/time.h>
> > > > #include <linux/clk.h>
> > > > #include <linux/delay.h>
> > > > +#include <linux/interconnect.h>
> > > > #include <linux/module.h>
> > > > #include <linux/of.h>
> > > > #include <linux/platform_device.h>
> > > > @@ -46,6 +47,49 @@ enum {
> > > > TSTBUS_MAX,
> > > > };
> >
[...]
> > > };
> > >
> > > Also, do we have defines for gears? Can we use them instead of indices?
> > >
> >
> > There are defines for the gears but not for lanes. So I ended up using numbers
> > for simplicity.
>
> My suggestion would be to use them for gears at least. Then it becomes
> cleaner (and maybe will solve some of my other comments).
>
I think it'd better to add enums for lanes as well (in unipro.h) and use both.
> >
> > - Mani
> >
> > > > + [MODE_PWM][1][1] = { 922, 1000 },
> > > > + [MODE_PWM][2][1] = { 1844, 1000 },
> > > > + [MODE_PWM][3][1] = { 3688, 1000 },
> > > > + [MODE_PWM][4][1] = { 7376, 1000 },
> > > > + [MODE_PWM][1][2] = { 1844, 1000 },
> > > > + [MODE_PWM][2][2] = { 3688, 1000 },
> > > > + [MODE_PWM][3][2] = { 7376, 1000 },
> > > > + [MODE_PWM][4][2] = { 14752, 1000 },
> > > > + [MODE_HS_RA][1][1] = { 127796, 1000 },
> > > > + [MODE_HS_RA][2][1] = { 255591, 1000 },
> > > > + [MODE_HS_RA][3][1] = { 1492582, 102400 },
> > > > + [MODE_HS_RA][4][1] = { 2915200, 204800 },
> > > > + [MODE_HS_RA][1][2] = { 255591, 1000 },
> > > > + [MODE_HS_RA][2][2] = { 511181, 1000 },
> > > > + [MODE_HS_RA][3][2] = { 1492582, 204800 },
> > > > + [MODE_HS_RA][4][2] = { 2915200, 409600 },
> > > > + [MODE_HS_RB][1][1] = { 149422, 1000 },
> > > > + [MODE_HS_RB][2][1] = { 298189, 1000 },
> > > > + [MODE_HS_RB][3][1] = { 1492582, 102400 },
> > > > + [MODE_HS_RB][4][1] = { 2915200, 204800 },
> > > > + [MODE_HS_RB][1][2] = { 298189, 1000 },
> > > > + [MODE_HS_RB][2][2] = { 596378, 1000 },
> > > > + [MODE_HS_RB][3][2] = { 1492582, 204800 },
> > > > + [MODE_HS_RB][4][2] = { 2915200, 409600 },
> > > > + [MODE_MAX][0][0] = { 7643136, 307200 },
> > > > +};
> > > > +
[...]
> > > > +static int ufs_qcom_icc_update_bw(struct ufs_qcom_host *host)
> > > > +{
> > > > + struct __ufs_qcom_bw_table bw_table;
> > > > +
> > > > + bw_table = ufs_qcom_get_bw_table(host);
> > > > +
> > > > + return ufs_qcom_icc_set_bw(host, bw_table.bw1, bw_table.bw2);
> > > > +}
> > > > +
> > > > static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
> > > > enum ufs_notify_change_status status,
> > > > struct ufs_pa_layer_attr *dev_max_params,
> > > > @@ -852,6 +941,8 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
> > > > memcpy(&host->dev_req_params,
> > > > dev_req_params, sizeof(*dev_req_params));
> > > > + ufs_qcom_icc_update_bw(host);
> > > > +
> > > > /* disable the device ref clock if entered PWM mode */
> > > > if (ufshcd_is_hs_mode(&hba->pwr_info) &&
> > > > !ufshcd_is_hs_mode(dev_req_params))
> > > > @@ -981,7 +1072,9 @@ static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
> > > > switch (status) {
> > > > case PRE_CHANGE:
> > > > - if (!on) {
> > > > + if (on) {
> > > > + ufs_qcom_icc_update_bw(host);
> > > > + } else {
> > > > if (!ufs_qcom_is_link_active(hba)) {
> > > > /* disable device ref_clk */
> > > > ufs_qcom_dev_ref_clk_ctrl(host, false);
> > > > @@ -993,6 +1086,9 @@ static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
> > > > /* enable the device ref clock for HS mode*/
> > > > if (ufshcd_is_hs_mode(&hba->pwr_info))
> > > > ufs_qcom_dev_ref_clk_ctrl(host, true);
> > > > + } else {
> > > > + ufs_qcom_icc_set_bw(host, ufs_qcom_bw_table[MODE_MIN][0][0].bw1,
> > > > + ufs_qcom_bw_table[MODE_MIN][0][0].bw2);
>
> With MODE_MIN values being initialised to 0, can we use the value directly
> instead? You are not defining the whole table for MODE_MIN anyway.
>
I initially thought about it, but having all the values in the table gives
better visibility IMO. Otherwise, one has to look into the actual call to
determine what is being set for min and max.
- Mani
--
மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists