linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: peterz@infradead.org, rafael@kernel.org,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	nicolas.pitre@linaro.org, vincent.guittot@linaro.org
Subject: Re: [RFC PATCH 1/2] irq: Add a framework to measure interrupt timings
Date: Tue, 12 Jan 2016 12:42:15 +0100	[thread overview]
Message-ID: <5694E697.6020306@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.11.1601081616530.3575@nanos>



Hi Thomas,

thanks for taking some time to review the patches.

On 01/08/2016 04:31 PM, Thomas Gleixner wrote:
> On Wed, 6 Jan 2016, Daniel Lezcano wrote:
>> +#ifdef CONFIG_IRQ_TIMINGS
>> +/**
>> + * timing handler to be called when an interrupt happens
>> + */
>> +typedef void (*irqt_handler_t)(unsigned int, ktime_t, void *, void *);
>> +
>> +/**
>> + * struct irqtimings - per interrupt irq timings descriptor
>> + * @handler:   interrupt handler timings function
>> + * @data:      pointer to the private data to be passed to the handler
>> + * @timestamp: latest interruption occurence
>
> There is no timestamp member.
>
>> + */
>> +struct irqtimings {
>> +	irqt_handler_t	  handler;
>> +	void              *data;
>
> What's that data thingy for. The proposed user does not use it at all and I
> have no idea why any user would want it. All it does is provide another level
> of indirection in the hotpath.

Yes, I agree. I added this private_data field for future use in case it 
would be needed but it does not make sense now.

>> +} ____cacheline_internodealigned_in_smp;
>
>> +/**
>> + * struct irqt_ops - structure to be used by the subsystem to call the
>> + * register and unregister ops when an irq is setup or freed.
>> + * @setup: registering callback
>> + * @free: unregistering callback
>> + *
>> + * The callbacks assumes the lock is held on the irq desc
>
> Crap. It's called outside of the locked region and the proposed user locks the
> descriptor itself, but that's a different story.
>
>> +static inline void free_irq_timings(unsigned int irq, void *dev_id)
>> +{
>> +	;
>
> What's the purpose of this semicolon?

Bah, old habit. I will remove it.

>> +#ifdef CONFIG_IRQ_TIMINGS
>> +void handle_irqt_event(struct irqtimings *irqt, struct irqaction *action)
>
> static ?
>
>> +{
>> +	if (irqt)
>
> This want's to use a static key.

Ok, I will look at that. I already used static keys to disable a portion 
of code from sysfs but never this way.

>> +		irqt->handler(action->irq, ktime_get(),
>> +			      action->dev_id, irqt->data);
>> +}
>> +#else
>> +#define handle_irqt_event(a, b)
>
> static inline stub if at all.

ok.

>> +#ifdef CONFIG_IRQ_TIMINGS
>> +/*
>> + * Global variable, only used by accessor functions, currently only
>> + * one user is allowed ...
>
> That variable is static not global. And what the heck means:
>
>>                          ... and it is up to the caller to make sure to
>> + * setup the irq timings which are already setup.
>
> -ENOPARSE.

hmm , yes ... it is not clear :)

I should have say:

"... and it is up to the caller to register the irq timing callback for 
the interrupts which are already setup."

>> + */
>> +static struct irqtimings_ops *irqtimings_ops;
>> +
>> +/**
>> + * register_irq_timings - register the ops when an irq is setup or freed
>> + *
>> + * @ops: the register/unregister ops to be called when at setup or
>> + * free time
>> + *
>> + * Returns -EBUSY if the slot is already in use, zero on success.
>> + */
>> +int register_irq_timings(struct irqtimings_ops *ops)
>> +{
>> +	if (irqtimings_ops)
>> +		return -EBUSY;
>> +
>> +	irqtimings_ops = ops;
>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * setup_irq_timings - call the timing register callback
>> + *
>> + * @desc: an irq desc structure
>
> The argument list tells a different story.
>
>> + *
>> + * Returns -EINVAL in case of error, zero on success.
>> + */
>> +int setup_irq_timings(unsigned int irq, struct irqaction *act)
>
> static is not in your book, right? These functions are only used in this file,
> so no point for having them global visible and the stubs should be local as
> well.

Ok.

>> +{
>> +	if (irqtimings_ops && irqtimings_ops->setup)
>> +		return irqtimings_ops->setup(irq, act);
>> +	return 0;
>> +}
>
> ...
>
>> @@ -1408,6 +1469,8 @@ static struct irqaction *__free_irq(unsigned int irq, void *dev_id)
>>
>>   	unregister_handler_proc(irq, action);
>>
>> +	free_irq_timings(irq, dev_id);
>
> This needs to go to the point where the interrupt is already synchronized and
> the action about to be destroyed.

Ok, noted.

Thanks !

   -- Daniel


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


  reply	other threads:[~2016-01-12 11:42 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-06 15:22 [RFC PATCH 0/2] IRQ based next prediction Daniel Lezcano
2016-01-06 15:22 ` [RFC PATCH 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-08 15:31   ` Thomas Gleixner
2016-01-12 11:42     ` Daniel Lezcano [this message]
2016-01-06 15:22 ` [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-06 17:40   ` Nicolas Pitre
2016-01-07 15:42     ` Daniel Lezcano
2016-01-12 19:27       ` Nicolas Pitre
2016-01-10 22:37     ` Daniel Lezcano
2016-01-10 22:46       ` Nicolas Pitre
2016-01-10 22:58         ` Daniel Lezcano
2016-01-10 23:13           ` Nicolas Pitre
2016-01-08 15:43   ` Thomas Gleixner
2016-01-12 12:41     ` Daniel Lezcano
2016-01-12 13:42       ` Thomas Gleixner
2016-01-12 14:16         ` Daniel Lezcano
2016-01-12 14:26           ` Thomas Gleixner
2016-01-12 14:52             ` Daniel Lezcano
2016-01-12 15:12               ` Thomas Gleixner
2016-01-12 16:04                 ` Daniel Lezcano
2016-01-13  9:17                   ` Thomas Gleixner
2016-01-18 13:21     ` Daniel Lezcano
2016-01-20 15:41       ` Thomas Gleixner
2016-01-20 16:00         ` [RFC V2 0/2] IRQ based next prediction Daniel Lezcano
2016-01-20 16:00           ` [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-20 17:55             ` Thomas Gleixner
2016-01-21  9:25               ` Daniel Lezcano
2016-01-21 10:27                 ` Thomas Gleixner
2016-01-20 19:07             ` Peter Zijlstra
2016-01-20 19:57               ` Thomas Gleixner
2016-01-20 20:04                 ` Nicolas Pitre
2016-01-20 20:20                 ` Peter Zijlstra
2016-01-20 20:22                   ` Thomas Gleixner
2016-01-21  9:50                 ` Daniel Lezcano
2016-01-21 10:08                   ` Peter Zijlstra
2016-01-21 12:38                     ` Daniel Lezcano
2016-01-21 20:27                     ` Thomas Gleixner
2016-01-21 13:52                   ` Thomas Gleixner
2016-01-21 14:19                     ` Daniel Lezcano
2016-01-21 18:56                       ` Thomas Gleixner
2016-01-22 10:15                         ` Peter Zijlstra
2016-01-21  9:26               ` Daniel Lezcano
2016-01-20 19:28             ` Peter Zijlstra
2016-01-21  9:53               ` Daniel Lezcano
2016-01-20 16:00           ` [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-20 17:46             ` Nicolas Pitre
2016-01-20 18:44               ` Peter Zijlstra
2016-01-21 10:03               ` Daniel Lezcano
2016-01-20 19:02             ` Peter Zijlstra
2016-01-20 19:17               ` Nicolas Pitre
2016-01-20 19:29                 ` Peter Zijlstra
2016-01-20 19:34             ` Peter Zijlstra
2016-01-20 19:40             ` Peter Zijlstra
2016-01-20 19:57               ` Nicolas Pitre
2016-01-20 20:22                 ` Peter Zijlstra
2016-01-20 19:49             ` Thomas Gleixner
2016-01-21 13:54               ` Daniel Lezcano
2016-01-21 14:12                 ` Thomas Gleixner
2016-01-20 16:00           ` [RFC V2 0/2] IRQ based next prediction Daniel Lezcano
2016-01-20 16:00           ` [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-20 16:00           ` [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-20 20:14             ` Nicolas Pitre
2016-01-21 13:04               ` Daniel Lezcano

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=5694E697.6020306@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nicolas.pitre@linaro.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vincent.guittot@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).