This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP4460 and GPIO/Interrupt configuration

Hi all, I've searched on the forum and found no discussion quite like what I'm facing. I am using a blaze-based development board running 4AJ.2.5p2 and I am trying to port LIS3DH from ST onto it. I have successfully ported the sensor to the extend that the sensor will CONTINUOUSLY display the current XYZ values. I am trying to enable interrupt on OMAP4460 to allow the sensor to ONLY work when it is moved.

Here's some details: The GPIO intended for this interrupt usage is 155. It is configured in arch/arm/mach-omap2/board-44xx-blaze-sensors.c

#define LIS3DH_ACC_DEFAULT_INT1_GPIO		155
#define LIS3DH_ACC_DEFAULT_INT2_GPIO		(-EINVAL)

static struct lis3dh_acc_platform_data lis3dh_pdata = {
  	.fs_range = LIS3DH_ACC_G_2G,
	.axis_map_x = 0,
	.axis_map_y = 1,
	.axis_map_z = 2,
	.negate_x = 0,
	.negate_y = 0,
	.negate_z = 0,
	.poll_interval = 100,
	.min_interval = LIS3DH_ACC_MIN_POLL_PERIOD_MS,
	.gpio_int1 = LIS3DH_ACC_DEFAULT_INT1_GPIO,
	.gpio_int2 = LIS3DH_ACC_DEFAULT_INT2_GPIO,
};
static struct i2c_board_info __initdata blaze_bus2_sensor_boardinfo[] = {
	{
		I2C_BOARD_INFO("lis3dh_acc", 0x19),
		.platform_data = &lis3dh_pdata,
	},
};
int __init blaze_sensor_init(void)
{
....
	omap_register_i2c_bus(2, 400, blaze_bus2_sensor_boardinfo,
			ARRAY_SIZE(blaze_bus2_sensor_boardinfo));
....
	return 0;
}

The function blaze_sensor_init(void) is executed in arch/arm/mach-omap2/board-4430sdp.c. PIN MUX for this GPIO has be configured as OMAP4_MUX(UART4_RX, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLDOWN)

Within the sensor driver, lis3dh_acc.c, the GPIO is transform into interrupt using:

if (stat->pdata->gpio_int1 >= 0) {
		stat->irq1 = gpio_to_irq(stat->pdata->gpio_int1);
		pr_info("%s: %s has set irq1 to irq: %d, "
							"mapped on gpio:%d\n",
			LIS3DH_ACC_DEV_NAME, __func__, stat->irq1,
							stat->pdata->gpio_int1);
	}

The output for this code is : [ 5.550567] lis3dh_acc: lis3dh_acc_probe has set irq1 to irq: 315, mapped on gpio:155

Since the PIN MUX has been set to low, rising trigger has been configured within the driver:

err = request_irq(stat->irq1, lis3dh_acc_isr1, IRQF_TRIGGER_RISING, "lis3dh_acc_irq1", stat); 

Note that IRQF_TRIGGER_HIGH has also been tried without success. I have even tried using a function generator to input a square wave clock at 1kHz with amplitude 1.8V into the GPIO, but no interrupt is detected.

Interrupt message will be displayed onscreen using:

static void lis3dh_acc_irq1_work_func(struct work_struct *work)
{
	struct lis3dh_acc_status *stat =
	container_of(work, struct lis3dh_acc_status, irq1_work);
	printk("[G_SENSOR]IRQ1 triggered, IRQ:%d, gpio:%d\n",  stat->irq1,stat->pdata->gpio_int1);
	enable_irq(stat->irq1);
}

This function is verified by setting trigger to IRQF_TRIGGER_LOW, where result is continuous flooding of interrupt successful messages.

Is there something I am missing from the OMAP interrupt settings? Is GPIO155 able to be configured as interrupt?

I hope my description is specific enough, please feel free to ask anything you think I missed.

Thanks! PS: are all GPIO able to be configured as interrupt in OMAP?

  • Hello Henry,

    If your query is still present (sorry for the delayed response), your code seems to be correct.

    Regarding your other questions all OMAP GPIOs, including GPIO155, can be configured as interrupts.

    What I can think of, as possible problems, is:
    1. Check if gpio is used somewhere else in your software (some other specific function)

    2. gpio_155 is muxed on the same pad as UART4_RX, sdmmc4_dat2 & kpd_row8. Check if your software uses any of those (uart4_rx, sdmmc4_dat2 or kpd_row8, especially uart4_rx), maybe sw registers the driver & that could conflict and cause problems with gpio_155 function.

    Best Regards,

    Yordan