u don't need to. But there are some advantages if you do:
You get automatic runtime PM time accounting for the adapter device
(how much time active and how much suspended), and suspend events will
propagate from the I2C clients all the way up to the adapter's parent.
Alan Stern
--
To unsubscribe fr
hin a probe routine).
In general, it's bad form to do pm_runtime_get/put calls on your parent
-- you should make changes only to the device you're responsible for.
Alan Stern
--
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
that drivers
impose by calling device_pm_wait_for_dev().
Alan Stern
--
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
On Tue, 20 Oct 2015, Mark Brown wrote:
> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>
> > Furthermore, that applies only to devices that use synchronous suspend.
> > Async suspend is becoming common, and there the only restrictions are
> > parent-child
On Tue, 20 Oct 2015, Tomeu Vizoso wrote:
> On 20 October 2015 at 18:04, Alan Stern <st...@rowland.harvard.edu> wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> >
do its job)..but Alan voiced concerns about that.
Don't worry too much about what I said. If adding a gadget bus will
solve the problem in an appropriate way, and if nobody else objects
(particularly Felipe, who is on vacation now), then go for it.
Alan Stern
--
To unsubscribe from this list
multiplexer):
Can you explain this in a little more detail? Exactly what does the
delete_device attribute do, when called for device D?
That is, what does a write to /sys/bus/i2c/devices/D/delete_device do?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-i2c
On Fri, 17 May 2013, Alexander Sverdlin wrote:
Hi!
On 05/17/2013 04:42 PM, ext Alan Stern wrote:
i2c: suppress lockdep warning on delete_device
Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep
warning is thrown in case i2c device is removed (via
On Fri, 17 May 2013, Alexander Sverdlin wrote:
Hi!
On 05/17/2013 05:31 PM, ext Alan Stern wrote:
i2c: suppress lockdep warning on delete_device
Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following
lockdep
warning is thrown in case i2c device is removed (via
it was registered!), they will be resumed
first.
Alan Stern
--
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
exist, but the subsystem code knows about
them and takes them into account. Grep for device_pm_wait_for_dev in
the appropriate subtrees and you'll see what I mean.
Now, I have no idea what the situation is with regard to I2C...
Alan Stern
--
To unsubscribe from this list: send the line
);
+}
+EXPORT_SYMBOL_GPL(pm_runtime_want_interaction);
+
+/**
* pm_runtime_no_callbacks - Ignore run-time PM callbacks for a device.
* @dev: Device to handle.
*
Don't forget that you also need to describe these things in
Documentation/power/runtime.txt.
Alan Stern
--
To unsubscribe from
in the end this won't make much difference, but we might as
well do it.
Alan Stern
--
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
. This is done by the PM core, in order to
prevent runtime power transitions from interfering with a system power
transition. The PM core increments the device's usage_count; this
prevents the device from being runtime-suspended but it allows
runtime-resume calls to go through.
Alan Stern
is allowed, a runtime suspend is not, and thus a system
power transititon is prevented.
Alan Stern
--
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
in a generic setting, and AFAICT the only place that happens is
in generic_ops.c, where the change is correct.
Alan Stern
--
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
with the details of how the i2c subsystem works. But
in general, the subsystem code should call pm_runtime_set_active()
for every device before registering it. Then if a driver doesn't use
any runtime-PM functions, pm_runtime_suspended() will return false.
Alan Stern
--
To unsubscribe from
On Tue, 14 Dec 2010, Mark Brown wrote:
On Tue, Dec 14, 2010 at 12:44:24PM -0500, Alan Stern wrote:
On Tue, 14 Dec 2010, Mark Brown wrote:
On Tue, Dec 14, 2010 at 11:16:45AM -0500, Alan Stern wrote:
I'm not familiar with the details of how the i2c subsystem works. But
in general
On Tue, 14 Dec 2010, Mark Brown wrote:
On Tue, Dec 14, 2010 at 02:10:58PM -0500, Alan Stern wrote:
I see. It sounds like you're really saying that new devices default to
the wrong runtime state. If pm_runtime_init() would set new devices to
RPM_ACTIVE instead of RPM_SUSPENDED
a bunch of tiny shim functions, sort of
like what I ended up doing in the USB stack (see usb_dev_prepare() and
the following routines in drivers/usb/core/usb.c).
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More
forces the
bus type to have a pm_ops member, which as you point out, will prevent
the legacy methods from being called.
Alan Stern
--
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
On Sun, 14 Mar 2010, Rafael J. Wysocki wrote:
On Sunday 14 March 2010, Alan Stern wrote:
On Sun, 14 Mar 2010, Rafael J. Wysocki wrote:
You know, maybe we should allow bus types to use both the old and new
interfaces. It would make life easier for other subsystems in addition
in the pm_ops structure would be empty.
The changes to the PM core necessary to do this are quite small. Does
it seem like a reasonable thing to do?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More
23 matches
Mail list logo
