Re: [PATCH] OMAP3: PM: Add the wakeup source driver, v3

From: Kim Kyuwon <chammoru@gmail.com>
To: Kevin Hilman <khilman@deeprootsystems.com>
Cc: OMAP <linux-omap@vger.kernel.org>,
	박경민 <kyungmin.park@samsung.com>, "Paul Walmsley" <paul@pwsan.com>
Subject: Re: [PATCH] OMAP3: PM: Add the wakeup source driver, v3
Date: Tue, 5 May 2009 18:08:50 +0900	[thread overview]
Message-ID: <4d34a0a70905050208u5f64957drda5298cae027e550@mail.gmail.com> (raw)
In-Reply-To: <87my9yte7e.fsf@deeprootsystems.com>

On Thu, Apr 30, 2009 at 11:21 PM, Kevin Hilman
<khilman@deeprootsystems.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html