public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* ACPI requesting I/O ports?
@ 2007-03-02 21:14 Jean Delvare
  2007-03-02 22:05 ` Moore, Robert
  0 siblings, 1 reply; 3+ messages in thread
From: Jean Delvare @ 2007-03-02 21:14 UTC (permalink / raw)
  To: Len Brown; +Cc: linux-acpi, Pavel Machek

Hi Len,

As a follow up of this dicussion:
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-March/019015.html

I'd like to know if it would be possible to have the acpi subsystem
somehow declare or even request the I/O ports it will be accessing when
running AML code? There is a need for this, otherwise other drivers
might access the same resources as the AML code does, with possibly bad
consequences.

Another approach proposed by Pavel Machek would be a general mutex to
protect the AML code from the rest of the kernel, this would probably
work too but the granularity (and thus the latency) would be better
with a per-I/O-region approach.

Thanks,
-- 
Jean Delvare

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: ACPI requesting I/O ports?
  2007-03-02 21:14 ACPI requesting I/O ports? Jean Delvare
@ 2007-03-02 22:05 ` Moore, Robert
  2007-03-03  9:21   ` Jean Delvare
  0 siblings, 1 reply; 3+ messages in thread
From: Moore, Robert @ 2007-03-02 22:05 UTC (permalink / raw)
  To: Jean Delvare, Brown, Len; +Cc: linux-acpi, Pavel Machek

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.


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Jean Delvare
> Sent: Friday, March 02, 2007 1:15 PM
> To: Brown, Len
> Cc: linux-acpi@vger.kernel.org; Pavel Machek
> Subject: ACPI requesting I/O ports?
> 
> Hi Len,
> 
> As a follow up of this dicussion:
>
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-March/019015.html
> 
> I'd like to know if it would be possible to have the acpi subsystem
> somehow declare or even request the I/O ports it will be accessing
when
> running AML code? There is a need for this, otherwise other drivers
> might access the same resources as the AML code does, with possibly
bad
> consequences.
> 
> Another approach proposed by Pavel Machek would be a general mutex to
> protect the AML code from the rest of the kernel, this would probably
> work too but the granularity (and thus the latency) would be better
> with a per-I/O-region approach.
> 
> Thanks,
> --
> Jean Delvare
> -
> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ACPI requesting I/O ports?
  2007-03-02 22:05 ` Moore, Robert
@ 2007-03-03  9:21   ` Jean Delvare
  0 siblings, 0 replies; 3+ messages in thread
From: Jean Delvare @ 2007-03-03  9:21 UTC (permalink / raw)
  To: Moore, Robert; +Cc: Brown, Len, linux-acpi, Pavel Machek

Hi Robert,

On Fri, 2 Mar 2007 14:05:45 -0800, Moore, Robert wrote:
> 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.

Can you please explain in greater details how "dynamical" it is? Any
real world example you could present?

Also, you say that port addresses _can_ be dynamically generated, which
suggests that some are not, so the ACPI subsystem could at least
properly request these ones?

Thanks,
-- 
Jean Delvare

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-03-03  9:24 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-02 21:14 ACPI requesting I/O ports? Jean Delvare
2007-03-02 22:05 ` Moore, Robert
2007-03-03  9:21   ` Jean Delvare

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox