hi wad -- this sounds fine, and makes sense. given the extra complication this will entail, current plan is to attempt to do everything via ACPI, but this backup is a good thing.
paul john wrote: > > Paul, > Having discovered problems with our previously proposed > method of co-generating interrupts on the host, tonight's installment > details a work around restoring a second interrupt line from the EC > to the VX855 (eliminated earlier in the design, and incorrectly > implemented > then anyway.). > > In a previous episode: > The embedded controller (EC) in the laptop communicates a bunch of stuff > to the "host" processor. It does this through some ports on the I/O > bus and > and interrupt wire to the host. Our intrepid code hacker pgf > proposed that > it would be much easier to support many of the cool features we support > through this EC communciations channel (lid switches, EB mode switches, > gamepad and rotate button presses, etc.) would be easier to support if > we had a separate virtual communications channel with the EC. This > channel would have an interrupt handler which wasn't in the ACPI code. > > Fine, we'll just wire the EC interrupt to another convenient > interrupt input > on the VX855. That input turned out to have complicated issues with > it's > parents, and couldn't be used. The only "available" inputs are also > used > to set chip options at "power-on", which is every resume. As the EC > interrupt > is frequently asserted at power-up, it would screw up these key > initializations. > > Current proposal: > We will provide a second interrupt from the EC to the host. This > interrupt > will go through an input which isn't "owned" by ACPI. This > interrupt will > not be asserted unless the system is running (S0). > This interrupt will not be able to "wake" the system, although the EC > may preceed it with an SCI interrupt to wake the system. > > This allows this second interrupt to now use one of the available > inputs. > One slight hitch is that the host control of the WLAN LED will be > bumped. > This will now be driven solely from the WLAN module as in XO-1. > > New GPIO mappings are attached. > > Cheers, > wad > > part 5 text/plain 2 > > =--------------------- paul fox, p...@laptop.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
