Received: by 10.192.165.148 with SMTP id m20csp687607imm; Fri, 20 Apr 2018 13:44:07 -0700 (PDT) X-Google-Smtp-Source: AIpwx49MLO5isnRdtbN+YWbPM00vKiIeYlxV5qbyJXWMWM5ctRJhqbBlyNGbi4mPSxoRZeucteSq X-Received: by 2002:a17:902:5710:: with SMTP id k16-v6mr11598301pli.177.1524257047381; Fri, 20 Apr 2018 13:44:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524257047; cv=none; d=google.com; s=arc-20160816; b=RZ/5HUl7kvZwMtkAMYBW8E3XzX0xoNV60vZKE1lQfezZ7tuL/OG2qFNNAMOTnubeiq EPIRqiF45C2BJ4RjdVpAarL+fs1g6YJid2HwSIywQ5eWmxY9bPJ81BxdUTG41eIkxVN3 lL1PlbtWsn6Us70LnhFJreyn/MskymITFu4+J28fbF9OjDrrmBhfpc4kr5rgxvLFjf+P r7TzO7EX+UiMKTR/gGyrYrSfKKT/TJQ9jeu2G1j2G2xdk/6xhu+X5qh/fVeRX+HIIlXR 0T8bJE/2t29LldL90ZHWVb/1qsCzMQnS7RlpfgA8mUVKHQ0yjjQlyhmCL6bzy5EYgcAO DlFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:to:from:date :arc-authentication-results; bh=P////ge5/2xpRMLDcS7pfhcRGhSx1wbygmrldBCsUoU=; b=rcAf1rVUjl+I/oPad+ehjVqItGtmVULZAW1aR9ccRf6BnLuXEfZ2VzQX/D+ScteOAP Emk0sW36TaR/wvdfF8qRw2CsVXyMAYj9x4mWg7RvEvoVTlXPLv8weRpEiUuRrGIAaR9x x90l8emBBtWtyHWdQDgEXnl7JFg334NEIlpXKQw5aj66pViIZ+93PzKTY9CAoF1382f5 y6K1FRdGJUSN/3UqLRnuW2Oq+1+t3JXA69ODKfmHeTLbtqDZ7g/esGJValoE2NIyKARM kTQ3mGJIkrucxcvB+1pfF/uauuH3bXXqESI3oduh/I+xTy9wcL2beo/gDzXIb7F9gSyP gXEQ== 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 k189si5392854pgd.587.2018.04.20.13.43.29; Fri, 20 Apr 2018 13:44:07 -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 S1752590AbeDTUj7 convert rfc822-to-8bit (ORCPT + 99 others); Fri, 20 Apr 2018 16:39:59 -0400 Received: from mail.bootlin.com ([62.4.15.54]:50934 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751258AbeDTUj6 (ORCPT ); Fri, 20 Apr 2018 16:39:58 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 8B1ED20720; Fri, 20 Apr 2018 22:39:56 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from localhost (LFbn-TOU-1-203-147.w86-201.abo.wanadoo.fr [86.201.50.147]) by mail.bootlin.com (Postfix) with ESMTPSA id 55D4C20376; Fri, 20 Apr 2018 22:39:56 +0200 (CEST) Date: Fri, 20 Apr 2018 22:39:56 +0200 From: Maxime Ripard To: Giulio Benetti , Chen-Yu Tsai , David Airlie , linux-kernel , dri-devel , linux-arm-kernel Subject: Re: [v2] drm/sun4i: add lvds mode_valid function Message-ID: <20180420203956.aqcuwu22iaxnnykn@flea> References: <1520940019-68977-1-git-send-email-giulio.benetti@micronovasrl.com> <20180419133421.6fx3whge7h364vd3@core> <129dfeb0-0962-608d-370e-277a3acce7ca@micronovasrl.com> <20180420131026.vbg3qgrj26egw5s2@core> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <20180420131026.vbg3qgrj26egw5s2@core> User-Agent: NeoMutt/20180323 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 20, 2018 at 03:10:26PM +0200, Ondřej Jirman wrote: > Hello, > > On Thu, Apr 19, 2018 at 04:02:08PM +0200, Giulio Benetti wrote: > > 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. > > When I set the range of pixel clock frequencies on simple-panel connected > to this encoder, the check still fails, so there's something not working > there as expected. This check is only called once with a typical frequency. > > I guess drm doesn't implement clock-frequency range on panels. But I haven't > looked. It does, but only omapdss is able to use it iirc. We could do it too, but that would be way out of scope for a fix. > I can set the exact frequency that the SoC can provide on the simple-panel, > but that's a bit of a hack. Yes. And if the only device using this thus far is broken, that's not really great either. Can you send a revert? Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com