How's it going?
So I'm going to talk about modern standby,
my work I've been doing with on modern standby on 3bSC.
So actually I took a 15 minute talk,
because I didn't think I'd have too much to talk about,
but I mean it kind of ballooned.
So I might gloss over a few things,
and if I speak a bit too quickly,
as I tend to do, please yell,
or maybe don't yell just to just make me know.
Anyway, so a bit about me,
my two interests, I guess, are OS's and graphics programming.
I'm sponsored by the 3bSC foundation
to work on a 0x and month standby,
and I work at a company called Benuable, which shows
as energy storage stuff in Belgium.
And yeah, I spend most of my time in a train.
Actually, I think my second true passion in life,
apart from my dog, is trains.
I'm really a huge nerd. Anyway,
so a bit of background about what the issue is.
So in the past, computers had something called S3,
and in modern laptops,
just to ease bioscivalment,
this kind of got removed and favor of something called S0x.
And 3bSC doesn't support S0x.
Therefore, 3bSC can't sleep on long laptops,
and therefore, well,
3bSC can't sleep on long laptops.
So a bit of previous work, Benuable dalsky from Intel,
in 2018, made these two revisions.
Things have kind of changed since then,
so there was quite a bit of stuff to do to pick up on.
And I'm going to talk about that.
So, what is actually S3 exactly?
So, ACPI defines a bunch of global states.
You've got S0 for a system that's fully awake and running.
S5 when it's off.
And S3 was suspending for RAM.
So RAM stays on all devices turn off,
and the CPU is turned off.
And then when you restart,
then your RAM's already there, you don't have to do that much.
And so, it's a pretty heavy-handed approach.
You're just asking firmware to go to sleep,
and then firmware just doesn't.
And you don't really have too much control over that.
And one of the implications of that is that
entering an existing S3 is kind of slow.
And ideally, you want it to be as quick as possible,
so just be able to like,
you know, close your laptop, it goes to sleep,
and it'd be ready to go.
So, as opposed to S3, S0iX,
your system is wasting in S0.
And your firmware decides when to enter S0iX,
one of the S0iX states,
and turn off the CPU,
just depending on some power constraints.
So, yeah.
And so, the end goal is S0i3,
that's the thing that your CPU is completely off,
and that's the thing that saves the most power.
So, just a bit of terminology,
when I speak of a shallow or power state,
that means that it's closer to being on,
so that's a smaller number,
so S0iX is on,
that's a smaller number,
it's closer to being on.
Deeper is the opposite,
and, yeah,
LPI just stands for low power idle.
So, yes.
A bit of a crash course on ACPI,
for a bit of context.
What ACPI is,
is basically your firmware exposes
a bunch of information about the hardware,
and something called AML,
which is kind of like a bytecode.
And it also contains a few methods
for your OS to tell devices what to do.
And so, here's an example of some decompiled AML,
this is ASL, for the lid device.
So, here we're defining,
the firmware is defining, oh, here's this lid.
This is its ID,
and this is what your kernel uses to know
that this is a lid device.
And then here's an example of a method,
which will return the state of the lid.
And so, in C, how would you use that?
Well, you get the integer at the lid object,
and here it's saying,
if there was a failure,
then we default to saying that it is lid, it's open.
And if there was no failure,
then if the lid status is different to zero,
then it means,
okay, if it's not zero, then this is one,
and if it is zero, then it's,
it's anyway, whatever.
Okay, SPMC,
system power management control.
So, this is the thing that defines,
what I've called DSMs.
So, DSMs are like these kind of multiplex functions,
where it's like a specific ACPI function,
where your vendor can define whatever they want on it.
So, generally, the first argument is a UID
that your vendor exposes,
and from that, you know,
that, oh, it's this UID,
so I can use these specific vendor specific functions.
And so, there are three,
I guess, five,
important ones for the SPMC.
The first one is get device constraints.
So, here you are asking the SPMC,
oh, give me a list of the states I need to put my devices
in to be able to enter a low power idle state.
And then you've got display off,
and entry, and exits, and display on,
which are just telling firmware,
oh, we're going into a sleep state,
or we want to go into a sleep state,
or we're exiting it.
And there's a few vendor specific complications,
which I kind of gloss over.
Okay, next thing I want to talk about,
are these states,
these are those device states
that you need to put your stuff in.
So, D0 is on D3 is off.
I'm not going to go into the difference between
D3 code and D3 code,
but there's some complications with that,
but that's not too too important.
And your which D states,
you can get that by through power resources.
So, here's an example of the NVMe device,
where you have these power resource objects are defined,
and a power resource object,
it's just a list of power resources,
which this specific state depends on.
So, you start,
if for example, you wanted to,
if for example, you wanted to know it,
okay,
say P0 and V is on as a power state,
then you know that you're in PR0,
because this is the shallower state that depends on it.
If this was off,
then you'd be in D3 code,
because you're at the lowest power state.
It's roughly explained here,
but again, I'm not going to go too too much into this.
In the interest of time.
So, suspended idle.
What is suspended idle exactly?
So, this is kind of distinct to,
as a direct states.
Suspended idle is basically just saying your CPU,
stop working, just idle.
And when your CPU is idle,
as when you're firm,
I can decide to go into a deeper sleep state.
And you do this with the X86 M-Wate instruction,
which is usually using conjunction with monitor,
but you can give it a hint to say,
instead of breaking out of the state
when a specific part of a piece of RAM,
or a piece of memory is modified,
we break out when we get an interrupt.
And then you can also define an EAX,
the C-State,
that we want the CPU to idle too.
So, yeah,
since we wake from idle on interrupts,
we kind of wanted to disable all the interrupts
that we have on our system,
except for the ACPI interrupts,
which is interrupt 9 usually.
And that interrupts is basically useful wake event.
So, maybe I press my power button,
then I want my computer to wake,
maybe I open the lid,
that would be that kind of stuff.
The only issue is that the firmware talks a lot,
and we don't want to stop break out of idle,
every single time the firmware has something to say.
So, normally you do this with,
you can choose up a device interrupts
or sends these events with DSW.
But the issue is that some pretty important weight devices
are kind of hidden away behind the same GP as,
or the same event number as other very talk to things.
So, for example,
latency on the embedded controller device,
you have your lid notifications and your battery notifications.
The battery in normal running,
at least on my laptop sends a GP every second.
So, this would interrupt the CPU every second.
And you can't mask that out,
because if you mask that out,
then you wouldn't be able to detect
when the lid opens to break out of idle,
which is obviously a bit of a problem.
So, the solution, I don't know,
it's not super clear,
signing the SPMC to enter an exit,
to sleep,
solves the issue.
So, my battery instead of reporting its states,
every second it reports every minute.
But, yeah, the best effort solution,
and this is what Linux does too,
is to idle loop.
So, if we break out of idle,
we check what was the last interrupt,
was the reason we broke out of idle.
The last time,
and if it wasn't what we considered
wake device, then we go immediately back to sleep.
So, not spend too much time there.
Yeah.
And on AMD,
the SMU system measurement unit
needs to be hinted that we're entering an existing sleep,
and that might also tell the CPU
to, or I guess, a firmware to show up,
but that's not working fully yet.
So, I found this kind of funny,
and all these are trying to get it to stay in idle problems.
Yes, they are as at a bar with Alex and Alex to Alex's.
And I saw this thing, this sticker,
say idle fucking sucks,
for those funny.
Anyway, debugging.
On Intel, you have something called the low power idle state table,
which basically has these residency counters,
and residency counters are just,
yeah, registers that count up for how long it's been in a specific state.
So, you know if it's actually gone into that state.
Unfortunately, oh yeah,
and it's for payments as LPI and ACPI,
but unfortunately, it seems like
most platforms don't actually expose residency counters through that,
so it's kind of useless.
But on AMD, you have something called the SMU,
which is a small part of the chip,
and it runs this power management firmware,
and you can send commands to it to ask it,
oh, have I gone into SLRI-3 or not?
So, that's that.
So, yeah, for now, SLRI-3,
we can't really answer it.
There's a bit of a prerequisite for this,
which is writing a USB-4 connection measure,
which I'm looking into,
but we'll see when that gets done.
Either way, there's still quite a bit more work needed.
So, demo.
This might break this might not break,
so I'm just going to go over these few other slides.
So, future actually getting SLRI-3.
I want to be able to give the users
to find more complex vehicles.
So, for example,
always try to idle the CPU and the lid is closed.
Hibernate, I'm not working on this,
but this is just suspending,
putting the memory to disk,
so you're saving even more power,
and I don't know if the termination I'm not going to go into this.
So, there's a public issue tracker for all these,
like, laptop-related projects, you can find this,
and these tests, if it works.
There's my contacts, and I'm going to try to demo.
So, I should have, if I go back here and here.
Let's see.
I can't actually see what I'm doing on this.
Let's see.
It's a CTL.
Okay, so here I've set the power button states
to go into S2ID when I press it,
and hopefully if I press this,
it will go to sleep.
Now, you're not going to see anything change,
but trust me it's going to sleep.
And now I can like press the keyboard to break out of sleep,
and hopefully if no actually tested this with HDMI,
it might just seem kind of work.
I don't know.
I went better than any expected.
Anyway, that's that.
Do you have time for questions?
No, not too much.
Not too much?
Okay.
I encourage you to grab this guy.
I'm asking questions outside of the demo.
If you have questions.
Okay.
Thank you very much.
Yeah.
Thanks for listening.
Great.