 Hello everyone, I'm Wenpeng Wu, a software development engineer in Intel. Currently I'm working for the ZIFER project. Today I want to share my understanding of the power management framework of ZIFER. First, let's look at the goals of the framework. The first one is consume as little power as possible in each system state and don't waste energy when system in idle. And the second one is convenient to use and deploy for users. To achieve the goals there are two kind of power management. The first one is system power management. And another one is device runtime power management. First, let's look at the component of the system power management. There are five components for the system power management. The first one is a PM state and the next one is a PM policy. And the next is a device PM and a platform PM. And the last one is a PM call. And every component in the framework is shown in the right picture. And I will introduce every component in detail in the next slide. So let's look at the first component, PM state. First, it unifies the definition about the power management state. So that we can... The definition is based on the ACPS spec and the Linux power state. And every platform has to map their own power state to 3451. So that the different PM call can unify the PM state. It's very convenient for the PM call to do the decision and makes the operation accordingly. So this is a PM state. And the next one is a PM policy. PM policy is to make the decision about the next power state or the system. System idle time is one with a factor to impact the decisions. And the constraint to estimate side is another factor to impact the decision. But why we need the constraint? Let's consider the case. One device may configure a transfer. And while the transfer is ongoing, a system wants to power off the device to enter some system power state. So if no constraint, the system will power off the device. And the ongoing transfer will last. So the constraint is also very important for the PM policy to make the decision. So let's look at the API defined for the PM policy. And it should cover the requirements we talked just now. Every platform should implement its own policy following this API. So let's look at the API. The first I want to talk about is the next state API. It will get the next system power state based on the current system status. And the next one is constraint. So I just talked about device may set constraint with the API to set constraint for the supported power state so that others can impact the PM policy when making decisions. And the release constraint is release the constraint set by the set constraint API for the supported power state. It should be pilot with the set constraint. This is PM policy we defined here. And the next one is device PM. It's mainly about the maintaining PM state per device instance and doing clock or power operations per the decided system power state with defined device PM APIs. And the power on off sequence is very important. Because there is some dependency between devices. So the implementation is highly depends on the device dependency information from DTS. Another key point here is the interrupt is enabled when submitting DTS. During which wake up interrupt from DTS may happen. So DTS should use the API or PM Collier to update if there is pending make up interrupt to avoid missing make up interrupt. This is a device PM. Okay, let's look at the next one is platform PM and PM call. So platform PM layer is straightforward. But the implementation highly depends on every platform. For example, there may be state and think between cash and RAM. And RAM retention and WFI or WFE instruction. And as a PM call will use the standard API or every component to do the system side power management. Okay, let's look at API defined for the platform PM. It's very simple. There will be three APIs for the platform PM. The first one is initial and the second one is resume and the last one is suspend. So under the decided PM state will be passed to the suspended resume so that the platform layer can do their operations according to the PM state. So this is the platform PM and PM call. Okay, after that, this is all of the component or the system side power management. So after the system power management, there will be device runtime power management. The definition is that devices will dynamically go to low power mode when they are not in use even CPU is running. So this is device itself to make the decision to do the device runtime power management. But how to define device not in use? Let's look at two examples. First for the I2C, we can put suspended resume callbacks or device around data transfer function so that when we need some I2C transfer resume device first and then up data transfer suspended device. It will seal power when device not in use. But for night device, we can put suspended resume callbacks around data transfer because when in high throughput, it's hard to suspend the resume repeatedly without performance loss. So put them around night device, put them around device open and close. It's a reasonable choice. So it's a device that decides it's not in use instead of device runtime PM framework. So let's look at APIs defined for the device runtime PM. Let's look at the operations every device should implement for the device runtime power management. There are four APIs. Let's look at the posterior resume and pre-suspend callbacks. They are used to do stuff without ARQ locked. For example, state sync between driver and firmware. Device driver should take care of all the possible errors during this ARQ unlocked period. And the results will be indicated by the return value. And the suspended resume callbacks will do the real power or clock involved stuff with ARQ locked. The specific state device will go completely depends on every device. Resume suspend is a generic definition here. So this is an API for the device runtime operations. And another one is KAPS for the for the system and the resume. It is designed by based on the user account and some of the state 888 where the device is So let's look at the claim. It's about claiming a device to mark the device as being used to make sure any device operation protected by the successful claim is safe. But it can't be used in either. Another one is release. It will release a given device. It first will decrease the user account of the given device and the suspended device if all of the conditions satisfied. This function must be called after any claim happens. It can't be used in ISR also. This is a KAPS for the device runtime power management. The implementation is on the GitHub. Any suggestions or comments for that. This is device runtime power management. This is all of the topic about about the power management or safer. Thank you. Any questions?