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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)

Chan

 

 

From: Ozgur Karatas <ozgurk@xxxxxxxx>
Sent: Tuesday, April 12, 2022 4:15 PM
To: Chan Kim <ckim@xxxxxxxxxx>
Cc: Greg KH <greg@xxxxxxxxx>; kernelnewbies@xxxxxxxxxxxxxxxxx; qemu-discuss <qemu-discuss@xxxxxxxxxx>
Subject: Re: Can't understand /proc/interrupts output for GICv3 case

 

 

On Tue, Apr 12, 2022 at 6:44 AM Chan Kim <ckim@xxxxxxxxxx> 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.

 

 

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@xxxxxxxx>
Sent: Monday, April 11, 2022 11:53 PM
To: Chan Kim <ckim@xxxxxxxxxx>
Cc: Greg KH <greg@xxxxxxxxx>; kernelnewbies@xxxxxxxxxxxxxxxxx; qemu-discuss <qemu-discuss@xxxxxxxxxx>
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@xxxxxxxxxx> 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 dont know how to remove this bar in the lefe when I add my in-line reply in outlook..) its 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 its 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.

 

 ==> 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.

 

==> your link doesnt 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 its 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 Ive read those books here and there in the past, but you know Im not given that much time for this and my job isnt 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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]

  Powered by Linux