Received: by 10.192.165.156 with SMTP id m28csp753217imm; Thu, 19 Apr 2018 07:03:49 -0700 (PDT) X-Google-Smtp-Source: AIpwx49v7F/rgBi9FSGh5HQtiTLtp3kHO8o591fb67ss2GDbIeQtl7CtzDx0nWowDYOHrzBCLYuS X-Received: by 2002:a17:902:7844:: with SMTP id e4-v6mr6232931pln.296.1524146629900; Thu, 19 Apr 2018 07:03:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524146629; cv=none; d=google.com; s=arc-20160816; b=rRkvlK7IoVChPYkUDFvXls2v3uyggorYof65UgmoSlupZvGJU0Lhtvfdu4OwJzCnLS n6/PWf0PiJQXfnFphWDy/UkhsPxlLxaUJSuvJf1HVFwFmKyj64xfOHVXjbuBVbhlQOVp +GnF1u8TrzAaDmNOR1bNlPtCOssKczi0SPWH8fIleVIv+xo7TE0n3vQAzGGauvN/26cu Y5AFK9yChEdFw4HF6qMST+uECI2wIOZnOSNWEOP98IibUSVFpxnnvsUL/vYnncDwuNRX iamLwI6o4vDCN8M+cwhXC0MkiTz1a+oi6qYTSCNTY/0usdQuHJio0PQSZK9IbFQ0SA30 yfqQ== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:dkim-signature :arc-authentication-results; bh=38YoLGpzhgkn6j/GjKpUUpqyVuI6sR9FeAmkBVphuyM=; b=0PvVMj1nyLHyH7chutcvuAwn5umERBrtr92YKCHCTziAl0Rt5t88kumN0x6I+G0vEW AgToyDLVsJ42ih5PGD1W5BxH6nzMhKb3V6keIcd5ldA4V1etJlsn6VGsa5Um7BxFe3kn qrini+T/ys4rcrtla3pR5zg6xGKRqKCDp5ZtcWs+RhU9ElREk33hPgu1PxfSpCa+Lh7D A2/hba632RNULwzt5bFIQLmWojqvMGyFNpyb3ZZyU4docxHGAMO3Y8Rws44CAHz79oPL Z+VcW+EHQoth45itnnLbyU0g69uRgvz42OOuPp/f+5hcWV3YXPfdmQEpU7u4ZUzY8f6J K54Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@micronovasrl.com header.s=dkim header.b=o49feZVS; 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 w8si2944543pgv.276.2018.04.19.07.03.33; Thu, 19 Apr 2018 07:03:49 -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; dkim=temperror (no key for signature) header.i=@micronovasrl.com header.s=dkim header.b=o49feZVS; 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 S1752647AbeDSOCL (ORCPT + 99 others); Thu, 19 Apr 2018 10:02:11 -0400 Received: from mail.micronovasrl.com ([212.103.203.10]:32800 "EHLO mail.micronovasrl.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750989AbeDSOCK (ORCPT ); Thu, 19 Apr 2018 10:02:10 -0400 Received: from mail.micronovasrl.com (mail.micronovasrl.com [127.0.0.1]) by mail.micronovasrl.com (Postfix) with ESMTP id 36459B00744 for ; Thu, 19 Apr 2018 16:02:09 +0200 (CEST) Authentication-Results: mail.micronovasrl.com (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=micronovasrl.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=micronovasrl.com; h=content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:to:subject:subject; s=dkim; t= 1524146528; x=1525010529; bh=QGGzG/32fd38s5GTYpNr1kPyBGHik6qJY6z HNU7mXOQ=; b=o49feZVSxGOc0x/WIs1TQQqdanl29mch+AUho1U6N6ygkICo0t8 Ij6TmU7fXYunVjWoEr8mutF5Kb3ELNoxgff8Z4I8ymmrrs1WEymU/QJN/TmUfVAA ir9OYO2jwYajsrl4Lim63FacZVeW4M5t8h7f/SvtVA2j4RWtKLS33mVM= X-Virus-Scanned: Debian amavisd-new at mail.micronovasrl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-10 required=4.5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.micronovasrl.com ([127.0.0.1]) by mail.micronovasrl.com (mail.micronovasrl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Cq4_V-nmE4iy for ; Thu, 19 Apr 2018 16:02:08 +0200 (CEST) Received: from [192.168.123.59] (unknown [192.168.123.59]) by mail.micronovasrl.com (Postfix) with ESMTPSA id AA6C7B00058; Thu, 19 Apr 2018 16:02:07 +0200 (CEST) Subject: Re: [v2] drm/sun4i: add lvds mode_valid function To: Chen-Yu Tsai , Maxime Ripard , David Airlie , linux-kernel , dri-devel , linux-arm-kernel References: <1520940019-68977-1-git-send-email-giulio.benetti@micronovasrl.com> <20180419133421.6fx3whge7h364vd3@core> From: Giulio Benetti Message-ID: <129dfeb0-0962-608d-370e-277a3acce7ca@micronovasrl.com> Date: Thu, 19 Apr 2018 16:02:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: it Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi everybody, Il 19/04/2018 15:36, Chen-Yu Tsai ha scritto: > 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/ Thanks for pointing that Thread ChenYu. So the only chance is to trim frequency according to encoder capabilities. I agree to block when encoder can't provide frequency specified, otherwise you could drive you panel at the near the lowest(highest) frequency and get out of limits for a few without knowing it. Best regards -- Giulio Benetti CTO MICRONOVA SRL Sede: Via A. Niedda 3 - 35010 Vigonza (PD) Tel. 049/8931563 - Fax 049/8931346 Cod.Fiscale - P.IVA 02663420285 Capitale Sociale € 26.000 i.v. Iscritta al Reg. Imprese di Padova N. 02663420285 Numero R.E.A. 258642 > > 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 = { > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >