Re: [PATCH 00/15] atmel_mxt_ts - device tree, bootloader, etc

[Nick Dyer]

On 07/07/14 12:21, Sekhar Nori wrote:
> I was unable to get the touchscreen working on my board after applying 
> just these patches. It does work correctly with your for-next branch so 
> I guess I need to wait for you to post the rest of your patches too.
> 
> Here are the relevant messages at boot. Full boot log is available here 
> (in case you want to have a look): http://paste.ubuntu.com/7759703/
> 
> [    2.315717] atmel_mxt_ts 0-004a: Direct firmware load failed with error -2
> [    2.322949] atmel_mxt_ts 0-004a: Falling back to user helper
> [    5.934924] atmel_mxt_ts 0-004a: Wait for completion timed out.
> [    5.941237] atmel_mxt_ts 0-004a: Warning: Info CRC error - device=0x000000 file=0x8EE45C
> [    7.294769] atmel_mxt_ts 0-004a: Wait for completion timed out.
> [    7.300976] atmel_mxt_ts 0-004a: Resetting chip
> [   10.574729] atmel_mxt_ts 0-004a: Wait for completion timed out.
> [   10.581010] atmel_mxt_ts 0-004a: Error -110 updating config
> [   10.626788] atmel_mxt_ts 0-004a: Family: 128 Variant: 1 Firmware V1.6.AB Objects: 17
> 
> One key difference is that these patches try to load the config at 
> probe where as with your -next branch that is avoided in the DT case. 
> This is also missing the new update_cfg sysfs interface (which I guess 
> you will post as follow-on patches).
> 
> The wait_for_completion() times out because the interrupt never 
> arrives. Even later when testing using evtest, I do not see interrupts 
> coming. There are only two interrupts that arrive during boot and it 
> stays that way. There is something going on with the way interrupts are 
> handled. I havent debugged further yet. This problem is not there with 
> your for-next branch.

Thanks for trying this, apologies that it didn't work.

Looking at it, I've a feeling that this is the solution for the issue you see:
https://github.com/ndyer/linux/commit/4e8f8d56361b09a2a

Although, the fact that it says the device is reporting the Info CRC to be
0x000000 is rather odd, as well.

It would be useful if you could turn on all the debug in the driver and
re-test (#define DEBUG 1 at the top). However, if you don't have time, I
will try and reproduce on my test system.

cheers

Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/