From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC3C52F3614 for ; Thu, 2 Jul 2026 10:48:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782989316; cv=none; b=NmdScaRhTPWW5OSS0lpxYloJIea5cq23oKFS/+VqFjknjCA/iQiKlI00PSACmz+uXDRrReAz6I/Uau3Os+XT4BKhRzJmbMOQu+NZ8oL7WxXz6zWadbJqSVyXHiPkp11gPBoao605iTjyT94Lvj3exenQRaXISkiilF1xVRmfDfU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782989316; c=relaxed/simple; bh=CP90g/Sd8SpBamQMkPP7wI+cAPxvLKgKoJOnW93/UXA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PEXHgoVKSb44RWaBgst7CyMxrYO3FDgSTBzA4XH1+M25enel+R3U6BbnzOF89+ga0R7Psk/E+QRGYr0pWl+eiAWCEjM0+8G83i55nveqS6htplqTiAlbWcbMLidiop8LVmBBS2rb82+lIbBAiR2KX8FfvA8FoXriug/eu2y91qU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dcaqOliq; arc=none smtp.client-ip=209.85.210.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dcaqOliq" Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-8478cc93299so1267656b3a.2 for ; Thu, 02 Jul 2026 03:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782989315; x=1783594115; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=8HePeeifvB/opdYPmqi87Awn5dRCasskHjfVg9hPOIo=; b=dcaqOliqF6MY8EexIiXb648nQZwaNGFs3qvOJw4YX++pmySRFPvLwFEPUK/Vfitou8 rsGc2q//f1THizj95QuNICYojijxjy8+74c6FZDw4nWX0uUoRnTrOup8LqIwSNRuvIgt Wt1DTGnaUV1hfzx1gu9kVvxEusUS4Vaf7nnz8ffpwZsDhNNlCtXCL+oA33n6zuv7BnGp 4JqP+DY7D2CwpguZ8J7Kx6FLPQD5M1ypuTHFOL2YTS8WzU5+f6/X+U3BE1Z5b8NrmVsn 8OE+7OZNHQBcgqJMa8FQMDgYWTm5Vq0NKDUebD+xc3kWAIZ1MOTxVbXf3HO7/nGNAzPw R41A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782989315; x=1783594115; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=8HePeeifvB/opdYPmqi87Awn5dRCasskHjfVg9hPOIo=; b=OwPWjFP8fKW2dcOn9SdsNWyf97GO3QL3jz67Lz1GvRKNTaHjFijtqeWFAcgtyl9NkH wx8q1xPbfkUtDHaWlEOgyTxWbzhd12QhgRG/fYnyPzF2ShDduJmat3lZscXghS9xfwsu Y3xsvYpUyvxvDf7M8vcs5rdUyDg72e+RyneG/6HmeBGN82oH/U46axX81OwL9U6q8vxR 7RqmfI7OnEtVr9bAL74hfo+0tbuOj7VbYNSmbmUCWh7WMpEShWwavZlurLTnJI+7RgdY ZFwKci4w6L1zPWp9rBqsVApufu/3eHKSPdus4Ct/pvyGViLg6yiAeTmEKaLldae4RL4e 1F0A== X-Forwarded-Encrypted: i=1; AFNElJ/9Haw3TfU2gRCpdryuUpKbjJGTAic7HelMNCnhW3unbVdFwX5RhzarTVILGuGwu6tm3BXBYyrnfXQbTdU=@vger.kernel.org X-Gm-Message-State: AOJu0Yzt25b/5NuOuSvIOAqIluGTdKRHw3vDYTppcUir7Ql7NF7SwtiH PwLsH+hmHc8t20wm/z+w7NtsX4WC7Fwz53lYGIQ98iL8E2zMLyvQdnXZ X-Gm-Gg: AfdE7cn5xFHFkJpZs2i9TCcYsU8Ax8IiT3sGtJCacVPHKWAVP3N+HhK50YS8fydIo3Y AgQ66wUfzli2VkpLuUWEoKp7iIpsOYsQUXWfgR3yglOdhLutQ74FcdjsEjjqnzM9CzoRICeqqlG nY8+D9CKqhIr4MbBeiYkK+HAggAwq/PW1W3rfsLODc083vamlCzcWPuNLrU0YYoPJQCarTaTAEO /D1OU9G6XgRrnhP22MvbMYB5d1QllfUv0ji/kM/SdULnSfuTAB7wvKgPbnSDntk5SuwaEQvX/Mz 2FQiaBW3WD2LxkORKlcbk83gy6TuJq16dowTSasZZE7/RnaatpUi/wo7D5esuGYVcbVd4PPyhCv kBPA1HgXZwPvtFSFIGmg7CjUki1zbGi8UVtZsskLYJ63SPY/J8166UFVEdeZc3tReYpliAJ+fcA JlUh9eY7w4YHI1cEQp0zOngo7GfoBcLn2muW92ZtYkgFe+od0gkdtJOkStumv/54EOxnw+sqWN6 DOEaYxXydsuh2qlLSaxInWkHYjLprxN+hzIVU8QqvQ= X-Received: by 2002:a05:6a20:e20f:b0:3b4:669c:ee32 with SMTP id adf61e73a8af0-3bfed3b26edmr7042853637.37.1782989314653; Thu, 02 Jul 2026 03:48:34 -0700 (PDT) Received: from leonardoc-nb (201-68-197-145.dsl.telesp.net.br. [201.68.197.145]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-30f116065c5sm5936815eec.11.2026.07.02.03.48.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jul 2026 03:48:34 -0700 (PDT) From: Leonardo Costa To: louis.chauvet@bootlin.com Cc: airlied@gmail.com, bparrot@ti.com, conor+dt@kernel.org, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, jsarha@ti.com, jyri.sarha@iki.fi, kristo@kernel.org, krzk+dt@kernel.org, lee@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, maarten.lankhorst@linux.intel.com, mripard@kernel.org, nm@ti.com, robh@kernel.org, sam@ravnborg.org, simona@ffwll.ch, stable@vger.kernel.org, thomas.petazzoni@bootlin.com, tomi.valkeinen@ideasonboard.com, tomi.valkeinen@ti.com, tzimmermann@suse.de, vigneshr@ti.com Subject: Re: [PATCH 4/4] drm/tidss: Fix sampling edge configuration Date: Thu, 2 Jul 2026 07:48:01 -0300 Message-ID: <20260702104817.1219078-1-leoreis.costa@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250730-fix-edge-handling-v1-4-1bdfb3fe7922@bootlin.com> References: <20250730-fix-edge-handling-v1-4-1bdfb3fe7922@bootlin.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hello, We tested this patch and it introduces a regression on our panel. On our board, a Toshiba TC358768 DPI-to-DSI bridge is connected to the parallel RGB output. The bridge requires data to be driven on the negative edge, and this is also reflected by the `ipc` variable in `dispc_vp_enable()`, which is set to `1`. With this patch applied, however, data is driven on the positive edge instead. According to SPRUIV7C, both `MAIN_CTRL_MMR_CFG0_DPI0_CLK_CTRL[8]` and `DSS_VP1_POL_FREQ[14] IPC` should be programmed consistently. However, if we follow the actual bit descriptions, and ignore the sentence saying that the two programmed values should be the same, the data is driven on the requested edge. >From SPRUIV7C (https://www.ti.com/lit/ug/spruiv7b/spruiv7c.pdf): MAIN_CTRL_MMR_CFG0_DPI0_CLK_CTRL[8] (DPI0_CLK_CTRL_DATA_CLK_INVDIS): Clock edge select for DPI0 data outputs Note that this value should be the same as the programmed value of DSS_POL_FREQ[14] IPC. Reset Source: mod_por_rst_n 0 DATA and DE are driven on the falling edge of clk 1 DATA and DE are driven on the rising edge of clk DSS_VP1_POL_FREQ[14] (IPC) Invert pixel clock To set data to pixel clock relationship, CTRL_MMR_DPI0_CLK_CTRL[8] DPI0_CLK_CTRL_DATA_CLK_INVDIS setting should be the same as the [14] IPC setting. 0 Data is driven on the LCD data lines on the rising-edge of the pixel clock 1 Data is driven on the LCD data lines on the falling-edge of the pixel clock So, the proposed fix to this patch is: ```diff - regmap_update_bits(dispc->clk_ctrl, 0, 0x100, ipc ? 0x100 : 0x000); + regmap_update_bits(dispc->clk_ctrl, 0, 0x100, ipc ? 0x000 : 0x100); ``` Reverting the patch also makes the Toshiba bridge work correctly again. However, we can confirm that the patch is needed, otherwise only the positive-edge case (our case) works correctly. In other words, the two registers need to match semantically, not numerically.