Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85215C27C76 for ; Sun, 22 Jan 2023 15:01:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230002AbjAVPBw (ORCPT ); Sun, 22 Jan 2023 10:01:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229766AbjAVPBu (ORCPT ); Sun, 22 Jan 2023 10:01:50 -0500 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97E141EFCC for ; Sun, 22 Jan 2023 07:01:31 -0800 (PST) Received: from pendragon.ideasonboard.com (213-243-189-158.bb.dnainternet.fi [213.243.189.158]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 51B4F308; Sun, 22 Jan 2023 16:01:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1674399689; bh=j3vz0DSUIpc5ec02NZSPESop0K570/BUISZm0J+cBbA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fmLGxu2hZXCaj+h0avMNLV/i0wpeHp5mrpKImh5jieuN0x1zX6pCzEptdFL/VxQlw mM4T5lFX8ECGxS24LonRTwxNN5CX8/nIWSpe29RMVihmN6RMT8k7MNfMGCdiouTZGF gX1wVOtc3hCHqoeDUYR+Qapl9TLBcGakYDQAzJwA= Date: Sun, 22 Jan 2023 17:01:27 +0200 From: Laurent Pinchart To: John Keeping Cc: Sam Ravnborg , Doug Anderson , Neil Armstrong , Jernej Skrabec , Robert Foss , Jonas Karlman , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Stephen Boyd , Andrzej Hajda , Hsin-Yi Wang Subject: Re: [PATCH] drm/bridge: panel: Set orientation on panel_bridge connector Message-ID: References: <20230120114313.2087015-1-john@metanate.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Sat, Jan 21, 2023 at 05:58:11PM +0000, John Keeping wrote: > On Sat, Jan 21, 2023 at 09:57:18AM +0100, Sam Ravnborg wrote: > > On Fri, Jan 20, 2023 at 01:44:38PM -0800, Doug Anderson wrote: > > > On Fri, Jan 20, 2023 at 3:43 AM John Keeping wrote: > > > > > > > > Commit 15b9ca1641f0 ("drm: Config orientation property if panel provides > > > > it") added a helper to set the panel panel orientation early but only > > > > connected this for drm_bridge_connector, which constructs a panel bridge > > > > with DRM_BRIDGE_ATTACH_NO_CONNECTOR and creates the connector itself. > > > > > > > > When the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is not specified and the > > > > panel_bridge creates its own connector the orientation is not set unless > > > > the panel does it in .get_modes which is too late and leads to a warning > > > > splat from __drm_mode_object_add() because the device is already > > > > registered. > > > > > > > > Call the necessary function to set add the orientation property when the > > > > connector is created so that it is available before the device is > > > > registered. > > > > > > I have no huge objection to your patch and it looks OK to me. That > > > being said, my understanding is that: > > > > > > 1. DRM_BRIDGE_ATTACH_NO_CONNECTOR is "the future" and not using the > > > flag is "deprecated". > > > > Correct. > > Could we take a look at how much is required to move the relevant driver > > to use DRM_BRIDGE_ATTACH_NO_CONNECTOR? > > > > If this is too much work now we may land this simple patch, but the > > preference is to move all drivers to the new bridge handling and thus > > asking display drivers to create the connector. I fully agree with Doug and Sam here. Let's see if we can keep the yak shaving minimal :-) > > What display driver are we dealing with here? > > This is dw-mipi-dsi-rockchip which uses the component path in > dw-mipi-dsi (and, in fact, is the only driver using that mode of > dw-mipi-dsi). > > I'm not familiar enough with DRM to say whether it's easy to convert to > DRM_BRIDGE_ATTACH_NO_CONNECTOR - should dw-mipi-dsi-rockchip be moving > to use dw-mipi-dsi as a bridge driver or should dw_mipi_dsi_bind() have > a drm_bridge_attach_flags argument? But I'm happy to test patches if it > looks easy to convert to you :-) I'd go for the former (use dw_mipi_dsi_probe() and acquire the DSI bridge with of_drm_find_bridge() instead of using the component framework) if possible, but I don't know how intrusive that would be. -- Regards, Laurent Pinchart