[...]

quoted

The only related PM thing, that shall be the decision of the driver,
is whether it wants to enable runtime PM or not, during ->probe().

So do you want to create the links during the DMAengine driver probe? How do
you
plan to find all the client devices? Please note that you really want to
create
links to devices which will really use the DMA engine calls. Some client
drivers might decide in runtime weather to use DMA engine or not, depending
on
other data.

I don't have great plan, just wanted to share my thoughts around the
problems we want to solve.

[...]

quoted

If we could set up the device link already at device initialization,
it should also be possible to avoid getting -EPROBE_DEFER for dma
client drivers when requesting their dma channels.

At the first glance this sounds like an ultimate solution for all problems,
but I don't think that device links can be used this way. If I get it right,
you would like to create links on client device initialization, preferably
somewhere in the kernel driver core. This will be handled somehow by a
completely generic code, which will create a link each pair of devices,
which are connected by a phandle. Is this what you meant? Please note that
that time no driver for both client and provider are probed. IMHO that
doesn't look like a right generic approach

How that code will know get following information:
1. is it really needed to create a link for given device pair?
2. what link flags should it use?
3. what about circular dependencies?
4. what about runtime optional dependencies?
5. what about non-dt platforms? acpi?

To give a good answer of these questions, I need to spend more time
investigating.

However, from a top-level point of view, I think the device links
seems like the perfect match for solving the runtime/system PM
problems.

No matter whether we can set up the links at device initialization
time, driver probe or whatever time.

This looks like another newer ending story of "how can we avoid deferred
probe
in a generic way". IMHO we should first solve the problem of irq-safe
runtime
PM in DMA engine drivers first. I proposed how it can be done with device
links.
With no changes in the client API. Later if one decide to extend the client
API
in a way it will allow other runtime PM implementation - I see no problem to
convert pl330 driver to the new approach, but for the time being - this
would
be the easiest way to get it really functional.

Agree, let's drop the deferred probe topic from the discussions - it's
just going to be overwhelming. :-)

[...]

quoted

So besides solving the irq-safe issue for dma driver, using the
device-links has additionally two advantages. I already mentioned the
-EPROBE_DEFER issue above.

Not really. IMHO device links can be properly established once both drivers
are probed...

Okay.

quoted

The second thing, is the runtime/system PM relations we get for free
by using the links. In other words, the dma driver/core don't need to
care about dealing with pm_runtime_get|put() as that would be managed
by the dma client driver.

IMHO there might be drivers which don't want to use device links based
runtime
PM in favor of irq-safe PM or something else. This should be really left to
drivers.

Okay.

Kind regards
Uffe