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.5 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 8F9E7C8300F for ; Thu, 30 Apr 2020 13:37:43 +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 65B682074A for ; Thu, 30 Apr 2020 13:37:43 +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="AUQMg9Bf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 65B682074A 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 BF7396E89F; Thu, 30 Apr 2020 13:37:42 +0000 (UTC) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0E6EE6E89F for ; Thu, 30 Apr 2020 13:37:41 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id x18so6957175wrq.2 for ; Thu, 30 Apr 2020 06:37:40 -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=cIp9DbU+6rRfiPbG8uAVaJPBU9twoue+ADTvawohLJ4=; b=AUQMg9Bfr7hBR51Z28J9x9t2Irvw2vW5PyG4R/MxI6yDPK6/b/N3PFe0ZbPEv/oNXD MX/9JYqZK8jR0AvdRC6mo7BRI2JjjnAX3A4N7FC2xazulqlbx3GfSuQFUyJZhPZ12dNt UQTEgyH586iFrg6yerVwQymf3ZQWBP7qFMeTs= 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=cIp9DbU+6rRfiPbG8uAVaJPBU9twoue+ADTvawohLJ4=; b=hXXy1YnpyzH0vdxO+pERW7FHjf4/B1YT8/L6gKvd7m0MlqE2OQ01xyQsD514zR8vi6 aZkjmD0rVQ9ciYpzRjYmYdSFUccYZUgzGProtZWN36gjN8z2JJVXaXxvpua0OBodeJob D+r84Uc546hVB4bZiRWTIFLWZ2It90srNFQWuhTbZIZDXbe9kl7g+MGk9oQBt7uOcLtN tFJzhvthKQ32qfDyNqYd5lfWHVR/THqQ+ys9KMvfouC0JRPP06GJ1TB7dxtvwxOX9dvg DDd9kPHnvun+RZIOwnHZMeXuqAZR/QMtaEMZsG5XqRdPHVz3PZSWW1g7BRXRewX587X0 U4Zw== X-Gm-Message-State: AGi0PuaujFRr6onit67chCr2Zbgkrg7jTwgS94UvMYgoq7zxkfp4AAJn 1dEafmj4Vf14fhDwZUQVxC3iuw== X-Google-Smtp-Source: APiQypL9RK8HI6QxyV+3Rq7Wl6MRj5xlTTsfy+Y6JwCeDq2W1PgLcVkhMuTOPlnyqwhEdYENozbNbQ== X-Received: by 2002:adf:df8d:: with SMTP id z13mr4003100wrl.304.1588253859692; Thu, 30 Apr 2020 06:37:39 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id o3sm4146326wru.68.2020.04.30.06.37.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Apr 2020 06:37:38 -0700 (PDT) Date: Thu, 30 Apr 2020 15:37:31 +0200 From: Daniel Vetter To: Xin Ji Subject: Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver Message-ID: <20200430133731.GA10381@phenom.ffwll.local> Mail-Followup-To: Xin Ji , Nicolas Boichat , devel@driverdev.osuosl.org, Laurent Pinchart , Dan Carpenter , Andrzej Hajda , Neil Armstrong , Jonas Karlman , Jernej Skrabec , David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Pi-Hsun Shih , Sheng Pan , Qilin Wen , Ming Liu References: <20200424065124.GA31922@xin-VirtualBox> <20200428100508.GD3456981@phenom.ffwll.local> <20200430033614.GA6645@xin-VirtualBox> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200430033614.GA6645@xin-VirtualBox> X-Operating-System: Linux phenom 5.4.0-4-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, Nicolas Boichat , Jernej Skrabec , Pi-Hsun Shih , Neil Armstrong , David Airlie , Qilin Wen , Jonas Karlman , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Andrzej Hajda , Ming Liu , Laurent Pinchart , 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 Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote: > On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote: > > 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. > We have found some panel which HBP less than 8, if we reject to adjust > video timing, then there is no display. The customer does not accept it, > they push us to fix it, the only resolve way is to adjust timing. Are we talking about external DP screen here, or some built-in panel? For the later case we do a lot of mode adjusting in many drivers ... I haven't checked, by if our connector type is eDP then this should be all fine. -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