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=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 D2F3FC48BC2 for ; Mon, 21 Jun 2021 11:44:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B34426109E for ; Mon, 21 Jun 2021 11:44:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229611AbhFULqg (ORCPT ); Mon, 21 Jun 2021 07:46:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229487AbhFULqg (ORCPT ); Mon, 21 Jun 2021 07:46:36 -0400 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F78EC061574; Mon, 21 Jun 2021 04:44:21 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id u20so5001398ljl.13; Mon, 21 Jun 2021 04:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TvnTnGnSvT/wzcRtCIQ6B7dOOoTU5ysPY7rP65LBPcY=; b=NXGg0c7craxUcqNhRaT+jQw2x5ROQqdt5x2dBCqXs2jNFOEy/YGap3LnXP1YwcUAjM 5G01dyQKmz25sWNdAzoECLk94HKhYL3CSlwl8Sb8Cr9/Z0uIcXA+uKLE2DXZ7xzJGgCh LpexwTncTGfEFCD0q83Dbcor+Aao2Jhbtym/jCGzjruRUIg3QuWH5NboNFiUrYIoVAwS QALcOuU0LGWRYtO5ZSu1YTuK0vb0SsavpdHeIWe3owroU6nnG93Oc0/DWQ1hga5vuhod NU/eTkw/kA3mLYrsFDCJqSfxEQNpeBZEQpZwvqyDS/vaIJtMJ+IuIpl0bSd4qj0nex/T JDjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TvnTnGnSvT/wzcRtCIQ6B7dOOoTU5ysPY7rP65LBPcY=; b=QWYmaQInwfwqnhYUSyvdH5YTcd7RzvpRypRU83/jrktqfGAjeu6Aibx9GrlCt9izfy C0W6TjUwAl7Ok6vlN+kQFEi2XkSNVuUrJsZmidQhqza+/6SfygshwlYqMmyThT68H6z1 3qbax7qlU1HNTTWLZQP554jP3KTs5YfFNWBawXWIoWS5OLPrSNdufBMVYdCHAAIEF8ZW gR41LVgdwNyiHZfL3vSGtFfELW8vDiz7dXMrMbn5hDKdmnTyTh1w5clNdfCXyEc5Vvhg YQZAeOH9wg8UpyJneOTI3WoCq4unfB2dcm1aventCnGstIyQavgiDWFPwL2AvMgJqoL+ UE4A== X-Gm-Message-State: AOAM532F4mwuf/q9+sN/0fGV7dQF9JI56wwORmrhAmRx4F/ex6REPfe0 b6FbXMbGYGMy2pyVTeG6twY= X-Google-Smtp-Source: ABdhPJzZqNE1v82IJt68up+rW8SvYARB7SxPKZ+9ubQvwMGy0eOKEOsPIa0ETY98RpNKHEL+/717Ng== X-Received: by 2002:a05:651c:236:: with SMTP id z22mr5920364ljn.106.1624275859324; Mon, 21 Jun 2021 04:44:19 -0700 (PDT) Received: from [192.168.2.145] (94-29-29-31.dynamic.spd-mgts.ru. [94.29.29.31]) by smtp.googlemail.com with ESMTPSA id z4sm2085643lji.61.2021.06.21.04.44.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Jun 2021 04:44:19 -0700 (PDT) Subject: Re: [PATCH v18 0/2] Add memory bandwidth management to NVIDIA Tegra DRM driver To: Thierry Reding Cc: linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Matt Merhar , Jonathan Hunter , Peter Geis , Nicolas Chauvet , =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= References: <20210601042108.1942-1-digetx@gmail.com> <8accfe1e-fc48-21ca-f7c6-bd2d60162e6d@gmail.com> <50912a57-aa43-58b0-02d2-6928578d6286@gmail.com> From: Dmitry Osipenko Message-ID: Date: Mon, 21 Jun 2021 14:43:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org 21.06.2021 14:01, Thierry Reding пишет: > On Mon, Jun 21, 2021 at 07:19:15AM +0300, Dmitry Osipenko wrote: >> 07.06.2021 01:40, Dmitry Osipenko пишет: >>> 01.06.2021 07:21, Dmitry Osipenko пишет: >>>> This series adds memory bandwidth management to the NVIDIA Tegra DRM driver, >>>> which is done using interconnect framework. It fixes display corruption that >>>> happens due to insufficient memory bandwidth. >>>> >>>> Changelog: >>>> >>>> v18: - Moved total peak bandwidth from CRTC state to plane state and removed >>>> dummy plane bandwidth state initialization from T186+ plane hub. This >>>> was suggested by Thierry Reding to v17. >>>> >>>> - I haven't done anything about the cursor's plane bandwidth which >>>> doesn't contribute to overlapping bandwidths for a small sized >>>> window because it works okay as-is. >>> >>> Thierry, will you take these patches for 5.14? >>> >> >> The display controller does _NOT_WORK_ properly without bandwidth >> management. > > That's surprising. So either it has never worked before (which I think > I'd know) or something has caused this regression recently. In the > latter case we need to identify what that was and revert (or fix) it. The problem is caused by the support of dynamic memory frequency scaling which does a good job at keeping memory in a low power state during idle time. So display controller may not get enough bandwidth at the start of scanout if it won't request BW beforehand. This problem existed for many years on T124 and now T20/30 are also affected. The DC of T20 is the least tolerant to memory bandwidth troubles. This problem is not critical, but it hurts user experience since high resolution modes may not work at all and display output may become distorted, requiring a DC reset. >> Can we get this patch into 5.14? What is the problem? > > There was not enough time to review and test this, so I didn't feel > comfortable picking it up so close to the -rc6 cut-off. I plan to pick > this up early in the v5.14 release cycle and target v5.15. Thank you for the explanation! It's not uncommon to forget about patches, so the silence worries me. I hoped that both the dynamic freq scaling and display BW support would be merged around the same time, but apparently we got a disconnect here. 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=-2.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 C8849C4743C for ; Mon, 21 Jun 2021 11:44:23 +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 67023601FE for ; Mon, 21 Jun 2021 11:44:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67023601FE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 DD72B8991E; Mon, 21 Jun 2021 11:44:22 +0000 (UTC) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3358A8991E for ; Mon, 21 Jun 2021 11:44:21 +0000 (UTC) Received: by mail-lj1-x236.google.com with SMTP id q23so14269268ljh.0 for ; Mon, 21 Jun 2021 04:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TvnTnGnSvT/wzcRtCIQ6B7dOOoTU5ysPY7rP65LBPcY=; b=NXGg0c7craxUcqNhRaT+jQw2x5ROQqdt5x2dBCqXs2jNFOEy/YGap3LnXP1YwcUAjM 5G01dyQKmz25sWNdAzoECLk94HKhYL3CSlwl8Sb8Cr9/Z0uIcXA+uKLE2DXZ7xzJGgCh LpexwTncTGfEFCD0q83Dbcor+Aao2Jhbtym/jCGzjruRUIg3QuWH5NboNFiUrYIoVAwS QALcOuU0LGWRYtO5ZSu1YTuK0vb0SsavpdHeIWe3owroU6nnG93Oc0/DWQ1hga5vuhod NU/eTkw/kA3mLYrsFDCJqSfxEQNpeBZEQpZwvqyDS/vaIJtMJ+IuIpl0bSd4qj0nex/T JDjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TvnTnGnSvT/wzcRtCIQ6B7dOOoTU5ysPY7rP65LBPcY=; b=BEY+MnSW2gPZeOr5eeN0ZGQ1/VPWgKYjP/7hhHQJz6bn8RjKUu4x0CaYI7pqPkgmwy nDGwVVSHz+hN0qPqeGyRF1Fx2kRDfoN6Eu0H36QPrKyqR4f1lGiM/jwc5gY3fo/A52Ee SyV1ya3crDatOjVyiFAdFC2PkqDDAaEAqwSOi54Js+bFIc+57CExw1dX6OmTOJoTc95h 3mbnFTFfYhd8t+meCci6MV04bUQpmmpb5yVk5/7Qs0nK7oXUr3Bj7gkDom46nqgQwVBr 9wUu1uhG3vbZh7hNI9NPi6qzrinIJS1ZCvXKzum/3er9xtjKavusS9kVPG4TGzn2pS2C //Yg== X-Gm-Message-State: AOAM532WxV/uw+3Iie1+c+5hmvRmzc8FaKarL9RSTOsQ3uohfZus6u0h g7UYF6hfv1Mc6PkYj+VFQMQ= X-Google-Smtp-Source: ABdhPJzZqNE1v82IJt68up+rW8SvYARB7SxPKZ+9ubQvwMGy0eOKEOsPIa0ETY98RpNKHEL+/717Ng== X-Received: by 2002:a05:651c:236:: with SMTP id z22mr5920364ljn.106.1624275859324; Mon, 21 Jun 2021 04:44:19 -0700 (PDT) Received: from [192.168.2.145] (94-29-29-31.dynamic.spd-mgts.ru. [94.29.29.31]) by smtp.googlemail.com with ESMTPSA id z4sm2085643lji.61.2021.06.21.04.44.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Jun 2021 04:44:19 -0700 (PDT) Subject: Re: [PATCH v18 0/2] Add memory bandwidth management to NVIDIA Tegra DRM driver To: Thierry Reding References: <20210601042108.1942-1-digetx@gmail.com> <8accfe1e-fc48-21ca-f7c6-bd2d60162e6d@gmail.com> <50912a57-aa43-58b0-02d2-6928578d6286@gmail.com> From: Dmitry Osipenko Message-ID: Date: Mon, 21 Jun 2021 14:43:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: linux-pm@vger.kernel.org, Nicolas Chauvet , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Jonathan Hunter , Matt Merhar , Peter Geis , linux-tegra@vger.kernel.org, =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 21.06.2021 14:01, Thierry Reding пишет: > On Mon, Jun 21, 2021 at 07:19:15AM +0300, Dmitry Osipenko wrote: >> 07.06.2021 01:40, Dmitry Osipenko пишет: >>> 01.06.2021 07:21, Dmitry Osipenko пишет: >>>> This series adds memory bandwidth management to the NVIDIA Tegra DRM driver, >>>> which is done using interconnect framework. It fixes display corruption that >>>> happens due to insufficient memory bandwidth. >>>> >>>> Changelog: >>>> >>>> v18: - Moved total peak bandwidth from CRTC state to plane state and removed >>>> dummy plane bandwidth state initialization from T186+ plane hub. This >>>> was suggested by Thierry Reding to v17. >>>> >>>> - I haven't done anything about the cursor's plane bandwidth which >>>> doesn't contribute to overlapping bandwidths for a small sized >>>> window because it works okay as-is. >>> >>> Thierry, will you take these patches for 5.14? >>> >> >> The display controller does _NOT_WORK_ properly without bandwidth >> management. > > That's surprising. So either it has never worked before (which I think > I'd know) or something has caused this regression recently. In the > latter case we need to identify what that was and revert (or fix) it. The problem is caused by the support of dynamic memory frequency scaling which does a good job at keeping memory in a low power state during idle time. So display controller may not get enough bandwidth at the start of scanout if it won't request BW beforehand. This problem existed for many years on T124 and now T20/30 are also affected. The DC of T20 is the least tolerant to memory bandwidth troubles. This problem is not critical, but it hurts user experience since high resolution modes may not work at all and display output may become distorted, requiring a DC reset. >> Can we get this patch into 5.14? What is the problem? > > There was not enough time to review and test this, so I didn't feel > comfortable picking it up so close to the -rc6 cut-off. I plan to pick > this up early in the v5.14 release cycle and target v5.15. Thank you for the explanation! It's not uncommon to forget about patches, so the silence worries me. I hoped that both the dynamic freq scaling and display BW support would be merged around the same time, but apparently we got a disconnect here.