[PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Can Guo]

Add reset control for host controller so that host controller can be reset
as required in its power up sequence.

Signed-off-by: Can Guo <cang@codeaurora.org>
---
 drivers/scsi/ufs/ufs-qcom.c | 53 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/scsi/ufs/ufs-qcom.h |  3 +++
 2 files changed, 56 insertions(+)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index a5b7148..c69c29a1c 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -246,6 +246,44 @@ static void ufs_qcom_select_unipro_mode(struct ufs_qcom_host *host)
 	mb();
 }
 
+/**
+ * ufs_qcom_host_reset - reset host controller and PHY
+ */
+static int ufs_qcom_host_reset(struct ufs_hba *hba)
+{
+	int ret = 0;
+	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
+
+	if (!host->core_reset) {
+		dev_warn(hba->dev, "%s: reset control not set\n", __func__);
+		goto out;
+	}
+
+	ret = reset_control_assert(host->core_reset);
+	if (ret) {
+		dev_err(hba->dev, "%s: core_reset assert failed, err = %d\n",
+				 __func__, ret);
+		goto out;
+	}
+
+	/*
+	 * The hardware requirement for delay between assert/deassert
+	 * is at least 3-4 sleep clock (32.7KHz) cycles, which comes to
+	 * ~125us (4/32768). To be on the safe side add 200us delay.
+	 */
+	usleep_range(200, 210);
+
+	ret = reset_control_deassert(host->core_reset);
+	if (ret)
+		dev_err(hba->dev, "%s: core_reset deassert failed, err = %d\n",
+				 __func__, ret);
+
+	usleep_range(1000, 1100);
+
+out:
+	return ret;
+}
+
 static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
 {
 	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
@@ -254,6 +292,12 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
 	bool is_rate_B = (UFS_QCOM_LIMIT_HS_RATE == PA_HS_MODE_B)
 							? true : false;
 
+	/* Reset UFS Host Controller and PHY */
+	ret = ufs_qcom_host_reset(hba);
+	if (ret)
+		dev_warn(hba->dev, "%s: host reset returned %d\n",
+				  __func__, ret);
+
 	if (is_rate_B)
 		phy_set_mode(phy, PHY_MODE_UFS_HS_B);
 
@@ -1101,6 +1145,15 @@ static int ufs_qcom_init(struct ufs_hba *hba)
 	host->hba = hba;
 	ufshcd_set_variant(hba, host);
 
+	/* Setup the reset control of HCI */
+	host->core_reset = devm_reset_control_get(hba->dev, "rst");
+	if (IS_ERR(host->core_reset)) {
+		err = PTR_ERR(host->core_reset);
+		dev_warn(dev, "Failed to get reset control %d\n", err);
+		host->core_reset = NULL;
+		err = 0;
+	}
+
 	/* Fire up the reset controller. Failure here is non-fatal. */
 	host->rcdev.of_node = dev->of_node;
 	host->rcdev.ops = &ufs_qcom_reset_ops;
diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
index d401f17..2d95e7c 100644
--- a/drivers/scsi/ufs/ufs-qcom.h
+++ b/drivers/scsi/ufs/ufs-qcom.h
@@ -6,6 +6,7 @@
 #define UFS_QCOM_H_
 
 #include <linux/reset-controller.h>
+#include <linux/reset.h>
 
 #define MAX_UFS_QCOM_HOSTS	1
 #define MAX_U32                 (~(u32)0)
@@ -233,6 +234,8 @@ struct ufs_qcom_host {
 	u32 dbg_print_en;
 	struct ufs_qcom_testbus testbus;
 
+	/* Reset control of HCI */
+	struct reset_control *core_reset;
 	struct reset_controller_dev rcdev;
 
 	struct gpio_desc *device_reset;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

RE: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Avri Altman]

> 
> Add reset control for host controller so that host controller can be reset as
> required in its power up sequence.
> 
> Signed-off-by: Can Guo <cang@codeaurora.org>
Reviewed-by: Avri Altman <avri.altman@wdc.com>

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Vinod Koul]

Hi Can,

On 14-11-19, 22:09, Can Guo wrote:
> Add reset control for host controller so that host controller can be reset
> as required in its power up sequence.

I am seeing a regression on UFS on SM8150-mtp with this patch. I think
Jeff is seeing same one lenove laptop on 8998.

845 does not seem to have this issue and only thing I can see is that on
sm8150 and 8998 we define reset as:

                        resets = <&gcc GCC_UFS_BCR>;
                        reset-names = "rst";

Thanks

> 
> Signed-off-by: Can Guo <cang@codeaurora.org>
> ---
>  drivers/scsi/ufs/ufs-qcom.c | 53 +++++++++++++++++++++++++++++++++++++++++++++
>  drivers/scsi/ufs/ufs-qcom.h |  3 +++
>  2 files changed, 56 insertions(+)
> 
> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> index a5b7148..c69c29a1c 100644
> --- a/drivers/scsi/ufs/ufs-qcom.c
> +++ b/drivers/scsi/ufs/ufs-qcom.c
> @@ -246,6 +246,44 @@ static void ufs_qcom_select_unipro_mode(struct ufs_qcom_host *host)
>  	mb();
>  }
>  
> +/**
> + * ufs_qcom_host_reset - reset host controller and PHY
> + */
> +static int ufs_qcom_host_reset(struct ufs_hba *hba)
> +{
> +	int ret = 0;
> +	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> +
> +	if (!host->core_reset) {
> +		dev_warn(hba->dev, "%s: reset control not set\n", __func__);
> +		goto out;
> +	}
> +
> +	ret = reset_control_assert(host->core_reset);
> +	if (ret) {
> +		dev_err(hba->dev, "%s: core_reset assert failed, err = %d\n",
> +				 __func__, ret);
> +		goto out;
> +	}
> +
> +	/*
> +	 * The hardware requirement for delay between assert/deassert
> +	 * is at least 3-4 sleep clock (32.7KHz) cycles, which comes to
> +	 * ~125us (4/32768). To be on the safe side add 200us delay.
> +	 */
> +	usleep_range(200, 210);
> +
> +	ret = reset_control_deassert(host->core_reset);
> +	if (ret)
> +		dev_err(hba->dev, "%s: core_reset deassert failed, err = %d\n",
> +				 __func__, ret);
> +
> +	usleep_range(1000, 1100);
> +
> +out:
> +	return ret;
> +}
> +
>  static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>  {
>  	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> @@ -254,6 +292,12 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>  	bool is_rate_B = (UFS_QCOM_LIMIT_HS_RATE == PA_HS_MODE_B)
>  							? true : false;
>  
> +	/* Reset UFS Host Controller and PHY */
> +	ret = ufs_qcom_host_reset(hba);
> +	if (ret)
> +		dev_warn(hba->dev, "%s: host reset returned %d\n",
> +				  __func__, ret);
> +
>  	if (is_rate_B)
>  		phy_set_mode(phy, PHY_MODE_UFS_HS_B);
>  
> @@ -1101,6 +1145,15 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>  	host->hba = hba;
>  	ufshcd_set_variant(hba, host);
>  
> +	/* Setup the reset control of HCI */
> +	host->core_reset = devm_reset_control_get(hba->dev, "rst");
> +	if (IS_ERR(host->core_reset)) {
> +		err = PTR_ERR(host->core_reset);
> +		dev_warn(dev, "Failed to get reset control %d\n", err);
> +		host->core_reset = NULL;
> +		err = 0;
> +	}
> +
>  	/* Fire up the reset controller. Failure here is non-fatal. */
>  	host->rcdev.of_node = dev->of_node;
>  	host->rcdev.ops = &ufs_qcom_reset_ops;
> diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
> index d401f17..2d95e7c 100644
> --- a/drivers/scsi/ufs/ufs-qcom.h
> +++ b/drivers/scsi/ufs/ufs-qcom.h
> @@ -6,6 +6,7 @@
>  #define UFS_QCOM_H_
>  
>  #include <linux/reset-controller.h>
> +#include <linux/reset.h>
>  
>  #define MAX_UFS_QCOM_HOSTS	1
>  #define MAX_U32                 (~(u32)0)
> @@ -233,6 +234,8 @@ struct ufs_qcom_host {
>  	u32 dbg_print_en;
>  	struct ufs_qcom_testbus testbus;
>  
> +	/* Reset control of HCI */
> +	struct reset_control *core_reset;
>  	struct reset_controller_dev rcdev;
>  
>  	struct gpio_desc *device_reset;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project

-- 
~Vinod

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Jeffrey Hugo]

On Mon, Dec 16, 2019 at 12:05 PM Vinod Koul <vkoul@kernel.org> wrote:
>
> Hi Can,
>
> On 14-11-19, 22:09, Can Guo wrote:
> > Add reset control for host controller so that host controller can be reset
> > as required in its power up sequence.
>
> I am seeing a regression on UFS on SM8150-mtp with this patch. I think
> Jeff is seeing same one lenove laptop on 8998.

Confirmed.

>
> 845 does not seem to have this issue and only thing I can see is that on
> sm8150 and 8998 we define reset as:
>
>                         resets = <&gcc GCC_UFS_BCR>;
>                         reset-names = "rst";
>
> Thanks
>
> >
> > Signed-off-by: Can Guo <cang@codeaurora.org>
> > ---
> >  drivers/scsi/ufs/ufs-qcom.c | 53 +++++++++++++++++++++++++++++++++++++++++++++
> >  drivers/scsi/ufs/ufs-qcom.h |  3 +++
> >  2 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> > index a5b7148..c69c29a1c 100644
> > --- a/drivers/scsi/ufs/ufs-qcom.c
> > +++ b/drivers/scsi/ufs/ufs-qcom.c
> > @@ -246,6 +246,44 @@ static void ufs_qcom_select_unipro_mode(struct ufs_qcom_host *host)
> >       mb();
> >  }
> >
> > +/**
> > + * ufs_qcom_host_reset - reset host controller and PHY
> > + */
> > +static int ufs_qcom_host_reset(struct ufs_hba *hba)
> > +{
> > +     int ret = 0;
> > +     struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> > +
> > +     if (!host->core_reset) {
> > +             dev_warn(hba->dev, "%s: reset control not set\n", __func__);
> > +             goto out;
> > +     }
> > +
> > +     ret = reset_control_assert(host->core_reset);
> > +     if (ret) {
> > +             dev_err(hba->dev, "%s: core_reset assert failed, err = %d\n",
> > +                              __func__, ret);
> > +             goto out;
> > +     }
> > +
> > +     /*
> > +      * The hardware requirement for delay between assert/deassert
> > +      * is at least 3-4 sleep clock (32.7KHz) cycles, which comes to
> > +      * ~125us (4/32768). To be on the safe side add 200us delay.
> > +      */
> > +     usleep_range(200, 210);
> > +
> > +     ret = reset_control_deassert(host->core_reset);
> > +     if (ret)
> > +             dev_err(hba->dev, "%s: core_reset deassert failed, err = %d\n",
> > +                              __func__, ret);
> > +
> > +     usleep_range(1000, 1100);
> > +
> > +out:
> > +     return ret;
> > +}
> > +
> >  static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
> >  {
> >       struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> > @@ -254,6 +292,12 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
> >       bool is_rate_B = (UFS_QCOM_LIMIT_HS_RATE == PA_HS_MODE_B)
> >                                                       ? true : false;
> >
> > +     /* Reset UFS Host Controller and PHY */
> > +     ret = ufs_qcom_host_reset(hba);
> > +     if (ret)
> > +             dev_warn(hba->dev, "%s: host reset returned %d\n",
> > +                               __func__, ret);
> > +
> >       if (is_rate_B)
> >               phy_set_mode(phy, PHY_MODE_UFS_HS_B);
> >
> > @@ -1101,6 +1145,15 @@ static int ufs_qcom_init(struct ufs_hba *hba)
> >       host->hba = hba;
> >       ufshcd_set_variant(hba, host);
> >
> > +     /* Setup the reset control of HCI */
> > +     host->core_reset = devm_reset_control_get(hba->dev, "rst");
> > +     if (IS_ERR(host->core_reset)) {
> > +             err = PTR_ERR(host->core_reset);
> > +             dev_warn(dev, "Failed to get reset control %d\n", err);
> > +             host->core_reset = NULL;
> > +             err = 0;
> > +     }
> > +
> >       /* Fire up the reset controller. Failure here is non-fatal. */
> >       host->rcdev.of_node = dev->of_node;
> >       host->rcdev.ops = &ufs_qcom_reset_ops;
> > diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
> > index d401f17..2d95e7c 100644
> > --- a/drivers/scsi/ufs/ufs-qcom.h
> > +++ b/drivers/scsi/ufs/ufs-qcom.h
> > @@ -6,6 +6,7 @@
> >  #define UFS_QCOM_H_
> >
> >  #include <linux/reset-controller.h>
> > +#include <linux/reset.h>
> >
> >  #define MAX_UFS_QCOM_HOSTS   1
> >  #define MAX_U32                 (~(u32)0)
> > @@ -233,6 +234,8 @@ struct ufs_qcom_host {
> >       u32 dbg_print_en;
> >       struct ufs_qcom_testbus testbus;
> >
> > +     /* Reset control of HCI */
> > +     struct reset_control *core_reset;
> >       struct reset_controller_dev rcdev;
> >
> >       struct gpio_desc *device_reset;
> > --
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > a Linux Foundation Collaborative Project
>
> --
> ~Vinod

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[cang]

On 2019-12-17 03:12, Jeffrey Hugo wrote:
> On Mon, Dec 16, 2019 at 12:05 PM Vinod Koul <vkoul@kernel.org> wrote:
>> 
>> Hi Can,
>> 
>> On 14-11-19, 22:09, Can Guo wrote:
>> > Add reset control for host controller so that host controller can be reset
>> > as required in its power up sequence.
>> 
>> I am seeing a regression on UFS on SM8150-mtp with this patch. I think
>> Jeff is seeing same one lenove laptop on 8998.
> 
> Confirmed.
> 
>> 
>> 845 does not seem to have this issue and only thing I can see is that 
>> on
>> sm8150 and 8998 we define reset as:
>> 
>>                         resets = <&gcc GCC_UFS_BCR>;
>>                         reset-names = "rst";
>> 
>> Thanks
>> 
>> >
>> > Signed-off-by: Can Guo <cang@codeaurora.org>
>> > ---
>> >  drivers/scsi/ufs/ufs-qcom.c | 53 +++++++++++++++++++++++++++++++++++++++++++++
>> >  drivers/scsi/ufs/ufs-qcom.h |  3 +++
>> >  2 files changed, 56 insertions(+)
>> >
>> > diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
>> > index a5b7148..c69c29a1c 100644
>> > --- a/drivers/scsi/ufs/ufs-qcom.c
>> > +++ b/drivers/scsi/ufs/ufs-qcom.c
>> > @@ -246,6 +246,44 @@ static void ufs_qcom_select_unipro_mode(struct ufs_qcom_host *host)
>> >       mb();
>> >  }
>> >
>> > +/**
>> > + * ufs_qcom_host_reset - reset host controller and PHY
>> > + */
>> > +static int ufs_qcom_host_reset(struct ufs_hba *hba)
>> > +{
>> > +     int ret = 0;
>> > +     struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>> > +
>> > +     if (!host->core_reset) {
>> > +             dev_warn(hba->dev, "%s: reset control not set\n", __func__);
>> > +             goto out;
>> > +     }
>> > +
>> > +     ret = reset_control_assert(host->core_reset);
>> > +     if (ret) {
>> > +             dev_err(hba->dev, "%s: core_reset assert failed, err = %d\n",
>> > +                              __func__, ret);
>> > +             goto out;
>> > +     }
>> > +
>> > +     /*
>> > +      * The hardware requirement for delay between assert/deassert
>> > +      * is at least 3-4 sleep clock (32.7KHz) cycles, which comes to
>> > +      * ~125us (4/32768). To be on the safe side add 200us delay.
>> > +      */
>> > +     usleep_range(200, 210);
>> > +
>> > +     ret = reset_control_deassert(host->core_reset);
>> > +     if (ret)
>> > +             dev_err(hba->dev, "%s: core_reset deassert failed, err = %d\n",
>> > +                              __func__, ret);
>> > +
>> > +     usleep_range(1000, 1100);
>> > +
>> > +out:
>> > +     return ret;
>> > +}
>> > +
>> >  static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>> >  {
>> >       struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>> > @@ -254,6 +292,12 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>> >       bool is_rate_B = (UFS_QCOM_LIMIT_HS_RATE == PA_HS_MODE_B)
>> >                                                       ? true : false;
>> >
>> > +     /* Reset UFS Host Controller and PHY */
>> > +     ret = ufs_qcom_host_reset(hba);
>> > +     if (ret)
>> > +             dev_warn(hba->dev, "%s: host reset returned %d\n",
>> > +                               __func__, ret);
>> > +
>> >       if (is_rate_B)
>> >               phy_set_mode(phy, PHY_MODE_UFS_HS_B);
>> >
>> > @@ -1101,6 +1145,15 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>> >       host->hba = hba;
>> >       ufshcd_set_variant(hba, host);
>> >
>> > +     /* Setup the reset control of HCI */
>> > +     host->core_reset = devm_reset_control_get(hba->dev, "rst");
>> > +     if (IS_ERR(host->core_reset)) {
>> > +             err = PTR_ERR(host->core_reset);
>> > +             dev_warn(dev, "Failed to get reset control %d\n", err);
>> > +             host->core_reset = NULL;
>> > +             err = 0;
>> > +     }
>> > +
>> >       /* Fire up the reset controller. Failure here is non-fatal. */
>> >       host->rcdev.of_node = dev->of_node;
>> >       host->rcdev.ops = &ufs_qcom_reset_ops;
>> > diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
>> > index d401f17..2d95e7c 100644
>> > --- a/drivers/scsi/ufs/ufs-qcom.h
>> > +++ b/drivers/scsi/ufs/ufs-qcom.h
>> > @@ -6,6 +6,7 @@
>> >  #define UFS_QCOM_H_
>> >
>> >  #include <linux/reset-controller.h>
>> > +#include <linux/reset.h>
>> >
>> >  #define MAX_UFS_QCOM_HOSTS   1
>> >  #define MAX_U32                 (~(u32)0)
>> > @@ -233,6 +234,8 @@ struct ufs_qcom_host {
>> >       u32 dbg_print_en;
>> >       struct ufs_qcom_testbus testbus;
>> >
>> > +     /* Reset control of HCI */
>> > +     struct reset_control *core_reset;
>> >       struct reset_controller_dev rcdev;
>> >
>> >       struct gpio_desc *device_reset;
>> > --
>> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> > a Linux Foundation Collaborative Project
>> 
>> --
>> ~Vinod

Hi Jeffrey and Vinod,

Thanks for reporting this. May I know what kind of regression do you see 
on
8150 and 8998?
BTW, do you have reset control for UFS PHY in your DT?
See 71278b058a9f8752e51030e363b7a7306938f64e.

FYI, we use reset control on all of our platforms and it is
a must during our power up sequence.

Thanks,
Can Guo.

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Vinod Koul]

Hi Can,

On 17-12-19, 08:37, cang@codeaurora.org wrote:
> On 2019-12-17 03:12, Jeffrey Hugo wrote:
> > On Mon, Dec 16, 2019 at 12:05 PM Vinod Koul <vkoul@kernel.org> wrote:
> > > 
> > > Hi Can,
> > > 
> > > On 14-11-19, 22:09, Can Guo wrote:
> > > > Add reset control for host controller so that host controller can be reset
> > > > as required in its power up sequence.
> > > 
> > > I am seeing a regression on UFS on SM8150-mtp with this patch. I think
> > > Jeff is seeing same one lenove laptop on 8998.
> > 
> > Confirmed.
> > 
> > > 
> > > 845 does not seem to have this issue and only thing I can see is
> > > that on
> > > sm8150 and 8998 we define reset as:
> > > 
> > >                         resets = <&gcc GCC_UFS_BCR>;
> > >                         reset-names = "rst";
> > > 
> 
> Hi Jeffrey and Vinod,
> 
> Thanks for reporting this. May I know what kind of regression do you see on
> 8150 and 8998?
> BTW, do you have reset control for UFS PHY in your DT?
> See 71278b058a9f8752e51030e363b7a7306938f64e.
> 
> FYI, we use reset control on all of our platforms and it is
> a must during our power up sequence.

Yes we do have this and additionally both the DTS describe a 'rst' reset
and this patch tries to use this.

Can you please tell me which platform this was tested on how the reset
was described in DT

Thanks
-- 
~Vinod

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[cang]

On 2019-12-17 12:13, Vinod Koul wrote:
> Hi Can,
> 
> On 17-12-19, 08:37, cang@codeaurora.org wrote:
>> On 2019-12-17 03:12, Jeffrey Hugo wrote:
>> > On Mon, Dec 16, 2019 at 12:05 PM Vinod Koul <vkoul@kernel.org> wrote:
>> > >
>> > > Hi Can,
>> > >
>> > > On 14-11-19, 22:09, Can Guo wrote:
>> > > > Add reset control for host controller so that host controller can be reset
>> > > > as required in its power up sequence.
>> > >
>> > > I am seeing a regression on UFS on SM8150-mtp with this patch. I think
>> > > Jeff is seeing same one lenove laptop on 8998.
>> >
>> > Confirmed.
>> >
>> > >
>> > > 845 does not seem to have this issue and only thing I can see is
>> > > that on
>> > > sm8150 and 8998 we define reset as:
>> > >
>> > >                         resets = <&gcc GCC_UFS_BCR>;
>> > >                         reset-names = "rst";
>> > >
>> 
>> Hi Jeffrey and Vinod,
>> 
>> Thanks for reporting this. May I know what kind of regression do you 
>> see on
>> 8150 and 8998?
>> BTW, do you have reset control for UFS PHY in your DT?
>> See 71278b058a9f8752e51030e363b7a7306938f64e.
>> 
>> FYI, we use reset control on all of our platforms and it is
>> a must during our power up sequence.
> 
> Yes we do have this and additionally both the DTS describe a 'rst' 
> reset
> and this patch tries to use this.
> 
> Can you please tell me which platform this was tested on how the reset
> was described in DT
> 
> Thanks

Hi Vinod,

If you are using the 8998's DT present on upstream, you may also need to 
enable
device reset on your platform. (We usually do a device reset before call 
ufshcd_hba_enable())
Given that 845 works fine, it may be the difference you have with 845. 
845 has device
reset support ready in upstream code, you can check sdm845-mtp.dts.
It is same for 8150, which is a lack of device reset support in upstream 
code base.

To enable UFS device reset, please see
1. 
https://lore.kernel.org/linux-arm-msm/20190828191756.24312-4-bjorn.andersson@linaro.org/
2. 53a5372ce326116f3e3d3f1d701113b2542509f4

FYI, I tested the patch on 8250 and its family platforms. In my build, I 
ported
change in #2 to my code base (in your case, make change to
drivers/pinctrl/qcom/pinctrl-msm8998.c) and enable the GPIO in DT like 
sdm845-mtp.dts

         reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>;

Thanks

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Vinod Koul]

Hi Can,

On 17-12-19, 15:10, cang@codeaurora.org wrote:
> On 2019-12-17 12:13, Vinod Koul wrote:
> > Hi Can,
> > 
> > On 17-12-19, 08:37, cang@codeaurora.org wrote:
> > > On 2019-12-17 03:12, Jeffrey Hugo wrote:
> > > > On Mon, Dec 16, 2019 at 12:05 PM Vinod Koul <vkoul@kernel.org> wrote:
> > > > >
> > > > > Hi Can,
> > > > >
> > > > > On 14-11-19, 22:09, Can Guo wrote:
> > > > > > Add reset control for host controller so that host controller can be reset
> > > > > > as required in its power up sequence.
> > > > >
> > > > > I am seeing a regression on UFS on SM8150-mtp with this patch. I think
> > > > > Jeff is seeing same one lenove laptop on 8998.
> > > >
> > > > Confirmed.
> > > >
> > > > >
> > > > > 845 does not seem to have this issue and only thing I can see is
> > > > > that on
> > > > > sm8150 and 8998 we define reset as:
> > > > >
> > > > >                         resets = <&gcc GCC_UFS_BCR>;
> > > > >                         reset-names = "rst";
> > > > >
> > > 
> > > Hi Jeffrey and Vinod,
> > > 
> > > Thanks for reporting this. May I know what kind of regression do you
> > > see on
> > > 8150 and 8998?
> > > BTW, do you have reset control for UFS PHY in your DT?
> > > See 71278b058a9f8752e51030e363b7a7306938f64e.
> > > 
> > > FYI, we use reset control on all of our platforms and it is
> > > a must during our power up sequence.
> > 
> > Yes we do have this and additionally both the DTS describe a 'rst' reset
> > and this patch tries to use this.
> > 
> > Can you please tell me which platform this was tested on how the reset
> > was described in DT
> > 
> > Thanks
> 
> Hi Vinod,
> 
> If you are using the 8998's DT present on upstream, you may also need to
> enable
> device reset on your platform. (We usually do a device reset before call
> ufshcd_hba_enable())
> Given that 845 works fine, it may be the difference you have with 845. 845
> has device
> reset support ready in upstream code, you can check sdm845-mtp.dts.
> It is same for 8150, which is a lack of device reset support in upstream
> code base.

I am using 8150mtp and you can see the DTS at [1]
with this patch I get phy timeout error

[    2.532594] qcom-qmp-phy 1d87000.phy: phy initialization timed-out

If i revert this patch the Timeout goes away. UFS node for this platform
is enabled in [2] and [3]

I did add the GPIO as well for testing but that doesnt work, only thing
that makes it work is rename the reset line to something other that 'rst'

I found that with this patch the reset is invoked twice, not sure why!

The 845 does not define a reset 'rst' but both 8150 and 8998 define
that!

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h=for-next
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3834a2e92229ef26d30de28acb698b2b23d3e397
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3e5bf28d2c3981f949e848eec8a60e0b9b61189d
> 
> To enable UFS device reset, please see
> 1. https://lore.kernel.org/linux-arm-msm/20190828191756.24312-4-bjorn.andersson@linaro.org/
> 2. 53a5372ce326116f3e3d3f1d701113b2542509f4

Yes both are added for UFS and I am testing with these..
> 
> FYI, I tested the patch on 8250 and its family platforms. In my build, I
> ported
> change in #2 to my code base (in your case, make change to
> drivers/pinctrl/qcom/pinctrl-msm8998.c) and enable the GPIO in DT like
> sdm845-mtp.dts

Please see drivers/pinctrl/qcom/pinctrl-sm8150.c upstream

>         reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>;

Yup, added:

        reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;

-- 
~Vinod

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[cang]

On 2019-12-17 17:24, Vinod Koul wrote:
> Hi Can,
> 
> On 17-12-19, 15:10, cang@codeaurora.org wrote:
>> On 2019-12-17 12:13, Vinod Koul wrote:
>> > Hi Can,
>> >
>> > On 17-12-19, 08:37, cang@codeaurora.org wrote:
>> > > On 2019-12-17 03:12, Jeffrey Hugo wrote:
>> > > > On Mon, Dec 16, 2019 at 12:05 PM Vinod Koul <vkoul@kernel.org> wrote:
>> > > > >
>> > > > > Hi Can,
>> > > > >
>> > > > > On 14-11-19, 22:09, Can Guo wrote:
>> > > > > > Add reset control for host controller so that host controller can be reset
>> > > > > > as required in its power up sequence.
>> > > > >
>> > > > > I am seeing a regression on UFS on SM8150-mtp with this patch. I think
>> > > > > Jeff is seeing same one lenove laptop on 8998.
>> > > >
>> > > > Confirmed.
>> > > >
>> > > > >
>> > > > > 845 does not seem to have this issue and only thing I can see is
>> > > > > that on
>> > > > > sm8150 and 8998 we define reset as:
>> > > > >
>> > > > >                         resets = <&gcc GCC_UFS_BCR>;
>> > > > >                         reset-names = "rst";
>> > > > >
>> > >
>> > > Hi Jeffrey and Vinod,
>> > >
>> > > Thanks for reporting this. May I know what kind of regression do you
>> > > see on
>> > > 8150 and 8998?
>> > > BTW, do you have reset control for UFS PHY in your DT?
>> > > See 71278b058a9f8752e51030e363b7a7306938f64e.
>> > >
>> > > FYI, we use reset control on all of our platforms and it is
>> > > a must during our power up sequence.
>> >
>> > Yes we do have this and additionally both the DTS describe a 'rst' reset
>> > and this patch tries to use this.
>> >
>> > Can you please tell me which platform this was tested on how the reset
>> > was described in DT
>> >
>> > Thanks
>> 
>> Hi Vinod,
>> 
>> If you are using the 8998's DT present on upstream, you may also need 
>> to
>> enable
>> device reset on your platform. (We usually do a device reset before 
>> call
>> ufshcd_hba_enable())
>> Given that 845 works fine, it may be the difference you have with 845. 
>> 845
>> has device
>> reset support ready in upstream code, you can check sdm845-mtp.dts.
>> It is same for 8150, which is a lack of device reset support in 
>> upstream
>> code base.
> 
> I am using 8150mtp and you can see the DTS at [1]
> with this patch I get phy timeout error
> 
> [    2.532594] qcom-qmp-phy 1d87000.phy: phy initialization timed-out
> 
> If i revert this patch the Timeout goes away. UFS node for this 
> platform
> is enabled in [2] and [3]
> 
> I did add the GPIO as well for testing but that doesnt work, only thing
> that makes it work is rename the reset line to something other that 
> 'rst'
> 
> I found that with this patch the reset is invoked twice, not sure why!
> 
> The 845 does not define a reset 'rst' but both 8150 and 8998 define
> that!
> 
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h=for-next
> [2]:
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3834a2e92229ef26d30de28acb698b2b23d3e397
> [3]:
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3e5bf28d2c3981f949e848eec8a60e0b9b61189d
>> 
>> To enable UFS device reset, please see
>> 1. 
>> https://lore.kernel.org/linux-arm-msm/20190828191756.24312-4-bjorn.andersson@linaro.org/
>> 2. 53a5372ce326116f3e3d3f1d701113b2542509f4
> 
> Yes both are added for UFS and I am testing with these..
>> 
>> FYI, I tested the patch on 8250 and its family platforms. In my build, 
>> I
>> ported
>> change in #2 to my code base (in your case, make change to
>> drivers/pinctrl/qcom/pinctrl-msm8998.c) and enable the GPIO in DT like
>> sdm845-mtp.dts
> 
> Please see drivers/pinctrl/qcom/pinctrl-sm8150.c upstream
> 
>>         reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>;
> 
> Yup, added:
> 
>         reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;

Hi Vinod,

What do you mean by the reset is invoked twice?

Renaming 'rst' to something else equals disabling this patch.

You said 845 has not this problem, I thought you tested the patch on 845 
with
the same 'rst' defined on 8998 and 8150. If 'rst' is not present in 
845's DT,
it means this patch has no impact on 845.

Actually, in our code base, we are not using phy-qcom-qmp.c. Instead,
we are using phy-qcom-ufs.c. phy-qcom-ufs.c is the one we use in all of 
our
mobile projects. Although both have the same functionality,
but in phy-qcom-ufs.c, the PCS ready bit polling timeout is 1000000us,
while in phy-qcom-qmp.c the PCS ready bit polling timeout is 1000us.
Would you mind give below change a try?

FYI, I tried the opposite change on my board (decrease the PCS polling 
timeout
used in phy-qcom-ufs.c), I did see PCS polling timeout, which is the 
same failure
you encountered.

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 39e8deb..0ee9149 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -66,7 +66,7 @@
  /* QPHY_V3_PCS_MISC_CLAMP_ENABLE register bits */
  #define CLAMP_EN                               BIT(0) /* enables i/o 
clamp_n */

-#define PHY_INIT_COMPLETE_TIMEOUT              1000
+#define PHY_INIT_COMPLETE_TIMEOUT              1000000
  #define POWER_DOWN_DELAY_US_MIN                        10
  #define POWER_DOWN_DELAY_US_MAX                        11

On 845, if there is 'rst'

Thanks.

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Vinod Koul]

On 17-12-19, 18:09, cang@codeaurora.org wrote:
> On 2019-12-17 17:24, Vinod Koul wrote:
> > Hi Can,
> > 
> > On 17-12-19, 15:10, cang@codeaurora.org wrote:
> > > On 2019-12-17 12:13, Vinod Koul wrote:
> > > > Hi Can,
> > > >
> > > > On 17-12-19, 08:37, cang@codeaurora.org wrote:
> > > > > On 2019-12-17 03:12, Jeffrey Hugo wrote:
> > > > > > On Mon, Dec 16, 2019 at 12:05 PM Vinod Koul <vkoul@kernel.org> wrote:
> > > > > > >
> > > > > > > Hi Can,
> > > > > > >
> > > > > > > On 14-11-19, 22:09, Can Guo wrote:
> > > > > > > > Add reset control for host controller so that host controller can be reset
> > > > > > > > as required in its power up sequence.
> > > > > > >
> > > > > > > I am seeing a regression on UFS on SM8150-mtp with this patch. I think
> > > > > > > Jeff is seeing same one lenove laptop on 8998.
> > > > > >
> > > > > > Confirmed.
> > > > > >
> > > > > > >
> > > > > > > 845 does not seem to have this issue and only thing I can see is
> > > > > > > that on
> > > > > > > sm8150 and 8998 we define reset as:
> > > > > > >
> > > > > > >                         resets = <&gcc GCC_UFS_BCR>;
> > > > > > >                         reset-names = "rst";
> > > > > > >
> > > > >
> > > > > Hi Jeffrey and Vinod,
> > > > >
> > > > > Thanks for reporting this. May I know what kind of regression do you
> > > > > see on
> > > > > 8150 and 8998?
> > > > > BTW, do you have reset control for UFS PHY in your DT?
> > > > > See 71278b058a9f8752e51030e363b7a7306938f64e.
> > > > >
> > > > > FYI, we use reset control on all of our platforms and it is
> > > > > a must during our power up sequence.
> > > >
> > > > Yes we do have this and additionally both the DTS describe a 'rst' reset
> > > > and this patch tries to use this.
> > > >
> > > > Can you please tell me which platform this was tested on how the reset
> > > > was described in DT
> > > >
> > > > Thanks
> > > 
> > > Hi Vinod,
> > > 
> > > If you are using the 8998's DT present on upstream, you may also
> > > need to
> > > enable
> > > device reset on your platform. (We usually do a device reset before
> > > call
> > > ufshcd_hba_enable())
> > > Given that 845 works fine, it may be the difference you have with
> > > 845. 845
> > > has device
> > > reset support ready in upstream code, you can check sdm845-mtp.dts.
> > > It is same for 8150, which is a lack of device reset support in
> > > upstream
> > > code base.
> > 
> > I am using 8150mtp and you can see the DTS at [1]
> > with this patch I get phy timeout error
> > 
> > [    2.532594] qcom-qmp-phy 1d87000.phy: phy initialization timed-out
> > 
> > If i revert this patch the Timeout goes away. UFS node for this platform
> > is enabled in [2] and [3]
> > 
> > I did add the GPIO as well for testing but that doesnt work, only thing
> > that makes it work is rename the reset line to something other that
> > 'rst'
> > 
> > I found that with this patch the reset is invoked twice, not sure why!
> > 
> > The 845 does not define a reset 'rst' but both 8150 and 8998 define
> > that!
> > 
> > [1]:
> > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h=for-next
> > [2]:
> > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3834a2e92229ef26d30de28acb698b2b23d3e397
> > [3]:
> > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3e5bf28d2c3981f949e848eec8a60e0b9b61189d
> > > 
> > > To enable UFS device reset, please see
> > > 1. https://lore.kernel.org/linux-arm-msm/20190828191756.24312-4-bjorn.andersson@linaro.org/
> > > 2. 53a5372ce326116f3e3d3f1d701113b2542509f4
> > 
> > Yes both are added for UFS and I am testing with these..
> > > 
> > > FYI, I tested the patch on 8250 and its family platforms. In my
> > > build, I
> > > ported
> > > change in #2 to my code base (in your case, make change to
> > > drivers/pinctrl/qcom/pinctrl-msm8998.c) and enable the GPIO in DT like
> > > sdm845-mtp.dts
> > 
> > Please see drivers/pinctrl/qcom/pinctrl-sm8150.c upstream
> > 
> > >         reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>;
> > 
> > Yup, added:
> > 
> >         reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
> 
> Hi Vinod,
> 
> What do you mean by the reset is invoked twice?
> 
> Renaming 'rst' to something else equals disabling this patch.
> 
> You said 845 has not this problem, I thought you tested the patch on 845
> with
> the same 'rst' defined on 8998 and 8150. If 'rst' is not present in 845's
> DT,
> it means this patch has no impact on 845.

To clarify: This problem is not seen in 845 with upstream kernel ie
5.5-rc1 but regression is observed in sm8150 and 8998 (Jeff)

And if I add the reset line to 845 (i am testing on dragon board
RB3, I am seeing same issue here as well)
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1374,6 +1374,8 @@
                        lanes-per-direction = <2>;
                        power-domains = <&gcc UFS_PHY_GDSC>;
                        #reset-cells = <1>;
+                       resets = <&gcc GCC_UFS_PHY_BCR>;
+                       reset-names = "rst";
 
                        iommus = <&apps_smmu 0x100 0xf>;
 

And on boot i am seeing UFS failing:

[    3.205567] qcom-qmp-phy 88eb000.phy: Registered Qcom-QMP phy
[    3.215440] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vdd-hba-supply regulator, assuming enabled
[    3.226315] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vccq-supply regulator, assuming enabled
[    3.236844] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vccq2-supply regulator, assuming enabled
[    3.257053] scsi host0: ufshcd
[    3.275109] qcom-qmp-phy 1d87000.phy: phy initialization timed-out
[    3.283677] qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x40904
[    3.290508] phy phy-1d87000.phy.0: phy poweron failed --> -110
[    3.296407] ufshcd-qcom 1d84000.ufshc: ufs_qcom_power_up_sequence: phy power on failed, ret = -110
[    3.360851] ufshcd-qcom 1d84000.ufshc: Controller enable failed
[    3.366838] ufshcd-qcom 1d84000.ufshc: Host controller enable failed

> Actually, in our code base, we are not using phy-qcom-qmp.c. Instead,
> we are using phy-qcom-ufs.c. phy-qcom-ufs.c is the one we use in all of our
> mobile projects. Although both have the same functionality,
> but in phy-qcom-ufs.c, the PCS ready bit polling timeout is 1000000us,
> while in phy-qcom-qmp.c the PCS ready bit polling timeout is 1000us.
> Would you mind give below change a try?

Sure and this seems to do the trick on 845 with resets defined, Jeff can
you try this on your laptop

But I dont get same result on sm8150-mtp, i am still seeing timeout with
1000000us.

The bigger question is why is the reset causing the timeout to be
increased for sdm845 and not to work in case of sm8150!

> FYI, I tried the opposite change on my board (decrease the PCS polling
> timeout
> used in phy-qcom-ufs.c), I did see PCS polling timeout, which is the same
> failure
> you encountered.
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 39e8deb..0ee9149 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -66,7 +66,7 @@
>  /* QPHY_V3_PCS_MISC_CLAMP_ENABLE register bits */
>  #define CLAMP_EN                               BIT(0) /* enables i/o
> clamp_n */
> 
> -#define PHY_INIT_COMPLETE_TIMEOUT              1000
> +#define PHY_INIT_COMPLETE_TIMEOUT              1000000
>  #define POWER_DOWN_DELAY_US_MIN                        10
>  #define POWER_DOWN_DELAY_US_MAX                        11
> 
> On 845, if there is 'rst'
> 
> Thanks.

-- 
~Vinod

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Jeffrey Hugo]

[-- Attachment #1: Type: text/plain, Size: 8237 bytes --]

On Tue, Dec 17, 2019 at 8:08 AM Vinod Koul <vkoul@kernel.org> wrote:
>
> On 17-12-19, 18:09, cang@codeaurora.org wrote:
> > On 2019-12-17 17:24, Vinod Koul wrote:
> > > Hi Can,
> > >
> > > On 17-12-19, 15:10, cang@codeaurora.org wrote:
> > > > On 2019-12-17 12:13, Vinod Koul wrote:
> > > > > Hi Can,
> > > > >
> > > > > On 17-12-19, 08:37, cang@codeaurora.org wrote:
> > > > > > On 2019-12-17 03:12, Jeffrey Hugo wrote:
> > > > > > > On Mon, Dec 16, 2019 at 12:05 PM Vinod Koul <vkoul@kernel.org> wrote:
> > > > > > > >
> > > > > > > > Hi Can,
> > > > > > > >
> > > > > > > > On 14-11-19, 22:09, Can Guo wrote:
> > > > > > > > > Add reset control for host controller so that host controller can be reset
> > > > > > > > > as required in its power up sequence.
> > > > > > > >
> > > > > > > > I am seeing a regression on UFS on SM8150-mtp with this patch. I think
> > > > > > > > Jeff is seeing same one lenove laptop on 8998.
> > > > > > >
> > > > > > > Confirmed.
> > > > > > >
> > > > > > > >
> > > > > > > > 845 does not seem to have this issue and only thing I can see is
> > > > > > > > that on
> > > > > > > > sm8150 and 8998 we define reset as:
> > > > > > > >
> > > > > > > >                         resets = <&gcc GCC_UFS_BCR>;
> > > > > > > >                         reset-names = "rst";
> > > > > > > >
> > > > > >
> > > > > > Hi Jeffrey and Vinod,
> > > > > >
> > > > > > Thanks for reporting this. May I know what kind of regression do you
> > > > > > see on
> > > > > > 8150 and 8998?
> > > > > > BTW, do you have reset control for UFS PHY in your DT?
> > > > > > See 71278b058a9f8752e51030e363b7a7306938f64e.
> > > > > >
> > > > > > FYI, we use reset control on all of our platforms and it is
> > > > > > a must during our power up sequence.
> > > > >
> > > > > Yes we do have this and additionally both the DTS describe a 'rst' reset
> > > > > and this patch tries to use this.
> > > > >
> > > > > Can you please tell me which platform this was tested on how the reset
> > > > > was described in DT
> > > > >
> > > > > Thanks
> > > >
> > > > Hi Vinod,
> > > >
> > > > If you are using the 8998's DT present on upstream, you may also
> > > > need to
> > > > enable
> > > > device reset on your platform. (We usually do a device reset before
> > > > call
> > > > ufshcd_hba_enable())
> > > > Given that 845 works fine, it may be the difference you have with
> > > > 845. 845
> > > > has device
> > > > reset support ready in upstream code, you can check sdm845-mtp.dts.
> > > > It is same for 8150, which is a lack of device reset support in
> > > > upstream
> > > > code base.
> > >
> > > I am using 8150mtp and you can see the DTS at [1]
> > > with this patch I get phy timeout error
> > >
> > > [    2.532594] qcom-qmp-phy 1d87000.phy: phy initialization timed-out
> > >
> > > If i revert this patch the Timeout goes away. UFS node for this platform
> > > is enabled in [2] and [3]
> > >
> > > I did add the GPIO as well for testing but that doesnt work, only thing
> > > that makes it work is rename the reset line to something other that
> > > 'rst'
> > >
> > > I found that with this patch the reset is invoked twice, not sure why!
> > >
> > > The 845 does not define a reset 'rst' but both 8150 and 8998 define
> > > that!
> > >
> > > [1]:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h=for-next
> > > [2]:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3834a2e92229ef26d30de28acb698b2b23d3e397
> > > [3]:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3e5bf28d2c3981f949e848eec8a60e0b9b61189d
> > > >
> > > > To enable UFS device reset, please see
> > > > 1. https://lore.kernel.org/linux-arm-msm/20190828191756.24312-4-bjorn.andersson@linaro.org/
> > > > 2. 53a5372ce326116f3e3d3f1d701113b2542509f4
> > >
> > > Yes both are added for UFS and I am testing with these..
> > > >
> > > > FYI, I tested the patch on 8250 and its family platforms. In my
> > > > build, I
> > > > ported
> > > > change in #2 to my code base (in your case, make change to
> > > > drivers/pinctrl/qcom/pinctrl-msm8998.c) and enable the GPIO in DT like
> > > > sdm845-mtp.dts
> > >
> > > Please see drivers/pinctrl/qcom/pinctrl-sm8150.c upstream
> > >
> > > >         reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>;
> > >
> > > Yup, added:
> > >
> > >         reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
> >
> > Hi Vinod,
> >
> > What do you mean by the reset is invoked twice?
> >
> > Renaming 'rst' to something else equals disabling this patch.
> >
> > You said 845 has not this problem, I thought you tested the patch on 845
> > with
> > the same 'rst' defined on 8998 and 8150. If 'rst' is not present in 845's
> > DT,
> > it means this patch has no impact on 845.
>
> To clarify: This problem is not seen in 845 with upstream kernel ie
> 5.5-rc1 but regression is observed in sm8150 and 8998 (Jeff)
>
> And if I add the reset line to 845 (i am testing on dragon board
> RB3, I am seeing same issue here as well)
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1374,6 +1374,8 @@
>                         lanes-per-direction = <2>;
>                         power-domains = <&gcc UFS_PHY_GDSC>;
>                         #reset-cells = <1>;
> +                       resets = <&gcc GCC_UFS_PHY_BCR>;
> +                       reset-names = "rst";
>
>                         iommus = <&apps_smmu 0x100 0xf>;
>
>
> And on boot i am seeing UFS failing:
>
> [    3.205567] qcom-qmp-phy 88eb000.phy: Registered Qcom-QMP phy
> [    3.215440] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vdd-hba-supply regulator, assuming enabled
> [    3.226315] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vccq-supply regulator, assuming enabled
> [    3.236844] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable to find vccq2-supply regulator, assuming enabled
> [    3.257053] scsi host0: ufshcd
> [    3.275109] qcom-qmp-phy 1d87000.phy: phy initialization timed-out
> [    3.283677] qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x40904
> [    3.290508] phy phy-1d87000.phy.0: phy poweron failed --> -110
> [    3.296407] ufshcd-qcom 1d84000.ufshc: ufs_qcom_power_up_sequence: phy power on failed, ret = -110
> [    3.360851] ufshcd-qcom 1d84000.ufshc: Controller enable failed
> [    3.366838] ufshcd-qcom 1d84000.ufshc: Host controller enable failed
>
> > Actually, in our code base, we are not using phy-qcom-qmp.c. Instead,
> > we are using phy-qcom-ufs.c. phy-qcom-ufs.c is the one we use in all of our
> > mobile projects. Although both have the same functionality,
> > but in phy-qcom-ufs.c, the PCS ready bit polling timeout is 1000000us,
> > while in phy-qcom-qmp.c the PCS ready bit polling timeout is 1000us.
> > Would you mind give below change a try?
>
> Sure and this seems to do the trick on 845 with resets defined, Jeff can
> you try this on your laptop

I'm attaching a complete log of the failure I see.

Increasing PHY_INIT_COMPLETE_TIMEOUT to the indicated value appears to
fix the issue for me.

>
> But I dont get same result on sm8150-mtp, i am still seeing timeout with
> 1000000us.
>
> The bigger question is why is the reset causing the timeout to be
> increased for sdm845 and not to work in case of sm8150!
>
> > FYI, I tried the opposite change on my board (decrease the PCS polling
> > timeout
> > used in phy-qcom-ufs.c), I did see PCS polling timeout, which is the same
> > failure
> > you encountered.
> >
> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> > b/drivers/phy/qualcomm/phy-qcom-qmp.c
> > index 39e8deb..0ee9149 100644
> > --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> > +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> > @@ -66,7 +66,7 @@
> >  /* QPHY_V3_PCS_MISC_CLAMP_ENABLE register bits */
> >  #define CLAMP_EN                               BIT(0) /* enables i/o
> > clamp_n */
> >
> > -#define PHY_INIT_COMPLETE_TIMEOUT              1000
> > +#define PHY_INIT_COMPLETE_TIMEOUT              1000000
> >  #define POWER_DOWN_DELAY_US_MIN                        10
> >  #define POWER_DOWN_DELAY_US_MAX                        11
> >
> > On 845, if there is 'rst'
> >
> > Thanks.
>
> --
> ~Vinod

[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 53264 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x51af8014]
[    0.000000] Linux version 5.5.0-rc2+ (ubuntu@aw-bldr-10) (gcc version 6.5.0 20181026 (Ubuntu/Linaro 6.5.0-2ubuntu1~18.04)) #1069 SMP PREEMPT Tue Dec 17 07:23:35 PST 2019
[    0.000000] Machine model: Lenovo Miix 630
[    0.000000] printk: debug: ignoring loglevel setting.
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: EFI v2.60 by American Megatrends
[    0.000000] efi:  ACPI 2.0=0x9dfd7000  ESRT=0x9a7f1f98  SMBIOS=0x9df36000  MEMATTR=0x9c03c018  TPMEventLog=0x9d8b8018  RNG=0x9ded5f98  MEMRESERVE=0x9d8b7018
[    0.000000] efi: seeding entropy pool
[    0.000000] efi: memattr: Unexpected EFI Memory Attributes table version -1347440721
[    0.000000] esrt: Reserving ESRT space from 0x000000009a7f1f98 to 0x000000009a7f1fd0.
[    0.000000] cma: Reserved 32 MiB at 0x00000000fe000000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000080000000-0x000000017e4bffff]
[    0.000000] NUMA: NODE_DATA [mem 0x17dd65100-0x17dd66fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000080000000-0x00000000bfffffff]
[    0.000000]   DMA32    [mem 0x00000000c0000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x000000017e4bffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080000000-0x00000000803fffff]
[    0.000000]   node   0: [mem 0x0000000080400000-0x0000000080d5ffff]
[    0.000000]   node   0: [mem 0x0000000080eb0000-0x00000000857fffff]
[    0.000000]   node   0: [mem 0x0000000088f00000-0x000000008aafffff]
[    0.000000]   node   0: [mem 0x000000008ab00000-0x000000008cbfffff]
[    0.000000]   node   0: [mem 0x0000000093c00000-0x00000000940fffff]
[    0.000000]   node   0: [mem 0x0000000094300000-0x00000000956fffff]
[    0.000000]   node   0: [mem 0x0000000095800000-0x000000009dd93fff]
[    0.000000]   node   0: [mem 0x000000009dd94000-0x000000009df87fff]
[    0.000000]   node   0: [mem 0x000000009df88000-0x000000009f9fffff]
[    0.000000]   node   0: [mem 0x000000009fc00000-0x000000009ffcffff]
[    0.000000]   node   0: [mem 0x000000009ffd0000-0x000000009ffd9fff]
[    0.000000]   node   0: [mem 0x000000009ffdd000-0x00000000abdfffff]
[    0.000000]   node   0: [mem 0x00000000abe00000-0x000000017e4bffff]
[    0.000000] Zeroed struct page in unavailable ranges: 412 pages
[    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000017e4bffff]
[    0.000000] On node 0 totalpages: 997229
[    0.000000]   DMA zone: 3403 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 217773 pages, LIFO batch:63
[    0.000000]   DMA32 zone: 4096 pages used for memmap
[    0.000000]   DMA32 zone: 262144 pages, LIFO batch:63
[    0.000000]   Normal zone: 8083 pages used for memmap
[    0.000000]   Normal zone: 517312 pages, LIFO batch:63
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.0 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.0
[    0.000000] psci: OSI mode supported.
[    0.000000] percpu: Embedded 22 pages/cpu s53016 r8192 d28904 u90112
[    0.000000] pcpu-alloc: s53016 r8192 d28904 u90112 alloc=22*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: GIC system register CPU interface
[    0.000000] CPU features: detected: Kernel page table isolation (KPTI)
[    0.000000] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 981647
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.5.0-rc2+ root=UUID=67afc572-56a9-4a7e-b17f-08d5fedf332c ro nokaslr efi=novamap ignore_loglevel log_buf_len=16M
[    0.000000] printk: log_buf_len: 16777216 bytes
[    0.000000] printk: early log buf free: 126932(96%)
[    0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[    0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: mapped [mem 0xbbfff000-0xbffff000] (64MB)
[    0.000000] Memory: 3481848K/3988916K available (12284K kernel code, 1964K rwdata, 6776K rodata, 5184K init, 460K bss, 474300K reserved, 32768K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=8.
[    0.000000]  Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GICv3: 608 SPIs implemented
[    0.000000] GICv3: 0 Extended SPIs implemented
[    0.000000] GICv3: Distributor has no Range Selector support
[    0.000000] GICv3: 16 PPIs implemented
[    0.000000] GICv3: no VLPI support, no direct LPI support
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000017b00000
[    0.000000] ITS: No ITS available, not enabling LPIs
[    0.000000] random: get_random_bytes called from start_kernel+0x2b8/0x454 with crng_init=0
[    0.000000] arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[    0.000002] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[    0.000113] Console: colour dummy device 80x25
[    0.000663] printk: console [tty0] enabled
[    0.000724] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
[    0.000741] pid_max: default: 32768 minimum: 301
[    0.000808] LSM: Security Framework initializing
[    0.000865] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    0.000886] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    0.023444] ASID allocator initialised with 32768 entries
[    0.031442] rcu: Hierarchical SRCU implementation.
[    0.041360] Remapping and enabling EFI services.
[    0.047467] smp: Bringing up secondary CPUs ...
[    0.080848] Detected VIPT I-cache on CPU1
[    0.080879] GICv3: CPU1: found redistributor 1 region 0:0x0000000017b20000
[    0.080926] CPU1: Booted secondary processor 0x0000000001 [0x51af8014]
[    0.112731] Detected VIPT I-cache on CPU2
[    0.112753] GICv3: CPU2: found redistributor 2 region 0:0x0000000017b40000
[    0.112791] CPU2: Booted secondary processor 0x0000000002 [0x51af8014]
[    0.144768] Detected VIPT I-cache on CPU3
[    0.144790] GICv3: CPU3: found redistributor 3 region 0:0x0000000017b60000
[    0.144829] CPU3: Booted secondary processor 0x0000000003 [0x51af8014]
[    0.177161] Detected VIPT I-cache on CPU4
[    0.177224] GICv3: CPU4: found redistributor 100 region 0:0x0000000017b80000
[    0.177299] CPU4: Booted secondary processor 0x0000000100 [0x51af8001]
[    0.209021] Detected VIPT I-cache on CPU5
[    0.209081] GICv3: CPU5: found redistributor 101 region 0:0x0000000017ba0000
[    0.209150] CPU5: Booted secondary processor 0x0000000101 [0x51af8001]
[    0.241080] Detected VIPT I-cache on CPU6
[    0.241144] GICv3: CPU6: found redistributor 102 region 0:0x0000000017bc0000
[    0.241214] CPU6: Booted secondary processor 0x0000000102 [0x51af8001]
[    0.273142] Detected VIPT I-cache on CPU7
[    0.273208] GICv3: CPU7: found redistributor 103 region 0:0x0000000017be0000
[    0.273279] CPU7: Booted secondary processor 0x0000000103 [0x51af8001]
[    0.273448] smp: Brought up 1 node, 8 CPUs
[    0.273589] SMP: Total of 8 processors activated.
[    0.273598] CPU features: detected: 32-bit EL0 Support
[    0.273607] CPU features: detected: CRC32 instructions
[    0.773881] CPU: All CPU(s) started at EL1
[    0.773934] alternatives: patching kernel code
[    0.775716] devtmpfs: initialized
[    0.780404] KASLR disabled on command line
[    0.780722] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.780745] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
[    0.781749] pinctrl core: initialized pinctrl subsystem
[    0.782750] thermal_sys: Registered thermal governor 'step_wise'
[    0.782753] thermal_sys: Registered thermal governor 'power_allocator'
[    0.784005] SMBIOS 3.0 present.
[    0.784027] DMI: LENOVO 81F1/LNVNB161216, BIOS 8WCN25WW 05/10/2018
[    0.784357] NET: Registered protocol family 16
[    0.785415] DMA: preallocated 256 KiB pool for atomic allocations
[    0.785429] audit: initializing netlink subsys (disabled)
[    0.785580] audit: type=2000 audit(0.296:1): state=initialized audit_enabled=0 res=1
[    0.786442] cpuidle: using governor menu
[    0.786673] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.789734] Serial: AMBA PL011 UART driver
[    0.829059] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    0.829100] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    0.829132] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.829162] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    0.831983] cryptd: max_cpu_qlen set to 1000
[    0.836699] ACPI: Interpreter disabled.
[    0.838932] iommu: Default domain type: Translated
[    0.839236] vgaarb: loaded
[    0.839771] SCSI subsystem initialized
[    0.840013] libata version 3.00 loaded.
[    0.840397] usbcore: registered new interface driver usbfs
[    0.840502] usbcore: registered new interface driver hub
[    0.840674] usbcore: registered new device driver usb
[    0.841766] pps_core: LinuxPPS API ver. 1 registered
[    0.841796] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.841850] PTP clock support registered
[    0.842051] EDAC MC: Ver: 3.0.0
[    0.843270] Registered efivars operations
[    0.844728] FPGA manager framework
[    0.844875] Advanced Linux Sound Architecture Driver Initialized.
[    0.846219] clocksource: Switched to clocksource arch_sys_counter
[    0.846568] VFS: Disk quotas dquot_6.6.0
[    0.846683] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.846956] pnp: PnP ACPI: disabled
[    0.856606] s1: supplied by vph_pwr
[    0.856712] NET: Registered protocol family 2
[    0.856764] s2: supplied by vph_pwr
[    0.856869] s3: supplied by vph_pwr
[    0.856895] s3: Bringing 0uV into 1352000-1352000uV
[    0.856989] s4: supplied by vph_pwr
[    0.857013] s4: Bringing 0uV into 1800000-1800000uV
[    0.857107] s5: supplied by vph_pwr
[    0.857144] s5: Bringing 0uV into 1904000-1904000uV
[    0.857243] s6: supplied by vph_pwr
[    0.857341] s7: supplied by vph_pwr
[    0.857364] s7: Bringing 0uV into 900000-900000uV
[    0.857420] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear)
[    0.857464] s8: supplied by vph_pwr
[    0.857534] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear)
[    0.857598] s9: supplied by vph_pwr
[    0.857703] s10: supplied by vph_pwr
[    0.857805] s11: supplied by vph_pwr
[    0.857915] s12: supplied by vph_pwr
[    0.858013] s13: supplied by vph_pwr
[    0.858109] l1: supplied by s7
[    0.858137] TCP bind hash table entries: 32768 (order: 7, 524288 bytes, linear)
[    0.858147] l1: Bringing 0uV into 880000-880000uV
[    0.858308] l2: supplied by s3
[    0.858334] l2: Bringing 0uV into 1200000-1200000uV
[    0.858424] l3: supplied by s7
[    0.858448] l3: Bringing 0uV into 1000000-1000000uV
[    0.858546] l4: supplied by s7
[    0.858659] l5: supplied by s7
[    0.858685] l5: Bringing 0uV into 800000-800000uV
[    0.858779] l6: supplied by s5
[    0.858802] l6: Bringing 0uV into 1808000-1808000uV
[    0.858818] TCP: Hash tables configured (established 32768 bind 32768)
[    0.858903] l7: supplied by s5
[    0.858936] l7: Bringing 0uV into 1800000-1800000uV
[    0.859002] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
[    0.859046] l8: supplied by s3
[    0.859079] l8: Bringing 0uV into 1200000-1200000uV
[    0.859143] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
[    0.859176] l9: supplied by vph_pwr
[    0.859215] l9: Bringing 0uV into 1808000-1808000uV
[    0.859318] l10: supplied by vph_pwr
[    0.859341] l10: Bringing 0uV into 1808000-1808000uV
[    0.859457] l11: supplied by s7
[    0.859482] l11: Bringing 0uV into 1000000-1000000uV
[    0.859488] NET: Registered protocol family 1
[    0.859594] l12: supplied by s5
[    0.859617] l12: Bringing 0uV into 1800000-1800000uV
[    0.859717] l13: supplied by vph_pwr
[    0.859744] l13: Bringing 0uV into 1808000-1808000uV
[    0.859860] l14: supplied by s5
[    0.859883] l14: Bringing 0uV into 1880000-1880000uV
[    0.859984] l15: supplied by s5
[    0.860008] l15: Bringing 0uV into 1800000-1800000uV
[    0.860025] RPC: Registered named UNIX socket transport module.
[    0.860061] RPC: Registered udp transport module.
[    0.860086] RPC: Registered tcp transport module.
[    0.860109] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.860111] l16: supplied by vph_pwr
[    0.860132] l16: Bringing 0uV into 2704000-2704000uV
[    0.860177] PCI: CLS 0 bytes, default 64
[    0.860243] l17: supplied by s3
[    0.860279] l17: Bringing 0uV into 1304000-1304000uV
[    0.860385] l18: supplied by vph_pwr
[    0.860412] l18: Bringing 0uV into 2704000-2704000uV
[    0.860433] Unpacking initramfs...
[    0.860518] l19: supplied by vph_pwr
[    0.860552] l19: Bringing 0uV into 3008000-3008000uV
[    0.860660] l20: supplied by vph_pwr
[    0.860698] l20: Bringing 0uV into 2960000-2960000uV
[    0.860811] l21: supplied by vph_pwr
[    0.860838] l21: Bringing 0uV into 2960000-2960000uV
[    0.860948] l22: supplied by vph_pwr
[    0.860971] l22: Bringing 0uV into 2864000-2864000uV
[    0.861080] l23: supplied by vph_pwr
[    0.861119] l23: Bringing 0uV into 3312000-3312000uV
[    0.861226] l24: supplied by vph_pwr
[    0.861249] l24: Bringing 0uV into 3088000-3088000uV
[    0.861361] l25: supplied by vph_pwr
[    0.861389] l25: Bringing 0uV into 3104000-3104000uV
[    0.861504] l26: supplied by s3
[    0.861540] l26: Bringing 0uV into 1200000-1200000uV
[    0.861644] l27: supplied by s7
[    0.861757] l28: supplied by vph_pwr
[    0.861781] l28: Bringing 0uV into 3008000-3008000uV
[    0.861894] lvs1: supplied by s4
[    0.862028] lvs2: supplied by s4
[    3.104979] Freeing initrd memory: 18804K
[    3.106251] kvm [1]: HYP mode not available
[    3.190294] Initialise system trusted keyrings
[    3.190543] workingset: timestamp_bits=44 max_order=20 bucket_order=0
[    3.202329] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    3.203562] NFS: Registering the id_resolver key type
[    3.203618] Key type id_resolver registered
[    3.203643] Key type id_legacy registered
[    3.203680] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    3.203907] 9p: Installing v9fs 9p2000 file system support
[    3.232621] Key type asymmetric registered
[    3.232651] Asymmetric key parser 'x509' registered
[    3.232709] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
[    3.232722] io scheduler mq-deadline registered
[    3.232730] io scheduler kyber registered
[    3.238478] efifb: probing for efifb
[    3.238534] efifb: framebuffer at 0x80400000, using 9600k, total 9600k
[    3.238545] efifb: mode is 1920x1280x32, linelength=7680, pages=1
[    3.238553] efifb: scrolling: redraw
[    3.238561] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    3.261582] Console: switching to colour frame buffer device 240x80
[    3.283507] fb0: EFI VGA frame buffer device
[    3.283888] EINJ: ACPI disabled.
[    3.292957] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    3.294485] SuperH (H)SCI(F) driver initialized
[    3.294977] msm_serial c171000.serial: msm_serial: detected port #0
[    3.295109] msm_serial: driver initialized
[    3.295886] arm-smmu 1680000.iommu: probing hardware configuration...
[    3.295986] arm-smmu 1680000.iommu: SMMUv2 with:
[    3.296077] arm-smmu 1680000.iommu:  stage 1 translation
[    3.296159] arm-smmu 1680000.iommu:  address translation ops
[    3.296246] arm-smmu 1680000.iommu:  non-coherent table walk
[    3.296332] arm-smmu 1680000.iommu:  (IDR0.CTTW overridden by FW configuration)
[    3.296444] arm-smmu 1680000.iommu:  stream matching with 16 register groups
[    3.296570] arm-smmu 1680000.iommu:  6 context banks (0 stage-2 only)
[    3.296679] arm-smmu 1680000.iommu:  Supported page sizes: 0x63315000
[    3.296777] arm-smmu 1680000.iommu:  Stage-1: 36-bit VA -> 36-bit IPA
[    3.297844] arm-smmu 16c0000.iommu: probing hardware configuration...
[    3.297944] arm-smmu 16c0000.iommu: SMMUv2 with:
[    3.298026] arm-smmu 16c0000.iommu:  stage 1 translation
[    3.298108] arm-smmu 16c0000.iommu:  address translation ops
[    3.298194] arm-smmu 16c0000.iommu:  non-coherent table walk
[    3.298298] arm-smmu 16c0000.iommu:  (IDR0.CTTW overridden by FW configuration)
[    3.298409] arm-smmu 16c0000.iommu:  stream matching with 14 register groups
[    3.298533] arm-smmu 16c0000.iommu:  10 context banks (0 stage-2 only)
[    3.298642] arm-smmu 16c0000.iommu:  Supported page sizes: 0x63315000
[    3.298740] arm-smmu 16c0000.iommu:  Stage-1: 36-bit VA -> 36-bit IPA
[    3.306005] loop: module loaded
[    3.308351] spmi spmi-0: PMIC arbiter version v3 (0x30000000)
[    3.314253] gpio gpiochip2: (800f000.spmi:pmic@4:gpios@c000): detected irqchip that is shared with multiple gpiochips: please fix the driver.
[    3.315167] libphy: Fixed MDIO Bus: probed
[    3.315414] tun: Universal TUN/TAP device driver, 1.6
[    3.316009] thunder_xcv, ver 1.0
[    3.316082] thunder_bgx, ver 1.0
[    3.316153] nicpf, ver 1.0
[    3.316561] hclge is initializing
[    3.316616] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
[    3.316724] hns3: Copyright (c) 2017 Huawei Corporation.
[    3.316836] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[    3.316925] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    3.317037] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
[    3.317142] igb: Copyright (c) 2007-2014 Intel Corporation.
[    3.317247] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.4.0-k
[    3.317365] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    3.317665] sky2: driver version 1.30
[    3.318166] VFIO - User Level meta-driver version: 0.3
[    3.319369] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    3.319471] ehci-pci: EHCI PCI platform driver
[    3.319558] ehci-platform: EHCI generic platform driver
[    3.319712] ehci-orion: EHCI orion driver
[    3.319833] ehci-exynos: EHCI EXYNOS driver
[    3.324219] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    3.328586] ohci-pci: OHCI PCI platform driver
[    3.332991] ohci-platform: OHCI generic platform driver
[    3.337466] ohci-exynos: OHCI EXYNOS driver
[    3.342165] usbcore: registered new interface driver usb-storage
[    3.348475] i2c /dev entries driver
[    3.353298] i2c_qup c17a000.i2c:
                tx channel not available
[    3.362000] i2c_qup c17a000.i2c: Could not get core clock
[    3.371449] sdhci: Secure Digital Host Controller Interface driver
[    3.375883] sdhci: Copyright(c) Pierre Ossman
[    3.380512] Synopsys Designware Multimedia Card Interface Driver
[    3.385479] sdhci-pltfm: SDHCI platform and OF driver helper
[    3.390753] sdhci_msm c0a4900.sdhci: Got CD GPIO
[    3.395189] sdhci_msm c0a4900.sdhci: Peripheral clk setup failed (-517)
[    3.400317] ledtrig-cpu: registered to indicate activity on CPUs
[    3.405646] usbcore: registered new interface driver usbhid
[    3.410023] usbhid: USB HID core driver
[    3.417295] NET: Registered protocol family 17
[    3.421819] 9pnet: Installing 9P2000 support
[    3.426240] Key type dns_resolver registered
[    3.431087] registered taskstats version 1
[    3.435439] Loading compiled-in X.509 certificates
[    3.458184] msm_serial c171000.serial: msm_serial: detected port #1
[    3.462631] msm_serial c171000.serial: uartclk = 19200000
[    3.466992] c171000.serial: ttyMSM1 at MMIO 0xc171000 (irq = 39, base_baud = 1200000) is a MSM
[    3.472467] serial serial0: tty port ttyMSM1 registered
[    3.479404] dwc3-qcom a8f8800.usb: IRQ dp_hs_phy_irq not found
[    3.483828] dwc3-qcom a8f8800.usb: IRQ dm_hs_phy_irq not found
[    3.489274] dwc3 a800000.dwc3: Failed to get clk 'ref': -2
[    3.494545] i2c_qup c17a000.i2c:
                tx channel not available
[    3.504639] sdhci_msm c0a4900.sdhci: Got CD GPIO
[    3.547769] mmc0: SDHCI controller on c0a4900.sdhci [c0a4900.sdhci] using ADMA 64-bit
[    3.553723] dwc3 a800000.dwc3: Failed to get clk 'ref': -2
[    3.559870] dwc3 a800000.dwc3: Failed to get clk 'ref': -2
[    3.565639] hctosys: unable to open rtc device (rtc0)
[    3.570759] ------------[ cut here ]------------
[    3.575178] gcc_gpu_bimc_gfx_clk status stuck at 'on'
[    3.575210] WARNING: CPU: 3 PID: 1 at drivers/clk/qcom/clk-branch.c:92 clk_branch_toggle+0x160/0x170
[    3.584197] Modules linked in:
[    3.588735] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc2+ #1069
[    3.593346] Hardware name: LENOVO 81F1/LNVNB161216, BIOS 8WCN25WW 05/10/2018
[    3.598019] pstate: 60000085 (nZCv daIf -PAN -UAO)
[    3.602722] pc : clk_branch_toggle+0x160/0x170
[    3.607442] lr : clk_branch_toggle+0x160/0x170
[    3.612115] sp : ffff80001005bd00
[    3.616762] x29: ffff80001005bd00 x28: 0000000000000000
[    3.621425] x27: ffff8000113e8070 x26: ffff8000113305a0
[    3.626079] x25: ffff8000111a81e0 x24: 0000000000000000
[    3.630723] x23: ffff80001192be00 x22: ffff8000105f2420
[    3.635326] x21: 0000000000000000 x20: ffff800011849000
[    3.639899] x19: 0000000000000000 x18: ffffffffffffffff
[    3.644356] x17: 0000000000001800 x16: 0000000000008f20
[    3.648695] x15: 0000000000001e00 x14: 0000000000000001
[    3.653000] x13: ffff800010da6b90 x12: ffff0000f4111ca0
[    3.657292] x11: 0000000000000001 x10: 0000000000000020
[    3.661614] x9 : 00000000ffffffff x8 : ffff800011a3bb98
[    3.665947] x7 : 6375747320737574 x6 : ffff800011a3b6b9
[    3.670282] x5 : 0000000000000000 x4 : 0000000000000000
[    3.674589] x3 : 00000000ffffffff x2 : ffff8000ec875000
[    3.678857] x1 : 6024f5744eae8900 x0 : 0000000000000000
[    3.683102] Call trace:
[    3.687307]  clk_branch_toggle+0x160/0x170
[    3.691497]  clk_branch2_disable+0x18/0x20
[    3.695646]  clk_disable_unused_subtree+0xac/0xe4
[    3.699760]  clk_disable_unused+0x5c/0xe8
[    3.703814]  do_one_initcall+0x58/0x1a0
[    3.707851]  kernel_init_freeable+0x19c/0x20c
[    3.711875]  kernel_init+0x10/0x108
[    3.715849]  ret_from_fork+0x10/0x1c
[    3.719791] ---[ end trace a886f7912f8296e8 ]---
[    3.724105] ------------[ cut here ]------------
[    3.728060] gcc_rx1_usb2_clkref_clk status stuck at 'on'
[    3.728081] WARNING: CPU: 3 PID: 1 at drivers/clk/qcom/clk-branch.c:92 clk_branch_toggle+0x160/0x170
[    3.736139] Modules linked in:
[    3.740180] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G        W         5.5.0-rc2+ #1069
[    3.744312] Hardware name: LENOVO 81F1/LNVNB161216, BIOS 8WCN25WW 05/10/2018
[    3.748473] pstate: 60000085 (nZCv daIf -PAN -UAO)
[    3.752615] pc : clk_branch_toggle+0x160/0x170
[    3.756741] lr : clk_branch_toggle+0x160/0x170
[    3.760843] sp : ffff80001005bcc0
[    3.764943] x29: ffff80001005bcc0 x28: 0000000000000000
[    3.769047] x27: ffff8000113e8070 x26: ffff8000113305a0
[    3.773113] x25: ffff8000111a7900 x24: 0000000000000000
[    3.777151] x23: ffff80001192a6f8 x22: ffff8000105f2420
[    3.781156] x21: 0000000000000000 x20: ffff800011849000
[    3.785127] x19: 0000000000000000 x18: ffffffffffffffff
[    3.789068] x17: 0000000000001800 x16: 0000000000008f20
[    3.792995] x15: 0000000000001e00 x14: 0000000000000001
[    3.796864] x13: ffff800010da6b90 x12: ffff0000f4111f90
[    3.800706] x11: 0000000000000001 x10: 0000000000000020
[    3.804533] x9 : 00000000ffffffff x8 : ffff800011a3bb98
[    3.808352] x7 : 7320737574617473 x6 : ffff800011a3b6bc
[    3.812156] x5 : 0000000000000000 x4 : 0000000000000000
[    3.815963] x3 : 00000000ffffffff x2 : ffff8000ec875000
[    3.819759] x1 : 6024f5744eae8900 x0 : 0000000000000000
[    3.823544] Call trace:
[    3.827274]  clk_branch_toggle+0x160/0x170
[    3.831026]  clk_branch2_disable+0x18/0x20
[    3.834713]  clk_disable_unused_subtree+0xac/0xe4
[    3.838361]  clk_disable_unused_subtree+0x3c/0xe4
[    3.841954]  clk_disable_unused_subtree+0x3c/0xe4
[    3.845545]  clk_disable_unused+0x5c/0xe8
[    3.849094]  do_one_initcall+0x58/0x1a0
[    3.852624]  kernel_init_freeable+0x19c/0x20c
[    3.856166]  kernel_init+0x10/0x108
[    3.859676]  ret_from_fork+0x10/0x1c
[    3.863130] ---[ end trace a886f7912f8296e9 ]---
[    3.866731] ALSA device list:
[    3.870184]   No soundcards found.
[    3.875145] Freeing unused kernel memory: 5184K
[    3.878652] Run /init as init process
[    3.915805] mmc0: new ultra high speed SDR104 SDHC card at address aaaa
[    3.920406] mmcblk0: mmc0:aaaa SE32G 29.7 GiB
[    3.933723]  mmcblk0: p1 p2
[    3.939803] dwc3 a800000.dwc3: Failed to get clk 'ref': -2
[    4.598286] qcom-qmp-phy 1c06000.phy: Registered Qcom-QMP phy
[    4.598901] ufshcd-qcom 1da4000.ufshc: ufshcd_populate_vreg: Unable to find vdd-hba-supply regulator, assuming enabled
[    4.602337] qcom-pcie 1c00000.pci: 1c00000.pci supply vdda not found, using dummy regulator
[    4.603133] qcom-qmp-phy 1da7000.phy: 1da7000.phy supply vdda-phy not found, using dummy regulator
[    4.603301] qcom-qmp-phy 1da7000.phy: 1da7000.phy supply vdda-pll not found, using dummy regulator
[    4.603783] qcom-qmp-phy 1da7000.phy: Registered Qcom-QMP phy
[    4.604882] qcom-qmp-phy c010000.phy: Registered Qcom-QMP phy
[    4.605346] ufshcd-qcom 1da4000.ufshc: ufshcd_populate_vreg: Unable to find vcc-supply regulator, assuming enabled
[    4.608932] qcom-pcie 1c00000.pci: 1c00000.pci supply vddpe-3v3 not found, using dummy regulator
[    4.612522] ufshcd-qcom 1da4000.ufshc: ufshcd_populate_vreg: Unable to find vccq-supply regulator, assuming enabled
[    4.613150] qcom-qusb2-phy c012000.phy: Registered Qcom-QUSB2 phy
[    4.635677] i2c_hid 0-003a: 0-003a supply vdd not found, using dummy regulator
[    4.639563] ufshcd-qcom 1da4000.ufshc: ufshcd_populate_vreg: Unable to find vccq2-supply regulator, assuming enabled
[    4.643709] i2c_hid 0-003a: 0-003a supply vddl not found, using dummy regulator
[    4.651882] qcom-qmp-phy 1c06000.phy: phy initialization timed-out
[    4.656723] phy phy-1c06000.phy.0: phy init failed --> -110
[    4.658103] random: fast init done
[    4.661167] qcom-pcie: probe of 1c00000.pci failed with error -110
[    4.665977] scsi host0: ufshcd
[    4.671075] dwc3 a800000.dwc3: Failed to get clk 'ref': -2
[    4.687298] qcom-qmp-phy 1da7000.phy: phy initialization timed-out
[    4.688740] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[    4.698834] input: hid-over-i2c 04F3:0400 Keyboard as /devices/platform/soc/c17a000.i2c/i2c-0/0-003a/0018:04F3:0400.0001/input/input0
[    4.700059] input: hid-over-i2c 04F3:0400 Consumer Control as /devices/platform/soc/c17a000.i2c/i2c-0/0-003a/0018:04F3:0400.0001/input/input1
[    4.701640] phy phy-1da7000.phy.1: phy poweron failed --> -110
[    4.701649] ufshcd-qcom 1da4000.ufshc: ufs_qcom_power_up_sequence: phy power on failed, ret = -110
[    4.703464] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[    4.703620] xhci-hcd xhci-hcd.0.auto: hcc params 0x0230fe65 hci version 0x110 quirks 0x0000000002010010
[    4.716471] input: hid-over-i2c 04F3:0400 Wireless Radio Control as /devices/platform/soc/c17a000.i2c/i2c-0/0-003a/0018:04F3:0400.0001/input/input2
[    4.720485] xhci-hcd xhci-hcd.0.auto: irq 56, io mem 0x0a800000
[    4.734477] input: hid-over-i2c 04F3:0400 Mouse as /devices/platform/soc/c17a000.i2c/i2c-0/0-003a/0018:04F3:0400.0001/input/input3
[    4.738482] hub 1-0:1.0: USB hub found
[    4.751520] input: hid-over-i2c 04F3:0400 Touchpad as /devices/platform/soc/c17a000.i2c/i2c-0/0-003a/0018:04F3:0400.0001/input/input5
[    4.754437] ufshcd-qcom 1da4000.ufshc: Controller enable failed
[    4.754441] ufshcd-qcom 1da4000.ufshc: Host controller enable failed
[    4.754469] host_regs: 00000000: 1587001f 00000000 00000210 00000000
[    4.754473] host_regs: 00000010: 01000000 00010217 00000000 00000000
[    4.754476] host_regs: 00000020: 00000000 00000000 00000000 00000000
[    4.754480] host_regs: 00000030: 00000008 00000000 00000000 00000000
[    4.754483] host_regs: 00000040: 00000000 00000000 00000000 00000000
[    4.754486] host_regs: 00000050: 00000000 00000000 00000000 00000000
[    4.754489] host_regs: 00000060: 00000000 00000000 00000000 00000000
[    4.754493] host_regs: 00000070: 00000000 00000000 00000000 00000000
[    4.754496] host_regs: 00000080: 00000000 00000000 00000000 00000000
[    4.754499] host_regs: 00000090: 00000000 00000001 00000000 00000000
[    4.754504] ufshcd-qcom 1da4000.ufshc: hba->ufs_version = 0x210, hba->capabilities = 0x1587001f
[    4.754507] ufshcd-qcom 1da4000.ufshc: hba->outstanding_reqs = 0x0, hba->outstanding_tasks = 0x0
[    4.754511] ufshcd-qcom 1da4000.ufshc: last_hibern8_exit_tstamp at 0 us, hibern8_exit_cnt = 0
[    4.754514] ufshcd-qcom 1da4000.ufshc: No record of pa_err errors
[    4.754517] ufshcd-qcom 1da4000.ufshc: No record of dl_err errors
[    4.754521] ufshcd-qcom 1da4000.ufshc: No record of nl_err errors
[    4.754524] ufshcd-qcom 1da4000.ufshc: No record of tl_err errors
[    4.754527] ufshcd-qcom 1da4000.ufshc: No record of dme_err errors
[    4.754530] ufshcd-qcom 1da4000.ufshc: No record of auto_hibern8_err errors
[    4.754533] ufshcd-qcom 1da4000.ufshc: No record of fatal_err errors
[    4.754536] ufshcd-qcom 1da4000.ufshc: No record of link_startup_fail errors
[    4.754540] ufshcd-qcom 1da4000.ufshc: No record of resume_fail errors
[    4.754543] ufshcd-qcom 1da4000.ufshc: No record of suspend_fail errors
[    4.754546] ufshcd-qcom 1da4000.ufshc: No record of dev_reset errors
[    4.754549] ufshcd-qcom 1da4000.ufshc: No record of host_reset errors
[    4.754553] ufshcd-qcom 1da4000.ufshc: No record of task_abort errors
[    4.754557] ufshcd-qcom 1da4000.ufshc: clk: core_clk, rate: 200000000
[    4.754560] ufshcd-qcom 1da4000.ufshc: clk: core_clk_unipro, rate: 150000000
[    4.754575] HCI Vendor Specific Registers 00000000: 000000c8 00000000 00000000 00000000
[    4.754579] HCI Vendor Specific Registers 00000010: 00000000 00000000 00000001 1c00052e
[    4.754582] HCI Vendor Specific Registers 00000020: 3f011300 30010000 00000000 00000000
[    4.754585] HCI Vendor Specific Registers 00000030: 00000000 00000000 00000000 00000000
[    4.754613] UFS_UFS_DBG_RD_REG_OCSC 00000000: 00000000 00000000 00000000 00000000
[    4.754616] UFS_UFS_DBG_RD_REG_OCSC 00000010: 00000000 00000000 00000000 00000000
[    4.754620] UFS_UFS_DBG_RD_REG_OCSC 00000020: 00000000 00000000 00000000 00000000
[    4.754623] UFS_UFS_DBG_RD_REG_OCSC 00000030: 00000000 00000000 00000000 00000000
[    4.754626] UFS_UFS_DBG_RD_REG_OCSC 00000040: 00000000 00000000 00000000 00000000
[    4.754629] UFS_UFS_DBG_RD_REG_OCSC 00000050: 00000000 00000000 00000000 00000000
[    4.754633] UFS_UFS_DBG_RD_REG_OCSC 00000060: 00000000 00000000 00000000 00000000
[    4.754636] UFS_UFS_DBG_RD_REG_OCSC 00000070: 00000000 00000000 00000000 00000000
[    4.754639] UFS_UFS_DBG_RD_REG_OCSC 00000080: 00000000 00000000 00000000 00000000
[    4.754643] UFS_UFS_DBG_RD_REG_OCSC 00000090: 00000000 00000000 00000000 00000000
[    4.754646] UFS_UFS_DBG_RD_REG_OCSC 000000a0: 00000000 00000000 00000000 00000000
[    4.754668] UFS_UFS_DBG_RD_EDTL_RAM 00000000: 00000000 00000000 00000000 00000000
[    4.754671] UFS_UFS_DBG_RD_EDTL_RAM 00000010: 00000000 00000000 00000000 00000000
[    4.754674] UFS_UFS_DBG_RD_EDTL_RAM 00000020: 00000000 00000000 00000000 00000000
[    4.754678] UFS_UFS_DBG_RD_EDTL_RAM 00000030: 00000000 00000000 00000000 00000000
[    4.754681] UFS_UFS_DBG_RD_EDTL_RAM 00000040: 00000000 00000000 00000000 00000000
[    4.754684] UFS_UFS_DBG_RD_EDTL_RAM 00000050: 00000000 00000000 00000000 00000000
[    4.754687] UFS_UFS_DBG_RD_EDTL_RAM 00000060: 00000000 00000000 00000000 00000000
[    4.754691] UFS_UFS_DBG_RD_EDTL_RAM 00000070: 00000000 00000000 00000000 00000000
[    4.754762] UFS_UFS_DBG_RD_DESC_RAM 00000000: 00000000 00000000 00000000 00000000
[    4.754765] UFS_UFS_DBG_RD_DESC_RAM 00000010: 00000000 00000000 00000000 00000000
[    4.754769] UFS_UFS_DBG_RD_DESC_RAM 00000020: 00000000 00000000 00000000 00000000
[    4.754772] UFS_UFS_DBG_RD_DESC_RAM 00000030: 00000000 00000000 00000000 00000000
[    4.754775] UFS_UFS_DBG_RD_DESC_RAM 00000040: 00000000 00000000 00000000 00000000
[    4.754778] UFS_UFS_DBG_RD_DESC_RAM 00000050: 00000000 00000000 00000000 00000000
[    4.754782] UFS_UFS_DBG_RD_DESC_RAM 00000060: 00000000 00000000 00000000 00000000
[    4.754785] UFS_UFS_DBG_RD_DESC_RAM 00000070: 00000000 00000000 00000000 00000000
[    4.754789] UFS_UFS_DBG_RD_DESC_RAM 00000080: 00000000 00000000 00000000 00000000
[    4.754792] UFS_UFS_DBG_RD_DESC_RAM 00000090: 00000000 00000000 00000000 00000000
[    4.754795] UFS_UFS_DBG_RD_DESC_RAM 000000a0: 00000000 00000000 00000000 00000000
[    4.754798] UFS_UFS_DBG_RD_DESC_RAM 000000b0: 00000000 00000000 00000000 00000000
[    4.754802] UFS_UFS_DBG_RD_DESC_RAM 000000c0: 00000000 00000000 00000000 00000000
[    4.754805] UFS_UFS_DBG_RD_DESC_RAM 000000d0: 00000000 00000000 00000000 00000000
[    4.754808] UFS_UFS_DBG_RD_DESC_RAM 000000e0: 00000000 00000000 00000000 00000000
[    4.754812] UFS_UFS_DBG_RD_DESC_RAM 000000f0: 00000000 00000000 00000000 00000000
[    4.754815] UFS_UFS_DBG_RD_DESC_RAM 00000100: 00000000 00000000 00000000 00000000
[    4.754818] UFS_UFS_DBG_RD_DESC_RAM 00000110: 00000000 00000000 00000000 00000000
[    4.754821] UFS_UFS_DBG_RD_DESC_RAM 00000120: 00000000 00000000 00000000 00000000
[    4.754825] UFS_UFS_DBG_RD_DESC_RAM 00000130: 00000000 00000000 00000000 00000000
[    4.754828] UFS_UFS_DBG_RD_DESC_RAM 00000140: 00000000 00000000 00000000 00000000
[    4.754831] UFS_UFS_DBG_RD_DESC_RAM 00000150: 00000000 00000000 00000000 00000000
[    4.754835] UFS_UFS_DBG_RD_DESC_RAM 00000160: 00000000 00000000 00000000 00000000
[    4.754838] UFS_UFS_DBG_RD_DESC_RAM 00000170: 00000000 00000000 00000000 00000000
[    4.754841] UFS_UFS_DBG_RD_DESC_RAM 00000180: 00000000 00000000 00000000 00000000
[    4.754844] UFS_UFS_DBG_RD_DESC_RAM 00000190: 00000000 00000000 00000000 00000000
[    4.754848] UFS_UFS_DBG_RD_DESC_RAM 000001a0: 00000000 00000000 00000000 00000000
[    4.754851] UFS_UFS_DBG_RD_DESC_RAM 000001b0: 00000000 00000000 00000000 00000000
[    4.754854] UFS_UFS_DBG_RD_DESC_RAM 000001c0: 00000000 00000000 00000000 00000000
[    4.754857] UFS_UFS_DBG_RD_DESC_RAM 000001d0: 00000000 00000000 00000000 00000000
[    4.754861] UFS_UFS_DBG_RD_DESC_RAM 000001e0: 00000000 00000000 00000000 00000000
[    4.754864] UFS_UFS_DBG_RD_DESC_RAM 000001f0: 00000000 00000000 00000000 00000000
[    4.754903] UFS_UFS_DBG_RD_PRDT_RAM 00000000: 00000000 00000000 00000000 00000000
[    4.754906] UFS_UFS_DBG_RD_PRDT_RAM 00000010: 00000000 00000000 00000000 00000000
[    4.754909] UFS_UFS_DBG_RD_PRDT_RAM 00000020: 00000000 00000000 00000000 00000000
[    4.754913] UFS_UFS_DBG_RD_PRDT_RAM 00000030: 00000000 00000000 00000000 00000000
[    4.754916] UFS_UFS_DBG_RD_PRDT_RAM 00000040: 00000000 00000000 00000000 00000000
[    4.754919] UFS_UFS_DBG_RD_PRDT_RAM 00000050: 00000000 00000000 00000000 00000000
[    4.754922] UFS_UFS_DBG_RD_PRDT_RAM 00000060: 00000000 00000000 00000000 00000000
[    4.754926] UFS_UFS_DBG_RD_PRDT_RAM 00000070: 00000000 00000000 00000000 00000000
[    4.754929] UFS_UFS_DBG_RD_PRDT_RAM 00000080: 00000000 00000000 00000000 00000000
[    4.754932] UFS_UFS_DBG_RD_PRDT_RAM 00000090: 00000000 00000000 00000000 00000000
[    4.754936] UFS_UFS_DBG_RD_PRDT_RAM 000000a0: 00000000 00000000 00000000 00000000
[    4.754939] UFS_UFS_DBG_RD_PRDT_RAM 000000b0: 00000000 00000000 00000000 00000000
[    4.754942] UFS_UFS_DBG_RD_PRDT_RAM 000000c0: 00000000 00000000 00000000 00000000
[    4.754945] UFS_UFS_DBG_RD_PRDT_RAM 000000d0: 00000000 00000000 00000000 00000000
[    4.754949] UFS_UFS_DBG_RD_PRDT_RAM 000000e0: 00000000 00000000 00000000 00000000
[    4.754952] UFS_UFS_DBG_RD_PRDT_RAM 000000f0: 00000000 00000000 00000000 00000000
[    4.754960] UFS_DBG_RD_REG_UAWM 00000000: 00000000 00000000 00000000 00000000
[    4.754966] UFS_DBG_RD_REG_UARM 00000000: 00000000 00000000 00000000 00000000
[    4.754995] UFS_DBG_RD_REG_TXUC 00000000: 00000000 00000000 00000000 00000000
[    4.754998] UFS_DBG_RD_REG_TXUC 00000010: 00000000 00000000 00000000 00000000
[    4.755001] UFS_DBG_RD_REG_TXUC 00000020: 00000000 00000000 00000000 00000000
[    4.755005] UFS_DBG_RD_REG_TXUC 00000030: 00000000 00000000 00000000 00000000
[    4.755008] UFS_DBG_RD_REG_TXUC 00000040: 00000000 00000000 00000000 00000000
[    4.755011] UFS_DBG_RD_REG_TXUC 00000050: 00000000 00000000 00000000 00000000
[    4.755014] UFS_DBG_RD_REG_TXUC 00000060: 00000000 00000000 00000000 00000000
[    4.755018] UFS_DBG_RD_REG_TXUC 00000070: 00000000 00000000 00000000 00000000
[    4.755021] UFS_DBG_RD_REG_TXUC 00000080: 00000000 00000000 00000000 00000000
[    4.755024] UFS_DBG_RD_REG_TXUC 00000090: 00000000 00000000 00000000 00000000
[    4.755027] UFS_DBG_RD_REG_TXUC 000000a0: 00000000 00000000 00000000 00000000
[    4.755031] UFS_DBG_RD_REG_TXUC 000000b0: 00000000 00000000 00000000 00000000
[    4.755050] UFS_DBG_RD_REG_RXUC 00000000: 00000000 00000000 00000000 00000000
[    4.755053] UFS_DBG_RD_REG_RXUC 00000010: 00000000 00000000 00000000 00000000
[    4.755056] UFS_DBG_RD_REG_RXUC 00000020: 00000000 00000000 00000000 00000000
[    4.755060] UFS_DBG_RD_REG_RXUC 00000030: 00000000 00000000 00000000 00000000
[    4.755063] UFS_DBG_RD_REG_RXUC 00000040: 00000000 00000000 00000000 00000000
[    4.755066] UFS_DBG_RD_REG_RXUC 00000050: 00000000 00000000 00000000 00000000
[    4.755069] UFS_DBG_RD_REG_RXUC 00000060: 00000000 00000000 00000000
[    4.755083] UFS_DBG_RD_REG_DFC 00000000: 00000000 00000000 00000000 00000000
[    4.755086] UFS_DBG_RD_REG_DFC 00000010: 00000000 00000000 00000000 00000000
[    4.755090] UFS_DBG_RD_REG_DFC 00000020: 00000000 00000000 00000000 00000000
[    4.755093] UFS_DBG_RD_REG_DFC 00000030: 00000000 00000000 00000000 00000000
[    4.755096] UFS_DBG_RD_REG_DFC 00000040: 00000000 00000000 00000000
[    4.755117] UFS_DBG_RD_REG_TRLUT 00000000: 00000000 00000000 00000000 00000000
[    4.755121] UFS_DBG_RD_REG_TRLUT 00000010: 00000000 00000000 00000000 00000000
[    4.755124] UFS_DBG_RD_REG_TRLUT 00000020: 00000000 00000000 00000000 00000000
[    4.755127] UFS_DBG_RD_REG_TRLUT 00000030: 00000000 00000000 00000000 00000000
[    4.755130] UFS_DBG_RD_REG_TRLUT 00000040: 00000000 00000000 00000000 00000000
[    4.755134] UFS_DBG_RD_REG_TRLUT 00000050: 00000000 00000000 00000000 00000000
[    4.755137] UFS_DBG_RD_REG_TRLUT 00000060: 00000000 00000000 00000000 00000000
[    4.755140] UFS_DBG_RD_REG_TRLUT 00000070: 00000000 00000000 00000000 00000000
[    4.755143] UFS_DBG_RD_REG_TRLUT 00000080: 00000000 00000000
[    4.755152] UFS_DBG_RD_REG_TMRLUT 00000000: 00000000 00000000 00000000 00000000
[    4.755155] UFS_DBG_RD_REG_TMRLUT 00000010: 00000000 00000000 00000000 00000000
[    4.755157] UFS_DBG_RD_REG_TMRLUT 00000020: 00000000
[    4.755788] hub 1-0:1.0: 1 port detected
[    4.755998] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[    4.756271] UFS_TEST_BUS 00000000
[    4.758775] UNIPRO_TEST_BUS 00000000: 00000000 00000000 00000000 00000000
[    4.758779] UNIPRO_TEST_BUS 00000010: 00000000 00000000 00000000 00000000
[    4.758782] UNIPRO_TEST_BUS 00000020: 00000000 00000000 00000000 00000000
[    4.758785] UNIPRO_TEST_BUS 00000030: 00000000 00000000 00000000 00000000
[    4.758788] UNIPRO_TEST_BUS 00000040: 00000000 00000000 00000000 00000000
[    4.758791] UNIPRO_TEST_BUS 00000050: 00000000 00000000 00000000 00000000
[    4.758794] UNIPRO_TEST_BUS 00000060: 00000000 00000000 00000000 00000000
[    4.758797] UNIPRO_TEST_BUS 00000070: 00000000 00000000 00000000 00000000
[    4.758801] UNIPRO_TEST_BUS 00000080: 00000000 00000000 00000000 00000000
[    4.758804] UNIPRO_TEST_BUS 00000090: 00000000 00000000 00000000 00000000
[    4.758807] UNIPRO_TEST_BUS 000000a0: 00000000 00000000 00000000 00000000
[    4.758810] UNIPRO_TEST_BUS 000000b0: 00000000 00000000 00000000 00000000
[    4.758813] UNIPRO_TEST_BUS 000000c0: 00000000 00000000 00000000 00000000
[    4.758816] UNIPRO_TEST_BUS 000000d0: 00000000 00000000 00000000 00000000
[    4.758820] UNIPRO_TEST_BUS 000000e0: 00000000 00000000 00000000 00000000
[    4.758823] UNIPRO_TEST_BUS 000000f0: 00000000 00000000 00000000 00000000
[    4.758826] UNIPRO_TEST_BUS 00000100: 00000000 00000000 00000000 00000000
[    4.758829] UNIPRO_TEST_BUS 00000110: 00000000 00000000 00000000 00000000
[    4.758832] UNIPRO_TEST_BUS 00000120: 00000000 00000000 00000000 00000000
[    4.758835] UNIPRO_TEST_BUS 00000130: 00000000 00000000 00000000 00000000
[    4.758839] UNIPRO_TEST_BUS 00000140: 00000000 00000000 00000000 00000000
[    4.758842] UNIPRO_TEST_BUS 00000150: 00000000 00000000 00000000 00000000
[    4.758845] UNIPRO_TEST_BUS 00000160: 00000000 00000000 00000000 00000000
[    4.758848] UNIPRO_TEST_BUS 00000170: 00000000 00000000 00000000 00000000
[    4.758851] UNIPRO_TEST_BUS 00000180: 00000000 00000000 00000000 00000000
[    4.758854] UNIPRO_TEST_BUS 00000190: 00000000 00000000 00000000 00000000
[    4.758857] UNIPRO_TEST_BUS 000001a0: 00000000 00000000 00000000 00000000
[    4.758861] UNIPRO_TEST_BUS 000001b0: 00000000 00000000 00000000 00000000
[    4.758864] UNIPRO_TEST_BUS 000001c0: 00000000 00000000 00000000 00000000
[    4.758867] UNIPRO_TEST_BUS 000001d0: 00000000 00000000 00000000 00000000
[    4.758870] UNIPRO_TEST_BUS 000001e0: 00000000 00000000 00000000 00000000
[    4.758873] UNIPRO_TEST_BUS 000001f0: 00000000 00000000 00000000 00000000
[    4.758876] UNIPRO_TEST_BUS 00000200: 00000000 00000000 00000000 00000000
[    4.758879] UNIPRO_TEST_BUS 00000210: 00000000 00000000 00000000 00000000
[    4.758883] UNIPRO_TEST_BUS 00000220: 00000000 00000000 00000000 00000000
[    4.758886] UNIPRO_TEST_BUS 00000230: 00000000 00000000 00000000 00000000
[    4.758889] UNIPRO_TEST_BUS 00000240: 00000000 00000000 00000000 00000000
[    4.758892] UNIPRO_TEST_BUS 00000250: 00000000 00000000 00000000 00000000
[    4.758895] UNIPRO_TEST_BUS 00000260: 00000000 00000000 00000000 00000000
[    4.758898] UNIPRO_TEST_BUS 00000270: 00000000 00000000 00000000 00000000
[    4.758901] UNIPRO_TEST_BUS 00000280: 00000000 00000000 00000000 00000000
[    4.758905] UNIPRO_TEST_BUS 00000290: 00000000 00000000 00000000 00000000
[    4.758908] UNIPRO_TEST_BUS 000002a0: 00000000 00000000 00000000 00000000
[    4.758911] UNIPRO_TEST_BUS 000002b0: 00000000 00000000 00000000 00000000
[    4.758914] UNIPRO_TEST_BUS 000002c0: 00000000 00000000 00000000 00000000
[    4.758917] UNIPRO_TEST_BUS 000002d0: 00000000 00000000 00000000 00000000
[    4.758920] UNIPRO_TEST_BUS 000002e0: 00000000 00000000 00000000 00000000
[    4.758923] UNIPRO_TEST_BUS 000002f0: 00000000 00000000 00000000 00000000
[    4.758926] UNIPRO_TEST_BUS 00000300: 00000000 00000000 00000000 00000000
[    4.758930] UNIPRO_TEST_BUS 00000310: 00000000 00000000 00000000 00000000
[    4.758933] UNIPRO_TEST_BUS 00000320: 00000000 00000000 00000000 00000000
[    4.758936] UNIPRO_TEST_BUS 00000330: 00000000 00000000 00000000 00000000
[    4.758939] UNIPRO_TEST_BUS 00000340: 00000000 00000000 00000000 00000000
[    4.758942] UNIPRO_TEST_BUS 00000350: 00000000 00000000 00000000 00000000
[    4.758945] UNIPRO_TEST_BUS 00000360: 00000000 00000000 00000000 00000000
[    4.758948] UNIPRO_TEST_BUS 00000370: 00000000 00000000 00000000 00000000
[    4.758952] UNIPRO_TEST_BUS 00000380: 00000000 00000000 00000000 00000000
[    4.758955] UNIPRO_TEST_BUS 00000390: 00000000 00000000 00000000 00000000
[    4.758958] UNIPRO_TEST_BUS 000003a0: 00000000 00000000 00000000 00000000
[    4.758961] UNIPRO_TEST_BUS 000003b0: 00000000 00000000 00000000 00000000
[    4.758964] UNIPRO_TEST_BUS 000003c0: 00000000 00000000 00000000 00000000
[    4.758967] UNIPRO_TEST_BUS 000003d0: 00000000 00000000 00000000 00000000
[    4.758970] UNIPRO_TEST_BUS 000003e0: 00000000 00000000 00000000 00000000
[    4.758974] UNIPRO_TEST_BUS 000003f0: 00000000 00000000 00000000 00000000
[    4.760087] ufshcd-qcom 1da4000.ufshc: UFS Host state=0
[    4.760091] ufshcd-qcom 1da4000.ufshc: lrb in use=0x0, outstanding reqs=0x0 tasks=0x0
[    4.760095] ufshcd-qcom 1da4000.ufshc: saved_err=0x0, saved_uic_err=0x0
[    4.760098] ufshcd-qcom 1da4000.ufshc: Device power mode=0, UIC link state=0
[    4.760101] ufshcd-qcom 1da4000.ufshc: PM in progress=0, sys. suspended=0
[    4.760104] ufshcd-qcom 1da4000.ufshc: Auto BKOPS=0, Host self-block=0
[    4.760107] ufshcd-qcom 1da4000.ufshc: Clk gate=1
[    4.760110] ufshcd-qcom 1da4000.ufshc: error handling flags=0x0, req. abort count=0
[    4.760113] ufshcd-qcom 1da4000.ufshc: Host capabilities=0x1587001f, caps=0xf
[    4.760116] ufshcd-qcom 1da4000.ufshc: quirks=0x0, dev. quirks=0x0
[    4.761007] ufshcd-qcom 1da4000.ufshc: Initialization failed
[    4.769802] hid-generic 0018:04F3:0400.0001: input: I2C HID v1.00 Keyboard [hid-over-i2c 04F3:0400] on 0-003a
[    4.774384] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[    4.774396] xhci-hcd xhci-hcd.0.auto: Host supports USB 3.0 SuperSpeed
[    4.774445] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[    4.774991] hub 2-0:1.0: USB hub found
[    5.090531] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[    5.093425] hub 2-0:1.0: 1 port detected
[    5.099329] ufshcd-qcom 1da4000.ufshc: ufshcd_pltfrm_init() failed -5
[    5.279185] ufshcd-qcom: probe of 1da4000.ufshc failed with error -5
[    5.415282] hub 1-1:1.0: USB hub found
[    5.417674] hub 1-1:1.0: 4 ports detected
[    5.510743] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[    5.639544] hub 2-1:1.0: USB hub found
[    5.645748] hub 2-1:1.0: 4 ports detected
[    6.190442] usb 1-1.1: new high-speed USB device number 3 using xhci-hcd
[    6.406883] hub 1-1.1:1.0: USB hub found
[    6.409267] hub 1-1.1:1.0: 4 ports detected
[    6.430919] usb 2-1.4: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[    6.456113] usb-storage 2-1.4:1.0: USB Mass Storage device detected
[    6.459830] scsi host0: usb-storage 2-1.4:1.0
[    6.586345] usb 1-1.2: new high-speed USB device number 4 using xhci-hcd
[    6.922539] usb 1-1.1.2: new high-speed USB device number 5 using xhci-hcd
[    6.958439] raid6: neonx8   gen()   825 MB/s
[    7.030390] raid6: neonx8   xor()   677 MB/s
[    7.102402] raid6: neonx4   gen()   884 MB/s
[    7.178757] raid6: neonx4   xor()   748 MB/s
[    7.216137] hid-generic 0003:2109:D101.0002: device has no listeners, quitting
[    7.254422] raid6: neonx2   gen()   642 MB/s
[    7.330862] raid6: neonx2   xor()   633 MB/s
[    7.406286] raid6: neonx1   gen()   472 MB/s
[    7.482262] raid6: neonx1   xor()   442 MB/s
[    7.495968] scsi 0:0:0:0: Direct-Access     SanDisk  Extreme          0001 PQ: 0 ANSI: 6
[    7.558264] raid6: int64x8  gen()   388 MB/s
[    7.634221] raid6: int64x8  xor()   215 MB/s
[    7.710346] raid6: int64x4  gen()   393 MB/s
[    7.748772] sd 0:0:0:0: [sda] 122552320 512-byte logical blocks: (62.7 GB/58.4 GiB)
[    7.752796] sd 0:0:0:0: [sda] Write Protect is off
[    7.756304] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[    7.760343] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    7.786280] raid6: int64x4  xor()   227 MB/s
[    7.862382] raid6: int64x2  gen()   347 MB/s
[    7.938285] raid6: int64x2  xor()   204 MB/s
[    8.014387] raid6: int64x1  gen()   289 MB/s
[    8.090368] raid6: int64x1  xor()   163 MB/s
[    8.100395] raid6: using algorithm neonx4 gen() 884 MB/s
[    8.110785] raid6: .... xor() 748 MB/s, rmw enabled
[    8.121004]  sda: sda1 sda2
[    8.121054] raid6: using neon recovery algorithm
[    8.128446] sd 0:0:0:0: [sda] Attached SCSI removable disk
[    8.146696] xor: measuring software checksum speed
[    8.194221]    8regs     :  1021.000 MB/sec
[    8.242218]    32regs    :  1185.000 MB/sec
[    8.290565]    arm64_neon:   962.000 MB/sec
[    8.301584] xor: using function: 32regs (1185.000 MB/sec)
[    8.404812] Btrfs loaded, crc32c=crc32c-generic
[    8.772275] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[    9.426284] systemd[1]: System time before build time, advancing clock.
[    9.555696] NET: Registered protocol family 10
[    9.570483] Segment Routing with IPv6
[    9.616081] efivars: get_next_variable: status=8000000000000003
[    9.654342] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[    9.683471] systemd[1]: Detected architecture arm64.
[    9.774402] systemd[1]: Set hostname to <8998mtp>.
[    9.799640] systemd[1]: Couldn't move remaining userspace processes, ignoring: Input/output error
[   10.326610] systemd[1]: File /lib/systemd/system/systemd-journald.service:36 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.
[   10.332170] systemd[1]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)
[   10.478988] systemd[1]: Configuration file /usr/local/lib/systemd/system/qrtr-ns.service is marked executable. Please remove executable permission bits. Proceeding anyway.
[   10.624682] random: systemd: uninitialized urandom read (16 bytes read)
[   10.630762] systemd[1]: Listening on Journal Socket.
[   10.642473] random: systemd: uninitialized urandom read (16 bytes read)
[   10.648319] systemd[1]: Listening on udev Kernel Socket.
[   10.659869] random: systemd: uninitialized urandom read (16 bytes read)
[   10.665808] systemd[1]: Listening on Journal Socket (/dev/log).
[   10.783973] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[   11.070227] Adding 312700k swap on /swapfile.  Priority:-2 extents:2 across:320892k
[   11.114678] random: crng init done
[   11.130807] random: 7 urandom warning(s) missed due to ratelimiting
[   11.224764] systemd-journald[520]: Received request to flush runtime journal from PID 1
[   11.253062] systemd-journald[520]: File /var/log/journal/b5ff3368aa8b4fde8d460a2dcdaec32c/system.journal corrupted or uncleanly shut down, renaming and replacing.
[   12.142343] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[   12.164502] NET: Registered protocol family 42
[   12.173218] remoteproc remoteproc0: 4080000.remoteproc is available
[   12.183935] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   12.345490] ath10k_snoc 18800000.wifi: Adding to iommu group 0
[   12.920693] asix 1-1.2:1.0 eth0: register 'asix' at usb-xhci-hcd.0.auto-1.2, ASIX AX88772 USB 2.0 Ethernet, 00:50:b6:0b:c9:33
[   12.926562] usbcore: registered new interface driver asix
[   12.948568] asix 1-1.2:1.0 enx0050b60bc933: renamed from eth0
[   14.054443] remoteproc remoteproc0: powering up 4080000.remoteproc
[   14.149989] remoteproc remoteproc0: Booting fw image qcom/LENOVO/81F1/qcdsp1v28998.mbn, size 230056
[   15.532360] IPv6: ADDRCONF(NETDEV_CHANGE): enx0050b60bc933: link becomes ready
[   15.548608] asix 1-1.2:1.0 enx0050b60bc933: link up, 100Mbps, full-duplex, lpa 0xCDE1
[   15.762278] qcom-q6v5-mss 4080000.remoteproc: MBA booted, loading mpss
[   16.893719] remoteproc remoteproc0: remote processor 4080000.remoteproc is now up

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[cang]

On 2019-12-18 00:00, Jeffrey Hugo wrote:
> On Tue, Dec 17, 2019 at 8:08 AM Vinod Koul <vkoul@kernel.org> wrote:
>> 
>> On 17-12-19, 18:09, cang@codeaurora.org wrote:
>> > On 2019-12-17 17:24, Vinod Koul wrote:
>> > > Hi Can,
>> > >
>> > > On 17-12-19, 15:10, cang@codeaurora.org wrote:
>> > > > On 2019-12-17 12:13, Vinod Koul wrote:
>> > > > > Hi Can,
>> > > > >
>> > > > > On 17-12-19, 08:37, cang@codeaurora.org wrote:
>> > > > > > On 2019-12-17 03:12, Jeffrey Hugo wrote:
>> > > > > > > On Mon, Dec 16, 2019 at 12:05 PM Vinod Koul <vkoul@kernel.org> wrote:
>> > > > > > > >
>> > > > > > > > Hi Can,
>> > > > > > > >
>> > > > > > > > On 14-11-19, 22:09, Can Guo wrote:
>> > > > > > > > > Add reset control for host controller so that host controller can be reset
>> > > > > > > > > as required in its power up sequence.
>> > > > > > > >
>> > > > > > > > I am seeing a regression on UFS on SM8150-mtp with this patch. I think
>> > > > > > > > Jeff is seeing same one lenove laptop on 8998.
>> > > > > > >
>> > > > > > > Confirmed.
>> > > > > > >
>> > > > > > > >
>> > > > > > > > 845 does not seem to have this issue and only thing I can see is
>> > > > > > > > that on
>> > > > > > > > sm8150 and 8998 we define reset as:
>> > > > > > > >
>> > > > > > > >                         resets = <&gcc GCC_UFS_BCR>;
>> > > > > > > >                         reset-names = "rst";
>> > > > > > > >
>> > > > > >
>> > > > > > Hi Jeffrey and Vinod,
>> > > > > >
>> > > > > > Thanks for reporting this. May I know what kind of regression do you
>> > > > > > see on
>> > > > > > 8150 and 8998?
>> > > > > > BTW, do you have reset control for UFS PHY in your DT?
>> > > > > > See 71278b058a9f8752e51030e363b7a7306938f64e.
>> > > > > >
>> > > > > > FYI, we use reset control on all of our platforms and it is
>> > > > > > a must during our power up sequence.
>> > > > >
>> > > > > Yes we do have this and additionally both the DTS describe a 'rst' reset
>> > > > > and this patch tries to use this.
>> > > > >
>> > > > > Can you please tell me which platform this was tested on how the reset
>> > > > > was described in DT
>> > > > >
>> > > > > Thanks
>> > > >
>> > > > Hi Vinod,
>> > > >
>> > > > If you are using the 8998's DT present on upstream, you may also
>> > > > need to
>> > > > enable
>> > > > device reset on your platform. (We usually do a device reset before
>> > > > call
>> > > > ufshcd_hba_enable())
>> > > > Given that 845 works fine, it may be the difference you have with
>> > > > 845. 845
>> > > > has device
>> > > > reset support ready in upstream code, you can check sdm845-mtp.dts.
>> > > > It is same for 8150, which is a lack of device reset support in
>> > > > upstream
>> > > > code base.
>> > >
>> > > I am using 8150mtp and you can see the DTS at [1]
>> > > with this patch I get phy timeout error
>> > >
>> > > [    2.532594] qcom-qmp-phy 1d87000.phy: phy initialization timed-out
>> > >
>> > > If i revert this patch the Timeout goes away. UFS node for this platform
>> > > is enabled in [2] and [3]
>> > >
>> > > I did add the GPIO as well for testing but that doesnt work, only thing
>> > > that makes it work is rename the reset line to something other that
>> > > 'rst'
>> > >
>> > > I found that with this patch the reset is invoked twice, not sure why!
>> > >
>> > > The 845 does not define a reset 'rst' but both 8150 and 8998 define
>> > > that!
>> > >
>> > > [1]:
>> > > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h=for-next
>> > > [2]:
>> > > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3834a2e92229ef26d30de28acb698b2b23d3e397
>> > > [3]:
>> > > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3e5bf28d2c3981f949e848eec8a60e0b9b61189d
>> > > >
>> > > > To enable UFS device reset, please see
>> > > > 1. https://lore.kernel.org/linux-arm-msm/20190828191756.24312-4-bjorn.andersson@linaro.org/
>> > > > 2. 53a5372ce326116f3e3d3f1d701113b2542509f4
>> > >
>> > > Yes both are added for UFS and I am testing with these..
>> > > >
>> > > > FYI, I tested the patch on 8250 and its family platforms. In my
>> > > > build, I
>> > > > ported
>> > > > change in #2 to my code base (in your case, make change to
>> > > > drivers/pinctrl/qcom/pinctrl-msm8998.c) and enable the GPIO in DT like
>> > > > sdm845-mtp.dts
>> > >
>> > > Please see drivers/pinctrl/qcom/pinctrl-sm8150.c upstream
>> > >
>> > > >         reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>;
>> > >
>> > > Yup, added:
>> > >
>> > >         reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
>> >
>> > Hi Vinod,
>> >
>> > What do you mean by the reset is invoked twice?
>> >
>> > Renaming 'rst' to something else equals disabling this patch.
>> >
>> > You said 845 has not this problem, I thought you tested the patch on 845
>> > with
>> > the same 'rst' defined on 8998 and 8150. If 'rst' is not present in 845's
>> > DT,
>> > it means this patch has no impact on 845.
>> 
>> To clarify: This problem is not seen in 845 with upstream kernel ie
>> 5.5-rc1 but regression is observed in sm8150 and 8998 (Jeff)
>> 
>> And if I add the reset line to 845 (i am testing on dragon board
>> RB3, I am seeing same issue here as well)
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -1374,6 +1374,8 @@
>>                         lanes-per-direction = <2>;
>>                         power-domains = <&gcc UFS_PHY_GDSC>;
>>                         #reset-cells = <1>;
>> +                       resets = <&gcc GCC_UFS_PHY_BCR>;
>> +                       reset-names = "rst";
>> 
>>                         iommus = <&apps_smmu 0x100 0xf>;
>> 
>> 
>> And on boot i am seeing UFS failing:
>> 
>> [    3.205567] qcom-qmp-phy 88eb000.phy: Registered Qcom-QMP phy
>> [    3.215440] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable 
>> to find vdd-hba-supply regulator, assuming enabled
>> [    3.226315] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable 
>> to find vccq-supply regulator, assuming enabled
>> [    3.236844] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: Unable 
>> to find vccq2-supply regulator, assuming enabled
>> [    3.257053] scsi host0: ufshcd
>> [    3.275109] qcom-qmp-phy 1d87000.phy: phy initialization timed-out
>> [    3.283677] qcom_rpmh TCS Busy, retrying RPMH message send: 
>> addr=0x40904
>> [    3.290508] phy phy-1d87000.phy.0: phy poweron failed --> -110
>> [    3.296407] ufshcd-qcom 1d84000.ufshc: ufs_qcom_power_up_sequence: 
>> phy power on failed, ret = -110
>> [    3.360851] ufshcd-qcom 1d84000.ufshc: Controller enable failed
>> [    3.366838] ufshcd-qcom 1d84000.ufshc: Host controller enable 
>> failed
>> 
>> > Actually, in our code base, we are not using phy-qcom-qmp.c. Instead,
>> > we are using phy-qcom-ufs.c. phy-qcom-ufs.c is the one we use in all of our
>> > mobile projects. Although both have the same functionality,
>> > but in phy-qcom-ufs.c, the PCS ready bit polling timeout is 1000000us,
>> > while in phy-qcom-qmp.c the PCS ready bit polling timeout is 1000us.
>> > Would you mind give below change a try?
>> 
>> Sure and this seems to do the trick on 845 with resets defined, Jeff 
>> can
>> you try this on your laptop
> 
> I'm attaching a complete log of the failure I see.
> 
> Increasing PHY_INIT_COMPLETE_TIMEOUT to the indicated value appears to
> fix the issue for me.
> 
>> 
>> But I dont get same result on sm8150-mtp, i am still seeing timeout 
>> with
>> 1000000us.
>> 
>> The bigger question is why is the reset causing the timeout to be
>> increased for sdm845 and not to work in case of sm8150!
>> 
>> > FYI, I tried the opposite change on my board (decrease the PCS polling
>> > timeout
>> > used in phy-qcom-ufs.c), I did see PCS polling timeout, which is the same
>> > failure
>> > you encountered.
>> >
>> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
>> > b/drivers/phy/qualcomm/phy-qcom-qmp.c
>> > index 39e8deb..0ee9149 100644
>> > --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
>> > +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
>> > @@ -66,7 +66,7 @@
>> >  /* QPHY_V3_PCS_MISC_CLAMP_ENABLE register bits */
>> >  #define CLAMP_EN                               BIT(0) /* enables i/o
>> > clamp_n */
>> >
>> > -#define PHY_INIT_COMPLETE_TIMEOUT              1000
>> > +#define PHY_INIT_COMPLETE_TIMEOUT              1000000
>> >  #define POWER_DOWN_DELAY_US_MIN                        10
>> >  #define POWER_DOWN_DELAY_US_MAX                        11
>> >
>> > On 845, if there is 'rst'
>> >
>> > Thanks.
>> 
>> --
>> ~Vinod

Hi Vinod and Jeffrey,

Let me summary here, now the 1000000us timeout works for both 845 and 
8998.
However, 8150 still fails.

>> The bigger question is why is the reset causing the timeout to be
>> increased for sdm845 and not to work in case of sm8150! (Vinod)

I would not say this patch increases the timeout. With this patch,
the PCS polling timeout, per my profiling, the PCS ready usually needs
less than 5000us, which is the actual time needed for PCS bit to be 
ready.

The reason why 1000us worked for you is because, w/o the patch, UFS PHY
registers are retained from pre-kernel stage (bootloader i.e.), the PCS 
ready
bit was set to 1 in pre-kernel stage, so when kernel driver reads it, it 
returns
1, not even to be polled at all. It may seem "faster", but not the right
thing to do, because kernel stage may need different PHY settings than
pre-kernel stage, keeping the settings configured in pre-kernel stage is 
not
always right, so this patch is needed. And increasing 1000us to 
1000000us
is the right thing to do, but not a hack.

As reg for the phy initialization timeout on 8150, I found there is 
something
wrong with its settings in /drivers/phy/qualcomm/phy-qcom-qmp.c

static const struct qmp_phy_init_tbl sm8150_ufsphy_serdes_tbl[] = {
	QMP_PHY_INIT_CFG(QPHY_POWER_DOWN_CONTROL, 0x01),
	QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0xd9),

"QMP_PHY_INIT_CFG(QPHY_POWER_DOWN_CONTROL, 0x01)" should NOT appear in 
the serdes
table! I haven't check who made this change, but please have a try after 
remove
this line from sm8150_ufsphy_serdes_tbl.

Thanks.
Can Guo.

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Vinod Koul]

On 18-12-19, 02:44, cang@codeaurora.org wrote:
 
> Hi Vinod and Jeffrey,
> 
> Let me summary here, now the 1000000us timeout works for both 845 and 8998.
> However, 8150 still fails.
> 
> > > The bigger question is why is the reset causing the timeout to be
> > > increased for sdm845 and not to work in case of sm8150! (Vinod)
> 
> I would not say this patch increases the timeout. With this patch,
> the PCS polling timeout, per my profiling, the PCS ready usually needs
> less than 5000us, which is the actual time needed for PCS bit to be ready.
> 
> The reason why 1000us worked for you is because, w/o the patch, UFS PHY
> registers are retained from pre-kernel stage (bootloader i.e.), the PCS
> ready
> bit was set to 1 in pre-kernel stage, so when kernel driver reads it, it
> returns
> 1, not even to be polled at all. It may seem "faster", but not the right
> thing to do, because kernel stage may need different PHY settings than
> pre-kernel stage, keeping the settings configured in pre-kernel stage is not
> always right, so this patch is needed. And increasing 1000us to 1000000us
> is the right thing to do, but not a hack.
> 
> As reg for the phy initialization timeout on 8150, I found there is
> something
> wrong with its settings in /drivers/phy/qualcomm/phy-qcom-qmp.c
> 
> static const struct qmp_phy_init_tbl sm8150_ufsphy_serdes_tbl[] = {
> 	QMP_PHY_INIT_CFG(QPHY_POWER_DOWN_CONTROL, 0x01),
> 	QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0xd9),
> 
> "QMP_PHY_INIT_CFG(QPHY_POWER_DOWN_CONTROL, 0x01)" should NOT appear in the
> serdes
> table! I haven't check who made this change, but please have a try after
> remove
> this line from sm8150_ufsphy_serdes_tbl.

That is me :) Looks like I made an error while porting from downstream. I
did a quick check to remove this and it doesn't work yet, let me recheck
the settings again ...

Thanks for your help!

-- 
~Vinod

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[cang]

On 2019-12-18 12:12, Vinod Koul wrote:
> On 18-12-19, 02:44, cang@codeaurora.org wrote:
> 
>> Hi Vinod and Jeffrey,
>> 
>> Let me summary here, now the 1000000us timeout works for both 845 and 
>> 8998.
>> However, 8150 still fails.
>> 
>> > > The bigger question is why is the reset causing the timeout to be
>> > > increased for sdm845 and not to work in case of sm8150! (Vinod)
>> 
>> I would not say this patch increases the timeout. With this patch,
>> the PCS polling timeout, per my profiling, the PCS ready usually needs
>> less than 5000us, which is the actual time needed for PCS bit to be 
>> ready.
>> 
>> The reason why 1000us worked for you is because, w/o the patch, UFS 
>> PHY
>> registers are retained from pre-kernel stage (bootloader i.e.), the 
>> PCS
>> ready
>> bit was set to 1 in pre-kernel stage, so when kernel driver reads it, 
>> it
>> returns
>> 1, not even to be polled at all. It may seem "faster", but not the 
>> right
>> thing to do, because kernel stage may need different PHY settings than
>> pre-kernel stage, keeping the settings configured in pre-kernel stage 
>> is not
>> always right, so this patch is needed. And increasing 1000us to 
>> 1000000us
>> is the right thing to do, but not a hack.
>> 
>> As reg for the phy initialization timeout on 8150, I found there is
>> something
>> wrong with its settings in /drivers/phy/qualcomm/phy-qcom-qmp.c
>> 
>> static const struct qmp_phy_init_tbl sm8150_ufsphy_serdes_tbl[] = {
>> 	QMP_PHY_INIT_CFG(QPHY_POWER_DOWN_CONTROL, 0x01),
>> 	QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0xd9),
>> 
>> "QMP_PHY_INIT_CFG(QPHY_POWER_DOWN_CONTROL, 0x01)" should NOT appear in 
>> the
>> serdes
>> table! I haven't check who made this change, but please have a try 
>> after
>> remove
>> this line from sm8150_ufsphy_serdes_tbl.
> 
> That is me :) Looks like I made an error while porting from downstream. 
> I
> did a quick check to remove this and it doesn't work yet, let me 
> recheck
> the settings again ...
> 
> Thanks for your help!

Hi Vinod,

Indeed, you need to tweak your settings. I spent some time help you
figure this out. Try below change and please let me know if it can
resolve your problem.

I would not say this is a regression caused by my patch, it is just
my patch reveals something incorrect in the settings.

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 8e642a6..0cc9044 100755
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -66,7 +66,7 @@
  /* QPHY_V3_PCS_MISC_CLAMP_ENABLE register bits */
  #define CLAMP_EN                               BIT(0) /* enables i/o 
clamp_n */

-#define PHY_INIT_COMPLETE_TIMEOUT              1000
+#define PHY_INIT_COMPLETE_TIMEOUT              1000000
  #define POWER_DOWN_DELAY_US_MIN                        10
  #define POWER_DOWN_DELAY_US_MAX                        11

@@ -166,6 +166,7 @@ static const unsigned int 
sdm845_ufsphy_regs_layout[] = {
  };

  static const unsigned int sm8150_ufsphy_regs_layout[] = {
+       [QPHY_SW_RESET]                 = 0x08,
         [QPHY_START_CTRL]               = 0x00,
         [QPHY_PCS_READY_STATUS]         = 0x180,
  };
@@ -885,7 +886,6 @@ static const struct qmp_phy_init_tbl 
msm8998_usb3_pcs_tbl[] = {
  };

  static const struct qmp_phy_init_tbl sm8150_ufsphy_serdes_tbl[] = {
-       QMP_PHY_INIT_CFG(QPHY_POWER_DOWN_CONTROL, 0x01),
         QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0xd9),
         QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x11),
         QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_HS_SWITCH_SEL, 0x00),
@@ -1390,7 +1390,6 @@ static const struct qmp_phy_cfg sm8150_ufsphy_cfg 
= {
         .pwrdn_ctrl             = SW_PWRDN,

         .is_dual_lane_phy       = true,
-       .no_pcs_sw_reset        = true,
  };

  static void qcom_qmp_phy_configure(void __iomem *base,
---

Aside of the phy settings, your DT needs some modifications too,
seems you copied most of them from sdm845.
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3834a2e92229ef26d30de28acb698b2b23d3e397

<--snip-->
> +		ufs_mem_phy: phy@1d87000 {
> +			compatible = "qcom,sm8150-qmp-ufs-phy";
> +			reg = <0 0x01d87000 0 0x18c>;

The size 0x18c is wrong, in the code you are even accessing registers
whose offsets are beyond 0x18c, see

#define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE0	0x1ac
#define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE0	0x1b0
#define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE1	0x1b4
#define QSERDES_V4_COM_BIN_VCOCAL_HSCLK_SEL		0x1bc
#define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE1	0x1b8

FYI, the total size of serdes registers is 0x1c0.

<--snip-->
> +			ufs_mem_phy_lanes: lanes@1d87400 {
> +				reg = <0 0x01d87400 0 0x108>,
> +				      <0 0x01d87600 0 0x1e0>,
> +				      <0 0x01d87c00 0 0x1dc>,

Same as above, see

#define QPHY_V4_MULTI_LANE_CTRL1			0x1e0

FYI, the total size of PCS registers is 0x200

> +				      <0 0x01d87800 0 0x108>,
> +				      <0 0x01d87a00 0 0x1e0>;
> +				#phy-cells = <0>;
> +			};
<--snip-->

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Vinod Koul]

On 19-12-19, 15:12, cang@codeaurora.org wrote:
> On 2019-12-18 12:12, Vinod Koul wrote:
> > On 18-12-19, 02:44, cang@codeaurora.org wrote:

> 
> Aside of the phy settings, your DT needs some modifications too,
> seems you copied most of them from sdm845.
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3834a2e92229ef26d30de28acb698b2b23d3e397
> 
> <--snip-->
> > +		ufs_mem_phy: phy@1d87000 {
> > +			compatible = "qcom,sm8150-qmp-ufs-phy";
> > +			reg = <0 0x01d87000 0 0x18c>;
> 
> The size 0x18c is wrong, in the code you are even accessing registers
> whose offsets are beyond 0x18c, see
> 
> #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE0	0x1ac
> #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE0	0x1b0
> #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE1	0x1b4
> #define QSERDES_V4_COM_BIN_VCOCAL_HSCLK_SEL		0x1bc
> #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE1	0x1b8
> 
> FYI, the total size of serdes registers is 0x1c0.

Yeah I will update it to 0x1c0

> 
> <--snip-->
> > +			ufs_mem_phy_lanes: lanes@1d87400 {
> > +				reg = <0 0x01d87400 0 0x108>,
> > +				      <0 0x01d87600 0 0x1e0>,
> > +				      <0 0x01d87c00 0 0x1dc>,
> 
> Same as above, see
> 
> #define QPHY_V4_MULTI_LANE_CTRL1			0x1e0
> 
> FYI, the total size of PCS registers is 0x200
> 
> > +				      <0 0x01d87800 0 0x108>,
> > +				      <0 0x01d87a00 0 0x1e0>;
> > +				#phy-cells = <0>;
> > +			};
> <--snip-->

So I managed to fix it by configuring QPHY_SW_RESET in
qcom_qmp_phy_com_init() before invoking the configuration. That makes it
work for me. Will send patches shortly

-- 
~Vinod

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Jeffrey Hugo]

On Thu, Dec 19, 2019 at 7:21 AM Vinod Koul <vkoul@kernel.org> wrote:
>
> On 19-12-19, 15:12, cang@codeaurora.org wrote:
> > On 2019-12-18 12:12, Vinod Koul wrote:
> > > On 18-12-19, 02:44, cang@codeaurora.org wrote:
>
> >
> > Aside of the phy settings, your DT needs some modifications too,
> > seems you copied most of them from sdm845.
> > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3834a2e92229ef26d30de28acb698b2b23d3e397
> >
> > <--snip-->
> > > +           ufs_mem_phy: phy@1d87000 {
> > > +                   compatible = "qcom,sm8150-qmp-ufs-phy";
> > > +                   reg = <0 0x01d87000 0 0x18c>;
> >
> > The size 0x18c is wrong, in the code you are even accessing registers
> > whose offsets are beyond 0x18c, see
> >
> > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE0     0x1ac
> > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE0     0x1b0
> > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE1     0x1b4
> > #define QSERDES_V4_COM_BIN_VCOCAL_HSCLK_SEL           0x1bc
> > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE1     0x1b8
> >
> > FYI, the total size of serdes registers is 0x1c0.
>
> Yeah I will update it to 0x1c0
>
> >
> > <--snip-->
> > > +                   ufs_mem_phy_lanes: lanes@1d87400 {
> > > +                           reg = <0 0x01d87400 0 0x108>,
> > > +                                 <0 0x01d87600 0 0x1e0>,
> > > +                                 <0 0x01d87c00 0 0x1dc>,
> >
> > Same as above, see
> >
> > #define QPHY_V4_MULTI_LANE_CTRL1                      0x1e0
> >
> > FYI, the total size of PCS registers is 0x200
> >
> > > +                                 <0 0x01d87800 0 0x108>,
> > > +                                 <0 0x01d87a00 0 0x1e0>;
> > > +                           #phy-cells = <0>;
> > > +                   };
> > <--snip-->
>
> So I managed to fix it by configuring QPHY_SW_RESET in
> qcom_qmp_phy_com_init() before invoking the configuration. That makes it
> work for me. Will send patches shortly

So, you are going to send some fixes to make sm8150 work.  We also
need the extended timeout for all platforms, yes?  Who is going to
send up the patch for the timeout?  All of this should be -rc material
since Can's change caused these issues to appear, and thus impact
users, no?

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[Vinod Koul]

On 19-12-19, 07:25, Jeffrey Hugo wrote:
> On Thu, Dec 19, 2019 at 7:21 AM Vinod Koul <vkoul@kernel.org> wrote:
> >
> > On 19-12-19, 15:12, cang@codeaurora.org wrote:
> > > On 2019-12-18 12:12, Vinod Koul wrote:
> > > > On 18-12-19, 02:44, cang@codeaurora.org wrote:
> >
> > >
> > > Aside of the phy settings, your DT needs some modifications too,
> > > seems you copied most of them from sdm845.
> > > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3834a2e92229ef26d30de28acb698b2b23d3e397
> > >
> > > <--snip-->
> > > > +           ufs_mem_phy: phy@1d87000 {
> > > > +                   compatible = "qcom,sm8150-qmp-ufs-phy";
> > > > +                   reg = <0 0x01d87000 0 0x18c>;
> > >
> > > The size 0x18c is wrong, in the code you are even accessing registers
> > > whose offsets are beyond 0x18c, see
> > >
> > > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE0     0x1ac
> > > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE0     0x1b0
> > > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE1     0x1b4
> > > #define QSERDES_V4_COM_BIN_VCOCAL_HSCLK_SEL           0x1bc
> > > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE1     0x1b8
> > >
> > > FYI, the total size of serdes registers is 0x1c0.
> >
> > Yeah I will update it to 0x1c0
> >
> > >
> > > <--snip-->
> > > > +                   ufs_mem_phy_lanes: lanes@1d87400 {
> > > > +                           reg = <0 0x01d87400 0 0x108>,
> > > > +                                 <0 0x01d87600 0 0x1e0>,
> > > > +                                 <0 0x01d87c00 0 0x1dc>,
> > >
> > > Same as above, see
> > >
> > > #define QPHY_V4_MULTI_LANE_CTRL1                      0x1e0
> > >
> > > FYI, the total size of PCS registers is 0x200
> > >
> > > > +                                 <0 0x01d87800 0 0x108>,
> > > > +                                 <0 0x01d87a00 0 0x1e0>;
> > > > +                           #phy-cells = <0>;
> > > > +                   };
> > > <--snip-->
> >
> > So I managed to fix it by configuring QPHY_SW_RESET in
> > qcom_qmp_phy_com_init() before invoking the configuration. That makes it
> > work for me. Will send patches shortly
> 
> So, you are going to send some fixes to make sm8150 work.  We also
> need the extended timeout for all platforms, yes?  Who is going to
> send up the patch for the timeout?  All of this should be -rc material
> since Can's change caused these issues to appear, and thus impact
> users, no?

yeah I have tested a timeout of 10ms and seems to look good for me on
sm8150 and sdm845. I will be sending the patches in few minutes :) and
yes the timeout should be marked to 5.5 fixes

Thanks
-- 
~Vinod

Re: [PATCH v5 2/7] scsi: ufs-qcom: Add reset control support for host controller

[cang]

On 2019-12-19 22:52, Vinod Koul wrote:
> On 19-12-19, 07:25, Jeffrey Hugo wrote:
>> On Thu, Dec 19, 2019 at 7:21 AM Vinod Koul <vkoul@kernel.org> wrote:
>> >
>> > On 19-12-19, 15:12, cang@codeaurora.org wrote:
>> > > On 2019-12-18 12:12, Vinod Koul wrote:
>> > > > On 18-12-19, 02:44, cang@codeaurora.org wrote:
>> >
>> > >
>> > > Aside of the phy settings, your DT needs some modifications too,
>> > > seems you copied most of them from sdm845.
>> > > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3834a2e92229ef26d30de28acb698b2b23d3e397
>> > >
>> > > <--snip-->
>> > > > +           ufs_mem_phy: phy@1d87000 {
>> > > > +                   compatible = "qcom,sm8150-qmp-ufs-phy";
>> > > > +                   reg = <0 0x01d87000 0 0x18c>;
>> > >
>> > > The size 0x18c is wrong, in the code you are even accessing registers
>> > > whose offsets are beyond 0x18c, see
>> > >
>> > > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE0     0x1ac
>> > > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE0     0x1b0
>> > > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE1     0x1b4
>> > > #define QSERDES_V4_COM_BIN_VCOCAL_HSCLK_SEL           0x1bc
>> > > #define QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE1     0x1b8
>> > >
>> > > FYI, the total size of serdes registers is 0x1c0.
>> >
>> > Yeah I will update it to 0x1c0
>> >
>> > >
>> > > <--snip-->
>> > > > +                   ufs_mem_phy_lanes: lanes@1d87400 {
>> > > > +                           reg = <0 0x01d87400 0 0x108>,
>> > > > +                                 <0 0x01d87600 0 0x1e0>,
>> > > > +                                 <0 0x01d87c00 0 0x1dc>,
>> > >
>> > > Same as above, see
>> > >
>> > > #define QPHY_V4_MULTI_LANE_CTRL1                      0x1e0
>> > >
>> > > FYI, the total size of PCS registers is 0x200
>> > >
>> > > > +                                 <0 0x01d87800 0 0x108>,
>> > > > +                                 <0 0x01d87a00 0 0x1e0>;
>> > > > +                           #phy-cells = <0>;
>> > > > +                   };
>> > > <--snip-->
>> >
>> > So I managed to fix it by configuring QPHY_SW_RESET in
>> > qcom_qmp_phy_com_init() before invoking the configuration. That makes it
>> > work for me. Will send patches shortly
>> 
>> So, you are going to send some fixes to make sm8150 work.  We also
>> need the extended timeout for all platforms, yes?  Who is going to
>> send up the patch for the timeout?  All of this should be -rc material
>> since Can's change caused these issues to appear, and thus impact
>> users, no?
> 
> yeah I have tested a timeout of 10ms and seems to look good for me on
> sm8150 and sdm845. I will be sending the patches in few minutes :) and
> yes the timeout should be marked to 5.5 fixes
> 
> Thanks

Hi Vinod,

Good to know it works for you. Vivek Gautam, who is the author QCOM UFS 
PHY
driver, has left QCOM. Please add Asutosh Das(asutoshd@codeaurora.org),
Bao D. Nguyen(nguyenb@codeaurora.org) and me for QCOM UFS PHY changes.

Actually, without this change, your PHY is not even re-initialized at 
all
during kernel bootup, it just retains whatever it was configured in 
UEFI,
yet you are still saying this is a regression. The extended timeout is 
what
UFS PHY has to take for a full initialization.

Regards,
Can Guo.