Hi Bhaumik,
On Mon, 9 Nov 2020 at 23:44, Bhaumik Bhatt <bbhatt@xxxxxxxxxxxxxx> wrote:
>
> Some MHI clients may want to request for pausing or resuming of the
> data transfers for their channels. Enable them to do so using the new
> APIs provided for the same.
>
> Signed-off-by: Bhaumik Bhatt <bbhatt@xxxxxxxxxxxxxx>
> ---
> drivers/bus/mhi/core/main.c | 41 +++++++++++++++++++++++++++++++++++++++++
> include/linux/mhi.h | 16 ++++++++++++++++
> 2 files changed, 57 insertions(+)
>
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 1226933..01845c6 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -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_pause_transfer(struct mhi_device *mhi_dev)
> +{
> + return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_STOP);
> +}
> +EXPORT_SYMBOL_GPL(mhi_pause_transfer);
> +
> +int mhi_resume_transfer(struct mhi_device *mhi_dev)
> +{
> + return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_START);
> +}
> +EXPORT_SYMBOL_GPL(mhi_resume_transfer);
Look like it is stop and start, not pause and resume?
TBH maybe we should rework/clarify MHI core and having well-defined
states, maybe something like that:
1. When MHI core detects device for a driver, MHI core resets and
initializes the channel(s), then call client driver probe function
=> channel UNKNOWN->DISABLED state
=> channel DISABLED->ENABLED state
2. When driver is ready for sending data, drivers calls mhi_start_transfer
=> Channel is ENABLED->RUNNING state
3. Driver performs normal data transfers
4. The driver can suspend/resume transfer, it stops (suspend) the channel, can
=> Channel is RUNNING->STOP
=> Channel is STOP->RUNNING
...
5. When device is removed, MHI core reset the channel
=> channel is (RUNNING|STOP) -> DISABLED
Today mhi_prepare_for_transfer performs both ENABLE and RUNNING
transition, the idea would be to keep channel enabling/disabling in
the MHI core (before/after driver probe/remove) and channel start/stop
managed by the client driver.
Regards,
Loic
