* [PATCH v5 1/9] bus: mhi: core: Allow sending the STOP channel command
2021-01-08 20:54 [PATCH v5 0/9] Updates to MHI channel handling Bhaumik Bhatt
@ 2021-01-08 20:54 ` Bhaumik Bhatt
2021-01-21 11:25 ` Manivannan Sadhasivam
2021-01-08 20:54 ` [PATCH v5 2/9] bus: mhi: core: Allow channel to be disabled from stopped state Bhaumik Bhatt
` (7 subsequent siblings)
8 siblings, 1 reply; 21+ messages in thread
From: Bhaumik Bhatt @ 2021-01-08 20:54 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain,
Bhaumik Bhatt
Add support to allow sending the STOP channel command. If a
client driver would like to STOP a channel and have the device
retain the channel context instead of issuing a RESET to it and
clearing the context, this would provide support for it after
the ability to send this command is exposed to clients.
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
---
drivers/bus/mhi/core/main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 8576b0f..c22d7df 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1224,6 +1224,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,
a Linux Foundation Collaborative Project
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCH v5 1/9] bus: mhi: core: Allow sending the STOP channel command
2021-01-08 20:54 ` [PATCH v5 1/9] bus: mhi: core: Allow sending the STOP channel command Bhaumik Bhatt
@ 2021-01-21 11:25 ` Manivannan Sadhasivam
0 siblings, 0 replies; 21+ messages in thread
From: Manivannan Sadhasivam @ 2021-01-21 11:25 UTC (permalink / raw)
To: Bhaumik Bhatt; +Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain
On Fri, Jan 08, 2021 at 12:54:49PM -0800, Bhaumik Bhatt wrote:
> Add support to allow sending the STOP channel command. If a
> client driver would like to STOP a channel and have the device
> retain the channel context instead of issuing a RESET to it and
> clearing the context, this would provide support for it after
> the ability to send this command is exposed to clients.
>
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Thanks,
Mani
> ---
> drivers/bus/mhi/core/main.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 8576b0f..c22d7df 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -1224,6 +1224,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,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v5 2/9] bus: mhi: core: Allow channel to be disabled from stopped state
2021-01-08 20:54 [PATCH v5 0/9] Updates to MHI channel handling Bhaumik Bhatt
2021-01-08 20:54 ` [PATCH v5 1/9] bus: mhi: core: Allow sending the STOP channel command Bhaumik Bhatt
@ 2021-01-08 20:54 ` Bhaumik Bhatt
2021-01-21 11:35 ` Manivannan Sadhasivam
2021-01-08 20:54 ` [PATCH v5 3/9] bus: mhi: core: Improvements to the channel handling state machine Bhaumik Bhatt
` (6 subsequent siblings)
8 siblings, 1 reply; 21+ messages in thread
From: Bhaumik Bhatt @ 2021-01-08 20:54 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain,
Bhaumik Bhatt
If a channel was explicitly stopped but not reset, allow it to
move to a disabled state so that the channel context can be
cleaned up after a driver remove is issued. Since the channel
remained in stopped state, its context on the device is not
cleared. Allow this move if a client driver module is unloaded
or a device crash occurs.
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
---
drivers/bus/mhi/core/init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index aa575d3..03c5786 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -1293,7 +1293,8 @@ static int mhi_driver_remove(struct device *dev)
mutex_lock(&mhi_chan->mutex);
- if (ch_state[dir] == MHI_CH_STATE_ENABLED &&
+ 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);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCH v5 2/9] bus: mhi: core: Allow channel to be disabled from stopped state
2021-01-08 20:54 ` [PATCH v5 2/9] bus: mhi: core: Allow channel to be disabled from stopped state Bhaumik Bhatt
@ 2021-01-21 11:35 ` Manivannan Sadhasivam
0 siblings, 0 replies; 21+ messages in thread
From: Manivannan Sadhasivam @ 2021-01-21 11:35 UTC (permalink / raw)
To: Bhaumik Bhatt; +Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain
On Fri, Jan 08, 2021 at 12:54:50PM -0800, Bhaumik Bhatt wrote:
> If a channel was explicitly stopped but not reset, allow it to
> move to a disabled state so that the channel context can be
> cleaned up after a driver remove is issued. Since the channel
> remained in stopped state, its context on the device is not
> cleared. Allow this move if a client driver module is unloaded
> or a device crash occurs.
>
The commit message needs to be improved. The stopped channel will by default
move to stopped state during mhi_driver_remove(). So this patch is not at all
doing anything other than clearing the context for stopped channels.
Please fix it!
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Thanks,
Mani
> ---
> drivers/bus/mhi/core/init.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index aa575d3..03c5786 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -1293,7 +1293,8 @@ static int mhi_driver_remove(struct device *dev)
>
> mutex_lock(&mhi_chan->mutex);
>
> - if (ch_state[dir] == MHI_CH_STATE_ENABLED &&
> + 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);
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v5 3/9] bus: mhi: core: Improvements to the channel handling state machine
2021-01-08 20:54 [PATCH v5 0/9] Updates to MHI channel handling Bhaumik Bhatt
2021-01-08 20:54 ` [PATCH v5 1/9] bus: mhi: core: Allow sending the STOP channel command Bhaumik Bhatt
2021-01-08 20:54 ` [PATCH v5 2/9] bus: mhi: core: Allow channel to be disabled from stopped state Bhaumik Bhatt
@ 2021-01-08 20:54 ` Bhaumik Bhatt
2021-01-21 14:43 ` Manivannan Sadhasivam
2021-01-08 20:54 ` [PATCH v5 4/9] bus: mhi: core: Clear configuration from channel context during reset Bhaumik Bhatt
` (5 subsequent siblings)
8 siblings, 1 reply; 21+ messages in thread
From: Bhaumik Bhatt @ 2021-01-08 20:54 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain,
Bhaumik Bhatt
Improve the channel handling state machine such that all commands
go through a common function and validation process to ensure
that the state machine is not violated in any way and adheres to
the MHI specification.
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
---
drivers/bus/mhi/core/init.c | 6 ++
drivers/bus/mhi/core/internal.h | 12 +++
drivers/bus/mhi/core/main.c | 166 +++++++++++++++++++++++-----------------
3 files changed, 114 insertions(+), 70 deletions(-)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 03c5786..482b365 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -54,6 +54,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",
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 6f80ec3..7e3aac1 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -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)
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index c22d7df..081fdf0 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1250,56 +1250,118 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl,
return 0;
}
-static void __mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
- struct mhi_chan *mhi_chan)
+static int mhi_update_channel_state(struct mhi_controller *mhi_cntrl,
+ struct mhi_chan *mhi_chan,
+ enum mhi_ch_state_type to_state)
{
- int ret;
struct device *dev = &mhi_cntrl->mhi_dev->dev;
+ enum mhi_cmd_type cmd = MHI_CMD_NOP;
+ int ret = -EIO;
+
+ dev_dbg(dev, "Updating channel %s(%d) state to: %s\n", mhi_chan->name,
+ mhi_chan->chan, TO_CH_STATE_TYPE_STR(to_state));
+
+ switch (to_state) {
+ case MHI_CH_STATE_TYPE_RESET:
+ write_lock_irq(&mhi_chan->lock);
+ if (mhi_chan->ch_state != MHI_CH_STATE_STOP &&
+ mhi_chan->ch_state != MHI_CH_STATE_ENABLED &&
+ mhi_chan->ch_state != MHI_CH_STATE_SUSPENDED) {
+ write_unlock_irq(&mhi_chan->lock);
+ goto exit_invalid_state;
+ }
+ mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
+ write_unlock_irq(&mhi_chan->lock);
- dev_dbg(dev, "Entered: unprepare channel:%d\n", mhi_chan->chan);
+ cmd = MHI_CMD_RESET_CHAN;
+ break;
+ case MHI_CH_STATE_TYPE_STOP:
+ if (mhi_chan->ch_state != MHI_CH_STATE_ENABLED)
+ goto exit_invalid_state;
- /* no more processing events for this channel */
- mutex_lock(&mhi_chan->mutex);
- write_lock_irq(&mhi_chan->lock);
- if (mhi_chan->ch_state != MHI_CH_STATE_ENABLED &&
- mhi_chan->ch_state != MHI_CH_STATE_SUSPENDED) {
- write_unlock_irq(&mhi_chan->lock);
- mutex_unlock(&mhi_chan->mutex);
- return;
+ cmd = MHI_CMD_STOP_CHAN;
+ break;
+ case MHI_CH_STATE_TYPE_START:
+ if (mhi_chan->ch_state != MHI_CH_STATE_STOP &&
+ mhi_chan->ch_state != MHI_CH_STATE_DISABLED)
+ goto exit_invalid_state;
+
+ cmd = MHI_CMD_START_CHAN;
+ break;
+ default:
+ goto exit_invalid_state;
}
- mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
- write_unlock_irq(&mhi_chan->lock);
+ /* bring host and device out of suspended states */
+ ret = mhi_device_get_sync(mhi_cntrl->mhi_dev);
+ if (ret)
+ return ret;
+ mhi_cntrl->runtime_get(mhi_cntrl);
reinit_completion(&mhi_chan->completion);
- read_lock_bh(&mhi_cntrl->pm_lock);
- if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
- read_unlock_bh(&mhi_cntrl->pm_lock);
- goto error_invalid_state;
+ ret = mhi_send_cmd(mhi_cntrl, mhi_chan, cmd);
+ if (ret) {
+ dev_err(dev, "Failed to send %s(%d) %s command\n",
+ mhi_chan->name, mhi_chan->chan,
+ TO_CH_STATE_TYPE_STR(to_state));
+ goto exit_command_failure;
}
- mhi_cntrl->wake_toggle(mhi_cntrl);
- read_unlock_bh(&mhi_cntrl->pm_lock);
+ ret = wait_for_completion_timeout(&mhi_chan->completion,
+ msecs_to_jiffies(mhi_cntrl->timeout_ms));
+ if (!ret || mhi_chan->ccs != MHI_EV_CC_SUCCESS) {
+ dev_err(dev, "Failed to receive %s(%d) %s command completion\n",
+ mhi_chan->name, mhi_chan->chan,
+ TO_CH_STATE_TYPE_STR(to_state));
+ ret = -EIO;
+ goto exit_command_failure;
+ }
- mhi_cntrl->runtime_get(mhi_cntrl);
+ ret = 0;
+
+ if (to_state != MHI_CH_STATE_TYPE_RESET) {
+ write_lock_irq(&mhi_chan->lock);
+ mhi_chan->ch_state = (to_state == MHI_CH_STATE_TYPE_START) ?
+ MHI_CH_STATE_ENABLED : MHI_CH_STATE_STOP;
+ write_unlock_irq(&mhi_chan->lock);
+ }
+
+ dev_dbg(dev, "Channel %s(%d) state change to %s successful\n",
+ mhi_chan->name, mhi_chan->chan, TO_CH_STATE_TYPE_STR(to_state));
+
+exit_command_failure:
mhi_cntrl->runtime_put(mhi_cntrl);
- ret = mhi_send_cmd(mhi_cntrl, mhi_chan, MHI_CMD_RESET_CHAN);
- if (ret)
- goto error_invalid_state;
+ mhi_device_put(mhi_cntrl->mhi_dev);
- /* even if it fails we will still reset */
- ret = wait_for_completion_timeout(&mhi_chan->completion,
- msecs_to_jiffies(mhi_cntrl->timeout_ms));
- if (!ret || mhi_chan->ccs != MHI_EV_CC_SUCCESS)
- dev_err(dev,
- "Failed to receive cmd completion, still resetting\n");
+ return ret;
+
+exit_invalid_state:
+ dev_err(dev, "Channel %s(%d) update to %s not allowed\n",
+ mhi_chan->name, mhi_chan->chan, TO_CH_STATE_TYPE_STR(to_state));
+
+ return -EINVAL;
+}
+
+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;
+
+ /* no more processing events for this channel */
+ mutex_lock(&mhi_chan->mutex);
+
+ 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");
-error_invalid_state:
if (!mhi_chan->offload_ch) {
mhi_reset_chan(mhi_cntrl, mhi_chan);
mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
}
- dev_dbg(dev, "chan:%d successfully resetted\n", mhi_chan->chan);
+ dev_dbg(dev, "chan:%d successfully reset\n", mhi_chan->chan);
+
mutex_unlock(&mhi_chan->mutex);
}
@@ -1309,8 +1371,6 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
int ret = 0;
struct device *dev = &mhi_cntrl->mhi_dev->dev;
- dev_dbg(dev, "Preparing channel: %d\n", mhi_chan->chan);
-
if (!(BIT(mhi_cntrl->ee) & mhi_chan->ee_mask)) {
dev_err(dev,
"Current EE: %s Required EE Mask: 0x%x for chan: %s\n",
@@ -1321,14 +1381,6 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
mutex_lock(&mhi_chan->mutex);
- /* If channel is not in disable state, do not allow it to start */
- if (mhi_chan->ch_state != MHI_CH_STATE_DISABLED) {
- ret = -EIO;
- dev_dbg(dev, "channel: %d is not in disabled state\n",
- mhi_chan->chan);
- goto error_init_chan;
- }
-
/* Check of client manages channel context for offload channels */
if (!mhi_chan->offload_ch) {
ret = mhi_init_chan_ctxt(mhi_cntrl, mhi_chan);
@@ -1336,34 +1388,11 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
goto error_init_chan;
}
- reinit_completion(&mhi_chan->completion);
- read_lock_bh(&mhi_cntrl->pm_lock);
- if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
- read_unlock_bh(&mhi_cntrl->pm_lock);
- ret = -EIO;
- goto error_pm_state;
- }
-
- mhi_cntrl->wake_toggle(mhi_cntrl);
- read_unlock_bh(&mhi_cntrl->pm_lock);
- mhi_cntrl->runtime_get(mhi_cntrl);
- mhi_cntrl->runtime_put(mhi_cntrl);
-
- ret = mhi_send_cmd(mhi_cntrl, mhi_chan, MHI_CMD_START_CHAN);
+ ret = mhi_update_channel_state(mhi_cntrl, mhi_chan,
+ MHI_CH_STATE_TYPE_START);
if (ret)
goto error_pm_state;
- ret = wait_for_completion_timeout(&mhi_chan->completion,
- msecs_to_jiffies(mhi_cntrl->timeout_ms));
- if (!ret || mhi_chan->ccs != MHI_EV_CC_SUCCESS) {
- ret = -EIO;
- goto error_pm_state;
- }
-
- write_lock_irq(&mhi_chan->lock);
- mhi_chan->ch_state = MHI_CH_STATE_ENABLED;
- write_unlock_irq(&mhi_chan->lock);
-
/* Pre-allocate buffer for xfer ring */
if (mhi_chan->pre_alloc) {
int nr_el = get_nr_avail_ring_elements(mhi_cntrl,
@@ -1401,9 +1430,6 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
mutex_unlock(&mhi_chan->mutex);
- dev_dbg(dev, "Chan: %d successfully moved to start state\n",
- mhi_chan->chan);
-
return 0;
error_pm_state:
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCH v5 3/9] bus: mhi: core: Improvements to the channel handling state machine
2021-01-08 20:54 ` [PATCH v5 3/9] bus: mhi: core: Improvements to the channel handling state machine Bhaumik Bhatt
@ 2021-01-21 14:43 ` Manivannan Sadhasivam
0 siblings, 0 replies; 21+ messages in thread
From: Manivannan Sadhasivam @ 2021-01-21 14:43 UTC (permalink / raw)
To: Bhaumik Bhatt; +Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain
On Fri, Jan 08, 2021 at 12:54:51PM -0800, Bhaumik Bhatt wrote:
> Improve the channel handling state machine such that all commands
> go through a common function and validation process to ensure
> that the state machine is not violated in any way and adheres to
> the MHI specification.
>
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
> ---
> drivers/bus/mhi/core/init.c | 6 ++
> drivers/bus/mhi/core/internal.h | 12 +++
> drivers/bus/mhi/core/main.c | 166 +++++++++++++++++++++++-----------------
> 3 files changed, 114 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index 03c5786..482b365 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -54,6 +54,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",
> diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
> index 6f80ec3..7e3aac1 100644
> --- a/drivers/bus/mhi/core/internal.h
> +++ b/drivers/bus/mhi/core/internal.h
> @@ -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)
>
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index c22d7df..081fdf0 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -1250,56 +1250,118 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl,
> return 0;
> }
>
> -static void __mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
> - struct mhi_chan *mhi_chan)
> +static int mhi_update_channel_state(struct mhi_controller *mhi_cntrl,
> + struct mhi_chan *mhi_chan,
> + enum mhi_ch_state_type to_state)
> {
> - int ret;
> struct device *dev = &mhi_cntrl->mhi_dev->dev;
> + enum mhi_cmd_type cmd = MHI_CMD_NOP;
> + int ret = -EIO;
> +
> + dev_dbg(dev, "Updating channel %s(%d) state to: %s\n", mhi_chan->name,
> + mhi_chan->chan, TO_CH_STATE_TYPE_STR(to_state));
Instead of explicitly using the channel name and its id, you should be
able to use `mhi_chan->mhi_dev->dev` so that dev_dbg() can provide that
information for you. For instance,
mhi0_IPCR: Updating channel state to RESET
Do it for all instances below.
> +
> + switch (to_state) {
> + case MHI_CH_STATE_TYPE_RESET:
> + write_lock_irq(&mhi_chan->lock);
> + if (mhi_chan->ch_state != MHI_CH_STATE_STOP &&
> + mhi_chan->ch_state != MHI_CH_STATE_ENABLED &&
> + mhi_chan->ch_state != MHI_CH_STATE_SUSPENDED) {
> + write_unlock_irq(&mhi_chan->lock);
> + goto exit_invalid_state;
> + }
> + mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
> + write_unlock_irq(&mhi_chan->lock);
>
> - dev_dbg(dev, "Entered: unprepare channel:%d\n", mhi_chan->chan);
> + cmd = MHI_CMD_RESET_CHAN;
> + break;
> + case MHI_CH_STATE_TYPE_STOP:
> + if (mhi_chan->ch_state != MHI_CH_STATE_ENABLED)
> + goto exit_invalid_state;
>
> - /* no more processing events for this channel */
> - mutex_lock(&mhi_chan->mutex);
> - write_lock_irq(&mhi_chan->lock);
> - if (mhi_chan->ch_state != MHI_CH_STATE_ENABLED &&
> - mhi_chan->ch_state != MHI_CH_STATE_SUSPENDED) {
> - write_unlock_irq(&mhi_chan->lock);
> - mutex_unlock(&mhi_chan->mutex);
> - return;
> + cmd = MHI_CMD_STOP_CHAN;
> + break;
> + case MHI_CH_STATE_TYPE_START:
> + if (mhi_chan->ch_state != MHI_CH_STATE_STOP &&
> + mhi_chan->ch_state != MHI_CH_STATE_DISABLED)
> + goto exit_invalid_state;
> +
> + cmd = MHI_CMD_START_CHAN;
> + break;
> + default:
> + goto exit_invalid_state;
> }
>
> - mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
> - write_unlock_irq(&mhi_chan->lock);
> + /* bring host and device out of suspended states */
> + ret = mhi_device_get_sync(mhi_cntrl->mhi_dev);
You are sneaking in a change here. Please add it to the commit description.
> + if (ret)
> + return ret;
> + mhi_cntrl->runtime_get(mhi_cntrl);
>
> reinit_completion(&mhi_chan->completion);
> - read_lock_bh(&mhi_cntrl->pm_lock);
> - if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
> - read_unlock_bh(&mhi_cntrl->pm_lock);
> - goto error_invalid_state;
> + ret = mhi_send_cmd(mhi_cntrl, mhi_chan, cmd);
> + if (ret) {
> + dev_err(dev, "Failed to send %s(%d) %s command\n",
> + mhi_chan->name, mhi_chan->chan,
> + TO_CH_STATE_TYPE_STR(to_state));
> + goto exit_command_failure;
> }
>
> - mhi_cntrl->wake_toggle(mhi_cntrl);
> - read_unlock_bh(&mhi_cntrl->pm_lock);
> + ret = wait_for_completion_timeout(&mhi_chan->completion,
> + msecs_to_jiffies(mhi_cntrl->timeout_ms));
> + if (!ret || mhi_chan->ccs != MHI_EV_CC_SUCCESS) {
> + dev_err(dev, "Failed to receive %s(%d) %s command completion\n",
> + mhi_chan->name, mhi_chan->chan,
> + TO_CH_STATE_TYPE_STR(to_state));
> + ret = -EIO;
> + goto exit_command_failure;
> + }
>
> - mhi_cntrl->runtime_get(mhi_cntrl);
> + ret = 0;
> +
> + if (to_state != MHI_CH_STATE_TYPE_RESET) {
> + write_lock_irq(&mhi_chan->lock);
> + mhi_chan->ch_state = (to_state == MHI_CH_STATE_TYPE_START) ?
> + MHI_CH_STATE_ENABLED : MHI_CH_STATE_STOP;
> + write_unlock_irq(&mhi_chan->lock);
> + }
> +
> + dev_dbg(dev, "Channel %s(%d) state change to %s successful\n",
> + mhi_chan->name, mhi_chan->chan, TO_CH_STATE_TYPE_STR(to_state));
> +
> +exit_command_failure:
> mhi_cntrl->runtime_put(mhi_cntrl);
> - ret = mhi_send_cmd(mhi_cntrl, mhi_chan, MHI_CMD_RESET_CHAN);
> - if (ret)
> - goto error_invalid_state;
> + mhi_device_put(mhi_cntrl->mhi_dev);
>
> - /* even if it fails we will still reset */
> - ret = wait_for_completion_timeout(&mhi_chan->completion,
> - msecs_to_jiffies(mhi_cntrl->timeout_ms));
> - if (!ret || mhi_chan->ccs != MHI_EV_CC_SUCCESS)
> - dev_err(dev,
> - "Failed to receive cmd completion, still resetting\n");
> + return ret;
> +
This is not a recommended way to handle error paths. There should be a
single return for all error paths. Please fix it.
> +exit_invalid_state:
> + dev_err(dev, "Channel %s(%d) update to %s not allowed\n",
> + mhi_chan->name, mhi_chan->chan, TO_CH_STATE_TYPE_STR(to_state));
> +
> + return -EINVAL;
> +}
> +
> +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;
> +
> + /* no more processing events for this channel */
Move this comment below.
Thanks,
Mani
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v5 4/9] bus: mhi: core: Clear configuration from channel context during reset
2021-01-08 20:54 [PATCH v5 0/9] Updates to MHI channel handling Bhaumik Bhatt
` (2 preceding siblings ...)
2021-01-08 20:54 ` [PATCH v5 3/9] bus: mhi: core: Improvements to the channel handling state machine Bhaumik Bhatt
@ 2021-01-08 20:54 ` Bhaumik Bhatt
2021-01-21 14:47 ` Manivannan Sadhasivam
2021-01-08 20:54 ` [PATCH v5 5/9] bus: mhi: core: Add support to stop or start channel data transfers Bhaumik Bhatt
` (4 subsequent siblings)
8 siblings, 1 reply; 21+ messages in thread
From: Bhaumik Bhatt @ 2021-01-08 20:54 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain,
Bhaumik Bhatt
When clearing up the channel context after client drivers are
done using channels, the configuration is currently not being
reset entirely. Ensure this is done to appropriately handle
issues where clients unaware of the context state end up calling
functions which expect a context.
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
---
drivers/bus/mhi/core/init.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 482b365..30eef19 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -558,6 +558,7 @@ void mhi_deinit_chan_ctxt(struct mhi_controller *mhi_cntrl,
struct mhi_ring *buf_ring;
struct mhi_ring *tre_ring;
struct mhi_chan_ctxt *chan_ctxt;
+ u32 tmp;
buf_ring = &mhi_chan->buf_ring;
tre_ring = &mhi_chan->tre_ring;
@@ -568,7 +569,19 @@ void mhi_deinit_chan_ctxt(struct mhi_controller *mhi_cntrl,
vfree(buf_ring->base);
buf_ring->base = tre_ring->base = NULL;
+ tre_ring->ctxt_wp = NULL;
chan_ctxt->rbase = 0;
+ chan_ctxt->rlen = 0;
+ chan_ctxt->rp = 0;
+ chan_ctxt->wp = 0;
+
+ tmp = chan_ctxt->chcfg;
+ tmp &= ~CHAN_CTX_CHSTATE_MASK;
+ tmp |= (MHI_CH_STATE_DISABLED << CHAN_CTX_CHSTATE_SHIFT);
+ chan_ctxt->chcfg = tmp;
+
+ /* Update to all cores */
+ smp_wmb();
}
int mhi_init_chan_ctxt(struct mhi_controller *mhi_cntrl,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCH v5 4/9] bus: mhi: core: Clear configuration from channel context during reset
2021-01-08 20:54 ` [PATCH v5 4/9] bus: mhi: core: Clear configuration from channel context during reset Bhaumik Bhatt
@ 2021-01-21 14:47 ` Manivannan Sadhasivam
0 siblings, 0 replies; 21+ messages in thread
From: Manivannan Sadhasivam @ 2021-01-21 14:47 UTC (permalink / raw)
To: Bhaumik Bhatt; +Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain
On Fri, Jan 08, 2021 at 12:54:52PM -0800, Bhaumik Bhatt wrote:
> When clearing up the channel context after client drivers are
> done using channels, the configuration is currently not being
> reset entirely. Ensure this is done to appropriately handle
> issues where clients unaware of the context state end up calling
> functions which expect a context.
>
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Thanks,
Mani
> ---
> drivers/bus/mhi/core/init.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index 482b365..30eef19 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -558,6 +558,7 @@ void mhi_deinit_chan_ctxt(struct mhi_controller *mhi_cntrl,
> struct mhi_ring *buf_ring;
> struct mhi_ring *tre_ring;
> struct mhi_chan_ctxt *chan_ctxt;
> + u32 tmp;
>
> buf_ring = &mhi_chan->buf_ring;
> tre_ring = &mhi_chan->tre_ring;
> @@ -568,7 +569,19 @@ void mhi_deinit_chan_ctxt(struct mhi_controller *mhi_cntrl,
> vfree(buf_ring->base);
>
> buf_ring->base = tre_ring->base = NULL;
> + tre_ring->ctxt_wp = NULL;
> chan_ctxt->rbase = 0;
> + chan_ctxt->rlen = 0;
> + chan_ctxt->rp = 0;
> + chan_ctxt->wp = 0;
> +
> + tmp = chan_ctxt->chcfg;
> + tmp &= ~CHAN_CTX_CHSTATE_MASK;
> + tmp |= (MHI_CH_STATE_DISABLED << CHAN_CTX_CHSTATE_SHIFT);
> + chan_ctxt->chcfg = tmp;
> +
> + /* Update to all cores */
> + smp_wmb();
> }
>
> int mhi_init_chan_ctxt(struct mhi_controller *mhi_cntrl,
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v5 5/9] bus: mhi: core: Add support to stop or start channel data transfers
2021-01-08 20:54 [PATCH v5 0/9] Updates to MHI channel handling Bhaumik Bhatt
` (3 preceding siblings ...)
2021-01-08 20:54 ` [PATCH v5 4/9] bus: mhi: core: Clear configuration from channel context during reset Bhaumik Bhatt
@ 2021-01-08 20:54 ` Bhaumik Bhatt
2021-01-21 14:50 ` Manivannan Sadhasivam
2021-01-08 20:54 ` [PATCH v5 6/9] bus: mhi: core: Check channel execution environment before issuing reset Bhaumik Bhatt
` (3 subsequent siblings)
8 siblings, 1 reply; 21+ messages in thread
From: Bhaumik Bhatt @ 2021-01-08 20:54 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain,
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() and
mhi_stop_transfer().
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
---
drivers/bus/mhi/core/main.c | 50 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/mhi.h | 19 +++++++++++++++++
2 files changed, 69 insertions(+)
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 081fdf0..a84e6aa 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1583,6 +1583,56 @@ 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 device *dev = &mhi_cntrl->mhi_dev->dev;
+ struct mhi_chan *mhi_chan;
+ struct mhi_chan_ctxt *chan_ctxt;
+ 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 fails as client will reset
+ * both upon failure
+ */
+ mutex_lock(&mhi_chan->mutex);
+ chan_ctxt = &mhi_cntrl->mhi_ctxt->chan_ctxt[mhi_chan->chan];
+ if (!(chan_ctxt->chcfg & CHAN_CTX_CHSTATE_MASK)) {
+ mutex_unlock(&mhi_chan->mutex);
+ dev_err(dev, "Channel %s(%u) context not initialized\n",
+ mhi_chan->name, mhi_chan->chan);
+ return -EINVAL;
+ }
+ 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;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index fe65554..b5e11ba 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -715,6 +715,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
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCH v5 5/9] bus: mhi: core: Add support to stop or start channel data transfers
2021-01-08 20:54 ` [PATCH v5 5/9] bus: mhi: core: Add support to stop or start channel data transfers Bhaumik Bhatt
@ 2021-01-21 14:50 ` Manivannan Sadhasivam
2021-02-04 20:25 ` Bhaumik Bhatt
0 siblings, 1 reply; 21+ messages in thread
From: Manivannan Sadhasivam @ 2021-01-21 14:50 UTC (permalink / raw)
To: Bhaumik Bhatt; +Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain
On Fri, Jan 08, 2021 at 12:54:53PM -0800, Bhaumik Bhatt wrote:
> 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() and
> mhi_stop_transfer().
>
Do you have any user for these APIs? If not then please post it when one
is available.
Thanks,
Mani
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v5 5/9] bus: mhi: core: Add support to stop or start channel data transfers
2021-01-21 14:50 ` Manivannan Sadhasivam
@ 2021-02-04 20:25 ` Bhaumik Bhatt
0 siblings, 0 replies; 21+ messages in thread
From: Bhaumik Bhatt @ 2021-02-04 20:25 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain
On 2021-01-21 06:50 AM, Manivannan Sadhasivam wrote:
> On Fri, Jan 08, 2021 at 12:54:53PM -0800, Bhaumik Bhatt wrote:
>> 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() and
>> mhi_stop_transfer().
>>
>
> Do you have any user for these APIs? If not then please post it when
> one
> is available.
>
> Thanks,
> Mani
I will be dropping this patch in upcoming v6 series.
Thanks,
Bhaumik
---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v5 6/9] bus: mhi: core: Check channel execution environment before issuing reset
2021-01-08 20:54 [PATCH v5 0/9] Updates to MHI channel handling Bhaumik Bhatt
` (4 preceding siblings ...)
2021-01-08 20:54 ` [PATCH v5 5/9] bus: mhi: core: Add support to stop or start channel data transfers Bhaumik Bhatt
@ 2021-01-08 20:54 ` Bhaumik Bhatt
2021-01-21 15:12 ` Manivannan Sadhasivam
2021-01-08 20:54 ` [PATCH v5 7/9] bus: mhi: core: Remove __ prefix for MHI channel unprepare function Bhaumik Bhatt
` (2 subsequent siblings)
8 siblings, 1 reply; 21+ messages in thread
From: Bhaumik Bhatt @ 2021-01-08 20:54 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain,
Bhaumik Bhatt
A 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 as the device will no longer be able
to respond to such a request.
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
---
drivers/bus/mhi/core/main.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index a84e6aa..ec720fe 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1351,11 +1351,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);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCH v5 6/9] bus: mhi: core: Check channel execution environment before issuing reset
2021-01-08 20:54 ` [PATCH v5 6/9] bus: mhi: core: Check channel execution environment before issuing reset Bhaumik Bhatt
@ 2021-01-21 15:12 ` Manivannan Sadhasivam
2021-02-04 20:23 ` Bhaumik Bhatt
0 siblings, 1 reply; 21+ messages in thread
From: Manivannan Sadhasivam @ 2021-01-21 15:12 UTC (permalink / raw)
To: Bhaumik Bhatt; +Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain
On Fri, Jan 08, 2021 at 12:54:54PM -0800, Bhaumik Bhatt wrote:
> A client can attempt to unprepare certain channels for transfer even
> after the execution environment they are supposed to run in has changed.
Just out of curiosity, under what circumstances it can happen? We don't
have any in kernel user for the mhi_unprepare_from_transfer() API :/
> 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 as the device will no longer be able
> to respond to such a request.
>
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
> ---
> drivers/bus/mhi/core/main.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index a84e6aa..ec720fe 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -1351,11 +1351,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);
Again, use channel's struct dev here.
Thanks,
Mani
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH v5 6/9] bus: mhi: core: Check channel execution environment before issuing reset
2021-01-21 15:12 ` Manivannan Sadhasivam
@ 2021-02-04 20:23 ` Bhaumik Bhatt
0 siblings, 0 replies; 21+ messages in thread
From: Bhaumik Bhatt @ 2021-02-04 20:23 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain
Hi Mani,
On 2021-01-21 07:12 AM, Manivannan Sadhasivam wrote:
> On Fri, Jan 08, 2021 at 12:54:54PM -0800, Bhaumik Bhatt wrote:
>> A client can attempt to unprepare certain channels for transfer even
>> after the execution environment they are supposed to run in has
>> changed.
>
> Just out of curiosity, under what circumstances it can happen? We don't
> have any in kernel user for the mhi_unprepare_from_transfer() API :/
>
We do and it's the qrtr-mhi driver where we can potentially see this
happen.
Mainly, since they want to undo whatever they have done in probe(), this
can
come from the remove() after MHI power down is initiated.
I have updated this patch in upcoming v6 series with a debug message as
we only
want to proceed with clean-up directly.
>> 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 as the device will no longer be
>> able
>> to respond to such a request.
>>
>> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
>> Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
>> ---
>> drivers/bus/mhi/core/main.c | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
>> index a84e6aa..ec720fe 100644
>> --- a/drivers/bus/mhi/core/main.c
>> +++ b/drivers/bus/mhi/core/main.c
>> @@ -1351,11 +1351,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);
>
> Again, use channel's struct dev here.
>
Done.
> Thanks,
> Mani
Thanks,
Bhaumik
---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v5 7/9] bus: mhi: core: Remove __ prefix for MHI channel unprepare function
2021-01-08 20:54 [PATCH v5 0/9] Updates to MHI channel handling Bhaumik Bhatt
` (5 preceding siblings ...)
2021-01-08 20:54 ` [PATCH v5 6/9] bus: mhi: core: Check channel execution environment before issuing reset Bhaumik Bhatt
@ 2021-01-08 20:54 ` Bhaumik Bhatt
2021-01-08 20:54 ` [PATCH v5 8/9] bus: mhi: Improve documentation on channel transfer setup APIs Bhaumik Bhatt
2021-01-08 20:54 ` [PATCH v5 9/9] bus: mhi: core: Do not clear channel context more than once Bhaumik Bhatt
8 siblings, 0 replies; 21+ messages in thread
From: Bhaumik Bhatt @ 2021-01-08 20:54 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain,
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 <bbhatt@codeaurora.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
---
drivers/bus/mhi/core/main.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index ec720fe..8039964 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1342,8 +1342,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;
@@ -1456,7 +1456,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;
}
@@ -1573,7 +1573,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;
@@ -1591,7 +1591,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);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH v5 8/9] bus: mhi: Improve documentation on channel transfer setup APIs
2021-01-08 20:54 [PATCH v5 0/9] Updates to MHI channel handling Bhaumik Bhatt
` (6 preceding siblings ...)
2021-01-08 20:54 ` [PATCH v5 7/9] bus: mhi: core: Remove __ prefix for MHI channel unprepare function Bhaumik Bhatt
@ 2021-01-08 20:54 ` Bhaumik Bhatt
2021-01-08 20:54 ` [PATCH v5 9/9] bus: mhi: core: Do not clear channel context more than once Bhaumik Bhatt
8 siblings, 0 replies; 21+ messages in thread
From: Bhaumik Bhatt @ 2021-01-08 20:54 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain,
Bhaumik Bhatt
The 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.
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
---
include/linux/mhi.h | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index b5e11ba..94c5075 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -703,13 +703,35 @@ 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. Calling the
+ * mhi_start_transfer() function is not required
+ * afterwards as channels are already started. This
+ * function also initializes the channel context
+ * whereas mhi_start_transfer() can only be used to
+ * issue the start channel command once the context
+ * is setup.
* @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. Calling mhi_stop_transfer() is
+ * not required before calling this function as it
+ * will only stop transfers, not reset channels.
* @mhi_dev: Device associated with the channels
*/
void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH v5 9/9] bus: mhi: core: Do not clear channel context more than once
2021-01-08 20:54 [PATCH v5 0/9] Updates to MHI channel handling Bhaumik Bhatt
` (7 preceding siblings ...)
2021-01-08 20:54 ` [PATCH v5 8/9] bus: mhi: Improve documentation on channel transfer setup APIs Bhaumik Bhatt
@ 2021-01-08 20:54 ` Bhaumik Bhatt
2021-01-09 4:39 ` Hemant Kumar
2021-01-21 15:15 ` Manivannan Sadhasivam
8 siblings, 2 replies; 21+ messages in thread
From: Bhaumik Bhatt @ 2021-01-08 20:54 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain,
Bhaumik Bhatt
When clearing the channel context, calling mhi_free_coherent()
more than once can result in kernel warnings such as "trying to
free invalid coherent area". Prevent extra work by adding a check
to skip calling mhi_deinit_chan_ctxt() if the client driver has
already disabled the channels.
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
---
drivers/bus/mhi/core/init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 30eef19..272f350 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -1314,6 +1314,7 @@ static int mhi_driver_remove(struct device *dev)
if ((ch_state[dir] == MHI_CH_STATE_ENABLED ||
ch_state[dir] == MHI_CH_STATE_STOP) &&
+ mhi_chan->ch_state != MHI_CH_STATE_DISABLED &&
!mhi_chan->offload_ch)
mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCH v5 9/9] bus: mhi: core: Do not clear channel context more than once
2021-01-08 20:54 ` [PATCH v5 9/9] bus: mhi: core: Do not clear channel context more than once Bhaumik Bhatt
@ 2021-01-09 4:39 ` Hemant Kumar
2021-01-21 15:15 ` Manivannan Sadhasivam
1 sibling, 0 replies; 21+ messages in thread
From: Hemant Kumar @ 2021-01-09 4:39 UTC (permalink / raw)
To: Bhaumik Bhatt, manivannan.sadhasivam
Cc: linux-arm-msm, jhugo, linux-kernel, loic.poulain
On 1/8/21 12:54 PM, Bhaumik Bhatt wrote:
> When clearing the channel context, calling mhi_free_coherent()
> more than once can result in kernel warnings such as "trying to
> free invalid coherent area". Prevent extra work by adding a check
> to skip calling mhi_deinit_chan_ctxt() if the client driver has
> already disabled the channels.
>
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> ---
> drivers/bus/mhi/core/init.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index 30eef19..272f350 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -1314,6 +1314,7 @@ static int mhi_driver_remove(struct device *dev)
>
> if ((ch_state[dir] == MHI_CH_STATE_ENABLED ||
> ch_state[dir] == MHI_CH_STATE_STOP) &&
> + mhi_chan->ch_state != MHI_CH_STATE_DISABLED &&
> !mhi_chan->offload_ch)
> mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
>
>
Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v5 9/9] bus: mhi: core: Do not clear channel context more than once
2021-01-08 20:54 ` [PATCH v5 9/9] bus: mhi: core: Do not clear channel context more than once Bhaumik Bhatt
2021-01-09 4:39 ` Hemant Kumar
@ 2021-01-21 15:15 ` Manivannan Sadhasivam
1 sibling, 0 replies; 21+ messages in thread
From: Manivannan Sadhasivam @ 2021-01-21 15:15 UTC (permalink / raw)
To: Bhaumik Bhatt; +Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, loic.poulain
On Fri, Jan 08, 2021 at 12:54:57PM -0800, Bhaumik Bhatt wrote:
> When clearing the channel context, calling mhi_free_coherent()
> more than once can result in kernel warnings such as "trying to
> free invalid coherent area". Prevent extra work by adding a check
> to skip calling mhi_deinit_chan_ctxt() if the client driver has
> already disabled the channels.
>
Again, please explain where and when exactly you spotted this issue.
Thanks,
Mani
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> ---
> drivers/bus/mhi/core/init.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index 30eef19..272f350 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -1314,6 +1314,7 @@ static int mhi_driver_remove(struct device *dev)
>
> if ((ch_state[dir] == MHI_CH_STATE_ENABLED ||
> ch_state[dir] == MHI_CH_STATE_STOP) &&
> + mhi_chan->ch_state != MHI_CH_STATE_DISABLED &&
> !mhi_chan->offload_ch)
> mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply [flat|nested] 21+ messages in thread