Linus,
amba/pl022 and my dma driver dw_dmac.c, both have registered init() routines
with subsys_initcall(). Now at bootup, spi boots up before DMA and so DMA
channels are never available at spi probe.
What should be done to solve this issue?
One idea is allocate DMA channel as and when required, instead of allocating them
at probe. But in that case too i am not sure, that this issue will be solved.
As, if spi slave device is added from board file, then it will also try to transfer
data as soon as spi driver is up. So that too may be called before dma_probe().
--
viresh
2011/5/13 viresh kumar [off-list ref]:
amba/pl022 and my dma driver dw_dmac.c, both have registered init() routines
with subsys_initcall(). Now at bootup, spi boots up before DMA and so DMA
channels are never available at spi probe.
What should be done to solve this issue?
If you check drivers/dma/ste_dma40.c you can see that our solution was to
simply move the DMA engine to arch_initcall().
Which sort of makes sense for a DMA engine.
Does this work for dw_dmac.c?
One idea is allocate DMA channel as and when required, instead of allocating them
at probe. But in that case too i am not sure, that this issue will be solved.
For the serial port I've added a real funny tweak to queue the ports
and add DMA later since these are initialized very early.
Check in drivers/tty/serial/amba-pl011.c
Hope this helps,
Linus Walleij
On 05/13/2011 08:01 PM, Linus Walleij wrote:
2011/5/13 viresh kumar [off-list ref]:
quoted
amba/pl022 and my dma driver dw_dmac.c, both have registered init() routines
with subsys_initcall(). Now at bootup, spi boots up before DMA and so DMA
channels are never available at spi probe.
What should be done to solve this issue?
If you check drivers/dma/ste_dma40.c you can see that our solution was to
simply move the DMA engine to arch_initcall().
Which sort of makes sense for a DMA engine.
Does this work for dw_dmac.c?
Yes, it worked here too..
--
viresh