On Thu, Aug 25, 2011 at 04:17:31PM +0200, Rafael J. Wysocki wrote:
On Thursday, August 25, 2011, Mark Brown wrote:
On Tue, Aug 23, 2011 at 11:31:54PM +0200, Rafael J. Wysocki wrote:
Perhaps. Still, that requires some policy to be put into drivers,
which I don't think is entirely
On Fri, Aug 26, 2011 at 11:25:13AM +0900, MyungJoo Ham wrote:
On Fri, Jul 1, 2011 at 12:11 AM, jean.pi...@newoldbits.com wrote:
@@ -129,19 +146,19 @@ static const struct file_operations pm_qos_power_fops
= {
/* unlocked internal variant */
static inline int pm_qos_get_value(struct
On Friday, August 26, 2011, mark gross wrote:
On Fri, Aug 26, 2011 at 11:25:13AM +0900, MyungJoo Ham wrote:
On Fri, Jul 1, 2011 at 12:11 AM, jean.pi...@newoldbits.com wrote:
@@ -129,19 +146,19 @@ static const struct file_operations
pm_qos_power_fops = {
/* unlocked internal variant
On Tue, Aug 23, 2011 at 11:31:54PM +0200, Rafael J. Wysocki wrote:
Perhaps. Still, that requires some policy to be put into drivers,
which I don't think is entirely correct.
So, I don't really have the bandwidth to discuss this properly for at
least the next week or so - is it possible to
On Thursday, August 25, 2011, Mark Brown wrote:
On Tue, Aug 23, 2011 at 11:31:54PM +0200, Rafael J. Wysocki wrote:
Perhaps. Still, that requires some policy to be put into drivers,
which I don't think is entirely correct.
So, I don't really have the bandwidth to discuss this properly
On Thu, Aug 25, 2011 at 4:17 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, August 25, 2011, Mark Brown wrote:
On Tue, Aug 23, 2011 at 11:31:54PM +0200, Rafael J. Wysocki wrote:
Perhaps. Still, that requires some policy to be put into drivers,
which I don't think is entirely
On Thursday, August 25, 2011, Jean Pihet wrote:
On Thu, Aug 25, 2011 at 4:17 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, August 25, 2011, Mark Brown wrote:
On Tue, Aug 23, 2011 at 11:31:54PM +0200, Rafael J. Wysocki wrote:
Perhaps. Still, that requires some policy to be put
On Fri, Jul 1, 2011 at 12:11 AM, jean.pi...@newoldbits.com wrote:
@@ -129,19 +146,19 @@ static const struct file_operations pm_qos_power_fops =
{
/* unlocked internal variant */
static inline int pm_qos_get_value(struct pm_qos_object *o)
{
- if (plist_head_empty(o-requests))
+
On Sun, Aug 21, 2011 at 08:05:53PM +0200, Rafael J. Wysocki wrote:
On Sunday, August 21, 2011, Mark Brown wrote:
I don't understand why the driver would need to know what situation it's
in. I'd been working on the basis that the idea was that the driver
said what the constraints it has
On Tuesday, August 23, 2011, Mark Brown wrote:
On Sun, Aug 21, 2011 at 08:05:53PM +0200, Rafael J. Wysocki wrote:
On Sunday, August 21, 2011, Mark Brown wrote:
I don't understand why the driver would need to know what situation it's
in. I'd been working on the basis that the idea was
On Sat, Aug 20, 2011 at 09:14:37PM +0200, Rafael J. Wysocki wrote:
I guess you mean the driver here and I'm not really sure it can.
For instance, the driver may not know what configuration it works in,
e.g. is there a power domain or a hierarchy of those and how much time
it takes to power
On Sunday, August 21, 2011, Mark Brown wrote:
On Sat, Aug 20, 2011 at 09:14:37PM +0200, Rafael J. Wysocki wrote:
I guess you mean the driver here and I'm not really sure it can.
For instance, the driver may not know what configuration it works in,
e.g. is there a power domain or a
On Fri, Aug 19, 2011 at 10:24:19PM -0400, Alan Stern wrote:
On Sat, 20 Aug 2011, Mark Brown wrote:
interfaces and let the subsystem and driver translate these into actual
wakeup latency constraints:
https://lists.linux-foundation.org/pipermail/linux-pm/2011-August/032422.html
On Saturday, August 20, 2011, Mark Brown wrote:
On Fri, Aug 19, 2011 at 10:42:20PM +0200, Rafael J. Wysocki wrote:
I really wouldn't like the discussion to go in circles.
First, please tell me what in particular you are objecting to,
because I don't think that's any of the patches that
On Sat, Aug 20, 2011 at 11:35:58AM +0200, Rafael J. Wysocki wrote:
I'm not sure what you mean by exposing per-device wakeup latency constraints
to user space. I simply thought it might be useful to allow user space to
add and remove those, in analogy to what it can do with the currently
On Sat, 20 Aug 2011, Mark Brown wrote:
On Fri, Aug 19, 2011 at 10:24:19PM -0400, Alan Stern wrote:
On Sat, 20 Aug 2011, Mark Brown wrote:
interfaces and let the subsystem and driver translate these into actual
wakeup latency constraints:
On Sat, Aug 20, 2011 at 09:48:25AM -0400, Alan Stern wrote:
No, I as wasking about driver- and subsystem-specific interfaces to
userspace that translate into things users are already doing. Kevin's
example was a touchscreen (although that was really an example of
setting a power usage level,
On Saturday, August 20, 2011, Mark Brown wrote:
On Sat, Aug 20, 2011 at 09:48:25AM -0400, Alan Stern wrote:
No, I as wasking about driver- and subsystem-specific interfaces to
userspace that translate into things users are already doing. Kevin's
example was a touchscreen (although that
On Saturday, August 20, 2011, Mark Brown wrote:
On Sat, Aug 20, 2011 at 11:35:58AM +0200, Rafael J. Wysocki wrote:
I'm not sure what you mean by exposing per-device wakeup latency
constraints
to user space. I simply thought it might be useful to allow user space to
add and remove
On Sat, Aug 20, 2011 at 06:34:34PM +0200, Rafael J. Wysocki wrote:
On Saturday, August 20, 2011, Mark Brown wrote:
Any sort of media streaming would be an obvious example - the
application picks the amount of data it buffers and how often it's
notified of progress depending on the usage
On Sat, Aug 20, 2011 at 06:51:42PM +0200, Rafael J. Wysocki wrote:
On Saturday, August 20, 2011, Mark Brown wrote:
Coming at this from the embedded perspective modifying the kernel just
isn't an issue. It's quite depressing in other cases too but some of
the circumstances you mentioned in
On Saturday, August 20, 2011, Mark Brown wrote:
On Sat, Aug 20, 2011 at 06:34:34PM +0200, Rafael J. Wysocki wrote:
On Saturday, August 20, 2011, Mark Brown wrote:
Any sort of media streaming would be an obvious example - the
application picks the amount of data it buffers and how often
On Saturday, August 20, 2011, Mark Brown wrote:
On Sat, Aug 20, 2011 at 06:51:42PM +0200, Rafael J. Wysocki wrote:
On Saturday, August 20, 2011, Mark Brown wrote:
Coming at this from the embedded perspective modifying the kernel just
isn't an issue. It's quite depressing in other cases
Hi,
I really wouldn't like the discussion to go in circles.
First, please tell me what in particular you are objecting to,
because I don't think that's any of the patches that have been
sent to the linux-pm list to date.
Thanks,
Rafael
--
To unsubscribe from this list: send the line unsubscribe
On Fri, Aug 19, 2011 at 10:42:20PM +0200, Rafael J. Wysocki wrote:
I really wouldn't like the discussion to go in circles.
First, please tell me what in particular you are objecting to,
because I don't think that's any of the patches that have been
sent to the linux-pm list to date.
The
On Sat, 20 Aug 2011, Mark Brown wrote:
The original issue that Kevin raised and CCed me in on was the idea of
exposing raw per-device wakeup latency constraints to userspace; it
seems much better to expose user level requirements via subsystem
interfaces and let the subsystem and driver
On Mon, 2011-08-08 at 23:31 +0200, Rafael J. Wysocki wrote:
On Sunday, August 07, 2011, Mark Brown wrote:
OK, so this does sound like there's probably a genuine issue on PCs due
to limitations in the environment. Is it possible to expose these
things to userspace in a way that's limited
On Sunday, August 07, 2011, Mark Brown wrote:
On Sat, Aug 06, 2011 at 09:46:20PM +0200, Rafael J. Wysocki wrote:
On Saturday, August 06, 2011, Mark Brown wrote:
I wouldn't say we've got to rely on userspace here - it seems like we
ought to be able to use DMI or other system data to
On Saturday, August 06, 2011, Mark Brown wrote:
On Fri, Aug 05, 2011 at 09:37:36PM +0200, Rafael J. Wysocki wrote:
On Friday, August 05, 2011, Mark Brown wrote:
Do you have any examples of this that aren't better expressed in device
specific terms?
I'm not sure what you mean
On Sat, Aug 06, 2011 at 09:46:20PM +0200, Rafael J. Wysocki wrote:
On Saturday, August 06, 2011, Mark Brown wrote:
I wouldn't say we've got to rely on userspace here - it seems like we
ought to be able to use DMI or other system data to identify the
affected systems and activate the
On Thu, Aug 04, 2011 at 09:15:30PM +0200, Rafael J. Wysocki wrote:
On Thursday, August 04, 2011, Mark Brown wrote:
On Wed, Aug 03, 2011 at 12:16:17AM +0200, Rafael J. Wysocki wrote:
On Tuesday, August 02, 2011, Kevin Hilman wrote:
I disagree and think that both are quite realistic
On Thu, Aug 04, 2011 at 09:15:30PM +0200, Rafael J. Wysocki wrote:
On Thursday, August 04, 2011, Mark Brown wrote:
On the one hand that's true. On the other hand that just seems like
going down a bad road where we have drivers that only work when run with
a magic userspace that may or may
On Friday, August 05, 2011, Mark Brown wrote:
On Thu, Aug 04, 2011 at 09:15:30PM +0200, Rafael J. Wysocki wrote:
On Thursday, August 04, 2011, Mark Brown wrote:
On the one hand that's true. On the other hand that just seems like
going down a bad road where we have drivers that only
On Fri, Aug 05, 2011 at 09:37:36PM +0200, Rafael J. Wysocki wrote:
On Friday, August 05, 2011, Mark Brown wrote:
Do you have any examples of this that aren't better expressed in device
specific terms?
I'm not sure what you mean exactly, but if you take two PC-like systems
with similar
On Wed, Aug 03, 2011 at 12:16:17AM +0200, Rafael J. Wysocki wrote:
On Tuesday, August 02, 2011, Kevin Hilman wrote:
I disagree and think that both are quite realistic (mainly because they
exist today, albiet mostly out of tree because no generic QoS framework
exist. e.g. on OMAP, we have
On Thursday, August 04, 2011, Mark Brown wrote:
On Wed, Aug 03, 2011 at 12:16:17AM +0200, Rafael J. Wysocki wrote:
On Tuesday, August 02, 2011, Kevin Hilman wrote:
I disagree and think that both are quite realistic (mainly because they
exist today, albiet mostly out of tree because no
36 matches
Mail list logo
