From patchwork Wed Jul 25 20:10:11 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 1239681 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by patchwork2.kernel.org (Postfix) with ESMTP id 5EA70DFFCD for ; Wed, 25 Jul 2012 21:18:22 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 655FC9F514 for ; Wed, 25 Jul 2012 14:18:22 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by gabe.freedesktop.org (Postfix) with ESMTP id 5AC4F9ECCE for ; Wed, 25 Jul 2012 14:16:35 -0700 (PDT) Received: by wibhq4 with SMTP id hq4so4649656wib.12 for ; Wed, 25 Jul 2012 14:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:x-mailer; bh=vvrjiF7TDUE/wKxzl0my3EQltunNYS61FpGVCaZPBuw=; b=LNn9dVAz7cL499uu1ik/q8tC8sKbfxYfXsGpME/qq+DOrkWzjXRwrMIIJQPuejp3l5 2C6M3vzl/vlU55EHn5+zs7rGXEQ6RC+kqlmRhs5SaxIsde3CZPsgJa9jJjpOvX2Cj7Hd fbwFmxNkb4kAAKegXk1XvLLOAE2DPXzGSYI6o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:x-gm-message-state; bh=vvrjiF7TDUE/wKxzl0my3EQltunNYS61FpGVCaZPBuw=; b=FfOKKPgvZkX5je2npD7juYGkON8qNUVADZCzeUFYeSVk7CEq1/iNNkh3IvXxycRfZ6 0UqQBrmtD8I5aNNVm8BtpYdB6kVGk6sT8sZF1tSlBLRkm2V1aOPQjeR4y3cIEjpzWgHu lOg+ysXFA/aUIdGWhDjVRd6LK/2OdszdHSDyNV3Qmr1lIsvsoHblXQ82qOTOjFsGCpUs dpB33FbuTTOdCZVMELHVvrYevQAwUDsgJJHpiztq/eiDnNNFH/M7LPLoxlYFTUL36UTO XW83QExn+KN8djp+3n0IoKO3JKSBw0r60IaF2z3lkAse0GW6hl+Nx3vdJfJIRp0ctSG1 eMwg== Received: by 10.216.68.2 with SMTP id k2mr7074865wed.69.1343250994155; Wed, 25 Jul 2012 14:16:34 -0700 (PDT) Received: from wespe.ffwll.local (178-83-130-250.dynamic.hispeed.ch. [178.83.130.250]) by mx.google.com with ESMTPS id fb20sm6963194wid.1.2012.07.25.14.16.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 14:16:33 -0700 (PDT) From: Daniel Vetter To: Intel Graphics Development , DRI Development Date: Wed, 25 Jul 2012 22:10:11 +0200 Message-Id: <1343247011-7523-1-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 1.7.10.4 X-Gm-Message-State: ALoCoQlZ/OXxBbK/yR31pHzK/uJYa06mT+pWCPB8cCcxN79BNO884gPsZYlf4VlFaVKOYejoRrDF Cc: Daniel Vetter Subject: [Intel-gfx] [PATCH] drm/fb-helper: don't clobber output routing in setup_crtcs X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org Yet again the too close relationship between the fb helper and the crtc helper code strikes. This time around the fb helper resets all encoder->crtc pointers to NULL before starting to set up it's own mode. Which is total bullocks, because this will clobber the existing output routing, which the new drm/i915 code depends upon to be absolutely correct. The crtc helper itself doesn't really care about that, since it disables unused encoders in a rather roundabout way. Two places call drm_setup_crts: - For the initial fb config. I've auditted all current drivers, and they all allocate their encoders with kzalloc. So there's no need to clear encoder->crtc once more. - When processing hotplug events while showing the fb console. This one is a bit more tricky, but both the crtc helper code and the new drm/i915 modeset code disable encoders if their crtc is changed and that encoder isn't part of the new config. Also, both disable any disconnected outputs, too. Which only leaves encoders that are on, connected, but for some odd reason the fb helper code doesn't want to use. That would be a bug in the fb configuration selector, since it tries to light up as many outputs as possible. v2: Kill the now unused encoders variable. Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_helper.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index f546d1e..4ecc869 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1230,7 +1230,6 @@ static void drm_setup_crtcs(struct drm_fb_helper *fb_helper) struct drm_device *dev = fb_helper->dev; struct drm_fb_helper_crtc **crtcs; struct drm_display_mode **modes; - struct drm_encoder *encoder; struct drm_mode_set *modeset; bool *enabled; int width, height; @@ -1241,11 +1240,6 @@ static void drm_setup_crtcs(struct drm_fb_helper *fb_helper) width = dev->mode_config.max_width; height = dev->mode_config.max_height; - /* clean out all the encoder/crtc combos */ - list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) { - encoder->crtc = NULL; - } - crtcs = kcalloc(dev->mode_config.num_connector, sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL); modes = kcalloc(dev->mode_config.num_connector,