EC

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?

Thanks,
Shaohua

Re: EC

[Alexey Starikovskiy]

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 platform and what other symptoms do you have? How exactly this EC is broken?

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

RE: EC

[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.

>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.

Thanks,
Shaohua

Re: EC

[Alexey Starikovskiy]

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

RE: EC

[Li, Shaohua]

>>> 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.
They said if burst timeout, then a GPE will fire. OS should check the burst bit in status reg to know if EC is in burst mode. If not, os might reissue burst enable as a retry.

They don't have any document to share with us. If you have other questions, please let me know, but please give detail questions so I can forward them to EC firmware engineer. This is a good chance for us to make EC better. 

Thanks,
Shaohua

Re: EC

[Alexey Starikovskiy]

Li, Shaohua пишет:
> They said if burst timeout, then a GPE will fire. OS should check the burst bit in status reg to know if EC is in burst mode. If not, os might reissue burst enable as a retry.
The main question is, in case of the burst timeout, do they abort read/write transaction they happen to be in?
> 
> They don't have any document to share with us. If you have other questions, please let me know, but please give detail questions so I can forward them to EC firmware engineer. This is a good chance for us to make EC better. 
Is there any circumstance when they can start GPE storm?


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

RE: EC

[Li, Shaohua]

Alex,
I got some reply, please let me know if you have other questions:
1. On burst timeout:
A: the driver should send optional ACPI Normal mode (Disable burst) command and then send the burst enable command followed by the read/write

2. if burst timeout, does EC firmware abort current read/write transaction?
A: Yes. If the timeout occurs before KSC receives the command and all the data bytes, EC aborts the transaction and goes back to normal mode.

3. what's the difference between burst mode and non-burst mode from the EC firmware point of view?
A: In burst mode, EC goes into a special mode where it disables interrupts and running all the tasks except responding to OSPM commands.

4. EC doesn't allow us to clean up GPE status bit, as soon as we set enable bit (at the end of interrupt handler), it fires new interrupt, how to avoid such case? We saw EC interrupt storm in a lot of systems.
A: EC generates SCI for every OBF or IBF. It also generates SCI even when EC disengage the burst. The driver should check the BURST_MODE bit in STATUS register on every SCI to see if it is in burst mode or not.