linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Frias <sf84@laposte.net>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	"Grygorii Strashko" <grygorii.strashko@ti.com>,
	Mason <slash.tmp@free.fr>, "Måns Rullgård" <mans@mansr.com>
Subject: Re: Using irq-crossbar.c
Date: Tue, 21 Jun 2016 13:03:40 +0200	[thread overview]
Message-ID: <57691F0C.5030600@laposte.net> (raw)
In-Reply-To: <57691491.20108@arm.com>

Hi Marc,

On 06/21/2016 12:18 PM, Marc Zyngier wrote:
>> Since irq-tango_v2.c is similar to irq-crossbar.c from TI (since it
>> is based on it), I was wondering what is the policy or recommendation
>> in such cases?
>> Should I attempt to merge the code (mainly the way to set up the
>> registers) on irq-crossbar.c or should we consider irq-tango_v2.c to
>> live its own life?
> 
> If the HW is significantly different, I'd rather have a separate driver.
> We can always share some things later on by having a small library of
> "stuff".

I'd say it is very similar. Most of the changes I did were done to understand how it worked.
However, it may end up being different if we use cascaded interrupts.

> 
>> NOTE: IMHO, irq-crossbar.c could benefit from clearer names for some
>> DT properties, because "max_irqs" and "max-crossbar-sources" are not
>> straight forward names for "mux_outputs" and "mux_inputs"
>> (respectively)
> 
> Maybe, but this ship has sailed a long time ago. This is an ABI now, and
> it is not going to change unless proven to be broken. On the other hand,
> you can name your own properties as you see fit.

Ok.

> 
>> NOTE2: current irq-tango_v2.c code still has a 24 IRQ limitation
>> since it is not using any API that would allow it to setup IRQ
>> sharing.
> 
> Unless you limit your mux level interrupts only, I cannot see how you
> could deal with cascaded interrupts. By the time you receive an edge,
> the line will have dropped, and you won't be able to identify the source
> interrupt.

Yes, cascaded interrupts would be limited to level only.

By the way, did you see my other questions? (copy/pasted here for convenience):

----
Ok, so after discussing with some HW engineers, they said that even if this is a pure router and cannot latch by itself, since the devices themselves latch their IRQ output, reading the 4x32bit RAW status registers could work as well, that means that if there are more than 24 devices, some could share IRQs, right?

Two questions then:
a) let's say we need to share some of the IRQs, which APIs should be used?

b) some people have been asking about IRQ affinity, they have not been clear about it, but I suppose maybe they want to redistribute the IRQs.
In this case, when using IRQ sharing a device may go from sharing an IRQ line to an exclusive line or viceversa, right?
Does Linux handles that on its own or there's some API to call as well?
----

About a) I did not find any driver that uses irq_domain_add_linear() and irq_domain_add_hierarchy() but maybe I'm not approaching the problem from the right angle.

Best regards,

Sebastian

  reply	other threads:[~2016-06-21 11:30 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-10 15:37 Using irq-crossbar.c Sebastian Frias
2016-06-10 16:05 ` Marc Zyngier
2016-06-10 19:36   ` Mason
2016-06-11  9:58     ` Marc Zyngier
2016-06-11 15:37       ` Mason
2016-06-12 10:00         ` Marc Zyngier
2016-06-12 13:50           ` Mason
2016-06-13  7:58             ` Marc Zyngier
2016-06-13 14:04         ` Lennart Sorensen
2016-06-13 14:57           ` Sebastian Frias
2016-06-13 15:42             ` Lennart Sorensen
2016-06-13 15:49               ` Mason
2016-06-13 15:57                 ` Marc Zyngier
2016-06-13 17:55                 ` Lennart Sorensen
2016-06-13 15:15       ` Sebastian Frias
2016-06-13 16:26         ` Marc Zyngier
2016-06-13 15:46   ` Sebastian Frias
2016-06-13 16:24     ` Marc Zyngier
2016-06-14 16:37       ` Sebastian Frias
2016-06-14 16:39         ` Sebastian Frias
2016-06-16 12:39           ` Sebastian Frias
2016-06-21 10:18             ` Marc Zyngier
2016-06-21 11:03               ` Sebastian Frias [this message]
2016-06-21 12:41                 ` Marc Zyngier
2016-06-21 15:29                   ` Sebastian Frias
2016-06-13 17:59     ` Lennart Sorensen
2016-06-10 16:06 ` Lennart Sorensen

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=57691F0C.5030600@laposte.net \
    --to=sf84@laposte.net \
    --cc=grygorii.strashko@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mans@mansr.com \
    --cc=marc.zyngier@arm.com \
    --cc=slash.tmp@free.fr \
    --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 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).