On Thu, Aug 21, 2014 at 12:36 AM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Tue, Aug 19, 2014 at 09:02:39PM -0700, Stéphane Marchesin wrote: >> On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding >> <thierry.reding@xxxxxxxxx> wrote: >> > On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote: >> >> Hi Thierry, >> >> >> >> On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding >> >> <thierry.reding@xxxxxxxxx> wrote: >> >> > On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote: >> >> >> Register exynos_dp_panel before the list of exynos crtcs and >> >> >> connectors are probed. >> >> >> >> >> >> This is needed because exynos_dp_panel should be registered to >> >> >> the drm_panel list via panel-exynos-dp probe, i.e much before >> >> >> exynos_dp_bind calls of_drm_find_panel(). >> >> >> >> >> >> Signed-off-by: Ajay Kumar <ajaykumar.rs@xxxxxxxxxxx> >> >> >> --- >> >> >> Changes since V1: >> >> >> Added platform_driver_unregister(&exynos_dp_panel_driver) to >> >> >> exynos_drm_platform_remove as per Jingoo Han's correction >> >> >> >> >> >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 15 +++++++++++++++ >> >> >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 + >> >> >> 2 files changed, 16 insertions(+) >> >> >> >> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c >> >> >> index 1d653f8..2db7f67 100644 >> >> >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c >> >> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c >> >> >> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) >> >> >> goto err_unregister_ipp_drv; >> >> >> #endif >> >> >> >> >> >> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP >> >> >> + ret = platform_driver_register(&exynos_dp_panel_driver); >> >> >> + if (ret < 0) >> >> >> + goto err_unregister_dp_panel; >> >> >> +#endif >> >> > >> >> > No, this is not how you're supposed to use DRM panel drivers. The idea >> >> > is that you write a standalone driver for a given panel. >> >> > >> >> > What you do here has a number of problems. For one it's a driver that's >> >> > tightly coupled to Exynos SoCs. But if I have a different SoC that uses >> >> > the same panel I want to be able to use the same driver, and not have to >> >> > rewrite the driver for my SoC. >> >> > >> >> > Another problem is that you're assuming here that the driver is built in >> >> > and it will break if you try to build either Exynos DRM or the panel >> >> > driver as a module. This is perhaps nothing you care about right now, >> >> > but eventually people will want to ship a single kernel that can run on >> >> > a number of SoCs. But if we keep adding things like this, that kernel >> >> > will keep growing in size until it no longer fits in any kind of memory. >> >> > >> >> > Thierry >> >> >> >> I completely agree with you in this! >> >> >> >> Yes, this is not acceptable, but I want to know an "acceptable" >> >> workaround for the situation below: >> >> I register the driver using module_init(). >> >> And, exynos_drm gets probed much before the panel driver probe happens. >> >> So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm >> >> tries to call >> >> "of_drm_find_panel" which always returns NULL. >> > >> > That's a situation that your driver needs to be able to deal with. The >> > driver registration order doesn't matter one bit. It may happen to work >> > most of the time, but as soon as one of the resources that your panel >> > driver needs isn't there when the panel is probed, then it won't be >> > registered and of_drm_find_panel() will still return NULL. >> > >> > Usually the right thing to do in that case would be to return (and >> > propagate) -EPROBE_DEFER so that your driver's probe is deferred and >> > retried when other drivers have been probed. That way it should >> > eventually get a non-NULL panel. >> >> So I just gave this (drm_panel + probe deferring) a shot on exynos, >> and correctly reacting to -EPROBE_DEFER postpones DP initialization by >> approximately 1.5 second. Is there a good way to handle that? As it >> stands, this isn't usable. > > How much is 1.5 seconds compared to the overall boot time of the device? 1.5s is 15-20% of my boot time (if you count the boot time from firmware start to login prompt, otherwise it's more). Note that on other platforms, we've seen this take as much as 5 or 6s, but for the exynos case it is "only" 1.5s. > What exactly is causing this 1.5 second delay? A regulator isn't ready, and then drm_panel returns defer. Then the whole drm driver init is deferred. > > This really is a fundamental issue with deferred probing and the issue > has come up several times in the past. A couple of possible solutions > have been proposed, with the latest being here[0] I think. That ended in > a bit of a debacle, unfortunately, but on of the outcomes was that a lot > of the ordering problems could be fixed by using phandle references to > track dependencies. I'm not aware of anyone working on that right now, > presumably because everyone is busy getting features merged rather than > optimizing boot speed. Yes, I don't believe boot time ordering will ever happen upstream, but then the current implementation with EPROBE_DEFER isn't usable either. Any ideas? ATM it seems like the only way out is to just write my own dt format for the panel and ignore drm_panel. Stéphane -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |