[Intel-gfx] [Intel-gift] Linux 3.10-rc7

[Winkler, Tomas]

> I don't see mei_me_pci_suspend() calling mei_disable_interrupts() and
> pci_disable_msi().

Suspend calls mei_reset with request for disabling interrupts  
I'm pretty sure I do free_irq and I do disable_msi in the suspend (Hope we are looking at the same code)

 I don't see a call to mei_enable_interrupts() from
> mei_me_pci_resume(). I don't think mei_enable_interrupts() is used
> anywhere. pci_dev_msi_enabled() enables the interrupts in
> mei_me_pci_resume() looks like.

Again here we call mei_reset with request of enabling the interrupts 

> 
> However, I did notice one thing, if pci_dev_msi_enabled() returns false,
> request_threaded_irq() is called  with IRQF_SHARED. Again might just be
> fine, it leads me to the next question.
>

Is the MSI disabled on  your platform? 
 
> mei_me_pci_suspend() has code that runs after disabling interrupts. Does
> this need to be split into suspend() and suspend_noirq() ops, since the IRQ
> could be shared?

If you don't have msi 
I think usually it is shared with some USB device, but I haven't seen that in my code I will check again.
Would other resume block the interrupt line?
 
> It is a possibility if pci_enable_msi() takes longer in resume path and
> pci_dev_msi_enabled() returns false, then IRQF_SHARED is requested.
> 
> Don't know if this helpful, but I thought I would ask just in case, it helps you
> think of something you didn't before. Please let me know if you need help
> gathering data from my system.

Thanks for ideas I will check that points.

Thanks
Tomas

> -- Shuah
> 
> Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
> America (Silicon Valley) shuah.kh at samsung.com | (970) 672-0658