exynos_drm_init() does probing of various drivers like dp_panel, hdmi, fimd, mixer, etc in an order and finally binds them together. Some of the drm devices (Eg: dp_panel) try to do regulator_get() and enable few supplies during their probe. Chances are that, these devices may get probed before the respective supply/PMIC is hooked. In such cases, dp_panel would continue with "dummy regulator". Which is not what the system wants. Lets give the core connectivity and regulators modules some time to hookup the supplies before Exynos DRM devices comes into picture. Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@xxxxxxxxxxx> --- This change is proposed after 1. Discussing with I2C/SPI & DMA subsystem maintainers and Others @ https://lkml.org/lkml/2014/5/9/333 Trying to change the I2C, SPI and DMA drivers as subsys_initcall() Which was strictly opposed, as a flaw was found in DRM subsystem. 2. -EPROBE_DEFER won't work well with the current sequency of platform_driver_register()s in exynos_drm_init() 3. bridge_panel mechanism is under RFC and no conclusions were drawn yet. We should be able to probe each DRM device independently and let PROBE_DEFER take care of dependencies. But, this could cause lot of bootup time. late_initcall() of DRM works well and fixes all the above issues for now. Kindly suggest, if an alternative/better mechanism is out there. Thanks, drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 4cef88f..78c185a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -692,7 +692,7 @@ static void exynos_drm_exit(void) platform_driver_unregister(&exynos_drm_platform_driver); } -module_init(exynos_drm_init); +late_initcall(exynos_drm_init); module_exit(exynos_drm_exit); MODULE_AUTHOR("Inki Dae <inki.dae@xxxxxxxxxxx>"); -- 1.7.9.5 -- 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
 |