Messages in this thread | | | From | "Winkler, Tomas" <> | Subject | RE: [Intel-gift] Linux 3.10-rc7 | Date | Thu, 11 Jul 2013 19:52:14 +0000 |
| |
> 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@samsung.com | (970) 672-0658
| |