From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2959DC433DF for ; Wed, 8 Jul 2020 16:54:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0627D2063A for ; Wed, 8 Jul 2020 16:54:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=flowbird.group header.i=@flowbird.group header.b="TtGG4LDi" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730503AbgGHQyM (ORCPT ); Wed, 8 Jul 2020 12:54:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730339AbgGHQyL (ORCPT ); Wed, 8 Jul 2020 12:54:11 -0400 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 54DA5C061A0B for ; Wed, 8 Jul 2020 09:54:11 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id a6so49750975wrm.4 for ; Wed, 08 Jul 2020 09:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flowbird.group; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WOVkqwckQQd55xs9l2xekP/piuHMiACO9inQRc/624Y=; b=TtGG4LDilrrh105PxPZxfegeCFu329cU+BDYujVlSNPA/eV+N5rQLeSu4f9VNLv4EY jJXnMpeYSsY9v5ysdriB/Hdv7bPmV6ebu0WLsdR5QtuofFwIKWHA25JdHRc8aJmzbtST dkPMA8o+wOk1I1iqtY8N8XkkS8AY9V/RXRrRmMpZhOHeETr6llzVlatZu8t4uIRUziB/ pZCHiO5QP8ZfoMsI13oKDv2l5Sao7jE9NVeqdVzNS8i7Sp+FU7KFZsf/qKt9IB8E1irm 0YehjaJ5rDST1wEhuW7LtWdNQ/+HKsI9krgqqI7O7wAyVZ2Wm6XV9+9fRTczuXASdmoi Q0Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WOVkqwckQQd55xs9l2xekP/piuHMiACO9inQRc/624Y=; b=AbzpUCrNa8839lByWpY/VvJaGJVr/YOSf1i/5xOCO8CNhTdDqpT7ZW6YnQ7VG6aRY2 nhhp/w4fp247pz0aRG9g+0rgyOv/BwFa+35BiTX1G+QBf3RpWp2n/7XpurSbg1ha5WOf f4GG9mQW3wmmV524qUMG/7h0viP/vnnu4oewI089cc4cu5HzUVmuwT/kmzp38AmSFTrF klLdoazqWkGpinypeLQSZmRkbKtIjt8L8+ElBcuHIFQ9NYSEjb6squWk11eDyTh+1ni/ 9ceNrpgBpJwFlaH37kCmj0Viadk9WwCVwPeTnTImQ1zbgZ4DLxjNc1F1Go2OlsxovFzb 1eLQ== X-Gm-Message-State: AOAM5326vxPOe8uGITHriWh438Q2Qjlo1wWeoHzR/KCM9AktNpEQ8ItM 1s8cLON1V8KtjqyBOj06IYMGXdSY74sOWiah8FSFUg== X-Google-Smtp-Source: ABdhPJyVCpbbKtoLOEzP8YwwHDnBfwPBOs+phqlZhXQ4uNw+YwtkN1XbsB4wVgHaAUiql5DgdP9vGzDTZQsegl1cvIg= X-Received: by 2002:adf:9062:: with SMTP id h89mr55137959wrh.285.1594227249993; Wed, 08 Jul 2020 09:54:09 -0700 (PDT) MIME-Version: 1.0 References: <1594137527-15201-1-git-send-email-martin.fuzzey@flowbird.group> In-Reply-To: From: "Fuzzey, Martin" Date: Wed, 8 Jul 2020 18:53:59 +0200 Message-ID: Subject: Re: [PATCH] drm: imx: Fix occasional screen corruption on modeset. To: Philipp Zabel Cc: Shawn Guo , Sascha Hauer , ML dri-devel , "Linux-Kernel@Vger. Kernel. Org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Philipp, thanks for the quick reply. On Wed, 8 Jul 2020 at 10:31, Philipp Zabel wrote: > Could this be just a panel getting confused because the pixel clock is > disabled, or is there really an issue with the IPU? Have you tried just > keeping clk_di_pixel enabled in ipu_di_disable(), but continuing > to disable DI and DC? > I've tried that now but still observed the corruption. > > The exact reason isn't understood but it seems timing related. > > Also just adding a msleep(2) or a mdelay(20) at the end of ipu_crtc_atomic_disable() makes the problem go away too. Obviously I'm not suggesting doing that, just that it may help understand what is going on. > > Just removing ipu_di_disable() leaks a clk_prepare_enable refcount on > the di->clk_di_pixel clock. > > Also this is followed by an ipu_dc_disable(), which should remove the DC > module's clock if this is the only display. So the DC should be disabled > anyway. > True. How about doing just ipu_crtc_disable_planes() and drm_crtc_vblank_off() in the active (modeset) case. and in ipu_crtc_atomic_enable() only doing the stuff (which doesn't touch the planes) if old_state->active == false ? That will fix the clock refcount problem and seems generally better as tearing down everything just to do a modeset seems a bit heavy handed. I've tested that and it works too but it's probably better to discuss this some more before sending a new patch. Regards, Martin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C6DCC433E0 for ; Thu, 9 Jul 2020 07:07:46 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 02AE020674 for ; Thu, 9 Jul 2020 07:07:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=flowbird.group header.i=@flowbird.group header.b="TtGG4LDi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 02AE020674 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=flowbird.group Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 988E26EA16; Thu, 9 Jul 2020 07:05:38 +0000 (UTC) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6DB466E57E for ; Wed, 8 Jul 2020 16:54:11 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id s10so49699161wrw.12 for ; Wed, 08 Jul 2020 09:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flowbird.group; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WOVkqwckQQd55xs9l2xekP/piuHMiACO9inQRc/624Y=; b=TtGG4LDilrrh105PxPZxfegeCFu329cU+BDYujVlSNPA/eV+N5rQLeSu4f9VNLv4EY jJXnMpeYSsY9v5ysdriB/Hdv7bPmV6ebu0WLsdR5QtuofFwIKWHA25JdHRc8aJmzbtST dkPMA8o+wOk1I1iqtY8N8XkkS8AY9V/RXRrRmMpZhOHeETr6llzVlatZu8t4uIRUziB/ pZCHiO5QP8ZfoMsI13oKDv2l5Sao7jE9NVeqdVzNS8i7Sp+FU7KFZsf/qKt9IB8E1irm 0YehjaJ5rDST1wEhuW7LtWdNQ/+HKsI9krgqqI7O7wAyVZ2Wm6XV9+9fRTczuXASdmoi Q0Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WOVkqwckQQd55xs9l2xekP/piuHMiACO9inQRc/624Y=; b=g6iG/Dtqf00qphglTBVgln2Kor3veQl9Zxp4wVB3UdbvVoUZXX1TEqXo4nn/4Fxnrf c+nQ18HPZ7n/AxK5LBoqNVQOLsOFBDA1P/dVzw5Ssk2WGBT2zJULMGp1QDty711JUhX6 iW1/D2sCKQKj0C9pODsCIrMhRg1gPbLNnTHPA0+4QtPdDz3Y/2hyy7b+xMaxYfs8yJ1y yqWVoz+zsrBDK7j+/pjUpKOR4JtSbAAeLdK6o2ajnkcK37iw9g+0iQbZNzmf18eBOW7/ XTiUXjk6hjqRybiDA+ZYNv5UhbNZemw397e41osLHzn1Ff3AMLtxFKwqWweYipAkDHOW rzeA== X-Gm-Message-State: AOAM531ooZwvpfTy4iIgX8fFvevLGhtcpx4/yhgwSBfERLq/X9C233P/ ej7PPw7pRmZnzjmJL9NWXztwzJWZNrd5nV6PaN1b4ZIQcsIdpg== X-Google-Smtp-Source: ABdhPJyVCpbbKtoLOEzP8YwwHDnBfwPBOs+phqlZhXQ4uNw+YwtkN1XbsB4wVgHaAUiql5DgdP9vGzDTZQsegl1cvIg= X-Received: by 2002:adf:9062:: with SMTP id h89mr55137959wrh.285.1594227249993; Wed, 08 Jul 2020 09:54:09 -0700 (PDT) MIME-Version: 1.0 References: <1594137527-15201-1-git-send-email-martin.fuzzey@flowbird.group> In-Reply-To: From: "Fuzzey, Martin" Date: Wed, 8 Jul 2020 18:53:59 +0200 Message-ID: Subject: Re: [PATCH] drm: imx: Fix occasional screen corruption on modeset. To: Philipp Zabel X-Mailman-Approved-At: Thu, 09 Jul 2020 07:05:03 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sascha Hauer , Shawn Guo , "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Philipp, thanks for the quick reply. On Wed, 8 Jul 2020 at 10:31, Philipp Zabel wrote: > Could this be just a panel getting confused because the pixel clock is > disabled, or is there really an issue with the IPU? Have you tried just > keeping clk_di_pixel enabled in ipu_di_disable(), but continuing > to disable DI and DC? > I've tried that now but still observed the corruption. > > The exact reason isn't understood but it seems timing related. > > Also just adding a msleep(2) or a mdelay(20) at the end of ipu_crtc_atomic_disable() makes the problem go away too. Obviously I'm not suggesting doing that, just that it may help understand what is going on. > > Just removing ipu_di_disable() leaks a clk_prepare_enable refcount on > the di->clk_di_pixel clock. > > Also this is followed by an ipu_dc_disable(), which should remove the DC > module's clock if this is the only display. So the DC should be disabled > anyway. > True. How about doing just ipu_crtc_disable_planes() and drm_crtc_vblank_off() in the active (modeset) case. and in ipu_crtc_atomic_enable() only doing the stuff (which doesn't touch the planes) if old_state->active == false ? That will fix the clock refcount problem and seems generally better as tearing down everything just to do a modeset seems a bit heavy handed. I've tested that and it works too but it's probably better to discuss this some more before sending a new patch. Regards, Martin _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel