All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andres Salomon <dilinger@queued.net>
To: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, linux-geode@lists.infradead.org
Subject: Re: IRQF_TIMER | IRQF_SHARED ?
Date: Mon, 12 Dec 2011 12:31:31 -0800	[thread overview]
Message-ID: <20111212123131.502be350@queued.net> (raw)
In-Reply-To: <4EE620A5.7080402@LiPPERTEmbedded.de>

On Mon, 12 Dec 2011 16:41:25 +0100
Jens Rottmann <JRottmann@LiPPERTEmbedded.de> wrote:

> Hi Andres,
> 
> one of our customers tripped over the fact that the MFGPT driver
> won't share its IRQ with anyone else. (MFGPT defaulted to same IRQ as
> audio, MFGPT driver loaded first, audio fails.) *No big deal!* They
> don't actually need MFGPT and will simply disable it. It just made me
> wonder ...
> 
> Why would it be such a bad idea to use IRQF_TIMER | IRQF_SHARED (see
> patch below)? mfgpt_tick() already does properly return IRQ_NONE when
> it feels unresponsible. I tested it with either driver loaded first
> and it seemed to work (well, at least audio worked, don't know how to
> explicitly test cs5535-clockevt).

Just loading cs5535-clockevt should start the periodic timer.  On my
XO-1, IRQ 7 starts firing immediately.


> 
> I thought about latencies of IRQ sharing being unacceptable for a
> timer, but ...
> - If MFGPT is loaded first there is no additional latency, is there?
> Audio recieves its IRQs only as 2nd in list but that's not a problem.
> - If MFGPT is loaded second - well, there is a latency, but without
> sharing the IRQ the driver failed to load at all, so that's still an
> improvement.
> 
> But I did not fail to notice that _none_ of the code in
> drivers/clocksource/ uses IRQF_SHARED, obviously this must be
> deliberate.

Hm, maybe tglx knows?  For my part, I don't think it would be a
problem, but I can imagine the reason for not sharing being clock drift
or something to that effect.


> 
> So, what's so bad about IRQF_TIMER | IRQF_SHARED?
> 
> Any education would be welcome, even if combined with flame. :-)
> 
> Thanks and best regards,
> Jens
> 
> --- linux-3.2-rc4/drivers/clocksource/cs5535-clockevt.c
> +++ shared_mfgpt_irq/drivers/clocksource/cs5535-clockevt.c
> @@ -133,7 +133,7 @@ static irqreturn_t mfgpt_tick(int irq, v
> 
>  static struct irqaction mfgptirq  = {
>  	.handler = mfgpt_tick,
> -	.flags = IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TIMER,
> +	.flags = IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TIMER |
> IRQF_SHARED, .name = DRV_NAME,
>  };
> 
> _
> 

  reply	other threads:[~2011-12-12 20:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-12 15:41 IRQF_TIMER | IRQF_SHARED ? Jens Rottmann
2011-12-12 20:31 ` Andres Salomon [this message]
2011-12-12 21:00   ` Martin-Éric Racine
2011-12-12 22:06     ` Andres Salomon
2011-12-12 23:38   ` Thomas Gleixner
2011-12-13 15:49   ` Jens Rottmann
2011-12-14 18:37     ` Jens Rottmann
2011-12-14 18:47       ` Andres Salomon
2011-12-21 15:42         ` [PATCH] cs5535-clockevt: don't ignore MFGPT on SMP-capable kernels Jens Rottmann
2012-01-11 10:10           ` Andres Salomon
2012-01-19 12:57             ` Jens Rottmann
2012-01-23 10:44               ` Andres Salomon
2011-12-21 16:37         ` IRQF_TIMER | IRQF_SHARED ? Jens Rottmann
2011-12-22 16:35         ` [PATCH] cs5535-clockevt: allow the MFGPT IRQ to be shared Jens Rottmann
2012-01-11 10:15           ` Andres Salomon
2012-01-30 13:51         ` [PATCH] cs5535-clockevt: don't ignore MFGPT on SMP-capable kernels Jens Rottmann
2012-01-30 13:59         ` [PATCH] cs5535-clockevt: allow the MFGPT IRQ to be shared Jens Rottmann
2012-02-06  8:20         ` [PATCH resend] cs5535-clockevt: don't ignore MFGPT on SMP-capable kernels Jens Rottmann
2012-02-06  8:23         ` [PATCH resend] cs5535-clockevt: allow the MFGPT IRQ to be shared Jens Rottmann
2011-12-19 14:32       ` "clockevents: Set noop handler in clockevents_exchange_device()" causes hang with cs5535-clockevt Jens Rottmann

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=20111212123131.502be350@queued.net \
    --to=dilinger@queued.net \
    --cc=JRottmann@LiPPERTEmbedded.de \
    --cc=linux-geode@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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.