[regression] mhi: ath11k resume fails on some devices

[Carl Huang]

On 2021-09-23 16:59, Manivannan Sadhasivam wrote:
> On Thu, Sep 23, 2021 at 04:34:43PM +0800, Carl Huang wrote:
>> On 2021-09-17 01:19, Manivannan Sadhasivam wrote:
>> > On Thu, Sep 16, 2021 at 07:42:02PM +0300, Kalle Valo wrote:
>> > > Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org> writes:
>> > >
>> > > > On Thu, Sep 16, 2021 at 01:18:22PM +0200, Loic Poulain wrote:
>> > > >> Le jeu. 16 sept. 2021 à 13:12, Manivannan Sadhasivam <
>> > > >> manivannan.sadhasivam at linaro.org> a écrit :
>> > > >>
>> > > >
>> > > > [...]
>> > > >
>> > > >> > If things seems to work fine without that patch, then it implies that
>> > > >> > setting M0
>> > > >> > state works during resume. I think we should just revert that patch.
>> > > >> >
>> > > >> > Loic, did that patch fix any issue for you or it was a cosmetic fix only?
>> > > >>
>> > > >>
>> > > >> It fixes sdx modem resuming issue, without that we don’t know modem needs
>> > > >> to be reinitialized.
>> > > >>
>> > > >
>> > > > Okay. Then in that case, the recovery mechanism has to be added to the ath11k
>> > > > MHI controller.
>> > >
>> > > What does that mean in practise, do you have any pointers or
>> > > examples? I
>> > > have no clue what you are proposing :)
>> > >
>> >
>> > Take a look at the mhi_pci_recovery_work() function below:
>> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/bus/mhi/pci_generic.c#n610
>> >
>> > You need to implement something similar that basically powers up the MHI
>> > endpoint (QCA6390) in case pm_resume() fails. At minimum, you need to
>> > call
>> > below functions:
>> >
>> > # Check if the device is powered on. If yes, then power it down to bring
>> > it back
>> > mhi_power_down()
>> > mhi_unprepare_after_power_down()
>> >
>> > # Power up the device
>> > mhi_prepare_for_power_up()
>> > mhi_sync_power_up()
>> >
>> > This implies that the WLAN device has been powered off during suspend,
>> > so the
>> > resume fails and we are bringing the device back to working state.
>> >
>> This is fine for platform which doesn't provide power supply during 
>> suspend.
>> But NUC has power supply in suspend state.
> 
> If NUC retains power supply during suspend then it should work with 
> that commit.
> During resume, the device is expected to be in M3 state and that's what 
> the
> commit verifies.
> 
> If the device is in a different state, then most likely the device have 
> power
> cycled.
> 
But the tricky thing here is that upstream QCA6390 doesn't have recovery 
mechanism to download
firmware again, so QCA6390 has no way to work after a power cycle.

>> QCA6390 on NUC works after just reverting this commit also proves NUC 
>> has
>> power supply in
>> suspend state.
>> 
> 
> That's because we allowed the device to be in any state during resume 
> and if it
> responds to the M0 transition it worked.
> 
>> The reason is MHI-STATUS register can't be read somehow in M3 state on 
>> NUC.
> 
> No, that's not correct.
> 
>> Does the MHI spec state that MHI-STATUS register can be read in M3 
>> state?
>> 
> 
> Yes, all the MHI registers are accessible in all states. During M3, 
> both MHI
> host and device (if supported) will transition to D3 Cold. Then during 
> resume,
> host will switch to D0 link state and will also notify the device to 
> enter D0.
> 
> For aid debugging, please see the state the device is in during 
> mhi_pm_resume().
> You can use below diff:
> 
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index fb99e3727155..482d55dd209e 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -898,6 +898,9 @@ int mhi_pm_resume(struct mhi_controller *mhi_cntrl)
>         if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state))
>                 return -EIO;
> 
> +       dev_info(dev, "Device state: %s\n",
> +                TO_MHI_STATE_STR(mhi_get_mhi_state(mhi_cntrl)));
> +
>         if (mhi_get_mhi_state(mhi_cntrl) != MHI_STATE_M3)
>                 return -EINVAL;
> 
> 
> Thanks,
> Mani