All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@linaro.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-omap@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<devicetree-discuss@lists.ozlabs.org>,
	Benoit Cousson <benoit.cousson@linaro.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Stephen Warren <swarren@wwwdotorg.org>
Subject: Re: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4
Date: Thu, 18 Jul 2013 15:01:17 +0300	[thread overview]
Message-ID: <51E7D90D.6070101@ti.com> (raw)
In-Reply-To: <20130718090408.GU7656@atomide.com>

Hi Tony,

On 07/18/2013 12:04 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko@ti.com> [130718 02:01]:
>> On 07/18/2013 11:09 AM, Tony Lindgren wrote:
>>
>> Don't think it's debug code - IO chain need to be rearmed after each
>> PRCM IO IRQ - otherwise IO wakeup events may be lost (at least on
>> OMAP4, OMAP5 requires more complex handling(( ).
>
> Nope, only after the mux register changes. I've verified it on
> am3730 with off-idle for both serial and wl12xx.

Unfortunately, there is a possibility to lose wake up events in case if
IO daisy chain will be rearmed (this will clean up all WAKEUPEVENT bits)
while there is some pending  WAKEUP event present. In this case, 
pcs_omap_handle_irq() will not call generic_handle_irq(wakeirq).

The below patch contains explanation of such kind of issue we've solved
in K3.4
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5ff316db224a2c3c23bfe44261275d520b4f78bb

Currently, in Mainline the same is possible on OMAP4 (which is SMP) if
some Device will be switched to idle and rearm IO chain while there is
pending WAKEUP event form USB for example. So, IO rearming need to be 
delayed until PRCM irq will be served served and PRCM irq handler should 
finally rearm IO daisy chain.


>
>> I didn't pick up your padconf patches yet -seems i need to be in sync :)
>
> Well you need those for proper wake-up event support..
>
>> Below the diff I used to verify IO wake up (It follows old IO daisy
>> chain hanlding models in hwmod before DT):
>
> ..then these changes not needed with the pinctrl-single changes.
>
> Regards,
>
> Tony
>


WARNING: multiple messages have this Message-ID (diff)
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@linaro.org>,
	linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org,
	Benoit Cousson <benoit.cousson@linaro.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Stephen Warren <swarren@wwwdotorg.org>
Subject: Re: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4
Date: Thu, 18 Jul 2013 15:01:17 +0300	[thread overview]
Message-ID: <51E7D90D.6070101@ti.com> (raw)
In-Reply-To: <20130718090408.GU7656@atomide.com>

Hi Tony,

On 07/18/2013 12:04 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko@ti.com> [130718 02:01]:
>> On 07/18/2013 11:09 AM, Tony Lindgren wrote:
>>
>> Don't think it's debug code - IO chain need to be rearmed after each
>> PRCM IO IRQ - otherwise IO wakeup events may be lost (at least on
>> OMAP4, OMAP5 requires more complex handling(( ).
>
> Nope, only after the mux register changes. I've verified it on
> am3730 with off-idle for both serial and wl12xx.

Unfortunately, there is a possibility to lose wake up events in case if
IO daisy chain will be rearmed (this will clean up all WAKEUPEVENT bits)
while there is some pending  WAKEUP event present. In this case, 
pcs_omap_handle_irq() will not call generic_handle_irq(wakeirq).

The below patch contains explanation of such kind of issue we've solved
in K3.4
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5ff316db224a2c3c23bfe44261275d520b4f78bb

Currently, in Mainline the same is possible on OMAP4 (which is SMP) if
some Device will be switched to idle and rearm IO chain while there is
pending WAKEUP event form USB for example. So, IO rearming need to be 
delayed until PRCM irq will be served served and PRCM irq handler should 
finally rearm IO daisy chain.


>
>> I didn't pick up your padconf patches yet -seems i need to be in sync :)
>
> Well you need those for proper wake-up event support..
>
>> Below the diff I used to verify IO wake up (It follows old IO daisy
>> chain hanlding models in hwmod before DT):
>
> ..then these changes not needed with the pinctrl-single changes.
>
> Regards,
>
> Tony
>


WARNING: multiple messages have this Message-ID (diff)
From: grygorii.strashko@ti.com (Grygorii Strashko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4
Date: Thu, 18 Jul 2013 15:01:17 +0300	[thread overview]
Message-ID: <51E7D90D.6070101@ti.com> (raw)
In-Reply-To: <20130718090408.GU7656@atomide.com>

Hi Tony,

On 07/18/2013 12:04 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko@ti.com> [130718 02:01]:
>> On 07/18/2013 11:09 AM, Tony Lindgren wrote:
>>
>> Don't think it's debug code - IO chain need to be rearmed after each
>> PRCM IO IRQ - otherwise IO wakeup events may be lost (at least on
>> OMAP4, OMAP5 requires more complex handling(( ).
>
> Nope, only after the mux register changes. I've verified it on
> am3730 with off-idle for both serial and wl12xx.

Unfortunately, there is a possibility to lose wake up events in case if
IO daisy chain will be rearmed (this will clean up all WAKEUPEVENT bits)
while there is some pending  WAKEUP event present. In this case, 
pcs_omap_handle_irq() will not call generic_handle_irq(wakeirq).

The below patch contains explanation of such kind of issue we've solved
in K3.4
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5ff316db224a2c3c23bfe44261275d520b4f78bb

Currently, in Mainline the same is possible on OMAP4 (which is SMP) if
some Device will be switched to idle and rearm IO chain while there is
pending WAKEUP event form USB for example. So, IO rearming need to be 
delayed until PRCM irq will be served served and PRCM irq handler should 
finally rearm IO daisy chain.


>
>> I didn't pick up your padconf patches yet -seems i need to be in sync :)
>
> Well you need those for proper wake-up event support..
>
>> Below the diff I used to verify IO wake up (It follows old IO daisy
>> chain hanlding models in hwmod before DT):
>
> ..then these changes not needed with the pinctrl-single changes.
>
> Regards,
>
> Tony
>

  reply	other threads:[~2013-07-18 12:02 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17 11:41 [PATCH 0/3] ARM: OMAP2+: omap_device: add dynamic pinctrl handling Grygorii Strashko
2013-07-17 11:41 ` Grygorii Strashko
2013-07-17 11:41 ` Grygorii Strashko
2013-07-17 11:41 ` [PATCH 1/3] pinctrl: rollback check for !dev->pins in pinctrl_pm_select*() APIs Grygorii Strashko
2013-07-17 11:41   ` Grygorii Strashko
2013-07-17 11:41   ` Grygorii Strashko
2013-07-17 15:40   ` Tony Lindgren
2013-07-17 15:40     ` Tony Lindgren
2013-07-26 23:22     ` Linus Walleij
2013-07-26 23:22       ` Linus Walleij
2013-07-26 23:22       ` Linus Walleij
2013-07-17 11:41 ` [PATCH 2/3] ARM: OMAP2+: omap_device: add pinctrl handling Grygorii Strashko
2013-07-17 11:41   ` Grygorii Strashko
2013-07-17 11:41   ` Grygorii Strashko
2013-07-17 15:38   ` Tony Lindgren
2013-07-17 15:38     ` Tony Lindgren
2013-07-17 16:56     ` Grygorii Strashko
2013-07-17 16:56       ` Grygorii Strashko
2013-07-17 16:56       ` Grygorii Strashko
2013-07-18  8:14       ` Tony Lindgren
2013-07-18  8:14         ` Tony Lindgren
2013-07-18 11:22         ` Grygorii Strashko
2013-07-18 11:22           ` Grygorii Strashko
2013-07-18 11:22           ` Grygorii Strashko
2013-07-17 11:41 ` [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4 Grygorii Strashko
2013-07-17 11:41   ` Grygorii Strashko
2013-07-17 11:41   ` Grygorii Strashko
2013-07-17 15:32   ` Tony Lindgren
2013-07-17 15:32     ` Tony Lindgren
2013-07-17 15:32     ` Tony Lindgren
2013-07-17 16:41     ` Grygorii Strashko
2013-07-17 16:41       ` Grygorii Strashko
2013-07-17 16:41       ` Grygorii Strashko
2013-07-18  8:09       ` Tony Lindgren
2013-07-18  8:09         ` Tony Lindgren
2013-07-18  8:09         ` Tony Lindgren
2013-07-18  8:54         ` Grygorii Strashko
2013-07-18  8:54           ` Grygorii Strashko
2013-07-18  8:54           ` Grygorii Strashko
2013-07-18  9:04           ` Tony Lindgren
2013-07-18  9:04             ` Tony Lindgren
2013-07-18 12:01             ` Grygorii Strashko [this message]
2013-07-18 12:01               ` Grygorii Strashko
2013-07-18 12:01               ` Grygorii Strashko
2013-07-17 11:57 ` [PATCH 0/3] ARM: OMAP2+: omap_device: add dynamic pinctrl handling Roger Quadros
2013-07-17 11:57   ` Roger Quadros
2013-07-17 11:57   ` Roger Quadros
2013-07-17 12:30   ` Grygorii Strashko
2013-07-17 12:30     ` Grygorii Strashko
2013-07-17 12:30     ` Grygorii Strashko
2013-07-18  6:44     ` Roger Quadros
2013-07-18  6:44       ` Roger Quadros
2013-07-18  6:44       ` Roger Quadros

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=51E7D90D.6070101@ti.com \
    --to=grygorii.strashko@ti.com \
    --cc=benoit.cousson@linaro.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=khilman@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=tony@atomide.com \
    /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.