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? Thanks, Mani > > -- > Jeffrey Hugo > Qualcomm Technologies, Inc. is a member of the > Code Aurora Forum, a Linux Foundation Collaborative Project.
