linuxsh-dev

Some questions about INTC

[EXTERNAL B. M. (P. ST-FIR/Eng) <ext...@de...>]

Hello Magnus,

I've migrated the SH7720 setup to the new intc code. I've some questions
about the new INTC code.

What are groups exactly for?
Group irqs which belong to one logical unit?
Group irqs which must share the ipr, or a similar register?
I assume both, but I'm not sure.

How to handle irqs which don't have a ipr register and don't have a mask
register?
H-UDI hasn't a mask/ipr register on SH7720, so it would trigger the
BUG_ON in intc_register_irq.
I won't use that irq, so I didnt include it.

And now the important question.
How to set the board specific irqs?
I don't need a special irq demux, or irq mask, like the existing boards.
(se7722)
I just have to set the priority and the level-sense.

I thought set_irq_type(...) is enough if the registers got correctly
associated with the irqs in the CPU setup.
The sens register gets correctly set, but I get the following error
message, when using the ethernet device (IRQ3).

Also I don't know how to set the board specific irq-prioritys in a clean
way.=20
At the moment I set it in the CPU setup.
Do I have to declare an intc description again, or is there a better
way?


udhcpc (v1.6.1) started
eth0: link down
eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
irq 35: nobody cared (try booting with the "irqpoll" option)
Stack: (0x8feb3cf8 to 0x8feb4000)
3ce0:                                                       8c006d8e
8feb3d08
3d00: 8c2966d4 8c29367c 8c03d3f4 8feb3d10 8c03d64a 8feb3d24 00000100
8c2966d4
3d20: 00000000 00000000 00000000 8c03dfaa 8feb3d4c 8c2e5710 0000000a
00000000
3d40: 8feb3e18 00000023 8c29367c 8c0037ec 8feb3d5c 8c2eabbc 00000033
8c0070dc
3d60: 8feb3dd0 00000000 8c0037b0 ffffffff 000000f0 00000000 40000000
00000100
3d80: 8c290334 0000000c a4140016 00000004 00000002 8c2eabbc 00000000
00000000
3da0: 0000000a 8c2e5710 8feb3dd0 8feb3dd0 8c019772 8c019886 40000000
00497300
3dc0: 00000340 00000038 ffffffff ffffffff 8c019886 8feb3df0 a8000068
008c42c8
3de0: 00000000 00000000 8c2eabbc 000000f0 8c0199f6 8feb3dfc 00000033
8c0037f2
3e00: 8feb3e04 8c0070dc 8feb3e78 a8000000 8c0037b0 ffffffff 00000000
00000000
3e20: 40000000 00000001 008c42c8 a800005c ffffffff 000000f0 a800005c
8c28e090
3e40: a8000000 00000000 008c42c8 a8000068 8feb3e78 8feb3e78 8c1652ba
8c16527c
3e60: 40000000 00497300 00000340 00000000 ffffffff ffffffff 8df57462
8c167554
3e80: 8feb3e9c 00000000 8c190e10 00001002 00000000 8df57400 8df57080
8c191004
3ea0: 8feb3eac 8df570fc 8df57080 8c191544 8feb3ec0 8df570fc 8df57080
00001043
3ec0: 8c1d0158 8feb3ee0 8dff9df8 00008914 00000000 ffffff9d 8df57080
7bbc1c8c
3ee0: 30687465 00000000 00000000 00000000 00001043 00000000 004bf53c
004819f2
3f00: 00001043 00000000 004bf53c 004819f2 00000000 00000000 8c1d2058
8feb3f38
3f20: 00494834 fffffff7 7bbc1c8c 7bbc1c8c 8c3b7238 00008914 8c18350a
8feb3f40
3f40: 8c070714 8feb3f58 7bbc1c8c 00000000 8c3b7238 7bbc1c8c 8c0707a2
8feb3f64
3f60: 7bbc1c8c 8fed2000 8fee16b8 8c070aa2 8feb3f80 00008914 00000004
8c3b7238
3f80: 00000000 8c0071fc 004948de 7bbc1cac ffffff0f 00000001 8feb3ff8
8c070a70
3fa0: 0044f280 00001002 7bbc1c9c 00000036 00000004 00008914 7bbc1c8c
00000000
3fc0: 7bbc1cac 00000120 7bbc1f1c 00000004 7bbc1cac 00494834 004948de
7bbc1c8c
3fe0: 0044f284 0040c9b8 00000000 00497300 00000022 00000000 0000004c
00000160

Call trace:
[<8c006d8e>] dump_stack+0xe/0x280
[<8c03d3f4>] __report_bad_irq+0x24/0x90
[<8c03d64a>] note_interrupt+0x1ea/0x220
[<8c03dfaa>] handle_level_irq+0xba/0x100
[<8c0037ec>] do_IRQ+0x3c/0x90
[<8c0070dc>] ret_from_exception+0x0/0x14
[<8c0037b0>] do_IRQ+0x0/0x90
[<8c019772>] __do_softirq+0x32/0xe0
[<8c019886>] do_softirq+0x66/0x80
[<8c019886>] do_softirq+0x66/0x80
[<8c0199f6>] irq_exit+0x36/0x50
[<8c0037f2>] do_IRQ+0x42/0x90
[<8c0070dc>] ret_from_exception+0x0/0x14
[<8c0037b0>] do_IRQ+0x0/0x90
[<8c1652ba>] smc911x_enable+0x3aa/0x430
[<8c16527c>] smc911x_enable+0x36c/0x430
[<8c167554>] smc911x_open+0x64/0xe0
[<8c190e10>] dev_set_rx_mode+0x0/0x50
[<8c191004>] dev_open+0xa4/0x100
[<8c191544>] dev_change_flags+0x74/0x1d0
[<8c1d0158>] devinet_ioctl+0x5f8/0x6e0
[<8c1d2058>] inet_ioctl+0x88/0xf0
[<8c18350a>] sock_ioctl+0xea/0x260
[<8c070714>] do_ioctl+0x54/0x70
[<8c0707a2>] vfs_ioctl+0x72/0x340
[<8c070aa2>] sys_ioctl+0x32/0x80
[<8c0071fc>] syscall_call+0xc/0x10
[<8c070a70>] sys_ioctl+0x0/0x80

handlers:
[<8c1667b0>] (smc911x_interrupt+0x0/0x930)
Disabling IRQ #35

Re: Some questions about INTC

[EXTERNAL B. M. (P. ST-FIR/Eng) <ext...@de...>]

Hi,

I have fixed the error now.=20
It was caused by the smc911x driver it requested the irq with=20
IRQF_TRIGGER_FALLING and overwrote my settings in the board setup.=20
After changing this to LOW it worked.

Regards

Markus

Re: Some questions about INTC

[Magnus D. <mag...@gm...>]

Hi Markus!

On 8/10/07, EXTERNAL Brunner Markus (Praktikant; ST-FIR/Eng)
<ext...@de...> wrote:
> Hi,
>
> I have fixed the error now.

Great! Sorry for not responding earlier.

> It was caused by the smc911x driver it requested the irq with
> IRQF_TRIGGER_FALLING and overwrote my settings in the board setup.
> After changing this to LOW it worked.

I wonder if it would make sense to extend the interrupt api to provide
a bitmap of all supported sense configurations supported by the
driver... That way the driver would tell the interrupt controller
which configurations it supports and it's up to the interrupt
controller pick one of them. Then the driver reads back which
configuration that was selected by the interrupt controller and sets
up the hardware it controls accordingly.

Or maybe that is too complicated, I'm not sure. But the current
framework seems a bit too limited IMO, especially if the interrupt
controller only supports a certain sense configuration.

The best solution may be the other way around though, where the
interrupt controller provides a bitmap of supported sense
configurations that the driver may choose from...

/ magnus

Re: Some questions about INTC

[Paul M. <le...@li...>]

On Mon, Aug 13, 2007 at 11:49:21AM +0900, Magnus Damm wrote:
> On 8/10/07, EXTERNAL Brunner Markus (Praktikant; ST-FIR/Eng)
> <ext...@de...> wrote:
> > It was caused by the smc911x driver it requested the irq with
> > IRQF_TRIGGER_FALLING and overwrote my settings in the board setup.
> > After changing this to LOW it worked.
> 
> I wonder if it would make sense to extend the interrupt api to provide
> a bitmap of all supported sense configurations supported by the
> driver... That way the driver would tell the interrupt controller
> which configurations it supports and it's up to the interrupt
> controller pick one of them. Then the driver reads back which
> configuration that was selected by the interrupt controller and sets
> up the hardware it controls accordingly.
> 
> Or maybe that is too complicated, I'm not sure. But the current
> framework seems a bit too limited IMO, especially if the interrupt
> controller only supports a certain sense configuration.
> 
> The best solution may be the other way around though, where the
> interrupt controller provides a bitmap of supported sense
> configurations that the driver may choose from...
> 
The current API works fine for this. the trigger flag is going to be
board-specific in the terms of most drivers, and conventional wisdom
dictates that the pin said peripheral's interrupt line is connected to is
able to do sense selection based on what the peripheral mandates.

There are of course cases where folks take edge-triggered devices and
plug them in to a level-only line or some combination thereof, but that's
not an API problem. The driver already has to know at request_irq() time
what trigger type it requires.

Re: Some questions about INTC

[Magnus D. <mag...@gm...>]

On 8/14/07, Paul Mundt <le...@li...> wrote:
> On Mon, Aug 13, 2007 at 11:49:21AM +0900, Magnus Damm wrote:
> > On 8/10/07, EXTERNAL Brunner Markus (Praktikant; ST-FIR/Eng)
> > <ext...@de...> wrote:
> > > It was caused by the smc911x driver it requested the irq with
> > > IRQF_TRIGGER_FALLING and overwrote my settings in the board setup.
> > > After changing this to LOW it worked.
> >
> > I wonder if it would make sense to extend the interrupt api to provide
> > a bitmap of all supported sense configurations supported by the
> > driver... That way the driver would tell the interrupt controller
> > which configurations it supports and it's up to the interrupt
> > controller pick one of them. Then the driver reads back which
> > configuration that was selected by the interrupt controller and sets
> > up the hardware it controls accordingly.
> >
> > Or maybe that is too complicated, I'm not sure. But the current
> > framework seems a bit too limited IMO, especially if the interrupt
> > controller only supports a certain sense configuration.
> >
> > The best solution may be the other way around though, where the
> > interrupt controller provides a bitmap of supported sense
> > configurations that the driver may choose from...
> >
> The current API works fine for this. the trigger flag is going to be
> board-specific in the terms of most drivers, and conventional wisdom
> dictates that the pin said peripheral's interrupt line is connected to is
> able to do sense selection based on what the peripheral mandates.
>
> There are of course cases where folks take edge-triggered devices and
> plug them in to a level-only line or some combination thereof, but that's
> not an API problem. The driver already has to know at request_irq() time
> what trigger type it requires.

How do we handle the case when say an ethernet controller can be
configured as either edge or level, but the stupid FPGA interrupt
controller only does only support one of them?

The driver for the ethernet controller is of course totally
disconnected from the interrupt controller code. But the ethernet
controller hardware does support both edge and level triggered
interrupts - just configure a certain register to switch mode. Can we
handle that today?

I don't have a use case for this atm, so it's purely academic...

/ magnus

Re: Some questions about INTC

[Paul M. <le...@li...>]

On Tue, Aug 14, 2007 at 07:45:34PM +0900, Magnus Damm wrote:
> On 8/14/07, Paul Mundt <le...@li...> wrote:
> > On Mon, Aug 13, 2007 at 11:49:21AM +0900, Magnus Damm wrote:
> > The current API works fine for this. the trigger flag is going to be
> > board-specific in the terms of most drivers, and conventional wisdom
> > dictates that the pin said peripheral's interrupt line is connected to is
> > able to do sense selection based on what the peripheral mandates.
> 
> How do we handle the case when say an ethernet controller can be
> configured as either edge or level, but the stupid FPGA interrupt
> controller only does only support one of them?
> 
> The driver for the ethernet controller is of course totally
> disconnected from the interrupt controller code. But the ethernet
> controller hardware does support both edge and level triggered
> interrupts - just configure a certain register to switch mode. Can we
> handle that today?
> 
We handle this today based on the board configuration. Regardless of what
the controller supports, there is always going to be board-specific glue
for this. This is true for things like buswidth, IRQ sense, and so on.
This is not something that can be implemented transparently, it's
ultimately up to the system integrator to know how this is wired up on
their particular platform and clue the driver in accordingly. The board
folks do have to know what they are doing at least some of the time.