Scheduling the output_poll_work before calling bind_all to create the crtcs can race the fbdev initialization with the components initialization (i.e. crtc initialization). One side effect is that we may call drm_fbdev_cma_init with a zeroed num_crtc value, crashing the fbdev allocation.
I found this while auditing the code to remove the crtc_count parameter from drm_fbdev_cma_init. I don't have the hardware to actually test this change, so it'd be better covered if someone can give a try. Although, every other driver I checked did this on a later phase of initialization.
Signed-off-by: Gabriel Krisman Bertazi krisman@collabora.co.uk Cc: Benjamin Gaignard benjamin.gaignard@linaro.org Cc: Vincent Abriou vincent.abriou@st.com --- drivers/gpu/drm/sti/sti_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c index d3db22488f96..516296010735 100644 --- a/drivers/gpu/drm/sti/sti_drv.c +++ b/drivers/gpu/drm/sti/sti_drv.c @@ -323,8 +323,6 @@ static int sti_init(struct drm_device *ddev)
sti_mode_config_init(ddev);
- drm_kms_helper_poll_init(ddev); - return 0; }
@@ -362,6 +360,8 @@ static int sti_bind(struct device *dev) if (ret) goto err_cleanup;
+ drm_kms_helper_poll_init(ddev); + ret = drm_dev_register(ddev, 0); if (ret) goto err_register;