Received-SPF: pass (google.com: domain of linux-kernel+bounces-191477-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Mon, 27 May 2024 19:13:59 -0300
From: Val Packett <val@packett.cool>
Subject: Re: [PATCH v2 1/2] drm/rockchip: vop: clear DMA stop bit upon vblank
 on RK3066
To: Heiko =?iso-8859-1?q?St=FCbner?= <heiko@sntech.de>
Cc: stable@vger.kernel.org, Sandy Huang <hjc@rock-chips.com>, Andy Yan
	<andy.yan@rock-chips.com>, Maarten Lankhorst
	<maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>,
	Daniel Vetter <daniel@ffwll.ch>, dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org,
	linux-kernel@vger.kernel.org
Message-Id: <BF06ES.TD22854ZPLB92@packett.cool>
In-Reply-To: <1817371.3VsfAaAtOV@diego>
References: <2024051930-canteen-produce-1ba7@gregkh>
	<20240527071736.21784-1-val@packett.cool> <1817371.3VsfAaAtOV@diego>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable


On Mon, May 27 2024 at 22:43:18 +02:00:00, Heiko St=FCbner=20
<heiko@sntech.de> wrote:
> Hi Val,
>=20
> Am Montag, 27. Mai 2024, 09:16:33 CEST schrieb Val Packett:
>>  On the RK3066, there is a bit that must be cleared, otherwise
>>  the picture does not show up
>> on the display (at least for RGB).
>>=20
>>  Fixes: f4a6de8 ("drm: rockchip: vop: add rk3066 vop definitions")
>>  Cc: stable@vger.kernel.org
>>  Signed-off-by: Val Packett <val@packett.cool>
>>  ---
>>  v2: doing this on vblank makes more sense; added fixes tag
>=20
> can you give a rationale for this please?
>=20
> I.e. does this dma-stop bit need to be set on each vblank that happens
> to push this frame to the display somehow?


The only things I'm 100% sure about:

- that bit is called dma_stop in the Android kernel's header;
- without ever setting that bit to 1, it was getting set to 1 by the=20
chip itself, as logging the register on flush was showing a 1 in that=20
position (it was the only set bit - I guess others aren't readable=20
after cfg_done?);
- without clearing it "between" frames, the whole screen is always=20
filled with noise, the picture is not visible.

The rest is at least a bit (ha) speculative:

As I understand from what the name implies, the hardware sets it to=20
indicate that it has scanned out the frame and is waiting for=20
acknowledgment (clearing) to be able to scan out the next frame. I=20
guess it's a redundant synchronization mechanism that was removed in=20
later iterations of the VOP hardware block.

I've been trying to see if moving where I clear the bit affects the=20
sort-of-tearing-but-vertical glitches that sometimes happen, especially=20
early on after the system has just booted, but that seems to be=20
completely unrelated pixel clock craziness (the Android kernel runs the=20
screen at 66 fps, interestingly).

I'm fairly confident that both places are "correct". The reason I'm=20
more on the side of vblank now is that it made logical sense to me when=20
I thought about it more: acknowledging that the frame has been scanned=20
out is a reaction to the frame having been scanned out. It's a=20
consequence of *that* that the acknowledgment is required for the next=20
frame to be drawn.

Unless we can get the opinion of someone closely familiar with this=20
decade-old hardware, we only have this reasoning to go off of :)

~val
>=20