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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85FACC001DF for ; Wed, 16 Aug 2023 08:15:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242804AbjHPIPV (ORCPT ); Wed, 16 Aug 2023 04:15:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237364AbjHPIOw (ORCPT ); Wed, 16 Aug 2023 04:14:52 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0BC794 for ; Wed, 16 Aug 2023 01:14:50 -0700 (PDT) Received: from [192.168.88.20] (91-154-35-171.elisa-laajakaista.fi [91.154.35.171]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id CE811B2A; Wed, 16 Aug 2023 10:13:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1692173615; bh=ElXL6fYxDLsP/9sUEgVHcxzYyUCsen+i+kQs9f4MzQE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=KyppgEgRNn/0vwjZ3IAxWZOVAc4lrgoLqpIsiRNgyw8h4S0hjp4zFj2mLXM8dhF/s LdRtGvZdIfG/iZuy6mdPsGjS38TBDICA5Aav1Lp1+I+4cf+aFSmgVznn2x8mHiPYoZ EZS1r2BOdwg+cnia5cEFatf691v4ZAnQViqE6G0I= Message-ID: <5ffb773d-5a3e-cb88-db3b-522423f2b834@ideasonboard.com> Date: Wed, 16 Aug 2023 11:14:43 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH 02/11] drm/bridge: tc358768: Fix bit updates To: Maxim Schwalm , =?UTF-8?Q?P=c3=a9ter_Ujfalusi?= , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , David Airlie , Daniel Vetter , Francesco Dolcini Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Aradhya Bhatia , Dmitry Osipenko , Thierry Reding , Svyatoslav Ryhel References: <20230804-tc358768-v1-0-1afd44b7826b@ideasonboard.com> <20230804-tc358768-v1-2-1afd44b7826b@ideasonboard.com> <241937b4-1ef8-abad-7c4a-b26bfab86a3a@ideasonboard.com> <92396880-edb5-d8e0-4fcf-54aeaa2b40d7@gmail.com> <52151daa-90af-a6c0-9b03-f69081321253@ideasonboard.com> Content-Language: en-US From: Tomi Valkeinen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/08/2023 20:21, Maxim Schwalm wrote: > On 14.08.23 08:34, Tomi Valkeinen wrote: >> On 13/08/2023 03:23, Maxim Schwalm wrote: >>> Hi, >>> >>> On 11.08.23 19:02, Tomi Valkeinen wrote: >>>> On 11/08/2023 19:23, Péter Ujfalusi wrote: >>>>> >>>>> >>>>> On 04/08/2023 13:44, Tomi Valkeinen wrote: >>>>>> The driver has a few places where it does: >>>>>> >>>>>> if (thing_is_enabled_in_config) >>>>>> update_thing_bit_in_hw() >>>>>> >>>>>> This means that if the thing is _not_ enabled, the bit never gets >>>>>> cleared. This affects the h/vsyncs and continuous DSI clock bits. >>>>> >>>>> I guess the idea was to keep the reset value unless it needs to be flipped. >>>>> >>>>>> >>>>>> Fix the driver to always update the bit. >>>>>> >>>>>> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") >>>>>> Signed-off-by: Tomi Valkeinen >>>>>> --- >>>>>> drivers/gpu/drm/bridge/tc358768.c | 13 +++++++------ >>>>>> 1 file changed, 7 insertions(+), 6 deletions(-) >>>>>> >>>>>> diff --git a/drivers/gpu/drm/bridge/tc358768.c b/drivers/gpu/drm/bridge/tc358768.c >>>>>> index bc97a837955b..b668f77673c3 100644 >>>>>> --- a/drivers/gpu/drm/bridge/tc358768.c >>>>>> +++ b/drivers/gpu/drm/bridge/tc358768.c >>>>>> @@ -794,8 +794,8 @@ static void tc358768_bridge_pre_enable(struct drm_bridge *bridge) >>>>>> val |= BIT(i + 1); >>>>>> tc358768_write(priv, TC358768_HSTXVREGEN, val); >>>>>> >>>>>> - if (!(mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)) >>>>>> - tc358768_write(priv, TC358768_TXOPTIONCNTRL, 0x1); >>>>>> + tc358768_write(priv, TC358768_TXOPTIONCNTRL, >>>>>> + (mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) ? 0 : BIT(0)); >>>>>> >>>>>> /* TXTAGOCNT[26:16] RXTASURECNT[10:0] */ >>>>>> val = tc358768_to_ns((lptxcnt + 1) * dsibclk_nsk * 4); >>>>>> @@ -861,11 +861,12 @@ static void tc358768_bridge_pre_enable(struct drm_bridge *bridge) >>>>>> tc358768_write(priv, TC358768_DSI_HACT, hact); >>>>>> >>>>>> /* VSYNC polarity */ >>>>>> - if (!(mode->flags & DRM_MODE_FLAG_NVSYNC)) >>>>>> - tc358768_update_bits(priv, TC358768_CONFCTL, BIT(5), BIT(5)); >>>>>> + tc358768_update_bits(priv, TC358768_CONFCTL, BIT(5), >>>>>> + (mode->flags & DRM_MODE_FLAG_PVSYNC) ? BIT(5) : 0); >>>>> >>>>> Was this the reverse before and should be: >>>>> (mode->flags & DRM_MODE_FLAG_PVSYNC) ? 0 : BIT(5) >>>> >>>> Bit 5 is 1 for active high vsync polarity. The test was previously >>>> !nvsync, i.e. the same as pvsync. >>> >>> this statement doesn't seem to be true, since this change causes a >>> regression on the Asus TF700T. Apparently, !nvsync is true and pvsync is >>> false in the present case. >> >> panasonic_vvx10f004b00_mode in panel_simple.c doesn't seem to have mode >> flags set. I would say that means the panel doesn't care about the sync >> polarities (which obviously is not the case), but maybe there's an >> assumption that if sync polarities are not set, the default is... >> positive? But I can't find any mention about this. >> >> Does it work for you if you set the polarities in >> panasonic_vvx10f004b00_mode? > > The panel seems to work with either negative or positive H-/Vsync in > conjunction with the attached patch from Thierry. Currently, the display > controller is unconditionally programmed for positive H-/Vsync though. > What should be done in this case? > > BTW, the vendor kernel configures the display controller as well as the > bridge for negative H-/Vsync. Ah, of course, I wasn't thinking. It's a DSI panel (obviously...), so it doesn't have sync polarities and as such it doesn't really make sense to define them in the panel-simple.c. But we still need an agreed sync polarity between the tegra and the tc358768, as that is a parallel video bus. And that polarity is not defined anywhere, as it is expected to come from the panel. Maybe tc358768 should have a mode-fixup, where it sets the polarities if they are not defined? I'll have to look at this a bit more. Tomi