| Message ID | 1617067704-28850-1-git-send-email-bbhatt@codeaurora.org |
|---|---|
| Headers | show |
| Series | MHI Emergency download and flash programmer support | expand |
On Tue, 30 Mar 2021 at 03:28, Bhaumik Bhatt <bbhatt@codeaurora.org> wrote: > > Currently, the firmware load handler returns after the EDL image > is downloaded. Wait for an MHI READY transition instead as the > specification expects so as to proceed with further bootup such > as device entering Flash Programmer execution environment. > > Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org> > Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
On Tue, 30 Mar 2021 at 03:28, Bhaumik Bhatt <bbhatt@codeaurora.org> wrote: > > When moving from SYS_ERROR transition to a different execution > environment, MHI host relies on the BHI register read to spawn > the next image download or wait for READY -> M0 states. The > device can at times move the execution environment to mission > mode when a pass through is expected, which can result in a > stall. Initiate a wait for MHI READY and write M0 such that the > device can proceed with state change event updates for any new > execution environment being entered. This allows us to remove > conditionals in handling firmware load for PBL modes and keeps > the execution environment out of the picture as it can change at > any time. > > Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org> Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
On Mon, Mar 29, 2021 at 06:28:20PM -0700, Bhaumik Bhatt wrote: > Device entering EDL or Emergency Download Mode will be in a > SYS_ERROR MHI state. This requires MHI host to proceed with the > EDL image download over BHI before device can enter an MHI READY > state and proceed with further bootup. Allow this to be handled > by relying on the execution environment check after SYS_ERROR > processing to determine whether to wait for an MHI READY or > download the EDL image over BHI after moving MHI PM state to > Power on Reset internally. This way handling is contained well > within the MHI core driver and helps pave the way for Flash > Programmer execution environment functionality. > > Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Thanks, Mani > --- > drivers/bus/mhi/core/pm.c | 19 ++++++++++++++++++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c > index fbe9447..b65222e 100644 > --- a/drivers/bus/mhi/core/pm.c > +++ b/drivers/bus/mhi/core/pm.c > @@ -564,6 +564,7 @@ static void mhi_pm_disable_transition(struct mhi_controller *mhi_cntrl) > static void mhi_pm_sys_error_transition(struct mhi_controller *mhi_cntrl) > { > enum mhi_pm_state cur_state, prev_state; > + enum dev_st_transition next_state; > struct mhi_event *mhi_event; > struct mhi_cmd_ctxt *cmd_ctxt; > struct mhi_cmd *mhi_cmd; > @@ -677,7 +678,23 @@ static void mhi_pm_sys_error_transition(struct mhi_controller *mhi_cntrl) > er_ctxt->wp = er_ctxt->rbase; > } > > - mhi_ready_state_transition(mhi_cntrl); > + /* Transition to next state */ > + if (MHI_IN_PBL(mhi_get_exec_env(mhi_cntrl))) { > + write_lock_irq(&mhi_cntrl->pm_lock); > + cur_state = mhi_tryset_pm_state(mhi_cntrl, MHI_PM_POR); > + write_unlock_irq(&mhi_cntrl->pm_lock); > + if (cur_state != MHI_PM_POR) { > + dev_err(dev, "Error moving to state %s from %s\n", > + to_mhi_pm_state_str(MHI_PM_POR), > + to_mhi_pm_state_str(cur_state)); > + goto exit_sys_error_transition; > + } > + next_state = DEV_ST_TRANSITION_PBL; > + } else { > + next_state = DEV_ST_TRANSITION_READY; > + } > + > + mhi_queue_state_transition(mhi_cntrl, next_state); > > exit_sys_error_transition: > dev_dbg(dev, "Exiting with PM state: %s, MHI state: %s\n", > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
On Mon, Mar 29, 2021 at 06:28:23PM -0700, Bhaumik Bhatt wrote: > When moving from SYS_ERROR transition to a different execution > environment, MHI host relies on the BHI register read to spawn > the next image download or wait for READY -> M0 states. The > device can at times move the execution environment to mission > mode when a pass through is expected, which can result in a > stall. Initiate a wait for MHI READY and write M0 such that the > device can proceed with state change event updates for any new > execution environment being entered. This allows us to remove > conditionals in handling firmware load for PBL modes and keeps > the execution environment out of the picture as it can change at > any time. > > Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Thanks, Mani > --- > drivers/bus/mhi/core/boot.c | 4 ++-- > drivers/bus/mhi/core/pm.c | 3 +-- > 2 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c > index 0f0ae88..8100cf5 100644 > --- a/drivers/bus/mhi/core/boot.c > +++ b/drivers/bus/mhi/core/boot.c > @@ -416,8 +416,8 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl) > } > } > > - /* If device is in pass through, do reset to ready state transition */ > - if (mhi_cntrl->ee == MHI_EE_PTHRU) > + /* wait for ready on pass through or any other execution environment */ > + if (mhi_cntrl->ee != MHI_EE_EDL && mhi_cntrl->ee != MHI_EE_PBL) > goto fw_load_ready_state; > > fw_name = (mhi_cntrl->ee == MHI_EE_EDL) ? > diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c > index 7ac9dfe..b6920a5 100644 > --- a/drivers/bus/mhi/core/pm.c > +++ b/drivers/bus/mhi/core/pm.c > @@ -763,8 +763,7 @@ void mhi_pm_st_worker(struct work_struct *work) > if (MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state)) > mhi_cntrl->ee = mhi_get_exec_env(mhi_cntrl); > write_unlock_irq(&mhi_cntrl->pm_lock); > - if (MHI_IN_PBL(mhi_cntrl->ee)) > - mhi_fw_load_handler(mhi_cntrl); > + mhi_fw_load_handler(mhi_cntrl); > break; > case DEV_ST_TRANSITION_SBL: > write_lock_irq(&mhi_cntrl->pm_lock); > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
On Mon, Mar 29, 2021 at 06:28:17PM -0700, Bhaumik Bhatt wrote: > Allow handling EDL mode after SYS_ERROR occurs by reading the execution > environment post handling and move to power on reset state to accommodate the > scenario. > Handle EDL mode properly and wait for ready instead of just exiting from the > firmware load. > Allow use of the Flash Programmer execution environment as a mission mode > use case for a blank NAND power up scenario. > Always attempt a wait for MHI ready state as device could be waiting for the > host to do so after pass through execution environment is seen. > Introduce patch to improve state awareness and aid in debugging. > > This patch series was tested on x86_64 architecture. > These patches were part of a different series before. It is good that you splitted the patches but you should mention that here. Thanks, Mani > Bhaumik Bhatt (6): > bus: mhi: core: Rely on accurate method to determine EDL mode > bus: mhi: core: Wait for ready after an EDL firmware download > bus: mhi: core: Handle EDL mode entry appropriately > bus: mhi: core: Identify Flash Programmer as a mission mode use case > bus: mhi: core: Wait for MHI READY state in most scenarios > bus: mhi: core: Improve state strings for debug messages > > Carl Yin (1): > bus: mhi: core: Add support for Flash Programmer execution environment > > drivers/bus/mhi/core/boot.c | 13 +++++++------ > drivers/bus/mhi/core/init.c | 34 ++++++++++++++++++---------------- > drivers/bus/mhi/core/internal.h | 4 +++- > drivers/bus/mhi/core/main.c | 3 +++ > drivers/bus/mhi/core/pm.c | 28 +++++++++++++++++++++++++--- > include/linux/mhi.h | 4 +++- > 6 files changed, 59 insertions(+), 27 deletions(-) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
On Mon, Mar 29, 2021 at 06:28:17PM -0700, Bhaumik Bhatt wrote: > Allow handling EDL mode after SYS_ERROR occurs by reading the execution > environment post handling and move to power on reset state to accommodate the > scenario. > Handle EDL mode properly and wait for ready instead of just exiting from the > firmware load. > Allow use of the Flash Programmer execution environment as a mission mode > use case for a blank NAND power up scenario. > Always attempt a wait for MHI ready state as device could be waiting for the > host to do so after pass through execution environment is seen. > Introduce patch to improve state awareness and aid in debugging. > > This patch series was tested on x86_64 architecture. > Applied to mhi-next! Thanks, Mani > Bhaumik Bhatt (6): > bus: mhi: core: Rely on accurate method to determine EDL mode > bus: mhi: core: Wait for ready after an EDL firmware download > bus: mhi: core: Handle EDL mode entry appropriately > bus: mhi: core: Identify Flash Programmer as a mission mode use case > bus: mhi: core: Wait for MHI READY state in most scenarios > bus: mhi: core: Improve state strings for debug messages > > Carl Yin (1): > bus: mhi: core: Add support for Flash Programmer execution environment > > drivers/bus/mhi/core/boot.c | 13 +++++++------ > drivers/bus/mhi/core/init.c | 34 ++++++++++++++++++---------------- > drivers/bus/mhi/core/internal.h | 4 +++- > drivers/bus/mhi/core/main.c | 3 +++ > drivers/bus/mhi/core/pm.c | 28 +++++++++++++++++++++++++--- > include/linux/mhi.h | 4 +++- > 6 files changed, 59 insertions(+), 27 deletions(-) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
Hi Mani, On 2021-03-31 04:16 AM, Manivannan Sadhasivam wrote: > On Mon, Mar 29, 2021 at 06:28:17PM -0700, Bhaumik Bhatt wrote: >> Allow handling EDL mode after SYS_ERROR occurs by reading the >> execution >> environment post handling and move to power on reset state to >> accommodate the >> scenario. >> Handle EDL mode properly and wait for ready instead of just exiting >> from the >> firmware load. >> Allow use of the Flash Programmer execution environment as a mission >> mode >> use case for a blank NAND power up scenario. >> Always attempt a wait for MHI ready state as device could be waiting >> for the >> host to do so after pass through execution environment is seen. >> Introduce patch to improve state awareness and aid in debugging. >> >> This patch series was tested on x86_64 architecture. >> > > These patches were part of a different series before. It is good that > you splitted the patches but you should mention that here. > > Thanks, > Mani > I will keep that in mind when submitting next time. >> Bhaumik Bhatt (6): >> bus: mhi: core: Rely on accurate method to determine EDL mode >> bus: mhi: core: Wait for ready after an EDL firmware download >> bus: mhi: core: Handle EDL mode entry appropriately >> bus: mhi: core: Identify Flash Programmer as a mission mode use case >> bus: mhi: core: Wait for MHI READY state in most scenarios >> bus: mhi: core: Improve state strings for debug messages >> >> Carl Yin (1): >> bus: mhi: core: Add support for Flash Programmer execution >> environment >> >> drivers/bus/mhi/core/boot.c | 13 +++++++------ >> drivers/bus/mhi/core/init.c | 34 >> ++++++++++++++++++---------------- >> drivers/bus/mhi/core/internal.h | 4 +++- >> drivers/bus/mhi/core/main.c | 3 +++ >> drivers/bus/mhi/core/pm.c | 28 +++++++++++++++++++++++++--- >> include/linux/mhi.h | 4 +++- >> 6 files changed, 59 insertions(+), 27 deletions(-) >> >> -- >> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora >> Forum, >> a Linux Foundation Collaborative Project >> Thanks, Bhaumik --- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Hello: This series was applied to qcom/linux.git (refs/heads/for-next): On Mon, 29 Mar 2021 18:28:17 -0700 you wrote: > Allow handling EDL mode after SYS_ERROR occurs by reading the execution > environment post handling and move to power on reset state to accommodate the > scenario. > Handle EDL mode properly and wait for ready instead of just exiting from the > firmware load. > Allow use of the Flash Programmer execution environment as a mission mode > use case for a blank NAND power up scenario. > Always attempt a wait for MHI ready state as device could be waiting for the > host to do so after pass through execution environment is seen. > Introduce patch to improve state awareness and aid in debugging. > > [...] Here is the summary with links: - [v1,1/7] bus: mhi: core: Rely on accurate method to determine EDL mode https://git.kernel.org/qcom/c/418bec695696 - [v1,2/7] bus: mhi: core: Wait for ready after an EDL firmware download https://git.kernel.org/qcom/c/4f214496ac74 - [v1,3/7] bus: mhi: core: Handle EDL mode entry appropriately https://git.kernel.org/qcom/c/ad416db9fabe - [v1,4/7] bus: mhi: core: Add support for Flash Programmer execution environment https://git.kernel.org/qcom/c/66ac7985b2af - [v1,5/7] bus: mhi: core: Identify Flash Programmer as a mission mode use case https://git.kernel.org/qcom/c/d20e82d4d016 - [v1,6/7] bus: mhi: core: Wait for MHI READY state in most scenarios https://git.kernel.org/qcom/c/e72919cebd19 - [v1,7/7] bus: mhi: core: Improve state strings for debug messages https://git.kernel.org/qcom/c/19e60d6e88a6 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html