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=-9.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 05B25C2D0A3 for ; Thu, 29 Oct 2020 22:49:11 +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 3940820782 for ; Thu, 29 Oct 2020 22:49:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="eWSKjWD4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3940820782 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com 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 06EF96E920; Thu, 29 Oct 2020 22:49:09 +0000 (UTC) Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by gabe.freedesktop.org (Postfix) with ESMTPS id 021466E920 for ; Thu, 29 Oct 2020 22:49:07 +0000 (UTC) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 6596850E; Thu, 29 Oct 2020 23:49:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1604011746; bh=HpOj4aA4dmtkEDrOn7oenTsUJ/yzJlXRU2JcQ1eVp1k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eWSKjWD4zNlciuUf32v3aE46igPy5ULxFmPztTN1l5YENj+IUhj0LC04JccnLhBNt EcDXdQhW2OEP4mTBZe0dmq02McRNgtgU2YNjztmqOROpNMtYoq06VR7BnypsP5nggQ 9fg8N0E5Dc68a0MpCYatsHQXGim7zpMnEDLAxRNE= Date: Fri, 30 Oct 2020 00:48:17 +0200 From: Laurent Pinchart To: Nikhil Devshatwar Subject: Re: [PATCH 3/5] drm: bridge: Propagate the bus flags from bridge->timings Message-ID: <20201029224817.GH15024@pendragon.ideasonboard.com> References: <20201016103917.26838-1-nikhil.nd@ti.com> <20201016103917.26838-4-nikhil.nd@ti.com> <20201028143453.njt3lak542wwx6jb@NiksLab> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201028143453.njt3lak542wwx6jb@NiksLab> 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: Tomi Valkeinen , Sekhar Nori , Swapnil Jakhade , dri-devel@lists.freedesktop.org, Boris Brezillon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hello, On Wed, Oct 28, 2020 at 08:04:53PM +0530, Nikhil Devshatwar wrote: > On 14:31-20201021, Tomi Valkeinen wrote: > > On 16/10/2020 13:39, Nikhil Devshatwar wrote: > > > When the next bridge does not specify any bus flags, use the > > > bridge->timings->input_bus_flags as fallback when propagating > > > bus flags from next bridge to current bridge. > > > > > > Signed-off-by: Nikhil Devshatwar > > > --- > > > drivers/gpu/drm/drm_bridge.c | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > > > index 64f0effb52ac..8353723323ab 100644 > > > --- a/drivers/gpu/drm/drm_bridge.c > > > +++ b/drivers/gpu/drm/drm_bridge.c > > > @@ -975,6 +975,13 @@ drm_atomic_bridge_propagate_bus_flags(struct drm_bridge *bridge, > > > * duplicate the "dummy propagation" logic. > > > */ > > > bridge_state->input_bus_cfg.flags = output_flags; > > > + > > > + /* > > > + * Use the bridge->timings->input_bus_flags as fallback if the next bridge > > > + * does not specify the flags > > > + */ > > > + if (!bridge_state->input_bus_cfg.flags) > > > + bridge_state->input_bus_cfg.flags = bridge->timings->input_bus_flags; > > > > According to docs, timings can be NULL. Correct. > > And, hmm... It's too easy to get confused with these, but... If the bridge defines timings, and > > timings->input_bus_flags != 0, should we always pick that, even if we got something via > > output_flags? Logic being, if this bridge defines timings->input_bus_flags, it probably wants that > > to be used regardless whether we got something from the next bridge. timings->input_bus_flags is an API that predates format and flags propagation along the pipeline. I would assume that drivers that implement propagation should do so in a way that prioritize that API, and either not report flags in the timings (in which case giving priority to one or another wouldn't make a difference as both would never be provided together), or would report flags in the timings as a best effort fallback for display controller drivers that would look at them exclusively without supporting the new API. I would thus think that the flags obtained through format negotiation should be prioritized. > Got it, the flags from timings if present should be prioritized rather > than treating them as fallback. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel