On 06/11/2015 12:17 PM, Alexander Holler wrote:

Am 11.06.2015 um 10:12 schrieb Linus Walleij:

quoted

On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler [off-list ref] wrote:

quoted

Am 10.06.2015 um 09:30 schrieb Linus Walleij:

quoted

quoted

i2c host comes out, probes the regulator driver, regulator driver
probes and then the regulator_get() call returns.

This requires instrumentation on anything providing a resource
to another driver like those I mentioned and a lot of overhead
infrastructure, but I think it's the right approach. However I don't
know if I would ever be able to pull that off myself, I know talk
is cheap and I should show the code instead.

You would end up with the same problem of deadlocks as currently, and you
would still need something ugly like the defered probe brutforce to avoid
them.

Sorry I don't get that. Care to elaborate on why?

Because loading/initializing on demand doesn't give you any solved order 
of drivers to initialize. And it can't because it has no idea about the 
requirements of other drivers.

So, this is only about ordering device probing. All built-in drivers
have already registered themselves by when we start probing.

The reason why it might work better in 
the case of the tegra is that it might give you another initialization 
order than the one which is currently choosen, which, by luck, might be 
a better one.

Note that this series was also tested on iMX.6, Exynos and OMAP4.

But maybe I missed something, I haven't looked at the patches at all. 

It's a really small patchset :)

  19 files changed, 130 insertions(+), 45 deletions(-)

Thanks,

Tomeu

But just loading on demand, can't magically give you a working order of 
drivers to initialize. E.g. how do you choose the first driver to 
initialize?

Regards,

Alexander Holler

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel