Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v18 0/2] Add memory bandwidth management to NVIDIA Tegra
 DRM driver
To:     Thierry Reding <thierry.reding@gmail.com>
Cc:     linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        Matt Merhar <mattmerhar@protonmail.com>,
        Jonathan Hunter <jonathanh@nvidia.com>,
        Peter Geis <pgwipeout@gmail.com>,
        Nicolas Chauvet <kwizart@gmail.com>,
        =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= <mirq-linux@rere.qmqm.pl>
References: <20210601042108.1942-1-digetx@gmail.com>
 <8accfe1e-fc48-21ca-f7c6-bd2d60162e6d@gmail.com>
 <50912a57-aa43-58b0-02d2-6928578d6286@gmail.com>
 <YNBxiFXMS9rfT93c@orome.fritz.box>
From:   Dmitry Osipenko <digetx@gmail.com>
Message-ID: <af058fc3-8696-a8f9-b52d-8e1b2ee760c3@gmail.com>
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: <YNBxiFXMS9rfT93c@orome.fritz.box>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

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.