From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org,
Lior Amsalem <alior@marvell.com>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Jason Cooper <jason@lakedaemon.net>,
Tawfik Bayouk <tawfik@marvell.com>, Andrew Lunn <andrew@lunn.ch>,
Wim Van Sebroeck <wim@iguana.be>,
Gregory Clement <gregory.clement@free-electrons.com>
Subject: Re: [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
Date: Wed, 22 Jan 2014 21:31:50 +0100 [thread overview]
Message-ID: <52E02AB6.7040104@gmail.com> (raw)
In-Reply-To: <20140122173417.GT18269@obsidianresearch.com>
On 01/22/2014 06:34 PM, Jason Gunthorpe wrote:
> On Wed, Jan 22, 2014 at 01:49:05PM -0300, Ezequiel Garcia wrote:
>>> Looking at this patch in isolation it looks to me like the clear
>>> bridge lines should be replaced with a request_irq (as that does the
>>> clear) - is the request_irq in the wrong spot?
>>
>> In that case, I thought that requesting the IRQ at probe time was enough
>> to ensure the BRIDGE_CAUSE would be cleared by the time the watchdog is
>> started. However, after reading through the irqchip code again, I'm no longer
>> sure this is the case.
>
> The watchdog should ideally be fully stopped before request_irq so
> there is no possible race.
>
>> It looks like the BRIDGE_CAUSE register is cleared when the interruption
>> is acked (which happens in the handler if I understood the code right).
>> So requesting the IRQ is useless...
>
> IMHO, the IRQ stuff should clear out pending edge triggered interrupts
> at request_irq time. It makes no sense to take an interrupt for a
> stale edge event.
>
> I had always assumed the core code did this via irq_gc_ack_clr_bit -
> but I don't see an obvious path..
>
>> Sebastian: If the above is correct, do you think we can add a cause clear to
>> the orion irqchip? (supposing it's harmful) Something like this:
Ezequiel,
irqchip/irq-orion.c does mask all interrupts but you are right, it
should also clear pending interrupts right after that.
So
/* mask all interrupts */
writel(0, gc->reg_base + ORION_BRIDGE_IRQ_MASK);
should become
/* mask and clear all interrupts */
writel(0, gc->reg_base + ORION_BRIDGE_IRQ_MASK);
writel(~0, gc->reg_base + ORION_BRIDGE_IRQ_CAUSE);
Could also be clear on write 0, I'll check that. I already had some
beer, so I'll postpone any patches till tomorrow.
Clearing BRIDGE_CAUSE will only clear all currently pending upstream
IRQs, of course. If WDT IRQ will be re-raised right after that in
BRIDGE_CAUSE depends on the actual HW implementation, i.e. we do no
clear the causing IRQ itself but just what it raised in BRIDGE_CAUSE.
So, you should also clear WDT's irq in the driver yourself to clear a
possible pending upstream BRIDGE_CAUSE.
Sebastian
WARNING: multiple messages have this Message-ID (diff)
From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
Date: Wed, 22 Jan 2014 21:31:50 +0100 [thread overview]
Message-ID: <52E02AB6.7040104@gmail.com> (raw)
In-Reply-To: <20140122173417.GT18269@obsidianresearch.com>
On 01/22/2014 06:34 PM, Jason Gunthorpe wrote:
> On Wed, Jan 22, 2014 at 01:49:05PM -0300, Ezequiel Garcia wrote:
>>> Looking at this patch in isolation it looks to me like the clear
>>> bridge lines should be replaced with a request_irq (as that does the
>>> clear) - is the request_irq in the wrong spot?
>>
>> In that case, I thought that requesting the IRQ at probe time was enough
>> to ensure the BRIDGE_CAUSE would be cleared by the time the watchdog is
>> started. However, after reading through the irqchip code again, I'm no longer
>> sure this is the case.
>
> The watchdog should ideally be fully stopped before request_irq so
> there is no possible race.
>
>> It looks like the BRIDGE_CAUSE register is cleared when the interruption
>> is acked (which happens in the handler if I understood the code right).
>> So requesting the IRQ is useless...
>
> IMHO, the IRQ stuff should clear out pending edge triggered interrupts
> at request_irq time. It makes no sense to take an interrupt for a
> stale edge event.
>
> I had always assumed the core code did this via irq_gc_ack_clr_bit -
> but I don't see an obvious path..
>
>> Sebastian: If the above is correct, do you think we can add a cause clear to
>> the orion irqchip? (supposing it's harmful) Something like this:
Ezequiel,
irqchip/irq-orion.c does mask all interrupts but you are right, it
should also clear pending interrupts right after that.
So
/* mask all interrupts */
writel(0, gc->reg_base + ORION_BRIDGE_IRQ_MASK);
should become
/* mask and clear all interrupts */
writel(0, gc->reg_base + ORION_BRIDGE_IRQ_MASK);
writel(~0, gc->reg_base + ORION_BRIDGE_IRQ_CAUSE);
Could also be clear on write 0, I'll check that. I already had some
beer, so I'll postpone any patches till tomorrow.
Clearing BRIDGE_CAUSE will only clear all currently pending upstream
IRQs, of course. If WDT IRQ will be re-raised right after that in
BRIDGE_CAUSE depends on the actual HW implementation, i.e. we do no
clear the causing IRQ itself but just what it raised in BRIDGE_CAUSE.
So, you should also clear WDT's irq in the driver yourself to clear a
possible pending upstream BRIDGE_CAUSE.
Sebastian
WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>,
Ezequiel Garcia
<ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Lior Amsalem <alior-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
Thomas Petazzoni
<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
Tawfik Bayouk <tawfik-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>,
Wim Van Sebroeck <wim-IQzOog9fTRqzQB+pC5nmwQ@public.gmane.org>,
Gregory Clement
<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Subject: Re: [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
Date: Wed, 22 Jan 2014 21:31:50 +0100 [thread overview]
Message-ID: <52E02AB6.7040104@gmail.com> (raw)
In-Reply-To: <20140122173417.GT18269-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On 01/22/2014 06:34 PM, Jason Gunthorpe wrote:
> On Wed, Jan 22, 2014 at 01:49:05PM -0300, Ezequiel Garcia wrote:
>>> Looking at this patch in isolation it looks to me like the clear
>>> bridge lines should be replaced with a request_irq (as that does the
>>> clear) - is the request_irq in the wrong spot?
>>
>> In that case, I thought that requesting the IRQ at probe time was enough
>> to ensure the BRIDGE_CAUSE would be cleared by the time the watchdog is
>> started. However, after reading through the irqchip code again, I'm no longer
>> sure this is the case.
>
> The watchdog should ideally be fully stopped before request_irq so
> there is no possible race.
>
>> It looks like the BRIDGE_CAUSE register is cleared when the interruption
>> is acked (which happens in the handler if I understood the code right).
>> So requesting the IRQ is useless...
>
> IMHO, the IRQ stuff should clear out pending edge triggered interrupts
> at request_irq time. It makes no sense to take an interrupt for a
> stale edge event.
>
> I had always assumed the core code did this via irq_gc_ack_clr_bit -
> but I don't see an obvious path..
>
>> Sebastian: If the above is correct, do you think we can add a cause clear to
>> the orion irqchip? (supposing it's harmful) Something like this:
Ezequiel,
irqchip/irq-orion.c does mask all interrupts but you are right, it
should also clear pending interrupts right after that.
So
/* mask all interrupts */
writel(0, gc->reg_base + ORION_BRIDGE_IRQ_MASK);
should become
/* mask and clear all interrupts */
writel(0, gc->reg_base + ORION_BRIDGE_IRQ_MASK);
writel(~0, gc->reg_base + ORION_BRIDGE_IRQ_CAUSE);
Could also be clear on write 0, I'll check that. I already had some
beer, so I'll postpone any patches till tomorrow.
Clearing BRIDGE_CAUSE will only clear all currently pending upstream
IRQs, of course. If WDT IRQ will be re-raised right after that in
BRIDGE_CAUSE depends on the actual HW implementation, i.e. we do no
clear the causing IRQ itself but just what it raised in BRIDGE_CAUSE.
So, you should also clear WDT's irq in the driver yourself to clear a
possible pending upstream BRIDGE_CAUSE.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-01-22 20:31 UTC|newest]
Thread overview: 192+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-21 9:12 [PATCH v2 00/15] Armada 370/XP watchdog support Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 01/15] ARM: Introduce atomic MMIO modify Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:45 ` Arnd Bergmann
2014-01-21 9:45 ` Arnd Bergmann
2014-01-21 9:45 ` Arnd Bergmann
2014-01-21 10:46 ` Ezequiel Garcia
2014-01-21 10:46 ` Ezequiel Garcia
2014-01-21 10:46 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 02/15] clocksource: orion: Use atomic access for shared registers Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:46 ` Arnd Bergmann
2014-01-21 9:46 ` Arnd Bergmann
2014-01-21 9:46 ` Arnd Bergmann
2014-01-21 9:58 ` Sebastian Hesselbarth
2014-01-21 9:58 ` Sebastian Hesselbarth
2014-01-21 9:58 ` Sebastian Hesselbarth
2014-01-21 10:54 ` Arnd Bergmann
2014-01-21 10:54 ` Arnd Bergmann
2014-01-21 10:54 ` Arnd Bergmann
2014-01-21 11:02 ` Andrew Lunn
2014-01-21 11:02 ` Andrew Lunn
2014-01-21 11:02 ` Andrew Lunn
2014-01-21 9:57 ` Daniel Lezcano
2014-01-21 9:57 ` Daniel Lezcano
2014-01-21 9:57 ` Daniel Lezcano
2014-01-21 10:53 ` Ezequiel Garcia
2014-01-21 10:53 ` Ezequiel Garcia
2014-01-21 10:53 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 03/15] watchdog: " Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:19 ` Fabio Estevam
2014-01-21 9:19 ` Fabio Estevam
2014-01-21 9:19 ` Fabio Estevam
2014-01-21 9:42 ` Ezequiel Garcia
2014-01-21 9:42 ` Ezequiel Garcia
2014-01-21 9:42 ` Ezequiel Garcia
2014-01-21 9:54 ` Arnd Bergmann
2014-01-21 9:54 ` Arnd Bergmann
2014-01-21 9:54 ` Arnd Bergmann
2014-01-21 10:13 ` Andrew Lunn
2014-01-21 10:13 ` Andrew Lunn
2014-01-21 10:13 ` Andrew Lunn
2014-01-21 9:12 ` [PATCH v2 04/15] watchdog: orion: Handle IRQ Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 05/15] watchdog: orion: Make RSTOUT register a separate resource Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 23:33 ` Jason Gunthorpe
2014-01-21 23:33 ` Jason Gunthorpe
2014-01-21 23:33 ` Jason Gunthorpe
2014-01-22 9:48 ` Arnd Bergmann
2014-01-22 9:48 ` Arnd Bergmann
2014-01-22 9:48 ` Arnd Bergmann
2014-01-22 16:21 ` Ezequiel Garcia
2014-01-22 16:21 ` Ezequiel Garcia
2014-01-22 16:21 ` Ezequiel Garcia
2014-01-22 18:01 ` Ezequiel Garcia
2014-01-22 18:01 ` Ezequiel Garcia
2014-01-22 18:01 ` Ezequiel Garcia
2014-01-22 18:14 ` Jason Gunthorpe
2014-01-22 18:14 ` Jason Gunthorpe
2014-01-22 18:14 ` Jason Gunthorpe
2014-01-22 18:21 ` Arnd Bergmann
2014-01-22 18:21 ` Arnd Bergmann
2014-01-22 18:21 ` Arnd Bergmann
2014-01-22 18:29 ` Ezequiel Garcia
2014-01-22 18:29 ` Ezequiel Garcia
2014-01-22 18:29 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 23:35 ` Jason Gunthorpe
2014-01-21 23:35 ` Jason Gunthorpe
2014-01-21 23:35 ` Jason Gunthorpe
2014-01-22 16:49 ` Ezequiel Garcia
2014-01-22 16:49 ` Ezequiel Garcia
2014-01-22 16:49 ` Ezequiel Garcia
2014-01-22 17:34 ` Jason Gunthorpe
2014-01-22 17:34 ` Jason Gunthorpe
2014-01-22 17:34 ` Jason Gunthorpe
2014-01-22 17:45 ` Ezequiel Garcia
2014-01-22 17:45 ` Ezequiel Garcia
2014-01-22 17:45 ` Ezequiel Garcia
2014-01-22 17:50 ` Jason Gunthorpe
2014-01-22 17:50 ` Jason Gunthorpe
2014-01-22 17:50 ` Jason Gunthorpe
2014-01-22 18:03 ` Ezequiel Garcia
2014-01-22 18:03 ` Ezequiel Garcia
2014-01-22 18:03 ` Ezequiel Garcia
2014-01-22 20:31 ` Sebastian Hesselbarth [this message]
2014-01-22 20:31 ` Sebastian Hesselbarth
2014-01-22 20:31 ` Sebastian Hesselbarth
2014-01-22 20:52 ` Jason Gunthorpe
2014-01-22 20:52 ` Jason Gunthorpe
2014-01-22 20:52 ` Jason Gunthorpe
2014-01-22 22:12 ` Ezequiel Garcia
2014-01-22 22:12 ` Ezequiel Garcia
2014-01-22 22:12 ` Ezequiel Garcia
2014-01-22 22:31 ` Jason Gunthorpe
2014-01-22 22:31 ` Jason Gunthorpe
2014-01-22 22:31 ` Jason Gunthorpe
2014-01-22 22:56 ` Ezequiel Garcia
2014-01-22 22:56 ` Ezequiel Garcia
2014-01-22 22:56 ` Ezequiel Garcia
2014-01-23 0:03 ` Sebastian Hesselbarth
2014-01-23 0:03 ` Sebastian Hesselbarth
2014-01-23 0:03 ` Sebastian Hesselbarth
2014-01-23 0:19 ` Jason Gunthorpe
2014-01-23 0:19 ` Jason Gunthorpe
2014-01-23 0:19 ` Jason Gunthorpe
2014-01-23 0:35 ` Sebastian Hesselbarth
2014-01-23 0:35 ` Sebastian Hesselbarth
2014-01-23 0:35 ` Sebastian Hesselbarth
2014-01-23 12:04 ` Ezequiel Garcia
2014-01-23 12:04 ` Ezequiel Garcia
2014-01-23 12:04 ` Ezequiel Garcia
2014-01-22 23:49 ` Sebastian Hesselbarth
2014-01-22 23:49 ` Sebastian Hesselbarth
2014-01-22 23:49 ` Sebastian Hesselbarth
2014-01-23 11:10 ` Ezequiel Garcia
2014-01-23 11:10 ` Ezequiel Garcia
2014-01-23 11:10 ` Ezequiel Garcia
2014-01-23 11:54 ` Ezequiel Garcia
2014-01-23 11:54 ` Ezequiel Garcia
2014-01-23 11:54 ` Ezequiel Garcia
2014-01-23 21:15 ` Sebastian Hesselbarth
2014-01-23 21:15 ` Sebastian Hesselbarth
2014-01-23 21:15 ` Sebastian Hesselbarth
2014-01-21 9:12 ` [PATCH v2 07/15] watchdog: orion: Introduce an orion_watchdog device structure Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 08/15] watchdog: orion: Introduce per-compatible of_device_id data Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 09/15] watchdog: orion: Add per-compatible clock initialization Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:18 ` Fabio Estevam
2014-01-21 9:18 ` Fabio Estevam
2014-01-21 9:18 ` Fabio Estevam
2014-01-21 9:43 ` Ezequiel Garcia
2014-01-21 9:43 ` Ezequiel Garcia
2014-01-21 9:43 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 10/15] watchdog: orion: Add per-compatible watchdog start implementation Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 11/15] watchdog: orion: Add support for Armada 370 and Armada XP SoC Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 12/15] ARM: mvebu: Enable Armada 370/XP watchdog in the devicetree Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 13/15] ARM: kirkwood: Add RSTOUT 'reg' entry to devicetree Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` [PATCH v2 14/15] watchdog: orion: Allow to build on any Orion platform Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:41 ` Sebastian Hesselbarth
2014-01-21 9:41 ` Sebastian Hesselbarth
2014-01-21 9:41 ` Sebastian Hesselbarth
2014-01-21 9:45 ` Andrew Lunn
2014-01-21 9:45 ` Andrew Lunn
2014-01-21 9:45 ` Andrew Lunn
2014-01-21 10:04 ` Ezequiel Garcia
2014-01-21 10:04 ` Ezequiel Garcia
2014-01-21 10:04 ` Ezequiel Garcia
2014-01-21 11:06 ` Removing PLAT_ORION dependency from ARCH_MVEBU (Was Re: [PATCH v2 14/15] watchdog: orion: Allow to build on any Orion platform) Ezequiel Garcia
2014-01-21 11:06 ` Ezequiel Garcia
2014-01-21 11:06 ` Ezequiel Garcia
2014-01-21 11:44 ` Sebastian Hesselbarth
2014-01-21 11:44 ` Sebastian Hesselbarth
2014-01-21 11:44 ` Sebastian Hesselbarth
2014-01-21 9:12 ` [PATCH v2 15/15] ARM: mvebu: Enable watchdog support in defconfig Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 9:12 ` Ezequiel Garcia
2014-01-21 12:47 ` Jason Cooper
2014-01-21 12:47 ` Jason Cooper
2014-01-21 12:47 ` Jason Cooper
2014-01-21 12:53 ` Andrew Lunn
2014-01-21 12:53 ` Andrew Lunn
2014-01-21 12:53 ` Andrew Lunn
2014-01-21 12:57 ` Jason Cooper
2014-01-21 12:57 ` Jason Cooper
2014-01-21 12:57 ` Jason Cooper
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=52E02AB6.7040104@gmail.com \
--to=sebastian.hesselbarth@gmail.com \
--cc=alior@marvell.com \
--cc=andrew@lunn.ch \
--cc=devicetree@vger.kernel.org \
--cc=ezequiel.garcia@free-electrons.com \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=tawfik@marvell.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=wim@iguana.be \
/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.