From: hdegoede@redhat.com (Hans de Goede)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/4] irqchip: sun4i: Use handle_fasteoi_late_irq for the ENMI (irq 0)
Date: Thu, 13 Mar 2014 16:13:22 +0100 [thread overview]
Message-ID: <5321CB12.3090704@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1403131542060.18573@ionos.tec.linutronix.de>
Hi,
On 03/13/2014 03:46 PM, Thomas Gleixner wrote:
> On Wed, 12 Mar 2014, Hans de Goede wrote:
>
>> The ENMI needs to have the ack done *after* clearing the interrupt source,
>> otherwise we will get a spurious interrupt for each real interrupt. Switch
>> to the new handle_fasteoi_late_irq handler which gives us the desired behavior.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/irqchip/irq-sun4i.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
>> index 8a2fbee..4b1c874 100644
>> --- a/drivers/irqchip/irq-sun4i.c
>> +++ b/drivers/irqchip/irq-sun4i.c
>> @@ -77,15 +77,22 @@ static void sun4i_irq_unmask(struct irq_data *irqd)
>> static struct irq_chip sun4i_irq_chip = {
>> .name = "sun4i_irq",
>> .irq_ack = sun4i_irq_ack,
>> + .irq_eoi = sun4i_irq_ack, /* For the ENMI */
>> .irq_mask = sun4i_irq_mask,
>> .irq_unmask = sun4i_irq_unmask,
>> + .flags = IRQCHIP_EOI_THREADED, /* Only affects the ENMI */
>
> That's not really true. The flags affect all interrupts which share
> that chip.
Yep, I figured out as much myself too while thinking a bit more about this
this morning.
So what I'm going to do in my next version of this patch is use 2
irqchip structures for the sun4i irqchip, one to describe the special
IRQ 0 and for all the others.
>
>> };
>>
>> static int sun4i_irq_map(struct irq_domain *d, unsigned int virq,
>> irq_hw_number_t hw)
>> {
>> - irq_set_chip_and_handler(virq, &sun4i_irq_chip,
>> - handle_level_irq);
>> + if (hw == 0) /* IRQ 0, the ENMI needs special handling */
>> + irq_set_chip_and_handler(virq, &sun4i_irq_chip,
>> + handle_fasteoi_late_irq);
>> + else
>> + irq_set_chip_and_handler(virq, &sun4i_irq_chip,
>> + handle_level_irq);
>
> I wonder what happens when you use the fasteoi handler for all of
> them.
As mentioned in my previous mail doing an ack (or an eio) seems to
be unnecessary for all but IRQ 0.
I do wonder if handle_level_irq is the right handle*irq function
to use in this case, since this is strictly used in the non smp
case I think that the mask / unmask done by handle_level_irq is
not necessary for non threaded handlers. So what would be the
correct handle*irq function to use in this case ?
Note the irqs are level irqs. IOW they may stay asserted while
the handler runs because of the handler and a new irq raising.
Regards,
Hans
WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Re: [PATCH v2 4/4] irqchip: sun4i: Use handle_fasteoi_late_irq for the ENMI (irq 0)
Date: Thu, 13 Mar 2014 16:13:22 +0100 [thread overview]
Message-ID: <5321CB12.3090704@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1403131542060.18573-3cz04HxQygjZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>
Hi,
On 03/13/2014 03:46 PM, Thomas Gleixner wrote:
> On Wed, 12 Mar 2014, Hans de Goede wrote:
>
>> The ENMI needs to have the ack done *after* clearing the interrupt source,
>> otherwise we will get a spurious interrupt for each real interrupt. Switch
>> to the new handle_fasteoi_late_irq handler which gives us the desired behavior.
>>
>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> drivers/irqchip/irq-sun4i.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
>> index 8a2fbee..4b1c874 100644
>> --- a/drivers/irqchip/irq-sun4i.c
>> +++ b/drivers/irqchip/irq-sun4i.c
>> @@ -77,15 +77,22 @@ static void sun4i_irq_unmask(struct irq_data *irqd)
>> static struct irq_chip sun4i_irq_chip = {
>> .name = "sun4i_irq",
>> .irq_ack = sun4i_irq_ack,
>> + .irq_eoi = sun4i_irq_ack, /* For the ENMI */
>> .irq_mask = sun4i_irq_mask,
>> .irq_unmask = sun4i_irq_unmask,
>> + .flags = IRQCHIP_EOI_THREADED, /* Only affects the ENMI */
>
> That's not really true. The flags affect all interrupts which share
> that chip.
Yep, I figured out as much myself too while thinking a bit more about this
this morning.
So what I'm going to do in my next version of this patch is use 2
irqchip structures for the sun4i irqchip, one to describe the special
IRQ 0 and for all the others.
>
>> };
>>
>> static int sun4i_irq_map(struct irq_domain *d, unsigned int virq,
>> irq_hw_number_t hw)
>> {
>> - irq_set_chip_and_handler(virq, &sun4i_irq_chip,
>> - handle_level_irq);
>> + if (hw == 0) /* IRQ 0, the ENMI needs special handling */
>> + irq_set_chip_and_handler(virq, &sun4i_irq_chip,
>> + handle_fasteoi_late_irq);
>> + else
>> + irq_set_chip_and_handler(virq, &sun4i_irq_chip,
>> + handle_level_irq);
>
> I wonder what happens when you use the fasteoi handler for all of
> them.
As mentioned in my previous mail doing an ack (or an eio) seems to
be unnecessary for all but IRQ 0.
I do wonder if handle_level_irq is the right handle*irq function
to use in this case, since this is strictly used in the non smp
case I think that the mask / unmask done by handle_level_irq is
not necessary for non threaded handlers. So what would be the
correct handle*irq function to use in this case ?
Note the irqs are level irqs. IOW they may stay asserted while
the handler runs because of the handler and a new irq raising.
Regards,
Hans
WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>,
linux-arm-kernel@lists.infradead.org,
devicetree <devicetree@vger.kernel.org>,
linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com
Subject: Re: [PATCH v2 4/4] irqchip: sun4i: Use handle_fasteoi_late_irq for the ENMI (irq 0)
Date: Thu, 13 Mar 2014 16:13:22 +0100 [thread overview]
Message-ID: <5321CB12.3090704@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1403131542060.18573@ionos.tec.linutronix.de>
Hi,
On 03/13/2014 03:46 PM, Thomas Gleixner wrote:
> On Wed, 12 Mar 2014, Hans de Goede wrote:
>
>> The ENMI needs to have the ack done *after* clearing the interrupt source,
>> otherwise we will get a spurious interrupt for each real interrupt. Switch
>> to the new handle_fasteoi_late_irq handler which gives us the desired behavior.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/irqchip/irq-sun4i.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
>> index 8a2fbee..4b1c874 100644
>> --- a/drivers/irqchip/irq-sun4i.c
>> +++ b/drivers/irqchip/irq-sun4i.c
>> @@ -77,15 +77,22 @@ static void sun4i_irq_unmask(struct irq_data *irqd)
>> static struct irq_chip sun4i_irq_chip = {
>> .name = "sun4i_irq",
>> .irq_ack = sun4i_irq_ack,
>> + .irq_eoi = sun4i_irq_ack, /* For the ENMI */
>> .irq_mask = sun4i_irq_mask,
>> .irq_unmask = sun4i_irq_unmask,
>> + .flags = IRQCHIP_EOI_THREADED, /* Only affects the ENMI */
>
> That's not really true. The flags affect all interrupts which share
> that chip.
Yep, I figured out as much myself too while thinking a bit more about this
this morning.
So what I'm going to do in my next version of this patch is use 2
irqchip structures for the sun4i irqchip, one to describe the special
IRQ 0 and for all the others.
>
>> };
>>
>> static int sun4i_irq_map(struct irq_domain *d, unsigned int virq,
>> irq_hw_number_t hw)
>> {
>> - irq_set_chip_and_handler(virq, &sun4i_irq_chip,
>> - handle_level_irq);
>> + if (hw == 0) /* IRQ 0, the ENMI needs special handling */
>> + irq_set_chip_and_handler(virq, &sun4i_irq_chip,
>> + handle_fasteoi_late_irq);
>> + else
>> + irq_set_chip_and_handler(virq, &sun4i_irq_chip,
>> + handle_level_irq);
>
> I wonder what happens when you use the fasteoi handler for all of
> them.
As mentioned in my previous mail doing an ack (or an eio) seems to
be unnecessary for all but IRQ 0.
I do wonder if handle_level_irq is the right handle*irq function
to use in this case, since this is strictly used in the non smp
case I think that the mask / unmask done by handle_level_irq is
not necessary for non threaded handlers. So what would be the
correct handle*irq function to use in this case ?
Note the irqs are level irqs. IOW they may stay asserted while
the handler runs because of the handler and a new irq raising.
Regards,
Hans
next prev parent reply other threads:[~2014-03-13 15:13 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-12 17:17 [PATCH v2 0/4] irq: sun4i IRQ 0 / ENMI fixes Hans de Goede
2014-03-12 17:17 ` Hans de Goede
2014-03-12 17:17 ` Hans de Goede
2014-03-12 17:17 ` [PATCH v2 1/4] irq: Add handle_fasteoi_late_irq irq handler Hans de Goede
2014-03-12 17:17 ` Hans de Goede
2014-03-12 17:17 ` Hans de Goede
2014-03-12 17:21 ` Hans de Goede
2014-03-12 17:21 ` Hans de Goede
2014-03-12 17:21 ` Hans de Goede
2014-03-12 17:17 ` [PATCH v2 2/4] irqchip: sun4i: Fix irq 0 not working Hans de Goede
2014-03-12 17:17 ` Hans de Goede
2014-03-12 17:17 ` Hans de Goede
2014-03-13 9:29 ` Maxime Ripard
2014-03-13 9:29 ` Maxime Ripard
2014-03-13 9:29 ` Maxime Ripard
2014-03-12 17:17 ` [PATCH v2 3/4] irqchip: sun4i: Fix a comment about mask register initialization Hans de Goede
2014-03-12 17:17 ` Hans de Goede
2014-03-12 17:17 ` Hans de Goede
2014-03-12 17:17 ` [PATCH v2 4/4] irqchip: sun4i: Use handle_fasteoi_late_irq for the ENMI (irq 0) Hans de Goede
2014-03-12 17:17 ` Hans de Goede
2014-03-12 17:17 ` Hans de Goede
2014-03-13 9:34 ` Maxime Ripard
2014-03-13 9:34 ` Maxime Ripard
2014-03-13 9:34 ` Maxime Ripard
2014-03-13 9:56 ` [linux-sunxi] " Carlo Caione
2014-03-13 9:56 ` Carlo Caione
2014-03-13 9:56 ` Carlo Caione
2014-03-13 11:12 ` Thomas Gleixner
2014-03-13 11:12 ` Thomas Gleixner
2014-03-13 11:12 ` Thomas Gleixner
2014-03-13 15:09 ` Hans de Goede
2014-03-13 15:09 ` Hans de Goede
2014-03-13 15:09 ` Hans de Goede
2014-03-13 14:46 ` Thomas Gleixner
2014-03-13 14:46 ` Thomas Gleixner
2014-03-13 14:46 ` Thomas Gleixner
2014-03-13 15:13 ` Hans de Goede [this message]
2014-03-13 15:13 ` Hans de Goede
2014-03-13 15:13 ` Hans de Goede
2014-03-13 16:27 ` Thomas Gleixner
2014-03-13 16:27 ` Thomas Gleixner
2014-03-13 16:27 ` Thomas Gleixner
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=5321CB12.3090704@redhat.com \
--to=hdegoede@redhat.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.