From: David Brownell <david-b@pacbell.net>
To: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Ben Dooks <ben-linux@fluff.org>,
Jean Delvare <khali@linux-fr.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-pm@lists.linux-foundation.org
Subject: Re: [PATCH] rtc: Set wakeup capability for I2C and SPI RTC drivers
Date: Thu, 27 Aug 2009 14:52:36 -0700 [thread overview]
Message-ID: <200908271452.37358.david-b@pacbell.net> (raw)
In-Reply-To: <20090827182207.GA7358@oksana.dev.rtsoft.ru>
NAK; see details below
On Thursday 27 August 2009, Anton Vorontsov wrote:
> RTC core won't allow wakeup alarms to be set if RTC devices' parent
> (i.e. i2c_client or spi_device) isn't wakeup capable.
Quite rightly so ... being wakeup-capable is config-specific.
> For I2C devices there is I2C_CLIENT_WAKE flag exists that we can pass
> via board info, and if set, I2C core will initialize wakeup capability.
> For SPI devices there is no such flag at all.
So why not add it for SPI? If it's an issue, it's not
unique to RTC devices.
> I believe that it's not platform code responsibility to allow or
> disallow wakeups, instead, drivers themselves should set the capability
> if a device can trigger wakeups.
Drivers can't generally know if that's possible though.
They need to be told that it is, by platform code.
Most devices can't issue wakeup events.
> That's what drivers/base/power/sysfs.c says:
>
> * It is the responsibility of device drivers to enable (or disable)
> * wakeup signaling as part of changing device power states, respecting
> * the policy choices provided through the driver model.
>
> I2C and SPI RTC devices send wakeup events via interrupt lines, so we
> should set the wakeup capability if IRQ is routed.
Re-read the quoted sentence. You're saying that policy
choices should be hard-wired into the driver; contrary
to that quote. (In this case the choice is one that
platform code must report, and which the hardware
designer made: if the device can issue wakeup events.)
> Ideally we should also check irq for wakeup capability before setting
> device's capability, i.e.
>
> if (can_irq_wake(irq))
> device_set_wakeup_capable(&client->dev, 1);
>
> But there is no can_irq_wake() call exist, and it is not that trivial
> to implement it for all interrupts controllers and complex/cascaded
> setups.
That is why platform code should device_init_wakeup() and
drivers should check device_can_wakeup(dev) ...
> drivers/base/power/sysfs.c also covers these cases:
>
> * Devices may not be able to generate wakeup events from all power
> * states. Also, the events may be ignored in some configurations;
> * for example, they might need help from other devices that aren't
> * active
>
> So there is no guarantee that wakeup will actually work,
Yes there is ... it's only **exceptional** cases where it can't
work. Your patch would make it routine that those flags be
unreliable; pretty nasty.
WARNING: multiple messages have this Message-ID (diff)
From: David Brownell <david-b@pacbell.net>
To: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Ben Dooks <ben-linux@fluff.org>,
Jean Delvare <khali@linux-fr.org>,
linux-pm@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] rtc: Set wakeup capability for I2C and SPI RTC drivers
Date: Thu, 27 Aug 2009 14:52:36 -0700 [thread overview]
Message-ID: <200908271452.37358.david-b@pacbell.net> (raw)
In-Reply-To: <20090827182207.GA7358@oksana.dev.rtsoft.ru>
NAK; see details below
On Thursday 27 August 2009, Anton Vorontsov wrote:
> RTC core won't allow wakeup alarms to be set if RTC devices' parent
> (i.e. i2c_client or spi_device) isn't wakeup capable.
Quite rightly so ... being wakeup-capable is config-specific.
> For I2C devices there is I2C_CLIENT_WAKE flag exists that we can pass
> via board info, and if set, I2C core will initialize wakeup capability.
> For SPI devices there is no such flag at all.
So why not add it for SPI? If it's an issue, it's not
unique to RTC devices.
> I believe that it's not platform code responsibility to allow or
> disallow wakeups, instead, drivers themselves should set the capability
> if a device can trigger wakeups.
Drivers can't generally know if that's possible though.
They need to be told that it is, by platform code.
Most devices can't issue wakeup events.
> That's what drivers/base/power/sysfs.c says:
>
> * It is the responsibility of device drivers to enable (or disable)
> * wakeup signaling as part of changing device power states, respecting
> * the policy choices provided through the driver model.
>
> I2C and SPI RTC devices send wakeup events via interrupt lines, so we
> should set the wakeup capability if IRQ is routed.
Re-read the quoted sentence. You're saying that policy
choices should be hard-wired into the driver; contrary
to that quote. (In this case the choice is one that
platform code must report, and which the hardware
designer made: if the device can issue wakeup events.)
> Ideally we should also check irq for wakeup capability before setting
> device's capability, i.e.
>
> if (can_irq_wake(irq))
> device_set_wakeup_capable(&client->dev, 1);
>
> But there is no can_irq_wake() call exist, and it is not that trivial
> to implement it for all interrupts controllers and complex/cascaded
> setups.
That is why platform code should device_init_wakeup() and
drivers should check device_can_wakeup(dev) ...
> drivers/base/power/sysfs.c also covers these cases:
>
> * Devices may not be able to generate wakeup events from all power
> * states. Also, the events may be ignored in some configurations;
> * for example, they might need help from other devices that aren't
> * active
>
> So there is no guarantee that wakeup will actually work,
Yes there is ... it's only **exceptional** cases where it can't
work. Your patch would make it routine that those flags be
unreliable; pretty nasty.
next prev parent reply other threads:[~2009-08-27 21:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-27 18:22 [PATCH] rtc: Set wakeup capability for I2C and SPI RTC drivers Anton Vorontsov
2009-08-27 18:22 ` Anton Vorontsov
2009-08-27 21:52 ` David Brownell [this message]
2009-08-27 21:52 ` David Brownell
2009-08-27 23:19 ` Anton Vorontsov
2009-08-27 23:19 ` Anton Vorontsov
2009-08-27 23:19 ` Anton Vorontsov
2009-08-28 0:30 ` Anton Vorontsov
2009-08-28 0:30 ` Anton Vorontsov
2009-09-22 21:19 ` Andrew Morton
2009-09-22 21:19 ` Andrew Morton
2009-09-22 21:19 ` Andrew Morton
2009-08-28 0:30 ` Anton Vorontsov
-- strict thread matches above, loose matches on Subject: below --
2009-08-27 18:22 Anton Vorontsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200908271452.37358.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=akpm@linux-foundation.org \
--cc=avorontsov@ru.mvista.com \
--cc=ben-linux@fluff.org \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.