What does request_mem_region() actually do and when it is needed?

Question

I'm studying on writing embedded linux driver, and decided to fire a few GPIOs to make sure I understand the book (LDD3, chap9.4.1) correctly.

I am able to control the correct GPIO pins as intended (making it high and low, I probed with a multimeter); however, I tested 2 pieces of code, one with request_mem_region(), and one without. I'm expecting the one without will fail, but both is working just fine.

Code with request_mem_region:

if( request_mem_region( PIN3_CONF_PHYS, MAPPED_SIZE_GPIO_CONF,DEVICE_NAME ) == NULL )
  {
    printk( KERN_ALERT
            "GPIO_140_141_conf_phys error:%s: unable to obtain I/O memory address 0x%08llX\n",
            DEVICE_NAME, PIN3_CONF_PHYS );

    return -EBUSY;
  }

pin3_conf = (u32)ioremap( PIN3_CONF_PHYS, MAPPED_SIZE_GPIO_CONF);
pin4_conf = (u32)ioremap( PIN4_CONF_PHYS, MAPPED_SIZE_GPIO_CONF);
pin5_conf = (u32)ioremap( PIN5_CONF_PHYS, MAPPED_SIZE_GPIO_CONF);
pin6_conf = (u32)ioremap( PIN6_CONF_PHYS, MAPPED_SIZE_GPIO_CONF);
//-----------------------------------------------------------------
if( request_mem_region( GPIO_BANK5_PHYS, MAPPED_SIZE_GPIO_5,DEVICE_NAME ) == NULL )
  {
    printk( KERN_ALERT
            "error:%s: unable to obtain I/O memory address 0x%08llX\n",
            DEVICE_NAME, GPIO_BANK5_PHYS );
 
    return -EBUSY;
  }
    
gpio_virt = (u32)ioremap( GPIO_BANK5_PHYS, MAPPED_SIZE_GPIO_5 );

//some iowrite32() functions continue...

Code without request_mem_region():

pin3_conf = (u32)ioremap( PIN3_CONF_PHYS, MAPPED_SIZE_GPIO_CONF);
pin4_conf = (u32)ioremap( PIN4_CONF_PHYS, MAPPED_SIZE_GPIO_CONF);
pin5_conf = (u32)ioremap( PIN5_CONF_PHYS, MAPPED_SIZE_GPIO_CONF);
pin6_conf = (u32)ioremap( PIN6_CONF_PHYS, MAPPED_SIZE_GPIO_CONF);
gpio_virt = (u32)ioremap( GPIO_BANK5_PHYS, MAPPED_SIZE_GPIO_5 );
//some iowrite32() functions continue...

The only difference I can observe from both cases is the result of doing a cat /proc/iomem, the one with request_mem_region() will display an additional line showing 49056000-49056097 : GPIO3.

My question is why request_mem_region() is needed since I can still communicate with the hardware address with only ioremap()? So when do we actually need to use request_mem_region()?

Thanks for any replies!

Ingratiate

Answer 1

request_mem_region tells the kernel that your driver is going to use this range of I/O addresses, which will prevent other drivers to make any overlapping call to the same region through request_mem_region. This mechanism does not do any kind of mapping, it's a pure reservation mechanism, which relies on the fact that all kernel device drivers must be nice, and they must call request_mem_region, check the return value, and behave properly in case of error.

So it is completely logical that your code works without request_mem_region, it's just that it doesn't comply with the kernel coding rules.

However, your code doesn't comply with the kernel coding style. And additionnally, there is an existing infrastructure to handle GPIOs, named gpiolib, which you should use instead of manually remapping your GPIO bank registers. Which platform are you working on ?

Canula

Thanks for the reply! This clear things up for me, I'm using the beagleboard with Angstrom. I posted another question in beagleboard group and I'm suggested to use gpiolib too. However, I tried #include <linux/gpio.h> or #include <asm/gpio.h> but both failed, what should I use instead? – Wrongdoing

Another question, when I do a make to compile a kernel module or a driver, which directories it will be looking for the headers for #include? For example, one of it will be <MY_KDIR>/include, thus #include <linux/module.h> and #include <linux/kernel.h> will look into <MY_DIR>/include/linux/; and #include <asm/io.h> will look into <MY_DIR>/include/asm/. – Wrongdoing

@Petazzoni Sorry for posting this 3rd comment, I just learned that I can notify the person answering my questions, and I could not edit the previous comments, so I have to post this. – Wrongdoing

Answer 2

Using request_mem_region() and ioremap() in device drivers is now deprecated. You should use the below "managed" functions instead, which simplify driver coding and error handling:

devm_ioremap()
devm_iounmap()
devm_ioremap_resource(), Takes care of both the request and remapping operations

Look at slide 293 of bootlin company training course.

Trousers