From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) (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 3729847CC70 for ; Thu, 2 Jul 2026 13:00:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782997235; cv=none; b=QNNvkkV+3cl/YBVwXV5DjF9T1Hn7IS4/7UJekIw97bxGgke00FznwkE8R4tejOlqOt4ScEwrFeN88JBk5VwufJmmzCq/mcJoFF9aTJJDaaogS/8320ednrPINJLgyjdY1w643vtt32NJ7QhWmLrMwvWABHMGu/OzyXZLjTxudAQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782997235; c=relaxed/simple; bh=S2US6hsMSbsmh9aIzwrsWN9LZI8PysP4A7CuAXv1jaE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b30WcnXY4UfPJltlQ0z7rl3+lFhnBoH6BdI/umkpE/IT1KyGiDl0nWq8zz2vRJyDQxKqn8RXd598v1e2/ZLauHF70VxaLlSHzw1byfNjwlGQvA3dR1i3jdIPf14YiwlgLmqSQV0U0cI9D6GT+n5CYHQmMqeN+6ndWHBZjiuMqlM= 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=lV3qz+hW; arc=none smtp.client-ip=209.85.215.178 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="lV3qz+hW" Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-c9c80265bd7so853399a12.1 for ; Thu, 02 Jul 2026 06:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782997233; x=1783602033; 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=1E44Sgh/fBb3+oxPV/igqOovjJZCJr4T8Ggc55Eveo0=; b=lV3qz+hWgGiP/7Ubojgx2Kw4DAxPXd0OQWAKVGDuEC67aDe0V+INUXctqL7vdjrPAW iXKN2yj5aU3IYgcLwiP5m5yx2ylvFeFRYDcA1cRO4gKQ3/kVbug0GBMbdDVvz1JtHo15 ogAIEoW4oR3+xRPC8IweWdfQXsFxtVDWWxO/kDHop5QYOFNgWPkrulXJrTuCziENVK3y rWobDHGvNMzzTHqyVRhHK/xAIFcffwrK+OlhUfejaBj+e+0z1I4UW1d+bwcmSEeyMe+x VenTyYp9OZocdCeDsfu6v+ZkORy+EGVvh0Whhbz6zOwwT06z5ekvH8VTKPx6/SMbt/DD vjtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782997233; x=1783602033; 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=1E44Sgh/fBb3+oxPV/igqOovjJZCJr4T8Ggc55Eveo0=; b=MWC7PTpPpVPGEwWwCyLF1Njpae5hT6pcr3DcNPnQlEsnx9e/JpMlTT3Hzjh5Dm3kpj SBSnPvdh71zZ27CQukyNoaFPwhIIU5Q6r+NNFtri6fsgXbASprMC7viwOk0JCQrIvgLt zIoa57xIXgxb/cRWo3NAmE/aD3ful70CsKK9EcZr4ToDOBZ7QHw22qPVH3/dVl7+IWrZ kfckPigIbSLigUdujTOObe6EmXHvYkWC17fzopwkdqQ6UFPAI2nG2z6/5QKevdNMDRW8 GoURPcpJMJRnZvX8ll0qeduTDyxxF8msIr63wNm8XDKEo32jTPrZbcewyQBuj1yBbRnw AaCQ== X-Forwarded-Encrypted: i=1; AFNElJ/icLvQVb2BDtnDn5p17KjU3sVLW8+ci0ru6NAcbKReH/Uod4rG1kSmODC6fHJ+UAqFa81oQ1FubayF5X4=@vger.kernel.org X-Gm-Message-State: AOJu0YxJ8IZxMBy5USkQZsuViOJO/WoLYgDkpEkF4SYSRO35NuqaSXUG 2+tV4D0dzF6VPUwToX6pj5lHWxXeVVaDS4KbP87GAjHjhvyseHRJwcdI X-Gm-Gg: AfdE7cmmJs6FinIxCUs4Gy0Bi3ZIivzA8Y/H+F6WZ/yafWrlLTFWNHfth+ATJilWo/S HbEthpNSjheTJqJt6A3C2fWYi93tnrxYzcMn3NL5DsU765h5gV57hD/IdqZlOZ1K/T/biiYy9dl RMxkC4VhiYoTnoIELE7VLtstdvo1a+yhs0WxPJdyjO5QJ6+gUK5Ssf0ACm/XKivjk4YguLS2RfL 53B3dgm6pUL498Pc2NlGGLUaJC2agFOlpd7csZgNFfm13BPAMS1jWqWU/4tFTkP60CPAOpudGpu rDb7gnZn1eJNYMht2EPC+vTok2Ld46aKJoLKOljOP1cluE+LJlNNJIM/Ag6oyMO8tjb77HmGEA8 Q4d8hxW1IecIS6c5uVY17G3L7KFhxw/S5Spn9sa7uJdn44vuflWriDcMIFQiYO7ycUCt4Ov5hl1 5NueqchJHn7HZzUEoJ57W6Ql8X0yjD74IwZGtgvllea3dNXMZsPVxPtYF2Je0XekoA2jNlZk/6W TaTDTO4jx0Wn0sdDpxWhuUnZObNUMKXOO+RKBK8n+w= X-Received: by 2002:a05:6a20:258f:b0:3bf:8b8d:3151 with SMTP id adf61e73a8af0-3bfed3efa54mr7187075637.44.1782997233311; Thu, 02 Jul 2026 06:00:33 -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-30f116065c5sm7279613eec.11.2026.07.02.06.00.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jul 2026 06:00:32 -0700 (PDT) From: Leonardo Costa To: s-jain1@ti.com Cc: airlied@gmail.com, aradhya.bhatia@linux.dev, conor+dt@kernel.org, devarsht@ti.com, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, h-shenoy@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, louis.chauvet@bootlin.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, nm@ti.com, praneeth@ti.com, robh@kernel.org, simona@ffwll.ch, tomi.valkeinen@ideasonboard.com, tzimmermann@suse.de, vigneshr@ti.com, leonardo.costa@toradex.com Subject: Re: [RESEND PATCH v2 5/5] drm/tidss: Fix sampling edge configuration Date: Thu, 2 Jul 2026 09:59:43 -0300 Message-ID: <20260702130010.1238089-1-leoreis.costa@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251106141227.899054-6-s-jain1@ti.com> References: <20251106141227.899054-6-s-jain1@ti.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. Please ignore the previous email I sent: https://lore.kernel.org/all/20260702104817.1219078-1-leoreis.costa@gmail.com/ I hadn't seen this more recent thread at the time.