From: Jean Delvare <khali@linux-fr.org> To: Richard Voigt <richardvoigt@gmail.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org>, Pavel Machek <pavel@ucw.cz>, Chuck Ebbert <cebbert@redhat.com>, Rudolf Marek <r.marek@assembler.cz>, linux-acpi@vger.kernel.org, linux-kernel <linux-kernel@vger.kernel.org>, lm-sensors@lm-sensors.org Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? Date: Mon, 19 Mar 2007 08:08:49 +0100 [thread overview] Message-ID: <20070319080849.17ecf173.khali@linux-fr.org> (raw) In-Reply-To: <2e59e6970703181236l3f92f105je522f2966ffb0a39@mail.gmail.com> Hi Richard, On Sun, 18 Mar 2007 14:36:08 -0500, Richard Voigt wrote: > On 3/3/07, Jean Delvare wrote: > > On Fri, 2 Mar 2007 21:12:51 +0000, Matthew Garrett wrote: > > > Assuming arbitration of access, what's the problem with having two > > > drivers accessing the same hardware? Do these chips generally have any > > > significant internal state other than trip points and the like? > > > > The "assuming arbitration of access" is the key part of your > > sentence ;) The problem is that currently no arbitration is done. If it > > was done, then state would probably not be a problem. Most hardware > > monitoring drivers don't assume any state is preserved between > > accesses, and those which do can easily be changed not to. The ACPI > > side is another story though, I guess we can't assume anything about > > the AML code's assumption on states, as it differs from one machine to > > the next. But we can try to be cooperative and restore the sensible > > registers (e.g. bank selector) in the same state we found them. > > I recall that one of the stated drawbacks of a lock was that no ACPI > code could execute while the hwmon driver was doing its fairly lengthy > conversation with the hardware. > > It seems that using transactional concepts here would solve that > problem. For example, the hwmon driver issues a start transaction > request. The first write request to any given location (bank register > for example) causes the previous memory value to be saved. Then, > instead of locking AML out, AML is allowed to execute, but any access > to the memory/port ranges reserved by the driver (when the transaction > is set up) cause the hwmon transaction to be rolled back so the AML > sees the expected state. Then AML proceeds as usual. When hwmon > tries additional operations, they fail with some "transaction > interrupted" error message, indicating to the hwmon driver to start > over. > > The only issue with this that I can see, is that if AML isn't > executed atomically wrt hwmon, then knowing when it is safe for hwmon > to retry is going to be difficult. No. We're not rolling back anything, it's totally unrealistic. These are device drivers we're talking about here, not a database. The I/O accesses done by the hardware monitoring drivers are not that long, so AML gets to wait for them to be finished, and that's it. There is no valid reason to give the priority to AML over regular device drivers. Rudolf Marek's approach sounds much better. > This probably requires changes to every hwmon driver, but they can be > updated piecemeal, starting with the ones most commonly found in > notebooks, where ACPI is most important. Most notebooks don't expose their hardware monitoring chip at all. Those which do use SMBus devices in majority, where I/O forwarding is going to be difficult, as it needs to be done at the SMBus controller level, not the hardware monitoring device level. I want to get my hands on such a laptop first though, as I need to see what exacly ACPI is doing before I can think of a solution. -- Jean Delvare
WARNING: multiple messages have this Message-ID (diff)
From: khali@linux-fr.org (Jean Delvare) To: Richard Voigt <richardvoigt@gmail.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org>, Pavel Machek <pavel@ucw.cz>, Chuck Ebbert <cebbert@redhat.com>, Rudolf Marek <r.marek@assembler.cz>, linux-acpi@vger.kernel.org, linux-kernel <linux-kernel@vger.kernel.org>, lm-sensors@lm-sensors.org Subject: [lm-sensors] Could the k8temp driver be interfering with ACPI? Date: Mon, 19 Mar 2007 07:08:49 +0000 [thread overview] Message-ID: <20070319080849.17ecf173.khali@linux-fr.org> (raw) In-Reply-To: <2e59e6970703181236l3f92f105je522f2966ffb0a39@mail.gmail.com> Hi Richard, On Sun, 18 Mar 2007 14:36:08 -0500, Richard Voigt wrote: > On 3/3/07, Jean Delvare wrote: > > On Fri, 2 Mar 2007 21:12:51 +0000, Matthew Garrett wrote: > > > Assuming arbitration of access, what's the problem with having two > > > drivers accessing the same hardware? Do these chips generally have any > > > significant internal state other than trip points and the like? > > > > The "assuming arbitration of access" is the key part of your > > sentence ;) The problem is that currently no arbitration is done. If it > > was done, then state would probably not be a problem. Most hardware > > monitoring drivers don't assume any state is preserved between > > accesses, and those which do can easily be changed not to. The ACPI > > side is another story though, I guess we can't assume anything about > > the AML code's assumption on states, as it differs from one machine to > > the next. But we can try to be cooperative and restore the sensible > > registers (e.g. bank selector) in the same state we found them. > > I recall that one of the stated drawbacks of a lock was that no ACPI > code could execute while the hwmon driver was doing its fairly lengthy > conversation with the hardware. > > It seems that using transactional concepts here would solve that > problem. For example, the hwmon driver issues a start transaction > request. The first write request to any given location (bank register > for example) causes the previous memory value to be saved. Then, > instead of locking AML out, AML is allowed to execute, but any access > to the memory/port ranges reserved by the driver (when the transaction > is set up) cause the hwmon transaction to be rolled back so the AML > sees the expected state. Then AML proceeds as usual. When hwmon > tries additional operations, they fail with some "transaction > interrupted" error message, indicating to the hwmon driver to start > over. > > The only issue with this that I can see, is that if AML isn't > executed atomically wrt hwmon, then knowing when it is safe for hwmon > to retry is going to be difficult. No. We're not rolling back anything, it's totally unrealistic. These are device drivers we're talking about here, not a database. The I/O accesses done by the hardware monitoring drivers are not that long, so AML gets to wait for them to be finished, and that's it. There is no valid reason to give the priority to AML over regular device drivers. Rudolf Marek's approach sounds much better. > This probably requires changes to every hwmon driver, but they can be > updated piecemeal, starting with the ones most commonly found in > notebooks, where ACPI is most important. Most notebooks don't expose their hardware monitoring chip at all. Those which do use SMBus devices in majority, where I/O forwarding is going to be difficult, as it needs to be done at the SMBus controller level, not the hardware monitoring device level. I want to get my hands on such a laptop first though, as I need to see what exacly ACPI is doing before I can think of a solution. -- Jean Delvare
next prev parent reply other threads:[~2007-03-19 7:09 UTC|newest] Thread overview: 220+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-02-16 17:31 Could the k8temp driver be interfering with ACPI? Chuck Ebbert 2007-02-16 17:31 ` [lm-sensors] " Chuck Ebbert 2007-02-16 17:57 ` Len Brown 2007-02-16 17:57 ` [lm-sensors] " Len Brown 2007-02-16 18:14 ` Chuck Ebbert 2007-02-16 18:14 ` [lm-sensors] " Chuck Ebbert 2007-02-16 19:59 ` Andi Kleen 2007-02-16 19:59 ` [lm-sensors] " Andi Kleen 2007-02-16 19:31 ` Chuck Ebbert 2007-02-16 19:31 ` [lm-sensors] " Chuck Ebbert 2007-02-18 17:32 ` Jean Delvare 2007-02-18 17:32 ` Jean Delvare 2007-02-18 23:22 ` Andi Kleen 2007-02-18 23:22 ` Andi Kleen 2007-02-17 10:49 ` Rudolf Marek 2007-02-17 10:49 ` [lm-sensors] " Rudolf Marek 2007-02-17 10:49 ` Rudolf Marek 2007-02-17 18:14 ` Chuck Ebbert 2007-02-17 18:14 ` Chuck Ebbert 2007-02-18 17:38 ` Jean Delvare 2007-02-18 17:38 ` Jean Delvare 2007-02-20 15:18 ` Matthew Garrett 2007-02-20 15:18 ` Matthew Garrett 2007-02-20 15:33 ` Luca Tettamanti 2007-02-20 15:33 ` Luca Tettamanti 2007-02-21 14:59 ` Jean Delvare 2007-02-21 14:59 ` Jean Delvare 2007-02-21 15:07 ` Jean Delvare 2007-02-21 15:07 ` Jean Delvare 2007-02-28 21:38 ` Pavel Machek 2007-02-28 21:38 ` Pavel Machek 2007-03-01 14:26 ` Jean Delvare 2007-03-01 14:26 ` [lm-sensors] " Jean Delvare 2007-03-01 14:26 ` Jean Delvare 2007-03-01 17:48 ` Dave Jones 2007-03-01 17:48 ` Dave Jones 2007-03-02 11:27 ` Jean Delvare 2007-03-02 11:27 ` Jean Delvare 2007-03-02 11:31 ` Pavel Machek 2007-03-02 11:31 ` Pavel Machek 2007-03-02 13:37 ` Jean Delvare 2007-03-02 13:37 ` Jean Delvare 2007-03-02 13:47 ` Henrique de Moraes Holschuh 2007-03-02 13:47 ` Henrique de Moraes Holschuh 2007-03-02 13:57 ` Pavel Machek 2007-03-02 13:57 ` Pavel Machek 2007-03-03 6:44 ` Jean Delvare 2007-03-03 6:44 ` Jean Delvare 2007-03-02 11:40 ` Pavel Machek 2007-03-02 11:40 ` Pavel Machek 2007-03-02 11:47 ` Matthew Garrett 2007-03-02 11:47 ` Matthew Garrett 2007-03-02 13:58 ` Pavel Machek 2007-03-02 13:58 ` Pavel Machek 2007-03-02 21:00 ` Jean Delvare 2007-03-02 21:00 ` Jean Delvare 2007-03-02 21:22 ` Henrique de Moraes Holschuh 2007-03-02 21:22 ` Henrique de Moraes Holschuh 2007-04-01 15:39 ` Pavel Machek 2007-04-01 15:39 ` Pavel Machek 2007-04-02 15:48 ` Jean Delvare 2007-04-02 15:48 ` [lm-sensors] " Jean Delvare 2007-04-02 19:22 ` Dave Jones 2007-04-02 19:22 ` [lm-sensors] " Dave Jones 2007-04-03 5:49 ` Jean Delvare 2007-04-03 5:49 ` [lm-sensors] " Jean Delvare 2007-04-02 20:55 ` Moore, Robert 2007-04-02 20:55 ` [lm-sensors] " Moore, Robert 2007-04-02 20:55 ` Moore, Robert 2007-04-03 7:21 ` Jean Delvare 2007-04-03 7:21 ` [lm-sensors] " Jean Delvare 2007-04-03 7:21 ` Jean Delvare 2007-04-04 21:35 ` Moore, Robert 2007-04-04 21:35 ` [lm-sensors] " Moore, Robert 2007-04-04 21:35 ` Moore, Robert 2007-03-02 14:10 ` [lm-sensors] " Jean Delvare 2007-03-02 14:10 ` Jean Delvare 2007-03-02 14:18 ` Matthew Garrett 2007-03-02 14:18 ` Matthew Garrett 2007-03-02 21:04 ` Jean Delvare 2007-03-02 21:04 ` Jean Delvare 2007-03-02 21:12 ` Matthew Garrett 2007-03-02 21:12 ` Matthew Garrett 2007-03-03 9:53 ` Jean Delvare 2007-03-03 9:53 ` Jean Delvare 2007-03-03 15:47 ` David Hubbard 2007-03-03 15:47 ` David Hubbard 2007-03-03 15:50 ` Matthew Garrett 2007-03-03 15:50 ` Matthew Garrett 2007-03-03 17:08 ` Rudolf Marek 2007-03-03 17:08 ` Rudolf Marek 2007-03-04 17:29 ` Rudolf Marek 2007-03-04 17:29 ` Rudolf Marek 2007-03-05 21:16 ` Jean Delvare 2007-03-05 21:16 ` Jean Delvare 2007-03-05 21:35 ` David Hubbard 2007-03-05 21:35 ` David Hubbard 2007-03-06 15:10 ` Jean Delvare 2007-03-06 15:10 ` Jean Delvare 2007-03-04 10:54 ` Jean Delvare 2007-03-04 10:54 ` Jean Delvare 2007-03-05 22:25 ` Pavel Machek 2007-03-05 22:25 ` Pavel Machek 2007-03-06 7:55 ` Benny Amorsen 2007-03-06 7:55 ` Benny Amorsen 2007-03-06 15:26 ` Jean Delvare 2007-03-06 15:26 ` Jean Delvare 2007-03-06 20:07 ` Stefan Monnier 2007-03-06 20:07 ` Stefan Monnier 2007-03-06 20:07 ` Stefan Monnier 2007-03-06 21:20 ` Pavel Machek 2007-03-06 21:20 ` Pavel Machek 2007-03-06 21:25 ` Moore, Robert 2007-03-06 21:25 ` Moore, Robert 2007-03-06 21:25 ` Moore, Robert 2007-03-18 19:36 ` richardvoigt 2007-03-18 19:36 ` richardvoigt at gmail.com 2007-03-19 7:08 ` Jean Delvare [this message] 2007-03-19 7:08 ` Jean Delvare 2007-03-02 22:07 ` Moore, Robert 2007-03-02 22:07 ` Moore, Robert 2007-03-02 22:07 ` Moore, Robert 2007-03-09 7:18 ` Pavel Machek 2007-03-09 7:18 ` Pavel Machek 2007-03-09 10:24 ` Jean Delvare 2007-03-09 10:24 ` Jean Delvare 2007-03-09 10:39 ` Alexey Starikovskiy 2007-03-09 10:39 ` Alexey Starikovskiy 2007-03-09 11:21 ` Pavel Machek 2007-03-09 11:21 ` Pavel Machek 2007-03-09 17:23 ` Jean Delvare 2007-03-09 17:23 ` Jean Delvare 2007-03-09 17:35 ` Alexey Starikovskiy 2007-03-09 17:35 ` Alexey Starikovskiy 2007-03-09 21:03 ` Moore, Robert 2007-03-09 21:03 ` Moore, Robert 2007-03-09 21:03 ` Moore, Robert 2007-03-09 20:56 ` Moore, Robert 2007-03-09 20:56 ` Moore, Robert 2007-03-09 20:56 ` Moore, Robert 2007-03-02 14:22 ` Pavel Machek 2007-03-02 14:22 ` Pavel Machek 2007-03-02 14:03 ` Jean Delvare 2007-03-02 14:03 ` Jean Delvare 2007-03-02 14:24 ` Pavel Machek 2007-03-02 14:24 ` Pavel Machek 2007-03-02 14:57 ` Matthew Garrett 2007-03-02 14:57 ` Matthew Garrett 2007-03-02 21:41 ` Jean Delvare 2007-03-02 21:41 ` Jean Delvare 2007-03-02 21:46 ` Matthew Garrett 2007-03-02 21:46 ` Matthew Garrett 2007-03-06 21:28 ` Jean Delvare 2007-03-06 21:28 ` Jean Delvare 2007-04-13 18:18 ` Bjorn Helgaas 2007-04-13 18:18 ` Bjorn Helgaas 2007-04-13 20:07 ` Pavel Machek 2007-04-13 20:07 ` Pavel Machek 2007-04-13 20:59 ` Bjorn Helgaas 2007-04-13 20:59 ` Bjorn Helgaas 2007-04-15 9:41 ` Jean Delvare 2007-04-15 9:41 ` Jean Delvare 2007-04-15 20:31 ` Bjorn Helgaas 2007-04-15 20:31 ` Bjorn Helgaas 2007-04-15 20:59 ` Luca Tettamanti 2007-04-15 20:59 ` Luca Tettamanti 2007-04-16 0:57 ` Bjorn Helgaas 2007-04-16 0:57 ` Bjorn Helgaas 2007-04-16 21:14 ` Luca Tettamanti 2007-04-16 21:14 ` Luca Tettamanti 2007-04-16 22:28 ` Bjorn Helgaas 2007-04-16 22:28 ` Bjorn Helgaas 2007-04-17 23:50 ` Luca Tettamanti 2007-04-17 23:50 ` Luca Tettamanti 2007-04-22 16:55 ` Luca Tettamanti 2007-04-22 16:55 ` Luca Tettamanti 2007-04-17 10:03 ` Jean Delvare 2007-04-17 10:03 ` Jean Delvare 2007-02-18 22:43 ` Rudolf Marek 2007-02-18 22:43 ` Rudolf Marek 2007-02-20 15:08 ` Chuck Ebbert 2007-02-20 15:08 ` Chuck Ebbert 2007-02-20 19:11 ` Dave Jones 2007-02-20 19:11 ` Dave Jones 2007-02-21 16:17 ` Jean Delvare 2007-02-21 16:17 ` Jean Delvare 2007-02-21 17:37 ` Dave Jones 2007-02-21 17:37 ` Dave Jones 2007-02-21 20:19 ` Dave Jones 2007-02-21 20:19 ` Dave Jones 2007-02-22 16:37 ` Jean Delvare 2007-02-22 16:37 ` Jean Delvare 2007-02-23 7:13 ` Hans de Goede 2007-02-23 7:13 ` [lm-sensors] " Hans de Goede 2007-02-23 7:13 ` Hans de Goede 2007-02-23 7:47 ` Jean Delvare 2007-02-23 7:47 ` Jean Delvare 2007-02-21 14:54 ` Jean Delvare 2007-02-21 14:54 ` Jean Delvare 2007-02-21 16:03 ` Chuck Ebbert 2007-02-21 16:03 ` Chuck Ebbert 2007-02-21 16:22 ` Jean Delvare 2007-02-21 16:22 ` Jean Delvare 2007-02-23 8:08 ` Hans de Goede 2007-02-26 17:24 ` Jean Delvare 2007-02-26 19:03 ` Hans de Goede 2007-02-27 8:45 ` Jean Delvare [not found] <7PvLN-1cj-3@gated-at.bofh.it> [not found] ` <7TEGV-6Jy-39@gated-at.bofh.it> [not found] ` <7TUBX-6TN-5@gated-at.bofh.it> [not found] ` <7UeqX-4QO-17@gated-at.bofh.it> [not found] ` <7UeqZ-4QO-27@gated-at.bofh.it> [not found] ` <7UgM5-np-1@gated-at.bofh.it> [not found] ` <7UgM8-np-11@gated-at.bofh.it> [not found] ` <7UnaS-2xP-9@gated-at.bofh.it> [not found] ` <7UnkC-2JB-9@gated-at.bofh.it> [not found] ` <7Uzcd-49u-3@gated-at.bofh.it> [not found] ` <7UEEN-4xi-3@gated-at.bofh.it> 2007-03-05 13:56 ` Bodo Eggert 2007-03-05 13:56 ` Bodo Eggert 2007-03-05 13:56 ` Bodo Eggert 2007-03-06 15:19 ` Jean Delvare 2007-03-06 15:19 ` Jean Delvare 2007-03-06 20:40 ` Bodo Eggert 2007-03-06 20:40 ` Bodo Eggert 2007-03-07 9:17 ` Jean Delvare 2007-03-07 9:17 ` Jean Delvare 2007-03-07 9:36 ` Pavel Machek 2007-03-07 9:36 ` Pavel Machek 2007-03-07 17:09 ` Bodo Eggert 2007-03-07 17:09 ` Bodo Eggert
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=20070319080849.17ecf173.khali@linux-fr.org \ --to=khali@linux-fr.org \ --cc=cebbert@redhat.com \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lm-sensors@lm-sensors.org \ --cc=mjg59@srcf.ucam.org \ --cc=pavel@ucw.cz \ --cc=r.marek@assembler.cz \ --cc=richardvoigt@gmail.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.