RE: [ACPI] [PATCH] Don't disable interrupts during EC access

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

  I forget one thing that could make me feel frustrated.
  There is a user outside of ACPI driver, that is sonypi_ec_read,
which can be invoked by sonypi_misc_ioctl, which haven't
disable EC-GPE. :-)
  If everything is handled by kacpid. I even think semaphore
is also unnecessary. Because every thing is run in the order
of a queue. :-)

Thanks
Luming=20

>-----Original Message-----
>From: acp...@li...=20
>[mailto:acp...@li...] On Behalf Of Yu, Luming
>Sent: 2004=C4=EA11=D4=C216=C8=D5 23:21
>To: Andi Kleen; Matthew Wilcox
>Cc: acp...@li...; Fu, Michael; Brown, Len;=20
>Moore, Robert
>Subject: RE: [ACPI] [PATCH] Don't disable interrupts during EC access
>
>>On Tue, Nov 16, 2004 at 12:16:16PM +0000, Matthew Wilcox wrote:
>>> On Tue, Nov 16, 2004 at 02:15:47PM +0800, Yu, Luming wrote:
>>> > Andi,
>>> >=20
>>> > This patch seems to break the atomic operation.
>>> > The original code enclosed by=20
>>spin_lock_irqsave/spin_unlock_irqresotre is trying to make=20
>>sure the first operation to EC_COMMAND
>>> > register , and the second operation to EC_DATA register=20
>>belong to one atomic transaction.
>>>=20
>>> Why would converting from a spinlock to a semaphore break this?
>>
>>As Willy said the operation should be still atomic in respect to
>>the register.
>
>It is just due to odd hardware behavior.  :-)
>For example, if you want to read data from EC.  The first step
>is writing 0x80 (read command) to ec command register.
>Then, if EC (hardware) write data into the output buffer, the
>output buffer flag (OBF) in the status register is set.
>(I assume it is within 1ms). According to ACPI spec,
>now, EC interrupt will get triggered. And this is
>firmware generated edge interrupt. It will hold until OBF get reset.
>When the host processor reads this data from the output buffer,=20
>the OBF can be reset.
>
>So, if you remove the spin_lock_irqsave, when OBF is set
>you could get interrupt storm. =20
>
>For detail, please refer to ACPI spec :
>12   ACPI Embedded Controller Interface Specification.
>
>>
>>And the event polling can take several ms, there is just no way=20
>>to do this during runtime with interrupts off. Especially since
>>thermal will do this every few seconds. With my patch at least=20
>>only kacpid is blocked for that long, not the whole system.
>>
>>-Andi
>>
>
>As for thermal event, AFAIK,  not all laptops use EC to=20
>generate thermal
>event. And I'm thinking of a algorithm.
>
>  There is a issue of kacpid consuming a lot of CPU time, which should=20
>be due to GPEs keep firing without any control. Current GPE handling
>just
>re-enable GPEs after handling GPEs without considering any semantics=20
>conveyed by that GPE.  For example,  some laptop could keep generating=20
>thermal GPE interrupt, if temperature is above a threshold. All these
>thermal events
>is just telling OS one thing, that is "temperature is above a specific
>threshold,
> please turn on cooling methods ...." .  Maybe this is platform issue,
> but driver  should handle this case smoothly.
>=20
>http://bugme.osdl.org/show_bug.cgi?id=3D3686
>=20
>
>Thanks
>Luming
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: InterSystems CACHE
>FREE OODBMS DOWNLOAD - A multidimensional database that combines
>robust object and relational technologies, making it a perfect match
>for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
>_______________________________________________
>Acpi-devel mailing list
>Acp...@li...
>https://lists.sourceforge.net/lists/listinfo/acpi-devel
>