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 <broonie@xxxxxxxxxx> 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.
Attachment:
signature.asc
Description: Digital signature
