4

I am trying to port drivers from old kernel to new one on ARM based platform. While porting one of the drivers I have noticed that request_irq fails on new kernel. Actually, what this driver have is a number of hard coded irq numbers, and it tries to request_irq for this HW lines. I started to search what is the reason of request_irq failure, - the reason is that the appropriate IRQ descriptor (irq_desc) have IRQ_NOREQUEST flag set.

I started to search where this flag is cleared, and found that it happens here:

of_platform_populate
          |
         ...
          |
   of_device_alloc
          |
         ...
          |
 irq_of_parse_and_map
(some levels below this flag is dropped)

So that code is invoked from mach init code and parse DTB, all interrupt numbers that are mentioned in DTB would be mapped to irq virtual space and will be accessible through appropriate devices structures, for example:

irq = platform_get_irq(pdev, 0);

As I already said, this old - fashion drivers just have hard-coded irq numbers in include files, and they don't have no appropriate dtb entries.

The question is what is the right way, from the kernel perspective of view, to port this? Do I need to make this old driver a platform device (now it is just a char device) and create appropriate dtb description for it? Or I can just use some kernel API to mark this interrupts as available? Is it a common/normal style?

Henry
  • 2,953
  • 2
  • 21
  • 34
Alex Hoppus
  • 3,821
  • 4
  • 28
  • 47
  • [This question on the GIC Linux initialization](http://stackoverflow.com/questions/36423059/arm-specific-irq-initialization) might be helpful. You can't just use a number as linux has an allocated structure in newer kernels (which support a sparse interrupt mapping). Newer kernels also manage resources so that driver init exceptions and de-registering are much less complex. – artless noise Nov 30 '16 at 14:06
  • *The question is what is the right way, from the kernel perspective of view, to port this?* You can do either, but the more sane is to make it a platform device; especially if it is ARM/SOC specific. Ie, it is a platform device. It is hard to give a *right* answer with out more specifics on the hardware and what the driver might do. – artless noise Nov 30 '16 at 14:15
  • @artlessnoise Could you give more details about "non sane" way? i would be glad to see any code examples if possible. Looks like it would not work if i just would drop this NOREQUEST flag. Please, you could put it as an answer. – Alex Hoppus Nov 30 '16 at 14:34
  • 1
    Try `irq_find_mapping(NULL, my_irq_num)`. Also, enable [**CONFIG_IRQ_DOMAIN_DEBUG**](http://lxr.free-electrons.com/source/kernel/irq/irqdomain.c#L725) and DEBUGFS (kernel hack, I think) and you can get the IRQ domain info. – artless noise Nov 30 '16 at 14:55
  • 1
    @AlexHoppus Correct way would be to define IRQ in Device Tree. Which requires, of course, converting the driver to use Device Tree. What is the hardware your driver represents? – Sam Protsenko Dec 01 '16 at 21:43
  • Actually, i asked about video decoder/encoder, but in fact there are a lot of them with this irq problem. – Alex Hoppus Dec 02 '16 at 05:04

0 Answers0