From: firstname.lastname@example.org To: Manivannan Sadhasivam <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH] mhi: add MHI_STATE_M2 to resume success criteria Date: Mon, 24 May 2021 11:14:58 +0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20210521124530.GF70095@thinkpad> On 2021-05-21 20:45, Manivannan Sadhasivam wrote: > Hi, > > The patch subject should be, > > "bus: mhi: Wait for M2 state during system resume" > > We follow "bus: mhi:" prefix for all MHI patches. Also, the subject > should > clearly portray what the patch is intend to do. > > On Tue, Apr 20, 2021 at 11:53:39AM +0800, Baochen Qiang wrote: >> During system resume, mhi driver triggers M3->M0 transition and then >> waits > > s/mhi driver/MHI host > >> for target device to enter M0 state. Once done, the device queues a >> state >> change event into ctrl event ring and notify mhi dirver by raising an > > s/notify/notifies and s/mhi dirver/MHI host. MHI driver is somewhat > confusing > since we have the MHI device driver (QRTR etc...) as well. So just use > MHI host > everywhere. > >> interrupt, where a tasklet is scheduled to process this event. In most >> cases, >> the taklet is served timely and wait operation succeeds. >> > > s/taklet/tasklet > >> However, there are cases where CPU is busy and can not serve this >> tasklet > > a/can not/cannot > >> for some time. Once delay goes long enough, the device moves itself to >> M1 >> state and also interrupts mhi driver after inserting a new state >> change >> event to ctrl ring. Later CPU finally has time to process the ring, >> however >> there are two events in it now: >> 1. for M3->M0 event, which is processed first as queued first, >> tasklet handler updates device state to M0 and wakes up the task, >> i.e., the mhi driver. >> 2. for M0->M1 event, which is processed later, tasklet handler >> triggers M1->M2 transition and updates device state to M2 >> directly, >> then wakes up the mhi driver(if still sleeping on this wait >> queue). >> Note that although mhi driver has been woken up while processing the >> first >> event, it may still has no chance to run before the second event is >> processed. >> In other words, mhi driver has to keep waiting till timeout cause the >> M0 state >> has been missed. >> >> kernel log here: >> ... >> Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.911251] mhi >> 0000:06:00.0: Entered with PM state: M3, MHI state: M3 >> Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.917762] mhi >> 0000:06:00.0: State change event to state: M0 >> Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.917767] mhi >> 0000:06:00.0: State change event to state: M1 >> Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4338.788231] mhi >> 0000:06:00.0: Did not enter M0 state, MHI state: M2, PM state: M2 >> ... >> >> Fix this issue by simply adding M2 as a valid state for resume. >> >> Tested-on: WCN6855 hw2.0 PCI >> WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 >> >> Signed-off-by: Baochen Qiang <email@example.com> > > Could you please add a fixes tag as well? And this patch should be > backported to > stable kernels also, so please CC firstname.lastname@example.org. > > Thanks, > Mani > Thanks Mani. Will address them and send as V2. >> --- >> drivers/bus/mhi/core/pm.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c >> index ce73cfa63cb3..ca5f2feed9d5 100644 >> --- a/drivers/bus/mhi/core/pm.c >> +++ b/drivers/bus/mhi/core/pm.c >> @@ -900,6 +900,7 @@ int mhi_pm_resume(struct mhi_controller >> *mhi_cntrl) >> >> ret = wait_event_timeout(mhi_cntrl->state_event, >> mhi_cntrl->dev_state == MHI_STATE_M0 || >> + mhi_cntrl->dev_state == MHI_STATE_M2 || >> MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state), >> msecs_to_jiffies(mhi_cntrl->timeout_ms)); >> >> -- >> 2.25.1 >>
prev parent reply other threads:[~2021-05-24 3:15 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-20 3:53 Baochen Qiang 2021-05-03 23:55 ` Hemant Kumar 2021-05-21 12:45 ` Manivannan Sadhasivam 2021-05-24 3:14 ` bqiang [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] mhi: add MHI_STATE_M2 to resume success criteria' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).