«неожиданная ловушка IRQ в векторе XX» на Beaglebone Black (Linux BBBW 4.14.71-ti-r80) - PullRequest
Новая
       19

«неожиданная ловушка IRQ в векторе XX» на Beaglebone Black (Linux BBBW 4.14.71-ti-r80)

0 голосов
/ 11 апреля 2019

У меня проблема с обработкой прерываний на beaglebone black.Я написал свою собственную комбинацию модуля ядра и драйвера пользовательского пространства для доступа к gpios (см. Также https://github.com/Terstegge/gpio-bbb). В старых ядрах все работало нормально. Использование самого последнего образа Debian (ядро 4.14.71)-ti-r80), я получаю ошибки в журнале ядра: 

[  461.028013] gpio_bbb: Device /dev/gpio_bbb registered
[  507.507335] gpio_bbb: Requesting GPIO #30
[  507.507370] Mode: f
[  507.507383] gpio_bbb: Requesting GPIO #49
[  507.507395] Mode: 37
[  507.507405] gpio_bbb: Requesting GPIO #15
[  507.507414] Mode: 37
[  507.507656] gpio_bbb: Using IRQ #77 for GPIO #49
[  507.507821] gpio_bbb: Using IRQ #78 for GPIO #15
[  571.511409] irq 77, desc: db1ad800, depth: 0, count: 0, unhandled: 0
[  571.511429] ->handle_irq():  c01ab7b0, 
[  571.511458] handle_bad_irq+0x0/0x2c0
[  571.511463] ->irq_data.chip(): dc122910, 
[  571.511476] 0xdc122910
[  571.511481] ->action(): dc454600
[  571.511487] ->action->handler(): bf4c904c, 
[  571.511514] gpio_irq_handler+0x0/0x34 [gpio_bbb]
[  571.511524]    IRQ_NOPROBE set
[  571.511532] unexpected IRQ trap at vector 4d

Я делаю следующее: В коде модуля я вызываю gpio_to_irq(), чтобы получить номер irq, а затем вызываю request_irq()Кажется, что оба вызова работают, потому что они не сообщают код ошибки (см. Файл журнала выше): 

  /* request the irq and install handler */
  if (!irq_enabled[gpio_num]) {
    irq = gpio_to_irq(gpio_num);
    /* request irq and install handler */
    ret = request_irq (irq, gpio_irq_handler, IRQF_SHARED, "gpio_bbb", &gpio_data);
    if (ret != 0) {
      printk(KERN_ERR MOD_STR"Failed to request IRQ %i (error %i)\n", irq, ret);
      return ret;
    }
    printk(KERN_INFO MOD_STR"Using IRQ #%i for GPIO #%i\n", irq, gpio_num);
    irq_enabled[gpio_num] = irq;
  }

При запуске тестовой программы я вижу, что мой модуль (gpio_bbb) зарегистрирован для прерыванийв / proc / interrupts: 

           CPU0       
...
 62:          0  tps65217   2 Edge      tps65217_pwr_but
 63:       5822  44e07000.gpio  29 Edge      wl18xx
 77:          0  4804c000.gpio  17 Edge      gpio_bbb
 78:          0  44e07000.gpio  15 Edge      gpio_bbb
IPI0:          0  CPU wakeup interrupts
IPI1:          0  Timer broadcast interrupts

При запуске некоторых прерываний (изменение входного значения gpio) и (даже) с пустым обработчиком прерываний, который ничего не делает: 

irqreturn_t gpio_irq_handler(int irq, void *dev_id) {
  return IRQ_HANDLED;
}

Я получаювышеупомянутые сообщения об ошибках в журнале ядра, и мои прерывания не обрабатываются :( Я заметил, что номера прерываний изменились (ранее номер IRQ для gpio был # gpio + 128). Я также знаю о новом libgpiod, который явно работает (я вижу устройства /dev/gpiochip[0..3]).Мои проблемы связаны с этими изменениями?Тем не менее, я немного сбит с толку, потому что все методы, которые я вызываю, работают, и все же мои прерывания обрабатываются как «неожиданные».Что я делаю не так ??

1 Ответ

0 голосов
/ 14 апреля 2019

Я исследовал проблему более подробно.Простым решением было добавить irq_set_irq_type(irq, IRQ_TYPE_NONE) после вызова request_any_context_irq() (этот метод теперь должен использоваться вместо request_irq()): 

ret = request_any_context_irq (irq, _gpio_irq_handler, IRQF_SHARED, "gpio_bbb", &gpio_data);
if (ret < 0) {
  printk(KERN_ERR MOD_STR"Failed to request IRQ %i (error %i)\n", irq, ret);
  return ret;
}
// Set IRQ type
irq_set_irq_type(irq, IRQ_TYPE_NONE);

Эти изменения, по-видимому, необходимы из-за нового универсального irqsystem в linux: https://www.kernel.org/doc/html/v4.12/core-api/genericirq.html. Я еще не до конца понял, почему и как тип IRQ влияет на вызываемые изнутри методы, но модуль gpio снова работает, как и ожидалось.

...