Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp3666814ybi; Tue, 18 Jun 2019 04:43:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqwBj/VKXAPO+ywE0gRYSOVuE1XeFoklk0bUvrhfHruTmrc3mhQHwD6ALCfpA8TkRAkpO2Sk X-Received: by 2002:a62:e801:: with SMTP id c1mr96042468pfi.41.1560858237987; Tue, 18 Jun 2019 04:43:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560858237; cv=none; d=google.com; s=arc-20160816; b=fsUUxJ9R//VFennxIXA43AvbNBbrxspNAxIC/bOw/qW6xVjYNN5DyzyiM6mb+RSKMa Ftl2ABdnPYXebzjAhjAZmwjZlNyfjk8ntwJONzK4ZTZB24k4X//KQgPxOkPxawKk8vPr hVlIU4hAVowqHq5G6qb7P/ITQkAkGB1VhxvXRCYM2SMf2TeQpi88kpONW530RDIMZR51 iEqPAvjvY2se1Qk3WNnHLP955jCv0nG7T43O//sX4C7is2pDL0uuO8Lswa5mf/ypybHx ja/QMy8KxCHKFjFfJZKXzPP34AzVfeXdEiAXAw1/GhOariNdGsxrObDhkgBwTL6Y5NFc g09A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=5qGqJdg+wsfVYT2KxKKLL7YQpxY66gkI5/E04j3clEI=; b=XOkP1AulJd973qJkDStmV0gYpzfDpbLyY+RyzmP99lCXF7av2+iSBTYnw3pdr4p2j3 /oTKyAtEqma3O+KsRc/owNlaIQqIazoku7Tr3rI6U1kbxi/agLLbyuIZMh13qOSfg55j BEgz+800KTNfDmltZqNUQH0oQsnYEdE+lQDn1hW2VljVy9/PXxC+c4nDWlsN122J8jhr o4BA/Ty3wKGxBsu5X9tqjlFKdBrb3UjqygOpitpPfgf8YgU3GqD4UZcLkWwtowOp8gGY Ery7HITSKknU9oYJUF6SqQQmXTVzwt3gwecIL+Q4D74Fv5HCjhskAiCun59OvlPvTBRv u30w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r5si2023480pji.43.2019.06.18.04.43.41; Tue, 18 Jun 2019 04:43:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729732AbfFRLnc (ORCPT + 99 others); Tue, 18 Jun 2019 07:43:32 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:44958 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729110AbfFRLnc (ORCPT ); Tue, 18 Jun 2019 07:43:32 -0400 Received: by mail-ed1-f67.google.com with SMTP id k8so21240297edr.11 for ; Tue, 18 Jun 2019 04:43:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5qGqJdg+wsfVYT2KxKKLL7YQpxY66gkI5/E04j3clEI=; b=DYl5mw9eiZ3157KlC17QqhDDEW4CRsKV+21qV0LHb2uUq+x32lP7vz7lWwIm3UCnpR sN+zh1cYqxkapAUYiHyV6jqjOFYtCZ6xwwS3jK/gHz1p3Fr0qdfOPfvF23DkUW82svoT sh7pN4/XnDsc5l7JGE9RpL3GxmZhwAXwxgCysoG7qzCKBZF7/pka1Hu5MRfCLMZnRo7s M1rFo+TWisawemX+hqmWDd0+1rw4pfKz0pRKLalN7dHV/euTrNb0n/eYC5VOhp+dkJhN pfEnEbcldVPkUzC3VfN8IVKLjhzDvHNbeqvIeoX6QeajwLgF4b9BGP7LcFT34S1RcRze MhSw== X-Gm-Message-State: APjAAAXMvaGxciyZFoADgWSOQ7gAMVMbKLp/GrHI+p9ByEl34BeDiCbX /AwdhllS8wGs1vMWgQZZK3WIsTvNA3g= X-Received: by 2002:aa7:cf90:: with SMTP id z16mr12262994edx.228.1560858208490; Tue, 18 Jun 2019 04:43:28 -0700 (PDT) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com. [209.85.128.45]) by smtp.gmail.com with ESMTPSA id x10sm4643731edd.73.2019.06.18.04.43.27 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jun 2019 04:43:28 -0700 (PDT) Received: by mail-wm1-f45.google.com with SMTP id u8so2905249wmm.1 for ; Tue, 18 Jun 2019 04:43:27 -0700 (PDT) X-Received: by 2002:a1c:a186:: with SMTP id k128mr3320549wme.125.1560858207199; Tue, 18 Jun 2019 04:43:27 -0700 (PDT) MIME-Version: 1.0 References: <20190520090318.27570-1-jagan@amarulasolutions.com> <20190520090318.27570-2-jagan@amarulasolutions.com> <20190523203407.o5obg2wtj7wwau6a@flea> <20190529145450.qnitxpmpr2a2xemk@flea> <20190604100011.cqkhpwmmmwh3vr3y@flea> <20190613125630.2b2fvvtvrcjlx4lv@flea> <20190614144526.lorg3saj4wjopgne@flea> In-Reply-To: From: Chen-Yu Tsai Date: Tue, 18 Jun 2019 19:43:14 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [linux-sunxi] Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits To: Jagan Teki Cc: Maxime Ripard , David Airlie , Daniel Vetter , dri-devel , linux-arm-kernel , linux-kernel , Bhushan Shah , Vasily Khoruzhick , =?UTF-8?B?5Z2a5a6a5YmN6KGM?= , Michael Trimarchi , linux-amarula , linux-sunxi Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki wrote: > > On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard wrote: > > > > On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote: > > > On Thu, Jun 13, 2019 at 6:56 PM Maxime Ripard wrote: > > > > > > > > On Wed, Jun 05, 2019 at 01:17:11PM +0530, Jagan Teki wrote: > > > > > On Tue, Jun 4, 2019 at 3:30 PM Maxime Ripard wrote: > > > > > > > > > > > > On Wed, May 29, 2019 at 11:44:56PM +0530, Jagan Teki wrote: > > > > > > > On Wed, May 29, 2019 at 8:24 PM Maxime Ripard wrote: > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:48:51PM +0530, Jagan Teki wrote: > > > > > > > > > On Fri, May 24, 2019 at 2:04 AM Maxime Ripard wrote: > > > > > > > > > > > > > > > > > > > > On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki wrote: > > > > > > > > > > > According to "DRM kernel-internal display mode structure" in > > > > > > > > > > > include/drm/drm_modes.h the current driver is trying to include > > > > > > > > > > > sync timings along with front porch value while checking and > > > > > > > > > > > computing drq set bits in non-burst mode. > > > > > > > > > > > > > > > > > > > > > > mode->hsync_end - mode->hdisplay => horizontal front porch + sync > > > > > > > > > > > > > > > > > > > > > > With adding additional sync timings, the dsi controller leads to > > > > > > > > > > > wrong drq set bits for "bananapi,s070wv20-ct16" panel which indeed > > > > > > > > > > > trigger panel flip_done timed out as: > > > > > > > > > > > > > > > > > > > > > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > > > > > > > > > [CRTC:46:crtc-0] vblank wait timed out > > > > > > > > > > > Modules linked in: > > > > > > > > > > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > > > > > > > > > > > Hardware name: Allwinner sun8i Family > > > > > > > > > > > Workqueue: events deferred_probe_work_func > > > > > > > > > > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > > > > > > > > > > [] (show_stack) from [] (dump_stack+0x84/0x98) > > > > > > > > > > > [] (dump_stack) from [] (__warn+0xfc/0x114) > > > > > > > > > > > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > > > > > > > > > > > [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > > > > > > > > > > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > > > > > > > > > > [] (drm_atomic_helper_commit_tail_rpm) from [] (commit_tail+0x40/0x6c) > > > > > > > > > > > [] (commit_tail) from [] (drm_atomic_helper_commit+0xbc/0x128) > > > > > > > > > > > [] (drm_atomic_helper_commit) from [] (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > > > > > > > > > > [] (restore_fbdev_mode_atomic) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > > > > > > > > > > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fb_helper_set_par+0x30/0x54) > > > > > > > > > > > [] (drm_fb_helper_set_par) from [] (fbcon_init+0x560/0x5ac) > > > > > > > > > > > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > > > > > > > > > > > [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) > > > > > > > > > > > [] (do_bind_con_driver) from [] (do_take_over_console+0x13c/0x1c4) > > > > > > > > > > > [] (do_take_over_console) from [] (do_fbcon_takeover+0x74/0xcc) > > > > > > > > > > > [] (do_fbcon_takeover) from [] (notifier_call_chain+0x44/0x84) > > > > > > > > > > > [] (notifier_call_chain) from [] (__blocking_notifier_call_chain+0x48/0x60) > > > > > > > > > > > [] (__blocking_notifier_call_chain) from [] (blocking_notifier_call_chain+0x18/0x20) > > > > > > > > > > > [] (blocking_notifier_call_chain) from [] (register_framebuffer+0x1e0/0x2f8) > > > > > > > > > > > [] (register_framebuffer) from [] (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > > > > > > > > > > > [] (__drm_fb_helper_initial_config_and_unlock) from [] (drm_fbdev_client_hotplug+0xe8/0x1b8) > > > > > > > > > > > [] (drm_fbdev_client_hotplug) from [] (drm_fbdev_generic_setup+0x88/0x118) > > > > > > > > > > > [] (drm_fbdev_generic_setup) from [] (sun4i_drv_bind+0x128/0x160) > > > > > > > > > > > [] (sun4i_drv_bind) from [] (try_to_bring_up_master+0x164/0x1a0) > > > > > > > > > > > [] (try_to_bring_up_master) from [] (__component_add+0x94/0x140) > > > > > > > > > > > [] (__component_add) from [] (sun6i_dsi_probe+0x144/0x234) > > > > > > > > > > > [] (sun6i_dsi_probe) from [] (platform_drv_probe+0x48/0x9c) > > > > > > > > > > > [] (platform_drv_probe) from [] (really_probe+0x1dc/0x2c8) > > > > > > > > > > > [] (really_probe) from [] (driver_probe_device+0x60/0x160) > > > > > > > > > > > [] (driver_probe_device) from [] (bus_for_each_drv+0x74/0xb8) > > > > > > > > > > > [] (bus_for_each_drv) from [] (__device_attach+0xd0/0x13c) > > > > > > > > > > > [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) > > > > > > > > > > > [] (bus_probe_device) from [] (deferred_probe_work_func+0x64/0x90) > > > > > > > > > > > [] (deferred_probe_work_func) from [] (process_one_work+0x204/0x420) > > > > > > > > > > > [] (process_one_work) from [] (worker_thread+0x274/0x5a0) > > > > > > > > > > > [] (worker_thread) from [] (kthread+0x11c/0x14c) > > > > > > > > > > > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > > > > > > > > > > > Exception stack(0xde539fb0 to 0xde539ff8) > > > > > > > > > > > 9fa0: 00000000 00000000 00000000 00000000 > > > > > > > > > > > 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > > > > > > > > > > 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 > > > > > > > > > > > ---[ end trace b57eb1e5c64c6b8b ]--- > > > > > > > > > > > random: fast init done > > > > > > > > > > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] flip_done timed out > > > > > > > > > > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] flip_done timed out > > > > > > > > > > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] flip_done timed out > > > > > > > > > > > > > > > > > > > > > > But according to Allwinner A33, A64 BSP code [1] [3] the TCON DRQ for > > > > > > > > > > > non-burst DSI mode can be computed based on "horizontal front porch" > > > > > > > > > > > value only (no sync timings included). > > > > > > > > > > > > > > > > > > > > > > Detailed evidence for drq set bits based on A33 BSP [1] [2] > > > > > > > > > > > > > > > > > > > > > > => panel->lcd_ht - panel->lcd_x - panel->lcd_hbp - 20 > > > > > > > > > > > => (tt->hor_front_porch + lcdp->panel_info.lcd_hbp + > > > > > > > > > > > lcdp->panel_info.lcd_x) - panel->lcd_x - panel->lcd_hbp - 20 > > > > > > > > > > > => tt->hor_front_porch - 20 > > > > > > > > > > > > > > > > > > > > The thing is, while your explanation on the DRM side is sound, > > > > > > > > > > Allwinner has been using the hbp field of their panel description to > > > > > > > > > > store what DRM calls the backporch and the sync period. > > > > > > > > > > > > > > > > > > Exactly, hbp = backporch + sync > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/disp_lcd.c#L2046 > > > > > > > > > > > > > > > > > > And the above computation is rely on that as well. If you can see the > > > > > > > > > final out of the above computation you can get the front porch value > > > > > > > > > (w/o sync ) > > > > > > > > > > > > > > > > As I was saying, you are explaining it well for DRM, but in order for > > > > > > > > your last formula (the one coming from the BSP) to make sense, you > > > > > > > > have to explain that the horizontal back porch for Allwinner contains > > > > > > > > the sync period, otherwise your expansion of lcd_ht doesn't make > > > > > > > > sense. > > > > > > > > > > > > > > I'm not sure why we need to take care of back porch since the formula > > > > > > > clearly evaluating a result as front porch, without sync timing (as > > > > > > > current code included this sync), I keep the hbp and trying to > > > > > > > substitute the lcd_ht value so the end result would cancel hbp. > > > > > > > > > > > > Because it changes how lcd_ht expands. In the DRM case, it will expand > > > > > > to the displayed area, the front porch, the sync period and the back > > > > > > porch. > > > > > > > > > > > > In your case, you expand it to the displayed area, the front porch and > > > > > > the back porch, precisely because in Allwinner's case, the back porch > > > > > > has the sync period. > > > > > > > > > > I understand the point, but technically it matter about the final > > > > > computation result. May be we can even manage the same computation in > > > > > back porch, but I'm not sure. Since the final output doesn't involve > > > > > any sync length, why we can include that ie what I'm not sure. > > > > > > > > We have the following formula: > > > > lcd_ht - lcd_x - lcd_hbp - 20 > > > > > > > > Using the concepts as they are defined in DRM, this expands to: > > > > x + hbp + hsync + hfp - x - hbp - 20 > > > > > > Here is diff between allwinner hbp vs hbp in DRM. > > > > > > Say hbp in DRM can call it hbackporch, so > > > > > > => x + hbackporch + hsync + hfp - -x - hbp - 20 > > > > > > (and here we need to substitute hbp formula from allwinner since the > > > actual equation would coming from there > > > https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/disp_lcd.c#L2046) > > > > And this is precisely what needs to be said, with an explanation about > > where that hor_back_porch is being used later on, and what impact it > > could have. > > Yes, it an equation and the mathematical equations can be substitute > to variety kind I did agree with that, whether you can use hbackporch > or not or use another-way the final resulting value is equivalent to > the value of front porch. In that case we can solve based on what I > explained above. If you still dought me, please run BSP and check the > resulting value on this check, you can get the front porch value. Maxime is not doubting you. He is saying that you need to include the detailed explanation in your commit log, and not just reference pieces of code. This is separate from the requirement of having a correct patch. Providing just a mathematical formula isn't enough either, because it is not clear to the average reader which term expanded into what. A better way to do is to first provide the definition of each term in a form easy to understand, such as the following: List of LCD parameters as defined by Allwinner, explained using terms from the DRM subsystem: - lcd_ht: horizontal total size - lcd_x: horizontal display size - lcd_hbp: horizontal sync + backporch Or better yet, copy the diagram from drm_modes.h and add lcd_* to the bottom to show the differences. <-------------------------------- lcd_[hv]t -----------------------------> <----- lcd_[xy] --------> <-------- lcd_[hv]bp ---------> Active Front Sync Back Region Porch Porch <-----------------------><----------------><-------------><--------------> //////////////////////| ////////////////////// | ////////////////////// |.................. ................ _______________ <----- [hv]display -----> <------------- [hv]sync_start ------------> <--------------------- [hv]sync_end ---------------------> <-------------------------------- [hv]total -----------------------------> Then you can go on explain what effect the difference in the definition of "backporch" has on the piece of code you are fixing: The DSI driver misinterpreted the hbp term from the BSP code to refer only to the backporch, when in fact it was backporch + sync. Thus the driver incorrectly used the horizontal front porch plus sync in its calculation of the DRQ value, when it should not have included the sync period. The above explains how you came to create your fix. At this point you don't even need to include the mathematical formulas anymore. The why you already explained, the flip_done time outs. The result you haven't explained, but it can be as simple as: With the terms fixed, the panel displays correctly without any timeouts. Hope this explains clearly what is needed in your commit log, and how to make it easier to understand for other, especially for people either not familiar with display internals, and/or Allwinner specifics. Regards ChenYu