From: boris.brezillon@free-electrons.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/5] irqchip: add dumb demultiplexer implementation
Date: Wed, 14 Jan 2015 09:22:35 +0100 [thread overview]
Message-ID: <20150114092235.032dc986@bbrezillon> (raw)
In-Reply-To: <CAL_JsqJ5DSo6jmAuHPDdV6pMca8BVbg5V-GZ5=2qu96_QYXMtQ@mail.gmail.com>
Hi Rob,
On Tue, 13 Jan 2015 21:26:42 -0600
Rob Herring <robherring2@gmail.com> wrote:
> On Tue, Jan 13, 2015 at 12:46 PM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > Some interrupt controllers are multiplexing several peripheral IRQs on
> > a single interrupt line.
> > While this is not a problem for most IRQs (as long as all peripherals
> > request the interrupt with IRQF_SHARED flag set), multiplexing timers and
> > other type of peripherals will generate a WARNING (mixing IRQF_NO_SUSPEND
> > and !IRQF_NO_SUSPEND is prohibited).
> >
> > Create a dumb irq demultiplexer which simply forwards interrupts to all
> > peripherals (exactly what's happening with IRQ_SHARED) but keep a unique
> > irq number for each peripheral, thus preventing the IRQF_NO_SUSPEND
> > and !IRQF_NO_SUSPEND mix on a given interrupt.
>
> This really seems like a work-around for how IRQF_SHARED works. It
> seems like what is really desired is just per handler disabling.
Like what I proposed here [1] ?
> It is
> fragile in that devices can deadlock the system if the drivers don't
> disable the interrupt source before calling disable_irq.
Not exactly deadlock since spurious interrupt detection is implemented,
but yes, things won't work as expected.
> But unlike
> IRQF_SHARED, there is nothing explicit in the driver indicating it is
> designed to work properly with a shared interrupt line.
>
> I see no reason to accept this into DT either. We already can support
> shared lines and modeling an OR gate as an interrupt controller is
> pointless.
Okay, I guess I'll let DT and irq maintainers decide what is preferable
here (I already spent much time than I first expected to remove this
warning in a proper way).
Best Regards,
Boris
[1]https://lkml.org/lkml/2014/12/15/552
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
Nicolas Ferre
<nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
Jean-Christophe Plagniol-Villard
<plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>,
Alexandre Belloni
<alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
"Rafael J. Wysocki"
<rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v2 1/5] irqchip: add dumb demultiplexer implementation
Date: Wed, 14 Jan 2015 09:22:35 +0100 [thread overview]
Message-ID: <20150114092235.032dc986@bbrezillon> (raw)
In-Reply-To: <CAL_JsqJ5DSo6jmAuHPDdV6pMca8BVbg5V-GZ5=2qu96_QYXMtQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
On Tue, 13 Jan 2015 21:26:42 -0600
Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Jan 13, 2015 at 12:46 PM, Boris Brezillon
> <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > Some interrupt controllers are multiplexing several peripheral IRQs on
> > a single interrupt line.
> > While this is not a problem for most IRQs (as long as all peripherals
> > request the interrupt with IRQF_SHARED flag set), multiplexing timers and
> > other type of peripherals will generate a WARNING (mixing IRQF_NO_SUSPEND
> > and !IRQF_NO_SUSPEND is prohibited).
> >
> > Create a dumb irq demultiplexer which simply forwards interrupts to all
> > peripherals (exactly what's happening with IRQ_SHARED) but keep a unique
> > irq number for each peripheral, thus preventing the IRQF_NO_SUSPEND
> > and !IRQF_NO_SUSPEND mix on a given interrupt.
>
> This really seems like a work-around for how IRQF_SHARED works. It
> seems like what is really desired is just per handler disabling.
Like what I proposed here [1] ?
> It is
> fragile in that devices can deadlock the system if the drivers don't
> disable the interrupt source before calling disable_irq.
Not exactly deadlock since spurious interrupt detection is implemented,
but yes, things won't work as expected.
> But unlike
> IRQF_SHARED, there is nothing explicit in the driver indicating it is
> designed to work properly with a shared interrupt line.
>
> I see no reason to accept this into DT either. We already can support
> shared lines and modeling an OR gate as an interrupt controller is
> pointless.
Okay, I guess I'll let DT and irq maintainers decide what is preferable
here (I already spent much time than I first expected to remove this
warning in a proper way).
Best Regards,
Boris
[1]https://lkml.org/lkml/2014/12/15/552
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Rob Herring <robherring2@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Nicolas Ferre <nicolas.ferre@atmel.com>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Alexandre Belloni <alexandre.belloni@free-electrons.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] irqchip: add dumb demultiplexer implementation
Date: Wed, 14 Jan 2015 09:22:35 +0100 [thread overview]
Message-ID: <20150114092235.032dc986@bbrezillon> (raw)
In-Reply-To: <CAL_JsqJ5DSo6jmAuHPDdV6pMca8BVbg5V-GZ5=2qu96_QYXMtQ@mail.gmail.com>
Hi Rob,
On Tue, 13 Jan 2015 21:26:42 -0600
Rob Herring <robherring2@gmail.com> wrote:
> On Tue, Jan 13, 2015 at 12:46 PM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > Some interrupt controllers are multiplexing several peripheral IRQs on
> > a single interrupt line.
> > While this is not a problem for most IRQs (as long as all peripherals
> > request the interrupt with IRQF_SHARED flag set), multiplexing timers and
> > other type of peripherals will generate a WARNING (mixing IRQF_NO_SUSPEND
> > and !IRQF_NO_SUSPEND is prohibited).
> >
> > Create a dumb irq demultiplexer which simply forwards interrupts to all
> > peripherals (exactly what's happening with IRQ_SHARED) but keep a unique
> > irq number for each peripheral, thus preventing the IRQF_NO_SUSPEND
> > and !IRQF_NO_SUSPEND mix on a given interrupt.
>
> This really seems like a work-around for how IRQF_SHARED works. It
> seems like what is really desired is just per handler disabling.
Like what I proposed here [1] ?
> It is
> fragile in that devices can deadlock the system if the drivers don't
> disable the interrupt source before calling disable_irq.
Not exactly deadlock since spurious interrupt detection is implemented,
but yes, things won't work as expected.
> But unlike
> IRQF_SHARED, there is nothing explicit in the driver indicating it is
> designed to work properly with a shared interrupt line.
>
> I see no reason to accept this into DT either. We already can support
> shared lines and modeling an OR gate as an interrupt controller is
> pointless.
Okay, I guess I'll let DT and irq maintainers decide what is preferable
here (I already spent much time than I first expected to remove this
warning in a proper way).
Best Regards,
Boris
[1]https://lkml.org/lkml/2014/12/15/552
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-01-14 8:22 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-13 18:46 [PATCH v2 0/5] ARM: at91: fix irq_pm_install_action WARNING Boris Brezillon
2015-01-13 18:46 ` Boris Brezillon
2015-01-13 18:46 ` Boris Brezillon
2015-01-13 18:46 ` [PATCH v2 1/5] irqchip: add dumb demultiplexer implementation Boris Brezillon
2015-01-13 18:46 ` Boris Brezillon
2015-01-13 18:46 ` Boris Brezillon
2015-01-13 21:00 ` Thomas Gleixner
2015-01-13 21:00 ` Thomas Gleixner
2015-01-14 8:31 ` Boris Brezillon
2015-01-14 8:31 ` Boris Brezillon
2015-01-14 3:26 ` Rob Herring
2015-01-14 3:26 ` Rob Herring
2015-01-14 3:26 ` Rob Herring
2015-01-14 8:22 ` Boris Brezillon [this message]
2015-01-14 8:22 ` Boris Brezillon
2015-01-14 8:22 ` Boris Brezillon
2015-01-14 10:36 ` Thomas Gleixner
2015-01-14 10:36 ` Thomas Gleixner
2015-01-14 10:36 ` Thomas Gleixner
2015-01-14 22:24 ` Rob Herring
2015-01-14 22:24 ` Rob Herring
2015-01-14 22:24 ` Rob Herring
2015-01-14 22:55 ` Boris Brezillon
2015-01-14 22:55 ` Boris Brezillon
2015-01-14 22:55 ` Boris Brezillon
2015-01-15 9:44 ` Nicolas Ferre
2015-01-15 9:44 ` Nicolas Ferre
2015-01-15 9:44 ` Nicolas Ferre
2015-01-15 9:11 ` Thomas Gleixner
2015-01-15 9:11 ` Thomas Gleixner
2015-01-15 9:11 ` Thomas Gleixner
2015-01-15 9:26 ` Nicolas Ferre
2015-01-15 9:26 ` Nicolas Ferre
2015-01-15 9:26 ` Nicolas Ferre
2015-01-15 15:40 ` Rob Herring
2015-01-15 15:40 ` Rob Herring
2015-01-15 15:40 ` Rob Herring
2015-01-20 13:08 ` Thomas Gleixner
2015-01-20 13:08 ` Thomas Gleixner
2015-01-20 20:07 ` Rob Herring
2015-01-14 13:36 ` Nicolas Ferre
2015-01-14 13:36 ` Nicolas Ferre
2015-01-14 13:36 ` Nicolas Ferre
2015-01-14 14:03 ` Boris Brezillon
2015-01-14 14:03 ` Boris Brezillon
2015-01-14 14:03 ` Boris Brezillon
2015-01-14 14:43 ` Nicolas Ferre
2015-01-14 14:43 ` Nicolas Ferre
2015-01-14 14:43 ` Nicolas Ferre
2015-01-13 18:46 ` [PATCH v2 2/5] irqchip: Add DT binding doc for dumb demuxer chips Boris Brezillon
2015-01-13 18:46 ` Boris Brezillon
2015-01-13 18:46 ` Boris Brezillon
2015-01-13 19:00 ` Jason Cooper
2015-01-13 19:00 ` Jason Cooper
2015-01-13 19:00 ` Jason Cooper
2015-01-13 20:52 ` Boris Brezillon
2015-01-13 20:52 ` Boris Brezillon
2015-01-13 20:52 ` Boris Brezillon
2015-01-14 18:56 ` Jason Cooper
2015-01-14 18:56 ` Jason Cooper
2015-01-14 18:56 ` Jason Cooper
2015-01-14 19:08 ` Boris Brezillon
2015-01-14 19:08 ` Boris Brezillon
2015-01-14 19:08 ` Boris Brezillon
2015-01-14 19:33 ` Jason Cooper
2015-01-14 19:33 ` Jason Cooper
2015-01-14 19:33 ` Jason Cooper
2015-01-14 13:42 ` Nicolas Ferre
2015-01-14 13:42 ` Nicolas Ferre
2015-01-14 13:42 ` Nicolas Ferre
2015-01-13 18:46 ` [PATCH v2 3/5] ARM: at91/dt: select DUMB_IRQ_DEMUX for all at91 SoCs Boris Brezillon
2015-01-13 18:46 ` Boris Brezillon
2015-01-14 13:45 ` Nicolas Ferre
2015-01-14 13:45 ` Nicolas Ferre
2015-01-14 13:45 ` Nicolas Ferre
2015-01-13 18:46 ` [PATCH v2 4/5] ARM: at91/dt: add AIC irq1 muxed peripheral id definitions Boris Brezillon
2015-01-13 18:46 ` Boris Brezillon
2015-01-14 13:21 ` Nicolas Ferre
2015-01-14 13:21 ` Nicolas Ferre
2015-01-14 13:21 ` Nicolas Ferre
2015-01-14 13:34 ` Boris Brezillon
2015-01-14 13:34 ` Boris Brezillon
2015-01-14 13:34 ` Boris Brezillon
2015-01-14 13:40 ` Nicolas Ferre
2015-01-14 13:40 ` Nicolas Ferre
2015-01-14 13:40 ` Nicolas Ferre
2015-01-13 18:46 ` [PATCH v2 5/5] ARM: at91/dt: define a dumb irq demultiplexer chip connected on irq1 Boris Brezillon
2015-01-13 18:46 ` Boris Brezillon
2015-01-14 13:48 ` Nicolas Ferre
2015-01-14 13:48 ` Nicolas Ferre
2015-01-14 13:48 ` Nicolas Ferre
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=20150114092235.032dc986@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.