ONKEY interrupt is trapped in PMU occasionally on resuming

Andy Green andy at openmoko.com
Mon Feb 4 16:47:46 CET 2008

Hash: SHA1

Somebody in the thread at some point said:

> So I tried to use i2cdump to read PCF50633 after every suspend/resume
> process. This issue would not happen anymore. Obviously, INTs of
> PCF50633 are not read & clear indeed as resuming occasionally.  

Hi Matt -

I look at the driver and I dunno if IRQT_FALLING for the PCF50633 is a
good idea.  The interrupt is disabled

static void pcf50633_work(struct work_struct *work)
	struct pcf50633_data *pcf =
			container_of(work, struct pcf50633_data, work);
	u_int8_t int1, int2, int3, int4, int5;

	pcf->working = 1;

	/* FIXME: read in one i2c transaction */
	int1 = __reg_read(pcf, PCF50633_REG_INT1); <== IRQ# can go up here
	int2 = __reg_read(pcf, PCF50633_REG_INT2);
	int3 = __reg_read(pcf, PCF50633_REG_INT3);
	int4 = __reg_read(pcf, PCF50633_REG_INT4);
	int5 = __reg_read(pcf, PCF50633_REG_INT5);

... various handlers ...

	enable_irq(pcf->irq); <=== does the CPU recognize any interrupt that
happened since PCF50633_REG_INT1 was read?

If another interrupt happens between the I2C reads that clear the
interrupt source, and re-enabling interrupt service at the end of the
workqueue handler, I don't actually know if the CPU interrupt hardware
will understand that it should rememer about it and signal on re-enable.
 If it doesn't take care, then the IRQ line will stick low forever
because we never see a falling edge any more if it is stuck low.

How about trying

	set_irq_type(irq, IRQT_FALLING);

changed to

	set_irq_type(irq, IRQT_LOW);

in drivers/i2c/chips/pcf50633.c

Still it doesn't explain the 0xff INT2 register.

- -Andy

Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list