Linux Power Management Support, Бібліотека Лінукс Портала
Переклад Linux Power Management Support
ключові слова для пошуку: драйвер керування живленням linux енергоспоживання енергозбереження
1. Вступ.Спливла тут із глибин часів тема про керування харчуванням у лінухах, поліз у kernel documentation пошукати чогось на цю тему. Знайшов, але, як виявилось, не зовсім те. Але я вирішив, що переклад все одно буде корисним, як мінімум мені як практика англійської :). Так як з англійською у мене не дуже, то обґрунтовані поправки в перекладі приймаються та вносяться.
2. Переклад Documentation/pm.txt з дистрибутива ядра 2.4.23.
Підтримка керування живленням в Linux
Цей документ поверхово описує використання керування живленням у вашій Linux-системі та впровадження цієї підтримки у драйвери.
APM чи ACPI? ------------- Якщо у вас відносно нові x86 ноутбук, настільна система або сервер, то швидше за все вони підтримують Розширене Управління Живленням (Advanced Power Management, APM) або Розширені Конфігурацію та Інтерфейс Харчування (Advanced Configuration and Power Interface, ACPI). З цих двох технологій ACPI свіжіша і переносить систему керування живленням в руки операційної системи, що дозволяє керувати нею ефективніше, ніж це можливо через BIOS за допомогою APM.
Найкращим способом визначення, яка з двох технологій підтримується вашою системою, є складання ядра з підтримкою обох (з версії 2.3.х підтримка ACPI включена за замовчуванням). Якщо буде знайдено працюючу апаратну підтримку ACPI, то ACPI-драйвер "перекриє" і відключить APM, інакше буде використовуватися APM.
На жаль, у вас немає можливості використовувати ACPI та APM одночасно. Деякі товариші, які мають неповну або місцяминекоректну апаратну підтримку ACPI або APM, хотіли б використовувати обидві технології щоб увімкнути весь набір можливостей, але не існує можливості досягти цього. Машиною можна керувати тільки через один інтерфейс (їх можна перемикати, але не використовувати одночасно).
User-space Daemons ------------------ Як APM, так і ACPI потребують підтримки програм-демонів, що працюють у просторі користувача та називаються apmd і acpid відповідно. Обох можна знайти у дистрибутиві Linux або отримати через Internet (див. посилання нижче) і вам потрібно зробити так, щоб вони піднімалися в процесі завантаження системи. Якщо апаратної підтримки APM або ACPI у вашій системі немає, демон просто завершить свою роботу.
Інтерфейс драйвера ------------------ Якщо ви пишете новий драйвер для пристрою або підтримуєте наявний, то він повинен включати підтримку керування живленням. Без цього такий драйвер навіть у системах з її підтримкою може унеможливити безпечне засипання.
У двох словах: 1) зареєструйте кожну частину пристрою через pm_register 2) викличте pm_access перед зверненням до обладнання (це гарантує, що пристрій увімкнено та готово) 3) ваша функція pm_callback буде викликана перед переходом у стан "сну" (ACPI D1-D3) або після повернення з нього (ACPI D0) 4) викличте pm_dev_idle коли пристрій не використовується якийсь час (необов'язково, але допоможе виявленню простою пристрою ) 5) при вивантаженні модуля (драйвера) не забудьте розреєструвати його за допомогою pm_unregister
Подробиці ----------- Нижче наводиться невеликий список ЧаВо, який буде згодом замінений повноцінним посібником з написання драйверів.
Питання: Коли пристрої"засинають"? Про: Пристрої можуть бути "присипані" за прямим запитом користувача (закриття кришки ноутбука), через системну політику керування живленням (після 30 хвилин неактивності на консолі) або через політику керування живленням пристрою (вимикання живлення пристрою після 5 хвилин простою).
Питання: Чи повинен завжди драйвер виконувати запит на вимкнення живлення? О: Ні, драйвер може повернути -EBUSY у відповідь на запит і це зупинить відключення живлення системи. У цьому випадку всі відключені пристрої "будуть" і система продовжує працювати. Спробу можна повторити пізніше.
Питання: Чи може блокувати запити відключення/вмикання драйвера? О: Так, драйвер може затримувати видачу відповіді на такий запит до готовності пристрою обробити цей запит. Однак краще реагувати на запити настільки швидко, наскільки це можливо.
П: У якому контексті виникають запити на вимкнення/вмикання? О: Запити на вимкнення/живлення породжуються в контексті потоку ядра. Тому під час "сну" системи безпечно блокувати і виділяти пам'ять, ініціювати запити і робити все, що завгодно, що можна робити по відношенню до ядра.
Чи буде драйвер обробляти запити "уві сні"? О: Можливо. Обробка запитів після "засипання" цілком залежить від драйвера - він може виконувати їх, так і відкидати або просто ігнорувати. Важливо тут те, що драйвер не отримає доступу до пристрою через те, що шина може бути неактивна. (*) Якщо драйвер утворює чергу із запитів до пристрою в той час, поки воно "спить", то вам слід пам'ятати про те, що стан цього пристрою та пов'язаних з ним об'єктів (напр. локальної мережі) до моменту пробудження може змінитись. Видається розумним ігнорувати всі запити, тільки якщо цене драйвер пристрою для зберігання інформації.
П: Чи можу я керувати шинно-специфічними регістрами управління живленням? Про: Ні. Цим займається драйвер відповідної шини. Цей драйвер або підсистема керування живленням в цілому самостійно задіють доступну функціональність управління живленням, якщо вона є.
П: Так що мені насправді необхідно для включення підтримки вимикання/вмикання живлення? В: Вам потрібно зберегти будь-які дані про стан пристрою (контекст), які можуть бути втрачені при вимкненні пристрою. При використанні ACPI доступні три рівні відключення: D1, D2 і D3 (ці рівні передаються як аргумент "data" callback'у пристрою). На рівні D3 пристрій відключається повністю і втрачає весь контекст, D1 і D2 просто різною мірою знижують енергоспоживання і в цьому випадку втрачається лише частина контексту. Щоб просто й повністю убезпечити себе, достатньо просто зберігати весь контекст і потім його повністю відновлювати.
Питання: Де я можу зберігати контекст пристрою? О: Швидше за все в пам'яті. Виділіть буфер за допомогою kmalloc або збережіть контекст у дескрипторі пристрою. Це гарантує, що вміст пам'яті буде відновлено та доступно перед увімкненням, навіть якщо система скидала свій стан диск перед вимкненням.
П: Що мені потрібно для використання ACPI для APM (і т.д.)? В: Драйвери не повинні турбуватися про те, яка технологія керування живленням використовується в системі. Для них головне не забувати опрацьовувати запити на відключення/включення.
Питання: Як бути із залежностями між пристроями? О: Коли драйвер реєструє пристрій, підсистема керування живленням використовує надану інформацію для побудови дерева залежностей міжпристроями (на зразок USB-пристрій А підключено до USB-контролера Б, підключеного до PCI-шини В). Коли підсистема хоче "приспати" пристрій, вона спочатку надсилає відповідний запит драйверу, тому драйверу контролера і так далі до системної шини. Під час пробудження пристрою все відбувається у зворотному порядку.
Питання: Де я можу отримати додаткову інформацію про включення керування живленням для мого особливого драйвера або пристрою? В: Спробуйте звернутися до листа розсилки розробників ACPI [email protected]
Системний інтерфейс ------------------- Якщо ви розробляєте нову систему керування живленням для Linux (щось на кшталт APM або ACPI), то вам необхідно взаємодіяти з драйверами через існуючий інтерфейс керування живленням.
3. ПриміткиУ тому ж файлі у дистрибутиві ядра 2.6.0 змін не виявлено.