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


Groups > linux.kernel > #1299121

Routable IRQs

From Felipe Balbi <balbi@ti.com>
Newsgroups linux.kernel
Subject Routable IRQs
Date 2015-12-29 21:20 +0100
Message-ID <qL8Uq-5fn-17@gated-at.bofh.it> (permalink)
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

Hi Thomas & Jason,

I'm dealing with an interesting situation which I'm wondering if Linux
already support for.

Basically, in some TI SoCs we have what's referred to as Programmable
Real-Time Unit SubSystem (PRUSS). That's essentially a really simple,
low latency, single cycle architecture which is pretty darn good for bit
banging peripherals (ETH, SPI, I2C, UART, etc). It's very predicatable
because every instruction takes 5ns and interrupts don't cause
exceptions, they just get registered.

Anyway, the interesting part is that PRUSS has 64 events (on current
incarnations at least) and PRUSS has 10 physical IRQ lines to the ARM
land. Each of these 64 events can be routed to any of these 10 IRQ
lines. This might not be very useful on UP (AM335x & AM437x) other than
the fact that soft-IP drivers running on Linux would need to guarantee
they are the ones who should handle the IRQ. However, on SMP (AM57xx) we
could have real tangible benefits by means of IRQ affinity, etc.

So, the question is, what is there in IRQ subsystem today for routable
IRQ support ?

If a Diagram helps here's a simple one. Note that I'm not showing
details on the PRUSS side, but that side can also map events pretty much
any way it wants.

 .--------------------.             .--------------------.
 |      HOST CPU      |             |       PRUSS        |
 |--------------------|             |--------------------|
 |                    |             |                    |
 |               irq0 |<-.----------|evt0                |
 |                    |  |          |                    |
 |               irq1 |  |  .-------|evt1                |
 |                    |  |  |       |                    |
 |               irq2 |  '----------|evt2                |
 |                    |     |       |                    |
 |               irq3 |     |       |                    |
 |                    |     |       |                    |
 |               irq4 |     |       | .                  |
 |                    |     |       |                    |
 |               irq5 |     |       | .                  |
 |                    |     |       |                    |
 |               irq6 |     |       | .                  |
 |                    |     |       |                    |
 |               irq7 |<----'       |                    |
 |                    |             |                    |
 |               irq8 |             |                    |
 |                    |             |                    |
 |               irq9 |<------------|evtN                |
 '--------------------'             '--------------------'

Given this setup, what I want to do, is let soft-IP drivers running on
linux rely on standard *request_*irq() calls and DTS descrition. But I'm
still considering how/if we should describe the routing itself or just
go round-robin (i.o.w. irq0 -> evt0, irq1 -> evt1, ..., irq9 -> evt9,
irq0 -> evt10, ...).

Thoughts ?

-- 
balbi

Back to linux.kernel | Previous | NextNext in thread | Find similar | Unroll thread


Thread

Routable IRQs Felipe Balbi <balbi@ti.com> - 2015-12-29 21:20 +0100
  Re: Routable IRQs Thomas Gleixner <tglx@linutronix.de> - 2015-12-30 19:20 +0100
    Re: Routable IRQs Felipe Balbi <balbi@ti.com> - 2015-12-30 19:50 +0100
      Re: Routable IRQs Thomas Gleixner <tglx@linutronix.de> - 2015-12-30 21:00 +0100
        Re: Routable IRQs Felipe Balbi <balbi@ti.com> - 2015-12-30 21:20 +0100

csiph-web