All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Moore, Robert" <robert.moore@intel.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"devel@acpica.org" <devel@acpica.org>
Subject: RE: [Devel] acpi_os_read_memory() from interrupt context
Date: Wed, 4 Aug 2010 15:26:15 -0700	[thread overview]
Message-ID: <4911F71203A09E4D9981D27F9D830858AC59CF57@orsmsx503.amr.corp.intel.com> (raw)
In-Reply-To: <201008041119.23633.bjorn.helgaas@hp.com>

If you need to pre-map the ACPI registers, I would expect the host to build a list of these during initialization as you mention, then lookup and use the appropriate mapping in acpi_os_read_memory.  The acpi_os memory interfaces are not generic memory interfaces; they are only used for memory-mapped ACPI registers, so it is entirely appropriate to do whatever you need to do to obtain a mapping for the registers when at interrupt level.



>-----Original Message-----
>From: devel-bounces@acpica.org [mailto:devel-bounces@acpica.org] On Behalf
>Of Bjorn Helgaas
>Sent: Wednesday, August 04, 2010 10:19 AM
>To: linux-acpi@vger.kernel.org; devel@acpica.org
>Subject: [Devel] acpi_os_read_memory() from interrupt context
>
>Linux reads some ACPI registers from interrupt context.  For example,
>we read the PM1 Status register in the SCI interrupt handler via
>this path:
>
>    acpi_irq
>      acpi_ev_sci_xrupt_handler
>        acpi_ev_fixed_event_detect
>          acpi_hw_register_read
>            acpi_hw_read_multiple
>              acpi_read
>
>But acpi_read() takes a generic address structure, and if that
>address happens to be in memory space (not I/O port space), we use
>acpi_os_read_memory().  In Linux, that uses ioremap() to map the
>address, and that doesn't work from interrupt context.
>
>I can imagine fixing this by doing the ioremap() at boot-time
>rather than at interrupt-time, but most of this interrupt path
>is in the ACPI CA, not in Linux itself, so it would probably
>require some redesign in the CA.
>
>Any suggestions?
>
>Bjorn
>_______________________________________________
>Devel mailing list
>Devel@acpica.org
>http://lists.acpica.org/listinfo/devel

WARNING: multiple messages have this Message-ID (diff)
From: Moore, Robert <robert.moore at intel.com>
To: devel@acpica.org
Subject: Re: [Devel] acpi_os_read_memory() from interrupt context
Date: Wed, 04 Aug 2010 15:26:15 -0700	[thread overview]
Message-ID: <4911F71203A09E4D9981D27F9D830858AC59CF57@orsmsx503.amr.corp.intel.com> (raw)
In-Reply-To: 201008041119.23633.bjorn.helgaas@hp.com

[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]

If you need to pre-map the ACPI registers, I would expect the host to build a list of these during initialization as you mention, then lookup and use the appropriate mapping in acpi_os_read_memory.  The acpi_os memory interfaces are not generic memory interfaces; they are only used for memory-mapped ACPI registers, so it is entirely appropriate to do whatever you need to do to obtain a mapping for the registers when at interrupt level.



>-----Original Message-----
>From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
>Of Bjorn Helgaas
>Sent: Wednesday, August 04, 2010 10:19 AM
>To: linux-acpi(a)vger.kernel.org; devel(a)acpica.org
>Subject: [Devel] acpi_os_read_memory() from interrupt context
>
>Linux reads some ACPI registers from interrupt context.  For example,
>we read the PM1 Status register in the SCI interrupt handler via
>this path:
>
>    acpi_irq
>      acpi_ev_sci_xrupt_handler
>        acpi_ev_fixed_event_detect
>          acpi_hw_register_read
>            acpi_hw_read_multiple
>              acpi_read
>
>But acpi_read() takes a generic address structure, and if that
>address happens to be in memory space (not I/O port space), we use
>acpi_os_read_memory().  In Linux, that uses ioremap() to map the
>address, and that doesn't work from interrupt context.
>
>I can imagine fixing this by doing the ioremap() at boot-time
>rather than at interrupt-time, but most of this interrupt path
>is in the ACPI CA, not in Linux itself, so it would probably
>require some redesign in the CA.
>
>Any suggestions?
>
>Bjorn
>_______________________________________________
>Devel mailing list
>Devel(a)acpica.org
>http://lists.acpica.org/listinfo/devel

  reply	other threads:[~2010-08-04 22:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-04 17:19 acpi_os_read_memory() from interrupt context Bjorn Helgaas
2010-08-04 17:19 ` [Devel] " Bjorn Helgaas
2010-08-04 22:26 ` Moore, Robert [this message]
2010-08-04 22:26   ` Moore, Robert
2010-08-11  9:25 ` Andi Kleen
2010-08-11  9:25   ` [Devel] " Andi Kleen

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=4911F71203A09E4D9981D27F9D830858AC59CF57@orsmsx503.amr.corp.intel.com \
    --to=robert.moore@intel.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=devel@acpica.org \
    --cc=linux-acpi@vger.kernel.org \
    /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: link
Be 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.