Hello Wolfram, On 21 May 2014 15:55, Wolfram Sang <w...@the-dreams.de> wrote: > On Fri, May 09, 2014 at 03:54:25PM +0100, Mark Brown wrote: >> On Fri, May 09, 2014 at 08:12:47PM +0530, Naveen Krishna Ch wrote: >> > On 9 May 2014 19:21, Mark Brown <broo...@kernel.org> wrote: >> > > On Fri, May 09, 2014 at 05:50:00PM +0530, Naveen Krishna Ch wrote: >> >> > >> DRM related drivers like DP, FIMD, HDMI, Mixer wants to be probed ASAP >> > >> during the boot. >> > >> The real problem comes when, one of these drivers do a regulator_get(). >> >> > >> If the physical supply is not enabled/hookedup the regulator_get() call >> > >> assumes that physical supply is present and returns a >> > >> "dummy_regulator" (But, not an error). >> >> > >> Because of which, Display and several other devices fails to work. >> >> > > These drivers are buggy, if they geniunely expect and handle a missing >> > > supply then they should be using regulator_get_optional() to request the >> > > regulator and even if they don't the use of subsys_initcall() is not >> > > going to fix anything here - if a dummy regulator is going to be >> > > returned the time things are probed won't make a difference. >> >> ... >> >> > If all the I2C, SPI, DMA, I2C_TUNNEL, DRM based LCD are all mod_probes() >> > DRM drivers are probing a head of the PMIC probe. Which is causing the >> > display drivers to get "dummy_regulators" instead of the real supplies. >> >> No, it really won't - I have no idea what you are doing but it's not >> mainline. If you are getting dummy regulators then you don't have a >> supply present at all and probe ordering isn't going to make a blind >> bit of difference. >> >> Please provide a specific technical description of the problem you are >> seeing in mainline. > > +1 Unless we have a clear understanding that this is the only acceptable > solution in mainline, this is really an out-of-tree patch.
Few of the DRM based devices need regulators during their probe and DRM subsystem wants to bring up LCD as fast as it could to give a better user experience. Exynos DRM (few others for that matter) does platform_driver_register() of devices in a sequence and finally binds them all together into one blob or /dev/dri-0 device. Which makes it hard to implement -EPROBE_DEFER. Even if -EPROBE_DEFER is implemented in DRM, it adds lot of overhead during the boot up. I've proposed to make exynos_drm_init() as late_initcall() instead of making I2C, SPI, DMA and I2C-arbitrator and I2C-TUNNEL drivers as subsys_initcall() http://www.spinics.net/lists/linux-samsung-soc/msg30858.html Kindly, suggest a workable approach for all the subsystems. > -- Shine bright, (: Nav :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
