From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Jeffrey Hugo <jhugo@codeaurora.org>
Cc: Bhaumik Vasav Bhatt <bbhatt@codeaurora.org>,
Hemant Kumar <hemantk@codeaurora.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] bus: mhi: core: Handle syserr during power_up
Date: Mon, 13 Apr 2020 19:04:47 +0530 [thread overview]
Message-ID: <20200413133447.GA19124@Mani-XPS-13-9360> (raw)
In-Reply-To: <79feeb0b-0837-c5b6-087d-856c3e238c67@codeaurora.org>
On Fri, Apr 10, 2020 at 03:39:57PM -0600, Jeffrey Hugo wrote:
> On 4/10/2020 2:37 PM, Bhaumik Vasav Bhatt wrote:
> > Hi Jeff,
> >
> > We will always have the mhi_intvec_handler registered and trigger your
> > wake_up state event when you write MHI RESET. BHI INTVEC IRQ using
> > mhi_cntrl->irq[0] is _not_ unregistered once you enter AMSS EE.
>
> I understand it is not unregistered. However mhi_cntrl->irq[0] may be
> reserved for BHI, and thus only exercised by PBL EE. Where as,
> mhi_cntrl->irq[1..N] may be only exercised by AMSS EE. mhi_intvec_handler is
> not called in response to mhi_cntrl->irq[1..N].
>
> Additionally, I re-reviewed the MHI spec, and I don't see where the spec
> requires the device to issue an interrupt upon completion of the RESET
> request.
>
> Under section 3.5, step 11 states -
>
> "The host must poll for the value of the RESET bit to detect the completion
> of the reset procedure by the device (RESET is set to 0)."
>
If this is the scenario then we need to change all of the wait_event_timeout()
implementation for MHI RESET in current stack to polling.
Or the interrupt generation is not defined in spec (sheet) but part of the
existing implementation?
Thanks,
Mani
> So, by this, my proposed solution appears to be spec compliant, where as
> what Hemant proposed is not.
>
> >
> > So, your below assumption is not true:
> > >>>So, if we are in the PBL EE, we would expect to see the BHI
> > interrupt, but if we are in the AMSS EE, we would expect to see a MHI
> > interrupt.
> >
> > At the start of mhi_async_power_up(), you've already registered for the
> > BHI interrupt as we do setup for IRQ and it is only unregistered from
> > power down if power up on the same cycle was a success.
>
> You seem to have misunderstood my point. If the BHI irq is only for BHI
> activity, which is activity restricted to the PBL EE, and the MHI
> interrupt(s) are restricted to MHI activity, which for the purposes of this
> discussion only occur in the AMSS EE, then my assumption is correct. When
> the device is in PBL EE, we should only observe BHI irqs, and when the
> device is in AMSS EE, we should only observe MHI irqs.
>
> This is a statement of what IRQ lines the device is raising, and not a
> statement of what handlers the host has, or has not registered.
>
> Again, if the BHI irq is only generated in the PBL EE, and we rely on the
> BHI irq for "sensing" the state_event - we will never see the state_event in
> the AMSS EE, unless the same IRQ line is used for both MHI and BHI (which is
> only a select set of usecases, and not universal).
>
> >
> > On 4/10/20 8:03 AM, Jeffrey Hugo wrote:
> > > On 4/9/2020 6:55 PM, Hemant Kumar wrote:
> > > >
> > > > On 4/7/20 9:50 AM, Jeffrey Hugo wrote:
> > > > > The MHI device may be in the syserr state when we attempt to init it in
> > > > > power_up(). Since we have no local state, the handling is simple -
> > > > > reset the device and wait for it to transition out of the reset state.
> > > > >
> > > > > Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
> > > > > ---
> > > > > drivers/bus/mhi/core/pm.c | 20 ++++++++++++++++++++
> > > > > 1 file changed, 20 insertions(+)
> > > > >
> > > > > diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> > > > > index 52690cb..3285c9e 100644
> > > > > --- a/drivers/bus/mhi/core/pm.c
> > > > > +++ b/drivers/bus/mhi/core/pm.c
> > > > > @@ -9,6 +9,7 @@
> > > > > #include <linux/dma-direction.h>
> > > > > #include <linux/dma-mapping.h>
> > > > > #include <linux/interrupt.h>
> > > > > +#include <linux/iopoll.h>
> > > > > #include <linux/list.h>
> > > > > #include <linux/mhi.h>
> > > > > #include <linux/module.h>
> > > > > @@ -760,6 +761,7 @@ static void mhi_deassert_dev_wake(struct
> > > > > mhi_controller *mhi_cntrl,
> > > > > int mhi_async_power_up(struct mhi_controller *mhi_cntrl)
> > > > > {
> > > > > + enum mhi_state state;
> > > > > enum mhi_ee_type current_ee;
> > > > > enum dev_st_transition next_state;
> > > > > struct device *dev = &mhi_cntrl->mhi_dev->dev;
> > > > > @@ -829,6 +831,24 @@ int mhi_async_power_up(struct
> > > > > mhi_controller *mhi_cntrl)
> > > > > goto error_bhi_offset;
> > > > > }
> > > > > + state = mhi_get_mhi_state(mhi_cntrl);
> > > > > + if (state == MHI_STATE_SYS_ERR) {
> > > > > + mhi_set_mhi_state(mhi_cntrl, MHI_STATE_RESET);
> > > > > + ret = readl_poll_timeout(mhi_cntrl->regs + MHICTRL, val,
> > > > > + !(val & MHICTRL_RESET_MASK), 1000,
> > > > > + mhi_cntrl->timeout_ms * 1000);
> > > > can we use this instead of polling because MSI is configures and
> > > > int_vec handler is registered
> > > >
> > > > wait_event_timeout(mhi_cntrl->state_event,
> > > > MHI_PM_IN_FATAL_STATE(mhi_cntrl->pm_state) ||
> > > > mhi_read_reg_field(mhi_cntrl, base, MHICTRL,
> > > > MHICTRL_RESET_MASK,
> > > > MHICTRL_RESET_SHIFT, &reset) || !reset ,
> > > > msecs_to_jiffies(mhi_cntrl->timeout_ms));
> > > >
> > > > 1) In case of MHI_PM_IN_FATAL_STATE we would not be accessing MHI reg
> > > > 2) Consistent with current MHI driver code.
> > >
> > > I'm not sure this works in the way you intend.
> > >
> > > state_event is linked to the intvec, which is the BHI interrupt. I
> > > don't see that the state_event is triggered in the MHI interrupt
> > > path (mhi_irq_handler). So, if we are in the PBL EE, we would
> > > expect to see the BHI interrupt, but if we are in the AMSS EE, we
> > > would expect to see a MHI interrupt.
> > >
> > > Now, for my concerned usecase, those two interrupts happen to be the
> > > same interrupt, so both will get triggered, but I don't expect that
> > > to be the same for all usecases.
> > >
> > > So, with the solution I propose, we exit the wait (poll loop) as
> > > soon as we see the register change values.
> > >
> > > With the solution you propose, if we only get the MHI interrupt,
> > > we'll have to wait out the entire timeout value, and then check the
> > > register. In this scenario, we are almost guaranteed to wait for
> > > longer than necessary.
> > >
> > > Did I miss something?
> > >
> > > > > + if (ret) {
> > > > > + dev_info(dev, "Failed to reset MHI due to
> > > > > syserr state\n");
> > > > > + goto error_bhi_offset;
> > > > > + }
> > > > > +
> > > > > + /*
> > > > > + * device cleares INTVEC as part of RESET processing,
> > > > > + * re-program it
> > > > > + */
> > > > > + mhi_write_reg(mhi_cntrl, mhi_cntrl->bhi, BHI_INTVEC, 0);
> > > > > + }
> > > > > +
> > > > > /* Transition to next state */
> > > > > next_state = MHI_IN_PBL(current_ee) ?
> > > > > DEV_ST_TRANSITION_PBL : DEV_ST_TRANSITION_READY;
> > > >
> > >
> > >
>
>
> --
> Jeffrey Hugo
> Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2020-04-13 13:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 16:50 [PATCH v2 0/5] Misc MHI fixes Jeffrey Hugo
2020-04-07 16:50 ` [PATCH v2 1/5] bus: mhi: core: Handle syserr during power_up Jeffrey Hugo
2020-04-10 0:55 ` Hemant Kumar
2020-04-10 15:03 ` Jeffrey Hugo
2020-04-10 20:37 ` Bhaumik Vasav Bhatt
2020-04-10 21:39 ` Jeffrey Hugo
2020-04-13 13:34 ` Manivannan Sadhasivam [this message]
2020-04-13 14:01 ` Jeffrey Hugo
2020-04-21 6:08 ` Manivannan Sadhasivam
2020-04-22 20:16 ` Jeffrey Hugo
2020-04-07 16:50 ` [PATCH v2 2/5] bus: mhi: core: Make sure to powerdown if mhi_sync_power_up fails Jeffrey Hugo
2020-04-08 1:34 ` hemantk
2020-04-08 16:19 ` Jeffrey Hugo
2020-04-07 16:50 ` [PATCH v2 3/5] bus: mhi: core: Remove link_status() callback Jeffrey Hugo
2020-04-07 16:50 ` [PATCH v2 4/5] bus: mhi: core: Offload register accesses to the controller Jeffrey Hugo
2020-04-07 16:50 ` [PATCH v2 5/5] bus: mhi: core: Fix typo in comment Jeffrey Hugo
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 \
--in-reply-to=20200413133447.GA19124@Mani-XPS-13-9360 \
--to=manivannan.sadhasivam@linaro.org \
--cc=bbhatt@codeaurora.org \
--cc=hemantk@codeaurora.org \
--cc=jhugo@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).