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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 63A31C433ED for ; Tue, 18 May 2021 14:21:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 498E6611BF for ; Tue, 18 May 2021 14:21:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344529AbhEROWZ (ORCPT ); Tue, 18 May 2021 10:22:25 -0400 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:57495 "EHLO new3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241291AbhEROWW (ORCPT ); Tue, 18 May 2021 10:22:22 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id E39BD5808BA; Tue, 18 May 2021 10:21:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 18 May 2021 10:21:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=lWIf1SAehz/MyS6HAHHwUIo8Dvl Qutv5w9WI0Lg2kmc=; b=QyeF9DW43KQ36ukC1peXzYdFHKFadkwOb71yOYJ5vQ3 XzEI/11psIyt7lFlcUS9WqqsScu9y3NBOBtIWYc8dK6X+200V9gyoVCGi3izOSlV v5u+2oZIHRBbiiun/WSYVTGrnNFmHU7zovAlfMXN3oPuTJhh/Det7j72KUQJCf6a qbZv3YEXR4q9LMPSpJULtcu2wHZ0roQo63vfUJDhxpiQAoO68ouvwF9WB1m8byFB CwqpI1O9pyzsNAx7PABdRP1+tJISqN18Xb8WaANhCdHeA8SGQfzN1iHkJHlY7Fna JxlJ44bcoJYbZ8y3ZfCDrDqF94aMr3lWeTnJJLyzTqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=lWIf1S Aehz/MyS6HAHHwUIo8DvlQutv5w9WI0Lg2kmc=; b=pdPTvbnCm9SvLC0OtOXzuX 2qPtSnDcqScMIbae9z9LQq3wgIy2dSsh4l0nPZjw0XSzg27K4d4iRngCex5n547J YxH1s8HfTqpL/phEqd+1Zanevc4EF2DXt6XULfh4eCv9UYYB2OCGRVuvmARCzsbz Yl5Fo8aBTCRYGpheqT0h4c8RM+LfZ1TVnF7VAYJ9JxKUJG3gaBbw8yEKBeBHww69 NinBnXeGnn9A/b+jHPT0woriamANA+n9VU6AfnKFI7DPiSdWmllVZ1g4LNB/Bfci bpUhZHeOd23nc8IlALdZmwrnnoEKq68mmGE/Fr4OBrsBMu+vRRxwZ1icAs8qwTYg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeijedgjeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepuedtgfejueduheevgfevvdettdduleffgfffkeeltdffkeegudekjeeuveei gedunecukfhppeeltddrkeelrdeikedrjeeinecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 18 May 2021 10:21:02 -0400 (EDT) Date: Tue, 18 May 2021 16:20:59 +0200 From: Maxime Ripard To: Kevin Tang Cc: Maarten Lankhorst , Sean Paul , David Airlie , Daniel Vetter , Rob Herring , Mark Rutland , Orson Zhai , Chunyan Zhang , "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , devicetree@vger.kernel.org Subject: Re: [PATCH v5 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver Message-ID: <20210518142059.o7ql6de4src53y4l@gilmour> References: <20210425123607.26537-1-kevin3.tang@gmail.com> <20210425123607.26537-7-kevin3.tang@gmail.com> <20210430093503.aupvt2qkrzkzy2ed@gilmour> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cu37uqlsbtggd2ix" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --cu37uqlsbtggd2ix Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 12, 2021 at 09:53:06PM +0800, Kevin Tang wrote: > > > +struct dsi_reg { > > > + union _0x00 { > > > + u32 val; > > > + struct _DSI_VERSION { > > > + u32 dsi_version: 16; > > > + u32 reserved: 16; > > > + } bits; > > > + } DSI_VERSION; > > > > Using unions and structures to define the register is really frowned > > upon in favor of defines, like you rightfully did in the crtc driver. > > This workload is too big, this design has been used for many years, > so I actually want to keep it the same, but if it really doesn=E2=80=99t = meet > the current design. > > I can change the design, but it may take a lot of time...... There's no rush :) > > > +static int sprd_dsi_find_panel(struct sprd_dsi *dsi) > > > +{ > > > + struct device *dev =3D dsi->host.dev; > > > + struct device_node *child, *lcds_node; > > > + struct drm_panel *panel; > > > + > > > + /* search /lcds child node first */ > > > + lcds_node =3D of_find_node_by_path("/lcds"); > > > + for_each_child_of_node(lcds_node, child) { > > > + panel =3D of_drm_find_panel(child); > > > + if (!IS_ERR(panel)) { > > > + dsi->panel =3D panel; > > > + return 0; > > > + } > > > + } > > > > That's not part of your binding > Ok, i will remove it. > > > > > + > > > + /* > > > + * If /lcds child node search failed, we search > > > + * the child of dsi host node. > > > + */ > > > + for_each_child_of_node(dev->of_node, child) { > > > + panel =3D of_drm_find_panel(child); > > > + if (!IS_ERR(panel)) { > > > + dsi->panel =3D panel; > > > + return 0; > > > + } > > > + } > > > > And you don't need this either. You'll register a mipi_dsi_host, > > that will in turn probe all the devices under that bus, and will > > then call the .attach callback. > > This should be move to the .attach callback? The panel pointer assignment can. The rest is useless. > > > + drm_err(dsi->drm, "of_drm_find_panel() failed\n"); > > > + return -ENODEV; > > > +} > > > + > > > +static int sprd_dsi_host_attach(struct mipi_dsi_host *host, > > > + struct mipi_dsi_device *slave) > > > +{ > > > + struct sprd_dsi *dsi =3D host_to_dsi(host); > > > + struct dsi_context *ctx =3D &dsi->ctx; > > > + int ret; > > > + > > > + dsi->slave =3D slave; > > > + ctx->lanes =3D slave->lanes; > > > + ctx->format =3D slave->format; > > > + ctx->byte_clk =3D slave->hs_rate / 8; > > > + ctx->esc_clk =3D slave->lp_rate; > > > + > > > + if (slave->mode_flags & MIPI_DSI_MODE_VIDEO) > > > + ctx->work_mode =3D DSI_MODE_VIDEO; > > > + else > > > + ctx->work_mode =3D DSI_MODE_CMD; > > > + > > > + if (slave->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) > > > + ctx->burst_mode =3D VIDEO_BURST_WITH_SYNC_PULSES; > > > + else if (slave->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE) > > > + ctx->burst_mode =3D VIDEO_NON_BURST_WITH_SYNC_PULSES; > > > + else > > > + ctx->burst_mode =3D VIDEO_NON_BURST_WITH_SYNC_EVENTS; > > > + > > > + if (slave->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) > > > + ctx->nc_clk_en =3D true; > > > > I'm not sure why you need to duplicate all this, can't you just > > dereference the dsi->slave pointer when you need it? > > Sorry, can you help me with a demo? In your sprd_dsi_encoder_enable function, you call sprd_dphy_init which takes a pointer to struct dsi_context, and will call, say, dsi_phy_datalane_en, using ctx->lanes. Since you have access to the struct sprd_dsi in sprd_dsi_encoder_enable, why not pass it and the mipi_dsi_device pointer to sprd_dphy_init, and dereference slave->lanes in dsi_phy_datalane_en? This will greatly reduce the size of the dsi_context structure. > > > +static enum drm_mode_status > > > +sprd_dsi_connector_mode_valid(struct drm_connector *connector, > > > + struct drm_display_mode *mode) > > > +{ > > > + struct sprd_dsi *dsi =3D connector_to_dsi(connector); > > > + > > > + drm_dbg(dsi->drm, "%s() mode: "DRM_MODE_FMT"\n", __func__, DRM_= MODE_ARG(mode)); > > > + > > > + if (mode->type & DRM_MODE_TYPE_PREFERRED) { > > > + dsi->mode =3D mode; > > > + drm_display_mode_to_videomode(dsi->mode, &dsi->ctx.vm); > > > + } > > > > Again, what happens if the mode isn't the preferred one? > > We hope to restore the low-resolution image to the original resolution > through the scaling algorithm while keeping the resolution unchanged. > So whether it's dpu or dsi, must be keeping on preferred mode. Is there any particular reason to do so? Why do you need to take the preferred mode into account in the first place? Can't you just use whatever drm_display_mode is being passed? Maxime --cu37uqlsbtggd2ix Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYKPNSwAKCRDj7w1vZxhR xTkyAQDlju0M602qpVt5QqMkP/mXG96XFA7wwVjdRUi6ftdYuQEAwB33bO0dbA4k Q8V37uwQo+IwBHQ+nx9rFtITgynxIQI= =VvI9 -----END PGP SIGNATURE----- --cu37uqlsbtggd2ix-- 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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 E9B9AC433B4 for ; Tue, 18 May 2021 14:21:06 +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 ABEA9611BF for ; Tue, 18 May 2021 14:21:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ABEA9611BF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech 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 0665D6EB8A; Tue, 18 May 2021 14:21:06 +0000 (UTC) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by gabe.freedesktop.org (Postfix) with ESMTPS id 152766EB8A for ; Tue, 18 May 2021 14:21:04 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id E39BD5808BA; Tue, 18 May 2021 10:21:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 18 May 2021 10:21:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=lWIf1SAehz/MyS6HAHHwUIo8Dvl Qutv5w9WI0Lg2kmc=; b=QyeF9DW43KQ36ukC1peXzYdFHKFadkwOb71yOYJ5vQ3 XzEI/11psIyt7lFlcUS9WqqsScu9y3NBOBtIWYc8dK6X+200V9gyoVCGi3izOSlV v5u+2oZIHRBbiiun/WSYVTGrnNFmHU7zovAlfMXN3oPuTJhh/Det7j72KUQJCf6a qbZv3YEXR4q9LMPSpJULtcu2wHZ0roQo63vfUJDhxpiQAoO68ouvwF9WB1m8byFB CwqpI1O9pyzsNAx7PABdRP1+tJISqN18Xb8WaANhCdHeA8SGQfzN1iHkJHlY7Fna JxlJ44bcoJYbZ8y3ZfCDrDqF94aMr3lWeTnJJLyzTqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=lWIf1S Aehz/MyS6HAHHwUIo8DvlQutv5w9WI0Lg2kmc=; b=pdPTvbnCm9SvLC0OtOXzuX 2qPtSnDcqScMIbae9z9LQq3wgIy2dSsh4l0nPZjw0XSzg27K4d4iRngCex5n547J YxH1s8HfTqpL/phEqd+1Zanevc4EF2DXt6XULfh4eCv9UYYB2OCGRVuvmARCzsbz Yl5Fo8aBTCRYGpheqT0h4c8RM+LfZ1TVnF7VAYJ9JxKUJG3gaBbw8yEKBeBHww69 NinBnXeGnn9A/b+jHPT0woriamANA+n9VU6AfnKFI7DPiSdWmllVZ1g4LNB/Bfci bpUhZHeOd23nc8IlALdZmwrnnoEKq68mmGE/Fr4OBrsBMu+vRRxwZ1icAs8qwTYg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeijedgjeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepuedtgfejueduheevgfevvdettdduleffgfffkeeltdffkeegudekjeeuveei gedunecukfhppeeltddrkeelrdeikedrjeeinecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 18 May 2021 10:21:02 -0400 (EDT) Date: Tue, 18 May 2021 16:20:59 +0200 From: Maxime Ripard To: Kevin Tang Subject: Re: [PATCH v5 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver Message-ID: <20210518142059.o7ql6de4src53y4l@gilmour> References: <20210425123607.26537-1-kevin3.tang@gmail.com> <20210425123607.26537-7-kevin3.tang@gmail.com> <20210430093503.aupvt2qkrzkzy2ed@gilmour> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cu37uqlsbtggd2ix" Content-Disposition: inline In-Reply-To: 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: Mark Rutland , devicetree@vger.kernel.org, David Airlie , Chunyan Zhang , "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , Rob Herring , Orson Zhai , Sean Paul Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --cu37uqlsbtggd2ix Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 12, 2021 at 09:53:06PM +0800, Kevin Tang wrote: > > > +struct dsi_reg { > > > + union _0x00 { > > > + u32 val; > > > + struct _DSI_VERSION { > > > + u32 dsi_version: 16; > > > + u32 reserved: 16; > > > + } bits; > > > + } DSI_VERSION; > > > > Using unions and structures to define the register is really frowned > > upon in favor of defines, like you rightfully did in the crtc driver. > > This workload is too big, this design has been used for many years, > so I actually want to keep it the same, but if it really doesn=E2=80=99t = meet > the current design. > > I can change the design, but it may take a lot of time...... There's no rush :) > > > +static int sprd_dsi_find_panel(struct sprd_dsi *dsi) > > > +{ > > > + struct device *dev =3D dsi->host.dev; > > > + struct device_node *child, *lcds_node; > > > + struct drm_panel *panel; > > > + > > > + /* search /lcds child node first */ > > > + lcds_node =3D of_find_node_by_path("/lcds"); > > > + for_each_child_of_node(lcds_node, child) { > > > + panel =3D of_drm_find_panel(child); > > > + if (!IS_ERR(panel)) { > > > + dsi->panel =3D panel; > > > + return 0; > > > + } > > > + } > > > > That's not part of your binding > Ok, i will remove it. > > > > > + > > > + /* > > > + * If /lcds child node search failed, we search > > > + * the child of dsi host node. > > > + */ > > > + for_each_child_of_node(dev->of_node, child) { > > > + panel =3D of_drm_find_panel(child); > > > + if (!IS_ERR(panel)) { > > > + dsi->panel =3D panel; > > > + return 0; > > > + } > > > + } > > > > And you don't need this either. You'll register a mipi_dsi_host, > > that will in turn probe all the devices under that bus, and will > > then call the .attach callback. > > This should be move to the .attach callback? The panel pointer assignment can. The rest is useless. > > > + drm_err(dsi->drm, "of_drm_find_panel() failed\n"); > > > + return -ENODEV; > > > +} > > > + > > > +static int sprd_dsi_host_attach(struct mipi_dsi_host *host, > > > + struct mipi_dsi_device *slave) > > > +{ > > > + struct sprd_dsi *dsi =3D host_to_dsi(host); > > > + struct dsi_context *ctx =3D &dsi->ctx; > > > + int ret; > > > + > > > + dsi->slave =3D slave; > > > + ctx->lanes =3D slave->lanes; > > > + ctx->format =3D slave->format; > > > + ctx->byte_clk =3D slave->hs_rate / 8; > > > + ctx->esc_clk =3D slave->lp_rate; > > > + > > > + if (slave->mode_flags & MIPI_DSI_MODE_VIDEO) > > > + ctx->work_mode =3D DSI_MODE_VIDEO; > > > + else > > > + ctx->work_mode =3D DSI_MODE_CMD; > > > + > > > + if (slave->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) > > > + ctx->burst_mode =3D VIDEO_BURST_WITH_SYNC_PULSES; > > > + else if (slave->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE) > > > + ctx->burst_mode =3D VIDEO_NON_BURST_WITH_SYNC_PULSES; > > > + else > > > + ctx->burst_mode =3D VIDEO_NON_BURST_WITH_SYNC_EVENTS; > > > + > > > + if (slave->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) > > > + ctx->nc_clk_en =3D true; > > > > I'm not sure why you need to duplicate all this, can't you just > > dereference the dsi->slave pointer when you need it? > > Sorry, can you help me with a demo? In your sprd_dsi_encoder_enable function, you call sprd_dphy_init which takes a pointer to struct dsi_context, and will call, say, dsi_phy_datalane_en, using ctx->lanes. Since you have access to the struct sprd_dsi in sprd_dsi_encoder_enable, why not pass it and the mipi_dsi_device pointer to sprd_dphy_init, and dereference slave->lanes in dsi_phy_datalane_en? This will greatly reduce the size of the dsi_context structure. > > > +static enum drm_mode_status > > > +sprd_dsi_connector_mode_valid(struct drm_connector *connector, > > > + struct drm_display_mode *mode) > > > +{ > > > + struct sprd_dsi *dsi =3D connector_to_dsi(connector); > > > + > > > + drm_dbg(dsi->drm, "%s() mode: "DRM_MODE_FMT"\n", __func__, DRM_= MODE_ARG(mode)); > > > + > > > + if (mode->type & DRM_MODE_TYPE_PREFERRED) { > > > + dsi->mode =3D mode; > > > + drm_display_mode_to_videomode(dsi->mode, &dsi->ctx.vm); > > > + } > > > > Again, what happens if the mode isn't the preferred one? > > We hope to restore the low-resolution image to the original resolution > through the scaling algorithm while keeping the resolution unchanged. > So whether it's dpu or dsi, must be keeping on preferred mode. Is there any particular reason to do so? Why do you need to take the preferred mode into account in the first place? Can't you just use whatever drm_display_mode is being passed? Maxime --cu37uqlsbtggd2ix Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYKPNSwAKCRDj7w1vZxhR xTkyAQDlju0M602qpVt5QqMkP/mXG96XFA7wwVjdRUi6ftdYuQEAwB33bO0dbA4k Q8V37uwQo+IwBHQ+nx9rFtITgynxIQI= =VvI9 -----END PGP SIGNATURE----- --cu37uqlsbtggd2ix--