All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeffrey Hugo <quic_jhugo@quicinc.com>
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 v6 3/4] bus: mhi: core: Process execution environment changes serially
Date: Mon, 23 Aug 2021 12:43:31 -0600	[thread overview]
Message-ID: <899da888-321a-c228-8537-b72821700dc7@quicinc.com> (raw)
In-Reply-To: <1614208985-20851-4-git-send-email-bbhatt@codeaurora.org>

On 2/24/2021 4:23 PM, Bhaumik Bhatt wrote:
> In current design, whenever the BHI interrupt is fired, the
> execution environment is updated. This can cause race conditions
> and impede ongoing power up/down processing. For example, if a
> power down is in progress, MHI host updates to a local "disabled"
> execution environment. If a BHI interrupt fires later, that value
> gets replaced with one from the BHI EE register. This impacts the
> controller as it does not expect multiple RDDM execution
> environment change status callbacks as an example. Another issue
> would be that the device can enter mission mode and the execution
> environment is updated, while device creation for SBL channels is
> still going on due to slower PM state worker thread run, leading
> to multiple attempts at opening the same channel.
> 
> Ensure that EE changes are handled only from appropriate places
> and occur one after another and handle only PBL modes or RDDM EE
> changes as critical events directly from the interrupt handler.
> Simplify handling by waiting for SYS ERROR before handling RDDM.
> This also makes sure that we use the correct execution environment
> to notify the controller driver when the device resets to one of
> the PBL execution environments.
> 
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>

<snip>

> @@ -452,27 +451,30 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, void *priv)
>   	}
>   	write_unlock_irq(&mhi_cntrl->pm_lock);
>   
> -	 /* If device supports RDDM don't bother processing SYS error */
> -	if (mhi_cntrl->rddm_image) {
> -		/* host may be performing a device power down already */
> -		if (!mhi_is_active(mhi_cntrl))
> -			goto exit_intvec;
> +	if (pm_state != MHI_PM_SYS_ERR_DETECT || ee == mhi_cntrl->ee)
> +		goto exit_intvec;
>   
> -		if (mhi_cntrl->ee == MHI_EE_RDDM && mhi_cntrl->ee != ee) {
> +	switch (ee) {
> +	case MHI_EE_RDDM:
> +		/* proceed if power down is not already in progress */
> +		if (mhi_cntrl->rddm_image && mhi_is_active(mhi_cntrl)) {
>   			mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_EE_RDDM);
> +			mhi_cntrl->ee = ee;
>   			wake_up_all(&mhi_cntrl->state_event);
>   		}
> -		goto exit_intvec;
> -	}
> -
> -	if (pm_state == MHI_PM_SYS_ERR_DETECT) {
> +		break;
> +	case MHI_EE_PBL:
> +	case MHI_EE_EDL:
> +	case MHI_EE_PTHRU:
> +		mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_FATAL_ERROR);
> +		mhi_cntrl->ee = ee;
>   		wake_up_all(&mhi_cntrl->state_event);
> -
> -		/* For fatal errors, we let controller decide next step */
> -		if (MHI_IN_PBL(ee))
> -			mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_FATAL_ERROR);
> -		else
> -			mhi_pm_sys_err_handler(mhi_cntrl);
> +		mhi_pm_sys_err_handler(mhi_cntrl);
> +		break;
> +	default:
> +		wake_up_all(&mhi_cntrl->state_event);
> +		mhi_pm_sys_err_handler(mhi_cntrl);
> +		break;
>   	}

Bhaumik, can you explain the above change?  Before this patch (which is 
now committed), if there was a fatal error, the controller was notified 
(MHI_CB_FATAL_ERROR) and it decided all action.  After this patch, the 
controller is notified, but also the core attempts to handle the syserr.

This is a change in behavior, and seems to make a mess of the 
controller, and possibly the core fighting each other.

Specifically, I'm rebasing the AIC100 driver onto 5.13, which has this 
change, and I'm seeing a serious regression.  I'm thinking that for the 
PBL/EDL/PTHRU case, mhi_pm_sys_err_handler() should not be called.

Thoughts?

  parent reply	other threads:[~2021-08-23 18:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-24 23:23 [PATCH v6 0/4] Serialize execution environment changes for MHI Bhaumik Bhatt
2021-02-24 23:23 ` [PATCH v6 1/4] bus: mhi: core: Destroy SBL devices when moving to mission mode Bhaumik Bhatt
2021-02-26 22:06   ` Hemant Kumar
2021-03-04  8:41   ` Loic Poulain
2021-03-10 14:03   ` Manivannan Sadhasivam
2021-02-24 23:23 ` [PATCH v6 2/4] bus: mhi: core: Download AMSS image from appropriate function Bhaumik Bhatt
2021-03-04  8:42   ` Loic Poulain
2021-02-24 23:23 ` [PATCH v6 3/4] bus: mhi: core: Process execution environment changes serially Bhaumik Bhatt
2021-03-04  8:43   ` Loic Poulain
2021-03-10 14:04   ` Manivannan Sadhasivam
2021-08-23 18:43   ` Jeffrey Hugo [this message]
2021-08-23 19:19     ` Bhaumik Bhatt
2021-08-23 19:38       ` Jeffrey Hugo
2021-08-26 18:04         ` Bhaumik Bhatt
2021-02-24 23:23 ` [PATCH v6 4/4] bus: mhi: core: Update debug prints to include local device state Bhaumik Bhatt
2021-03-04  8:45   ` Loic Poulain
2021-03-10 14:07 ` [PATCH v6 0/4] Serialize execution environment changes for MHI Manivannan Sadhasivam
2021-05-26 19:03 ` patchwork-bot+linux-arm-msm

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=899da888-321a-c228-8537-b72821700dc7@quicinc.com \
    --to=quic_jhugo@quicinc.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.