RE: Ottawa

RE: Ottawa

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1557 bytes --]


On Fri, 11 Mar 2005, Benjamin Herrenschmidt wrote:

> I totally agree. I think we badly need a PM workshop of some sort,
> either before or after KS/OLS, if possible at the same place, with a
> least a couple of days so we have time to 1) expose all the issues, 2)
> get over the usual misunderstanding, 3) agree on a set of solutions.

I totally agree. So, how do we do it?

Doing it before KS would be the best, IMO. How long do we want, 1 day? 2
days? If we take 1 day, we could do it on Sunday, which would require
everyone show up by Saturday (earlier for more recovery time). That would
give us a good 6-14 hours of talk time, with plenty of breaks for food,
beer, sanity, etc.

The other thing we need is a venue. Unless we magically got some sort of
sponsorship, and someone stepped forward to organize a location, we need
something for free. What I suggest is that someone get a 'Business Suite'
at Les Suites and we have it there.

I had one of those rooms 2 years ago, and it included a kitchen, dining
room w/ table/living room w/ couch, an office attached to that. The
bedroom was separate. It was larger than some apartments I've lived in. It
could comfortably seat at least 6-8 people, and we'd have lots of room for
laptops, etc.

On that note, no matter where we have it, I'd like to limit it to 6-8
people, with at most maybe 10. I don't wish to exclude anyone, but I think
that smaller groups can remain more focused. Plus, there's all those
sociological studies that say 6-7 people is the optimal size for a
discussion group. :)


	Pat

[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

RE: Ottawa

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

Hi.

On Sat, 2005-03-12 at 08:06, Patrick Mochel wrote:
> On that note, no matter where we have it, I'd like to limit it to 6-8
> people, with at most maybe 10. I don't wish to exclude anyone, but I think
> that smaller groups can remain more focused. Plus, there's all those
> sociological studies that say 6-7 people is the optimal size for a
> discussion group. :)

I don't mind being left out, so long as the recording is good.

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net


[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

RE: Ottawa

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 743 bytes --]


On Sat, 12 Mar 2005, Nigel Cunningham wrote:

> Hi.
>
> On Sat, 2005-03-12 at 08:06, Patrick Mochel wrote:
> > On that note, no matter where we have it, I'd like to limit it to 6-8
> > people, with at most maybe 10. I don't wish to exclude anyone, but I think
> > that smaller groups can remain more focused. Plus, there's all those
> > sociological studies that say 6-7 people is the optimal size for a
> > discussion group. :)
>
> I don't mind being left out, so long as the recording is good.

No recordings, please. Not only would acquiring equipment add to the
complexity, but I'd much rather speak directly to a known audience than
anonymously to an unknown one..

I would think you would be one of the necessary people, anyway..

	Pat

[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

RE: Ottawa

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

Hi.

On Sat, 2005-03-12 at 08:44, Patrick Mochel wrote:
> On Sat, 12 Mar 2005, Nigel Cunningham wrote:
> 
> > Hi.
> >
> > On Sat, 2005-03-12 at 08:06, Patrick Mochel wrote:
> > > On that note, no matter where we have it, I'd like to limit it to 6-8
> > > people, with at most maybe 10. I don't wish to exclude anyone, but I think
> > > that smaller groups can remain more focused. Plus, there's all those
> > > sociological studies that say 6-7 people is the optimal size for a
> > > discussion group. :)
> >
> > I don't mind being left out, so long as the recording is good.
> 
> No recordings, please. Not only would acquiring equipment add to the
> complexity, but I'd much rather speak directly to a known audience than
> anonymously to an unknown one..

Sorry. I didn't mean tape recording; I was just meaning something along
the lines of minute taking :>

> I would think you would be one of the necessary people, anyway..

I was afraid you were going to say that :> I'd really like to go to
church in the morning; any chance of an afternoon start?

Regards,

Nigel

-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net


[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

RE: Ottawa

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 668 bytes --]


On Sat, 12 Mar 2005, Nigel Cunningham wrote:

> > I would think you would be one of the necessary people, anyway..
>
> I was afraid you were going to say that :> I'd really like to go to
> church in the morning; any chance of an afternoon start?

Ah. In all actuality, I'd prefer a Saturday meeting and take Sunday off.
The KS + OLS is 6 days, and having a day between intensities seems
attrractive.

On a more pragmatic note, there is always a dinner for KS attendees on
Sunday evening. By taking an afternoon start, we set a hard limit of the
length of the meeting. If it comes down to it, we can start in the
morning, and you can join us in the afternoon..


	Pat

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: Ottawa

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

Suits me fine :>

I haven't booked my flights yet, so could still seek to arrive Friday or
Saturday. What time on Saturday are you thinking?

Regards,

Nigel

On Tue, 2005-03-15 at 05:05, Patrick Mochel wrote:
> On Sat, 12 Mar 2005, Nigel Cunningham wrote:
> 
> > > I would think you would be one of the necessary people, anyway..
> >
> > I was afraid you were going to say that :> I'd really like to go to
> > church in the morning; any chance of an afternoon start?
> 
> Ah. In all actuality, I'd prefer a Saturday meeting and take Sunday off.
> The KS + OLS is 6 days, and having a day between intensities seems
> attrractive.
> 
> On a more pragmatic note, there is always a dinner for KS attendees on
> Sunday evening. By taking an afternoon start, we set a hard limit of the
> length of the meeting. If it comes down to it, we can start in the
> morning, and you can join us in the afternoon..
> 
> 
> 	Pat
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: Ottawa

[Benjamin Herrenschmidt]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

On Fri, 2005-03-11 at 13:06 -0800, Patrick Mochel wrote:
> On Fri, 11 Mar 2005, Benjamin Herrenschmidt wrote:
> 
> > I totally agree. I think we badly need a PM workshop of some sort,
> > either before or after KS/OLS, if possible at the same place, with a
> > least a couple of days so we have time to 1) expose all the issues, 2)
> > get over the usual misunderstanding, 3) agree on a set of solutions.
> 
> I totally agree. So, how do we do it?

You could try to contact usenix maybe ? Or talk to Ted ?

> Doing it before KS would be the best, IMO. How long do we want, 1 day? 2
> days? If we take 1 day, we could do it on Sunday, which would require
> everyone show up by Saturday (earlier for more recovery time). That would
> give us a good 6-14 hours of talk time, with plenty of breaks for food,
> beer, sanity, etc.

1 day may not be enough, but we could do one day + a BOF ...

> The other thing we need is a venue. Unless we magically got some sort of
> sponsorship, and someone stepped forward to organize a location, we need
> something for free. What I suggest is that someone get a 'Business Suite'
> at Les Suites and we have it there.

Ok... Well, afaik, I'll have to go to some random IBM approved hotel,
but I'm not sure at this point.

> I had one of those rooms 2 years ago, and it included a kitchen, dining
> room w/ table/living room w/ couch, an office attached to that. The
> bedroom was separate. It was larger than some apartments I've lived in. It
> could comfortably seat at least 6-8 people, and we'd have lots of room for
> laptops, etc.
> 
> On that note, no matter where we have it, I'd like to limit it to 6-8
> people, with at most maybe 10. I don't wish to exclude anyone, but I think
> that smaller groups can remain more focused. Plus, there's all those
> sociological studies that say 6-7 people is the optimal size for a
> discussion group. :)

Us, Nigel, David Brownell, Alan, Pavel, Brown, we are already 7... ?

Ben.



[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: Ottawa

[Jordan Crouse]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

On Sat, 12 Mar 2005 10:54:55 +1100
"Benjamin Herrenschmidt" <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:

> > On that note, no matter where we have it, I'd like to limit it to
> > 6-8 people, with at most maybe 10. I don't wish to exclude anyone,
> > but I think that smaller groups can remain more focused. Plus,
> > there's all those sociological studies that say 6-7 people is the
> > optimal size for a discussion group. :)
> 
> Us, Nigel, David Brownell, Alan, Pavel, Brown, we are already 7... ?

Are there any logical divisions of area of interest that could result in
multiple productive meetings? 
  
Jordan

-- 
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>






[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: Ottawa

[Benjamin Herrenschmidt]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

On Fri, 2005-03-11 at 17:08 -0700, Jordan Crouse wrote:
> On Sat, 12 Mar 2005 10:54:55 +1100
> "Benjamin Herrenschmidt" <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
> 
> > > On that note, no matter where we have it, I'd like to limit it to
> > > 6-8 people, with at most maybe 10. I don't wish to exclude anyone,
> > > but I think that smaller groups can remain more focused. Plus,
> > > there's all those sociological studies that say 6-7 people is the
> > > optimal size for a discussion group. :)
> > 
> > Us, Nigel, David Brownell, Alan, Pavel, Brown, we are already 7... ?
> 
> Are there any logical divisions of area of interest that could result in
> multiple productive meetings? 

Not sure. There are 2 different "main" areas, which are the global
system suspend/resume, and the "local" or "dynamic" power management of
devices & busses. We have a good solution for the first, but not for the
second at this point, so I would expect that we concentrate on that
part.

Plus some always-pending issues for global suspend, the biggest one
beeing video chips that need a re-POST on wakeup.

Ben.



[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: Ottawa

[Adam Belay]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Sat, 2005-03-12 at 11:29 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2005-03-11 at 17:08 -0700, Jordan Crouse wrote:
> > On Sat, 12 Mar 2005 10:54:55 +1100
> > "Benjamin Herrenschmidt" <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
> > 
> > > > On that note, no matter where we have it, I'd like to limit it to
> > > > 6-8 people, with at most maybe 10. I don't wish to exclude anyone,
> > > > but I think that smaller groups can remain more focused. Plus,
> > > > there's all those sociological studies that say 6-7 people is the
> > > > optimal size for a discussion group. :)
> > > 
> > > Us, Nigel, David Brownell, Alan, Pavel, Brown, we are already 7... ?
> > 
> > Are there any logical divisions of area of interest that could result in
> > multiple productive meetings? 
> 
> Not sure. There are 2 different "main" areas, which are the global
> system suspend/resume, and the "local" or "dynamic" power management of
> devices & busses. We have a good solution for the first, but not for the
> second at this point, so I would expect that we concentrate on that
> part.
> 
> Plus some always-pending issues for global suspend, the biggest one
> beeing video chips that need a re-POST on wakeup.
> 
> Ben.

Under the topic of dynamic power management, there are a few logical
divisions of interest:

1.) Low-level - providing the bus support and facilities for higher
level power management (ex. the current work I'm doing with the PCI bus
driver).  Also support for power domains might fall under this category.

2.) Driver state and driver relationships - logical vs. physical, driver
API, threading power management to transition multiple devices at once,
etc

3.) Power Management Policy - determining which behavior to take for
various classes of devices, how to determine idleness etc., and how to
control/monitor those devices.

4.) Userspace - how to notify of power changes, how to allow the user to
control power management.

Anything else?

Thanks,
Adam



[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: Ottawa

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]

On Friday 11 March 2005 5:08 pm, Adam Belay wrote:
> 
> Under the topic of dynamic power management, there are a few logical
> divisions of interest:
> 
> 1.) Low-level - providing the bus support and facilities for higher
> level power management (ex. the current work I'm doing with the PCI bus
> driver).  Also support for power domains might fall under this category.
> 
> 2.) Driver state and driver relationships - logical vs. physical, driver
> API, threading power management to transition multiple devices at once,
> etc

Clock management.  ARM (and other) SOC based boards commonly have
schemes to gate clocks off when the peripheral in question is unused,
thereby saving power.  <asm-arm/hardware/clock.h> has an API used to
explicitly represent the clock tree.

So a common mode of operation with such systems will be to keep
the peripheral unclocked (saving power) until it's needed.  I don't
actually see any reason to routinely plan policy options there,
that'd just be pointless extra work.  clk_use() when the device
is active, clk_unuse() otherwise.  And in some cases "suspended"
will mean "unused" for at least some clocks.

That's sort of a "low level" category ... except that it pops up to
higher level concerns.  For example, clocks may be shared (which can
make the "low level" vs "driver state and relationships" distinctions
look nonexistent), and they may interact with system power transitions. 

Plus there are interactions with external devices.  For example, some
SOCs can enter various deep sleep states when USB is either suspended
(by the host) or disconnected ... but not all.  (And some could do it
given external transceiver support...)  So there may be a choice between
entering a deeper sleep, or discarding active device state...


> 3.) Power Management Policy - determining which behavior to take for
> various classes of devices, how to determine idleness etc., and how to
> control/monitor those devices.

The primary mechanism I've heard discussed is having devices monitor
when they haven't been used recently, and using that to enter some
suspend level.  The "not even active" clock gating approach isn't
quite the same.

 
> 4.) Userspace - how to notify of power changes, how to allow the user to
> control power management.
> 
> Anything else?

Oh, and wakeup event sources.  ACPI has a very indirect approach,
which seems to underlay some assumptions on this list.  There's a
similar thing going on with PCI.  So for example when folk start
to assume that a "wakeup" event is for some reason distinct from
the device's normal IRQ, I must cringe ... anyone assuming that
device or system suspend involves turning off IRQs is erecting
roadblocks against most embedded hardware.

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Ottawa

[Benjamin Herrenschmidt]

[-- Attachment #1: Type: text/plain, Size: 4517 bytes --]


> Clock management.  ARM (and other) SOC based boards commonly have
> schemes to gate clocks off when the peripheral in question is unused,
> thereby saving power.  <asm-arm/hardware/clock.h> has an API used to
> explicitly represent the clock tree.

I have similar stuff on pmac, though probably not as detailed as the ARM
ones, I think it's orthogonal to the PM model. That is, it's up to a
device driver to decide wether to "release" it's clock or not based on
it's state, the clock net management beeing completely separated from
the actual device state management. That's also how I do it on pmac, and
I think hwo Apple does it.

> So a common mode of operation with such systems will be to keep
> the peripheral unclocked (saving power) until it's needed.  I don't
> actually see any reason to routinely plan policy options there,
> that'd just be pointless extra work.  clk_use() when the device
> is active, clk_unuse() otherwise.  And in some cases "suspended"
> will mean "unused" for at least some clocks.

Yes, but it's orthogonal to the PM model. A device could even request
slower clocks in intermediate power states or whatever, but it's the
device driver that calls into the "clock manager" on power state
transitions (or even at runtime) to express it's needs.

> That's sort of a "low level" category ... except that it pops up to
> higher level concerns.  For example, clocks may be shared (which can
> make the "low level" vs "driver state and relationships" distinctions
> look nonexistent), and they may interact with system power transitions. 

A bit, but then, the clock net is often even more scary than the power
tree. I wouldn't try to mix them up.

> Plus there are interactions with external devices.  For example, some
> SOCs can enter various deep sleep states when USB is either suspended
> (by the host) or disconnected ... but not all.  (And some could do it
> given external transceiver support...)  So there may be a choice between
> entering a deeper sleep, or discarding active device state...
> 
> 
> > 3.) Power Management Policy - determining which behavior to take for
> > various classes of devices, how to determine idleness etc., and how to
> > control/monitor those devices.
> 
> The primary mechanism I've heard discussed is having devices monitor
> when they haven't been used recently, and using that to enter some
> suspend level.  The "not even active" clock gating approach isn't
> quite the same.

Yes, drivers deciding themselves, or through sysfs. Part of the model I
propose is to let drivers expose a richer set of states to userland as
well. Policy for things like handelds can become so complicated that I
think it should be moved to userspace.
 
> > 4.) Userspace - how to notify of power changes, how to allow the user to
> > control power management.
> > 
> > Anything else?
> 
> Oh, and wakeup event sources.  ACPI has a very indirect approach,
> which seems to underlay some assumptions on this list.  There's a
> similar thing going on with PCI.  So for example when folk start
> to assume that a "wakeup" event is for some reason distinct from
> the device's normal IRQ, I must cringe ... anyone assuming that
> device or system suspend involves turning off IRQs is erecting
> roadblocks against most embedded hardware.

Yes and no ... They must be treated differently for sure. There are a
lot of cases where they are actually completely different. The problem
we discussed a while ago with USB is an example of the mess, and I still
have to investigate in details. Basically, the current USB code upstream
will crash the machine on sleep 90% of the times when I have something
plugged, while the same set of devices sleeps happily in OS X 100% of
the time. So we must be doing something wrong.

Wether the system IRQs must be masked or not is one thing that is
platform specific during suspend. Wether devices must stop their IRQ
emission, well... At least with USB, you do free_irq(). That means that
unless your IRQ is shared, it _will_ be masked at the controller level
anyway. So if the IRQ is used to wakeup the CPU, that is broken, at
least unless the IRQ line from the device (before reaching the IRQ
controller) is also triggering some sort of external wakeup mecanism.

I tend to think that devices using IRQs for wakeup instead of separate
IOs are broken design, but then, we all know that HW folks can't get
anything right ;)

In some cases, we might have to provide some arch hooks to be called by
drivers to know what to do ...

Ben.


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Ottawa [topics]

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 5852 bytes --]

On Sunday 13 March 2005 9:07 pm, Benjamin Herrenschmidt wrote:
> 
> > Clock management.  ARM (and other) SOC based boards commonly have
> > schemes to gate clocks off when the peripheral in question is unused,
> > thereby saving power.  <asm-arm/hardware/clock.h> has an API used to
> > explicitly represent the clock tree.
> 
> I have similar stuff on pmac, though probably not as detailed as the ARM
> ones, I think it's orthogonal to the PM model. That is, it's up to a
> device driver to decide wether to "release" it's clock or not based on
> it's state, the clock net management beeing completely separated from
> the actual device state management. That's also how I do it on pmac, and
> I think hwo Apple does it.

Sort of.  Point being that clock management is often the only
hardware control over peripheral power consumption.  Clock
usage appears both as "driver-internal" state ... and also
as a constraint affecting the possible system PM transitions.


> > So a common mode of operation with such systems will be to keep
> > the peripheral unclocked (saving power) until it's needed.  I don't
> > actually see any reason to routinely plan policy options there,
> > that'd just be pointless extra work.  clk_use() when the device
> > is active, clk_unuse() otherwise.  And in some cases "suspended"
> > will mean "unused" for at least some clocks.
> 
> Yes, but it's orthogonal to the PM model. A device could even request
> slower clocks in intermediate power states or whatever, but it's the
> device driver that calls into the "clock manager" on power state
> transitions (or even at runtime) to express it's needs.

Not orthogonal.  Suspending a device will often involve a clock
transition ... and certain clocking levels will preclude certain
system PM states.


> > That's sort of a "low level" category ... except that it pops up to
> > higher level concerns.  For example, clocks may be shared (which can
> > make the "low level" vs "driver state and relationships" distinctions
> > look nonexistent), and they may interact with system power transitions. 
> 
> A bit, but then, the clock net is often even more scary than the power
> tree. I wouldn't try to mix them up.

Embedded chips normally couple clock management with power management
very tightly.  They may have separate power switching controls, but
that's less widespread.

 
> > The primary mechanism I've heard discussed is having devices monitor
> > when they haven't been used recently, and using that to enter some
> > suspend level.  The "not even active" clock gating approach isn't
> > quite the same.
> 
> Yes, drivers deciding themselves, or through sysfs. Part of the model I
> propose is to let drivers expose a richer set of states to userland as
> well. Policy for things like handelds can become so complicated that I
> think it should be moved to userspace.

When drivers just don't use clocks they don't need (a "policy"), it
gets simple rather quickly.  Pushing it to userspace would be a way
to add complexity ... IMO a non-goal.


> > > 4.) Userspace - how to notify of power changes, how to allow the user to
> > > control power management.
> > > 
> > > Anything else?
> > 
> > Oh, and wakeup event sources.  ACPI has a very indirect approach,
> > which seems to underlay some assumptions on this list.  There's a
> > similar thing going on with PCI.  So for example when folk start
> > to assume that a "wakeup" event is for some reason distinct from
> > the device's normal IRQ, I must cringe ... anyone assuming that
> > device or system suspend involves turning off IRQs is erecting
> > roadblocks against most embedded hardware.
> 
> Yes and no ... They must be treated differently for sure. There are a
> lot of cases where they are actually completely different.

And as many when they aren't.  Hence my point that assuming they ARE
is making trouble.  Some of the swsusp discussions seem to bring that
notion out.


> The problem 
> we discussed a while ago with USB is an example of the mess, and I still
> have to investigate in details. Basically, the current USB code upstream
> will crash the machine on sleep 90% of the times when I have something
> plugged, while the same set of devices sleeps happily in OS X 100% of
> the time. So we must be doing something wrong.

Orthogonal issue; still loks specific to your hardware.


> Wether the system IRQs must be masked or not is one thing that is
> platform specific during suspend. Wether devices must stop their IRQ
> emission, well... 

What's a "system IRQ" as opposed to any other kind?  Drivers don't
generally know or care how their IRQs are routed, they just care
that they get a callback.


> At least with USB, you do free_irq(). That means that 
> unless your IRQ is shared, it _will_ be masked at the controller level
> anyway. So if the IRQ is used to wakeup the CPU, that is broken, at
> least unless the IRQ line from the device (before reaching the IRQ
> controller) is also triggering some sort of external wakeup mecanism.

That's a good example of a PCI-specific assumption, the type I
was saying creates problems.  Non-PCI hardware has no reason to
free the IRQ.  (In fact, the only reason PCI hardware does it is
to keep that PPC-ism out of the OHCI code.)

 
> I tend to think that devices using IRQs for wakeup instead of separate
> IOs are broken design, but then, we all know that HW folks can't get
> anything right ;)

Again, that's a strong PCI bias.  Having PCI biases like that is
just creating trouble.  In fact, not all PCI hardware works that
way either ... just stuff using the PCI PM model.  And the last
many PCI busess I've looked at have had devices that don't use
the PCM PM attributes, don't support PCI D3 ...

- Dave



> In some cases, we might have to provide some arch hooks to be called by
> drivers to know what to do ...
> 
> Ben.
> 
> 

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Ottawa [topics]

[Benjamin Herrenschmidt]

[-- Attachment #1: Type: text/plain, Size: 6742 bytes --]

On Wed, 2005-03-16 at 13:50 -0800, David Brownell wrote:

> > 
> > Yes, but it's orthogonal to the PM model. A device could even request
> > slower clocks in intermediate power states or whatever, but it's the
> > device driver that calls into the "clock manager" on power state
> > transitions (or even at runtime) to express it's needs.
> 
> Not orthogonal.  Suspending a device will often involve a clock
> transition ... and certain clocking levels will preclude certain
> system PM states.

 .../...

Oh well, then come up with a scheme that can deal with those without
beeing as big as the kernel itself...

> 
> > > That's sort of a "low level" category ... except that it pops up to
> > > higher level concerns.  For example, clocks may be shared (which can
> > > make the "low level" vs "driver state and relationships" distinctions
> > > look nonexistent), and they may interact with system power transitions. 
> > 
> > A bit, but then, the clock net is often even more scary than the power
> > tree. I wouldn't try to mix them up.
> 
> Embedded chips normally couple clock management with power management
> very tightly.  They may have separate power switching controls, but
> that's less widespread.

I am familiar with that, and I still think this shouldn't be directly
dealt by the PM framework. In fact, in most embedded cases, drivers are
specific anyway and can embed the clock net stuff.

>  
> > > The primary mechanism I've heard discussed is having devices monitor
> > > when they haven't been used recently, and using that to enter some
> > > suspend level.  The "not even active" clock gating approach isn't
> > > quite the same.
> > 
> > Yes, drivers deciding themselves, or through sysfs. Part of the model I
> > propose is to let drivers expose a richer set of states to userland as
> > well. Policy for things like handelds can become so complicated that I
> > think it should be moved to userspace.
> 
> When drivers just don't use clocks they don't need (a "policy"), it
> gets simple rather quickly.  Pushing it to userspace would be a way
> to add complexity ... IMO a non-goal.

Gah ? Did you understand what I said ?
> 
> > > > 4.) Userspace - how to notify of power changes, how to allow the user to
> > > > control power management.
> > > > 
> > > > Anything else?
> > > 
> > > Oh, and wakeup event sources.  ACPI has a very indirect approach,
> > > which seems to underlay some assumptions on this list.  There's a
> > > similar thing going on with PCI.  So for example when folk start
> > > to assume that a "wakeup" event is for some reason distinct from
> > > the device's normal IRQ, I must cringe ... anyone assuming that
> > > device or system suspend involves turning off IRQs is erecting
> > > roadblocks against most embedded hardware.
> > 
> > Yes and no ... They must be treated differently for sure. There are a
> > lot of cases where they are actually completely different.
> 
> And as many when they aren't.  Hence my point that assuming they ARE
> is making trouble.  Some of the swsusp discussions seem to bring that
> notion out.

It's all bla bla bla as far as I'm concerned, we should find a model and
see if it actually precludes anything. I think in all cases, the
specifics of clock dependencies can be expressed as power state
dependencies.
> 
> > The problem 
> > we discussed a while ago with USB is an example of the mess, and I still
> > have to investigate in details. Basically, the current USB code upstream
> > will crash the machine on sleep 90% of the times when I have something
> > plugged, while the same set of devices sleeps happily in OS X 100% of
> > the time. So we must be doing something wrong.
> 
> Orthogonal issue; still loks specific to your hardware.

"My" hardware is jsut a fucking standard NEC USB2 chip in most cases and
a lucent cell in Apple stuff in the other. Also "My" hardware is also
the class of laptops that happen to have had working sleep support for
much longer and much more reliably than any x86 out there. You are
breaking that and don't seem to be interested in making that work. THat
makes me thing that working sleep on USB today is just a matter of luck.
 
> > Wether the system IRQs must be masked or not is one thing that is
> > platform specific during suspend. Wether devices must stop their IRQ
> > emission, well... 
> 
> What's a "system IRQ" as opposed to any other kind?  Drivers don't
> generally know or care how their IRQs are routed, they just care
> that they get a callback.

"system irq" means masking the irq at the PIC level (enable/disable irq)
while masking the irq at the device level means stopping irq emission on
the device using device local registers. It's totally different and may
have a different impact on PM depending on how wakeup works.
> 
> > At least with USB, you do free_irq(). That means that 
> > unless your IRQ is shared, it _will_ be masked at the controller level
> > anyway. So if the IRQ is used to wakeup the CPU, that is broken, at
> > least unless the IRQ line from the device (before reaching the IRQ
> > controller) is also triggering some sort of external wakeup mecanism.
> 
> That's a good example of a PCI-specific assumption, the type I
> was saying creates problems.  Non-PCI hardware has no reason to
> free the IRQ.  (In fact, the only reason PCI hardware does it is
> to keep that PPC-ism out of the OHCI code.)

Which we have to keep anyway for the suspend code. And embedded with
bizarre clock stuff will need hooks there too. I don't understand how
you try to get the ppc stuff out on one side and deal with all the
embedded cruft on the other. Masking IRQ in my case is mostly a matter
of sanity. I'm switching the main clock off on the OHCI cell and disable
the cell in the ASIC, I disable the IRQ that I know is not shared to
make sure that there is no "dangling" irq line. I'm fairly sure other
platforms (embedded especially) will need similar tweaks.
>  
> > I tend to think that devices using IRQs for wakeup instead of separate
> > IOs are broken design, but then, we all know that HW folks can't get
> > anything right ;)
> 
> Again, that's a strong PCI bias.

Not at all. I would have said the same before we had PCI PM in the PCI
spec.

>   Having PCI biases like that is
> just creating trouble.  In fact, not all PCI hardware works that
> way either ... just stuff using the PCI PM model.  And the last
> many PCI busess I've looked at have had devices that don't use
> the PCM PM attributes, don't support PCI D3 ...
> 
> - Dave
> 
> 
> 
> > In some cases, we might have to provide some arch hooks to be called by
> > drivers to know what to do ...
> > 
> > Ben.
> > 
> > 
-- 
Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Ottawa [topics]

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 6571 bytes --]

On Wednesday 16 March 2005 3:40 pm, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-16 at 13:50 -0800, David Brownell wrote:
> 
> > > 
> > > Yes, but it's orthogonal to the PM model. A device could even request
> > > slower clocks in intermediate power states or whatever, but it's the
> > > device driver that calls into the "clock manager" on power state
> > > transitions (or even at runtime) to express it's needs.
> > 
> > Not orthogonal.  Suspending a device will often involve a clock
> > transition ... and certain clocking levels will preclude certain
> > system PM states.
> 
>  .../...
> 
> Oh well, then come up with a scheme that can deal with those without
> beeing as big as the kernel itself...

If suspend-prepare fails, then the pm core backs out of that state
transition.  That's one part -- isolating core from many details,
and keeping it from needing to centrally manage every minor detail.


Another part is something I've been implying quite a lot:  that many
system power transitions should be "opportunistic".  Drivers would
have default "low power when unused" policies.  Parents would see
low power children, and could enter low power states themselves.

Then the platform PM logic could automatically enter appropriate
system PM states.  E.g. using the variable scheduler timeout stuff
to notice that now might be a good time to enter "big sleep" or
some other S1 or "suspend" analogue ... or that since the 48 MHz
clock is off, that "deep sleep" (or other S3 analogue) is possible.
With various wakeup sources including the system timer, of course.

That could tie into the centrally managed power state transitions
as follows:  userspace says "goto state FOO", device tree is notified,
the above opportunistic logic kicks in.  When the tree notifications
complete, the same logic called from the VST code could kick in.
Same result:  system goes into S1, or S3, or whatever.  Just it's
done by userspace request, not automatically.  (A policy choice.)


This just uses the existing PM infrastructure intelligently, with
minor additions to pass information up the tree ... and to use
that information once it's there.  It decentralizes much of the
key decision making, leveraging hardware PM support.


> > Embedded chips normally couple clock management with power management
> > very tightly.  They may have separate power switching controls, but
> > that's less widespread.
> 
> I am familiar with that, and I still think this shouldn't be directly
> dealt by the PM framework. In fact, in most embedded cases, drivers are
> specific anyway and can embed the clock net stuff.

That just won't work.  They're joined at the hip.  Drivers embed much
clock tree knowledge, that goes without saying.  But at the same time,
the platform PM code has to understand very basic rules like "these
clocks must be off before we can enter state FOO" and "state BAR is
like state FOO but these additional clocks must be off".  It's got
to rely on the drivers to gate the clocks correctly, otherwise any
attempt to suspend will just break the drivers.


> "My" hardware is jsut a fucking standard NEC USB2 chip in most cases and
> a lucent cell in Apple stuff in the other. Also "My" hardware is also
> the class of laptops that happen to have had working sleep support for
> much longer and much more reliably than any x86 out there. You are
> breaking that and don't seem to be interested in making that work. THat
> makes me thing that working sleep on USB today is just a matter of luck.

Calm down.  I don't have "your" hardware to test with, and "you" (Paul)
only yesterday posted the first proposed patch.  Expecting me to solve
all your hardware-coupled problems is unreasonable in such cases.

Another thing that's unreasonable is to try to prevent progress in x86
space just because it'd affect PPC.  :)


> > > At least with USB, you do free_irq(). That means that 
> > > unless your IRQ is shared, it _will_ be masked at the controller level
> > > anyway. So if the IRQ is used to wakeup the CPU, that is broken, at
> > > least unless the IRQ line from the device (before reaching the IRQ
> > > controller) is also triggering some sort of external wakeup mecanism.
> > 
> > That's a good example of a PCI-specific assumption, the type I
> > was saying creates problems.  Non-PCI hardware has no reason to
> > free the IRQ.  (In fact, the only reason PCI hardware does it is
> > to keep that PPC-ism out of the OHCI code.)
> 
> Which we have to keep anyway for the suspend code.

You're making no sense to me, since you appear to have just ignored
the point I made.   The PCI code works, modulo bugs, today.  As do
several non-PCI chips, that will absolutely break if you try to
disable their (wakeup) IRQs during suspend.


> And embedded with 
> bizarre clock stuff will need hooks there too.

My example was embedded with non-bizarre clocks, which disproved
the point you were making about IRQs....


> I don't understand how 
> you try to get the ppc stuff out on one side and deal with all the
> embedded cruft on the other. Masking IRQ in my case is mostly a matter
> of sanity. I'm switching the main clock off on the OHCI cell and disable
> the cell in the ASIC, I disable the IRQ that I know is not shared to
> make sure that there is no "dangling" irq line. I'm fairly sure other
> platforms (embedded especially) will need similar tweaks.

Remember that the example I gave was for platforms that do NOT want
to see the IRQs disabled.  They are after all the sources of wakeup
events that take the system out of the sleep/suspend state.  They
do NOT want "similar tweaks" at all.

 
> > > I tend to think that devices using IRQs for wakeup instead of separate
> > > IOs are broken design, but then, we all know that HW folks can't get
> > > anything right ;)
> > 
> > Again, that's a strong PCI bias.
> 
> Not at all. I would have said the same before we had PCI PM in the PCI
> spec.

Well, it's at any rate a faulty assumption that you should stop making.

- Dave


> >   Having PCI biases like that is
> > just creating trouble.  In fact, not all PCI hardware works that
> > way either ... just stuff using the PCI PM model.  And the last
> > many PCI busess I've looked at have had devices that don't use
> > the PCM PM attributes, don't support PCI D3 ...
> > 
> > - Dave
> > 
> > 
> > 
> > > In some cases, we might have to provide some arch hooks to be called by
> > > drivers to know what to do ...
> > > 
> > > Ben.
> > > 
> > > 
> -- 
> Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> 
> 

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Ottawa [topics]

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1413 bytes --]

On Wed, 16 Mar 2005, David Brownell wrote:

> > Wether the system IRQs must be masked or not is one thing that is
> > platform specific during suspend. Wether devices must stop their IRQ
> > emission, well... 
> 
> What's a "system IRQ" as opposed to any other kind?  Drivers don't
> generally know or care how their IRQs are routed, they just care
> that they get a callback.

Given that on some platforms it's necessary to leave some IRQs enabled for 
remote wakeup to work, the definitions of FREEZE and SUSPEND need to be 
changed.  A quiesced device does not perform DMA and does not generate 
interrupt requests _except_ that it may issue wakeup requests (which may 
be IRQs) if it is enabled for remote wakeup.

I don't think this will cause any problems for Suspend To Disk.  If a 
wakeup IRQ arrives before the system is asleep and is fielded by an 
interrupt handler, the handler will try to start a resume.  But resume 
needs a process context to operate, and all processes will be frozen -- so 
nothing will happen.

The case of Suspend To Ram, where processes may not be frozen, can be
solved by suitable device locking.  If the PM core locks all devices
before initiating the sleep transition -- which it should in any case --
and unlocks them after waking up, and if resume processing involves
acquiring the device lock, then again nothing will happen.

Does this help clarify things?

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Ottawa [topics]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

Hi.

On Thu, 2005-03-17 at 15:11, Alan Stern wrote:
> On Wed, 16 Mar 2005, David Brownell wrote:
> 
> > > Wether the system IRQs must be masked or not is one thing that is
> > > platform specific during suspend. Wether devices must stop their IRQ
> > > emission, well... 
> > 
> > What's a "system IRQ" as opposed to any other kind?  Drivers don't
> > generally know or care how their IRQs are routed, they just care
> > that they get a callback.
> 
> Given that on some platforms it's necessary to leave some IRQs enabled for 
> remote wakeup to work, the definitions of FREEZE and SUSPEND need to be 
> changed.  A quiesced device does not perform DMA and does not generate 
> interrupt requests _except_ that it may issue wakeup requests (which may 
> be IRQs) if it is enabled for remote wakeup.

I don't think the definition of FREEZE needs to be changed because -
unless I misunderstand - it is only used when swsusp and Suspend2 are
doing their atomic copies. Pavel, is this right?

> I don't think this will cause any problems for Suspend To Disk.  If a 
> wakeup IRQ arrives before the system is asleep and is fielded by an 
> interrupt handler, the handler will try to start a resume.  But resume 
> needs a process context to operate, and all processes will be frozen -- so 
> nothing will happen.

Does the handler try to start a usermode helper program?

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Ottawa [topics]

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

On Wednesday 16 March 2005 8:44 pm, Nigel Cunningham wrote:
> Hi.
> 
> On Thu, 2005-03-17 at 15:11, Alan Stern wrote:
> > On Wed, 16 Mar 2005, David Brownell wrote:
> > 
> > > > Wether the system IRQs must be masked or not is one thing that is
> > > > platform specific during suspend. Wether devices must stop their IRQ
> > > > emission, well... 
> > > 
> > > What's a "system IRQ" as opposed to any other kind?  Drivers don't
> > > generally know or care how their IRQs are routed, they just care
> > > that they get a callback.
> > 
> > Given that on some platforms it's necessary to leave some IRQs enabled for 
> > remote wakeup to work, the definitions of FREEZE and SUSPEND need to be 
> > changed.  A quiesced device does not perform DMA and does not generate 
> > interrupt requests _except_ that it may issue wakeup requests (which may 
> > be IRQs) if it is enabled for remote wakeup.
> 
> I don't think the definition of FREEZE needs to be changed because -
> unless I misunderstand - it is only used when swsusp and Suspend2 are
> doing their atomic copies. Pavel, is this right?

FWIW this is another case where I think things become clearer if the
model is that swsusp and suspend2 aren't really "suspend/resume", but
are checkpoint-before-poweroff.  If they were really suspend states
(and maybe S4 counts as one of those, on hardware that handles it),
then wakeup would need to work ... otherwise, just say that from the
instant swsusp/suspend2 starts, wakeup is disallowed.

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Ottawa [topics]

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On Čt 17-03-05 15:44:53, Nigel Cunningham wrote:
> Hi.
> 
> On Thu, 2005-03-17 at 15:11, Alan Stern wrote:
> > On Wed, 16 Mar 2005, David Brownell wrote:
> > 
> > > > Wether the system IRQs must be masked or not is one thing that is
> > > > platform specific during suspend. Wether devices must stop their IRQ
> > > > emission, well... 
> > > 
> > > What's a "system IRQ" as opposed to any other kind?  Drivers don't
> > > generally know or care how their IRQs are routed, they just care
> > > that they get a callback.
> > 
> > Given that on some platforms it's necessary to leave some IRQs enabled for 
> > remote wakeup to work, the definitions of FREEZE and SUSPEND need to be 
> > changed.  A quiesced device does not perform DMA and does not generate 
> > interrupt requests _except_ that it may issue wakeup requests (which may 
> > be IRQs) if it is enabled for remote wakeup.
> 
> I don't think the definition of FREEZE needs to be changed because -
> unless I misunderstand - it is only used when swsusp and Suspend2 are
> doing their atomic copies. Pavel, is this right?

Yes, I think so.
								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Ottawa [topics]

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1429 bytes --]

On Thu, 17 Mar 2005, Nigel Cunningham wrote:

> > Given that on some platforms it's necessary to leave some IRQs enabled for 
> > remote wakeup to work, the definitions of FREEZE and SUSPEND need to be 
> > changed.  A quiesced device does not perform DMA and does not generate 
> > interrupt requests _except_ that it may issue wakeup requests (which may 
> > be IRQs) if it is enabled for remote wakeup.
> 
> I don't think the definition of FREEZE needs to be changed because -
> unless I misunderstand - it is only used when swsusp and Suspend2 are
> doing their atomic copies. Pavel, is this right?

Nevertheless the definition still needs to be changed.  As it stands now, 
moving from FREEZE to SUSPEND might involve an _increase_ in device 
activity -- namely, enabling resume IRQs.  That's not what we want.

> > I don't think this will cause any problems for Suspend To Disk.  If a 
> > wakeup IRQ arrives before the system is asleep and is fielded by an 
> > interrupt handler, the handler will try to start a resume.  But resume 
> > needs a process context to operate, and all processes will be frozen -- so 
> > nothing will happen.
> 
> Does the handler try to start a usermode helper program?

Depends on the details of the driver.  But it's impossible to _fork_ a new 
process from an interrupt handler.  You can try to _wakeup_ an existing 
process, but when the process is frozen it can't wake up.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: Ottawa

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 622 bytes --]


Sorry about the delay. Long week.. :/

On Sat, 12 Mar 2005, Benjamin Herrenschmidt wrote:

> > On that note, no matter where we have it, I'd like to limit it to 6-8
> > people, with at most maybe 10. I don't wish to exclude anyone, but I think
> > that smaller groups can remain more focused. Plus, there's all those
> > sociological studies that say 6-7 people is the optimal size for a
> > discussion group. :)
>
> Us, Nigel, David Brownell, Alan, Pavel, Brown, we are already 7... ?

Plus Adam Belay, maybe Greg K-H as the voice of reason, and maybe 1 more
that may arise before then, which would put us at 10.


	Pat

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Ottawa

[Greg KH]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Fri, Mar 18, 2005 at 12:16:50PM -0800, Patrick Mochel wrote:
> 
> Sorry about the delay. Long week.. :/
> 
> On Sat, 12 Mar 2005, Benjamin Herrenschmidt wrote:
> 
> > > On that note, no matter where we have it, I'd like to limit it to 6-8
> > > people, with at most maybe 10. I don't wish to exclude anyone, but I think
> > > that smaller groups can remain more focused. Plus, there's all those
> > > sociological studies that say 6-7 people is the optimal size for a
> > > discussion group. :)
> >
> > Us, Nigel, David Brownell, Alan, Pavel, Brown, we are already 7... ?
> 
> Plus Adam Belay, maybe Greg K-H as the voice of reason, and maybe 1 more
> that may arise before then, which would put us at 10.

I'll try to make it, but will try to stay out of the conversation and
let you all fight it out... :)

greg k-h

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]