From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.andi.de1.cc (mail.andi.de1.cc [178.238.236.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 498C21C68F for ; Sun, 21 Jun 2026 06:51:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.238.236.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782024713; cv=none; b=uDhFLrkJIfu5Tnm94deY4vnhAZdKj46Vw/qK6ZPhpuG4C+tUgJwtLXpZ1ZwMYuGmbz62xB2wcjnw078f9pTmgfQV/R8VNe9n7btuWMx1+VXW2R/g28oQvZjZk5G8W7I0nx5I7uYTHyaYbcHGF4kxfQEJfyXv3NYonRIO41wLU2Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782024713; c=relaxed/simple; bh=4Dej/wp17f868LHkoydOcCmNelmWJDaIzIh1UXnpnhQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OyPOFVYUtx81SuzCuMaKqxTmDi0F3cjNgtYl1pvpS9FgJvOkBVBojFtt3B79IUK4c7nOiGwUhpcyRxP4Hlejy0YZyXgJSdOpFl26QIiRpqFLmG697RbuFL616+W30DHU9ZaHHJPUo4/DS+EryzHDbBpjbyANharSdhHDnyCu1Hg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=kemnade.info; spf=pass smtp.mailfrom=kemnade.info; dkim=pass (2048-bit key) header.d=kemnade.info header.i=@kemnade.info header.b=IDPcOMrU; arc=none smtp.client-ip=178.238.236.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=kemnade.info Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kemnade.info Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kemnade.info header.i=@kemnade.info header.b="IDPcOMrU" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kemnade.info; s=20220719; h=References:In-Reply-To:Subject:Cc:To:From: Reply-To:Content-ID:Content-Description; bh=4P63oFqyxvE5wl0PfmAzNnEHPyZnJVNTOK5k5qm2RuY=; t=1782024712; x=1783234312; b=IDPcOMrUen1JUA+mAuCidAg8HF732hvm60rPLf+HnYtcyxGr414S6Ns8HskZaHXuagBDJibia3/ dcWg4z3Nf7JX9Th+/DOmLGoPLnx2h6+7ipzw1ecOrq9QEZQCnBbar8nuKuwJVET8IO+qMEFbuoUAL WpeOHEGeXT+E7l4ymkhp8hyFJFIS+7zOtvZLs2CuYD7D2UXTRoHB6zMI6OFtNVc9ramUEogWC35xo DsntSfQYnYWbVSkWl7z2Jg0W5uYlIM9Y10MezkJhF/7HHq1KotF/LlqR9dM0X1IPtgh7qFS8Ow/+L Y8n2FG8P5QFNgnTWSbnq3UlFk0dMaQo4Vv1A==; Date: Sun, 21 Jun 2026 08:51:44 +0200 From: Andreas Kemnade To: Tomi Valkeinen Cc: Marek Vasut , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Dave Stevenson Subject: Re: [PATCH v3 08/13] drm/bridge: tc358762: Support VTG Message-ID: <20260621085144.0bb1b96e@kemnade.info> In-Reply-To: <20260513-tc358762-fixes-v3-8-6698b55008b9@ideasonboard.com> References: <20260513-tc358762-fixes-v3-0-6698b55008b9@ideasonboard.com> <20260513-tc358762-fixes-v3-8-6698b55008b9@ideasonboard.com> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.49; aarch64-unknown-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 13 May 2026 16:10:17 +0300 Tomi Valkeinen wrote: > TC358762 can generate the DPI output's timings in two ways, either Video > Timings Generator (VTG) on or off: > - VTG off: Duplicate the timings coming from the DSI. This requires DSI > pulse mode. > - VTG on: Sync frame on DSI VSync Start, but the exact output timings > are defined in TC358762 registers. This can be used with DSI > event/burst mode. > > We are currently using VTG off in the driver. > > I observe that the hsync signal, on my HW setup, is not 100% stable with > VTG off, and it seems to lengthen by a single clock every now and then. > However, it then stabilizes later. To me the DSI input looks solid, but > that is more challenging to measure exactly. So I have not found the > root cause for this. > > Turning VTG on removes that instability. As I dont' see any downsides > with enabling VTG (and it would allow extending the driver to use > event/burst mode in the future), let's always enable the VTG. > > Signed-off-by: Tomi Valkeinen Seems to produce beside of HFP the same values as the variant with hard coded values with the same videomode struct value. So this looks sane. So based on that. Reviewed-by: Andreas Kemnade > --- > drivers/gpu/drm/bridge/tc358762.c | 33 +++++++++++++++++++++++++++++++++ > 1 file changed, 33 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/tc358762.c b/drivers/gpu/drm/bridge/tc358762.c > index c5734c4df440..2d9491e8e582 100644 > --- a/drivers/gpu/drm/bridge/tc358762.c > +++ b/drivers/gpu/drm/bridge/tc358762.c > @@ -19,6 +19,7 @@ > #include > > #include