From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754188AbdEOETD (ORCPT ); Mon, 15 May 2017 00:19:03 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:48854 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750772AbdEOETB (ORCPT ); Mon, 15 May 2017 00:19:01 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 5AE7D60729 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=architt@codeaurora.org Subject: Re: [PATCH v2 6/8] drm: Introduce drm_bridge_mode_valid() To: Laurent Pinchart References: <1645078.FS6fmucJTb@avalon> <2203839.UYlrXxpDjl@avalon> Cc: dri-devel@lists.freedesktop.org, Jose Abreu , Daniel Vetter , Alexey Brodkin , linux-kernel@vger.kernel.org, Carlos Palminha From: Archit Taneja Message-ID: <6490c0e0-d69c-fbd0-7bbe-583fec6386f9@codeaurora.org> Date: Mon, 15 May 2017 09:48:52 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <2203839.UYlrXxpDjl@avalon> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/12/2017 04:31 PM, 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. I guess converting into list would be a good start to achieve this. We'd probably need to extend/redo the drm_bridge_attach() API to tweak the order in the which the ops are called. Thanks, Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project