| Message ID | 1613701052-38885-2-git-send-email-bbhatt@codeaurora.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Serialize execution environment changes for MHI | expand |
On 2/18/2021 7:17 PM, Bhaumik Bhatt wrote: > 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 <bbhatt@codeaurora.org> > --- I like the idea, but I question where this is limited to the transition to mission mode. Feels like something that should occur on all EE changes. We might not have a current usecase that is outside what you've implemented here, but I don't think there is anything preventing that in future.
On 2021-02-19 08:10 AM, Jeffrey Hugo wrote: > On 2/18/2021 7:17 PM, Bhaumik Bhatt wrote: >> 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 <bbhatt@codeaurora.org> >> --- > > I like the idea, but I question where this is limited to the > transition to mission mode. Feels like something that should occur on > all EE changes. We might not have a current usecase that is outside > what you've implemented here, but I don't think there is anything > preventing that in future. You're right. It should not be limited to any single EE transition and that's how the code is written. I see my commit message gives the impression that it's only for SBL -> AMSS. I can correct that and mention it to be EE transition agnostic with SBL to AMSS as the currently usable example. Thanks, Bhaumik --- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c index 4e0131b..58f1425 100644 --- a/drivers/bus/mhi/core/main.c +++ b/drivers/bus/mhi/core/main.c @@ -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,17 @@ 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 execution environment is specified, remove only those devices that + * started in them based on ee_mask for the channels as we move on to a + * different execution environment + */ + 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 +277,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); diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c index 681960c..8da8806 100644 --- a/drivers/bus/mhi/core/pm.c +++ b/drivers/bus/mhi/core/pm.c @@ -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 */
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 <bbhatt@codeaurora.org> --- drivers/bus/mhi/core/main.c | 27 +++++++++++++++++++++++---- drivers/bus/mhi/core/pm.c | 3 +++ 2 files changed, 26 insertions(+), 4 deletions(-)