From: Konstantin Baydarov <kbaidarov@ru.mvista.com>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
<vgoyal@in.ibm.com>, "RT" <linux-rt-users@vger.kernel.org>,
"linux-kernel" <linux-kernel@vger.kernel.org>,
"Andi Kleen" <ak@suse.de>,
Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: [PATCH] kexec: reenable HPET before kexec
Date: Fri, 31 Aug 2007 14:31:51 +0400 [thread overview]
Message-ID: <20070831143151.7dde7c86@windmill.dev.rtsoft.ru> (raw)
In-Reply-To: <m1d4x4zyoe.fsf@ebiederm.dsl.xmission.com>
On Thu, 30 Aug 2007 12:04:33 -0600
ebiederm@xmission.com (Eric W. Biederman) wrote:
> I was assuming that CLOCK_EVT_MODE_SHUTDOWN just mapped
> to the shutdown method of the clock events or something else.
> But it shutdown means something different in this context we
> can certainly find a better place to hook into the device
> tree and call shutdown methods. Especially if that will
> make the code simpler.
Agree. I've got rig from timekeeping. Now I'm using system device tree shutdown interface, as you suggested. I've added HPET system device class with shutdown method and HPET device to sysdev.
> This is a design feature. machine_crash_shutdown is not really
> supposed to disable any hardware. There is a very minimal set that we
> haven't been able to figure out how to get the kernels initialization
> routines to deal with properly. Which is a temporary justification
> for not doing more now. If we can't find anyway to make the
> initialization code more robust for the hpet we can revisit this.
So you suggest to check if HPET is present in HPET init code even if HPET disabled in boot kernel command line or APIC is disabled. And if HPET is present and kernel not going to use it - disable HPET interrupts?
> Please remove the CONFIG_KEXEC. We need to do this on a reboot also
> so we don't confuse the BIOS. BIOS's frequently but not always
> can just reset the board to avoid complications like this, but if
> we need a shutdown method we need a shutdown method. The kexec
> case just exercises things more.
Removed CONFIG_KEXEC.
So here is new version of fix. Patch against 2.6.23-rc3.
Eric, review please. Thanks.
Signed-off-by: Konstantin Baydarov <kbaidarov@ru.mvista.com>
arch/i386/kernel/hpet.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
Index: linux-2.6.23-rc3/arch/i386/kernel/hpet.c
===================================================================
--- linux-2.6.23-rc3.orig/arch/i386/kernel/hpet.c
+++ linux-2.6.23-rc3/arch/i386/kernel/hpet.c
@@ -144,11 +144,31 @@ static void hpet_enable_int(void)
{
unsigned long cfg = hpet_readl(HPET_CFG);
+ if (hpet_legacy_int_enabled)
+ return;
+
cfg |= HPET_CFG_LEGACY;
hpet_writel(cfg, HPET_CFG);
hpet_legacy_int_enabled = 1;
}
+static void hpet_disable_int(void)
+{
+ unsigned long cfg;
+
+ if (!hpet_legacy_int_enabled)
+ return;
+
+ if (!is_hpet_capable())
+ return;
+
+ cfg = hpet_readl(HPET_CFG);
+ cfg &= ~HPET_CFG_LEGACY;
+ hpet_writel(cfg, HPET_CFG);
+ hpet_legacy_int_enabled = 0;
+
+}
+
static void hpet_set_mode(enum clock_event_mode mode,
struct clock_event_device *evt)
{
@@ -551,3 +571,31 @@ irqreturn_t hpet_rtc_interrupt(int irq,
return IRQ_HANDLED;
}
#endif
+
+static int hpet_shutdown(struct sys_device *dev)
+{
+ /* We need this to make PIT works in KEXECuted kernel */
+ hpet_disable_int();
+
+ return 0;
+}
+
+static struct sysdev_class hpet_sysdev_class = {
+ set_kset_name("hpet"),
+ .shutdown = hpet_shutdown,
+};
+
+static struct sys_device device_hpet = {
+ .id = 0,
+ .cls = &hpet_sysdev_class,
+};
+
+static int __init hpet_init_sysfs(void)
+{
+ int error = sysdev_class_register(&hpet_sysdev_class);
+ if (!error)
+ error = sysdev_register(&device_hpet);
+ return error;
+}
+
+device_initcall(hpet_init_sysfs);
next prev parent reply other threads:[~2007-08-31 10:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-20 16:55 [PATCH] kexec: reenable HPET before kexec Konstantin Baydarov
2007-08-20 18:26 ` Andi Kleen
2007-08-20 21:10 ` Konstantin Baydarov
2007-08-20 21:31 ` Daniel Walker
2007-08-21 13:01 ` Konstantin Baydarov
2007-08-23 9:08 ` Vivek Goyal
2007-08-23 11:49 ` Konstantin Baydarov
2007-08-27 5:36 ` Vivek Goyal
2007-08-27 18:26 ` Pallipadi, Venkatesh
2007-08-27 18:33 ` Eric W. Biederman
2007-08-28 12:58 ` Konstantin Baydarov
2007-08-30 7:32 ` Eric W. Biederman
2007-08-30 16:07 ` Konstantin Baydarov
2007-08-30 18:04 ` Eric W. Biederman
2007-08-31 10:31 ` Konstantin Baydarov [this message]
2007-09-17 9:47 ` Konstantin Baydarov
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=20070831143151.7dde7c86@windmill.dev.rtsoft.ru \
--to=kbaidarov@ru.mvista.com \
--cc=ak@suse.de \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=venkatesh.pallipadi@intel.com \
--cc=vgoyal@in.ibm.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox