linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeffrey Hugo <jhugo@codeaurora.org>
To: Bhaumik Bhatt <bbhatt@codeaurora.org>, manivannan.sadhasivam@linaro.org
Cc: linux-arm-msm@vger.kernel.org, hemantk@codeaurora.org,
	linux-kernel@vger.kernel.org, loic.poulain@linaro.org,
	carl.yin@quectel.com, naveen.kumar@quectel.com
Subject: Re: [PATCH v3 2/3] bus: mhi: core: Move to polling method to wait for MHI ready
Date: Wed, 10 Mar 2021 12:02:50 -0700	[thread overview]
Message-ID: <df566e64-8335-2ab2-85c8-bed4ec5b649d@codeaurora.org> (raw)
In-Reply-To: <1614138270-2374-3-git-send-email-bbhatt@codeaurora.org>

On 2/23/2021 8:44 PM, Bhaumik Bhatt wrote:
> In certain devices, it is likely that there is no incoming MHI
> interrupt for a transition to MHI READY state. One such example
> is the move from Pass Through to an SBL or AMSS execution
> environment. In order to facilitate faster bootup times as there
> is no need to wait until timeout_ms completes, MHI host can poll
> every 25 milliseconds to check if device has entered MHI READY
> until a maximum timeout of twice the timeout_ms is reached.
> 
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> ---
>   drivers/bus/mhi/core/pm.c | 31 ++++++++++++++-----------------
>   1 file changed, 14 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index 681960c..5fe33d4 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -153,34 +153,31 @@ static void mhi_toggle_dev_wake(struct mhi_controller *mhi_cntrl)
>   /* Handle device ready state transition */
>   int mhi_ready_state_transition(struct mhi_controller *mhi_cntrl)
>   {
> -	void __iomem *base = mhi_cntrl->regs;
>   	struct mhi_event *mhi_event;
>   	enum mhi_pm_state cur_state;
>   	struct device *dev = &mhi_cntrl->mhi_dev->dev;
> -	u32 reset = 1, ready = 0;
>   	int ret, i;
>   
> -	/* Wait for RESET to be cleared and READY bit to be set by the device */
> -	wait_event_timeout(mhi_cntrl->state_event,
> -			   MHI_PM_IN_FATAL_STATE(mhi_cntrl->pm_state) ||
> -			   mhi_read_reg_field(mhi_cntrl, base, MHICTRL,
> -					      MHICTRL_RESET_MASK,
> -					      MHICTRL_RESET_SHIFT, &reset) ||
> -			   mhi_read_reg_field(mhi_cntrl, base, MHISTATUS,
> -					      MHISTATUS_READY_MASK,
> -					      MHISTATUS_READY_SHIFT, &ready) ||
> -			   (!reset && ready),
> -			   msecs_to_jiffies(mhi_cntrl->timeout_ms));
> -
>   	/* Check if device entered error state */
>   	if (MHI_PM_IN_FATAL_STATE(mhi_cntrl->pm_state)) {
>   		dev_err(dev, "Device link is not accessible\n");
>   		return -EIO;
>   	}
>   
> -	/* Timeout if device did not transition to ready state */
> -	if (reset || !ready) {
> -		dev_err(dev, "Device Ready timeout\n");
> +	/* Wait for RESET to be cleared and READY bit to be set by the device */
> +	ret = mhi_poll_reg_field(mhi_cntrl, mhi_cntrl->regs, MHICTRL,
> +				 MHICTRL_RESET_MASK, MHICTRL_RESET_SHIFT, 0,
> +				 25000);
> +	if (ret) {
> +		dev_err(dev, "Device failed to clear MHI Reset\n");
> +		return -ETIMEDOUT;
> +	}
> +
> +	ret = mhi_poll_reg_field(mhi_cntrl, mhi_cntrl->regs, MHISTATUS,
> +				 MHISTATUS_READY_MASK, MHISTATUS_READY_SHIFT, 1,
> +				 25000);

You use the magic number "25000" twice here.  Its my understanding that 
the preference is to inline a magic number if its used in one spot, but 
use a macro if its used more than that.

Both uses are confined to this function, and in close proximity, so 
chances that one gets updated without the other seem minimal, so this 
feels like a borderline case.  I don't know if Mani has an opinion here.

I'd probably err on the side of making a macro or a single variable.  If 
not, I think some comments explaining the value are warranted (should 
comment the macro as well).

> +	if (ret) {
> +		dev_err(dev, "Device failed to enter MHI Ready\n");
>   		return -ETIMEDOUT;
>   	}
>   
> 


-- 
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

  reply	other threads:[~2021-03-10 19:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-24  3:44 [PATCH v3 0/3] Polling for MHI ready Bhaumik Bhatt
2021-02-24  3:44 ` [PATCH v3 1/3] bus: mhi: core: Introduce internal register poll helper function Bhaumik Bhatt
2021-03-05 13:37   ` Loic Poulain
2021-03-10 18:57   ` Jeffrey Hugo
2021-03-10 22:56     ` Bhaumik Bhatt
2021-02-24  3:44 ` [PATCH v3 2/3] bus: mhi: core: Move to polling method to wait for MHI ready Bhaumik Bhatt
2021-03-10 19:02   ` Jeffrey Hugo [this message]
2021-03-10 22:58     ` Bhaumik Bhatt
2021-02-24  3:44 ` [PATCH v3 3/3] bus: mhi: core: Use poll register read API for RDDM download Bhaumik Bhatt
2021-03-10 19:04   ` Jeffrey Hugo
2021-02-24  9:27 ` [PATCH v3 0/3] Polling for MHI ready Manivannan Sadhasivam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=df566e64-8335-2ab2-85c8-bed4ec5b649d@codeaurora.org \
    --to=jhugo@codeaurora.org \
    --cc=bbhatt@codeaurora.org \
    --cc=carl.yin@quectel.com \
    --cc=hemantk@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=naveen.kumar@quectel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).