On 4/21/2020 12:08 AM, Manivannan Sadhasivam wrote:
On Mon, Apr 13, 2020 at 08:01:36AM -0600, Jeffrey Hugo wrote:
On 4/13/2020 7:34 AM, Manivannan Sadhasivam wrote:
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?
It probably could be considered part of the existing implementation, but I'd
like to hear from Hemant/Bhaumik. Wherever we end up, I'd like to have the
spec match.
Hemant/Bhaumik, can you please share your thoughts?
Sorry. Hemant, Bhaumik, and I have had a few calls discussing this. We
are trying to come to a consensus on the expectation of the device
behavior, so that we can propose the best solution. Probably a few more
days yet while we await for a bit of clarification.
--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
