aboutsummaryrefslogtreecommitdiff
path: root/drivers/macintosh
diff options
context:
space:
mode:
authorBenjamin Herrenschmidt2008-02-07 14:29:43 +1100
committerPaul Mackerras2008-02-08 19:52:35 +1100
commit592a607bbc053bc6f614a0e619326009f4b3829e (patch)
treef6deedbe40c525c8fe088e08f620cd76cb865591 /drivers/macintosh
parenta4ffc0a0b240a29cbe489f6db9dae112a49ef1c1 (diff)
[POWERPC] Disable G5 NAP mode during SMU commands on U3
It appears that with the U3 northbridge, if the processor is in NAP mode the whole time while waiting for an SMU command to complete, then the SMU will fail. It could be related to the weird backward mechanism the SMU uses to get to system memory via i2c to the northbridge that doesn't operate properly when the said bridge is in napping along with the CPU. That is on U3 at least, U4 doesn't seem to be affected. This didn't show before NO_HZ as the timer wakeup was enough to make it work it seems, but that is no longer the case. This fixes it by disabling NAP mode on those machines while an SMU command is in flight. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'drivers/macintosh')
-rw-r--r--drivers/macintosh/smu.c25
1 files changed, 24 insertions, 1 deletions
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index 8ba49385c3ff..77ad192962c5 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -85,6 +85,7 @@ struct smu_device {
u32 cmd_buf_abs; /* command buffer absolute */
struct list_head cmd_list;
struct smu_cmd *cmd_cur; /* pending command */
+ int broken_nap;
struct list_head cmd_i2c_list;
struct smu_i2c_cmd *cmd_i2c_cur; /* pending i2c command */
struct timer_list i2c_timer;
@@ -135,6 +136,19 @@ static void smu_start_cmd(void)
fend = faddr + smu->cmd_buf->length + 2;
flush_inval_dcache_range(faddr, fend);
+
+ /* We also disable NAP mode for the duration of the command
+ * on U3 based machines.
+ * This is slightly racy as it can be written back to 1 by a sysctl
+ * but that never happens in practice. There seem to be an issue with
+ * U3 based machines such as the iMac G5 where napping for the
+ * whole duration of the command prevents the SMU from fetching it
+ * from memory. This might be related to the strange i2c based
+ * mechanism the SMU uses to access memory.
+ */
+ if (smu->broken_nap)
+ powersave_nap = 0;
+
/* This isn't exactly a DMA mapping here, I suspect
* the SMU is actually communicating with us via i2c to the
* northbridge or the CPU to access RAM.
@@ -211,6 +225,10 @@ static irqreturn_t smu_db_intr(int irq, void *arg)
misc = cmd->misc;
mb();
cmd->status = rc;
+
+ /* Re-enable NAP mode */
+ if (smu->broken_nap)
+ powersave_nap = 1;
bail:
/* Start next command if any */
smu_start_cmd();
@@ -461,7 +479,7 @@ int __init smu_init (void)
if (np == NULL)
return -ENODEV;
- printk(KERN_INFO "SMU driver %s %s\n", VERSION, AUTHOR);
+ printk(KERN_INFO "SMU: Driver %s %s\n", VERSION, AUTHOR);
if (smu_cmdbuf_abs == 0) {
printk(KERN_ERR "SMU: Command buffer not allocated !\n");
@@ -533,6 +551,11 @@ int __init smu_init (void)
goto fail;
}
+ /* U3 has an issue with NAP mode when issuing SMU commands */
+ smu->broken_nap = pmac_get_uninorth_variant() < 4;
+ if (smu->broken_nap)
+ printk(KERN_INFO "SMU: using NAP mode workaround\n");
+
sys_ctrler = SYS_CTRLER_SMU;
return 0;