查看报错源码,这里报错的原因是从中断获取到的中断源配置和设备树中的不一致,也不为IRQ_TYPE_NONE,这也能解释第一次insmod驱动不会出现问题,只有移除驱动重新insmod后才会出现的现象。 unsigned int irq_create_fwspec_mapping(struct irq_fwspec *fwspec)
int devm_request_irq(struct device *dev, unsigned int irq, irq_handler_t handler, unsigned long irqflags, const char *devname, void *dev_id); 此函数与request_irq()的区别是devm_开头的API申请的是内核“managed”的资源,一般不需要在出错处理和remove()接口里再显式的释放。有点类似Java的垃圾回收...
在内核中,除了可以通过request_irq()、devm_request_irq()申请中断以外,还可以通过request_threaded_irq()和devm_request_threaded_irq()申请。这两个函数的原型为: 由此可见,它们比request_irq()、devm_request_irq()多了一个参数thread_fn。用这两个API申请中断的时候,内核会为相应的中断号分配一个对应的内核...
在内核中除了可以通过request_irq()、devm_request_irq()申请中断以外,还可以通过request_threaded_irq() 和 devm_request_threaded_irq() 申请。这两个函数的原型为: /** * request_threaded_irq - allocate an interrupt line * @irq: Interrupt line to allocate * @handler: Function to be called when ...
devm_request_threaded_irq 函数特点如下: ①、用于申请中断,作用和 request_irq 函数类似。 ②、此函数的作用是中断线程化,大家如果直接在网上搜索“devm_request_threaded_irq”会发现相关解释很少。但是大家去搜索 request_threaded_irq 函数就会有很多讲解的博客和帖子,这两个函数在名字上的差别就是前者比后者多了...
API函数,devm_request_threaded_irq 函数特点如下:① 用于申请中断,作用和 request_irq 函数类似。
* 因为该驱动程序可能支持多个芯片,所以需要传入 extend_irq_chip_id 用于标识不同的芯片 */ devm_request_threaded_irq(&client->dev, client->irq, NULL, extend_irq_handler, IRQF_TRIGGER_LOW | IRQF_ONESHOT |IRQF_SHARED, dev_name(&client->dev), ...
申请函数使用了devm_request_threaded_irq函数,在驱动中我们会经常看到“devm_”开头的函数,这些函数大多用于注册、申请工作,使用这一类函数注册、申请的内容无需我们手动注销,驱动退出之前系统会自动完成注销。这里我们重点关注中断的处理函数goodix_ts_irq_handle r,触摸中断发生有将会在中断服务函数中上报触摸事件。
3. devm_request_threaded_irq 函数: ①用于申请中断,作用和 request_irq 函数类似。 ②此函数的作用是中断线程化。 中断线程化以后中断将作为内核线程运行,而且也可以被赋予不同的优先级,任务的优先级可能比中断线程的优先级高, 这样做的目的就是保证高优先级的任务能被优先处理。虽然中断下半部可以被延迟处理,...
如果我们使用 devm_request_threaded_irq 函数来申请中断,那么就不需要我们再调用free_irq 函数对其进行释放。大家可以注意一下,带有“devm_”前缀的都是一些和设备资源管理有关的函数。关于“devm_”函数的实现原理这里就不做详细的讲解了,我们的重点在于学会如何使用这些 API 函数,感兴趣的可以查阅一些其他文档或者帖...