On Thu, Apr 30, 2009 at 11:21 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: >>> Also, I still think the WKST register reading should be done in the >>> PRCM interrupt handler. In your previous attempt, you were seeing a >>> bunch of non-device wakeup related interrupts. Can you try again >>> with the attached patch (thanks to Paul Walmseley) which should help >>> us debug why you were seeing spurious PRCM interrupts. >> >> First of all, sorry for giving you the wrong information in the >> previous mail. I found that we actually have configured GPTIMER12 as >> the system timer. And I tried with the attached patch, but I can't >> see any debug message. However even now, PRCM interrupt handler is >> invoked quite often due to the system timer. > > That's what I assumed was happening. > >> As far as I know, after Peter's [OMAP3: PM: CPUidle: Add new >> lower-latency C1 state] patch is applied, the system is in 'wfi' state >> in every idle state. So whenever the system timer wake up the system >> from idle, I think PRCM interrupt occurs. Do you think still the WKST >> register should be read in the PRCM interrupt handler? ;) > > Yes. The WKST registers are already being read in the handler so they > can be properly cleared. All you are adding is the saving of them. > > In addition, you should not enter idle between the time the system > wakes from resume and your resume handler runs so you should be able > to get the correct WKST values. OK, Your idea is more reasonable. I modified as you said. thanks. >>> Also, I know we discussed this before, but I think the GPIO wakeup >>> source stuff really belongs in a separate patch, and if you think it >>> is still useful, and cannot be done by just enabling a GPIO IRQ from >>> the board file, I suggest you propose a patch to the generic GPIO >>> layer to add this interface. >> >> OK, I will remove this GPIO wakeup feature. But I want to know more >> detailed information about wakeup event . So, instead of using the >> GPIO wakeup, I'm planning using WAKEUPEVENT bit in CONTROL_PADCONF_x >> registers. > > That sounds OK. The current mux layer is lacking any knowledge of the > wake bits in the PADCONF regs, so I'd be interested in any ideas you > have of adding that support. I added my ideas about CONTROL_PADCONF_x into the new version of wake source driver. I will send it soon. Please review this new version again and feel free to give your opinion. Regards, Kyuwon (규원) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
