From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759799AbdEOGtI (ORCPT ); Mon, 15 May 2017 02:49:08 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:33112 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759777AbdEOGtH (ORCPT ); Mon, 15 May 2017 02:49:07 -0400 Date: Mon, 15 May 2017 08:49:00 +0200 From: Daniel Vetter To: Laurent Pinchart Cc: Archit Taneja , dri-devel@lists.freedesktop.org, Jose Abreu , Daniel Vetter , Alexey Brodkin , linux-kernel@vger.kernel.org, Carlos Palminha Subject: Re: [PATCH v2 6/8] drm: Introduce drm_bridge_mode_valid() Message-ID: <20170515064900.e4hfuns5gk6yo2r7@phenom.ffwll.local> Mail-Followup-To: Laurent Pinchart , Archit Taneja , dri-devel@lists.freedesktop.org, Jose Abreu , Alexey Brodkin , linux-kernel@vger.kernel.org, Carlos Palminha References: <1645078.FS6fmucJTb@avalon> <2203839.UYlrXxpDjl@avalon> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2203839.UYlrXxpDjl@avalon> X-Operating-System: Linux phenom 4.9.0-2-amd64 User-Agent: NeoMutt/20170306 (1.8.0) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 12, 2017 at 02:01:49PM +0300, Laurent Pinchart wrote: > Hi Archit, > > On Friday 12 May 2017 16:20:07 Archit Taneja wrote: > > On 05/12/2017 03:08 PM, Laurent Pinchart wrote: > > > On Wednesday 10 May 2017 17:14:33 Daniel Vetter wrote: > > >> On Wed, May 10, 2017 at 04:41:09PM +0300, Ville Syrjälä wrote: > > >>> On Tue, May 09, 2017 at 06:00:13PM +0100, Jose Abreu wrote: > > >>>> Introduce a new helper function which calls mode_valid() callback > > >>>> for all bridges in an encoder chain. > > >>>> > > >>>> Signed-off-by: Jose Abreu > > >>>> Cc: Carlos Palminha > > >>>> Cc: Alexey Brodkin > > >>>> Cc: Ville Syrjälä > > >>>> Cc: Daniel Vetter > > >>>> Cc: Dave Airlie > > >>>> Cc: Andrzej Hajda > > >>>> Cc: Archit Taneja > > >>>> --- > > >>>> > > >>>> drivers/gpu/drm/drm_bridge.c | 33 +++++++++++++++++++++++++++++++++ > > >>>> include/drm/drm_bridge.h | 2 ++ > > >>>> 2 files changed, 35 insertions(+) > > >>>> > > >>>> diff --git a/drivers/gpu/drm/drm_bridge.c > > >>>> b/drivers/gpu/drm/drm_bridge.c > > >>>> index 86a7637..dc8cdfe 100644 > > >>>> --- a/drivers/gpu/drm/drm_bridge.c > > >>>> +++ b/drivers/gpu/drm/drm_bridge.c > > >>>> @@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge > > >>>> *bridge, > > >>>> > > >>>> EXPORT_SYMBOL(drm_bridge_mode_fixup); > > >>>> > > >>>> /** > > >>>> > > >>>> + * drm_bridge_mode_valid - validate the mode against all bridges in > > >>>> the > > >>>> + * encoder chain. > > >>>> + * @bridge: bridge control structure > > >>>> + * @mode: desired mode to be validated > > >>>> + * > > >>>> + * Calls &drm_bridge_funcs.mode_valid for all the bridges in the > > >>>> encoder > > >>>> + * chain, starting from the first bridge to the last. If at least one > > >>>> bridge + * does not accept the mode the function returns the error > > >>>> code. > > >>>> + * > > >>>> + * Note: the bridge passed should be the one closest to the encoder. > > >>>> + * > > >>>> + * RETURNS: > > >>>> + * MODE_OK on success, drm_mode_status Enum error code on failure > > >>>> + */ > > >>>> +enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge, > > >>>> + const struct > drm_display_mode > > > > > > *mode) > > > > > >>>> +{ > > >>>> + enum drm_mode_status ret = MODE_OK; > > >>>> + > > >>>> + if (!bridge) > > >>>> + return ret; > > >>>> + > > >>>> + if (bridge->funcs->mode_valid) > > >>>> + ret = bridge->funcs->mode_valid(bridge, mode); > > >>>> + > > >>>> + if (ret != MODE_OK) > > >>>> + return ret; > > >>>> + > > >>>> + return drm_bridge_mode_valid(bridge->next, mode); > > >>> > > >>> Looks like it should be pretty trivial to avoid the recursion. > > >>> > > >>> Am I correct in interpreting this that bridges have some kind of > > >>> a hand rolled linked list implementation? Reusing the standard > > >>> linked lists would allow you to use list_for_each() etc. > > >> > > >> Yeah it's a hand-rolled list, but current hw also has a bridge nesting > > >> depth of 2, so it really doesn't matter. I guess once we have real long > > >> chains of bridges we can fix this (and just using list_head sounds like a > > >> great idea). > > > > > > Even if not really needed right now, it's a pretty easy cleanup, if Jose > > > has time to handle it in v3 of this series let's not postpone it ;-) > > > > jfyi, some of the bridge functions call the ops from the last bridge in the > > chain to first, so we'd need to use list_for_each_entry_prev() (or something > > like that) for them. > > And now that I think about it, for some of the operations (especially > enable/disable) I believe that the bridge should be able to decide whether to > call the next/previous bridge first or to configure its hardware first. I can > image bridges that need the previous bridge in the chain to provide a valid > clock before they get started, as well as bridges that need to be started with > the incoming video signal stopped. That's why we have pre_/post_ hooks ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch