[PATCH/RFC] Change accelerometers to use ABS events rather than REL events.

Neil Brown neilb at suse.de
Fri Mar 13 01:00:41 CET 2009


On Wednesday March 11, andy at 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



More information about the openmoko-kernel mailing list