[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>

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;