Touchpad testing.

[Tom Sylla]

This is what I had suspected all along, but I was hoping to get someone to
take waveforms of SERIRQ and the PS/2 line showing broken, and then proper
operation. Do you have those waveforms? Just changing settings until things
work is very dangerous. Checking them into a code tree without proper
validation is also dangerous.

Also, can you (quanta) audit the PRS? The platform designers are really the
ones who should know about the hardware, and can create recommended
settings.

Tom

On 9/21/06, Vance.Ke at quantatw.com <Vance.Ke at quantatw.com> wrote:
>
>
> We find where is the main problem. There are two MSR registers needed to
> set correctly in LinuxBIOS. One is 0x51400025 (IRQ Mapper LPC Mask) ,
> setting its value for 0x00001002 ; the other one is 0x5140004E (LPC Serial
> IRQ Control) , setting its value for 0xEFFD0080.
>
> Thanks.
>
> Best regards,
> Vance
>
> ================================================================
> -----Original Message-----
> From: devel-bounces at laptop.org [mailto:devel-bounces at laptop.org] On Behalf
> Of Tom Sylla
> Sent: Thursday, September 21, 2006 11:17 AM
> To: Mitch Bradley
> Cc: Ray Tseng (曾文瑞); devel at laptop.org; Warp at debian.org
> Subject: Re: Touchpad testing.
>
> Mitch Bradley wrote:
> > Will do.  I'm currently writing a PRS parser that will run in my diag
> > environment, so I can do PRS verification without having to install
> > giant wads o' TCL.
>
> Ah, people aren't understanding the PRS parser. You run it in FS2. You
> don't need wads of TCL, it comes with your FS2 installation.
>
> In FS2:
>    source PRSCheck.tcl
>
> and have the prs file in the same dir, and it will run. It reads the
> MSRs, I/Os, etc through JTAG, and checks them. The PRS is always going
> to be very dependent on where the thing is run, so porting it to a
> different environment is usually a bad idea. Part of the OLPC PRS
> process has to include at what point in the boot to run the PRS.
>
>
> > Will a complete PRS scan cover the SERIRQ settings?
>
> The utility of the PRS is only as good as the quality of the input file.
> The LPC section is probably very much wrong, since the specs were not
> available, and even now that they are, there will probably still need to
> be some reverse engineering of the way the IRQs work.
>
>
> >
> > Tom Sylla wrote:
> >> look at SERIRQ. It will probably be in continuous mode, where it
> >> shouldn't be or the polarity settings will be wrong. None of the EC
> >> init is being done, there is no "super I/O" configured into LB. The
> >> 5536 config is a best guess back when the EC spec was not available,
> >> so that is probably wrong too. If you look at the PS/2 and SERIRQ at
> >> the same time, the answer will just fall out.
> >>
> >> Mitch Bradley wrote:
> >>> These pictures show what happens on the OLPC board when you
> >>>
> >>> a) Don't drain the queue (QueueHoldoff.png)
> >>> b) Drain the queue every so often (RateControl.png)
> >>>
> >>> Conclusion: the EC is able to handle normal-rate mouse reports when
> the
> >>> software services it at the correct rate.
> >>
> >
> >
>
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20060921/fe934c7f/attachment.html>