[alsa-devel] of_dma_request_slave_channel() failed ?

Robin Murphy robin.murphy at arm.com
Thu Sep 13 12:11:49 CEST 2018


On 13/09/18 10:00, Geert Uytterhoeven wrote:
[...]
> The main issue is that if of_dma_find_controller() fails, a DMA slave driver
> cannot distinguish between dmac not yet probed successfully, and dmac
> driver not present.

...which is in fact the exact same problem that the IOMMU code has - 
might it make sense to give of_dma_request_slave_channel() similar 
(optional?) driver_deferred_probe_check_state() logic, i.e. "if my DMAC 
driver's not shown up by this point, assume it's not built-in and go on 
without it". Of course it is somewhat easier for IOMMU drivers as 
there's zero chance of those popping up as modules later on.

> However, as we rely more and more on probe deferral, this will cause more
> issues in the future.
> 
> I guess the proper solution is to take into account dependencies described
> in DT before probing devices, i.e. devices with phandles should always be
> probed after the targets of these phandles?
> Complication:
>    - Circular dependencies,
>    - Optional phandle targets (dmacs, oops).

Yeah, a proper dependency graph would be ideal, but it's certainly not 
trivial. There was an interesting proposal a couple of years ago of a 
half-way approach where various phandle-chasing routines could actively 
try to probe the target, but I think that got stymied on the fact that a 
single OF node may represent multiple different driver-level providers, 
so it's tricky to tell whether the *right* dependency has been satisfied 
without detailed knowledge of the individual bindings and driver 
implementations. That's probably still an issue for other approaches 
too, sadly.

Robin.


More information about the Alsa-devel mailing list