Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp1366821rwo; Wed, 2 Aug 2023 12:54:22 -0700 (PDT) X-Google-Smtp-Source: APBJJlFJ0Zdo9CXQSEcvCgnDmW0kyTM3fsOPTQUIuJT3dONEaBjdD8PH+GzFkI9Jk2f9E9iiRTpf X-Received: by 2002:a17:906:74d0:b0:993:e9b8:90ec with SMTP id z16-20020a17090674d000b00993e9b890ecmr6022743ejl.22.1691006062076; Wed, 02 Aug 2023 12:54:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691006062; cv=none; d=google.com; s=arc-20160816; b=t8xZ/cLIwvGk4mwqVe6blHFjdONAz3WjI59ByWi3sFBjoBjgLCTqbkAqFn5V9o4Nho hlTOvDIQjFuehvKhydBbqBOJBC+7LeYtgrZIHxcRazoV9WZ5304uYjiFWH9zkjQFvyNY dtznw8e3qQfWZwN4IEUDKgJwvLQ7FGqW+cJB+DmkGe10pYdfWnyWLJ/sQT7syCsvn4tJ S3gw7XTfQznpzlhZxaMA7Dxng1OTY/DYF+Lwal0N5TEtuz7MLooEyz3kpWUGuXav+8P2 QGUKA1PifrKIP565NviKw8kFHBgiusepZjNpxIwgYaCB3CWdfLnULMAo+lvRddrcNfQM b7iA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=wG5nguxWEtNmJchHHC506K+1GSUaj+O4MVu+D2EKXuk=; fh=r2ZINdNNVjVMch0LwNVbusnpvhZIdV2LvK8ow0asT+Q=; b=ly4IzSmCSP6Ha5slo9jEyoa46DIybavenXUe5xvQ4rHD5+Uh8TVd/ZjuIMCNRhabfU b+OJkuRRxy+Pzvc4I8HTIXpGdi16upq5pAlw0hmQupMlciYR6J2lu+odSgu5CtHH+lEj 8Y7BDTXv6lff1Z+huFqJzHGfqcDddLON9hAB2w5erpj6jZ6PsZZZecz2qaMjshSV0+2D p+eJa7JuttRxSXxI+QK58udeFiG2yhHr8kiwUXFxXYSryvTPsiGzSe2mJt68V89G4tzC SrK+1uIm2e7n8kUv07L9iO8GYzS/3M8pUrcwKiw/sw6Y4IVpR9nMgo9uuAW0UHfmsfCT jh9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=DRhGCqAh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gv4-20020a170906f10400b009829077b479si6761808ejb.860.2023.08.02.12.53.57; Wed, 02 Aug 2023 12:54:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=DRhGCqAh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231405AbjHBSqV (ORCPT + 99 others); Wed, 2 Aug 2023 14:46:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230076AbjHBSqU (ORCPT ); Wed, 2 Aug 2023 14:46:20 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7839119A4 for ; Wed, 2 Aug 2023 11:46:19 -0700 (PDT) Received: from pendragon.ideasonboard.com (213-243-189-158.bb.dnainternet.fi [213.243.189.158]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 5D88F9CA; Wed, 2 Aug 2023 20:45:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1691001913; bh=6lMIvnUDmcbkmqo6E/Xm2zfqir/+TekU2+85+m1X+qo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DRhGCqAhLNEY1+DwW1JlMQyZnqagkG6GpLtr+9d5fVZ5c6vTuwXf17B8Gyxuinsoi fWCiDEVmckZVwy4p5G6qt3uqgpiKWVRKDX8j40iG+pkFztNecCmk6CTuZR7yZvWXGb SpJEUnyGymyhvG89qZ/s7mdq4fdbPr3wXW/NaG6E= Date: Wed, 2 Aug 2023 21:46:22 +0300 From: Laurent Pinchart To: Dmitry Baryshkov Cc: neil.armstrong@linaro.org, David Airlie , Daniel Vetter , Andrzej Hajda , Robert Foss , Jonas Karlman , Jernej Skrabec , Andy Gross , Bjorn Andersson , Konrad Dybcio , Simon Ser , Janne Grunau , Alex Deucher , Christian =?utf-8?B?S8O2bmln?= , "Pan, Xinhui" , Harry Wentland , Leo Li , Rodrigo Siqueira , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org Subject: Re: [PATCH 2/4] drm/bridge-connector: handle subconnector types Message-ID: <20230802184622.GA32500@pendragon.ideasonboard.com> References: <20230729004913.215872-1-dmitry.baryshkov@linaro.org> <20230729004913.215872-3-dmitry.baryshkov@linaro.org> <0cc04d99-d7aa-68ff-b304-7d42ae7f0dde@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 02, 2023 at 12:05:50PM +0300, Dmitry Baryshkov wrote: > On Wed, 2 Aug 2023 at 11:35, Neil Armstrong wrote: > > On 29/07/2023 02:49, Dmitry Baryshkov wrote: > > > If the created connector type supports subconnector type property, > > > create and attach corresponding it. The default subtype value is 0, > > > which maps to the DRM_MODE_SUBCONNECTOR_Unknown type. > > > > > > Signed-off-by: Dmitry Baryshkov > > > --- > > > drivers/gpu/drm/drm_bridge_connector.c | 33 +++++++++++++++++++++++++- > > > include/drm/drm_bridge.h | 4 ++++ > > > 2 files changed, 36 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/drm_bridge_connector.c b/drivers/gpu/drm/drm_bridge_connector.c > > > index 07b5930b1282..a7b92f0d2430 100644 > > > --- a/drivers/gpu/drm/drm_bridge_connector.c > > > +++ b/drivers/gpu/drm/drm_bridge_connector.c > > > @@ -329,7 +329,9 @@ struct drm_connector *drm_bridge_connector_init(struct drm_device *drm, > > > struct drm_connector *connector; > > > struct i2c_adapter *ddc = NULL; > > > struct drm_bridge *bridge, *panel_bridge = NULL; > > > + enum drm_mode_subconnector subconnector; > > > int connector_type; > > > + int ret; > > > > > > bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL); > > > if (!bridge_connector) > > > @@ -365,8 +367,10 @@ struct drm_connector *drm_bridge_connector_init(struct drm_device *drm, > > > if (bridge->ops & DRM_BRIDGE_OP_MODES) > > > bridge_connector->bridge_modes = bridge; > > > > > > - if (!drm_bridge_get_next_bridge(bridge)) > > > + if (!drm_bridge_get_next_bridge(bridge)) { > > > connector_type = bridge->type; > > > + subconnector = bridge->subtype; > > > + } > > > > > > #ifdef CONFIG_OF > > > if (!drm_bridge_get_next_bridge(bridge) && > > > @@ -399,6 +403,33 @@ struct drm_connector *drm_bridge_connector_init(struct drm_device *drm, > > > if (panel_bridge) > > > drm_panel_bridge_set_orientation(connector, panel_bridge); > > > > > > + if (connector_type == DRM_MODE_CONNECTOR_DisplayPort) { > > > + drm_connector_attach_dp_subconnector_property(connector, subconnector); > > > + } else if (connector_type == DRM_MODE_CONNECTOR_DVII) { > > > + ret = drm_mode_create_dvi_i_properties(drm); > > > + if (ret) > > > + return ERR_PTR(ret); > > > + > > > + drm_object_attach_property(&connector->base, > > > + drm->mode_config.dvi_i_subconnector_property, > > > + subconnector); > > > + } else if (connector_type == DRM_MODE_CONNECTOR_TV) { > > > + ret = drm_mode_create_tv_properties(drm, > > > + BIT(DRM_MODE_TV_MODE_NTSC) | > > > + BIT(DRM_MODE_TV_MODE_NTSC_443) | > > > + BIT(DRM_MODE_TV_MODE_NTSC_J) | > > > + BIT(DRM_MODE_TV_MODE_PAL) | > > > + BIT(DRM_MODE_TV_MODE_PAL_M) | > > > + BIT(DRM_MODE_TV_MODE_PAL_N) | > > > + BIT(DRM_MODE_TV_MODE_SECAM)); > > > + if (ret) > > > + return ERR_PTR(ret); > > > > I don't think this is right, this should be called from the appropriate encoder > > device depending on the analog tv mode capabilities. > > Good question. My logic was the following: the DRM device can have > different TV out ports with different capabilities (yeah, pure > theoretical construct). In this case it might be impossible to create > a single subset of values. Thus it is more correct to create the > property listing all possible values. The property is immutable anyway > (and so the user doesn't have control over the value). Those ports would correspond to different connectors, so I agree with Neil, I don't think it's right to create a single property with all modes and attach it to all analog output connectors. If you want to support multiple analog outputs that have different capabilities, this will need changes to drm_mode_create_tv_properties() to allow creating multiple properties. If you don't want to do so now, and prefer limiting support to devices where all ports support the same modes (which includes devices with a single analog output), then the modes should reflect what the device supports. > > > + > > > + drm_object_attach_property(&connector->base, > > > + drm->mode_config.tv_subconnector_property, > > > + subconnector); > > > > Here, only add the property if drm->mode_config.tv_subconnector_property exists, > > and perhaps add a warning if not. > > This property is created in the previous call, > drm_mode_create_tv_properties() -> > drm_mode_create_tv_properties_legacy(). > > > AFAIK same for DRM_MODE_CONNECTOR_DVII. > > > > > + } > > > + > > > return connector; > > > } > > > EXPORT_SYMBOL_GPL(drm_bridge_connector_init); > > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h > > > index bf964cdfb330..68b14ac5ac0d 100644 > > > --- a/include/drm/drm_bridge.h > > > +++ b/include/drm/drm_bridge.h > > > @@ -739,6 +739,10 @@ struct drm_bridge { > > > * identifies the type of connected display. > > > */ > > > int type; > > > + /** > > > + * @subtype: the subtype of the connector for the DP/TV/DVI-I cases. > > > + */ > > > + enum drm_mode_subconnector subtype; > > > /** > > > * @interlace_allowed: Indicate that the bridge can handle interlaced > > > * modes. -- Regards, Laurent Pinchart