On Wednesday March 11, a...@openmoko.com wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Somebody in the thread at some point said: > > |> Either disabling one interrupt or having them both issue the same is a > |> valid solution to A5 situation. On A6, we removed the pullup and have > |> the one interrupt drive push-pull. > | > | It's not clear to me that 'disabling' is an option. > | The closest seems to be a setting called "GND" which presumably ties > | the line to Ground. Seeing the interrupt is active-low, that would be > | permanently asserted? > > You can select it to drive a source that is disabled from ever > happening, obviously it's simpler to just get them to drive the same > source in lockstep.
OK, I understand. Thanks. > > | For wake-from-suspend we cannot do any tricks with polling. We have > | to choose between wake-on-WUP_FF, or wake-on-CLICK. > | Fortunately there are two accelerometers so we can get all the > | functionality we are likely to want: > > Well, there is one more version-and-cpu-related quirk. > > On GTA02 A5, the INT1+INT2 net for the second accelerometer ends up on > EINT16 / GPG8. Unfortunately on S3C2442, only EINT0-15 are usable as > wake sources. > > On GTA02 A6+, we tried to fix this by bringing a copy of this interrupt > signal to EINT8 / GPG0 which is a wake source. But, we stuck R1547 in > the way which is marked as NC on the schematic version I am looking at. > ~ Presumably it really isn't fitted breaking this fix. > > So only one accelerometer works for wake. :-( Two follow-up questions. 1/ Is it possible to deduce whether the device can effect a wakeup from the platform_data? Maybe a range check on ->interrupt?? Alternately, and preferably, could this be included explicitly in the platform_data? 2/ # cat /sys/class/i2c-adapter/i2c-0/0-0073/neo1973-resume.0/resume_reason EINT00_ACCEL1 EINT01_GSM EINT02_BLUETOOTH EINT03_DEBUGBRD EINT04_JACK EINT05_WLAN EINT06_AUXKEY EINT07_HOLDKEY EINT08_ACCEL2 * EINT09_PMU EINT10_NULL EINT11_NULL EINT12_GLAMO EINT13_NULL EINT14_NULL EINT15_NULL (This in on a 'v5'). So ACCEL2 is listed on EINT_08, If it isn't really there we should fix that output. And the AUXKEY is listed there, but the AUX key doesn't cause a wakeup, and I vaguely remember reading some mail months ago which said that it cannot cause a wakeup. So should that be fixed too? > > | When the CPU is running we could take the same approach. Or we could > | conceivably program WUP_FF_2 to have the same threshold as the first > | click threshold. Then when it fires, set a timer for an appropriate > | duration and poll the 'click' status after that duration. > | It might not be worth the effort though. > > Not sure if or how the highpass filter can fit in there to allow > threshold to wake on tap or shake. I'm hoping that the click threshold is measured after the high pass filter, other wise we would need to reprogram the thresholds every time the device is re-oriented. I haven't found any doco which is explicit on this point. I'm going to need to experiment. Thanks, NeilBrown
