События питания

Перед рассмотрением, как реализовать управление питанием в драйвере, необходимо понять то, что события питания и как они могут влиять устройство. В OS X события питания являются переходами к и от следующих состояний:

• Сон

• След

• Завершение работы или перезапуск

Все драйверы должны реагировать на события сна. OS X определяет различные типы сна, который может произойти по разным причинам. Например, когда пользователь выбирает Sleep из Меню Apple или закрывает крышку ноутбука, системный сон происходит; неактивный сон происходит, когда не было никакого действия устройства или системы во время интервала, пользователь выбирает в энергетических предпочтениях Средства сохранения. К Вашему драйверу, однако, все события сна кажутся идентичными. Важная вещь понять о событии сна состоит в том, что Ваше устройство может быть выключено, когда система спит, таким образом, Ваш драйвер должен быть подготовлен инициализировать устройство, когда это пробуждено.

Все драйверы должны реагировать на системное событие следа путем включения. След может произойти, когда пользователь нажимает клавишу на клавиатуре, нажимает кнопку питания, или когда компьютер получает пакет пробуждения администратора сети. На следе драйверы должны выполнить надлежащее восстановление состояния устройства.

Драйверы устройств не должны реагировать на завершение работы и события перезапуска. Драйвер может принять решение получить уведомление о нависшем завершении работы или перезапуске с помощью метода, описанного в Получении Завершения работы и Уведомлений Перезапуска, но важно понять, что никакой драйвер не может предотвратить событие завершения работы.

Другой тип события является запросом включения питания устройства, происходящим, когда некоторый объект в системе требует, чтобы неактивное или приводимый в действие - от устройства были в применимом состоянии. Уведомление запроса включения питания устройства использует большинство тех же механизмов в качестве уведомлений следа и сна. Несмотря на то, что большинство драйверов не должно знать о запросах включения питания устройства, некоторые драйверы, возможно, должны были бы реализовать их и даже выполнить такие запросы сами. Для получения дополнительной информации об этом, посмотрите Инициирование Изменения Состояния электропитания

Плоскость питания: иерархия зависимостей от питания

OS X отслеживает все управляемые устройства питания в древовидной структуре, названной плоскостью питания, получающей зависимости от питания среди устройств. Устройство, обычно листовой объект в плоскости питания, обычно получает питание от своих наследователей и может предоставить питание его дочерним элементам. Например, потому что плата PCI зависит для, включают шину PCI, к которой она присоединяется, плата PCI считается дочерним элементом питания шины PCI. Аналогично, шина PCI считается родителем питания устройств, присоединенных к нему.

Плоскость питания является одной из плоскостей Реестра I/O. Как описано в Реестре I/O Реестр I/O является базой динамических данных устройства, и драйвер возражает что экспрессы различные связи с потребителями провайдера среди них. Для просмотра плоскости питания в рабочей системе откройте приложение Проводника Реестра I/O (расположенный в /Developer/Applications/Utilities) и выберите IOPower из всплывающего меню. Можно также войти ioreg -p IOPower в командной строке для наблюдения представления текущей плоскости питания. Рисунок 9-1 показывает плоскость питания в Power Mac G5 рабочий OS X v10.5.

На рисунке 9-1 Вы видите корень плоскости питания, вызванный объект IOPMrootDomain, и объекты, представляющие устройства и драйверы. Можно проигнорировать многих IOPowerConnection объекты, представляющие подключения питания, потому что эти объекты представляют интерес только для внутренних объектов управления питанием и процессов.

Устройства и состояния электропитания

Фундаментальный объект в управлении питанием является устройством. С точки зрения управления питанием устройство является модулем аппаратных средств, потребляемую мощность которых можно измерить и управлять независимо от питания системы. Устройство может также иметь некоторое состояние, которое должно быть сохранено и восстановлено через изменения в питании. В условиях управления питанием «устройство» синонимично с объектом драйвера устройства, управляющим им.

Устройство должно иметь по крайней мере два состояния электропитания, связанные с ним — прочь и на. Устройство может также иметь промежуточные состояния, представляющие некоторый уровень питания между полномочиями и никакого питания. Эти состояния описаны в массиве состояния электропитания, который Вы создаете в своем драйвере. (Вы изучаете, как создать этот массив и предоставить информацию состояния электропитания на шаге 3 в Реализации Основного Управления питанием), функциональность управления питанием Набора I/O использует эти состояния, чтобы гарантировать, чтобы все драйверы в плоскости питания получили питание, которого они требуют. Каждое состояние электропитания определяется возможностями устройства когда в том состоянии:

• Устройство, которое находится на максимальной мощности использования и имеет полную функциональность.

• Устройство, которое не является от использования никаким питанием и не имеет никакой функциональности.

• Устройство может быть в сокращенном состоянии электропитания, в котором это все еще применимо, но на более низком уровне производительности или функциональности.

• Устройство может быть в промежуточном состоянии, в котором это не применимо, но сохраняет некоторую конфигурацию или состояние.

Функциональность управления питанием Набора I/O связывает несколько атрибутов с каждым состоянием электропитания устройства. Драйвер устройства должен установить эти атрибуты, чтобы гарантировать, что точная информация о возможностях и требованиях устройства доступна.

Атрибуты состояния электропитания предоставляют следующую информацию:

• Возможность устройства, в то время как в данном состоянии

• Требования питания устройства его родителя питания

• Характеристики электропитания устройство могут обеспечить для его дочерних элементов питания

• Версия состояния электропитания структурирует использование устройства, чтобы хранить его информацию состояния электропитания

Решение, как реализовать управление питанием в драйвере

Для участия в управлении питанием OS X потребность наиболее в драйверах ядра только гарантирует, чтобы их устройства соответственно реагировали на системный сон и события следа. Некоторые в драйверах ядра, возможно, должны были бы выполнить другие задачи, такие как реализация состояния ожидания или принятие мер при завершении работы системы, но эти драйверы не типичны. Отражая это различие, управление питанием OS X определяет два типа драйверов:

• Пассивный драйвер реализует основное управление питанием для ответа на события питания системы; это не инициирует связанных с питанием действий для своего устройства.

• Активный драйвер реализует основное управление питанием для ответа на события питания системы, но это также реализует усовершенствованное управление питанием для выполнения задач, таких как решение, когда устройство должно стать неактивным, изменив состояние электропитания устройства, или обработав до завершения работы системы.

Примером пассивного драйвера является настоящее драйвера AppleSmartBatteryManager в большинстве портативных компьютеров Macintosh. Драйвер AppleSmartBatteryManager предоставляет информацию состояния батареи пункту строки меню состояния батареи; когда система собирается спать, драйвер просто прекращает опрашивать батарею относительно информации о статусе. Хорошим примером активного драйвера является встроенный аудио драйвер микросхемы, потому что это выполняет свое собственное определение безделья, чтобы позволить аудио аппаратным средствам выключаться, когда это не используется. Если не будет никакого звука, выходящего из внутренних динамиков ноутбука или рабочего стола, то аудио аппаратные средства заскочат в режим низкой мощности, пока они не будут необходимы.

Как можно предположить, пассивный драйвер намного проще, чем активный драйвер к разработке и реализации. По существу пассивный драйвер реализует один виртуальный метод и делает между тремя и пятью вызовами для участия в управлении питанием. Ответственность активного драйвера, с другой стороны, начинается с тех из пассивного драйвера, но увеличение с каждой дополнительной задачей драйвер должно выполнить.

Некоторые семьи I/O Kit обеспечивают различные уровни встроенной поддержки управления питанием подклассам драйвера. Например, семья Network (IONetworkingFamily) выполняет некоторые задачи инициализации управления питанием для драйвера подкласса, оставляя драйвер для выполнения других специфичных для устройства задач управления питанием.

Прежде чем Вы начнете разрабатывать свою водительскую реализацию управления питанием, необходимо искать семью I/O Kit в Ссылке семьи Набора I/O, чтобы узнать, предоставляет ли семья поддержку управления питанием или требует, чтобы подклассы выполнили различные или дополнительные задачи. Знайте, однако, что любая семья I/O Kit, обеспечивающая функциональность управления питанием, может все еще потребовать, чтобы Вы реализовали некоторые части ее. Следующие семьи I/O Kit обеспечивают некоторый тип функциональности управления питанием:

• Аудио семья (описанный в Аудио)

• Семья FireWire (описанный в FireWire)

• Сетевая семья (описанный в Сети)

• Семья стандарта PC Card, включающая Явно выраженные устройства Карты (описанный в плате ПК)

• Семья PCI (описанный в PCI и AGP)

• Семья Model архитектуры SCSI (описанный в Модели архитектуры SCSI)

• Семья USB (описанный в USB)

Даже если Ваш драйвер является подклассом семьи I/O Kit, не предоставляющей поддержки управления питанием, или если Ваш драйвер является прямым подклассом IOService, это может все еще быть пассивный участник управления питанием, пока это только реагирует на инициируемые в систему события питания. Если с другой стороны Ваш драйвер должен определить, когда Ваше устройство неактивно, или выполните задачи перед завершением работы, необходимо реализовать усовершенствованное управление питанием.

Если Вы решаете разработать пассивный драйвер, необходимо считать Реализующее Основное Управление питанием, чтобы изучить, как участвовать в управлении питанием и реагировать на сон и события следа. Вы не должны читать никакие другие разделы в этой главе.

Если Ваш драйвер должен быть активным диспетчером электропитания, необходимо также считать Реализующее Основное Управление питанием Тогда, необходимо считать Реализацию Усовершенствованное Управление питанием для руководства при реализации определенных задач.

Реализация основного управления питанием

Как определено в Решении, Как Реализовать Управление питанием в Вашем Драйвере, пассивный драйвер только реагирует на сон и события следа; это не инициирует изменяющего состояние электропитания действия. Ваш пассивный драйвер должен сделать следующие вещи обработать сон и след:

• Будьте присоединены в плоскость питания, таким образом, Вы получаете уведомления изменения питания и гарантировать, что зависимости от питания Вашего устройства рассматривают, когда ей говорят спать и проснуться.

  Зависимости от питания влияют на упорядочивание уведомлений следа и сна. В частности Вашему драйверу говорят спать, прежде чем его родителю питания скажут спать, и Вашему драйверу говорят проснуться после того, как его родителю питания говорят проснуться.

• Сохраните аппаратное состояние к памяти перед системным сном и восстановите состояние во время следа.

  Вы ответственны за запись кода, чтобы сделать это.

• Предотвратите все аппаратные доступы, в то время как Ваше устройство подготавливается ко сну.

  Можно возвратить ошибку любому запросу I/O, который Вы получаете, в то время как Ваше устройство засыпает, или можно блокировать все входящие потоки с помощью механизма пропускания, такой как IOCommandGate, на Вашем цикле работы (см. Циклы Работы для узнавания больше о циклах работы).

Для участия в управлении питанием так, чтобы Вы получили уведомления о событиях питания гарантируйте, что Ваш драйвер правильно присоединяется в плоскость питания и изменения состояния электропитания дескриптора, Вы выполняете несколько вызовов и реализуете один виртуальный метод. IOService класс обеспечивает все методы, описанные в этом разделе. Выполните шаги, упомянутые ниже для реализации основного управления питанием в драйвере.

1. Инициализируйте использование управления питанием PMinit. () метод выделяет внутренние структуры данных управления питанием, позволяющие внутренним процессам отслеживать Ваш драйвер.

   В Вашем водительском start подпрограмма, после вызова к Вашему суперклассу start метод, выполните следующий вызов:

   PMinit();

2. Будьте присоединены в использование плоскости питания joinPMtree. (IOService*) метод присоединяет переданный - в объекте драйвера в плоскость питания как дочерний элемент ее провайдера.

   В Вашем водительском start подпрограмма, после вызова к PMinit и перед вызовом к registerPowerDriver (показанный на шаге 3), вызвать joinPMtree как показано ниже:

   provider->joinPMtree(this);

3. Предоставьте информацию о состояниях электропитания своего устройства и зарегистрируйте свой драйвер в управлении питанием.

   1. Во-первых, объявите, что массив двух структур содержит информацию о Вашем устройстве прочь и на состояниях. Первый элемент в массиве должен содержать структуру, описывающую от состояния, и второй элемент массива должен содержать структуру, описывающую на состоянии. Как правило, драйвер переключает свое устройство на от состояния в ответ на событие сна и к на состоянии в ответ на событие следа, как описано в Событиях Питания

      В Вашем водительском start подпрограмма, после вызова к joinPMtree, заполните два IOPMPowerState структуры, как показано ниже:

      // Declare an array of two IOPMPowerState structures (kMyNumberOfStates = 2).

      static IOPMPowerState myPowerStates[kMyNumberOfStates];

      // Zero-fill the structures.

      bzero (myPowerStates, sizeof(myPowerStates));

      // Fill in the information about your device's off state:

      myPowerStates[0].version = 1;

      myPowerStates[0].capabilityFlags = kIOPMPowerOff;

      myPowerStates[0].outputPowerCharacter = kIOPMPowerOff;

      myPowerStates[0].inputPowerRequirement = kIOPMPowerOff;

      // Fill in the information about your device's on state:

      myPowerStates[1].version = 1;

      myPowerStates[1].capabilityFlags = kIOPMPowerOn;

      myPowerStates[1].outputPowerCharacter = kIOPMPowerOn;

      myPowerStates[1].inputPowerRequirement = kIOPMPowerOn;

      В некоторых драйверах Вы могли бы видеть этот шаг, реализованный в коде, подобном следующему:

      static IOPMPowerState myPowerStates[kMyNumberOfStates] = {

      {1, kIOPMPowerOff, kIOPMPowerOff, kIOPMPowerOff, 0, 0, 0, 0, 0, 0, 0, 0},

      {1, kIOPMPowerOn, kIOPMPowerOn, kIOPMPowerOn, 0, 0, 0, 0, 0, 0, 0, 0}

      };

   2. Затем все еще в Вашем водительском start подпрограмма, зарегистрируйте свой драйвер в использовании управления питанием (IOService*,IOPMPowerState*,unsignedlong). registerPowerDriver метод говорит управлению питанием, что переданный - в объекте драйвера может перейти устройство между состояниями электропитания, описанными в переданном - в массиве. После того, как Вы заполняете IOPMPowerState структуры, вызвать registerPowerDriver с Вашим состоянием электропитания выстраивают как показано ниже:

      registerPowerDriver (this, myPowerStates, kMyNumberOfStates);

4. Обработайте использование изменений состояния электропитания setPowerState. В то время как Ваш драйвер работает, Вы выполняете задачи, обрабатывающие сон и будящие уведомления о событии в Вашей реализации виртуального IOService метод setPowerState. Пример того, как сделать это, показан ниже:

   IOReturn MyIOServiceDriver::setPowerState ( unsigned long whichState, IOService * whatDevice )

   // Note that it is safe to ignore the whatDevice parameter.

   {

   if ( 0 == whichState ) {

   // Going to sleep. Perform state-saving tasks here.

   } else {

   // Waking up. Perform device initialization here.

   }

   if ( done )

   return kIOPMAckImplied;

   else

   return (/* a number of microseconds that represents the maximum time required to prepare for the state change */);

   }

   Если Вы возвращаетесь kIOPMAckImplied, Вы сигнализируете завершение перехода к новому состоянию электропитания. Если Вы не возвращаетесь kIOPMAckImplied и вместо этого возвратите максимальную сумму времени, которое требуется для подготовки устройства к изменению состояния электропитания, несомненно, необходимо будет вызвать acknowledgeSetPowerState когда Вы закончили переход состояния электропитания. Если Вы не вызываете acknowledgeSetPowerState прежде чем отрезок времени, который Вы указываете, протек, система продолжает свое изменение состояния электропитания, как будто Вы возвратились kIOPMAckImplied во-первых.

5. Нерегистр от управления питанием, когда Ваш драйвер разгружает использование PMstop. PMstop метод обрабатывает всю необходимую очистку, включая демонтаж Вашего драйвера от плоскости питания. Поскольку PMstop может поместить Ваши аппаратные средства в от состояния, несомненно, сможет завершить все аппаратные доступы перед вызовом его.

   В Вашем водительском stop подпрограмма после окончания всех вызовов, которые могли бы получить доступ аппаратным средствам, вызывает PMstop как показано ниже:

   PMstop();

Реализация усовершенствованного управления питанием

Этот раздел копается глубже в функциональности управления питанием Набора I/O. Подавляющее большинство разработчиков драйвера не должно понимать информацию в этом разделе, потому что основное управление питанием (как описано в Решении, Как Реализовать Управление питанием в Вашем Драйвере) достаточно для большинства устройств. Если Ваше устройство может быть пассивно питанием, которым управляют, считайте Реализующее Основное Управление питанием вместо этого.

Необходимо считать этот раздел, если драйвер должен выполнить усовершенствованные задачи управления питанием, такие как определение безделья устройства, принятие мер, когда система собирается завершить работу или решает изменить состояние электропитания устройства. Конечно, активные драйверы совместно используют некоторые задачи с пассивными драйверами, а именно, инициализация и разрушение управления питанием. Перед чтением о задачах в этом разделе, поэтому, необходимо поглядеть на шаги в Реализации Основного Управления питанием, чтобы изучить, как инициализировать и завершить управление питанием в драйвере. Даже если Ваш драйвер должен выполнить усовершенствованные задачи управления питанием, он все еще должен вызвать PMinit, joinPMtree, registerPowerDriver, и PMstop и реализация setPowerState, как показано в Реализации Основного Управления питанием

Этот раздел покрывает несколько задач, которые активный драйвер, возможно, должен был бы выполнить. Несмотря на то, что немного активных драйверов выполнят все задачи, большинство выполнит по крайней мере один. Каждая задача сопровождается фрагментом кода, чтобы помочь Вам реализовать его в своем драйвере.

enum {

    kMyOffPowerState  = 0,

    kMyIdlePowerState   = 1,

    kMyOnPowerState = 2

};

static IOPMPowerState myPowerStates[3] = {

    {1, kMyOffPowerState, kMyOffPowerState, kMyOffPowerState, 0, 0, 0, 0, 0, 0, 0, 0},

    {1,kIOPMPowerOn, kIOPMPowerOn, kIOPMPowerOn, 0, 0, 0, 0, 0, 0, 0, 0},

    {1,kIOPMPowerOn, kIOPMPowerOn, kIOPMPowerOn, 0, 0, 0, 0, 0, 0, 0, 0}

};

bool PMExampleDriver::start(IOService * provider)

{

   /*

    * Create a work loop and set up synchronization

    * using a command gate.

    */

    fWorkloop = IOWorkLoop::workLoop();

    fGate = IOCommandGate::commandGate(this);

    if (fGate && fWorkloop) {

        fWorkloop->addEventSource(fGate);

    }

     * Initialize power management, join the power plane,

     * and register with power management.

     */

    PMinit();

    provider->joinPMtree(this);

    registerPowerDriver(this, myPowerStates, 3);

}

enum {

    kMyOffState = 0,

    kMyOnState = 1

};

/*

 * Make sure the hardware is in the ON state

 * before accessing it. If it's powered off, call changePowerStateToPriv

 * to put the device in the ON state.

 */

if (getPowerState() == kMyOnState)

{

    /* Device is ON. OK to access hardware. */

} else {

    changePowerStateToPriv( kMyOnState );

    /*

     * Note: If your device has been powered off for a system sleep, you cannot

     * try to adjust your power state upwards. You are locked in your OFF or

     * low-power state until system power is restored on wake.

     */

    /*

     * Although changePowerStateToPriv returns immediately,

     * it is _NOT_ safe to touch the hardware yet. You must wait until you

     * receive your setPowerState() call before you can safely modify

     * the hardware.

     */

}

void MyExampleDriver::systemWillShutdown( IOOptionBits specifier )

{

    if ( kIOMessageSystemWillPowerOff == specifier ) {

        // System is shutting down; perform appropriate processing.

    } else if ( kIOMessageSystemWillRestart == specifier ) {

        // System is restarting; perform appropriate processing.

    }

    /*

     * You must call your superclass's implementation of systemWillShutdown as

     * soon as you're finished processing your shutdown or restart

     * because the shutdown will not proceed until you do.

     */

    super::systemWillShutdown( specifier );

}

// timeToStayOn is a length of time in milliseconds.

clampPowerOn ( timeToStayOn );