Touch Screen not working and PMIC Event Thread not running

[rb_ontario]

Hello,

I have a iMX53 QSB (-R) running Linux (2.6.35).  We have developed our own GUI application and it runs fine on the QSB.

We have also developed our own hardware and are trying to get the application to run on it. The problem is that the touch screen is not working when we run the application on our hardware.

Both boards use the MC34708 PMIC

I have confirmed that the I2C 0 seems to be working by running I2Cdetect.  The PMIC shows up at address 0x08 as expected on both board. (our own and the QSB).  However, when we touch the screen on our hardware, no activity to read the screen is observed on the I2C.   On the QSB, lots of activity occurs when the screen is touched.

I compared the active processes and noticed that a process named "pmic-even-thre" is running on the QSB but not on our hardware.  However, we are using the SAME micoSD card and swapping between the QSB and our own hardware to run these tests.

When I run i2cdump, or i2c get on our hardware, I get get the register data from the PMIC.  However, when I try to run it on the QSB, it says "Device or resource busy".  From reading the forums, this would occur if another driver is accessing the device while you're trying to run i2cdump.

My question is:  What would prevent the pmic-event-thre process from starting up on our hardware?  Is there some way to attempt to manually run it?  Is it necessary to set some environment variables in order to get this process to run? 

[HuiShao]

My custom board needs some generic ADC inputs, does anyone know if current PMIC ADC driver is able to do that? If not, how to complete it?

thanks in advance!

[HuiShao]

I don't see wait_for_interrupt function call in mc34708_adc.c, but rather see wait_for_completion_interruptible, am I using a different versino of ADC driver?

thanks!

Hui

[JianqingChen]

The reasons are two: 1.MC34708 the I2C instability caused I2C occupied, it is recommended to use the MC34708 the SPI. 2.In pmic-adc driver, replace wait_for_interrupt function for wait_for_interrupt_timeout function

[rb_ontario]

Update - U-boot checks the status off IIM fuses in the iMX53 processor to determine the hardware level.  Specifically it looks at the value of the fuse at offset 0x878.  If the value is 0x3, then the hardware is version B.  It it detects 0x1 or anything else, then the hardware is assumed to be version A.   Since I had not set this fuse, it was causing the wrong hardware version to be set.  This caused the wrong PMIC driver to be loaded and that in turn prevented the AtoD for the touch screen from working.

To set the fuse in u-boot, I had to enter "iim blow 0 30 3" (without quotes)

[rb_ontario]

Update - I logged the boot messages and noted that on the QSB the MC34708 is detected correctly and all the voltages are reported.   However, on our own hardware, the boot message shows that the da9052 is being detected (incorrect).  Our hardware does in fact have the MC34708 on.   I know that some of the older kernel version would not detect the MC34708.  However, we're running the same software on both board.   How could the software incorrectly detect the da9052?