[PATCH] drm/exynos: Make exynos_drm_init() call late during the bootup
Naveen Krishna Ch
naveenkrishna.ch at gmail.com
Sun May 25 22:39:52 PDT 2014
Hello Everyone,
On 21 May 2014 21:16, Thierry Reding <thierry.reding at gmail.com> 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 at samsung.com>
>> ---
>> 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 :)
More information about the dri-devel
mailing list