Received: by 10.192.165.156 with SMTP id m28csp727355imm; Thu, 19 Apr 2018 06:38:30 -0700 (PDT) X-Google-Smtp-Source: AIpwx48me0te+CBkqPDuVIWiR1u4H9+gbes3LM20hHg2JLGlr7HaO0tBAC/mNOZ3rOw1SnDToiib X-Received: by 10.99.117.29 with SMTP id q29mr5243601pgc.269.1524145110849; Thu, 19 Apr 2018 06:38:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524145110; cv=none; d=google.com; s=arc-20160816; b=WWWO4RDtps6znKLl+za00qxSerpYlMZWzQV4ifsZBs/BlEdXzT6px2+CvLh5pVZyZj oXXmAuFnB6eKHMKGaG2KQMFPSO/7mIpTRSTH9iTmXyl9ON5eQaYbHOC+8A+Ci241qTXU 7rmfjEL/qMy78YBRKWbc3Bv758L+Inmdl57CwnacSqqqIx0Fm1VN5SP3wbZ5q6eTRFRu KgyAIrl9jbSZujZll6ZU+9pVlPQjdqcqTjH2LieP19KBbp5yy+JzcZ5qhRRnUiISTFAh YQDtTzO5XA8v64TqzXAAJ+VRF/HbFbvFHslz8cjDdBW1zIjiI2O/vVR/Y/BKEhMb7pcC qGEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:to:subject :message-id:date:from:references:in-reply-to:mime-version :arc-authentication-results; bh=FrTy7MAF+R/AHEA6u1TC/bGohhndTd9dNyaqTOBNJHI=; b=c3QfFzLo89tzC2/LEvNHepcDpp5YSvjiR/8LOYUbr7pzAnR+3L3t+mOuB4v5Bw7zyo 0v78kaisygHIOIpVbwC2aBU+6i74TPkaCJfe1k+WfKcmtCtr5d4Xzvmh59XLoKS31suZ p5Mgw1rNjYdkLfU9Sh4fXRQPNrvi5ZsZ4XdWvTbMYuccQfbjHG+LyGEcOXN1QZYezC2Q MrTYBQaBDk8gaURsYqkcfZ69uErtgkD9UCS0pOJzVAKQV7T+zuRCcAa0FmwNW402dwX3 BM2zcrIatyE2l0TK91GONG3r1yEeTfSgP8pNkpj2QdCUC9hRh7J3cGqZ4F7r7AENboQV s9QA== 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 b128si3243041pfa.71.2018.04.19.06.38.16; Thu, 19 Apr 2018 06:38:30 -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 S1753595AbeDSNgt convert rfc822-to-8bit (ORCPT + 99 others); Thu, 19 Apr 2018 09:36:49 -0400 Received: from mail-wr0-f180.google.com ([209.85.128.180]:34364 "EHLO mail-wr0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753077AbeDSNgn (ORCPT ); Thu, 19 Apr 2018 09:36:43 -0400 Received: by mail-wr0-f180.google.com with SMTP id d19-v6so14163110wre.1 for ; Thu, 19 Apr 2018 06:36:42 -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:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=WVu1vy75qy+s3O4O8Jx/92CwXZAVkHkupV1VpQ0wYq8=; b=Oi+j1tOZOeEK3V2DIR4tLL1NgoLcrxr9nJgjsCIMWY0JeEdITMbShm9DadHiRMi7D0 7LAFEC65BekJzaA+6mwfzppyLg6ZqA6AVNWUHk1v9Z2oa04Mg+V+efmotfqtYt1gKzdd hz2mF7Y4m6522H44CyGXhqxmeJhuTz/reAc1sNMr3wAmME4cfhS59hHab70COURoYH7u aHZpdPjLnqrhJkWdU6bOhswpJ2aZorWJIISBv48/u5cqdZiqow9OEl4tQ1yCSm924xfU v3cYIXVH0st7buatelAxGVcKIAQWPy47TxUYak2OB0OVbADNcPoaKOTFUWlr5H8XcXin /Jfg== X-Gm-Message-State: ALQs6tAN/Te5NjXyR99+wM3McvB9tkWYS+ZHV2Dj053fTFcEY1msWFej QoQ3YgpA+zJbkD9hWIJKCqW2Q45R X-Received: by 10.80.137.167 with SMTP id g36mr8545072edg.25.1524145001413; Thu, 19 Apr 2018 06:36:41 -0700 (PDT) Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com. [209.85.128.170]) by smtp.gmail.com with ESMTPSA id 27sm2381021edz.22.2018.04.19.06.36.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 06:36:40 -0700 (PDT) Received: by mail-wr0-f170.google.com with SMTP id s18-v6so14124580wrg.9 for ; Thu, 19 Apr 2018 06:36:40 -0700 (PDT) X-Received: by 10.28.148.129 with SMTP id w123mr4754942wmd.116.1524145000607; Thu, 19 Apr 2018 06:36:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.142.19 with HTTP; Thu, 19 Apr 2018 06:36:19 -0700 (PDT) In-Reply-To: <20180419133421.6fx3whge7h364vd3@core> References: <1520940019-68977-1-git-send-email-giulio.benetti@micronovasrl.com> <20180419133421.6fx3whge7h364vd3@core> From: Chen-Yu Tsai Date: Thu, 19 Apr 2018 21:36:19 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [v2] drm/sun4i: add lvds mode_valid function To: Giulio Benetti , Maxime Ripard , David Airlie , linux-kernel , dri-devel , Chen-Yu Tsai , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 19, 2018 at 9:34 PM, Ondřej Jirman wrote: > Hello Giulio, > > this patch breaks LVDS output on A83T. Without it, modesetting works, > with it there's no output. > > Some more info below... > > On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote: >> mode_valid function is missing for lvds. >> >> Add it making it pointed by encoder helper functions. >> >> Signed-off-by: Giulio Benetti >> --- >> drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 55 insertions(+) >> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c b/drivers/gpu/drm/sun4i/sun4i_lvds.c >> index be3f14d..bffff4c 100644 >> --- a/drivers/gpu/drm/sun4i/sun4i_lvds.c >> +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c >> @@ -94,9 +94,64 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder) >> } >> } >> >> +static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct drm_encoder *crtc, >> + const struct drm_display_mode *mode) >> +{ >> + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc); >> + struct sun4i_tcon *tcon = lvds->tcon; >> + u32 hsync = mode->hsync_end - mode->hsync_start; >> + u32 vsync = mode->vsync_end - mode->vsync_start; >> + unsigned long rate = mode->clock * 1000; >> + long rounded_rate; >> + >> + DRM_DEBUG_DRIVER("Validating modes...\n"); >> + >> + if (hsync < 1) >> + return MODE_HSYNC_NARROW; >> + >> + if (hsync > 0x3ff) >> + return MODE_HSYNC_WIDE; >> + >> + if ((mode->hdisplay < 1) || (mode->htotal < 1)) >> + return MODE_H_ILLEGAL; >> + >> + if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff)) >> + return MODE_BAD_HVALUE; >> + >> + DRM_DEBUG_DRIVER("Horizontal parameters OK\n"); >> + >> + if (vsync < 1) >> + return MODE_VSYNC_NARROW; >> + >> + if (vsync > 0x3ff) >> + return MODE_VSYNC_WIDE; >> + >> + if ((mode->vdisplay < 1) || (mode->vtotal < 1)) >> + return MODE_V_ILLEGAL; >> + >> + if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff)) >> + return MODE_BAD_VVALUE; >> + >> + DRM_DEBUG_DRIVER("Vertical parameters OK\n"); >> + >> + tcon->dclk_min_div = 7; >> + tcon->dclk_max_div = 7; > > Why would validation function change any state anywhere? > >> + rounded_rate = clk_round_rate(tcon->dclk, rate); > > The issue is here, on A83T TBS A711 tablet, I get... > > sun4i-tcon 1c0c000.lcd-controller: XXX: hsync=20 hdisplay=1024 htotal=1384 > vsync=5 vdisplay=600 vtotal=640 rate=52000000 rounded_rate=51857142 > >> + if (rounded_rate < rate) >> + return MODE_CLOCK_LOW; >> + >> + if (rounded_rate > rate) >> + return MODE_CLOCK_HIGH; > > ... while the previous conditions require an exact match for some reason. > > But HW works fine without an exact rate match. Why is exact match required here? This thread might provide some more info, though we could never get an agreement. https://patchwork.kernel.org/patch/9446385/ ChenYu > > thank you, > Ondrej > >> + DRM_DEBUG_DRIVER("Clock rate OK\n"); >> + >> + return MODE_OK; >> +} >> + >> static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = { >> .disable = sun4i_lvds_encoder_disable, >> .enable = sun4i_lvds_encoder_enable, >> + .mode_valid = sun4i_lvds_encoder_mode_valid, >> }; >> >> static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {