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 00486C001E0 for ; Wed, 2 Aug 2023 17:36:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233758AbjHBRgh (ORCPT ); Wed, 2 Aug 2023 13:36:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53558 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232724AbjHBRgR (ORCPT ); Wed, 2 Aug 2023 13:36:17 -0400 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0225A1734 for ; Wed, 2 Aug 2023 10:35:11 -0700 (PDT) Received: from [127.0.0.1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id D294886863; Wed, 2 Aug 2023 19:34:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1690997642; bh=5SVSATqR9X+QGwFAD+ody3ENAQjB+Ws+LryjglXK6GQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=jgoIiR97HYJ3Esx98FNE1iCDcOKogg8kvLIls7BRwweGczvkuV52H+MBoDwNl7zT1 nvu0U6TwbvRjfonfTmMKO16zHGlg9V8ne7FdJJCBd8zwnl2rSEVx1qh+d3VYpm9tHD bau87T4OFkWTwEka97rD+8NlPehdgmUK43Ly89N7MHRcuaNkuBNFIs+LpNPV5mGzMq vKPKeET3W8AqHmU1uofgeysmSlcEMdvEl3JP9THe1T7WFDdKjzqsLxrlrq7o/rxIiO rcjYKSaM8xo/xs3UAohyT1omgsT7Hfu5jwvIcIxkj6ycvoPcQNFz2vDI0jy66ID07K 9bxtkgYXFYrjA== Message-ID: Date: Wed, 2 Aug 2023 19:29:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.1 Subject: Re: [PATCH] Revert "drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet" Content-Language: en-US To: Dmitry Baryshkov , Neil Armstrong , Andrzej Hajda , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , David Airlie , Daniel Vetter Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Jagan Teki , Abhinav Kumar , Amit Pundir References: <20230802-revert-do-not-generate-hfp-hbp-hsa-eot-packet-v1-1-f8a20084e15a@linaro.org> <6cd079a4-2f5b-0169-cbaf-b59a72f1b32b@denx.de> <6f96cd11-5055-ab36-74e3-20a45c0d8b40@linaro.org> From: Marek Vasut In-Reply-To: <6f96cd11-5055-ab36-74e3-20a45c0d8b40@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/2/23 15:16, Dmitry Baryshkov wrote: > On 02/08/2023 15:07, Marek Vasut wrote: >> On 8/2/23 10:52, Neil Armstrong wrote: >>> This reverts commit [1] to fix display regression on the Dragonboard >>> 845c >>> (SDM845) devboard. >>> >>> There's a mismatch on the real action of the following flags: >>> - MIPI_DSI_MODE_VIDEO_NO_HSA >>> - MIPI_DSI_MODE_VIDEO_NO_HFP >>> - MIPI_DSI_MODE_VIDEO_NO_HBP >>> which leads to a non-working display on qcom platforms. >>> >>> [1] 8ddce13ae696 ("drm/bridge: lt9611: Do not generate HFP/HBP/HSA >>> and EOT packet") >>> >>> Cc: Marek Vasut >>> Cc: Robert Foss >>> Cc: Jagan Teki >>> Cc: Dmitry Baryshkov >>> Cc: Abhinav Kumar >>> Fixes: 8ddce13ae69 ("drm/bridge: lt9611: Do not generate HFP/HBP/HSA >>> and EOT packet") >>> Reported-by: Amit Pundir >>> Link: >>> https://lore.kernel.org/r/CAMi1Hd0TD=2z_=bcDrht3H_wiLvAFcv8Z-U_r_KUOoeMc6UMjw@mail.gmail.com/ >>> Signed-off-by: Neil Armstrong >> >> This breaks LT9611 operation on i.MX8M Mini/Nano/Plus, so, NAK. >> >> I am currently using this LT9611 with Linux 6.1.y in production and >> this is not acceptable. I also believe the correct fix is on the MSM >> side, not on the LT9611 driver side, since MSM incorrectly implements >> these flags. > > There is no indication that MSM gets these flags wrong. > > Let me quote the DSI 1.3 (I think Abhinav already quoted DSI 1.2). > > Chapter 8.11.1 Transmission Packet Sequences: > > ======== > If a peripheral timing specification for HBP or HFP minimum period is > zero, the corresponding Blanking > Packet may be omitted. If the HBP or HFP maximum period is zero, the > corresponding blanking packet > shall be omitted. > ======== > > Next, chapter 8.11.2 Non-Burst Mode with Sync Pulses > > ====== > Normally, periods shown as HSA (Horizontal Sync Active), HBP (Horizontal > Back Porch) and HFP > (Horizontal Front Porch) are filled by Blanking Packets, with lengths > (including packet overhead) > calculated to match the period specified by the peripheral’s data sheet. > Alternatively, if there is sufficient > time to transition from HS to LP mode and back again, a timed interval > in LP mode may substitute for a > Blanking Packet, thus saving power. During HSA, HBP and HFP periods, the > bus should stay in the LP-11 > state. > ======== > > So, by the spec, sending the HSA / HBP / HFP as blanking packets should > always be accepted (and it is the default mode). Switching to LP-11 > should be permitted if there is a sufficient time to switch to LP-11 and > back. Not sending the packets is only possible if the peripheral > (lt9611) says so. > > We already know that lt9611 breaks if we try switching to LP-11 during > this period. We know that the there is a requirement time for the HSA / > HBP / HFP, because the HDMI monitor needs them. Thus, I can only > emphasise that the behaviour before the offending patch was correct. > > Last, but not least, breaking the in-kernel platform for the out-of-tree > peripheral doesn't sound correct. Except the MX8M support is all in-tree now, so please drop the "out-of-tree" argument. That I am using 6.1.y on those platforms in production makes no difference. > I can only propose the following steps: > > 1. land the revert to unbreak existing users. That's just trading breaking one set of users for breaking another set of users. > 2. Marek to propose and land the DT bindings & driver change that will > enable the workaround for the particular platform (i.MX8m). Since I have no access to the QCOM hardware or datasheet, can you have a look at the NXP.com MX8M M/N/P datasheets (those are available) and compare their behavior with the QCOM behavior ? I assume you do have the QCOM datasheets available.