OMAP3 interrupt latency much worse when CPU idle

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

 



Hi there,

to verify interrupt latency on OMAP3530 following test driver was written:
------8<-----------
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/gpio.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
#include <linux/irq.h>

struct gpio_test_dev {
	int gpio_in;
	int gpio_out;
};

static struct gpio_test_dev dev;

static irqreturn_t gpio_irq(int irq, void *dev_id)
{
	struct gpio_test_dev *gpio_dev = dev_id;
	int val;

	val = gpio_get_value(gpio_dev->gpio_in);
	if (val >= 0)
		gpio_set_value(gpio_dev->gpio_out, !val);

	return IRQ_HANDLED;
}

static int __init gpio_test_init(void)
{
	int rc;

	dev.gpio_in = 159;	/* mcbsp1_dr.gpio_159, pin18 */
	dev.gpio_out = 161;	/* mcbsp1_fsx.gpio_161, pin16 */

	rc = gpio_request(dev.gpio_in, "gpio-in");
	if (rc < 0)
		goto err;
	rc  = gpio_direction_input(dev.gpio_in);
	if (rc < 0)
		goto err_free_input;

	rc = gpio_request(dev.gpio_out, "gpio-out");
	if (rc < 0)
		goto err_free_input;
	rc  = gpio_direction_output(dev.gpio_out, 0);
	if (rc < 0)
		goto err_free_output;

	rc = request_irq(gpio_to_irq(dev.gpio_in), gpio_irq,
			IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
			"gpio-irq", &dev);
	if (rc < 0)
		goto err_free_output;

	return 0;

err_free_output:
	gpio_free(dev.gpio_out);
err_free_input:
	gpio_free(dev.gpio_in);
err:
	return rc;
}

static void __exit gpio_test_exit(void)
{
	free_irq(gpio_to_irq(dev.gpio_in), &dev);
	gpio_free(dev.gpio_in);
	gpio_free(dev.gpio_out);
}

module_init(gpio_test_init);
module_exit(gpio_test_exit);

MODULE_DESCRIPTION("GPIO interrupt test driver");
MODULE_LICENSE("GPL v2");
------8<-----------

gpio_in (yellow) is fed with signal generator while scope inputs are
connected to both gpio_in and gpio_out (blue). Output signal is inverted
to make waveform compare easier by naked eye.

Expected result is clean waveform with small offset and reasonable jitter.
To make this clearly visible, waveform persistence was enabled on scope.
Resulting waveform on idle system looks like this:
http://ladislav.michl.sweb.cz/omap3_edge_irq_1.png
As you can see, latency (jitter) is up to half of pulse width, which seems
pretty bad as frequency is 610Hz.

However, loaded system (*) shows much better results:
http://ladislav.michl.sweb.cz/omap3_edge_irq_2.png

Any idea how to get good enough (second measurement) results regardless of
the system load?

Kernel is 4.14-rc8 with Tony's patch applied:
https://patchwork.kernel.org/patch/9643499/

CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
CONFIG_NO_HZ_IDLE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT_NONE=y
CONFIG_HZ_FIXED=0
CONFIG_HZ_100=y
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y

Thank you,
	ladis

(*) simple shell one liner: 'while true; do true; done'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux