[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