From: Alexey Starikovskiy <astarikovskiy@suse.de>
To: "Li, Shaohua" <shaohua.li@intel.com>
Cc: "lenb@kernel.org" <lenb@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: EC
Date: Thu, 02 Jul 2009 11:45:13 +0400 [thread overview]
Message-ID: <4A4C6589.4070108@suse.de> (raw)
In-Reply-To: <76780B19A496DC4B80439008DAD7076C03453A5CB9@PDSMSX501.ccr.corp.intel.com>
Li, Shaohua пишет:
>
>> -----Original Message-----
>> From: Alexey Starikovskiy [mailto:astarikovskiy@suse.de]
>> Sent: Thursday, July 02, 2009 2:21 PM
>> To: Li, Shaohua
>> Cc: lenb@kernel.org; linux-acpi@vger.kernel.org
>> Subject: Re: EC
>>
>> Li, Shaohua пишет:
>>> Hi,
>>> Preempt isn't disabled between ec_burst_enable()/ec_burst_disable(), so
>> it's very likely there is a preemption between them and make the timing
>> for burst mode not comply with ACPI spec (400ms for first access and 50ms
>> for subsequent access).
>>> We have a system with broken EC and the BIOS engineer identified it's
>> the timing issue.
>>> What's the judgment why Linux doesn't comply with ACPI spec?
>> Please disable ec_burst_* and check again. Judgement is that ec_burst_* is
>> irrelevant to the protocol.
> What did you about 'irrelevant to the protocol'? This is what the spec defines.
I mean, that EC may drop out of burst mode if timeout happens, and it should not change
the flow of reads and writes to EC (the protocol). More, EC should work properly even if
we do not enter burst mode at all (my suggestion to disable calls to burst functions).
>
>> What platform and what other symptoms do you have? How exactly this EC is
>> broken?
> The temperature is wrong when we get it from reading EC. The BIOS engineer measured
> A lot of EC timeout in EC firmware, and they measured the timing how Linux accesses
> EC. The data they captured in oscilloscope shows Linux has long delay to access
> Ec with burst mode enabled, this occurs more often when another application is running.
Do they have any document about implemented EC timeouts? State diagram? Other than burst timeout, do they have any other timeouts? What happens if they get timeout, do they abort transaction? What do they write in status register?
Do they send GPE? Please collect as much as you can, I was looking for such info for a very long time.
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-07-02 7:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 5:42 EC Li, Shaohua
2009-07-02 6:20 ` EC Alexey Starikovskiy
2009-07-02 7:34 ` EC Li, Shaohua
2009-07-02 7:45 ` Alexey Starikovskiy [this message]
2009-07-03 1:44 ` EC Li, Shaohua
2009-07-03 2:28 ` EC Alexey Starikovskiy
2009-07-07 1:21 ` EC Li, Shaohua
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A4C6589.4070108@suse.de \
--to=astarikovskiy@suse.de \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=shaohua.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox