This past year I was tasked with enabling runtime power management for most of the drivers for the Moorestown architecture for Meego.  I was also the Meego kernel maintainer for the Moorestown architecture for a few months, and got to review many drivers during that time.  Below are the top 10 issues I found driver writers making (over and over and over again) while attempting to implement runtime power management.

1. Not understanding the general concept of runtime power management.  Runtime power management is initiated by the kernel and transparent to user space.  YOU determine when you are not busy and sleep then, you don’t wait for someone to tell you to.
2. Not understanding what your subsystem does for runtime PM.  I saw many driver writers duplicating work that is done in their subsystem core.
3. Make sure you understand all the possible entry points to your driver.  Sysfs is an entry point.
4. Make sure you understand when you are actually touching hardware.
5. Make sure you understand the context in which you are being called during these entry points (i.e. are you called in interrupt context?).
6. For drivers who may have entry points called in interrupt context, you must ensure that the hardware is available without sleeping, otherwise use a work queue.
7. Ref counting during the irq handler does cost cycles.  This may be ok, depending on your device.  If you have to do ref counting during the irq handler, use a threaded irq handler if possible (see #6).
8. Have the correct granularity for your ref counting.  Depending on your hardware, there is likely some kind of performance penalty for entering a suspended state.  You many even lose device state.  Restoring can take time, so you want to make sure you are appropriately idle before allowing a suspend.
9. Unbalanced ref counting occurs when you do not pay attention to error paths.
10. Unbalanced ref counting can occur when you try to do something tricky with the ref counting to work around overly complex code paths (like setting your pm usage count directly to zero).  This will cost you hours and hours of debug time.  If it isn’t obvious where to increment/decrement your counter, you are doing something wrong.

I couldn’t have been happier with how the Linux Plumbers Conference went last week. I went back and looked at the original proposal that we had Arjan, Greg, and Randy present to the Linux Foundation, and we seem to have hit all our original goals. From conception we wanted this to be a “working” conference – and from the conversations in the hallways that I overheard, to the discussions in the microconfs that went on, I could see that people were indeed getting together, discussing issues and solving problems. Conferences require a lot of time, effort, and money to do right, and it’s gratifying to feel that something useful will come out of this.

I think that now I can go back to blogging about duck poo and vegetables.

In addition to the topics to be discussed in the microconfs and the general talks (see http://linuxplumbersconf.org/program/schedule/), we will have “unconference” style talks. We have several smaller rooms available for people to get together and work out specifics, talk about something they didn’t get on the schedule, or have a group hug. These rooms can be reserved at the start of the conference.

August 18th the registration fee for Plumbers will increase to $300. If you haven’t already registered, what are you waiting for?