于 2012/10/23 2:37, Alan Stern 写道:
On Mon, 22 Oct 2012, Sarah Sharp wrote:
On Mon, Oct 15, 2012 at 08:42:47AM +0200, Rafael J. Wysocki wrote:
Sorry for the delay, I have been distracted by a number of things.
Me too. :)
On Monday 24 of September 2012 15:10:36 Sarah Sharp wrote:
On Tue, Sep
On Mon, 22 Oct 2012, Sarah Sharp wrote:
> On Mon, Oct 15, 2012 at 08:42:47AM +0200, Rafael J. Wysocki wrote:
> > Sorry for the delay, I have been distracted by a number of things.
>
> Me too. :)
>
> > On Monday 24 of September 2012 15:10:36 Sarah Sharp wrote:
> > > On Tue, Sep 25, 2012 at 12:09:
On Mon, Oct 15, 2012 at 08:42:47AM +0200, Rafael J. Wysocki wrote:
> Sorry for the delay, I have been distracted by a number of things.
Me too. :)
> On Monday 24 of September 2012 15:10:36 Sarah Sharp wrote:
> > On Tue, Sep 25, 2012 at 12:09:06AM +0200, Rafael J. Wysocki wrote:
> > > What about h
Sorry for the delay, I have been distracted by a number of things.
On Monday 24 of September 2012 15:10:36 Sarah Sharp wrote:
> On Tue, Sep 25, 2012 at 12:09:06AM +0200, Rafael J. Wysocki wrote:
> > On Monday, September 24, 2012, Alan Stern wrote:
> > > On Mon, 24 Sep 2012, Rafael J. Wysocki wrote
On 2012年09月25日 05:17, Alan Stern wrote:
> On Mon, 24 Sep 2012, Rafael J. Wysocki wrote:
>> Well, precisely. Which means that the user would have to apply
>> trial-and-error
>> to figure out which sysfs file corresponds to which physical port on his/her
>> machine.
>>
>> That doesn't sound really
On Tue, Sep 25, 2012 at 12:09:06AM +0200, Rafael J. Wysocki wrote:
> On Monday, September 24, 2012, Alan Stern wrote:
> > On Mon, 24 Sep 2012, Rafael J. Wysocki wrote:
> > > > > Second, I'm not sure if there's any way for user space to figure out
> > > > > what
> > > > > ports are connected to wha
On Monday, September 24, 2012, Alan Stern wrote:
> On Mon, 24 Sep 2012, Rafael J. Wysocki wrote:
>
> > I don't mean this.
> >
> > Suppose that there are two ports on the hub, A and B, and there's only one
> > power resource used to put A _and_ B into D3cold. Then, when you call
> > acpi_bus_set_
On Mon, 24 Sep 2012, Rafael J. Wysocki wrote:
> I don't mean this.
>
> Suppose that there are two ports on the hub, A and B, and there's only one
> power resource used to put A _and_ B into D3cold. Then, when you call
> acpi_bus_set_power(A, D3cold) on A alone, what really happens is that the
>
On Monday, September 24, 2012, Lan Tianyu wrote:
> On 2012/9/24 21:18, Rafael J. Wysocki wrote:
> > On Saturday, September 22, 2012, Rafael J. Wysocki wrote:
> >> On Friday, September 21, 2012, Sarah Sharp wrote:
> >>> Two weeks ago at Linux Plumbers Conference, I presented about the Intel
> >>> Ly
On Monday, September 24, 2012, Greg KH wrote:
> On Mon, Sep 24, 2012 at 10:46:30AM -0700, Greg KH wrote:
> > On Mon, Sep 24, 2012 at 03:18:19PM +0200, Rafael J. Wysocki wrote:
> > > On Saturday, September 22, 2012, Rafael J. Wysocki wrote:
> > > > On Friday, September 21, 2012, Sarah Sharp wrote:
>
On Mon, Sep 24, 2012 at 10:46:30AM -0700, Greg KH wrote:
> On Mon, Sep 24, 2012 at 03:18:19PM +0200, Rafael J. Wysocki wrote:
> > On Saturday, September 22, 2012, Rafael J. Wysocki wrote:
> > > On Friday, September 21, 2012, Sarah Sharp wrote:
> > > > Two weeks ago at Linux Plumbers Conference, I p
On Mon, Sep 24, 2012 at 03:18:19PM +0200, Rafael J. Wysocki wrote:
> On Saturday, September 22, 2012, Rafael J. Wysocki wrote:
> > On Friday, September 21, 2012, Sarah Sharp wrote:
> > > Two weeks ago at Linux Plumbers Conference, I presented about the Intel
> > > Lynx Point USB port power off mech
On 2012/9/24 21:18, Rafael J. Wysocki wrote:
On Saturday, September 22, 2012, Rafael J. Wysocki wrote:
On Friday, September 21, 2012, Sarah Sharp wrote:
Two weeks ago at Linux Plumbers Conference, I presented about the Intel
Lynx Point USB port power off mechanism. This email is a report out o
On Saturday, September 22, 2012, Rafael J. Wysocki wrote:
> On Friday, September 21, 2012, Sarah Sharp wrote:
> > Two weeks ago at Linux Plumbers Conference, I presented about the Intel
> > Lynx Point USB port power off mechanism. This email is a report out of
> > what was discussed, and a kick of
On Monday, September 24, 2012, Arjan van de Ven wrote:
> On 9/24/2012 12:13 AM, Alan Stern wrote:
> > Therefore all we need is an API for individual devices, not for
> > domains. Of course, userspace may want to know which devices all
> > belong to the same power domain.
>
> agreed on both.
>
>
On Monday, September 24, 2012, Arjan van de Ven wrote:
> On 9/23/2012 8:33 PM, Rafael J. Wysocki wrote:
> > On Sunday, September 23, 2012, Peter Stuge wrote:
> >> Rafael J. Wysocki wrote:
> >>> Well, we actually need to handle power domains appropriately.
> >> ..
> >>> Some work in that direction h
On Sunday, September 23, 2012, Peter Stuge wrote:
> Rafael J. Wysocki wrote:
> > > Is there already an API for power domains there? What does it look like?
> >
> > Yes, there is, as it turns out. :-)
> >
> > Please see drivers/base/power/domain.c and include/linux/pm_domain.h.
> >
> > Of course,
On 9/24/2012 12:13 AM, Alan Stern wrote:
> Therefore all we need is an API for individual devices, not for
> domains. Of course, userspace may want to know which devices all
> belong to the same power domain.
agreed on both.
I'd like PowerTOP to be able to report at least who keeps power alive a
On 9/23/2012 8:33 PM, Rafael J. Wysocki wrote:
> On Sunday, September 23, 2012, Peter Stuge wrote:
>> Rafael J. Wysocki wrote:
>>> Well, we actually need to handle power domains appropriately.
>> ..
>>> Some work in that direction has been done in the ARM space, where we have
>>> much more direct a
On Sun, 23 Sep 2012, Peter Stuge wrote:
> For starters I would like an API that sets a power domain on or off.
>
> I think that would be the simplest API, and maybe a good place to
> start. There is definitely room for more complex API as well, getting
> into various policies and so on, but to be
Rafael J. Wysocki wrote:
> > Is there already an API for power domains there? What does it look like?
>
> Yes, there is, as it turns out. :-)
>
> Please see drivers/base/power/domain.c and include/linux/pm_domain.h.
>
> Of course, this only covers a limited set of use cases at the moment, but I
On Sunday, September 23, 2012, Lan Tianyu wrote:
> 于 2012/9/22 20:08, Rafael J. Wysocki 写道:
> > So, my current idea is why don't we handle that through PM QoS? I mean we
> > have
> > a means to specify per-device PM QoS wakeup latency constraits and expose
> > it to
> > user space on a per-devic
On Sunday, September 23, 2012, Peter Stuge wrote:
> Rafael J. Wysocki wrote:
> > Well, we actually need to handle power domains appropriately.
> ..
> > Some work in that direction has been done in the ARM space, where we have
> > much more direct access to hardware, and I suppose it may be extended
On Sunday, September 23, 2012, Lan Tianyu wrote:
> 于 2012/9/23 3:54, Rafael J. Wysocki 写道:
> > On Friday, September 21, 2012, Peter Stuge wrote:
> >> Sarah Sharp wrote:
> > If userspace really wants the port off (e.g. to disconnect and
> > reconnect a misbehaving device), then it can set th
于 2012/9/23 3:54, Rafael J. Wysocki 写道:
On Friday, September 21, 2012, Peter Stuge wrote:
Sarah Sharp wrote:
If userspace really wants the port off (e.g. to disconnect and
reconnect a misbehaving device), then it can set the sysfs file
to off.
And unless all ganged ports are also off it will
于 2012/9/22 20:08, Rafael J. Wysocki 写道:
So, my current idea is why don't we handle that through PM QoS? I mean we have
a means to specify per-device PM QoS wakeup latency constraits and expose it to
user space on a per-device basis. I suppose we can we can handle the
"don't remove power from t
Rafael J. Wysocki wrote:
> Well, we actually need to handle power domains appropriately.
..
> Some work in that direction has been done in the ARM space, where we have
> much more direct access to hardware, and I suppose it may be extended to
> things like "ganged sets of ports" (which actually are
On Friday, September 21, 2012, Peter Stuge wrote:
> Sarah Sharp wrote:
> > > > If userspace really wants the port off (e.g. to disconnect and
> > > > reconnect a misbehaving device), then it can set the sysfs file
> > > > to off.
> > >
> > > And unless all ganged ports are also off it will fail. U
On Friday, September 21, 2012, Sarah Sharp wrote:
> On Fri, Sep 21, 2012 at 04:09:13PM -0400, Alan Stern wrote:
> > On Thu, 20 Sep 2012, Sarah Sharp wrote:
> >
> > > Two weeks ago at Linux Plumbers Conference, I presented about the Intel
> > > Lynx Point USB port power off mechanism. This email i
On Friday, September 21, 2012, Sarah Sharp wrote:
> Two weeks ago at Linux Plumbers Conference, I presented about the Intel
> Lynx Point USB port power off mechanism. This email is a report out of
> what was discussed, and a kick off point for further discussion.
>
> LPC Report out
>
On Fri, Sep 21, 2012 at 04:09:13PM -0400, Alan Stern wrote:
> On Thu, 20 Sep 2012, Sarah Sharp wrote:
>
> > Two weeks ago at Linux Plumbers Conference, I presented about the Intel
> > Lynx Point USB port power off mechanism. This email is a report out of
> > what was discussed, and a kick off poi
Sarah Sharp wrote:
> > > If userspace really wants the port off (e.g. to disconnect and
> > > reconnect a misbehaving device), then it can set the sysfs file
> > > to off.
> >
> > And unless all ganged ports are also off it will fail. Userspace will
> > want to know about that, and why, along with
On Fri, 21 Sep 2012, Sarah Sharp wrote:
> > > If userspace really wants the port off (e.g. to disconnect and
> > > reconnect a misbehaving device), then it can set the sysfs file
> > > to off.
> >
> > And unless all ganged ports are also off it will fail. Userspace will
> > want to know about tha
On Fri, Sep 21, 2012 at 08:54:38PM +0200, Peter Stuge wrote:
> Sarah Sharp wrote:
> > > How will userspace know why powering off the port does not work?
> >
> > We can expose the power resources in sysfs, so userspace can figure out
> > which ports are under which power resources.
>
> Sorry, I sh
On Thu, 20 Sep 2012, Sarah Sharp wrote:
> Two weeks ago at Linux Plumbers Conference, I presented about the Intel
> Lynx Point USB port power off mechanism. This email is a report out of
> what was discussed, and a kick off point for further discussion.
> - Len Brown mentioned that it's likely
Sarah Sharp wrote:
> > How will userspace know why powering off the port does not work?
>
> We can expose the power resources in sysfs, so userspace can figure out
> which ports are under which power resources.
Sorry, I should have clarified.
> If userspace really wants the port off (e.g. to di
On Fri, Sep 21, 2012 at 08:18:21PM +0200, Peter Stuge wrote:
> Hi,
>
> Sarah Sharp wrote:
> > Two weeks ago at Linux Plumbers Conference, I presented about the
> > Intel Lynx Point USB port power off mechanism.
>
> Good session with some participation, thanks to all!
>
>
> > The end result of t
On Fri, Sep 21, 2012 at 08:21:01PM +0200, Peter Stuge wrote:
> Sarah Sharp wrote:
> > a userspace program claims the interface via usbfs and reads from
> > the device when it wants to capture a finger scan. The kernel's
> > "auto" power policy would turn back on the port as soon as the
> > interfa
Sarah Sharp wrote:
> a userspace program claims the interface via usbfs and reads from
> the device when it wants to capture a finger scan. The kernel's
> "auto" power policy would turn back on the port as soon as the
> interface was claimed through usbfs.
This translates to a slightly less appea
Hi,
Sarah Sharp wrote:
> Two weeks ago at Linux Plumbers Conference, I presented about the
> Intel Lynx Point USB port power off mechanism.
Good session with some participation, thanks to all!
> The end result of those patches is that we expose a sysfs file per USB
> port to userspace to allow
On Fri, Sep 21, 2012 at 11:36:37AM +0800, Lan Tianyu wrote:
> On 2012年09月21日 09:52, Peter Chen wrote:
> >>
> >> Where I would like to see this work go is to have a certain set of
> >> "safe" internal USB devices be powered off by default when they are
> >> suspended. I think fingerprint readers an
On 2012年09月21日 09:52, Peter Chen wrote:
>>
>> Where I would like to see this work go is to have a certain set of
>> "safe" internal USB devices be powered off by default when they are
>> suspended. I think fingerprint readers and webcams would be a good
>> start, but we probably can't do bluetooth
>
> Where I would like to see this work go is to have a certain set of
> "safe" internal USB devices be powered off by default when they are
> suspended. I think fingerprint readers and webcams would be a good
> start, but we probably can't do bluetooth, 3G modems, BMCs, etc. We
> would need a ne
43 matches
Mail list logo
