I2S interrupts not triggered

[mhelin]

When I2S/PCM block is programmed to trigger an interrupt #55 when for an example transmit FIFO is below it's threshold level no IRQ 55 is triggered and interrupt handler is not called. However, armctrl supposedly implements handler for IRQ 81 which shows some activity in /proc/interrupts. It's not possible (Raspberry hangs) to register an interrupt handler for this (high) IRQ number. This might also be a firmware issue.

[philpoole]

Hi,
This issue has been documented in this forum thread http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=8496&start=125 .
It can be reproduced very easily with the gist below.
(If that fails, it should be viewable in https://gist.github.com/4357922, or the original thread - sorry, I'm new to github).
Basically, it's a very simple module that sets up the I2S PCM device with a few register pokes, and then starts filling the FIFO in order to trigger an interrupt. I'm happy the setup is reasonable, as I've had it working with my I2S DAC without using interrupts (with an immense CPU load, but it works).
Initially, it looks like nothing is happening, but /proc/interrupts suggests that interrupts are firing on IRQ 81, and PCM_INTSTC_A suggests that the interrupt line is high from the PCM block.

By placing debug in the kernel. I can see that IRQ 81 is being triggered in handle_level_irq() in the kernel, but isn't getting any further (not calling our ISR) because the IRQ is disabled, and has no action defined. This is with my test driver only setting up IRQ 55, so obviously some setup for 81 is required. However, doing that seems to make the pi crash (I assume) when the IRQ is triggered.
I tried hacking the kernel to also trigger the registered IRQ function for 55 (a very simple stub function - just a printk) as well as for 81 when 81 was fired, but again that just crashed. So something seems incorrect.
It's very possible we're setting interrupts up incorrectly. I took initial inspiration from my Linux Device Drivers book (3rd edition - which is rapidly becoming out of date now), and then from bcm2708_gpio.c, but I'm not 100% certain it's setup correctly.
I can see that there is some IRQ remapping in armctrl.c that is linking 55 to 81 (and, undoing that remapping crashes the box too {I've tried alsorts}).

Is there anything I can do to progress this further? Perhaps some debug I can perform? Is there a kernel configuration I need to set?

Where do you think this could be going wrong?

<script src="https://gist.github.com/4357922.js"></script>

[ghollingworth]

Are you sure you are handling the interrupt correctly? If you've enabled
it but are not handling the interrupt properly it could be locking up...

Check the dwc_otg code for an example of how to use an interrupt properly
(search the code for MPHI and you should find the relevant bits...

drivers/usb/host/dwc_otg/*

Gordon

On 22 December 2012 07:52, philpoole notifications@github.com wrote:

Hi,
This issue has been documented in this forum thread
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=8496&start=125 .
It can be reproduced very easily with the gist below.
(If that fails, it should be viewable in https://gist.github.com/4357922,
or the original thread - sorry, I'm new to github).
Basically, it's a very simple module that sets up the I2S PCM device with
a few register pokes, and then starts filling the FIFO in order to trigger
an interrupt. I'm happy the setup is reasonable, as I've had it working
with my I2S DAC without using interrupts (with an immense CPU load, but it
works).
Initially, it looks like nothing is happening, but /proc/interrupts
suggests that interrupts are firing on IRQ 81, and PCM_INTSTC_A suggests
that the interrupt line is high from the PCM block.

By placing debug in the kernel. I can see that IRQ 81 is being triggered
in handle_level_irq() in the kernel, but isn't getting any further (not
calling our ISR) because the IRQ is disabled, and has no action defined.
This is with my test driver only setting up IRQ 55, so obviously some setup
for 81 is required. However, doing that seems to make the pi crash (I
assume) when the IRQ is triggered.
I tried hacking the kernel to also trigger the registered IRQ function for
55 (a very simple stub function - just a printk) as well as for 81 when 81
was fired, but again that just crashed. So something seems incorrect.
It's very possible we're setting interrupts up incorrectly. I took initial
inspiration from my Linux Device Drivers book (3rd edition - which is
rapidly becoming out of date now), and then from bcm2708_gpio.c, but I'm
not 100% certain it's setup correctly.
I can see that there is some IRQ remapping in armctrl.c that is linking 55
to 81 (and, undoing that remapping crashes the box too {I've tried
alsorts}).

Is there anything I can do to progress this further? Perhaps some debug I
can perform? Is there a kernel configuration I need to set?

Where do you think this could be going wrong?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/161#issuecomment-11634895.

[philpoole]

Hi Gordon,
It's entirely possible that I'm doing things wrong. Knowing what works and what doesn't is a good start, so thanks for that. I shall have a look...
Regards,
Phil

[ghollingworth]

Phil,

Yes even I had quite a bit of trouble getting the FIQ working and I had
access to the verilog to check the wiring of the interrupts!!

Gordon

On 22 December 2012 18:40, philpoole notifications@github.com wrote:

Hi Gordon,
It's entirely possible that I'm doing things wrong. Knowing what works and
what doesn't is a good start, so thanks for that. I shall have a look...
Regards,
Phil

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/161#issuecomment-11639954.

[philpoole]

Hi Gordon,
Glad I'm not the only one!
Looking at dwc_otg_pcd_linux.c for instance, I notice that it uses request_irq() and free_irq() (as opposed to setup_irq() and remove_irq() that I used). I had originally tried that, but to no avail, and attempted the latter method from assessing bcm2708_gpi.c.
I'll have another look, but I'm afraid I'm sceptical at the moment (although perhaps I can debug the kernel to discover different behaviour - which might help).
Thanks for the help!
Phil

[mhelin]

Hi,

I've also played with both IRQ setup ways (request_irq and setupt_irq) but with no results, the IRQ #55 was never called.

In dwc_otg_driver.c request_irq is used as well:

retval = request_irq(devirq, dwc_otg_common_irq,
IRQF_SHARED,
"dwc_otg", dwc_otg_device);

"dwc_otg_common_irq" is the interrupt handler, struct dwc_otg_device contains some data.

[ghollingworth]

So I assume you are also using the same platform initialisation to allocate
the IRQ? i.e. you need to make sure your driver is correctly given the IRQ
resource in bcm2708.c

Have you tried allocating an IRQ that you know definitely works (such as
the MPHI or USB interrupt?) That way you know that you are correctly
allocating the resources etc.

Gordon

On 22 December 2012 22:13, mhelin notifications@github.com wrote:

Hi,

I've also played with both IRQ setup ways (request_irq and setupt_irq) but
with no results, the IRQ #55https://github.com/raspberrypi/linux/issues/55was never called.

In dwc_otg_driver.c request_irq is used as well:

retval = request_irq(devirq, dwc_otg_common_irq,
IRQF_SHARED,
"dwc_otg", dwc_otg_device);

"dwc_otg_common_irq" is the interrupt handler, struct dwc_otg_device
contains some data.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/161#issuecomment-11641851.

[philpoole]

Ok, I shall have a look (although christmas is looming, so it might take a while). I didn't make any changes to the kernel in order to implement this (just to debug). I was hoping that was unnecessary.
Trying a working, shared interrupt with a benign handler seems a sensible idea...

Regards,
Phil

[philpoole]

Been debugging further, and can actually see interrupts!
Basically, if I setup IRQ 81, as soon as INTEN_A is set (interrupts enabled on the PCM block), then infinite interrupts are fired. I wasn't seeing this initially, just a locked up pi.
It's strange, because nothing seems to stall these interrupt, except disabling them (clearing the status bit in INTSTC by writing 0xf does nothing, ensuring the interrupts should occur when full (00 to bits 6 and 5 of CS_A), and then maintaining an empty buffer doesn't help either).

[ghollingworth]

Likely to be the tx fifo empty interrupt being triggered have you tried
masking those interrupts?

Do you know which interrupts are actually being triggered

Gordon
On 28 Dec 2012 08:43, "philpoole" notifications@github.com wrote:

Been debugging further, and can actually see interrupts!
Basically, if I setup IRQ 81, as soon as INTEN_A is set (interrupts
enabled on the PCM block), then infinite interrupts are fired. I wasn't
seeing this initially, just a locked up pi.
It's strange, because nothing seems to stall these interrupt, except
disabling them (clearing the status bit in INTSTC by writing 0xf does
nothing, ensuring the interrupts should occur when full (00 to bits 6 and 5
of CS_A), and then maintaining an empty buffer doesn't help either).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/161#issuecomment-11727766.

[philpoole]

Hi Gordon,
Yes, well, it's definitely to do with the registers not behaving as I'd expect. Need to have a play...

Phil

[philpoole]

I appear to be getting regular interrupts now. I didn't realise, if you don't clear the TXERR flag when it occurs, it seems to just interrupt like crazy (even if you deal with the underflow, as I was).
So I think this issue isn't a problem now. The other issues are related to misuse of registers :)
Thanks for the help.

[mhelin]

So the problem when using IRQ #81 was the interrupt storm actually? What are the other register issues, please post your code to the I2S thread on forums when you get it working better. Can we now close this issue? I'm still wondering the IRQ number issue because the documentation specifies only the IRQ #55.

[mhelin]

After implementing the changes described I also got the I2S FIFO interrupt (undocumented IRQ 81) working so I'm closing this issue now. Thanks for everyone helping.