Serialize execution environment changes for MHI
Subsystems (2)
v2 cover Serialize execution environment changes for MHI
v2:
-Add patch to clear devices when moving execution environments
During full boot chain firmware download, the PM state worker downloads the AMSS image after waiting for the SBL execution environment change in PBL mode itself. Since getting rid of the firmware load worker thread, this design needs to change and MHI host must download the AMSS image from the SBL mode of PM state worker thread instead.
Ensure that EE changes are handled only from appropriate places and occur one after another and handle only PBL or RDDM EE changes as critical events directly from the interrupt handler and the status callback is given to the controller drivers promptly.
When moving from SBL to AMSS EE, clear SBL specific client devices by calling remove callbacks for them so they are not left opened in a different execution environment.
Bhaumik Bhatt (3):
bus: mhi: core: Clear devices when moving execution environments
bus: mhi: core: Download AMSS image from appropriate function
bus: mhi: core: Process execution environment changes serially
drivers/bus/mhi/core/boot.c | 44 ++++++++++++++++++++--------------------- drivers/bus/mhi/core/internal.h | 1 + drivers/bus/mhi/core/main.c | 36 +++++++++++++++++++++++---------- drivers/bus/mhi/core/pm.c | 10 ++++++++-- 4 files changed, 56 insertions(+), 35 deletions(-)
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v2 1/3 bus: mhi: core: Clear devices when moving execution environments
When moving from SBL to mission mode execution environment, there is no remove callback notification to MHI client drivers which operate on SBL mode only. Client driver devices are being created in SBL or AMSS(mission mode) and only destroyed after power down or SYS_ERROR. If there exist any SBL-specific channels, those are left open and client drivers are thus unaware of the new execution environment where those channels cannot operate. Close the gap and issue remove callbacks to SBL-specific client drivers once device enters mission mode.
--- drivers/bus/mhi/core/main.c | 22 ++++++++++++++++++---- drivers/bus/mhi/core/pm.c | 3 +++ 2 files changed, 21 insertions(+), 4 deletions(-)
drivers/bus/mhi/core/main.c +18 -4
@@ -244,8 +244,10 @@ static void mhi_del_ring_element(struct mhi_controller *mhi_cntrl,int mhi_destroy_device (struct device *dev,void *data) { +struct mhi_chan *ul_chan, *dl_chan;struct mhi_device *mhi_dev;struct mhi_controller *mhi_cntrl; +enum mhi_ee_type ee =MHI_EE_MAX ;if (dev->bus != &mhi_bus_type)return 0 ;
@@ -257,6 +259,12 @@ int mhi_destroy_device(struct device *dev, void *data)if (mhi_dev->dev_type ==MHI_DEVICE_CONTROLLER )return 0 ; + ul_chan = mhi_dev->ul_chan; + dl_chan = mhi_dev->dl_chan; + +if (data) + ee = *(enum mhi_ee_type *)data; +/* * For the suspend and resume case, this function will get called * without mhi_unregister_controller(). Hence, we need to drop the
@@ -264,11 +272,17 @@ int mhi_destroy_device(struct device *dev, void *data)* be sure that there will be no instances of mhi_dev left after * this. */ -if (mhi_dev->ul_chan) -put_device (&mhi_dev->ul_chan->mhi_dev->dev); +if (ul_chan) { +if (ee !=MHI_EE_MAX && !(ul_chan->ee_mask &BIT (ee))) +return 0 ; +put_device (&ul_chan->mhi_dev->dev); + } -if (mhi_dev->dl_chan) -put_device (&mhi_dev->dl_chan->mhi_dev->dev); +if (dl_chan) { +if (ee !=MHI_EE_MAX && !(dl_chan->ee_mask &BIT (ee))) +return 0 ; +put_device (&dl_chan->mhi_dev->dev); + }dev_dbg (&mhi_cntrl->mhi_dev->dev,"destroy device for chan:%s\n" , mhi_dev->name);
drivers/bus/mhi/core/pm.c +3 -0
@@ -377,6 +377,7 @@ static int mhi_pm_mission_mode_transition(struct mhi_controller *mhi_cntrl) {struct mhi_event *mhi_event;struct device *dev = &mhi_cntrl->mhi_dev->dev; +enum mhi_ee_type ee =MHI_EE_MAX , current_ee = mhi_cntrl->ee;int i, ret;dev_dbg (dev,"Processing Mission Mode transition\n" );
@@ -395,6 +396,8 @@ static int mhi_pm_mission_mode_transition(struct mhi_controller *mhi_cntrl)wake_up_all (&mhi_cntrl->state_event); +device_for_each_child (&mhi_cntrl->mhi_dev->dev, ¤t_ee, + mhi_destroy_device); mhi_cntrl->status_cb (mhi_cntrl,MHI_CB_EE_MISSION_MODE );/* Force MHI to be in M0 state before continuing */
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 1/3] bus: mhi: core: Clear devices when moving execution environments
Quoted 11 lines · Bhaumik Bhatt
When moving from SBL to mission mode execution environment, there is no remove callback notification to MHI client drivers which operate on SBL mode only. Client driver devices are being created in SBL or AMSS(mission mode) and only destroyed after power down or
SYS_ERROR. If there exist any SBL-specific channels, those are left open and client drivers are thus unaware of the new execution environment where those channels cannot operate. Close the gap and issue remove callbacks to SBL-specific client drivers once device enters mission mode.Signed-off-by Bhaumik Bhatt <[email protected]>
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 1/3] bus: mhi: core: Clear devices when moving execution environments
In reply to Bhaumik BhattQuoted 10 lines · Bhaumik Bhatt
When moving from SBL to mission mode execution environment, there is no remove callback notification to MHI client drivers which operate on SBL mode only. Client driver devices are being created in SBL or AMSS(mission mode) and only destroyed after power down or
SYS_ERROR. If there exist any SBL-specific channels, those are left open and client drivers are thus unaware of the new execution environment where those channels cannot operate. Close the gap and issue remove callbacks to SBL-specific client drivers once device enters mission mode.
What are the SBL specific channels and the client drivers operating on them? If this is something going to come in future, then this patch can come later.
Thanks,
Mani
Re: [PATCH v2 1/3] bus: mhi: core: Clear devices when moving execution environments
Hi Mani,
Quoted 12 lines · Manivannan Sadhasivam
Quoted 10 lines · Bhaumik Bhatt
When moving from SBL to mission mode execution environment, there is no remove callback notification to MHI client drivers which operate on SBL mode only. Client driver devices are being created in SBL or AMSS(mission mode) and only destroyed after power down or
SYS_ERROR. If there exist any SBL-specific channels, those are left open and client drivers are thus unaware of the new execution environment where those channels cannot operate. Close the gap and issue remove callbacks to SBL-specific client drivers once device enters mission mode.
Quoted 5 lines
What are the SBL specific channels and the client drivers operating on them? If this is something going to come in future, then this patch can come later.
Thanks,
Mani
Carl from Quectel (CC'd here) will need this patch as he works on EDL and Flash Programmer changes which also needs usage of QSAHARA server over SBL.
Thanks,
Bhaumik
---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v2 2/3 bus: mhi: core: Download AMSS image from appropriate function
In reply to Bhaumik BhattDuring full boot chain firmware download, the PM state worker downloads the AMSS image after waiting for the SBL execution environment change in PBL mode itself. Since getting rid of the firmware load worker thread, this design needs to change and MHI host must download the AMSS image from the SBL mode of PM state worker thread instead. Since the full boot chain firmware download is associated with a synchronous power up and has MHI host waiting for a transition to mission mode with a timeout, we can skip creating any devices (or probing any client drivers) in SBL mode transition and proceed directly with the AMSS image download.
This means that if MHI host driver is not responsible for the AMSS image download or the controller plans to have client drivers opening any SBL channels, for example, to download images or monitor debug logs for memory allocations or power management, the device can be powered up asynchronously.
--- drivers/bus/mhi/core/boot.c | 44 ++++++++++++++++++++--------------------- drivers/bus/mhi/core/internal.h | 1 + drivers/bus/mhi/core/pm.c | 2 ++ 3 files changed, 24 insertions(+), 23 deletions(-)
drivers/bus/mhi/core/boot.c +21 -23
@@ -389,7 +389,6 @@ static void mhi_firmware_copy(struct mhi_controller *mhi_cntrl,void mhi_fw_load_handler (struct mhi_controller *mhi_cntrl) {const struct firmware *firmware =NULL ; -struct image_info *image_info;struct device *dev = &mhi_cntrl->mhi_dev->dev;const char *fw_name;void *buf;
@@ -500,28 +499,6 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl) goto error_ready_state; } -/* Wait for the SBL event */ - ret =wait_event_timeout (mhi_cntrl->state_event, - mhi_cntrl->ee ==MHI_EE_SBL || -MHI_PM_IN_ERROR_STATE (mhi_cntrl->pm_state), -msecs_to_jiffies (mhi_cntrl->timeout_ms)); - -if (!ret ||MHI_PM_IN_ERROR_STATE (mhi_cntrl->pm_state)) { -dev_err (dev,"MHI did not enter SBL\n" ); - goto error_ready_state; - } - -/* Start full firmware image download */ - image_info = mhi_cntrl->fbc_image; - ret =mhi_fw_load_bhie (mhi_cntrl, -/* Vector table is the last entry */ - &image_info->mhi_buf[image_info->entries -1 ]); -if (ret) { -dev_err (dev,"MHI did not load image over BHIe, ret: %d\n" , - ret); - goto error_fw_load; - } -return ; error_ready_state:
@@ -532,3 +509,24 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl) mhi_cntrl->pm_state =MHI_PM_FW_DL_ERR ;wake_up_all (&mhi_cntrl->state_event); } + +int mhi_download_amss_image (struct mhi_controller *mhi_cntrl) +{ +struct image_info *image_info = mhi_cntrl->fbc_image; +struct device *dev = &mhi_cntrl->mhi_dev->dev; +int ret; + +if (!image_info) +return -EIO ; + + ret =mhi_fw_load_bhie (mhi_cntrl, +/* Vector table is the last entry */ + &image_info->mhi_buf[image_info->entries -1 ]); +if (ret) { +dev_err (dev,"MHI did not load AMSS, ret:%d\n" , ret); + mhi_cntrl->pm_state =MHI_PM_FW_DL_ERR ; +wake_up_all (&mhi_cntrl->state_event); + } + +return ret; +}
drivers/bus/mhi/core/internal.h +1 -0
@@ -619,6 +619,7 @@ int mhi_pm_m3_transition(struct mhi_controller *mhi_cntrl);int __mhi_device_get_sync (struct mhi_controller *mhi_cntrl);int mhi_send_cmd (struct mhi_controller *mhi_cntrl,struct mhi_chan *mhi_chan,enum mhi_cmd_type cmd); +int mhi_download_amss_image (struct mhi_controller *mhi_cntrl);static inline bool mhi_is_active (struct mhi_controller *mhi_cntrl) { return (mhi_cntrl->dev_state >= MHI_STATE_M0 &&
drivers/bus/mhi/core/pm.c +2 -0
@@ -758,6 +758,8 @@ void mhi_pm_st_worker(struct work_struct *work)* either SBL or AMSS states */ mhi_create_devices (mhi_cntrl); +if (mhi_cntrl->fbc_download) +mhi_download_amss_image (mhi_cntrl);break ;case DEV_ST_TRANSITION_MISSION_MODE :mhi_pm_mission_mode_transition (mhi_cntrl);
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 2/3] bus: mhi: core: Download AMSS image from appropriate function
Hi Bhaumik,
Quoted 4 lines · Bhaumik Bhatt
During full boot chain firmware download, the PM state worker downloads the AMSS image after waiting for the SBL execution environment change in PBL mode itself. Since getting rid of the firmware load worker thread, this design needs to change and MHI
Can we reword this as current driver does not have firmware load worker thread. Basically change is to avoid blocking st worker thread with a timeout to get SBL EE before starting AMSS image download. Instead trigger AMSS image download directly from the st worker thread when DEV_ST_TRANSITION_SBL is queued.
Quoted 8 lines
host must download the AMSS image from the SBL mode of PM state worker thread instead. Since the full boot chain firmware download is associated with a synchronous power up and has MHI host waiting for a transition to mission mode with a timeout, we can skip creating any devices (or probing any client drivers) in SBL mode transition and proceed directly with the AMSS image download.
Quoted 6 lines
This means that if MHI host driver is not responsible for the AMSS image download or the controller plans to have client drivers opening any SBL channels, for example, to download images or monitor debug logs for memory allocations or power management, the device can be powered up asynchronously.
[..]
Thanks,
Hemant
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v2 3/3 bus: mhi: core: Process execution environment changes serially
In reply to Bhaumik BhattIn current design, whenever the BHI interrupt is fired, the execution environment is updated. This can cause race conditions and impede any ongoing power up/down processing. For example, if a power down is in progress and the host has updated the execution environment to a local "disabled" state, any BHI interrupt firing later could replace it with the value from the BHI EE register. Another example would be that the device can enter mission mode while device creation for SBL is still going on, 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 or RDDM EE changes as critical events directly from the interrupt handler. 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.
--- drivers/bus/mhi/core/main.c | 14 ++++++++------ drivers/bus/mhi/core/pm.c | 5 +++-- 2 files changed, 11 insertions(+), 8 deletions(-)
drivers/bus/mhi/core/main.c +8 -6
@@ -411,7 +411,7 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, void *priv)struct device *dev = &mhi_cntrl->mhi_dev->dev;enum mhi_state state =MHI_STATE_MAX ;enum mhi_pm_state pm_state =0 ; -enum mhi_ee_type ee =0 ; +enum mhi_ee_type ee =MHI_EE_MAX ;write_lock_irq (&mhi_cntrl->pm_lock);if (!MHI_REG_ACCESS_VALID (mhi_cntrl->pm_state)) {
@@ -420,8 +420,7 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, void *priv) } state =mhi_get_mhi_state (mhi_cntrl); - ee = mhi_cntrl->ee; - mhi_cntrl->ee =mhi_get_exec_env (mhi_cntrl); + ee =mhi_get_exec_env (mhi_cntrl);dev_dbg (dev,"local ee:%s device ee:%s dev_state:%s\n" ,TO_MHI_EXEC_STR (mhi_cntrl->ee),TO_MHI_EXEC_STR (ee),TO_MHI_STATE_STR (state));
@@ -439,8 +438,9 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, void *priv)if (!mhi_is_active (mhi_cntrl)) goto exit_intvec; -if (mhi_cntrl->ee ==MHI_EE_RDDM && mhi_cntrl->ee != ee) { +if (ee ==MHI_EE_RDDM && mhi_cntrl->ee !=MHI_EE_RDDM ) { mhi_cntrl->status_cb (mhi_cntrl,MHI_CB_EE_RDDM ); + mhi_cntrl->ee = ee;wake_up_all (&mhi_cntrl->state_event); } goto exit_intvec;
@@ -450,10 +450,12 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, void *priv)wake_up_all (&mhi_cntrl->state_event);/* For fatal errors, we let controller decide next step */ -if (MHI_IN_PBL (ee)) +if (MHI_IN_PBL (ee)) { mhi_cntrl->status_cb (mhi_cntrl,MHI_CB_FATAL_ERROR ); -else + mhi_cntrl->ee = ee; + }else {mhi_pm_sys_err_handler (mhi_cntrl); + } } exit_intvec:
drivers/bus/mhi/core/pm.c +3 -2
@@ -384,14 +384,15 @@ static int mhi_pm_mission_mode_transition(struct mhi_controller *mhi_cntrl)write_lock_irq (&mhi_cntrl->pm_lock);if (MHI_REG_ACCESS_VALID (mhi_cntrl->pm_state)) - mhi_cntrl->ee =mhi_get_exec_env (mhi_cntrl); + ee =mhi_get_exec_env (mhi_cntrl); -if (!MHI_IN_MISSION_MODE (mhi_cntrl->ee)) { +if (!MHI_IN_MISSION_MODE (ee)) { mhi_cntrl->pm_state =MHI_PM_LD_ERR_FATAL_DETECT ;write_unlock_irq (&mhi_cntrl->pm_lock);wake_up_all (&mhi_cntrl->state_event);return -EIO ; } + mhi_cntrl->ee = ee;write_unlock_irq (&mhi_cntrl->pm_lock);wake_up_all (&mhi_cntrl->state_event);
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 3/3] bus: mhi: core: Process execution environment changes serially
Quoted 6 lines · Bhaumik Bhatt
In current design, whenever the BHI interrupt is fired, the execution environment is updated. This can cause race conditions and impede any ongoing power up/down processing. For example, if a power down is in progress and the host has updated the execution environment to a local "disabled" state, any BHI interrupt firing later could replace it with the value from the BHI EE register.
Can we add what is the real issue observed when mhi_cntrl->ee changed in above scenario?
Another example would be
Quoted 3 lines
that the device can enter mission mode while device creation for SBL is still going on, leading to multiple attempts at opening the same channel.
Even for this scenario, can we add the real issue that was observed e.g. same device was attempting to get created twice and caused xyz issue?
Quoted 8 lines
Ensure that EE changes are handled only from appropriate places and occur one after another and handle only PBL or RDDM EE changes as critical events directly from the interrupt handler. 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.
[..]
Thanks,
Hemant
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project