Can't understand /proc/interrupts output for GICv3 case

Ozgur Karatas ozgurk at ieee.org
Tue Apr 12 03:29:08 EDT 2022


On Tue, Apr 12, 2022 at 11:22 AM Chan Kim <ckim at etri.re.kr> wrote:

> Hi Ozgur,
>
> When I run it on ubuntu-20.04, the irq number returned was 5. (in 5.4.188
> vanila, it was 6) but this irq number will depend on the hardware
> configuration.
>
> And if I don’t pass IRQF_SHARED, the kernel would have assigned a
> dedicated irq_desc so it will not be a problem.
>
> And about irq 6 for floppy, isn’t it for intel specific? This irq number
> is virtual so I think kernel will assign the number as shared or dedicated
> I think.
>
> My app/driver is just for test so that other members can do driver test on
> the virtual machine so for now it suits my need.
>
> Thank you! (and I’ll be reading the references again soon)
>

Hello Chan,

I'm not experienced in this matter so information i would give would be
wrong. However, if you still want to drive a driver, is best to work with
kernel modules. Indeed, if you look at how linux kernel works on Interrupt
Handler as an example, i think you will find a solution much easier with a
use driver.

Regards

                   Ozgur

Chan
>
>
>
>
>
> *From:* Ozgur Karatas <ozgurk at ieee.org>
> *Sent:* Tuesday, April 12, 2022 4:15 PM
> *To:* Chan Kim <ckim at etri.re.kr>
> *Cc:* Greg KH <greg at kroah.com>; kernelnewbies at kernelnewbies.org;
> qemu-discuss <qemu-discuss at nongnu.org>
> *Subject:* Re: Can't understand /proc/interrupts output for GICv3 case
>
>
>
>
>
> On Tue, Apr 12, 2022 at 6:44 AM Chan Kim <ckim at etri.re.kr> wrote:
>
> Hi Ozgur,
>
> My replies in-line.
>
> Thanks!
>
>
>
> Hello Chan,
>
>
>
> today, web-based online content is gaining more importance than books
> especially in kernel.org you can browse serious content about IRQ and see
> examples.
>
>
>
> https://www.kernel.org/doc/html/v4.12/core-api/genericirq.html
>
> https://www.kernel.org/doc/html/
>
>
>
> You can search online.
>
>
>
> And you received as "6" in your last e-mail was actually a old floopy
> address and your code would fail if you were using a floopy.
>
> As Greg stated, if you use a domain driver over a kernel api, kernel would
> handle it in the get interrupt part.
>
>
>
> Regards
>
>
>
>                       Ozgur
>
>
>
>
>
> *From:* Ozgur Karatas <ozgurk at ieee.org>
> *Sent:* Monday, April 11, 2022 11:53 PM
> *To:* Chan Kim <ckim at etri.re.kr>
> *Cc:* Greg KH <greg at kroah.com>; kernelnewbies at kernelnewbies.org;
> qemu-discuss <qemu-discuss at nongnu.org>
> *Subject:* Re: Can't understand /proc/interrupts output for GICv3 case
>
>
>
>
>
> Re-hi,
>
>
>
> On Mon, Apr 11, 2022 at 6:16 PM Chan Kim <ckim at etri.re.kr> wrote:
>
>
> > > > What bus type is your driver written for?
> > > >
> > > That sounds very logical. In my case I added it to system bus.
> >
> > What exactly do you mean by "system bus"?
> >
> I meant 'sysbus' in qemu code that I showed in the qemu code.
> And I think it's the CPU bus.
>
> >
> > Where is your kernel code?
> >
> This is the init function of my char driver. I thought if the struct cdev
> contains struct device, maybe I could use the struct device's of_node to
> call of_irq_get but it doesn't.
> And I remember I've seen the cdev in usually contained in the driver data
> of
> platform driver(?). Can I implement platform driver in kernel module form?
> Below is the char driver init code. Currently it's request_irq(6, ... ) but
> I want to know out the number 6 using program. If you have any advice,
> please tell me.
>
> static int __init chr_driver_init(void)
> {
>         int ret;
>         /* Allocating Major number */
>         if ((alloc_chrdev_region(&dev, 0, 1, "axpu_Dev")) < 0) {
>                 printk(KERN_INFO"Cannot allocate the major number..\n");
>                 return -1;
>         }
>
>         printk(KERN_INFO"Major = %d Minor = %d..\n",MAJOR(dev),MINOR(dev));
>
>         /* creating cdev structure */
>         cdev_init(&axpu_cdev, &fops);
>         axpu_cdev.owner = THIS_MODULE;
>
>         /* Adding character device to the system */
>         if ((cdev_add(&axpu_cdev,dev,1)) < 0) {
>                 printk(KERN_INFO "Cannot add the device to the
> system...\n");
>                 goto r_class;
>         }
>
>
>
> I guess you got address 0x80000 randomly also may have this code from
> stackoverflow but it wont work for you.
>
> as written stackoverflow, device_create must be a character device and an
> address under /sys/dev/char before getting NULL.
>
> So did you create a char device with use mknod command?
>
>
>
>  ==> (I don’t know how to remove this bar in the lefe when I add my
> in-line reply in outlook..) it’s the size of address range of my device.
> My question is, how I can get the io virtual address when 1. my driver is a
> kernel module and 2. It is a character driver. For platform driver I got it
> from the resource table, but I think it’s an old method now and we should
> ask the bus as Greg-KH said. The kernel already knows the addresses because
> it had processed the device table.
>
>
>
> Actually register_chrdev will do this for you but you can do it with mknod
> if you wish.
>
>
>
>         /* creating struct class */
>         if ((dev_class = class_create(THIS_MODULE, "axpu_class")) == NULL)
> {
>                 printk(KERN_INFO "cannot create the struct class...\n");
>                 goto r_class;
>         }
>
>         /* for interrupt test !! */
>         /*  for vanilla work-around.. already made by mkdev */
>         if ((device_create(dev_class, NULL, dev, NULL, "axpu_device")) ==
> NULL) {
>                 printk(KERN_INFO "cannot create the device ..\n");
>                 goto r_device;
>         }
>         else { printk(KERN_INFO "axpu_device created..\n"); }
>         /**/
>
>         vaddr = ioremap(AXPU_BASE, 0x80000);   \
>
>
>
> Please first read Documentation/devices.txt because kernel can do dynamic
> allocation I think.
>
> *
> https://www.oreilly.com/library/view/linux-device-drivers/0596000081/ch03s02.html
>
> *
> https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch03.html
>
>
>
>  ==> I understand by using class_create and device_create, the device file
> is generated under /dev (without using mknod). I am using this method
> without problem and the app/driver runs ok on the virtual machine.
>
>
>
>         if(!vaddr)
>         {
>                 printk(KERN_INFO"Failed to map the address.\n");
>                 release_mem_region(AXPU_BASE,AXPU_SIZE);
>                 return 1;
>         }
>         printk("----- AXPU_BASE mapped at vaddr = %px\n", vaddr);
>
>         ret = request_irq(6, axpu_irq_handler, IRQF_SHARED, "axpu_irq",
> &axpu_cdev);
>         printk("request_irq returned %d\n", ret); // -EINVAL
>         printk(KERN_INFO "Device driver inserted ..done properly..\n");
>         return 0;
>
>
>
> You dont need to call manual, because it is defined in cdev.h.
>
> *
> https://embeddedguruji.blogspot.com/2019/01/automatically-creating-device-nodes.html
>
>
>
> ==> your link doesn’t show do any io access or irq processing. I want to
> know how I can get the io virtual address and the virtual irq number from
> the driver. My driver is a character device driver and it’s a kernel
> module which is inserted after OS has booted. I thinks this should be
> possible.
>
>
>
> in example for example device_destroy already destroys class.
>
>
>
> r_device :
>         class_destroy(dev_class);
>
> r_class :
>         unregister_chrdev_region(dev,1);
>         return -1;
> }
>
>
>
> it will be great that i will recommend three books to you again.
>
> * Understanding the Linux Kernel
> * Linux Device Drivers
>
> * Linux Kernel Development
>
>
>
> ==> Yes I’ve read those books here and there in the past, but you know I’m
> not given that much time for this and my job isn’t always working with
> linux drivers. I will take some time to read those books thoroughly
> sometime later.  Thanks for the interest and advices.
>
>
>
> Thank you.
> Chan Kim
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20220412/5557978b/attachment-0001.html>


More information about the Kernelnewbies mailing list