Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-08-01 Thread Alan Stern
On Fri, 1 Aug 2014, Thomas Gleixner wrote: > Anyone who thinks that this can and should be solved at the driver > level is simply taking the wrong drugs or ran out of supply of the > proper ones. Either call your shrink or your drug dealer to get out of > that. That's absolutely true, but there i

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-31 Thread Rafael J. Wysocki
On Friday, August 01, 2014 02:08:12 AM Rafael J. Wysocki wrote: > On Friday, August 01, 2014 12:16:23 AM Thomas Gleixner wrote: > > On Thu, 31 Jul 2014, Rafael J. Wysocki wrote: > > > On Thursday, July 31, 2014 12:44:24 PM Thomas Gleixner wrote: [cut] > Except for a couple of points where I'm not

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-31 Thread Rafael J. Wysocki
On Friday, August 01, 2014 01:41:31 AM Thomas Gleixner wrote: > On Thu, 31 Jul 2014, Rafael J. Wysocki wrote: > > On Thursday, July 31, 2014 04:12:55 PM Alan Stern wrote: > > > Pardon me for sticking my nose into the middle of the conversation, but > > > here's what it looks like to me: > > > > >

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-31 Thread Rafael J. Wysocki
On Friday, August 01, 2014 12:16:23 AM Thomas Gleixner wrote: > On Thu, 31 Jul 2014, Rafael J. Wysocki wrote: > > On Thursday, July 31, 2014 12:44:24 PM Thomas Gleixner wrote: > > > What's this PCIe PME handler doing? Is it required functionality for > > > the suspend/resume path or is it a wakeup/

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-31 Thread Thomas Gleixner
On Thu, 31 Jul 2014, Rafael J. Wysocki wrote: > On Thursday, July 31, 2014 04:12:55 PM Alan Stern wrote: > > Pardon me for sticking my nose into the middle of the conversation, but > > here's what it looks like to me: > > > > The entire no_irq phase of suspend/resume is starting to seem like a > >

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-31 Thread Thomas Gleixner
On Thu, 31 Jul 2014, Rafael J. Wysocki wrote: > On Thursday, July 31, 2014 12:44:24 PM Thomas Gleixner wrote: > > > > Aside of that I want to see a coherent explanation why a shared MSI > > > > interrupt makes any sense at all. > > > > > > > > 25: 1 <> 0 PCI-MSI-edge aerdrv, PCIe PME >

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-31 Thread Thomas Gleixner
On Thu, 31 Jul 2014, Rafael J. Wysocki wrote: > On Thursday, July 31, 2014 12:44:24 PM Thomas Gleixner wrote: > > What's this PCIe PME handler doing? Is it required functionality for > > the suspend/resume path or is it a wakeup/abort mechanism. > > It is a wakeup/abort mechanism. So why is it us

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-31 Thread Rafael J. Wysocki
On Thursday, July 31, 2014 04:12:55 PM Alan Stern wrote: > On Thu, 31 Jul 2014, Rafael J. Wysocki wrote: > > > And before we enter the wakeup handling slippery slope, let me make a note > > that this problem is bothering me quite a bit at the moment. In my opinion > > we need to address it someho

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-31 Thread Alan Stern
On Thu, 31 Jul 2014, Rafael J. Wysocki wrote: > And before we enter the wakeup handling slippery slope, let me make a note > that this problem is bothering me quite a bit at the moment. In my opinion > we need to address it somehow regardless of the wakeup issues and I'm not sure > if failing __s

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-31 Thread Rafael J. Wysocki
On Thursday, July 31, 2014 12:44:24 PM Thomas Gleixner wrote: > On Thu, 31 Jul 2014, Rafael J. Wysocki wrote: > > > On Thursday, July 31, 2014 02:12:11 AM Thomas Gleixner wrote: > > > On Thu, 31 Jul 2014, Thomas Gleixner wrote: > > > > On Wed, 30 Jul 2014, Rafael J. Wysocki wrote: > > > > Before t

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-31 Thread Thomas Gleixner
On Thu, 31 Jul 2014, Rafael J. Wysocki wrote: > On Thursday, July 31, 2014 02:12:11 AM Thomas Gleixner wrote: > > On Thu, 31 Jul 2014, Thomas Gleixner wrote: > > > On Wed, 30 Jul 2014, Rafael J. Wysocki wrote: > > > Before this code changes in any way I want to see: > > > > > > 1) a description

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-30 Thread Rafael J. Wysocki
On Thursday, July 31, 2014 02:12:11 AM Thomas Gleixner wrote: > On Thu, 31 Jul 2014, Thomas Gleixner wrote: > > On Wed, 30 Jul 2014, Rafael J. Wysocki wrote: > > Before this code changes in any way I want to see: > > > > 1) a description of the existing semantics and their background On that one

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-30 Thread Thomas Gleixner
On Thu, 31 Jul 2014, Thomas Gleixner wrote: > On Wed, 30 Jul 2014, Rafael J. Wysocki wrote: > Before this code changes in any way I want to see: > > 1) a description of the existing semantics and their background > > 2) a description of the short comings of the existing semantics w/o > cons

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-30 Thread Thomas Gleixner
On Wed, 30 Jul 2014, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Device drivers currently use enable_irq_wake() to configure their > interrupts for system wakeup, but that API is not particularly > well suited for this purpose, because it goes directly all the > way to the hardware an

[PATCH 1/3] irq / PM: New driver interface for wakeup interrupts

2014-07-30 Thread Rafael J. Wysocki
From: Rafael J. Wysocki Device drivers currently use enable_irq_wake() to configure their interrupts for system wakeup, but that API is not particularly well suited for this purpose, because it goes directly all the way to the hardware and attempts to change the IRQ configuration at the chip leve