Il Wed, Apr 18, 2007 at 01:50:29AM +0200, Luca Tettamanti ha scritto:
> >I'm sure you've seen these:
> > http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html
> > http://www.lm-sensors.org/wiki/AsusFormulaHacking
>
> Actually I haven't, I've happily ignored ACPI until now
Il Wed, Apr 18, 2007 at 01:50:29AM +0200, Luca Tettamanti ha scritto:
I'm sure you've seen these:
http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html
http://www.lm-sensors.org/wiki/AsusFormulaHacking
Actually I haven't, I've happily ignored ACPI until now ;-) My
On 4/17/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
On Monday 16 April 2007 15:14, Luca Tettamanti wrote:
> Problem is that ACPI methods are not documented at all (how am I
> supposed to know that "G6T6" is the reading of the 12V rail?) while the
> datasheet of hw monitoring chips (w83627ehf in
Hi Bjorn, Luca,
On Mon, 16 Apr 2007 23:14:11 +0200, Luca Tettamanti wrote:
> Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto:
> > In the case of k8temp, the driver claims PCI devices with a certain
> > vendor and device ID. PCI devices are mostly outside the scope of
> >
Hi Bjorn, Luca,
On Mon, 16 Apr 2007 23:14:11 +0200, Luca Tettamanti wrote:
Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto:
In the case of k8temp, the driver claims PCI devices with a certain
vendor and device ID. PCI devices are mostly outside the scope of
ACPI.
On 4/17/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Monday 16 April 2007 15:14, Luca Tettamanti wrote:
Problem is that ACPI methods are not documented at all (how am I
supposed to know that G6T6 is the reading of the 12V rail?) while the
datasheet of hw monitoring chips (w83627ehf in my
On Monday 16 April 2007 15:14, Luca Tettamanti wrote:
> It seems that Asus exposes monitorining data using "ATK0110" (enumerated
> in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D)
> (they have different methods though). Another motherboard with the same
> device may
Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto:
> On Sunday 15 April 2007 14:59, Luca Tettamanti wrote:
> > On 4/15/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > > But I missed the details, such as the specific devices in question,
> > > which ports they use, how they are
Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto:
On Sunday 15 April 2007 14:59, Luca Tettamanti wrote:
On 4/15/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
But I missed the details, such as the specific devices in question,
which ports they use, how they are described in
On Monday 16 April 2007 15:14, Luca Tettamanti wrote:
It seems that Asus exposes monitorining data using ATK0110 (enumerated
in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D)
(they have different methods though). Another motherboard with the same
device may actually call
On Sunday 15 April 2007 14:59, Luca Tettamanti wrote:
> On 4/15/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > But I missed the details, such as the specific devices in question,
> > which ports they use, how they are described in ACPI, which AML
> > methods use those ports, and which non-ACPI
On 4/15/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
On Sunday 15 April 2007 03:41, Jean Delvare wrote:
> On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote:
> > Of course, there are always BIOS defects. But if we could make a
> > case that a BIOS that doesn't declare the resources used by
On Sunday 15 April 2007 03:41, Jean Delvare wrote:
> On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote:
> > Of course, there are always BIOS defects. But if we could make a
> > case that a BIOS that doesn't declare the resources used by the AML
> > is defective, we could add quirks to
Hi Bjorn,
On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote:
> On Friday 13 April 2007 14:07, Pavel Machek wrote:
> > > > ... The primary issue is the concurrent access
> > > > to resources, which cause lots of trouble which are hard to investigate.
> > > > If ACPI reserves the ports, then
On Sunday 15 April 2007 14:59, Luca Tettamanti wrote:
On 4/15/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
But I missed the details, such as the specific devices in question,
which ports they use, how they are described in ACPI, which AML
methods use those ports, and which non-ACPI drivers
Hi Bjorn,
On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote:
On Friday 13 April 2007 14:07, Pavel Machek wrote:
... The primary issue is the concurrent access
to resources, which cause lots of trouble which are hard to investigate.
If ACPI reserves the ports, then the SMBus or
On Sunday 15 April 2007 03:41, Jean Delvare wrote:
On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote:
Of course, there are always BIOS defects. But if we could make a
case that a BIOS that doesn't declare the resources used by the AML
is defective, we could add quirks to reserve the
On 4/15/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Sunday 15 April 2007 03:41, Jean Delvare wrote:
On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote:
Of course, there are always BIOS defects. But if we could make a
case that a BIOS that doesn't declare the resources used by the
On Friday 13 April 2007 14:07, Pavel Machek wrote:
> > > ... The primary issue is the concurrent access
> > > to resources, which cause lots of trouble which are hard to investigate.
> > > If ACPI reserves the ports, then the SMBus or hardware monitoring
> > > drivers (or any other conflicting
Hi!
> > ... The primary issue is the concurrent access
> > to resources, which cause lots of trouble which are hard to investigate.
> > If ACPI reserves the ports, then the SMBus or hardware monitoring
> > drivers (or any other conflicting driver) will cleanly fail to load,
> > which would be a
On Friday 02 March 2007 07:03, Jean Delvare wrote:
> ... The primary issue is the concurrent access
> to resources, which cause lots of trouble which are hard to investigate.
> If ACPI reserves the ports, then the SMBus or hardware monitoring
> drivers (or any other conflicting driver) will
On Friday 02 March 2007 07:03, Jean Delvare wrote:
... The primary issue is the concurrent access
to resources, which cause lots of trouble which are hard to investigate.
If ACPI reserves the ports, then the SMBus or hardware monitoring
drivers (or any other conflicting driver) will cleanly
Hi!
... The primary issue is the concurrent access
to resources, which cause lots of trouble which are hard to investigate.
If ACPI reserves the ports, then the SMBus or hardware monitoring
drivers (or any other conflicting driver) will cleanly fail to load,
which would be a move in the
On Friday 13 April 2007 14:07, Pavel Machek wrote:
... The primary issue is the concurrent access
to resources, which cause lots of trouble which are hard to investigate.
If ACPI reserves the ports, then the SMBus or hardware monitoring
drivers (or any other conflicting driver) will
Hi!
> > Actually for the acpi stuff... we might wrap ACPI interpretter with a
> > semaphore that needs to be taken before starting any AML code. Then
> > just make sure sensors take same semaphore?
>
> I like the idea, it should work as long as we are guaranteed that all
> the hwmon device
Hi!
Actually for the acpi stuff... we might wrap ACPI interpretter with a
semaphore that needs to be taken before starting any AML code. Then
just make sure sensors take same semaphore?
I like the idea, it should work as long as we are guaranteed that all
the hwmon device accesses
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 +, Matthew Garrett wrote:
> > > Assuming arbitration of access, what's the problem with having two
> > > drivers accessing the same hardware? Do these chips
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 +, Matthew Garrett wrote:
Assuming arbitration of access, what's the problem with having two
drivers accessing the same hardware? Do these chips generally
On 3/3/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
Hi Matthew,
On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote:
> On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:
> > It might be more elegant but it won't work. We don't want to prevent
> > ACPI from accessing these I/O
On 3/3/07, Jean Delvare [EMAIL PROTECTED] wrote:
Hi Matthew,
On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote:
On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:
It might be more elegant but it won't work. We don't want to prevent
ACPI from accessing these I/O ports. If
No ACPI discussion can be complete without mentioning Microsoft and
Microsoft compatibility -- Windows does not fully support ACPI 2.0 to
this day, even though it was released in the year 2000, and ACPI 3.0 has
been out since 2004.
> -Original Message-
> From: Alexey Starikovskiy
Included the Intel ACPI spec representative.
I have heard that Windows is somehow restricting the ports and memory
locations that are accessible via AML; I don't know any of the details.
Also, there are fears of an "AML virus" attacking the machine.
Bob
> -Original Message-
> From:
Jean Delvare wrote:
Hi Alexey,
On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:
Jean Delvare wrote:
I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this
Hi Alexey,
On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:
> Jean Delvare wrote:
> > I can only second Pavel's wish here. This would be highly convenient
> > for OS developers to at least know which resources are accessed by AML
> > and SMM. Without this information, we can never
Hi!
> >>Can you take this as a wishlist item?
> >>
> >>It would be nice if next version of acpi specs supported table
> >>
> >>'AML / SMM BIOS will access these ports'
> >>
> >>...so we can get it correct with acpi4 or something..?
> >>
> >
> >I can only second Pavel's wish here. This would
Jean Delvare wrote:
On Fri, 9 Mar 2007 07:18:56 +, Pavel Machek wrote:
Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
Can you take
On Fri, 9 Mar 2007 07:18:56 +, Pavel Machek wrote:
> > Port (and memory) addresses can be dynamically generated by the AML code
> > and thus, there is no way that the ACPI subsystem can statically predict
> > any addresses that will be accessed by the AML.
>
> Can you take this as a wishlist
On Fri, 9 Mar 2007 07:18:56 +, Pavel Machek wrote:
Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
Can you take this as a wishlist item?
Jean Delvare wrote:
On Fri, 9 Mar 2007 07:18:56 +, Pavel Machek wrote:
Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
Can you take
Hi!
Can you take this as a wishlist item?
It would be nice if next version of acpi specs supported table
'AML / SMM BIOS will access these ports'
...so we can get it correct with acpi4 or something..?
I can only second Pavel's wish here. This would be highly convenient
for OS
Hi Alexey,
On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:
Jean Delvare wrote:
I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this information, we can never be sure
Jean Delvare wrote:
Hi Alexey,
On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:
Jean Delvare wrote:
I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this
Included the Intel ACPI spec representative.
I have heard that Windows is somehow restricting the ports and memory
locations that are accessible via AML; I don't know any of the details.
Also, there are fears of an AML virus attacking the machine.
Bob
-Original Message-
From: Pavel
No ACPI discussion can be complete without mentioning Microsoft and
Microsoft compatibility -- Windows does not fully support ACPI 2.0 to
this day, even though it was released in the year 2000, and ACPI 3.0 has
been out since 2004.
-Original Message-
From: Alexey Starikovskiy
Hi!
> Port (and memory) addresses can be dynamically generated by the AML code
> and thus, there is no way that the ACPI subsystem can statically predict
> any addresses that will be accessed by the AML.
Can you take this as a wishlist item?
It would be nice if next version of acpi specs
Hi!
Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
Can you take this as a wishlist item?
It would be nice if next version of acpi specs supported
On Wed, 7 Mar 2007, Jean Delvare wrote:
> On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:
> > 1) I asume port allocations or ACPI foreign port acces to be rare, so
> >there would be little impact on (un)registering hardware. Off cause
> >there are some long ACPI calls (like
Hi!
> > > > 2) make ACPI take this lock whenever it touches ports not allocated by
> > > > itself
> > > >and release it on function return.
> > >
> > > This is costly.
> >
> > TANSTAAFL. You'll need to take some lock, and if you want port emulation
> > or per-device-mutex, you'll have to
Hi Bodo,
On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:
> On Tue, 6 Mar 2007, Jean Delvare wrote:
> > On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
>
> > > 2) make ACPI take this lock whenever it touches ports not allocated by
> > > itself
> > >and release it on
Hi Bodo,
On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:
On Tue, 6 Mar 2007, Jean Delvare wrote:
On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
2) make ACPI take this lock whenever it touches ports not allocated by
itself
and release it on function return.
Hi!
2) make ACPI take this lock whenever it touches ports not allocated by
itself
and release it on function return.
This is costly.
TANSTAAFL. You'll need to take some lock, and if you want port emulation
or per-device-mutex, you'll have to pay the price.
True,
On Wed, 7 Mar 2007, Jean Delvare wrote:
On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:
1) I asume port allocations or ACPI foreign port acces to be rare, so
there would be little impact on (un)registering hardware. Off cause
there are some long ACPI calls (like reading
Hi Matthew,
On Fri, 2 Mar 2007 21:46:43 +, Matthew Garrett wrote:
> On Fri, Mar 02, 2007 at 10:41:55PM +0100, Jean Delvare wrote:
>
> > I like the patch, after adding some casts to the printf args it
> > compiles fine. However you print warnings each time a resource has been
> > reserved...
In other words, as per my earlier message:
Port addresses can be dynamically generated by the AML code and thus,
there is no way that the ACPI subsystem can statically predict any
addresses that will be accessed by the AML.
Bob
> -Original Message-
> From: [EMAIL PROTECTED]
Hi!
> > > Is there anything preventing us from doing such a walk and pre-allocate
> > > all the I/O ranges? I am not familiar with the ACPI code at all, would
> > > you possibly propose a patch doing that?
> >
> > ACPI AML is probably turing-complete: I'm afraid you are trying to
> > solve the
>> > Is there anything preventing us from doing such a walk and pre-allocate
>> > all the I/O ranges? I am not familiar with the ACPI code at all, would
>> > you possibly propose a patch doing that?
>>
>> ACPI AML is probably turing-complete: I'm afraid you are trying to
>> solve the halting
On Tue, 6 Mar 2007, Jean Delvare wrote:
> On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
> > 2) make ACPI take this lock whenever it touches ports not allocated by
> > itself
> >and release it on function return.
>
> This is costly.
TANSTAAFL. You'll need to take some lock, and if
Hi Pavel,
On Mon, 5 Mar 2007 22:25:48 +, Pavel Machek wrote:
> > Is there anything preventing us from doing such a walk and pre-allocate
> > all the I/O ranges? I am not familiar with the ACPI code at all, would
> > you possibly propose a patch doing that?
>
> ACPI AML is probably
Hi Bodo,
On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
> 1) Make a general resource allocation lock, if there is none.
Such a lock certainly exists, but I doubt it is public at the moment.
> 2) make ACPI take this lock whenever it touches ports not allocated by itself
>and release
Hi David,
On Mon, 5 Mar 2007 13:35:20 -0800, David Hubbard wrote:
> > 2* It seems to incur a signficant performance penalty.
> > request_resource isn't cheap as far as I know. And in the
> > absence of conflict, you are even allocating and releasing the resource
> > on _each_ I/O operation,
Hi David,
On Mon, 5 Mar 2007 13:35:20 -0800, David Hubbard wrote:
2* It seems to incur a signficant performance penalty.
request_resource isn't cheap as far as I know. And in the
absence of conflict, you are even allocating and releasing the resource
on _each_ I/O operation, which
Hi Bodo,
On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
1) Make a general resource allocation lock, if there is none.
Such a lock certainly exists, but I doubt it is public at the moment.
2) make ACPI take this lock whenever it touches ports not allocated by itself
and release it
Hi Pavel,
On Mon, 5 Mar 2007 22:25:48 +, Pavel Machek wrote:
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
ACPI AML is probably turing-complete:
On Tue, 6 Mar 2007, Jean Delvare wrote:
On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
2) make ACPI take this lock whenever it touches ports not allocated by
itself
and release it on function return.
This is costly.
TANSTAAFL. You'll need to take some lock, and if you want
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
ACPI AML is probably turing-complete: I'm afraid you are trying to
solve the halting problem (-
Hi!
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
ACPI AML is probably turing-complete: I'm afraid you are trying to
solve the halting problem
In other words, as per my earlier message:
Port addresses can be dynamically generated by the AML code and thus,
there is no way that the ACPI subsystem can statically predict any
addresses that will be accessed by the AML.
Bob
-Original Message-
From: [EMAIL PROTECTED]
Hi Matthew,
On Fri, 2 Mar 2007 21:46:43 +, Matthew Garrett wrote:
On Fri, Mar 02, 2007 at 10:41:55PM +0100, Jean Delvare wrote:
I like the patch, after adding some casts to the printf args it
compiles fine. However you print warnings each time a resource has been
reserved... without
> "PM" == Pavel Machek <[EMAIL PROTECTED]> writes:
PM> ACPI AML is probably turing-complete: I'm afraid you are trying to
PM> solve the halting problem (-> impossible).
If you can restrict the virtual machine which AML runs in to a limited
amount of memory/storage, you can solve halting for
Hi!
> > > Why would we end up with an overestimation if we check the I/O ports at
> > > boot time? Do you have concrete cases in mind?
> >
> > ACPI will often describe large operation regions, but won't necessarily
> > touch all of them. Effectively, every codepath would have to be walked
> >
Hi Jean, Rudolf,
1* It requires that we modify each driver individually. It's quite a
shame that we have to update drivers all around the kernel tree with
specific code to workaround a problem which is originally located in a
single place (the ACPI subsystem.) That being said this isn't a
Hi Rudolf,
On Sun, 04 Mar 2007 18:29:12 +0100, Rudolf Marek wrote:
> I produced some code which I proposed in mail above. The patch is not for
> review
> it is just a PoC to better show what I'm trying to do. It is a test case for
> my
> motherboard which has W83627EHF chip and ACPI thermal
David Hubbard <[EMAIL PROTECTED]> wrote:
> For I/O and memory that ACPI accesses and has not reserved, the AML
> interpreter could allocate at run-time.
>
> I'm not sure how to implement exactly. For example, it would be bad to
> have a /proc/ioports that had a lot of single ports allocated, for
David Hubbard [EMAIL PROTECTED] wrote:
For I/O and memory that ACPI accesses and has not reserved, the AML
interpreter could allocate at run-time.
I'm not sure how to implement exactly. For example, it would be bad to
have a /proc/ioports that had a lot of single ports allocated, for
Hi Rudolf,
On Sun, 04 Mar 2007 18:29:12 +0100, Rudolf Marek wrote:
I produced some code which I proposed in mail above. The patch is not for
review
it is just a PoC to better show what I'm trying to do. It is a test case for
my
motherboard which has W83627EHF chip and ACPI thermal method
Hi Jean, Rudolf,
1* It requires that we modify each driver individually. It's quite a
shame that we have to update drivers all around the kernel tree with
specific code to workaround a problem which is originally located in a
single place (the ACPI subsystem.) That being said this isn't a
Hi!
Why would we end up with an overestimation if we check the I/O ports at
boot time? Do you have concrete cases in mind?
ACPI will often describe large operation regions, but won't necessarily
touch all of them. Effectively, every codepath would have to be walked
through at
PM == Pavel Machek [EMAIL PROTECTED] writes:
PM ACPI AML is probably turing-complete: I'm afraid you are trying to
PM solve the halting problem (- impossible).
If you can restrict the virtual machine which AML runs in to a limited
amount of memory/storage, you can solve halting for it in
Hello again,
I produced some code which I proposed in mail above. The patch is not for review
it is just a PoC to better show what I'm trying to do. It is a test case for my
motherboard which has W83627EHF chip and ACPI thermal method and w83627ehf
compete the device.
When no driver is loaded,
Hi David,
On Sat, 3 Mar 2007 08:47:21 -0700, David Hubbard wrote:
> > Is there anything preventing us from doing such a walk and pre-allocate
> > all the I/O ranges? I am not familiar with the ACPI code at all, would
> > you possibly propose a patch doing that?
>
> Here's a random idea -- what
Hi David,
On Sat, 3 Mar 2007 08:47:21 -0700, David Hubbard wrote:
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
Here's a random idea -- what do you
Hello again,
I produced some code which I proposed in mail above. The patch is not for review
it is just a PoC to better show what I'm trying to do. It is a test case for my
motherboard which has W83627EHF chip and ACPI thermal method and w83627ehf
compete the device.
When no driver is loaded,
Hello all,
I was already thinking about some very general port forwarder,
(http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018788.html)
But I'm not able to find out how to do that painlessly. Even don't know if to
use the classes or even some new "bus" in driver model :/ some
On Sat, Mar 03, 2007 at 08:47:21AM -0700, David Hubbard wrote:
> For I/O and memory that ACPI accesses and has not reserved, the AML
> interpreter could allocate at run-time.
Not ideal. ACPI's already fiddling with ranges that have been reserved
by other drivers.
--
Matthew Garrett | [EMAIL
Hi Jean,
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
Here's a random idea -- what do you think of it?
ACPI already allocates some I/O ranges, which was
Hi Matthew,
On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote:
> On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:
> > It might be more elegant but it won't work. We don't want to prevent
> > ACPI from accessing these I/O ports. If we need to choose only one
> > "driver"
Hi Matthew,
On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote:
On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:
It might be more elegant but it won't work. We don't want to prevent
ACPI from accessing these I/O ports. If we need to choose only one
driver accessing the
Hi Jean,
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
Here's a random idea -- what do you think of it?
ACPI already allocates some I/O ranges, which was
On Sat, Mar 03, 2007 at 08:47:21AM -0700, David Hubbard wrote:
For I/O and memory that ACPI accesses and has not reserved, the AML
interpreter could allocate at run-time.
Not ideal. ACPI's already fiddling with ranges that have been reserved
by other drivers.
--
Matthew Garrett | [EMAIL
Hello all,
I was already thinking about some very general port forwarder,
(http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018788.html)
But I'm not able to find out how to do that painlessly. Even don't know if to
use the classes or even some new bus in driver model :/ some
On Fri, 2 Mar 2007 14:57:06 +0100, Pavel Machek wrote:
> On Fri 2007-03-02 14:37:20, Jean Delvare wrote:
> > drivers/pci/quirks.c is full of things we do against the BIOS authors
> > intent. You don't plan to remove them all, do you?
>
> Notice how quirks.c is careful to name machines where given
Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-acpi-
> [EMAIL PROTECTED] On
On Fri, Mar 02, 2007 at 10:41:55PM +0100, Jean Delvare wrote:
> I like the patch, after adding some casts to the printf args it
> compiles fine. However you print warnings each time a resource has been
> reserved... without checking if it hasn't been reserved by ACPI itself!
> My machine looks
Hi Matthew,
On Fri, 2 Mar 2007 14:57:09 +, Matthew Garrett wrote:
> How about this? It's informational only, but ought to result in
> complaints whenever ACPI tries to touch something that other hardware
> has reserved. We can't fail these accesses, but in theory we could
> consider some
On Fri, 02 Mar 2007, Jean Delvare wrote:
> I like the idea, it should work as long as we are guaranteed that all
> the hwmon device accesses happen in the AML code? I'm not familiar with
> ACPI, so you tell me.
Some fubar machines do it in SMM mode, and the AML code just reads memory
regions that
On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:
> On Fri, 2 Mar 2007 14:18:40 +, Matthew Garrett wrote:
> > In theory I /think/ so, but it would probably end up being an
> > overestimate of the coverage actually needed. Trapping at runtime is
> > arguably more elegant?
>
> It
On Fri, 2 Mar 2007 14:18:40 +, Matthew Garrett wrote:
> On Fri, Mar 02, 2007 at 03:10:55PM +0100, Jean Delvare wrote:
>
> > I'm not familiar with APCI at all so I didn't know, but what you write
> > here brings some hope. Would it be possible to parse all the DSDT code
> > at boot time and
Hi Pavel,
On Fri, 2 Mar 2007 14:58:10 +0100, Pavel Machek wrote:
> Actually for the acpi stuff... we might wrap ACPI interpretter with a
> semaphore that needs to be taken before starting any AML code. Then
> just make sure sensors take same semaphore?
I like the idea, it should work as long as
How about this? It's informational only, but ought to result in
complaints whenever ACPI tries to touch something that other hardware
has reserved. We can't fail these accesses, but in theory we could
consider some sort of locking layer that made it possible to interact
anyway. I haven't even
Hi!
> > Ok. You are right that ACPI is an ugly piece of mess. But I'm pretty
> > sure that 90%+ of ACPI notebook implementations *will* want to talk to
> > their monitoring chips... for temperature readings.
> >
> > So even if we fixed ACPI to reserve the ports, you'd be still unhappy;
> >
1 - 100 of 182 matches
Mail list logo
