Updates to MHI channel handling
Subsystems (2)
v2 cover Updates to MHI channel handling
MHI specification shows a state machine with support for STOP channel command and the validity of certain state transitions. MHI host currently does not provide any mechanism to stop a channel and restart it without resetting it. There are also times when the device moves on to a different execution environment while client drivers on the host are unaware of it and still attempt to reset the channels facing unnecessary timeouts.
This series addresses the above areas to provide support for stopping an MHI channel, resuming it back, improved documentation and improving upon channel state machine handling in general.
This set of patches was tested on arm64 architecture.
v2:
-Renamed the newly introduced APIs to mhi_start_transfer() / mhi_stop_transfer() -Added improved documentation to avoid confusion with the new APIs -Removed the __ prefix from mhi_unprepare_channel() API for consistency.
Bhaumik Bhatt (6):
bus: mhi: core: Allow receiving a STOP channel command response
bus: mhi: core: Improvements to the channel handling state machine
bus: mhi: core: Add support to stop or start channel data transfers
bus: mhi: core: Check execution environment for channel before issuing
reset
bus: mhi: core: Remove __ prefix for MHI channel unprepare function
bus: mhi: Improve documentation on channel transfer setup APIs
drivers/bus/mhi/core/init.c | 11 +- drivers/bus/mhi/core/internal.h | 12 +++ drivers/bus/mhi/core/main.c | 226 ++++++++++++++++++++++++++++------------ include/linux/mhi.h | 37 ++++++- 4 files changed, 215 insertions(+), 71 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/6 bus: mhi: core: Allow receiving a STOP channel command response
Add support to receive the response to a STOP channel command to the MHI bus. If a client would like to STOP a channel instead of issuing a RESET to it, this would provide support for it.
--- drivers/bus/mhi/core/init.c | 5 +++-- drivers/bus/mhi/core/main.c | 5 +++++ 2 files changed, 8 insertions(+), 2 deletions(-)
drivers/bus/mhi/core/init.c +3 -2
@@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev)mutex_lock (&mhi_chan->mutex); -if (ch_state[dir] ==MHI_CH_STATE_ENABLED && - !mhi_chan->offload_ch) +if ((ch_state[dir] ==MHI_CH_STATE_ENABLED || + ch_state[dir] ==MHI_CH_STATE_STOP ) && + !mhi_chan->offload_ch)mhi_deinit_chan_ctxt (mhi_cntrl, mhi_chan); mhi_chan->ch_state =MHI_CH_STATE_DISABLED ;
drivers/bus/mhi/core/main.c +5 -0
@@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl, cmd_tre->dword[0 ] =MHI_TRE_CMD_RESET_DWORD0 ; cmd_tre->dword[1 ] =MHI_TRE_CMD_RESET_DWORD1 (chan);break ; +case MHI_CMD_STOP_CHAN : + cmd_tre->ptr =MHI_TRE_CMD_STOP_PTR ; + cmd_tre->dword[0 ] =MHI_TRE_CMD_STOP_DWORD0 ; + cmd_tre->dword[1 ] =MHI_TRE_CMD_STOP_DWORD1 (chan); +break ;case MHI_CMD_START_CHAN : cmd_tre->ptr =MHI_TRE_CMD_START_PTR ; cmd_tre->dword[0 ] =MHI_TRE_CMD_START_DWORD0 ;
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/6] bus: mhi: core: Allow receiving a STOP channel command response
Quoted 15 lines · Bhaumik Bhatt
Add support to receive the response to a STOP channel command to the MHI bus. If a client would like to STOP a channel instead of issuing a RESET to it, this would provide support for it.
Signed-off-by Bhaumik Bhatt <[email protected]>--- drivers/bus/mhi/core/init.c | 5 +++-- drivers/bus/mhi/core/main.c | 5 +++++ 2 files changed, 8 insertions(+), 2 deletions(-)drivers/bus/mhi/core/init.c +0
-0
drivers/bus/mhi/core/init.c static int mhi_driver_remove(struct device *dev) · line 1271
Quoted 7 lines
drivers/bus/mhi/core/init.c +2
-2@@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev)mutex_lock (&mhi_chan->mutex); -if (ch_state[dir] ==MHI_CH_STATE_ENABLED && - !mhi_chan->offload_ch) + if ((ch_state[dir] == MHI_CH_STATE_ENABLED || + ch_state[dir] == MHI_CH_STATE_STOP) &&
This enum is not defined in this patch so it'll break. Please add a separate patch which introduces the new state enums alone and then have patches 1/2 as a followup.
Also this change is not belonging to this commit I believe.
Thanks,
Mani
Quoted 24 lines
drivers/bus/mhi/core/init.c +1
-0+ !mhi_chan->offload_ch)mhi_deinit_chan_ctxt (mhi_cntrl, mhi_chan); mhi_chan->ch_state =MHI_CH_STATE_DISABLED ;drivers/bus/mhi/core/main.c +5
-0@@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl, cmd_tre->dword[0 ] =MHI_TRE_CMD_RESET_DWORD0 ; cmd_tre->dword[1 ] =MHI_TRE_CMD_RESET_DWORD1 (chan);break ; +case MHI_CMD_STOP_CHAN : + cmd_tre->ptr =MHI_TRE_CMD_STOP_PTR ; + cmd_tre->dword[0 ] =MHI_TRE_CMD_STOP_DWORD0 ; + cmd_tre->dword[1 ] =MHI_TRE_CMD_STOP_DWORD1 (chan); +break ;case MHI_CMD_START_CHAN : cmd_tre->ptr =MHI_TRE_CMD_START_PTR ; cmd_tre->dword[0 ] =MHI_TRE_CMD_START_DWORD0 ;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/6] bus: mhi: core: Allow receiving a STOP channel command response
Hi Mani,
Quoted 19 lines · Manivannan Sadhasivam
Quoted 18 lines · Bhaumik Bhatt
Add support to receive the response to a STOP channel command to the MHI bus. If a client would like to STOP a channel instead of issuing a RESET to it, this would provide support for it.
Signed-off-by Bhaumik Bhatt <[email protected]>--- drivers/bus/mhi/core/init.c | 5 +++-- drivers/bus/mhi/core/main.c | 5 +++++ 2 files changed, 8 insertions(+), 2 deletions(-)drivers/bus/mhi/core/init.c +0
-0@@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev)mutex_lock (&mhi_chan->mutex);
Quoted 9 lines
drivers/bus/mhi/core/init.c static int mhi_driver_remove(struct device *dev) · line 1271
Quoted 4 lines
drivers/bus/mhi/core/init.c +2
-2-if (ch_state[dir] ==MHI_CH_STATE_ENABLED && - !mhi_chan->offload_ch) + if ((ch_state[dir] == MHI_CH_STATE_ENABLED || + ch_state[dir] == MHI_CH_STATE_STOP) &&This enum is not defined in this patch so it'll break. Please add a separate patch which introduces the new state enums alone and then have patches 1/2 as a followup.
It is actually already defined and present in internal.h as enum mhi_ch_state.
The old set of enums has MHI_CH_STATE_STOP from enum mhi_ch_state and the new enum I introduced is MHI_CH_STATE_TYPE_STOP from enum enum mhi_ch_state_type.
If it seems confusing, suggestions to renaming them are welcome.
Quoted 2 lines
Also this change is not belonging to this commit I believe.
I included this change here because, a channel can be in "stopped" state and a user module could be unloaded or a crash could force a driver remove leading us to come this check.
If you think I should move it as a separate patch, let me know.
Quoted 20 lines
Thanks,
ManiQuoted 17 lines
drivers/bus/mhi/core/init.c +1
-0+ !mhi_chan->offload_ch)mhi_deinit_chan_ctxt (mhi_cntrl, mhi_chan); mhi_chan->ch_state =MHI_CH_STATE_DISABLED ;drivers/bus/mhi/core/main.c +4
-0@@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl, cmd_tre->dword[0 ] =MHI_TRE_CMD_RESET_DWORD0 ; cmd_tre->dword[1 ] =MHI_TRE_CMD_RESET_DWORD1 (chan);break ; +case MHI_CMD_STOP_CHAN : + cmd_tre->ptr =MHI_TRE_CMD_STOP_PTR ; + cmd_tre->dword[0 ] =MHI_TRE_CMD_STOP_DWORD0 ; + cmd_tre->dword[1 ] =MHI_TRE_CMD_STOP_DWORD1 (chan);
Quoted 8 lines
Quoted 8 lines
drivers/bus/mhi/core/main.c +1
-0+break ;case MHI_CMD_START_CHAN : cmd_tre->ptr =MHI_TRE_CMD_START_PTR ;cmd_tre->dword[0] =
MHI_TRE_CMD_START_DWORD0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Thanks,
Bhaumik
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/6] bus: mhi: core: Allow receiving a STOP channel command response
Quoted 36 lines · Bhaumik Bhatt
Hi Mani,
Quoted 19 lines · Manivannan Sadhasivam
Quoted 18 lines · Bhaumik Bhatt
Add support to receive the response to a STOP channel command to the MHI bus. If a client would like to STOP a channel instead of issuing a RESET to it, this would provide support for it.
Signed-off-by Bhaumik Bhatt <[email protected]>--- drivers/bus/mhi/core/init.c | 5 +++-- drivers/bus/mhi/core/main.c | 5 +++++ 2 files changed, 8 insertions(+), 2 deletions(-)drivers/bus/mhi/core/init.c +0
-0@@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev)mutex_lock (&mhi_chan->mutex);Quoted 11 lines
drivers/bus/mhi/core/init.c static int mhi_driver_remove(struct device *dev) · line 1271
Quoted 4 lines
drivers/bus/mhi/core/init.c +2
-2-if (ch_state[dir] ==MHI_CH_STATE_ENABLED && - !mhi_chan->offload_ch) + if ((ch_state[dir] == MHI_CH_STATE_ENABLED || + ch_state[dir] == MHI_CH_STATE_STOP) &&This enum is not defined in this patch so it'll break. Please add a separate
patch which introduces the new state enums alone and then have patches 1/2
as a followup.It is actually already defined and present in
internal.has enummhi_ch_state.
Quoted 7 lines
The old set of enums has
MHI_CH_STATE_STOPfrom enummhi_ch_stateand the new
enum I introduced isMHI_CH_STATE_TYPE_STOPfrom enum enummhi_ch_state_type.If it seems confusing, suggestions to renaming them are welcome.
Ah, sorry. I got confused with MHI_CH_STATE_TYPE_STOP and MHI_CH_STATE_STOP. Ignore my previous comment.
Thanks,
Mani
Quoted 43 lines
Quoted 2 lines
Also this change is not belonging to this commit I believe.
I included this change here because, a channel can be in "stopped" state and a user module could be unloaded or a crash could force a driver remove leading
us to come this check.If you think I should move it as a separate patch, let me know.
Quoted 21 lines
Thanks,
ManiQuoted 18 lines
drivers/bus/mhi/core/init.c +1
-0+ !mhi_chan->offload_ch)mhi_deinit_chan_ctxt (mhi_cntrl, mhi_chan); mhi_chan->ch_state =MHI_CH_STATE_DISABLED ;drivers/bus/mhi/core/main.c +5
-0@@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl, cmd_tre->dword[0 ] =MHI_TRE_CMD_RESET_DWORD0 ; cmd_tre->dword[1 ] =MHI_TRE_CMD_RESET_DWORD1 (chan);break ; +case MHI_CMD_STOP_CHAN : + cmd_tre->ptr =MHI_TRE_CMD_STOP_PTR ; + cmd_tre->dword[0 ] =MHI_TRE_CMD_STOP_DWORD0 ; + cmd_tre->dword[1 ] =MHI_TRE_CMD_STOP_DWORD1 (chan); +break ;Quoted 8 lines
Quoted 8 lines
drivers/bus/mhi/core/main.c +0
-0case MHI_CMD_START_CHAN : cmd_tre->ptr =MHI_TRE_CMD_START_PTR ;cmd_tre->dword[0] =
MHI_TRE_CMD_START_DWORD0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative ProjectThanks,
BhaumikSignature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 1/6] bus: mhi: core: Allow receiving a STOP channel command response
Quoted 42 lines · Manivannan Sadhasivam
Quoted 41 lines · Bhaumik Bhatt
Hi Mani,
Quoted 19 lines · Manivannan Sadhasivam
Quoted 18 lines · Bhaumik Bhatt
Add support to receive the response to a STOP channel command to the MHI bus. If a client would like to STOP a channel instead of issuing a RESET to it, this would provide support for it.
Signed-off-by Bhaumik Bhatt <[email protected]>--- drivers/bus/mhi/core/init.c | 5 +++-- drivers/bus/mhi/core/main.c | 5 +++++ 2 files changed, 8 insertions(+), 2 deletions(-)drivers/bus/mhi/core/init.c +0
-0@@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev)mutex_lock (&mhi_chan->mutex);Quoted 11 lines
drivers/bus/mhi/core/init.c static int mhi_driver_remove(struct device *dev) · line 1271
Quoted 4 lines
drivers/bus/mhi/core/init.c +2
-2-if (ch_state[dir] ==MHI_CH_STATE_ENABLED && - !mhi_chan->offload_ch) + if ((ch_state[dir] == MHI_CH_STATE_ENABLED || + ch_state[dir] == MHI_CH_STATE_STOP) &&This enum is not defined in this patch so it'll break. Please add a separate
patch which introduces the new state enums alone and then have patches 1/2
as a followup.It is actually already defined and present in
internal.has enummhi_ch_state.The old set of enums has
MHI_CH_STATE_STOPfrom enummhi_ch_stateand the new
enum I introduced isMHI_CH_STATE_TYPE_STOPfrom enum enummhi_ch_state_type.
Quoted 9 lines
Quoted 2 lines
If it seems confusing, suggestions to renaming them are welcome.
Ah, sorry. I got confused with
MHI_CH_STATE_TYPE_STOPandMHI_CH_STATE_STOP. Ignore my previous comment.Thanks,
Mani
No problem.
Quoted 35 lines
Quoted 35 lines
Quoted 2 lines
Also this change is not belonging to this commit I believe.
I included this change here because, a channel can be in "stopped" state and a user module could be unloaded or a crash could force a driver remove leading
us to come this check.If you think I should move it as a separate patch, let me know.
Quoted 27 lines
Thanks,
ManiQuoted 24 lines
drivers/bus/mhi/core/init.c +1
-0+ !mhi_chan->offload_ch)mhi_deinit_chan_ctxt (mhi_cntrl, mhi_chan); mhi_chan->ch_state =MHI_CH_STATE_DISABLED ;drivers/bus/mhi/core/main.c +5
-0@@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl, cmd_tre->dword[0 ] =MHI_TRE_CMD_RESET_DWORD0 ; cmd_tre->dword[1 ] =MHI_TRE_CMD_RESET_DWORD1 (chan);break ; +case MHI_CMD_STOP_CHAN : + cmd_tre->ptr =MHI_TRE_CMD_STOP_PTR ; + cmd_tre->dword[0 ] =MHI_TRE_CMD_STOP_DWORD0 ; + cmd_tre->dword[1 ] =MHI_TRE_CMD_STOP_DWORD1 (chan); +break ;case MHI_CMD_START_CHAN : cmd_tre->ptr =MHI_TRE_CMD_START_PTR ;cmd_tre->dword[0] =
MHI_TRE_CMD_START_DWORD0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
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
Thanks,
Bhaumik
---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v2 2/6 bus: mhi: core: Improvements to the channel handling state machine
In reply to Bhaumik BhattAdd support to enable sending the stop channel command and improve the channel handling state machine such that all commands go through a common function. This can help ensure that the state machine is not violated in any way and adheres to the MHI specification.
--- drivers/bus/mhi/core/init.c | 6 ++ drivers/bus/mhi/core/internal.h | 12 +++ drivers/bus/mhi/core/main.c | 163 ++++++++++++++++++++++++---------------- 3 files changed, 116 insertions(+), 65 deletions(-)
drivers/bus/mhi/core/init.c +6 -0
@@ -51,6 +51,12 @@ const char * const mhi_state_str[MHI_STATE_MAX] = { [MHI_STATE_SYS_ERR] = "SYS_ERR", }; +const char *const mhi_ch_state_type_str[MHI_CH_STATE_TYPE_MAX ] = { + [MHI_CH_STATE_TYPE_RESET ] ="RESET" , + [MHI_CH_STATE_TYPE_STOP ] ="STOP" , + [MHI_CH_STATE_TYPE_START ] ="START" , +}; +static const char *const mhi_pm_state_str[] = { [MHI_PM_STATE_DISABLE ] ="DISABLE" , [MHI_PM_STATE_POR ] ="POR" ,
drivers/bus/mhi/core/internal.h +12 -0
@@ -369,6 +369,18 @@ enum mhi_ch_state { MHI_CH_STATE_ERROR = 0x5, }; +enum mhi_ch_state_type { +MHI_CH_STATE_TYPE_RESET , +MHI_CH_STATE_TYPE_STOP , +MHI_CH_STATE_TYPE_START , +MHI_CH_STATE_TYPE_MAX , +}; + +extern const char *const mhi_ch_state_type_str[MHI_CH_STATE_TYPE_MAX ]; +#define TO_CH_STATE_TYPE_STR (state) (((state) >= MHI_CH_STATE_TYPE_MAX) ? \ + "INVALID_STATE" : \ + mhi_ch_state_type_str[state]) +#define MHI_INVALID_BRSTMODE (mode) (mode != MHI_DB_BRST_DISABLE && \ mode != MHI_DB_BRST_ENABLE)
drivers/bus/mhi/core/main.c +98 -65
202 lines not on this page · raw message
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/6] bus: mhi: core: Improvements to the channel handling state machine
Quoted 35 lines · Bhaumik Bhatt
Add support to enable sending the stop channel command and improve the channel handling state machine such that all commands go through a common function. This can help ensure that the state machine is not violated in any way and adheres to the MHI specification.
Signed-off-by Bhaumik Bhatt <[email protected]>--- drivers/bus/mhi/core/init.c | 6 ++ drivers/bus/mhi/core/internal.h | 12 +++ drivers/bus/mhi/core/main.c | 163 ++++++++++++++++++++++++---------------- 3 files changed, 116 insertions(+), 65 deletions(-)drivers/bus/mhi/core/init.c +6
-0@@ -51,6 +51,12 @@ const char * const mhi_state_str[MHI_STATE_MAX] = { [MHI_STATE_SYS_ERR] = "SYS_ERR", }; +const char *const mhi_ch_state_type_str[MHI_CH_STATE_TYPE_MAX ] = { + [MHI_CH_STATE_TYPE_RESET ] ="RESET" , + [MHI_CH_STATE_TYPE_STOP ] ="STOP" , + [MHI_CH_STATE_TYPE_START ] ="START" , +}; +static const char *const mhi_pm_state_str[] = { [MHI_PM_STATE_DISABLE ] ="DISABLE" , [MHI_PM_STATE_POR ] ="POR" ,drivers/bus/mhi/core/internal.h +0
-0
drivers/bus/mhi/core/internal.h enum mhi_ch_state { · line 378
Quoted 10 lines
drivers/bus/mhi/core/internal.h +7
-0@@ -369,6 +369,18 @@ enum mhi_ch_state { MHI_CH_STATE_ERROR = 0x5, }; +enum mhi_ch_state_type { +MHI_CH_STATE_TYPE_RESET , +MHI_CH_STATE_TYPE_STOP , +MHI_CH_STATE_TYPE_START , +MHI_CH_STATE_TYPE_MAX , +}; +
As said in previous patch, this needs to be moved to a separate one.
Quoted 16 lines
drivers/bus/mhi/core/internal.h +5
-0+extern const char *const mhi_ch_state_type_str[MHI_CH_STATE_TYPE_MAX ]; +#define TO_CH_STATE_TYPE_STR (state) (((state) >= MHI_CH_STATE_TYPE_MAX) ? \ + "INVALID_STATE" : \ + mhi_ch_state_type_str[state]) +#define MHI_INVALID_BRSTMODE (mode) (mode != MHI_DB_BRST_DISABLE && \ mode != MHI_DB_BRST_ENABLE)drivers/bus/mhi/core/main.c +0
-0@@ -1220,56 +1220,120 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl,return 0 ; }
[...]
drivers/bus/mhi/core/main.c int mhi_send_cmd(struct mhi_controller *mhi_cntrl, · line 1321
Quoted 7 lines
drivers/bus/mhi/core/main.c +7
-0+static void __mhi_unprepare_channel (struct mhi_controller *mhi_cntrl, +struct mhi_chan *mhi_chan) +{ +int ret; +struct device *dev = &mhi_cntrl->mhi_dev->dev; + +dev_dbg (dev,"Entered: unprepare channel:%d\n" , mhi_chan->chan);
Please get rid of these debug prints. We have some of them right now but they should be removed at some point. For debugging, use ftrace.
Thanks,
Mani
PATCH v2 3/6 bus: mhi: core: Add support to stop or start channel data transfers
In reply to Bhaumik BhattSome MHI client drivers may want to request a pause or halt of data transfer activity on their channels. Support for this does not exist and must be introduced, wherein the channel context is not reset or cleared but only the STOP channel command is issued. This would need to be paired with an API that allows resuming the data transfer activity on channels by use of the START channel command. This API assumes that the context information is already setup. Enable this using two new APIs, mhi_start_transfer() and mhi_stop_transfer().
--- drivers/bus/mhi/core/main.c | 41 +++++++++++++++++++++++++++++++++++++++++ include/linux/mhi.h | 19 +++++++++++++++++++ 2 files changed, 60 insertions(+)
drivers/bus/mhi/core/main.c +41 -0
@@ -1560,6 +1560,47 @@ void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev) }EXPORT_SYMBOL_GPL (mhi_unprepare_from_transfer); +static int mhi_update_transfer_state (struct mhi_device *mhi_dev, +enum mhi_ch_state_type to_state) +{ +struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl; +struct mhi_chan *mhi_chan; +int dir, ret; + +for (dir =0 ; dir <2 ; dir++) { + mhi_chan = dir ? mhi_dev->ul_chan : mhi_dev->dl_chan; + +if (!mhi_chan) +continue ; + +/* +* Bail out if one of the channels fail as client will reset +* both upon failure +*/ +mutex_lock (&mhi_chan->mutex); + ret =mhi_update_channel_state (mhi_cntrl, mhi_chan, to_state); +if (ret) { +mutex_unlock (&mhi_chan->mutex); +return ret; + } +mutex_unlock (&mhi_chan->mutex); + } + +return 0 ; +} + +int mhi_stop_transfer (struct mhi_device *mhi_dev) +{ +return mhi_update_transfer_state (mhi_dev,MHI_CH_STATE_TYPE_STOP ); +} +EXPORT_SYMBOL_GPL (mhi_stop_transfer); + +int mhi_start_transfer (struct mhi_device *mhi_dev) +{ +return mhi_update_transfer_state (mhi_dev,MHI_CH_STATE_TYPE_START ); +} +EXPORT_SYMBOL_GPL (mhi_start_transfer); +int mhi_poll (struct mhi_device *mhi_dev,u32 budget) {struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
include/linux/mhi.h +19 -0
@@ -702,6 +702,25 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);void mhi_unprepare_from_transfer (struct mhi_device *mhi_dev);/** +* mhi_stop_transfer - Pauses ongoing channel activity by issuing the STOP +* channel command to both UL and DL channels. This command +* does not reset the channel context and the client drivers +* can issue mhi_start_transfer to resume activity. +* @mhi_dev: Device associated with the channels +*/ +int mhi_stop_transfer (struct mhi_device *mhi_dev); + +/** +* mhi_start_transfer - Resumes channel activity by issuing the START channel +* command to both UL and DL channels. This command assumes +* the channel context is already setup and the client +* drivers can issue mhi_stop_transfer to pause activity if +* required. +* @mhi_dev: Device associated with the channels +*/ +int mhi_start_transfer (struct mhi_device *mhi_dev); + +/** * mhi_poll - Poll for any available data in DL direction * @mhi_dev: Device associated with the channels * @budget: # of events to process
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/6] bus: mhi: core: Add support to stop or start channel data transfers
Quoted 32 lines · Bhaumik Bhatt
Some MHI client drivers may want to request a pause or halt of data transfer activity on their channels. Support for this does not exist and must be introduced, wherein the channel context is not reset or cleared but only the STOP channel command is issued. This would need to be paired with an API that allows resuming the data transfer activity on channels by use of the START channel command. This API assumes that the context information is already setup. Enable this using two new APIs,
mhi_start_transfer()andmhi_stop_transfer().Signed-off-by Bhaumik Bhatt <[email protected]>--- drivers/bus/mhi/core/main.c | 41 +++++++++++++++++++++++++++++++++++++++++ include/linux/mhi.h | 19 +++++++++++++++++++ 2 files changed, 60 insertions(+)drivers/bus/mhi/core/main.c +8
-0@@ -1560,6 +1560,47 @@ void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev) }EXPORT_SYMBOL_GPL (mhi_unprepare_from_transfer); +static int mhi_update_transfer_state (struct mhi_device *mhi_dev, +enum mhi_ch_state_type to_state) +{ +struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl; +struct mhi_chan *mhi_chan; +int dir, ret; + +for (dir =0 ; dir <2 ; dir++) {
drivers/bus/mhi/core/main.c void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev) · line 1580
Quoted 10 lines
drivers/bus/mhi/core/main.c +10
-0+ mhi_chan = dir ? mhi_dev->ul_chan : mhi_dev->dl_chan; + +if (!mhi_chan) +continue ; + +/* +* Bail out if one of the channels fail as client will reset +* both upon failure +*/ +mutex_lock (&mhi_chan->mutex);
Hmm. The documentation about wait_for_completion*() used in mhi_update_channel_state()says below,
"As all variants of wait_for_completion() can (obviously) block for a long time depending on the nature of the activity they are waiting for, so in most cases you probably don't want to call this with held mutexes."
Quoted 43 lines
drivers/bus/mhi/core/main.c +23
-0+ ret =mhi_update_channel_state (mhi_cntrl, mhi_chan, to_state); +if (ret) { +mutex_unlock (&mhi_chan->mutex); +return ret; + } +mutex_unlock (&mhi_chan->mutex); + } + +return 0 ; +} + +int mhi_stop_transfer (struct mhi_device *mhi_dev) +{ +return mhi_update_transfer_state (mhi_dev,MHI_CH_STATE_TYPE_STOP ); +} +EXPORT_SYMBOL_GPL (mhi_stop_transfer); + +int mhi_start_transfer (struct mhi_device *mhi_dev) +{ +return mhi_update_transfer_state (mhi_dev,MHI_CH_STATE_TYPE_START ); +} +EXPORT_SYMBOL_GPL (mhi_start_transfer); +int mhi_poll (struct mhi_device *mhi_dev,u32 budget) {struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;include/linux/mhi.h +9
-0@@ -702,6 +702,25 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);void mhi_unprepare_from_transfer (struct mhi_device *mhi_dev);/** +* mhi_stop_transfer - Pauses ongoing channel activity by issuing the STOP +* channel command to both UL and DL channels. This command +* does not reset the channel context and the client drivers +* can issue mhi_start_transfer to resume activity. +* @mhi_dev: Device associated with the channels +*/ +int mhi_stop_transfer (struct mhi_device *mhi_dev); + +/**
include/linux/mhi.h int mhi_prepare_for_transfer(struct mhi_device *mhi_dev); · line 723
Quoted 10 lines
include/linux/mhi.h +10
-0+* mhi_start_transfer - Resumes channel activity by issuing the START channel +* command to both UL and DL channels. This command assumes +* the channel context is already setup and the client +* drivers can issue mhi_stop_transfer to pause activity if +* required. +* @mhi_dev: Device associated with the channels +*/ +int mhi_start_transfer (struct mhi_device *mhi_dev); + +/**
Align the comment header properly.
Thanks,
Mani
Quoted 7 lines
include/linux/mhi.h +0
-0* mhi_poll - Poll for any available data in DL direction * @mhi_dev: Device associated with the channels * @budget: # of events to process 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/6] bus: mhi: core: Add support to stop or start channel data transfers
Hi Mani,
Quoted 49 lines · Manivannan Sadhasivam
Quoted 34 lines · Bhaumik Bhatt
Some MHI client drivers may want to request a pause or halt of data transfer activity on their channels. Support for this does not exist and must be introduced, wherein the channel context is not reset or cleared but only the STOP channel command is issued. This would need to be paired with an API that allows resuming the data transfer activity on channels by use of the START channel command. This API assumes that the context information is already setup. Enable this using two new APIs,
mhi_start_transfer()andmhi_stop_transfer().Signed-off-by Bhaumik Bhatt <[email protected]>--- drivers/bus/mhi/core/main.c | 41 +++++++++++++++++++++++++++++++++++++++++ include/linux/mhi.h | 19 +++++++++++++++++++ 2 files changed, 60 insertions(+)drivers/bus/mhi/core/main.c +8
-0@@ -1560,6 +1560,47 @@ void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev) }EXPORT_SYMBOL_GPL (mhi_unprepare_from_transfer); +static int mhi_update_transfer_state (struct mhi_device *mhi_dev, +enum mhi_ch_state_type to_state) +{ +struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl; +struct mhi_chan *mhi_chan; +int dir, ret; + +for (dir =0 ; dir <2 ; dir++) {drivers/bus/mhi/core/main.c void mhi_unprepare_from_transfer(struct · line 1581
Quoted 10 lines
drivers/bus/mhi/core/main.c +10
-0+ mhi_chan = dir ? mhi_dev->ul_chan : mhi_dev->dl_chan; + +if (!mhi_chan) +continue ; + +/* +* Bail out if one of the channels fail as client will reset +* both upon failure +*/ +mutex_lock (&mhi_chan->mutex);Hmm. The documentation about wait_for_completion*() used in mhi_update_channel_state()says below,
Quoted 4 lines
"As all variants of
wait_for_completion()can (obviously) block for a long time depending on the nature of the activity they are waiting for, so in most cases you probably don't want to call this with held mutexes."
Yes, that is understood. The mhi_chan->mutex is only used to lock any channel enable/start/stop/disable type operations, since these have to be in order, it is essential that we wait for one of the operations to finish before the next one.
Also we avoid a race, for example, at a time when a device crash forces a driver "remove" call, while an operation to start/stop a channel is already going on.
Quoted 56 lines
Quoted 56 lines
drivers/bus/mhi/core/main.c +23
-0+ ret =mhi_update_channel_state (mhi_cntrl, mhi_chan, to_state); +if (ret) { +mutex_unlock (&mhi_chan->mutex); +return ret; + } +mutex_unlock (&mhi_chan->mutex); + } + +return 0 ; +} + +int mhi_stop_transfer (struct mhi_device *mhi_dev) +{ +return mhi_update_transfer_state (mhi_dev,MHI_CH_STATE_TYPE_STOP ); +} +EXPORT_SYMBOL_GPL (mhi_stop_transfer); + +int mhi_start_transfer (struct mhi_device *mhi_dev) +{ +return mhi_update_transfer_state (mhi_dev,MHI_CH_STATE_TYPE_START ); +} +EXPORT_SYMBOL_GPL (mhi_start_transfer); +int mhi_poll (struct mhi_device *mhi_dev,u32 budget) {drivers/bus/mhi/core/main.c +0
-0struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;include/linux/mhi.h +1
-0@@ -702,6 +702,25 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);void mhi_unprepare_from_transfer (struct mhi_device *mhi_dev);/** +* mhi_stop_transfer - Pauses ongoing channel activity by issuing the STOP
+ * channel command to both UL and DL channels.
This command
+ * does not reset the channel context and the
client drivers
+ * can issuemhi_start_transferto resume
activity.
+ * @mhi_dev: Device associated with the channels
+ */include/linux/mhi.h +4
-0+int mhi_stop_transfer (struct mhi_device *mhi_dev); + +/** +* mhi_start_transfer - Resumes channel activity by issuing the START channel
+ * command to both UL and DL channels. This
command assumes
+ * the channel context is already setup and the
client
+ * drivers can issuemhi_stop_transferto pause
activity if
Quoted 9 lines
include/linux/mhi.h int mhi_prepare_for_transfer(struct mhi_device *mhi_dev); · line 723
Quoted 6 lines
+ * required.
+ * @mhi_dev: Device associated with the channels
+ */include/linux/mhi.h +3
-0+int mhi_start_transfer (struct mhi_device *mhi_dev); + +/** Align the comment header properly.
So I am trying to follow the documentation style for other functions in the same file. Is there any particular format you want me to refer to?
I use all spaces for the lines after the first one to align them just like the rest of them.
Quoted 10 lines
Thanks,
ManiQuoted 7 lines
*
mhi_poll- Poll for any available data in DL direction
* @mhi_dev: Device associated with the channels
* @budget: # of events to process
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Thanks,
Bhaumik
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/6] bus: mhi: core: Add support to stop or start channel data transfers
Quoted 65 lines · Bhaumik Bhatt
Hi Mani,
Quoted 49 lines · Manivannan Sadhasivam
Quoted 34 lines · Bhaumik Bhatt
Some MHI client drivers may want to request a pause or halt of data transfer activity on their channels. Support for this does not exist and must be introduced, wherein the channel context is not reset or cleared but only the STOP channel command is issued. This would need to be paired with an API that allows resuming the data transfer activity on channels by use of the START channel command. This API assumes that the context information is already setup. Enable this using two new APIs,
mhi_start_transfer()andmhi_stop_transfer().Signed-off-by Bhaumik Bhatt <[email protected]>--- drivers/bus/mhi/core/main.c | 41 +++++++++++++++++++++++++++++++++++++++++ include/linux/mhi.h | 19 +++++++++++++++++++ 2 files changed, 60 insertions(+)drivers/bus/mhi/core/main.c +8
-0@@ -1560,6 +1560,47 @@ void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev) }EXPORT_SYMBOL_GPL (mhi_unprepare_from_transfer); +static int mhi_update_transfer_state (struct mhi_device *mhi_dev, +enum mhi_ch_state_type to_state) +{ +struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl; +struct mhi_chan *mhi_chan; +int dir, ret; + +for (dir =0 ; dir <2 ; dir++) {drivers/bus/mhi/core/main.c void mhi_unprepare_from_transfer(struct · line 1581
Quoted 10 lines
drivers/bus/mhi/core/main.c +10
-0+ mhi_chan = dir ? mhi_dev->ul_chan : mhi_dev->dl_chan; + +if (!mhi_chan) +continue ; + +/* +* Bail out if one of the channels fail as client will reset +* both upon failure +*/ +mutex_lock (&mhi_chan->mutex);Hmm. The documentation about wait_for_completion*() used in mhi_update_channel_state()says below,
Quoted 5 lines
"As all variants of
wait_for_completion()can (obviously) block for a long
time depending on the nature of the activity they are waiting for, so in most cases you probably don't want to call this with held mutexes."Yes, that is understood. The
mhi_chan->mutexis only used to lock any channel
enable/start/stop/disable type operations, since these have to be in order, it
is essential that we wait for one of the operations to finish before the next
one.
Quoted 4 lines
Also we avoid a race, for example, at a time when a device crash forces a driver
"remove" call, while an operation to start/stop a channel is already going on.
Can't you just drop the lock before calling wait_for_completion() and acquire later? You should add a comment for that also!
Quoted 65 lines
Quoted 56 lines
Quoted 56 lines
drivers/bus/mhi/core/main.c +23
-0+ ret =mhi_update_channel_state (mhi_cntrl, mhi_chan, to_state); +if (ret) { +mutex_unlock (&mhi_chan->mutex); +return ret; + } +mutex_unlock (&mhi_chan->mutex); + } + +return 0 ; +} + +int mhi_stop_transfer (struct mhi_device *mhi_dev) +{ +return mhi_update_transfer_state (mhi_dev,MHI_CH_STATE_TYPE_STOP ); +} +EXPORT_SYMBOL_GPL (mhi_stop_transfer); + +int mhi_start_transfer (struct mhi_device *mhi_dev) +{ +return mhi_update_transfer_state (mhi_dev,MHI_CH_STATE_TYPE_START ); +} +EXPORT_SYMBOL_GPL (mhi_start_transfer); +int mhi_poll (struct mhi_device *mhi_dev,u32 budget) {drivers/bus/mhi/core/main.c +0
-0struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;include/linux/mhi.h +1
-0@@ -702,6 +702,25 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);void mhi_unprepare_from_transfer (struct mhi_device *mhi_dev);/** +* mhi_stop_transfer - Pauses ongoing channel activity by issuing the STOP
+ * channel command to both UL and DL channels.
This command
+ * does not reset the channel context and the
client drivers
+ * can issuemhi_start_transferto resume
activity.
+ * @mhi_dev: Device associated with the channels
+ */include/linux/mhi.h +4
-0+int mhi_stop_transfer (struct mhi_device *mhi_dev); + +/** +* mhi_start_transfer - Resumes channel activity by issuing the START channel
+ * command to both UL and DL channels. This
command assumes
+ * the channel context is already setup and
the client
+ * drivers can issuemhi_stop_transferto
pause activity ifQuoted 9 lines
include/linux/mhi.h int mhi_prepare_for_transfer(struct mhi_device *mhi_dev); · line 723
Quoted 6 lines
+ * required.
+ * @mhi_dev: Device associated with the channels
+ */include/linux/mhi.h +3
-0+int mhi_start_transfer (struct mhi_device *mhi_dev); + +/** Align the comment header properly.
Quoted 8 lines
So I am trying to follow the documentation style for other functions in the same
file. Is there any particular format you want me to refer to?I use all spaces for the lines after the first one to align them just like the
rest of them.
The diff shows me of below style:
/**
+ *
+ *
...
+ /**
I just asked to fix this.
Thanks,
Mani
Quoted 17 lines
Quoted 11 lines
Thanks,
ManiQuoted 8 lines
*
mhi_poll- Poll for any available data in DL direction
* @mhi_dev: Device associated with the channels
* @budget: # of events to process
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative ProjectThanks,
BhaumikSignature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 3/6] bus: mhi: core: Add support to stop or start channel data transfers
Quoted 66 lines · Manivannan Sadhasivam
Quoted 65 lines · Bhaumik Bhatt
Hi Mani,
Quoted 49 lines · Manivannan Sadhasivam
Quoted 34 lines · Bhaumik Bhatt
Some MHI client drivers may want to request a pause or halt of data transfer activity on their channels. Support for this does not exist and must be introduced, wherein the channel context is not reset or cleared but only the STOP channel command is issued. This would need to be paired with an API that allows resuming the data transfer activity on channels by use of the START channel command. This API assumes that the context information is already setup. Enable this using two new APIs,
mhi_start_transfer()andmhi_stop_transfer().Signed-off-by Bhaumik Bhatt <[email protected]>--- drivers/bus/mhi/core/main.c | 41 +++++++++++++++++++++++++++++++++++++++++ include/linux/mhi.h | 19 +++++++++++++++++++ 2 files changed, 60 insertions(+)drivers/bus/mhi/core/main.c +8
-0@@ -1560,6 +1560,47 @@ void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev) }EXPORT_SYMBOL_GPL (mhi_unprepare_from_transfer); +static int mhi_update_transfer_state (struct mhi_device *mhi_dev, +enum mhi_ch_state_type to_state) +{ +struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl; +struct mhi_chan *mhi_chan; +int dir, ret; + +for (dir =0 ; dir <2 ; dir++) {drivers/bus/mhi/core/main.c void mhi_unprepare_from_transfer(struct · line 1581
Quoted 10 lines
drivers/bus/mhi/core/main.c +10
-0+ mhi_chan = dir ? mhi_dev->ul_chan : mhi_dev->dl_chan; + +if (!mhi_chan) +continue ; + +/* +* Bail out if one of the channels fail as client will reset +* both upon failure +*/ +mutex_lock (&mhi_chan->mutex);Hmm. The documentation about wait_for_completion*() used in mhi_update_channel_state()says below,
Quoted 5 lines
"As all variants of
wait_for_completion()can (obviously) block for a long
time depending on the nature of the activity they are waiting for, so in most cases you probably don't want to call this with held mutexes."Yes, that is understood. The
mhi_chan->mutexis only used to lock any channel
enable/start/stop/disable type operations, since these have to be in order, it
is essential that we wait for one of the operations to finish before the next
one.
Quoted 8 lines
Quoted 4 lines
Also we avoid a race, for example, at a time when a device crash forces a driver
"remove" call, while an operation to start/stop a channel is already going on.Can't you just drop the lock before calling
wait_for_completion()and acquire later? You should add a comment for that also!
So, based on the MHI device sending a command completion, we do not expect to receive it out of order and for tighter control, we also do not want to allow multiple commands to be issued unless one has been responded to or times out due to reasons outside of MHI's control.
We share a common completion variable for a channel and multiple commands issued for channel state changes can result in the completions being mishandled.
For example, if we send two commands for the same channel - stop and reset and end up dropping/re-acquiring the lock while waiting for stop channel completion as a response, we could see a reinit_completion() before the complete() and the waiter keeps waiting as a result because the complete() is not seen till the next command response comes in. We may also have to move to complete_all() for this purpose, as these could come from different threads.
Another example is a failure to move states could be seen when dropping and re-acquiring the lock if stop and start channel commands are issued back to back whereas we will not see the issue with current behavior as a start will wait for a stop to fully complete.
Quoted 76 lines
Quoted 65 lines
Quoted 56 lines
Quoted 56 lines
drivers/bus/mhi/core/main.c +23
-0+ ret =mhi_update_channel_state (mhi_cntrl, mhi_chan, to_state); +if (ret) { +mutex_unlock (&mhi_chan->mutex); +return ret; + } +mutex_unlock (&mhi_chan->mutex); + } + +return 0 ; +} + +int mhi_stop_transfer (struct mhi_device *mhi_dev) +{ +return mhi_update_transfer_state (mhi_dev,MHI_CH_STATE_TYPE_STOP ); +} +EXPORT_SYMBOL_GPL (mhi_stop_transfer); + +int mhi_start_transfer (struct mhi_device *mhi_dev) +{ +return mhi_update_transfer_state (mhi_dev,MHI_CH_STATE_TYPE_START ); +} +EXPORT_SYMBOL_GPL (mhi_start_transfer); +int mhi_poll (struct mhi_device *mhi_dev,u32 budget) {drivers/bus/mhi/core/main.c +0
-0struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;include/linux/mhi.h +1
-0@@ -702,6 +702,25 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);void mhi_unprepare_from_transfer (struct mhi_device *mhi_dev);/** +* mhi_stop_transfer - Pauses ongoing channel activity by issuing the STOP
+ * channel command to both UL and DL channels.
This command
+ * does not reset the channel context and the
client drivers
+ * can issuemhi_start_transferto resume
activity.
+ * @mhi_dev: Device associated with the channels
+ */include/linux/mhi.h +4
-0+int mhi_stop_transfer (struct mhi_device *mhi_dev); + +/** +* mhi_start_transfer - Resumes channel activity by issuing the START channel
+ * command to both UL and DL channels. This
command assumes
+ * the channel context is already setup and
the client
+ * drivers can issuemhi_stop_transferto
pause activity ifQuoted 9 lines
include/linux/mhi.h int mhi_prepare_for_transfer(struct mhi_device *mhi_dev); · line 723
Quoted 6 lines
+ * required.
+ * @mhi_dev: Device associated with the channels
+ */include/linux/mhi.h +3
-0+int mhi_start_transfer (struct mhi_device *mhi_dev); + +/** Align the comment header properly.
Quoted 8 lines
So I am trying to follow the documentation style for other functions in the same
file. Is there any particular format you want me to refer to?I use all spaces for the lines after the first one to align them just like the
rest of them.The diff shows me of below style:
Quoted 8 lines
/**
+ *
+ *
...
+ /**I just asked to fix this.
I don't see an extra space. Is that it? All functions I see are of the style:
/**
* foo - function desc
*
* @param: Desc
*
*/
Quoted 20 lines
Thanks,
ManiQuoted 17 lines
Quoted 11 lines
Thanks,
ManiQuoted 8 lines
*
mhi_poll- Poll for any available data in DL direction
* @mhi_dev: Device associated with the channels
* @budget: # of events to process
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative ProjectThanks,
Bhaumik
--
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
PATCH v2 4/6 bus: mhi: core: Check execution environment for channel before issuing reset
In reply to Bhaumik BhattA client can attempt to unprepare certain channels for transfer even after the execution environment they are supposed to run in has changed. In the event that happens, the device need not be notified of the reset and the host can proceed with clean up for the channel context and memory allocated for it on the host.
--- drivers/bus/mhi/core/main.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
drivers/bus/mhi/core/main.c +13 -0
@@ -1323,11 +1323,24 @@ static void __mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,/* no more processing events for this channel */ mutex_lock (&mhi_chan->mutex); +if (!(BIT (mhi_cntrl->ee) & mhi_chan->ee_mask)) { +dev_err (dev, +"Current EE: %s Required EE Mask: 0x%x for chan: %s\n" , +TO_MHI_EXEC_STR (mhi_cntrl->ee), mhi_chan->ee_mask, + mhi_chan->name); + goto exit_unprepare_channel; + } + ret =mhi_update_channel_state (mhi_cntrl, mhi_chan,MHI_CH_STATE_TYPE_RESET );if (ret)dev_err (dev,"Failed to reset channel, still resetting\n" ); +exit_unprepare_channel: +write_lock_irq (&mhi_chan->lock); + mhi_chan->ch_state =MHI_CH_STATE_DISABLED ; +write_unlock_irq (&mhi_chan->lock); +if (!mhi_chan->offload_ch) {mhi_reset_chan (mhi_cntrl, mhi_chan);mhi_deinit_chan_ctxt (mhi_cntrl, mhi_chan);
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v2 5/6 bus: mhi: core: Remove __ prefix for MHI channel unprepare function
In reply to Bhaumik BhattThe __mhi_unprepare_channel() API does not require the __ prefix. Get rid of it and make the internal function consistent with the other function names.
--- drivers/bus/mhi/core/main.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/bus/mhi/core/main.c +5 -5
@@ -1312,8 +1312,8 @@ static int mhi_update_channel_state(struct mhi_controller *mhi_cntrl,return -EINVAL ; } -static void __mhi_unprepare_channel (struct mhi_controller *mhi_cntrl, -struct mhi_chan *mhi_chan) +static void mhi_unprepare_channel (struct mhi_controller *mhi_cntrl, +struct mhi_chan *mhi_chan) {int ret;struct device *dev = &mhi_cntrl->mhi_dev->dev;
@@ -1433,7 +1433,7 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl, error_pre_alloc:mutex_unlock (&mhi_chan->mutex); -__mhi_unprepare_channel (mhi_cntrl, mhi_chan); +mhi_unprepare_channel (mhi_cntrl, mhi_chan);return ret; }
@@ -1550,7 +1550,7 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev)if (!mhi_chan)continue ; -__mhi_unprepare_channel (mhi_cntrl, mhi_chan); +mhi_unprepare_channel (mhi_cntrl, mhi_chan); }return ret;
@@ -1568,7 +1568,7 @@ void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev)if (!mhi_chan)continue ; -__mhi_unprepare_channel (mhi_cntrl, mhi_chan); +mhi_unprepare_channel (mhi_cntrl, mhi_chan); } }EXPORT_SYMBOL_GPL (mhi_unprepare_from_transfer);
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 5/6] bus: mhi: core: Remove __ prefix for MHI channel unprepare function
Quoted 5 lines · Bhaumik Bhatt
The
__mhi_unprepare_channel()API does not require the __ prefix. Get rid of it and make the internal function consistent with the other function names.Signed-off-by Bhaumik Bhatt <[email protected]>
Thanks,
Mani
Quoted 50 lines
--- drivers/bus/mhi/core/main.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)drivers/bus/mhi/core/main.c +5
-5@@ -1312,8 +1312,8 @@ static int mhi_update_channel_state(struct mhi_controller *mhi_cntrl,return -EINVAL ; } -static void __mhi_unprepare_channel (struct mhi_controller *mhi_cntrl, -struct mhi_chan *mhi_chan) +static void mhi_unprepare_channel (struct mhi_controller *mhi_cntrl, +struct mhi_chan *mhi_chan) {int ret;struct device *dev = &mhi_cntrl->mhi_dev->dev;@@ -1433,7 +1433,7 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl, error_pre_alloc:mutex_unlock (&mhi_chan->mutex); -__mhi_unprepare_channel (mhi_cntrl, mhi_chan); +mhi_unprepare_channel (mhi_cntrl, mhi_chan);return ret; }@@ -1550,7 +1550,7 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev)if (!mhi_chan)continue ; -__mhi_unprepare_channel (mhi_cntrl, mhi_chan); +mhi_unprepare_channel (mhi_cntrl, mhi_chan); }return ret;@@ -1568,7 +1568,7 @@ void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev)if (!mhi_chan)continue ; -__mhi_unprepare_channel (mhi_cntrl, mhi_chan); +mhi_unprepare_channel (mhi_cntrl, mhi_chan); } }EXPORT_SYMBOL_GPL (mhi_unprepare_from_transfer);Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v2 6/6 bus: mhi: Improve documentation on channel transfer setup APIs
In reply to Bhaumik BhattThe mhi_prepare_for_transfer() and mhi_unprepare_from_transfer() APIs could use better explanation, especially with the addition of two new APIs to start and stop the transfers on channels. Add better set of information for those APIs to avoid confusion going forward.
--- include/linux/mhi.h | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)
include/linux/mhi.h +16 -2
@@ -690,13 +690,27 @@ int mhi_device_get_sync(struct mhi_device *mhi_dev);void mhi_device_put (struct mhi_device *mhi_dev);/** -* mhi_prepare_for_transfer - Setup channel for data transfer +* mhi_prepare_for_transfer - Setup UL and DL channels for data transfer. +* Allocate and initialize the channel context and +* also issue the START channel command to both +* channels. Channels can be started only if both +* host and device execution environments match and +* channels are in a DISABLED state. * @mhi_dev: Device associated with the channels */ int mhi_prepare_for_transfer (struct mhi_device *mhi_dev);/** -* mhi_unprepare_from_transfer - Unprepare the channels +* mhi_unprepare_from_transfer - Reset UL and DL channels for data transfer. +* Issue the RESET channel command and let the +* device clean-up the context so no incoming +* transfers are seen on the host. Free memory +* associated with the context on host. If device +* is unresponsive, only perform a host side +* clean-up. Channels can be reset only if both +* host and device execution environments match +* and channels are in an ENABLED, STOPPED or +* SUSPENDED state. * @mhi_dev: Device associated with the channels */ void mhi_unprepare_from_transfer (struct mhi_device *mhi_dev);
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 6/6] bus: mhi: Improve documentation on channel transfer setup APIs
Quoted 16 lines · Bhaumik Bhatt
The
mhi_prepare_for_transfer()andmhi_unprepare_from_transfer()APIs could use better explanation, especially with the addition of two new APIs to start and stop the transfers on channels. Add better set of information for those APIs to avoid confusion going forward.Signed-off-by Bhaumik Bhatt <[email protected]>--- include/linux/mhi.h | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)include/linux/mhi.h +0
-0
include/linux/mhi.h int mhi_device_get_sync(struct mhi_device *mhi_dev); · line 698
Quoted 10 lines
include/linux/mhi.h +6
-1@@ -690,13 +690,27 @@ int mhi_device_get_sync(struct mhi_device *mhi_dev);void mhi_device_put (struct mhi_device *mhi_dev);/** -* mhi_prepare_for_transfer - Setup channel for data transfer +* mhi_prepare_for_transfer - Setup UL and DL channels for data transfer. +* Allocate and initialize the channel context and +* also issue the START channel command to both +* channels. Channels can be started only if both +* host and device execution environments match and +* channels are in a DISABLED state.
It'd be good if you can add a note about how this API differs from mhi_start_transfer() API. The content says the difference but an explicit comparision would be good.
Thanks,
Mani
Quoted 23 lines
include/linux/mhi.h +10
-1* @mhi_dev: Device associated with the channels */ int mhi_prepare_for_transfer (struct mhi_device *mhi_dev);/** -* mhi_unprepare_from_transfer - Unprepare the channels +* mhi_unprepare_from_transfer - Reset UL and DL channels for data transfer. +* Issue the RESET channel command and let the +* device clean-up the context so no incoming +* transfers are seen on the host. Free memory +* associated with the context on host. If device +* is unresponsive, only perform a host side +* clean-up. Channels can be reset only if both +* host and device execution environments match +* and channels are in an ENABLED, STOPPED or +* SUSPENDED state. * @mhi_dev: Device associated with the channels */ void mhi_unprepare_from_transfer (struct mhi_device *mhi_dev);Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project