新手上路
- 积分
- 30
- 金钱
- 30
- 注册时间
- 2017-5-25
- 在线时间
- 20 小时
|
楼主 |
发表于 2021-5-12 11:45:25
|
显示全部楼层
接我提出的问题：key0_handler函数中的参数dev_id为imx6uirq设备的地址，但是这个地址是怎样传递到dev_id中去的呢？是在下面的request_irq函数中最后一个参数传递过去的嘛？答案：是
request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,
const char *name, void *dev)
我在网上找到答案了！！！
-------------------------------------------------------------转自网络，如有侵权，请坐下谈--------------------------
request_irq的作用是申请使用IRQ并注册中断处理程序。
request_irq（）函数的原型如下：
/* kernel/irq/manage.c */
int request_irq(
unsigned int irq,
    irqreturn_t (*handler)(int, void *, struct pt_regs *),
    unsigned long irqflags,
    const char *devname,
    void *dev_id );
 
我们知道，当使用内核共享中断时，request_irq必须要提供dev_id参数，并且dev_id的值必须唯一。那么这里提供唯一的dev_id值的究竟是做什么用的？
 
起先我以为dev_id的值是提供给kernel进行判断共享中断线上的哪一个设备产生了中断（即哪个irqaction产生中断）,然后执行相应的中断处理函数(irqaction->handler)。实际上不是的，我们来看看《Linux Kernel Development – Second Edition》第六章中Shared Handlers这一节,其中有段总结性的文字如下：
 
When the kernel receives an interrupt, it invokes sequentially each registered handler on the line. Therefore, it is important that the handler be capable of distinguishing whether it generated a given interrupt. The handler must quickly exit if its associated device did not generate the interrupt. This requires the hardware device to have a status register (or similar mechanism) that the handler can check. Most hardware does indeed have such a feature.
 
这段话的大概意思是，发生中断时，内核并不判断究竟是共享中断线上的哪个设备产生了中断，它会循环执行所有该中断线上注册的中断处理函数（即irqaction->handler函数）。因此irqaction->handler函数有责任识别出是否是自己的硬件设备产生了中断，然后再执行该中断处理函数。通常是通过读取该硬件设备提供的中断flag标志位进行判断。
 
那既然kernel循环执行该中断线上注册的所有irqaction->handler函数，把识别究竟是哪个硬件设备产生了中断这件事交给中断处理函数本身去做，那request_irq的dev_id参数究竟是做什么用的？
 
我总结了一下，实际上dev_id作用主要有两点：
一．在中断处理程序释放时使用到dev_id：
When your driver unloads, you need to unregister your interrupt handler and potentially disable the interrupt line. To do this, call
void free_irq(unsigned int irq, void *dev_id)
……
The fifth parameter, dev_id, is used primarily for shared interrupt lines. When an interrupt handler is freed (discussed later), dev_id provides a unique cookie to allow the removal of only the desired interrupt handler from the interrupt line. Without this parameter, it would be impossible for the kernel to know which handler to remove on a given interrupt line.
 
这里《LKD2》讲了很清楚，当调用free_irq注销中断处理函数时（通常卸载驱动时其中断处理函数也会被注销掉）,因为dev_id是唯一的，所以可以通过它来判断从共享中断线上的多个中断处理程序中删除指定的一个。如果没有这个参数，那么kernel不可能知道给定的中断线上到底要删除哪一个处理程序。
 
下面我们来看一下free_irq的代码：
void free_irq(unsigned int irq, void *dev_id)
{
    struct irq_desc *desc;
    struct irqaction **p;
    unsigned long flags;
    WARN_ON(in_interrupt());
    if (irq >= NR_IRQS)
        return;
    desc = irq_desc + irq;    /* 获取该中断号对应的irq_desc */
    spin_lock_irqsave(&desc->lock, flags);
    p = &desc->action;        /* 找到该irq的irqaction链表 */
    for (;;) {
        struct irqaction *action = *p;
        if (action) {
            struct irqaction **pp = p;
            p = &action->next;
            if (action->dev_id != dev_id)
                continue;   /* 这两句进行循环判断，直到找到相应dev_id设备的irqaction */
 
            /* Found it - now remove it from the list of entries */
            *pp = action->next;   /* 指向下一个irqaction */
            /* Currently used only by UML, might disappear one day.*/
#ifdef CONFIG_IRQ_RELEASE_METHOD
            if (desc->chip->release)
                desc->chip->release(irq, dev_id);
#endif
            if (!desc->action) {
                desc->status |= IRQ_DISABLED;
                if (desc->chip->shutdown)
                    desc->chip->shutdown(irq);
                else
                    desc->chip->disable(irq);
            }
            recalculate_desc_flags(desc);
            spin_unlock_irqrestore(&desc->lock, flags);
            unregister_handler_proc(irq, action);
            /* Make sure it's not being used on another CPU */
            synchronize_irq(irq);
            kfree(action);        /* 删除该设备(dev_id)的irqaction */
            return;
        }
        printk(KERN_ERR "Trying to free already-free IRQ %d\n", irq);
        spin_unlock_irqrestore(&desc->lock, flags);
        return;
    }
}
 
重点来了！！！！
二．将使用该中断处理程序的设备结构体传递给该中断处理程序:
首先看两个基础条件：
1)  内核中的各个设备结构体肯定是唯一的，因此满足dev_id唯一这个要求
2)  dev_id参数会在发生中断时传递给该中断的服务程序。
典型的中断服务程序定义如下：
 
static irqreturn_t intr_handler(int irq, void *dev_id, struct pt_regs *regs);
 
即request_irq的dev_id参数会传递给该中断服务程序的dev_id。因此也可以将驱动程序的设备结构体通过dev_id传递给中断服务程序。
这样做作用主要有两个：
1) 中断服务程序可能使用到设备结构体中的信息
如s3c2410的iis音频驱动,它是将DMA Channel结构体通过dev_id传递给中断服务程序
/* arch/arm/mach-s3c2410/dma.c */
int s3c2410_dma_request(unsigned int channel, struct s3c2410_dma_client *client,void *dev)
{
     err = request_irq(chan->irq, s3c2410_dma_irq, IRQF_DISABLED, client->name, (void *)chan);
……
}
 
目的是中断处理函数s3c2410_dma_irq内需要用到chan结构体的duf成员和load_state成员等。
使用方法如下：
/* arch/arm/mach-s3c2410/dma.c */
static irqreturn_t
s3c2410_dma_irq(int irq, void *devpw, struct pt_regs *regs)
{
    struct s3c2410_dma_chan *chan = (struct s3c2410_dma_chan *)devpw; /* 这里强制转化成request_irq时传给dev_id的设备类型，此处即s3c2410_dma_chan ，下面便可以使用它*/
    struct s3c2410_dma_buf *buf;
    buf = chan->curr;
    ……
}
 
因此，我们可以通过将设备结构传递给request_irq的dev_id参数这种机制，在中断处理函数中使用该设备结构体，这是大部分驱动程序通用的一种手法。
 
2）前面我们讲了若使用共享中断，那么中断处理函数自身需要能识别是否是自己的设备产生了中断。通常这是通过读取该硬件设备提供的中断flag标志位进行判断的。
而往往驱动程序里定义的设备结构体通常包含了该设备的IO地址,加上偏移就可以算出中断状态寄存器及中断flag标志位的IO地址信息。因此将设备结构体通过dev_id传递给设备中断处理程序的另一个作用就是使用共享中断时，可以在中断处理函数内通过读取该设备结构 (dev_id) 中提供的中断Flag标志位地址信息进行判断，是否是该设备产生了中断，然后再进一步判断是否继续往下执行还是跳到下一个irqaction->handler函数再判断执行。当然，如果本来就知道该设备中断状态寄存器的IO地址，也可以选择直接readl该地址信息进行判断。
————————————————
版权声明：本文为CSDN博主「围城&微尘」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_27516841/article/details/108541394
|
|
/2 
|手机版|OpenEdv-开源电子网
( 粤ICP备12000418号-1 )
发表于 2021-5-11 15:58:41
发表于 2021-5-12 01:32:52
