On 06/11/2015 12:17 PM, Alexander Holler wrote: > Am 11.06.2015 um 10:12 schrieb Linus Walleij: >> On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler <holler@xxxxxxxxxxxxx> wrote: >>> Am 10.06.2015 um 09:30 schrieb Linus Walleij: >> >>>> 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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
