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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 D8536C83000 for ; Tue, 28 Apr 2020 10:05:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 61E02206D6 for ; Tue, 28 Apr 2020 10:05:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="jibHKywq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727883AbgD1KFN (ORCPT ); Tue, 28 Apr 2020 06:05:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49042 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727107AbgD1KFM (ORCPT ); Tue, 28 Apr 2020 06:05:12 -0400 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A45C2C03C1A9 for ; Tue, 28 Apr 2020 03:05:12 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id k12so2058324wmj.3 for ; Tue, 28 Apr 2020 03:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=l+k7yFMhMisNWSRZhvrwWfroBahbWYYcttXSTYKeIwQ=; b=jibHKywqEOHP7s5Uq17E8ygefJpPB+KB36cR9akz/wwH6GF74Ovy8y7nrJQgKD/v86 +ADgY4xegjPKGLTcL6BJ0oyxEBc/3ebLDa6cz/R1bKVedxmKa2fGhgObMZIWZ0aSYDV9 qIlGzv7MRvovl3lA5TeZpfsQe5hz34ij7dOQw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=l+k7yFMhMisNWSRZhvrwWfroBahbWYYcttXSTYKeIwQ=; b=nq02ZieKS0OLfQ/diBePwp+ou8+dUj7QMkDnfqp1TcWNfU6WQkCwJ8iekFOIi8QLB2 abMfKHmJc9A0wt3uHU7BzTiT0btkr2s3YFmMjx9UCLX4nIy/D9U90FnWPNyeu/yrvV55 L7euDK49P3l4Yv7aO8fkjpbl1ofl9lF3mcO0pCdl49Rly9kd5N7nL0cPlw5NwchBWIZH IBJzRxTPAKZBu+JY0wzPv+sw2jZodPX1fCtF204UlNb+p5GoIhiA5u0Nxb70+95xR9Hl dmQOyj9JK1DBLc2r3Cp/TfkvBXH8EjgaEsuMO9okAW3UbHyc402bBdHNi2uD29qE8KAr Jwog== X-Gm-Message-State: AGi0PuZgEdF5/xMxibrZiFr5m9bQNURY76NutNNW+L3a/SeTd0fCTtG3 kFgvcz780VigkTEloWrGcO5U8g== X-Google-Smtp-Source: APiQypKQTCBtHEwl9qfvTCZEBaYghpXpXAL7yjy18ziiEevrdg+jQUjp5/w1QV7rvuqsCLOMh3LRRQ== X-Received: by 2002:a1c:dc8b:: with SMTP id t133mr3745031wmg.117.1588068311327; Tue, 28 Apr 2020 03:05:11 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id 138sm2786040wmb.14.2020.04.28.03.05.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2020 03:05:10 -0700 (PDT) Date: Tue, 28 Apr 2020 12:05:08 +0200 From: Daniel Vetter To: Nicolas Boichat Cc: Xin Ji , devel@driverdev.osuosl.org, Laurent Pinchart , Dan Carpenter , Andrzej Hajda , Neil Armstrong , Jonas Karlman , Jernej Skrabec , David Airlie , Daniel Vetter , lkml , dri-devel , Pi-Hsun Shih , Sheng Pan Subject: Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver Message-ID: <20200428100508.GD3456981@phenom.ffwll.local> Mail-Followup-To: Nicolas Boichat , Xin Ji , devel@driverdev.osuosl.org, Laurent Pinchart , Dan Carpenter , Andrzej Hajda , Neil Armstrong , Jonas Karlman , Jernej Skrabec , David Airlie , lkml , dri-devel , Pi-Hsun Shih , Sheng Pan References: <20200424065124.GA31922@xin-VirtualBox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.3.0-3-amd64 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote: > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji wrote: > > > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote: > > > Hi, > > > > > > Just commenting on the mode_fixup function that was added in v7. > > > > > [snip] > > > > + /* > > > > + * once illegal timing detected, use default HFP, HSYNC, HBP > > > > + */ > > > > + if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp < HP_MIN)) { > > > > > > should this be adj_hblanking/adj_hfp/adj_hbp? > > NO, need check original HFP and HBP, if they are not legal, driver need > > set default value to adj_hsync, adj_hfp, adj_hbp. > > > > > > > + adj_hsync = SYNC_LEN_DEF; > > > > + adj_hfp = HFP_HBP_DEF; > > > > + adj_hbp = HFP_HBP_DEF; > > > > + vref = adj->clock * 1000 / (adj->htotal * adj->vtotal); > > > > + if (hblanking < HBLANKING_MIN) { > > > > + delta_adj = HBLANKING_MIN - hblanking; > > > > + adj_clock = vref * delta_adj * adj->vtotal; > > > > + adj->clock += DIV_ROUND_UP(adj_clock, 1000); > > > > + } else { > > > > + delta_adj = hblanking - HBLANKING_MIN; > > > > + adj_clock = vref * delta_adj * adj->vtotal; > > > > + adj->clock -= DIV_ROUND_UP(adj_clock, 1000); > > > > + } > > > > + > > > > + DRM_WARN("illegal hblanking timing, use default.\n"); > > > > + DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp, hsync); > > > > > > How likely is it that this mode is going to work? Can you just return > > > false here to reject the mode? > > We want to set the default minimal Hblancking value, then it may display, > > otherwise. If we just return false, there is no display for sure. > > Right, understand your argument. I'm pondering if it's not just better > to reject the mode rather than trying a timing that is definitely > quite different from what the monitor was asking for. No super strong > opinion, I'll let other people on the list weigh in. Yeah mode_fixup is supposed to be used to adjust the mode in intermediate stages (e.g. if you go from progressive to interlaced only at the end of your pipeline or something like that). It's not meant for adjusting the mode yout actually put out through a hdmi or dp connector. For fixed panels adjusting modes to fit the panel is also fairly common, but not for external outputs. Since this is a DP bridge I'd say no adjusting, just reject what doesn't fit. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 A9B7DC83007 for ; Tue, 28 Apr 2020 10:05:19 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (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 7E1EB206D9 for ; Tue, 28 Apr 2020 10:05:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="jibHKywq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7E1EB206D9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 7A43586241; Tue, 28 Apr 2020 10:05:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37ggenF53kj2; Tue, 28 Apr 2020 10:05:16 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by fraxinus.osuosl.org (Postfix) with ESMTP id 4F44685E7C; Tue, 28 Apr 2020 10:05:16 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by ash.osuosl.org (Postfix) with ESMTP id 41D721BF277 for ; Tue, 28 Apr 2020 10:05:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 3DFCB86406 for ; Tue, 28 Apr 2020 10:05:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXxX0+tpF7zO for ; Tue, 28 Apr 2020 10:05:13 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by whitealder.osuosl.org (Postfix) with ESMTPS id 06EA686252 for ; Tue, 28 Apr 2020 10:05:12 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id x4so2065772wmj.1 for ; Tue, 28 Apr 2020 03:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=l+k7yFMhMisNWSRZhvrwWfroBahbWYYcttXSTYKeIwQ=; b=jibHKywqEOHP7s5Uq17E8ygefJpPB+KB36cR9akz/wwH6GF74Ovy8y7nrJQgKD/v86 +ADgY4xegjPKGLTcL6BJ0oyxEBc/3ebLDa6cz/R1bKVedxmKa2fGhgObMZIWZ0aSYDV9 qIlGzv7MRvovl3lA5TeZpfsQe5hz34ij7dOQw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=l+k7yFMhMisNWSRZhvrwWfroBahbWYYcttXSTYKeIwQ=; b=QA50eln4p800naByTAycOC+RWipXto09k3jHyrkujk9sFcaPJSk+Ka7YPUuNTt+oy7 3bHDgcs5bdt5s9ZkOhJogfYV9mOtllgNG3IygaMGck2d1IX4jlAFC1NSV4ib5dxCdpnB N39VEJ5f9ptpkvjXp5fNwbTEunEXhbslB9YWsWUnAh5wkHVR61N8cdmVXScbnZ5FIWxw 3TnqTpTHrI8g40g1vgN/SGyMoLLRzLYd0gcXMWsbCEX3ApQo21UCxGx6uEwxXzUKr9Mx xtSftQg4imZTX3Xr9w1VWpuCYjT0ew7EZchvfOLrN2rh1XYZztqORksmmdb8Cw0jNLV1 Y/BQ== X-Gm-Message-State: AGi0PubSAt+OxiaexGPoTTMVcPjZ55mC6rX8fHZFYUq+ymqBHpAA+wWq tobaaezqfzsJ9xfHfL0IScD/Qw== X-Google-Smtp-Source: APiQypKQTCBtHEwl9qfvTCZEBaYghpXpXAL7yjy18ziiEevrdg+jQUjp5/w1QV7rvuqsCLOMh3LRRQ== X-Received: by 2002:a1c:dc8b:: with SMTP id t133mr3745031wmg.117.1588068311327; Tue, 28 Apr 2020 03:05:11 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id 138sm2786040wmb.14.2020.04.28.03.05.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2020 03:05:10 -0700 (PDT) Date: Tue, 28 Apr 2020 12:05:08 +0200 From: Daniel Vetter To: Nicolas Boichat Subject: Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver Message-ID: <20200428100508.GD3456981@phenom.ffwll.local> Mail-Followup-To: Nicolas Boichat , Xin Ji , devel@driverdev.osuosl.org, Laurent Pinchart , Dan Carpenter , Andrzej Hajda , Neil Armstrong , Jonas Karlman , Jernej Skrabec , David Airlie , lkml , dri-devel , Pi-Hsun Shih , Sheng Pan References: <20200424065124.GA31922@xin-VirtualBox> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.3.0-3-amd64 X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, Jernej Skrabec , Pi-Hsun Shih , Neil Armstrong , David Airlie , Jonas Karlman , lkml , dri-devel , Andrzej Hajda , Laurent Pinchart , Daniel Vetter , Xin Ji , Dan Carpenter , Sheng Pan Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote: > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji wrote: > > > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote: > > > Hi, > > > > > > Just commenting on the mode_fixup function that was added in v7. > > > > > [snip] > > > > + /* > > > > + * once illegal timing detected, use default HFP, HSYNC, HBP > > > > + */ > > > > + if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp < HP_MIN)) { > > > > > > should this be adj_hblanking/adj_hfp/adj_hbp? > > NO, need check original HFP and HBP, if they are not legal, driver need > > set default value to adj_hsync, adj_hfp, adj_hbp. > > > > > > > + adj_hsync = SYNC_LEN_DEF; > > > > + adj_hfp = HFP_HBP_DEF; > > > > + adj_hbp = HFP_HBP_DEF; > > > > + vref = adj->clock * 1000 / (adj->htotal * adj->vtotal); > > > > + if (hblanking < HBLANKING_MIN) { > > > > + delta_adj = HBLANKING_MIN - hblanking; > > > > + adj_clock = vref * delta_adj * adj->vtotal; > > > > + adj->clock += DIV_ROUND_UP(adj_clock, 1000); > > > > + } else { > > > > + delta_adj = hblanking - HBLANKING_MIN; > > > > + adj_clock = vref * delta_adj * adj->vtotal; > > > > + adj->clock -= DIV_ROUND_UP(adj_clock, 1000); > > > > + } > > > > + > > > > + DRM_WARN("illegal hblanking timing, use default.\n"); > > > > + DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp, hsync); > > > > > > How likely is it that this mode is going to work? Can you just return > > > false here to reject the mode? > > We want to set the default minimal Hblancking value, then it may display, > > otherwise. If we just return false, there is no display for sure. > > Right, understand your argument. I'm pondering if it's not just better > to reject the mode rather than trying a timing that is definitely > quite different from what the monitor was asking for. No super strong > opinion, I'll let other people on the list weigh in. Yeah mode_fixup is supposed to be used to adjust the mode in intermediate stages (e.g. if you go from progressive to interlaced only at the end of your pipeline or something like that). It's not meant for adjusting the mode yout actually put out through a hdmi or dp connector. For fixed panels adjusting modes to fit the panel is also fairly common, but not for external outputs. Since this is a DP bridge I'd say no adjusting, just reject what doesn't fit. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel 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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 07B8AC83004 for ; Tue, 28 Apr 2020 10:05:16 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 D1221206D6 for ; Tue, 28 Apr 2020 10:05:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="jibHKywq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D1221206D6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 796AF6E15B; Tue, 28 Apr 2020 10:05:14 +0000 (UTC) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by gabe.freedesktop.org (Postfix) with ESMTPS id B5DC86E1D8 for ; Tue, 28 Apr 2020 10:05:12 +0000 (UTC) Received: by mail-wm1-x343.google.com with SMTP id z6so2184110wml.2 for ; Tue, 28 Apr 2020 03:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=l+k7yFMhMisNWSRZhvrwWfroBahbWYYcttXSTYKeIwQ=; b=jibHKywqEOHP7s5Uq17E8ygefJpPB+KB36cR9akz/wwH6GF74Ovy8y7nrJQgKD/v86 +ADgY4xegjPKGLTcL6BJ0oyxEBc/3ebLDa6cz/R1bKVedxmKa2fGhgObMZIWZ0aSYDV9 qIlGzv7MRvovl3lA5TeZpfsQe5hz34ij7dOQw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=l+k7yFMhMisNWSRZhvrwWfroBahbWYYcttXSTYKeIwQ=; b=WqvHcwItwJXsqSn4PJ2BU1H97HCq6W+1yoOAkc78j5EOIyLm+oabO0y0U6iWEeUCpQ 0IQcVZDDj7t9ZKY4WoDGVH0gLgeRtegkrbh0J77oighVLuOozHGattjKlQn6pfyB0uBJ aiiAmAd5zL4a8UWU9ncViJxOBQUY+M2iVnOcLD0Wo/SL+QoiyXFwaYHPa9u+l0tTQ8mp Adq13zYmwpAvdKVn6HpcoL1GuDinJHrLvBccHrGvdQAh9jGpgPVzWesONJ00f+tdBKag PLhxWZCmjAmoWfNdk+dn53N3pGKXf7vPYVMko/uD29xIRMzWVuYc/UtsyEZpWiHZJCZh 0Fzw== X-Gm-Message-State: AGi0PuZMwLMwJUOnAlldSLPKVV8PElr/fXmevFDU46CHUV9fxzQiKGNu VyjMghCYGXMm28OuLvIIp+RWdA== X-Google-Smtp-Source: APiQypKQTCBtHEwl9qfvTCZEBaYghpXpXAL7yjy18ziiEevrdg+jQUjp5/w1QV7rvuqsCLOMh3LRRQ== X-Received: by 2002:a1c:dc8b:: with SMTP id t133mr3745031wmg.117.1588068311327; Tue, 28 Apr 2020 03:05:11 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id 138sm2786040wmb.14.2020.04.28.03.05.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2020 03:05:10 -0700 (PDT) Date: Tue, 28 Apr 2020 12:05:08 +0200 From: Daniel Vetter To: Nicolas Boichat Subject: Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver Message-ID: <20200428100508.GD3456981@phenom.ffwll.local> Mail-Followup-To: Nicolas Boichat , Xin Ji , devel@driverdev.osuosl.org, Laurent Pinchart , Dan Carpenter , Andrzej Hajda , Neil Armstrong , Jonas Karlman , Jernej Skrabec , David Airlie , lkml , dri-devel , Pi-Hsun Shih , Sheng Pan References: <20200424065124.GA31922@xin-VirtualBox> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.3.0-3-amd64 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, Jernej Skrabec , Pi-Hsun Shih , Neil Armstrong , David Airlie , Jonas Karlman , lkml , dri-devel , Andrzej Hajda , Laurent Pinchart , Xin Ji , Dan Carpenter , Sheng Pan Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote: > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji wrote: > > > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote: > > > Hi, > > > > > > Just commenting on the mode_fixup function that was added in v7. > > > > > [snip] > > > > + /* > > > > + * once illegal timing detected, use default HFP, HSYNC, HBP > > > > + */ > > > > + if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp < HP_MIN)) { > > > > > > should this be adj_hblanking/adj_hfp/adj_hbp? > > NO, need check original HFP and HBP, if they are not legal, driver need > > set default value to adj_hsync, adj_hfp, adj_hbp. > > > > > > > + adj_hsync = SYNC_LEN_DEF; > > > > + adj_hfp = HFP_HBP_DEF; > > > > + adj_hbp = HFP_HBP_DEF; > > > > + vref = adj->clock * 1000 / (adj->htotal * adj->vtotal); > > > > + if (hblanking < HBLANKING_MIN) { > > > > + delta_adj = HBLANKING_MIN - hblanking; > > > > + adj_clock = vref * delta_adj * adj->vtotal; > > > > + adj->clock += DIV_ROUND_UP(adj_clock, 1000); > > > > + } else { > > > > + delta_adj = hblanking - HBLANKING_MIN; > > > > + adj_clock = vref * delta_adj * adj->vtotal; > > > > + adj->clock -= DIV_ROUND_UP(adj_clock, 1000); > > > > + } > > > > + > > > > + DRM_WARN("illegal hblanking timing, use default.\n"); > > > > + DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp, hsync); > > > > > > How likely is it that this mode is going to work? Can you just return > > > false here to reject the mode? > > We want to set the default minimal Hblancking value, then it may display, > > otherwise. If we just return false, there is no display for sure. > > Right, understand your argument. I'm pondering if it's not just better > to reject the mode rather than trying a timing that is definitely > quite different from what the monitor was asking for. No super strong > opinion, I'll let other people on the list weigh in. Yeah mode_fixup is supposed to be used to adjust the mode in intermediate stages (e.g. if you go from progressive to interlaced only at the end of your pipeline or something like that). It's not meant for adjusting the mode yout actually put out through a hdmi or dp connector. For fixed panels adjusting modes to fit the panel is also fairly common, but not for external outputs. Since this is a DP bridge I'd say no adjusting, just reject what doesn't fit. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel