search for: drm_for_each_connector

...struct drm_crtc_state *crtc_state; + struct drm_crtc *crtc; + int ret, i; state = drm_atomic_state_alloc(dev); if (!state) @@ -2437,29 +2441,48 @@ int drm_atomic_helper_disable_all(struct drm_device *dev, state->acquire_ctx = ctx; - drm_connector_list_iter_get(dev, &conn_iter); - drm_for_each_connector_iter(conn, &conn_iter) { - struct drm_crtc *crtc = conn->state->crtc; - struct drm_crtc_state *crtc_state; - - if (!crtc || conn->dpms != DRM_MODE_DPMS_ON) - continue; - + drm_for_each_crtc(crtc, dev) { crtc_state = drm_atomic_get_crtc_state(state, crtc); if (IS_ERR(crtc_sta...

...k. > > > > So what do we do with this? It fixes a problem upstream. There's no > > Fixes: to identify the bad commit. Any idea on that? It's either this or > > we dig out the bad commit (Chris probably knows which one?) and revert. > > The real trouble is the drm_for_each_connector in > drm_connector_register_all(). This introduced the new depency. The proper > fix imo is to fix up the connector_list locking, but for 4.8 we could do > the same hack+comment like we do in unregister_all. It's not the only > place that's broken anyway, and much less invasive...

...gt; So what do we do with this? It fixes a problem upstream. There's no > > > Fixes: to identify the bad commit. Any idea on that? It's either this or > > > we dig out the bad commit (Chris probably knows which one?) and revert. > > > > The real trouble is the drm_for_each_connector in > > drm_connector_register_all(). This introduced the new depency. The proper > > fix imo is to fix up the connector_list locking, but for 4.8 we could do > > the same hack+comment like we do in unregister_all. It's not the only > > place that's broken anyway, and...

...struct drm_crtc_state *crtc_state; + struct drm_crtc *crtc; + int ret, i; state = drm_atomic_state_alloc(dev); if (!state) @@ -2446,29 +2450,48 @@ int drm_atomic_helper_disable_all(struct drm_device *dev, state->acquire_ctx = ctx; - drm_connector_list_iter_get(dev, &conn_iter); - drm_for_each_connector_iter(conn, &conn_iter) { - struct drm_crtc *crtc = conn->state->crtc; - struct drm_crtc_state *crtc_state; - - if (!crtc || conn->dpms != DRM_MODE_DPMS_ON) - continue; - + drm_for_each_crtc(crtc, dev) { crtc_state = drm_atomic_get_crtc_state(state, crtc); if (IS_ERR(crtc_sta...

...tc *crtc; > + int ret, i; > > state = drm_atomic_state_alloc(dev); > if (!state) > @@ -2437,29 +2441,48 @@ int drm_atomic_helper_disable_all(struct drm_device *dev, > > state->acquire_ctx = ctx; > > - drm_connector_list_iter_get(dev, &conn_iter); > - drm_for_each_connector_iter(conn, &conn_iter) { > - struct drm_crtc *crtc = conn->state->crtc; > - struct drm_crtc_state *crtc_state; > - > - if (!crtc || conn->dpms != DRM_MODE_DPMS_ON) > - continue; > - > + drm_for_each_crtc(crtc, dev) { > crtc_state = drm_atomic_get_crtc_st...

...; > fbcon is a lot more work. > > So what do we do with this? It fixes a problem upstream. There's no > Fixes: to identify the bad commit. Any idea on that? It's either this or > we dig out the bad commit (Chris probably knows which one?) and revert. The real trouble is the drm_for_each_connector in drm_connector_register_all(). This introduced the new depency. The proper fix imo is to fix up the connector_list locking, but for 4.8 we could do the same hack+comment like we do in unregister_all. It's not the only place that's broken anyway, and much less invasive than this here. If...

On Tue, 12 Jul 2016, Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote: >> Backlights controlled by i915.ko and only associated with its connectors >> and also only associated with the intel_drmfb fbcon, controlled by >> i915.ko. In this situation, we already handle adjusting the backlight >> when the fbcon is