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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9966CC31E44 for ; Fri, 14 Jun 2019 06:33:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2C073208CA for ; Fri, 14 Jun 2019 06:33:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amarulasolutions.com header.i=@amarulasolutions.com header.b="LdrNHrf+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725891AbfFNGd0 (ORCPT ); Fri, 14 Jun 2019 02:33:26 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:37901 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725822AbfFNGdZ (ORCPT ); Fri, 14 Jun 2019 02:33:25 -0400 Received: by mail-io1-f65.google.com with SMTP id k13so3400415iop.5 for ; Thu, 13 Jun 2019 23:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BC78yzeE2YVKx79Y2+WiS4iK6WeI4kP4QaEjuFxmzkA=; b=LdrNHrf+3Zal1wdOC3nqZSVJTZ1ztZNykMZ180uzsuSvlISU5nSC4VNTxS8zoaOfrO hOY0UTpCsxGSV73FXv3vjyCicnC4lkVC/M23gJz9R9s9Nyz4Zw76EARWPGeUB9vRve/I SekLQ1rfJUbhW5Es0Pnp2hsgMFL6UaXyKuSso= 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=BC78yzeE2YVKx79Y2+WiS4iK6WeI4kP4QaEjuFxmzkA=; b=Keqa8P8Cb/S2HvpGS3/KU3pq+vY2gFrWKkUEwtEkPyC7VIVpSfC+Bo6Ae2KnT//28H onfrxNemjkUuo+ZF+axeTehWV8huIP2nCmoPrdyFdu7DgbFc8+6njqB+OLLneXsUuxts 4jOjxubtpRmKTabExY8jWE/TMDhm3fnwrMRBPKXPXLOApI/GDiDJihdsUZ9wuUoRkmT4 KX0XrWz/n3bG294CLu9Pz8fSpVRdxMxOz/sTMG3DOYyHmPTnYEqj80bP4MYfrv4N82Hj MJyDSdyGhouM/y+OG8yRqK1W64F7wR+wnnhHqbzkMfygb54SdaVGopGEjvkRDu7trMTJ 4XRw== X-Gm-Message-State: APjAAAWlp/rSSGDke2cMwxuLrnVFU9h8sYgTeDGJKPiXL2imYriYj9X+ NY+XJULEG7urAa7Gu/ESI2lzXVEW9E9ur/ILDpFCxw== X-Google-Smtp-Source: APXvYqweSn0IQ8QqCH4p5EFhvJNln9sfYUgga9RCLvHtMGb5QEWowO29OmcHTwtxMf4b7gjxCBAq/GZXs5jv+MERDZo= X-Received: by 2002:a02:3308:: with SMTP id c8mr46484238jae.103.1560494004682; Thu, 13 Jun 2019 23:33:24 -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> In-Reply-To: <20190613125630.2b2fvvtvrcjlx4lv@flea> From: Jagan Teki Date: Fri, 14 Jun 2019 12:03:13 +0530 Message-ID: Subject: Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits To: Maxime Ripard Cc: David Airlie , Daniel Vetter , Chen-Yu Tsai , 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 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) => x + hbackporch + hsync + hfp - x - (hbackporch + hsync) - 20 => x + hbackporch + hsync + hfp - x - hbackporch - hsync - 20 => hfp - 20 > > which ends up as > hsync + hfp - 20 > > Now, the same formula with how Allwinner defines it: > x + hbp + hfp - x - hbp - 20 > which ends up as > hfp - 20 This is true, and same I have explained in commit log. and hbp here is as per allwinner so we endedup hfp. which is satisfied by above DRM equation. > > So it definitely matters, and the sync period is used in one but not > the other. With the above explanation there is no sync included. 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 X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 250CFC31E44 for ; Fri, 14 Jun 2019 06:33:44 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C629D20850 for ; Fri, 14 Jun 2019 06:33:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FHeWqFfl"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=amarulasolutions.com header.i=@amarulasolutions.com header.b="LdrNHrf+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C629D20850 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amarulasolutions.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=SbPfchHdMFVLOGYPzLLyYkwuqOfc+Qv4YJmgs+f5R3k=; b=FHeWqFflejGOY7 Bwpej6aVFwPR4g28jZhxwgVf7Gm17yvdMyZ+nYahsNRd8t4uhjZ99kg9dQKQng8ZAtWh3EGYx0pl8 jCgaOZxWWx215BtFVAyX6cm/qjuFOynaQiRiz+f1q6Kdg/4A4A76yiNcIyEPBsx8dyC52Y99X0S8p hrYp36S8udh+fSKME8udKw5N6uE8yVeSVv8DCl+AaV8zzlhLpk4Mnd3/k5c8tmv+5nSwczo6XEmFg I5Mf/xHaT4ixqY/g1CYgw0j9sseSfnQcLe2WCv+wLyrh/7A3Zr5ZQfVt6HSPp4LB2OlIFziKb0JP3 l8DKe21WT7wM32WhEnVA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hbfmE-0001ny-Pf; Fri, 14 Jun 2019 06:33:30 +0000 Received: from mail-io1-xd43.google.com ([2607:f8b0:4864:20::d43]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hbfm9-0001lR-Ux for linux-arm-kernel@lists.infradead.org; Fri, 14 Jun 2019 06:33:28 +0000 Received: by mail-io1-xd43.google.com with SMTP id w25so3331937ioc.8 for ; Thu, 13 Jun 2019 23:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BC78yzeE2YVKx79Y2+WiS4iK6WeI4kP4QaEjuFxmzkA=; b=LdrNHrf+3Zal1wdOC3nqZSVJTZ1ztZNykMZ180uzsuSvlISU5nSC4VNTxS8zoaOfrO hOY0UTpCsxGSV73FXv3vjyCicnC4lkVC/M23gJz9R9s9Nyz4Zw76EARWPGeUB9vRve/I SekLQ1rfJUbhW5Es0Pnp2hsgMFL6UaXyKuSso= 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=BC78yzeE2YVKx79Y2+WiS4iK6WeI4kP4QaEjuFxmzkA=; b=K9knwnQUkpmWY++Ma9MrIbupk6/aNvmttHqxY0Y5+N75YwEcOUalKPzlVuQXnFvo/A beFg54dB470/s0sB5IgSTNntPVuCvH4f1AwpD4qCfD62BaGbtmF8xqJxZ+PpxYnNErMT q6at7mDfz9kVOCY2k44BeSpvr0z+V/ZdhSENZViWw2jdE5iBRr4CF6KnhSVW5EIuM8yF G2cO1mN/f3c+vLitHdN85/TbrQ51baV0PNXTI34vdeNHpbirSjIBieLQkvkdHnPedkYF l3avtq4uAc8tT64Ew9dTbFUbPJP2rqlGjw7zZUw/LLCA/xZk3e2B7c4Xe1gBjDI9tPoF OAaA== X-Gm-Message-State: APjAAAVwoP5MR8iozhpIh4suCJQPkDnWEwD40iLLBNVRvyUoPUxejMOw PHBT28A+Sbqderjem/n5pCkG4xIsDeEaoZNFZXghkw== X-Google-Smtp-Source: APXvYqweSn0IQ8QqCH4p5EFhvJNln9sfYUgga9RCLvHtMGb5QEWowO29OmcHTwtxMf4b7gjxCBAq/GZXs5jv+MERDZo= X-Received: by 2002:a02:3308:: with SMTP id c8mr46484238jae.103.1560494004682; Thu, 13 Jun 2019 23:33:24 -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> In-Reply-To: <20190613125630.2b2fvvtvrcjlx4lv@flea> From: Jagan Teki Date: Fri, 14 Jun 2019 12:03:13 +0530 Message-ID: Subject: Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits To: Maxime Ripard X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190613_233326_156059_6516A667 X-CRM114-Status: GOOD ( 26.60 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bhushan Shah , David Airlie , linux-sunxi , linux-kernel , dri-devel , =?UTF-8?B?5Z2a5a6a5YmN6KGM?= , Chen-Yu Tsai , Daniel Vetter , Michael Trimarchi , linux-amarula , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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) => x + hbackporch + hsync + hfp - x - (hbackporch + hsync) - 20 => x + hbackporch + hsync + hfp - x - hbackporch - hsync - 20 => hfp - 20 > > which ends up as > hsync + hfp - 20 > > Now, the same formula with how Allwinner defines it: > x + hbp + hfp - x - hbp - 20 > which ends up as > hfp - 20 This is true, and same I have explained in commit log. and hbp here is as per allwinner so we endedup hfp. which is satisfied by above DRM equation. > > So it definitely matters, and the sync period is used in one but not > the other. With the above explanation there is no sync included. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jagan Teki Subject: Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits Date: Fri, 14 Jun 2019 12:03:13 +0530 Message-ID: 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> Reply-To: jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: <20190613125630.2b2fvvtvrcjlx4lv@flea> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Maxime Ripard Cc: David Airlie , Daniel Vetter , Chen-Yu Tsai , dri-devel , linux-arm-kernel , linux-kernel , Bhushan Shah , Vasily Khoruzhick , =?UTF-8?B?5Z2a5a6a5YmN6KGM?= , Michael Trimarchi , linux-amarula , linux-sunxi List-Id: dri-devel@lists.freedesktop.org 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) => x + hbackporch + hsync + hfp - x - (hbackporch + hsync) - 20 => x + hbackporch + hsync + hfp - x - hbackporch - hsync - 20 => hfp - 20 > > which ends up as > hsync + hfp - 20 > > Now, the same formula with how Allwinner defines it: > x + hbp + hfp - x - hbp - 20 > which ends up as > hfp - 20 This is true, and same I have explained in commit log. and hbp here is as per allwinner so we endedup hfp. which is satisfied by above DRM equation. > > So it definitely matters, and the sync period is used in one but not > the other. With the above explanation there is no sync included.