On Fri Jun 06, 2014 at 16:33:01 +1000, Peter Howard wrote:
On Fri, 2014-06-06 at 10:16 +1000, Peter Howard wrote:
Dear all,
I'm currently trying to add extra hardware access to L4Linux on the da850. I'm having reasonable success (thanks Taueng!), but have hit a problem with interrupts. I have enabled: * GPIO access (working, with problem described below), * DMA access (working, I think), * Clock access (working, insomuch as the GPIO and DMA stop giving clock errors), * MMC/SD access (not working - and until it does I'm not 100% sure about DMA).
(For anyone who knows the omapl138, the mux setup _is_ being handled; part of the bsp code in Fiasco).
I hit my current problem when I got the Clock access working, and the GPIO driver started registering interrupts. At that point the serial console stops responding. It prints, but any attempts to type anything fail. Simply commenting out the second half of davinci_gpio_irq_setup() removes the problem. Of course then gpio interrupts can't work (not that I know if they are working yet). So clearly registering those interrupts is affecting the serial console being notified of data pending.
I don't expect anyone here to have the answer. But to work out the problem I need to better understand how the virtual serial works in L4Linux. So can anyone give me/point me to a description of how it does work, along with the relevant driver code?
Well, I've got rid of the problem, though I wouldn't say I fully understand things. I worked out I had to up NR_IRQS_HW to cover both the real hardware irq numbers, _and_ the numbers used by the gpio driver (a further 144 on top of the hw nums). Doing that moved the irq number allocated (via cap) to the virtual serial console out of the way. And I get a working serial console back.
There are IRQ number spaces, the first come the "hardware" interrupt, i.e. all the interrupt numbers Linux uses. Followed by that are dynamically allocated interrupt numbers. The (virtual) console uses one of the dynamically allocated interrupt numbers. Now I guess what happened is that hardware numbers ran into the dynamically allocated space and overwrote the console interrupt. Increasing NR_IRQS_HW is the right thing to do here.
Adam