From: Andi Kleen <andi@firstfloor.org>
To: Russell Leidich <rml@google.com>
Cc: Andi Kleen <andi@firstfloor.org>,
Torsten Kaiser <just.for.lkml@googlemail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
valdis.kletnieks@vt.edu, thockin@google.com
Subject: Re: [PATCH] AMD Thermal Interrupt Support
Date: Fri, 4 Jan 2008 23:26:37 +0100 [thread overview]
Message-ID: <20080104222637.GA19248@one.firstfloor.org> (raw)
In-Reply-To: <3f1a065b0801041333x579d0a8fs9c5535f95dd56015@mail.gmail.com>
> As to the question of Athlon RevG, it turns out that it has the same
> thermal erratum as RevF. Therefore the fact that this code only works
> with Barcelona and up is not a defficiency.
Thanks.
>
> There are 2 pending issues, to which I have received insufficient feedback:
>
> 1. Andi would like to eliminate the trampoline in mce_thermal.c, but
> no one has responded to my proposed disgusting hack on entry_64.S in
> order to do so.
There are two ways to do it:
either duplicate the entry point in entry_64.S and set different
vectors or let the asm glue jump through a call vector (use
apicinterrupt ...,*thermal_vector(%rip) ) Later is probably better.
>
> 2. Ingo pointed out that a given config file did not build. But when
The patch that was in git-x86 didn't build on 32bit. Perhaps it was a
32bit config file? Run it under "linux32" or equivalent on your distro.
> + */
> + if (therm_throt_process(1))
> + mce_log_therm_throt_event(cpu, 1);
> + /*
> + * We'll still get subsequent interrupts even if we don't clear the
> + * status bit in THERM_CTL_F3X64. Take advantage of this fact to avoid
> + * touching PCI space. (If this assumption fails at some point, we'll
> + * need to schedule_work() in order to enter a process context, so that
> + * PCI locks can be asserted for proper access. This requirement, in
PCI locks are spinlocks so they don't need process context. In PREEMPT-RT
kernels they can sleep, but there the handler will be likely already
a thread. Touching config space from interrupt context is legal, although
not very popular because it tends to be slow (but a few drivers do it)
> + /*
> + * If any of the northbridges has PCI ID 0x1103, then its thermal
> + * hardware suffers from an erratum which prevents this code from
> + * working, so abort.
Please add
* This implies it only works on Family 10h aka AMD Quad Core.
Otherwise I can just see the support questions of people asking why this
doesn't work for them.
Anyways I'm unsure about the blacklist here -- white list would
probably have been better. k8_northbridges[] will certainly include
Griffin northtbridges and who knows if TT will work there or not.
[sorry for mentioning that not earlier]
-Andi
next prev parent reply other threads:[~2008-01-04 22:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-17 18:54 [PATCH] AMD Thermal Interrupt Support Russell Leidich
2007-12-25 22:04 ` Andrew Morton
2007-12-27 18:57 ` Russell Leidich
2007-12-28 7:34 ` Andrew Morton
2007-12-28 20:40 ` Russell Leidich
2007-12-29 2:11 ` Andi Kleen
2007-12-29 2:30 ` Valdis.Kletnieks
2007-12-29 2:34 ` Andi Kleen
2007-12-29 2:57 ` Valdis.Kletnieks
2007-12-30 18:39 ` Andi Kleen
2008-01-02 19:43 ` Russell Leidich
2008-01-02 20:00 ` Andi Kleen
2008-01-02 21:12 ` Russell Leidich
2008-01-02 21:33 ` Torsten Kaiser
2008-01-02 21:50 ` Russell Leidich
2008-01-02 21:54 ` Andi Kleen
2008-01-02 22:32 ` Russell Leidich
2008-01-04 21:33 ` Russell Leidich
2008-01-04 22:26 ` Andi Kleen [this message]
2008-01-05 0:53 ` Russell Leidich
2008-01-05 13:24 ` Andi Kleen
2008-01-05 20:08 ` Russell Leidich
2008-01-08 23:42 ` Russell Leidich
2008-01-08 23:52 ` Andi Kleen
2008-01-09 2:28 ` Russell Leidich
2008-01-09 2:37 ` Andi Kleen
2008-01-11 2:21 ` Russell Leidich
2008-01-18 1:06 ` Russell Leidich
2008-02-03 0:10 ` Andrew Morton
2008-02-03 0:27 ` Harvey Harrison
2008-02-03 0:39 ` Andrew Morton
2008-02-03 0:50 ` [PATCH] x86: Remove pt_regs arg from smp_thermal_interrupt Harvey Harrison
2008-02-03 1:01 ` Harvey Harrison
2008-02-04 7:12 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2007-12-11 18:44 [PATCH] AMD Thermal Interrupt Support Russell Leidich
2007-12-11 19:13 ` Russell Leidich
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=20080104222637.GA19248@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=just.for.lkml@googlemail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rml@google.com \
--cc=tglx@linutronix.de \
--cc=thockin@google.com \
--cc=valdis.kletnieks@vt.edu \
/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.