Как ядро Linux обрабатывает совместно использованный IRQs?

Это охвачено в главе 10 Драйверов устройств Linux, 3-го выпуска, Corbet и др. Это доступно бесплатно онлайн, или можно бросить некоторого O'Reilly шекелей путь к мертвому дереву или формам электронной книги. Часть, относящаяся к Вашему вопросу, начинается на странице 278 в первой ссылке.

Если это имеет значение вот моя попытка перефразировать те три страницы плюс другие биты, которые я Погуглил:

• При регистрации общего обработчика IRQ ядро проверяет что также:

  a. никакой другой обработчик не существует для того прерывания, или

  b. все ранее зарегистрированные также требуемое совместное использование прерывания

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

• Когда PCI ¹ устройство повышает линию IRQ, обработчика прерываний ядра низкого уровня называют, и это в свою очередь называет всех зарегистрированных обработчиков прерываний, пасуя назад каждого dev_id Вы раньше регистрировали обработчик через request_irq().

  dev_id оцените должно быть уникальным для машины. Распространенный способ сделать, который должен передать указатель на для каждого устройства struct Ваше использование драйвера для управления тем устройством. Так как этот указатель должен быть в пространстве памяти Вашего драйвера для него, чтобы быть полезным для драйвера, это в силу самого факта уникально для того драйвера. ²

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

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

  Примером, который и др. дают Corbet, является пример параллельного порта ПК. Когда это утверждает линию прерывания, это также устанавливает главный бит в своем первом регистре устройства. (Таким образом, inb(0x378) & 0x80 == true, принятие стандартной нумерации порта I/O.), Когда Ваш обработчик обнаруживает это, он, как предполагается, делает свою работу, затем очищает IRQ путем записи значения, считанного из порта I/O назад к порту с главным очищенным битом.

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

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

  Предположите, что два устройства утверждают ту же линию прерывания одновременно. (Или по крайней мере, так закройтесь вовремя, что ядро не имеет времени для вызова обработчика прерываний, чтобы очистить строку и таким образом рассматривать второе утверждение как отдельное.) Ядро должно назвать все обработчики для той линии прерывания, чтобы дать каждому шанс запросить его связанные аппаратные средства, чтобы видеть, необходимо уделять внимание ли этому. Для двух различных драйверов довольно возможно успешно обработать прерывание в том же, проходят через список обработчика для данного прерывания.

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

Сноски:

1. Я указал PCI выше, потому что все вышеупомянутое принимает инициированные уровнем прерывания, как используется в исходной спецификации PCI. ISA использовал инициированные фронтом сигнала прерывания, которые сделали совместное использование хитрого в лучшем случае и возможного даже затем только при поддержке аппаратными средствами. PCIe использует сообщенные сообщению прерывания; сообщение прерывания содержит уникальное значение, которое ядро может использовать для предотвращения циклической игры предположения, требуемой с совместным использованием прерывания PCI. PCIe может избавить от самой необходимости совместное использование прерывания. (Я не знаю, делает ли это на самом деле, просто что это имеет потенциал к.)

2. Драйверы ядра Linux вся доля то же пространство памяти, но несвязанный драйвер, как предполагается, не слоняется без дела в чьем-либо пространстве памяти. Если Вы не раздаете тот указатель, можно быть вполне уверены, другой драйвер не собирается придумывать то же самое значение случайно самостоятельно.

Когда драйвер запрашивает общий IRQ, он передает указатель на ядро к ссылке на устройство определенная структура в пространстве памяти драйвера.

Согласно LDD3:

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

После проверки обработчиков IRQ нескольких драйверов кажется, что они зондируют сами аппаратные средства, чтобы определить, должно ли это обработать прерывание или возврат IRQ_NONE.

Примеры

  status = inw(uhci->io_addr + USBSTS);
  if (!(status & ~USBSTS_HCH))  /* shared interrupt, not mine */
    return IRQ_NONE;

В коде выше, драйвер читает USBSTS регистр, чтобы определить, существует ли прерывание к сервису.

  intmask = sdhci_readl(host, SDHCI_INT_STATUS);

  if (!intmask || intmask == 0xffffffff) {
    result = IRQ_NONE;
    goto out;
  }

Так же, как в предыдущем примере, драйвер проверяет регистр состояния, SDHCI_INT_STATUS определить, должно ли это обслужить прерывание.

  struct ath5k_softc *sc = dev_id;
  struct ath5k_hw *ah = sc->ah;
  enum ath5k_int status;
  unsigned int counter = 1000;

  if (unlikely(test_bit(ATH_STAT_INVALID, sc->status) ||
        !ath5k_hw_is_intr_pending(ah)))
    return IRQ_NONE;

Просто еще один пример.

Пожалуйста, посетите эту ссылку:

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