TSC2007 Linux Driver Problem - I2C Interrupt Scheduler Deadlock

Hi Johnny -

Has this been resolved?

Not yet, I don't have any solution for this problem.

Jenny,

In fact, I responded to Max Ron on 06-30-2010 at

http://e2e.ti.com/support/data_converters/precision_data_converters/int-precision_data_converters/f/75/p/54247/192539.aspx

Thereafter, I did not get further inquiry, and thus the case is considered closed already. 

Best regards,
Wendy F.

Hi

I modified the tsc2007 driver which was given in its page according to our needs. Our firm made its own DM365 board. In This board we used TSC2007 and connected PENIRQ pin to GPIO0 of DM365. It is being seen OK on driver. when i touch to touchscreen cursor is moving but at the same time i am getting

BUG: scheduling while atomic: swapper /0x00000103/0, CPU#0

warning and embedded linux is being crashed. there are 2 files that i modified and uploadded to www.muhendislikhizmeti.com/touchscreen.zip one is with timer the other is not. it is giving this error all time

is anyboy have any idea how to solve this problem.

thanks to all

The "scheduling while atomic"  panic happens when schedule() is called inside an interrupt context.   This happens in various calls throughout the system that have to wait for things; i2c read and most probably even the write functions call schedule().  The best solution for this that I've found is to use request_threaded_irq() rather than request_irq() to init your IRQ.

The semantics of request_threaded_irq() adds a single argument, a "quick check handler" function pointer.  I suggest you write something like this for that function:

irqreturn_t qchandler(int irq, void *data)
{
        return IRQ_WAKE_THREAD;
}

This basically tells Linux to handle the IRQ in the thread no matter what.   It would be neat if we could read the status of the chip prior to running the threaded interrupt, however that's just not how the cookie crumbles.

I hope this helps

:)