Skip to content
  • Baochen Qiang's avatar
    02b49cd1
    bus: mhi: Wait for M2 state during system resume · 02b49cd1
    Baochen Qiang authored
    
    
    During system resume, MHI host triggers M3->M0 transition and then waits
    for target device to enter M0 state. Once done, the device queues a state
    change event into ctrl event ring and notifies MHI host by raising an
    interrupt, where a tasklet is scheduled to process this event. In most
    cases, the tasklet is served timely and wait operation succeeds.
    
    However, there are cases where CPU is busy and cannot serve this tasklet
    for some time. Once delay goes long enough, the device moves itself to M1
    state and also interrupts MHI host after inserting a new state change
    event to ctrl ring. Later when CPU finally has time to process the ring,
    there will be two events:
    
    1. For M3->M0 event, which is the first event to be processed queued first.
       The tasklet handler serves the event, updates device state to M0 and
       wakes up the task.
    
    2. For M0->M1 event, which is processed later, the tasklet handler
       triggers M1->M2 transition and updates device state to M2 directly,
       then wakes up the MHI host (if it is still sleeping on this wait queue).
    
    Note that although MHI host 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 host has to keep waiting till timeout
    causing the M0 state to be 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
    
    Cc: stable@vger.kernel.org
    Fixes: 0c6b20a1 ("bus: mhi: core: Add support for MHI suspend and resume")
    Signed-off-by: default avatarBaochen Qiang <bqiang@codeaurora.org>
    Reviewed-by: default avatarHemant Kumar <hemantk@codeaurora.org>
    Reviewed-by: default avatarManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20210524040312.14409-1-bqiang@codeaurora.org
    
    
    [mani: slightly massaged the commit message]
    Signed-off-by: default avatarManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20210621161616.77524-4-manivannan.sadhasivam@linaro.org
    
    
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    02b49cd1
    bus: mhi: Wait for M2 state during system resume
    Baochen Qiang authored
    
    
    During system resume, MHI host triggers M3->M0 transition and then waits
    for target device to enter M0 state. Once done, the device queues a state
    change event into ctrl event ring and notifies MHI host by raising an
    interrupt, where a tasklet is scheduled to process this event. In most
    cases, the tasklet is served timely and wait operation succeeds.
    
    However, there are cases where CPU is busy and cannot serve this tasklet
    for some time. Once delay goes long enough, the device moves itself to M1
    state and also interrupts MHI host after inserting a new state change
    event to ctrl ring. Later when CPU finally has time to process the ring,
    there will be two events:
    
    1. For M3->M0 event, which is the first event to be processed queued first.
       The tasklet handler serves the event, updates device state to M0 and
       wakes up the task.
    
    2. For M0->M1 event, which is processed later, the tasklet handler
       triggers M1->M2 transition and updates device state to M2 directly,
       then wakes up the MHI host (if it is still sleeping on this wait queue).
    
    Note that although MHI host 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 host has to keep waiting till timeout
    causing the M0 state to be 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
    
    Cc: stable@vger.kernel.org
    Fixes: 0c6b20a1 ("bus: mhi: core: Add support for MHI suspend and resume")
    Signed-off-by: default avatarBaochen Qiang <bqiang@codeaurora.org>
    Reviewed-by: default avatarHemant Kumar <hemantk@codeaurora.org>
    Reviewed-by: default avatarManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20210524040312.14409-1-bqiang@codeaurora.org
    
    
    [mani: slightly massaged the commit message]
    Signed-off-by: default avatarManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20210621161616.77524-4-manivannan.sadhasivam@linaro.org
    
    
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Loading