Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1691634 > unrolled thread

Re: [PATCH 0/3] simulated interrupts

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/3] simulated interrupts Thomas Gleixner <tglx@linutronix.de> - 2017-07-19 14:30 +0200
    Re: [PATCH 0/3] simulated interrupts Bartosz Golaszewski <brgl@bgdev.pl> - 2017-07-19 14:50 +0200
      Re: [PATCH 0/3] simulated interrupts Thomas Gleixner <tglx@linutronix.de> - 2017-07-19 16:00 +0200
        Re: [PATCH 0/3] simulated interrupts Marc Zyngier <marc.zyngier@arm.com> - 2017-07-19 16:30 +0200
          Re: [PATCH 0/3] simulated interrupts Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-07-19 16:50 +0200
            Re: [PATCH 0/3] simulated interrupts Thomas Gleixner <tglx@linutronix.de> - 2017-07-19 17:00 +0200
              Re: [PATCH 0/3] simulated interrupts Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-07-19 18:00 +0200

#1691634 — Re: [PATCH 0/3] simulated interrupts

On Wed, 19 Jul 2017, Bartosz Golaszewski wrote:

> Some frameworks (e.g. iio, gpiolib) use irq_work to implement simulated
> interrupts that can be 'fired' from process context when needed and
> requested just like normal interrupts. This is useful for testing and
> development purposes.
> 
> Currently this code is reimplemented by every user. This series
> proposes to add a new set of functions that can be used by drivers
> that want to simulate interrupts without having to duplicate any
> boilerplate code.
> 
> The first patch adds a simple irq simulator framework. The second
> extends it with resource management. The third uses the new
> functionality in the gpio-mockup testing driver.
> 
> NOTE: The next candidate for using this API would be iio-dummy-evgen.

I like the general idea - have not looked at the code yet. Just a quick
question: How many copies/variants of this scheme do we have in tree?

Thanks,

	tglx

[toc] | [next] | [standalone]

#1691651

2017-07-19 14:25 GMT+02:00 Thomas Gleixner <tglx@linutronix.de>:
> On Wed, 19 Jul 2017, Bartosz Golaszewski wrote:
>
>> Some frameworks (e.g. iio, gpiolib) use irq_work to implement simulated
>> interrupts that can be 'fired' from process context when needed and
>> requested just like normal interrupts. This is useful for testing and
>> development purposes.
>>
>> Currently this code is reimplemented by every user. This series
>> proposes to add a new set of functions that can be used by drivers
>> that want to simulate interrupts without having to duplicate any
>> boilerplate code.
>>
>> The first patch adds a simple irq simulator framework. The second
>> extends it with resource management. The third uses the new
>> functionality in the gpio-mockup testing driver.
>>
>> NOTE: The next candidate for using this API would be iio-dummy-evgen.
>
> I like the general idea - have not looked at the code yet. Just a quick
> question: How many copies/variants of this scheme do we have in tree?
>
> Thanks,
>
>         tglx

Currently there are two: iio and gpiolib basically duplicate the same
code in their respective testing drivers. I only used irq_sim in
gpio-mockup in this series as an example and to see if there's any
interest in merging it before spending time on iio-dummy-evgen.

In the future this could be used in any framework that uses interrupts
and wants to test the irq code paths without touching any specific
hardware.

Thanks,
Bartosz

[toc] | [prev] | [next] | [standalone]

#1691695

On Wed, 19 Jul 2017, Bartosz Golaszewski wrote:

> 2017-07-19 14:25 GMT+02:00 Thomas Gleixner <tglx@linutronix.de>:
> > On Wed, 19 Jul 2017, Bartosz Golaszewski wrote:
> >
> >> Some frameworks (e.g. iio, gpiolib) use irq_work to implement simulated
> >> interrupts that can be 'fired' from process context when needed and
> >> requested just like normal interrupts. This is useful for testing and
> >> development purposes.
> >>
> >> Currently this code is reimplemented by every user. This series
> >> proposes to add a new set of functions that can be used by drivers
> >> that want to simulate interrupts without having to duplicate any
> >> boilerplate code.
> >>
> >> The first patch adds a simple irq simulator framework. The second
> >> extends it with resource management. The third uses the new
> >> functionality in the gpio-mockup testing driver.
> >>
> >> NOTE: The next candidate for using this API would be iio-dummy-evgen.
> >
> > I like the general idea - have not looked at the code yet. Just a quick
> > question: How many copies/variants of this scheme do we have in tree?
> >
> > Thanks,
> >
> >         tglx
> 
> Currently there are two: iio and gpiolib basically duplicate the same
> code in their respective testing drivers. I only used irq_sim in
> gpio-mockup in this series as an example and to see if there's any
> interest in merging it before spending time on iio-dummy-evgen.

Yes, I think so. Consolidation is always a good thing and simulation is
useful for developing or validating code.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1691718

On 19/07/17 14:58, Thomas Gleixner wrote:
> On Wed, 19 Jul 2017, Bartosz Golaszewski wrote:
> 
>> 2017-07-19 14:25 GMT+02:00 Thomas Gleixner <tglx@linutronix.de>:
>>> On Wed, 19 Jul 2017, Bartosz Golaszewski wrote:
>>>
>>>> Some frameworks (e.g. iio, gpiolib) use irq_work to implement simulated
>>>> interrupts that can be 'fired' from process context when needed and
>>>> requested just like normal interrupts. This is useful for testing and
>>>> development purposes.
>>>>
>>>> Currently this code is reimplemented by every user. This series
>>>> proposes to add a new set of functions that can be used by drivers
>>>> that want to simulate interrupts without having to duplicate any
>>>> boilerplate code.
>>>>
>>>> The first patch adds a simple irq simulator framework. The second
>>>> extends it with resource management. The third uses the new
>>>> functionality in the gpio-mockup testing driver.
>>>>
>>>> NOTE: The next candidate for using this API would be iio-dummy-evgen.
>>>
>>> I like the general idea - have not looked at the code yet. Just a quick
>>> question: How many copies/variants of this scheme do we have in tree?
>>>
>>> Thanks,
>>>
>>>         tglx
>>
>> Currently there are two: iio and gpiolib basically duplicate the same
>> code in their respective testing drivers. I only used irq_sim in
>> gpio-mockup in this series as an example and to see if there's any
>> interest in merging it before spending time on iio-dummy-evgen.
> 
> Yes, I think so. Consolidation is always a good thing and simulation is
> useful for developing or validating code.

Indeed, that's pretty interesting.

On a slightly tangential subject, there is another aspect that I thought
of implementing for a while, but always ended up just relying on a quick
hack: forcing the injection of an actual interrupt. A number of
interrupt controllers have the ability to make an interrupt pending, for
it to be handled as if a device had actually triggered it.

In my case, it has proved to be incredibly useful when debugging the
interrupt controller itself, and also things that mess with interrupts
in a creative way (like KVM) while relying on a particular interrupt
controller.

What I had in mind was something like:

echo 1 >/proc/irq/9/trigger (or the corresponding
/sys/kernel/debug/irq/irqs/ interface if we want to make sure that this
is really not for production use...).

If there is any interest, I'll try to whip something up.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[toc] | [prev] | [next] | [standalone]

#1691807

On Wed, Jul 19, 2017 at 5:19 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 19/07/17 14:58, Thomas Gleixner wrote:
>> On Wed, 19 Jul 2017, Bartosz Golaszewski wrote:

> echo 1 >/proc/irq/9/trigger
> (or the corresponding /sys/kernel/debug/irq/irqs/ interface if we want to make sure that this
> is really not for production use...).

or /sys/kernel/irq as a successor of /proc/irq


-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1691820

On Wed, 19 Jul 2017, Andy Shevchenko wrote:

> On Wed, Jul 19, 2017 at 5:19 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > On 19/07/17 14:58, Thomas Gleixner wrote:
> >> On Wed, 19 Jul 2017, Bartosz Golaszewski wrote:
> 
> > echo 1 >/proc/irq/9/trigger
> > (or the corresponding /sys/kernel/debug/irq/irqs/ interface if we want to make sure that this
> > is really not for production use...).
> 
> or /sys/kernel/irq as a successor of /proc/irq

/sys/kernel/debug/irq/irqs/ is already there and it's DEBUG and not
something which is in the regular sysfs maze.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1691963

On Wed, Jul 19, 2017 at 5:53 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 19 Jul 2017, Andy Shevchenko wrote:
>> On Wed, Jul 19, 2017 at 5:19 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:

>> > echo 1 >/proc/irq/9/trigger
>> > (or the corresponding /sys/kernel/debug/irq/irqs/ interface if we want to make sure that this
>> > is really not for production use...).
>>
>> or /sys/kernel/irq as a successor of /proc/irq
>
> /sys/kernel/debug/irq/irqs/ is already there and it's DEBUG and not
> something which is in the regular sysfs maze.

Yep. My point was "not to extend /proc/irq interface". From the
description of the series it indeed looks suitable rather for debug.

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web