Re: [PATCH] i2c: Hook up runtime PM support
Hi Mark,
On Fri, 5 Feb 2010 12:30:11 +, Mark Brown wrote:
Allow I2C drivers to make use of the runtime PM framework by adding
bus implementations of the runtime PM operations. These simply
immediately suspend when the device is idle. The runtime PM framework
provides drivers with off the shelf refcounts for enables and sysfs
control for managing runtime suspend from userspace so is useful even
without meaningful input from the bus.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
Changed to allow drivers to use the idle callback to veto suspend.
drivers/i2c/i2c-core.c | 50
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 10be7b5..4131698 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -34,6 +34,7 @@
#include linux/hardirq.h
#include linux/irqflags.h
#include linux/rwsem.h
+#include linux/pm_runtime.h
#include asm/uaccess.h
#include i2c-core.h
@@ -184,6 +185,52 @@ static int i2c_device_pm_resume(struct device *dev)
#define i2c_device_pm_resume NULL
#endif
+#ifdef CONFIG_PM_RUNTIME
+static int i2c_device_runtime_suspend(struct device *dev)
+{
+ const struct dev_pm_ops *pm;
+
+ if (!dev-driver)
+ return 0;
+ pm = dev-driver-pm;
+ if (!pm || !pm-runtime_suspend)
+ return 0;
+ return pm-runtime_suspend(dev);
+}
+
+static int i2c_device_runtime_resume(struct device *dev)
+{
+ const struct dev_pm_ops *pm;
+
+ if (!dev-driver)
+ return 0;
+ pm = dev-driver-pm;
+ if (!pm || !pm-runtime_resume)
+ return 0;
+ return pm-runtime_resume(dev);
+}
+
+static int i2c_device_runtime_idle(struct device *dev)
+{
+ const struct dev_pm_ops *pm = NULL;
+ int ret;
+
+ if (dev-driver)
+ pm = dev-driver-pm;
+ if (pm pm-runtime_idle) {
+ ret = pm-runtime_idle(dev);
+ if (ret)
+ return ret;
+ }
+
+ return pm_runtime_suspend(dev);
+}
+#else
+#define i2c_device_runtime_suspend NULL
+#define i2c_device_runtime_resumeNULL
+#define i2c_device_runtime_idle NULL
+#endif
+
static int i2c_device_suspend(struct device *dev, pm_message_t mesg)
{
struct i2c_client *client = i2c_verify_client(dev);
@@ -251,6 +298,9 @@ static const struct attribute_group
*i2c_dev_attr_groups[] = {
static const struct dev_pm_ops i2c_device_pm_ops = {
.suspend = i2c_device_pm_suspend,
.resume = i2c_device_pm_resume,
+ .runtime_suspend = i2c_device_runtime_suspend,
+ .runtime_resume = i2c_device_runtime_resume,
+ .runtime_idle = i2c_device_runtime_idle,
};
struct bus_type i2c_bus_type = {
Applied, thanks. I am a little surprised to see that these functions
have nothing i2c-specific, so I am wondering why we have to duplicate
them in every bus type... Shouldn't the functions above be part of
drivers/base/power/runtime.c and exported so that all bus types that
want them can reuse them?
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] i2c: Add SMBus alert support
Hi Jean,
I have a couple of parts I can test this on (connected to a pxa271)
but it may be a little while before I get to it (so don't let me
hold the patch up!)
On tiny point below. Worth changing if you are doing another roll of the patch
as at least in my dozy Monday evening state it confused me for a few moments!
Thanks,
Jonathan
Acked-by: Jonathan Cameron ji...@cam.ac.uk
SMBus alert support. The SMBus alert protocol allows several SMBus
slave devices to share a single interrupt pin on the SMBus master,
while still allowing the master to know which slave triggered the
interrupt.
This is based on preliminary work by David Brownell. The key
difference between David's implementation and mine is that his was
part of i2c-core, while mine is split into a separate, standalone
module named i2c-smbus. The i2c-smbus module is meant to include
support for all SMBus extensions to the I2C protocol in the future.
The benefit of this approach is a zero cost for I2C bus segments which
do not need SMBus alert support. Where David's implementation
increased the size of struct i2c_adapter by 7% (40 bytes on i386),
mine doesn't touch it. Where David's implementation added over 150
lines of code to i2c-core (+10%), mine doesn't touch it. The only
change that touches all the users of the i2c subsystem is a new
callback in struct i2c_driver (common to both implementations.) I seem
to remember Trent was worried about the footprint of David'd
implementation, hopefully mine addresses the issue.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Trent Piepho tpie...@freescale.com
---
Documentation/i2c/smbus-protocol | 16 ++
drivers/i2c/Makefile |2
drivers/i2c/i2c-smbus.c | 264
++
include/linux/i2c-smbus.h| 50 +++
include/linux/i2c.h |7 +
5 files changed, 338 insertions(+), 1 deletion(-)
--- linux-2.6.33-rc7.orig/Documentation/i2c/smbus-protocol2010-02-12
14:19:47.0 +0100
+++ linux-2.6.33-rc7/Documentation/i2c/smbus-protocol 2010-02-12
14:19:51.0 +0100
@@ -185,6 +185,22 @@ the protocol. All ARP communications use
require PEC checksums.
+SMBus Alert
+===
+
+SMBus Alert was introduced in Revision 1.0 of the specification.
+
+The SMBus alert protocol allows several SMBus slave devices to share a
+single interrupt pin on the SMBus master, while still allowing the master
+to know which slave triggered the interrupt.
+
+This is implemented the following way in the Linux kernel:
+* I2C bus drivers which support SMBus alert should call
+ i2c_setup_smbus_alert() to setup SMBus alert support.
+* I2C drivers for devices which can trigger SMBus alerts should implement
+ the optional alert() callback.
+
+
I2C Block Transactions
==
--- linux-2.6.33-rc7.orig/drivers/i2c/Makefile2010-02-12
14:19:47.0 +0100
+++ linux-2.6.33-rc7/drivers/i2c/Makefile 2010-02-12 16:08:34.0
+0100
@@ -3,7 +3,7 @@
#
obj-$(CONFIG_I2C_BOARDINFO) += i2c-boardinfo.o
-obj-$(CONFIG_I2C)+= i2c-core.o
+obj-$(CONFIG_I2C)+= i2c-core.o i2c-smbus.o
obj-$(CONFIG_I2C_CHARDEV)+= i2c-dev.o
obj-y+= busses/ chips/ algos/
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.33-rc7/drivers/i2c/i2c-smbus.c 2010-02-12 16:11:34.0
+0100
...
+/*
+ * The alert IRQ handler needs to hand work off to a task which can issue
+ * SMBus calls, because those sleeping calls can't be made in IRQ context.
+ */
+static void smbus_alert(struct work_struct *work)
+{
+ struct i2c_smbus_alert *data;
+ struct i2c_client *ara;
+ unsigned short prev_addr = 0; /* Not a valid address */
+
+ data = container_of(work, struct i2c_smbus_alert, alert);
+ ara = data-ara;
+
+ for (;;) {
+ s32 status;
+ struct alert_data data;
Can we change the name of data here. From readability point of view it
would be better not to have this reliance on scope (as data used for
struct i2c_smbus_alert *data above. (obviously changing it above would
work as well!)
+
+ /*
+ * Devices with pending alerts reply in address order, low
+ * to high, because of slave transmit arbitration. After
+ * responding, an SMBus device stops asserting SMBALERT#.
+ *
+ * Note that SMBus 2.0 reserves 10-bit addresess for future
+ * use. We neither handle them, nor try to use PEC here.
+ */
+ status = i2c_smbus_read_byte(ara);
+ if (status 0)
+ break;
+
+ data.flag = status 1;
+ data.addr = status 1;
+
+ if (data.addr == prev_addr) {
+ dev_warn(ara-dev,
Re: [PATCH] i2c: Hook up runtime PM support
On Monday 15 February 2010, Mark Brown wrote: On Mon, Feb 15, 2010 at 07:14:09PM +0100, Jean Delvare wrote: Applied, thanks. I am a little surprised to see that these functions have nothing i2c-specific, so I am wondering why we have to duplicate them in every bus type... Shouldn't the functions above be part of drivers/base/power/runtime.c and exported so that all bus types that want them can reuse them? In fact this is the first bus type that doesn't need anything specific in these routines so fat. I tend to agree - in fact I'd been a little surprised the default for buses that don't provide anything was to refuse to do runtime PM (though I can see the transition issues when a bus does want to go and do its own thing). My actual plan here was to implement this for a couple of buses and then present a patch factoring out the common code. That's a good approach IMO. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: Hook up runtime PM support
On Mon, Feb 15, 2010 at 08:08:24PM +0100, Rafael J. Wysocki wrote: On Monday 15 February 2010, Mark Brown wrote: On Mon, Feb 15, 2010 at 07:14:09PM +0100, Jean Delvare wrote: Applied, thanks. I am a little surprised to see that these functions have nothing i2c-specific, so I am wondering why we have to duplicate them in every bus type... Shouldn't the functions above be part of drivers/base/power/runtime.c and exported so that all bus types that want them can reuse them? In fact this is the first bus type that doesn't need anything specific in these routines so fat. Not really - the platform bus is the same, it's just that some platforms are also able to do some neat stuff with the information they glean via runtime PM. The platform bus is actually a bit of a problem here since it gets used both for on-SoC devices where that sort of stuff is possible and also for things like MFDs and random memory mapped things on the system, meaning that drivers can't take advantage of runtime PM unless someone goes through and does something per-SoC which is a bit inconvnient. There's other buses like SPI that are in the same boat as I2C - they don't really have a cohesive bus level power management structure, or the power management is fully handled by with noop methods on the bus and holding the parent open until all the children are idle. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/4] i2c-mpc: add support for the Freescale MPC512x and other fixes
Ben D., These 4 patches are totally fine. Do you want to pick them up, or should I take them through the PowerPC tree? Cheers, g. On Wed, Feb 10, 2010 at 7:55 AM, Wolfgang Grandegger w...@grandegger.com wrote: From: Wolfgang Grandegger w...@denx.de This patch series adds support for the MPC512x from Freescale to the i2c-mpc driver. At that occasion, issues with __devinit[data] have been fixed and the doc of the FSL I2C dts bindings updated. It has been tested on a MPC5121ADS, TQM5200 and TQM8560 board Changes since v1: - use macro MPC_I2C_CLOCK_PRESERVE/SAFE for the special clock settings. - document the special DTS node fsl,mpc5121-i2c-ctrl. - update and correct the Kconfig help. - some other minor fixes as suggested by Wolfram. Changes since v2: - use __init[data] instead of __devinit[data] for this driver. Changes since v3: - switch back to __devinit[data] as pointed out by Ben. Changes since v4: - check MPC_I2C_CLOCK_SAFE instead of !clock as suggested by Wolfram. - update MODULE_DESCRIPTION(). Changes since v5 (suggested by Grant Likely): - various correctings for labling initialization functions and data (this is tricky because section mismatches are not always obvious). - add a separate patch for renaming the setclock into setup functions. - correct the doc of the I2C bindings, e.g. don't mention the legacy clock setting and remove obsolte parts. Changes since v6: - use __devinitconst for const data as suggested by Stephen Rothwell. Wolfgang Wolfgang Grandegger (4): i2c-mpc: use __devinit[data] for initialization functions and data i2c-mpc: rename setclock initialization functions to setup i2c-mpc: add support for the MPC512x processors from Freescale powerpc: doc/dts-bindings: update doc of FSL I2C bindings Documentation/powerpc/dts-bindings/fsl/i2c.txt | 30 +++- drivers/i2c/busses/Kconfig | 7 +- drivers/i2c/busses/i2c-mpc.c | 194 +++- 3 files changed, 146 insertions(+), 85 deletions(-) ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
