From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Torokhov Subject: Re: [PATCH] Don't disable interrupts during EC access Date: Wed, 17 Nov 2004 02:58:23 -0500 Message-ID: <200411170258.23552.dtor_core@ameritech.net> References: <16A54BF5D6E14E4D916CE26C9AD305758EF9BD@pdsmsx402.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <16A54BF5D6E14E4D916CE26C9AD305758EF9BD-4yWAQGcml66iAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org> Content-Disposition: inline Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: "Li, Shaohua" Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Andi Kleen , "Yu, Luming" , Matthew Wilcox , "Fu, Michael" , "Brown, Len" , "Moore, Robert" List-Id: linux-acpi@vger.kernel.org On Wednesday 17 November 2004 02:10 am, Li, Shaohua wrote: > >On Tuesday 16 November 2004 10:37 am, Andi Kleen wrote: > >> > For detail, please refer to ACPI spec : > >> > 12 ? ACPI Embedded Controller Interface Specification. > >> > >> Ok. But the problem is not the actual write, but the waiting > >> for the event which takes extremly long on these machines > >> (it's not a single broken machine, but has been observed > >> on several VIA based laptops). Would it work to only disable > >> interrupts during the register write/read, but not during the > >> polling delay? > > > >Actually, the proper solution would be to get rid of polling entirely, > >like in the patch below. Could anyone with a box with EC verify that > >it works? > > > >Btw, what's up with initializing every variable in ACPI code? It is > >not free after all... > > > I agree the right solution should be to stop polling, but did you look > at the comments in ec.c (line 361)? It said some systems can't work with > asynchronous mode. > Hmm... Let's see. We can only have 1 reader/writer active at the same time per EC becuase they are serialized via ec->sem. So the only thing we can race with is SCI generated by firmware in response to external factors. So I guess we still need sleep-polling in acpi_ec_query_data, something like this: while (unlikely(down_trylock(&ec->sem))) { /* reader or writer is waiting for completion */ value = acpi_ec_read_status(ec); if ((value & ACPI_EC_FLAG_OBF) || (ec->expect_ibe && !(value & ACPI_EC_FLAG_IBF))) { ec->expect_ibe = 0; wake_up(&ec->wait); } msleep(1); } acpi_hw_low_level_write(8, ACPI_EC_COMMAND_QUERY, &ec->command_addr); result = acpi_ec_wait_obf(ec); if (result < 0) goto end; ..... Will this work? -- Dmitry ------------------------------------------------------- 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