<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sean McNeil wrote:
<blockquote cite="mid:48B4A7A8.6060609@mcneil.com" type="cite">
  <pre wrap="">Andy Green wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Somebody in the thread at some point said:
| This large patch removes motion sensor from Linux SPI bitbang driver.
| Previously, some access was done through Linux SPI protected
| by a mutex, and the ISR access was done by platform bitbang code due
| to inability of Linux SPI driver to work in the interrupt context.
|
| Now all access is done by bitbang callbacks in mach_gta02.c and are
| protected by single scheme of interrupt lockout for the duration --
| I line-by-line'd the driver to confirm that best I could, adding
| protection and taking more care on several /sys related paths.
|
| Because this is no longer a Linux SPI bus driver, the path for various
| /sys things have changed.  They can now be found down, eg,
|
| /sys/devices/platform/lis302dl.1/sample_rate
|
| lis302dl.1 is the top sensor and .2 the bottom.  The names of the input
| susbsytem paths remain the same as before.

I tested this for some minutes in two ssh sessions hexdumping the same
and both channels, it seems OK.  But because of the change in /sys path,
~ it feels better to get some confirmation it improves the situation
before putting people though that change on stable, so I stuck it on
andy branch right now and would appreciate some testing... it should
apply pretty well to 2.6.26 too.

-Andy
    </pre>
  </blockquote>
  <pre wrap=""><!---->I merged this into the stable 2.6.26 git and it breaks battery again :(

It also didn't solve my lockup. It took a little longer, but first
input3 stopped then input2 just as before.

There is something odd with the gpio stuff as battery was broken first
by some old cfgpin calls in the led driver. Perhaps all gpio accesses
should be made atomic if they are not already.

I'm curious why setting the pin before the cfgpin is done. This seems
counter-intuitive. If it was an input and I call set, then configure it
as an output wouldn't it just latch to what it was before the config or
is there a mux on a separate output register?</pre>
</blockquote>
<br>
Responding to myself... It must be multiplexed I guess or there would
not be any way to guarantee an immediate level without a toggle when
you switch from input to output.<br>
<br>
</body>
</html>