Question

The start address 0x4806E000 (UART4 base address) is already present in /proc/iomem with the name omap4-uart.

How to disable the memory regions already allocated ?.

Edit : Even though request_mem_region is successful the console during booting shows this messages.

[    0.758514] Serial: 8250/16550 driver, 3 ports, IRQ sharing enabled
[    0.760040] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 104) is a OMAP UART0
[    0.760498] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 105) is a OMAP UART1
[    0.760955] omap_uart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2
[    1.778808] console [ttyO2] enabled
[    1.782989] omap_uart omap_uart.3: [UART3]: failure [serial_omap_probe]: -22
[    1.790466] omap_uart: probe of omap_uart.3 failed with error -22

I think it indicates the kernel is still trying to configure the uart4 instance? Edit 2: During software reset the while loop enters into infinite loop

/* Pad Configuration */
    unsigned int pad_value = 0xFFF8FFF8;
    l = ioread32(pad_map);
    l &= pad_value;
    iowrite32(l,pad_map);
    printk(KERN_ALERT "pad configured\n");


    /* Software reset */

       printk(KERN_ALERT "reset check bit = %x\n",((serial_in(UART_OMAP_SYSC))));
       serial_out(UART_OMAP_SYSC,swreset);
       printk(KERN_ALERT "reset check bit = %x\n",((serial_in(UART_OMAP_SYSC))));
       readval = serial_in(UART_OMAP_SYSS);
       while((readval & 0x01)== 0);
       printk(KERN_ALERT "software reset completed\n");
Was it helpful?

Solution 2

@Dino,

How to disable the memory regions already allocated ?.

Solution: what i think is that you can disable UART driver from kernel (menuconfig), build the kernel image and check /proc/iomem, I guess UART4 related instances will be removed.

Note: If using device tree concept then need to disable UART4 node "@uart4" in device tree.

I would like to use it in my driver code with different name. Is it possible?

Solution: In your LKM request for the memory range using request_mem_region with your driver name.

BTW: Why the call to ioremap is not failing ?

Solution: ioremap api will not fail because api does not have check for ex:"driver name" or any other checks.

OTHER TIPS

I don't believe it's possible to reuse the memory region by other driver. This would make first driver misbehaving. This means that in order to use this memory region by your driver, you should first disable the other driver.

Now it's possible that your ioremap() call won't return an error. It's also possible that it will appear to work perfectly fine. This is because AFAIK, the content of /proc/iomem does not come from ioremap() calls but from request_mem_region() calls. It's important to understand what both of them do:

  • You should first call request_mem_region to claim that your driver is going to use requested memory region (note that this won't do any memory mapping, it will only indicate your will in doing so). In case of your device, some driver already did this so it may use this region when needed. It's possible, however, that it didn't call ioremap() immediately after claiming the region but will do this on demand.

  • If above call succeeded, you may be sure that no other driver is going to use this region. This means you are free to call ioremap() and iounmap() on this region whenever you want.

Technically it's possible to do only 2nd thing and skip using request_mem_region but this way your driver would have to keep memory mapped all times just to indicate that you may use it in future. So you should be nice and always reserve the region first.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top