Messages in this thread | | | Date | Fri, 17 Oct 2014 13:15:55 +0200 | From | Lars-Peter Clausen <> | Subject | Re: [PATCH] dmaengine: pl330: use subsys_initcall |
| |
On 10/17/2014 09:35 AM, Vinod Koul wrote: > On Fri, Oct 17, 2014 at 09:45:45AM +0200, Lars-Peter Clausen wrote: >> On 10/17/2014 02:48 AM, Ray Jui wrote: >>> As part of subsystem that many slave drivers depend on, it's more >>> appropriate for the pl330 DMA driver to be initialized at >>> subsys_initcall than device_initcall >> >> Well, we do have -EPROBE_DEFER these days to handle these kinds of >> dependencies so we no longer have to these kinds of manual init >> reordering tricks. > How ould that work? > > Consider for example SPI and dmanegine. SPI driver got probed, then to start > a transaction requested a channel... while dmaengine driver is still getting > probed/not probed yet. So SPI driver didnt get a channel. >
Ideally the SPI driver requests the channel in probe function and if the DMA controller is not yet probed returns EPROBE_DEFER. If the SPI driver requests the channel in the transfer handler it needs to deal with being able to fall back to non DMA transfers anyway so this shouldn't be a problem.
But in any case fiddling around with the init sequences is just a quick hack and might makes the problem less likely to appear in some cases, but there is no guarantee that it works. And I think the proper solution at the moment is to use probe deferral.
Other subsystems have seen patches which moved drivers from using subsys_initcall to device_initcall/module_..._driver/ with the reasoning that this is no longer necessary because of EPROBE_DEFER. So I don't think we should be doing the exact opposite in DMA framework. Also if we'd apply this patch it won't take to long until somebody suggest going back to module_platform_driver() instead of subsys_initcall.
- Lars
| |