On Mon, Nov 08, 2021 at 09:16:07PM +0300, Dmitry Osipenko wrote: > 08.11.2021 18:17, Daniel Vetter пишет: > > On Mon, Nov 08, 2021 at 02:08:21AM +0300, Dmitry Osipenko wrote: > >> Use drm_dp_aux_register_ddc/chardev() helpers that allow to register I2C > >> adapter separately from the character device. This fixes broken display > >> panel driver of Acer Chromebook CB5-311 that fails to probe starting with > >> v5.13 kernel when DP AUX registration order was changed. Tegra SOR driver > >> is never probed now using the new registration order because tegra-output > >> always fails with -EPROBE_DEFER due to missing display panel that requires > >> DP AUX DDC to be registered first. The offending commit made DDC to be > >> registered after SOR's output, which can't ever happen. Use new helpers > >> to restore the registration order and revive display panel. > > > > This feels a bit backward, I think the clean solution would be to untangle > > the SOR loading from the panel driver loading, and then only block > > registering the overall drm_device on both drivers having loaded. > > Sounds impossible. > > 1. DRM device can be created only when all components are ready, panel > is one of the components. Nope. drm_device can be instantiated whenever you feel like. drm_dev_register can only be called when it's all fully set up. Absolutely nothing would work if drm_device wouldn't support this two-stage setup. So sequence: 1. drm_dev_init 2. bind sor driver 3. create dp aux ddc 4. bind panel 5. yay we have everything, drm_dev_register This should work, and it's designed to work like this actually. You couldn't write big complex drivers otherwise. -Daniel > > 2. SOR driver is controlling panel and programs h/w based on panel presence. > > 3. Panel can't become ready until DP AUX DDC is created. > > 4. DP AUX DDC can't be created until DRM device is created. > > 5. Go to 1. > > Even if there is an option to somehow rewrite Tegra DRM driver to > accommodate it to the desired driver model, it won't be something > portable to stable kernels. > > > This here at least feels like a game of whack-a-mole, if like every driver > > needs its own careful staging of everything. > > That is inevitable because each hardware design is individual. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
