[PATCH] i2c: allow specifying separate wakeup interrupt in device tree

2015-07-30 Thread Dmitry Torokhov
Instead of having each i2c driver individually parse device tree data in case it or platform supports separate wakeup interrupt, and handle enabling and disabling wakeup interrupts in their power management routines, let's have i2c core do that for us. Platforms wishing to specify separate wakeup

Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree

2015-08-05 Thread Tony Lindgren
* Dmitry Torokhov [150803 13:05]: > On Mon, Aug 03, 2015 at 03:21:21AM -0700, Tony Lindgren wrote: > > > > Hmm why do we need the check for if (device_can_wakeup(&client->dev)))? > > Because of the code in device_wakeup_attach_irq(): > > ws = dev->power.wakeup; > if (!ws) { >

Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree

2015-08-19 Thread Wolfram Sang
> > > > @@ -659,20 +662,47 @@ static int i2c_device_probe(struct device *dev) > > > > if (!device_can_wakeup(&client->dev)) > > > > device_init_wakeup(&client->dev, > > > > client->flags & > > > > I2C_CLIENT_WAKE); > > > > > > I was

Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree

2015-08-19 Thread Dmitry Torokhov
Hi Wolfram, On Wed, Aug 19, 2015 at 10:43 AM, Wolfram Sang wrote: > >> > > > @@ -659,20 +662,47 @@ static int i2c_device_probe(struct device *dev) >> > > > if (!device_can_wakeup(&client->dev)) >> > > > device_init_wakeup(&client->dev, >> > > >

Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree

2015-07-31 Thread Vignesh R
On 07/31/2015 01:44 AM, Dmitry Torokhov wrote: > Instead of having each i2c driver individually parse device tree data in > case it or platform supports separate wakeup interrupt, and handle > enabling and disabling wakeup interrupts in their power management > routines, let's have i2c core do th

Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree

2015-08-03 Thread Tony Lindgren
* Vignesh R [150731 04:00]: > On 07/31/2015 01:44 AM, Dmitry Torokhov wrote: > > Instead of having each i2c driver individually parse device tree data in > > case it or platform supports separate wakeup interrupt, and handle > > enabling and disabling wakeup interrupts in their power management >

Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree

2015-08-03 Thread Dmitry Torokhov
Hi Tony, On Mon, Aug 03, 2015 at 03:21:21AM -0700, Tony Lindgren wrote: > * Vignesh R [150731 04:00]: > > On 07/31/2015 01:44 AM, Dmitry Torokhov wrote: > > > Instead of having each i2c driver individually parse device tree data in > > > case it or platform supports separate wakeup interrupt, and

Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree

2015-08-09 Thread Wolfram Sang
On Thu, Jul 30, 2015 at 01:14:31PM -0700, Dmitry Torokhov wrote: > Instead of having each i2c driver individually parse device tree data in > case it or platform supports separate wakeup interrupt, and handle > enabling and disabling wakeup interrupts in their power management > routines, let's hav

Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree

2015-08-09 Thread Dmitry Torokhov
On Sun, Aug 09, 2015 at 05:22:55PM +0200, Wolfram Sang wrote: > On Thu, Jul 30, 2015 at 01:14:31PM -0700, Dmitry Torokhov wrote: > > Instead of having each i2c driver individually parse device tree data in > > case it or platform supports separate wakeup interrupt, and handle > > enabling and disab

Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree

2015-08-09 Thread Wolfram Sang
> > I think it is a useful addition. Can someone add a paragraph describing > > this handling on top of the new generic i2c binding docs? > > > > http://patchwork.ozlabs.org/patch/505368/ > > Yes, I will. Great, thanks! > > > > > > @@ -659,20 +662,47 @@ static int i2c_device_probe(struct dev

Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree

2015-08-24 Thread Wolfram Sang
> > When reviewing V2, I wasn't comfortable with just guessing what the old > > code means. So, I did some digging and found: > > > > https://lkml.org/lkml/2008/8/10/204 > > > > Quoting the interesting paragraph from David Brownell: > > > > === > > > > Better would be to preserve any existing sett