Hello Everyone, On 21 May 2014 21:16, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Wed, May 14, 2014 at 05:09:45PM +0530, Naveen Krishna Chatradhi wrote: >> 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() > > Then this is the problem that you need to fix. If the driver doesn't > handle -EPROBE_DEFER properly then that means the driver is broken. No > amount of initcall ordering can fix this for you. We seem to have a problem with the probe sequencing and usage of _EPROBE_DEFER in DRM. Component way of registration doesnt seem to fix everything. Inki Dae, Is there any discussion or approach underway. Anyone working on this. > > Thierry -- Shine bright, (: Nav :) _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
