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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 909B6C433F5 for ; Mon, 8 Nov 2021 15:58:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6FF5361178 for ; Mon, 8 Nov 2021 15:58:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241111AbhKHQBX (ORCPT ); Mon, 8 Nov 2021 11:01:23 -0500 Received: from new4-smtp.messagingengine.com ([66.111.4.230]:32919 "EHLO new4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239202AbhKHQBW (ORCPT ); Mon, 8 Nov 2021 11:01:22 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id D491D58079C; Mon, 8 Nov 2021 10:58:37 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 08 Nov 2021 10:58:37 -0500 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=fm1; bh=GDGBKLqsXucgJZv4oQj5QE89wMt W+wTyGvv0GI+MQ18=; b=cNFW3T8QTDTcwFKSUJTTabtY0ynmIQFuznxeO1WXlFV nwtPMasTYLWRFRVlJqyFWfZRrzDJk7w3RtuuB+j4Gq/RYABSOHML+zhivtpTO3Q7 kW/K9lNHDghyFsz/KUQTpb3/rfWc6GKJ5XFv+SIDxSowgh6xsimRhLXyZaqW8bMd tzV+dRUfFTeWA8Lcl3Whsh1PN2sqHauADBzuFw0B5vDZe33z9hVrsvW68GKzjHH7 /7X1yWRBgRw/wcU71wWmw3UIusw1ia7V0FK5B59IMy8IM3+ietGBZUcXttviUmfs v81JI9vciRT3ExjD4OzWnJsIANGD0FwbBMplTlXt5RQ== 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=fm1; bh=GDGBKL qsXucgJZv4oQj5QE89wMtW+wTyGvv0GI+MQ18=; b=NkeqNIi7j8NIhjl56GOWHP jOu7vHwsYsRPOApzDR8DD56iq1wS4MmKa6YMpV18KW+9sm7ApIh3Gj10BFmj0kUP oHEkNjv5rEDxQYmkkm9a9Pk/kSWWWkZmVLuMAO+M34iibt6+72e05I8uXFUXH/NJ srjJn6hNW6MT7DkHTpgfBorpvS2+OKc1avge2NbiMurjUOiMkDTlQ6IHlseE3hZY iVwITwt/S9VYkwvgZK+bUI52HuF4H2EMRPB27UsVcWxaM10wZiZ2bRtbOW6yGrYr gHSg5IXLX+IFLvt/mvWiarjSHGpLkBGBuUu0AB6JtvHrnPA+NKRzrfoBChtWLA4A == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvgdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtudenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpeduvdduhfekkeehgffftefflefgffdtheffudffgeevteffheeuiedvvdejvdfg veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrg igihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 8 Nov 2021 10:58:36 -0500 (EST) Date: Mon, 8 Nov 2021 16:58:34 +0100 From: Maxime Ripard To: Ville =?utf-8?B?U3lyasOkbMOk?= Cc: Daniel Vetter , Emma Anholt , Dom Cobley , Tim Gover , Dave Stevenson , David Airlie , dri-devel@lists.freedesktop.org, Jonathan Hunter , Thierry Reding , Thomas Zimmermann , linux-tegra@vger.kernel.org, Daniel Vetter , Phil Elwell Subject: Re: [PATCH 02/13] drm/connector: Add helper to check if a mode requires scrambling Message-ID: <20211108155834.6zz236ll75bxwcrk@gilmour> References: <20211102145944.259181-1-maxime@cerno.tech> <20211102145944.259181-3-maxime@cerno.tech> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xgtaknx57htu4h3l" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org --xgtaknx57htu4h3l Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 05, 2021 at 08:14:04PM +0200, Ville Syrj=E4l=E4 wrote: > On Fri, Nov 05, 2021 at 07:02:30PM +0100, Daniel Vetter wrote: > > On Thu, Nov 04, 2021 at 05:37:21PM +0200, Ville Syrj=E4l=E4 wrote: > > > On Tue, Nov 02, 2021 at 03:59:33PM +0100, Maxime Ripard wrote: > > > > --- a/include/drm/drm_modes.h > > > > +++ b/include/drm/drm_modes.h > > > > @@ -424,6 +424,21 @@ static inline bool drm_mode_is_stereo(const st= ruct drm_display_mode *mode) > > > > return mode->flags & DRM_MODE_FLAG_3D_MASK; > > > > } > > > > =20 > > > > +/** > > > > + * drm_mode_hdmi_requires_scrambling - Checks if a mode requires H= DMI Scrambling > > > > + * @mode: DRM display mode > > > > + * > > > > + * Checks if a given display mode requires the scrambling to be en= abled. > > > > + * > > > > + * Returns: > > > > + * A boolean stating whether it's required or not. > > > > + */ > > > > +static inline bool > > > > +drm_mode_hdmi_requires_scrambling(const struct drm_display_mode *m= ode) > > > > +{ > > > > + return mode->clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ; > > > > +} > > >=20 > > > That's only correct for 8bpc. The actual limit is on the TMDS clock (= or > > > rather TMDS character rate as HDMI 2.0 calls it due to the 1/1 vs. 1/4 > > > magic for the actually transmitted TMDS clock). > >=20 > > Yeah we might need to add the bus format for the cable here too, to make > > this complete. >=20 > I don't think we have a usable thing for that on the drm level, so > would need to invent something. Oh, and the mode->clock vs.=20 > mode->crtc_clock funny business also limits the usability of this > approach. So probably just easiest to pass in the the driver calculated > TMDS clock instead. If we look at all (I think?) the existing users of scrambling in KMS as of 5.15, only i915 seems to use crtc_clock (which, in retrospect, seems to be the right thing to do), and only i915 and dw-hdmi use an output format, i915 rolling its own, and dw-hdmi using the mbus formats. I think using the mbus format here makes the most sense: i915 already is rolling a whole bunch of other code, and we use the mbus defines for the bridge format enumeration as well which is probably going to have some interaction. I'm not quite sure what to do next though. The whole point of that series is to streamline as much as possible the scrambling and TMDS ratio setup to avoid the duplication we already have in the drivers that support it, every one using the mostly-the-same-but-slightly-different logic to configure it. The mode is fortunately stored in generic structures so it's easy to make that decision. Having to take into account the output format however makes it mandatory to move the bus format in the drm_connector_state(?) structure too. It's already in the bridge_state though, so should we take the final bridge format as the cable format if it's tied to a bridge? Maxime --xgtaknx57htu4h3l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYYlJKgAKCRDj7w1vZxhR xdTmAQCYyR6ooj+GVU69Oh06Ug442R0aK7g89ZBZBwxfGLt8SgEA3fw21eNOtPUv orlcPTbMxfPcjs2s5i12xUsUgWY+vww= =bsEq -----END PGP SIGNATURE----- --xgtaknx57htu4h3l-- 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BBCCC433F5 for ; Mon, 8 Nov 2021 15:58:41 +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 3232861186 for ; Mon, 8 Nov 2021 15:58:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3232861186 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2F1996E1A7; Mon, 8 Nov 2021 15:58:40 +0000 (UTC) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by gabe.freedesktop.org (Postfix) with ESMTPS id B248A6E1A7 for ; Mon, 8 Nov 2021 15:58:38 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id D491D58079C; Mon, 8 Nov 2021 10:58:37 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 08 Nov 2021 10:58:37 -0500 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=fm1; bh=GDGBKLqsXucgJZv4oQj5QE89wMt W+wTyGvv0GI+MQ18=; b=cNFW3T8QTDTcwFKSUJTTabtY0ynmIQFuznxeO1WXlFV nwtPMasTYLWRFRVlJqyFWfZRrzDJk7w3RtuuB+j4Gq/RYABSOHML+zhivtpTO3Q7 kW/K9lNHDghyFsz/KUQTpb3/rfWc6GKJ5XFv+SIDxSowgh6xsimRhLXyZaqW8bMd tzV+dRUfFTeWA8Lcl3Whsh1PN2sqHauADBzuFw0B5vDZe33z9hVrsvW68GKzjHH7 /7X1yWRBgRw/wcU71wWmw3UIusw1ia7V0FK5B59IMy8IM3+ietGBZUcXttviUmfs v81JI9vciRT3ExjD4OzWnJsIANGD0FwbBMplTlXt5RQ== 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=fm1; bh=GDGBKL qsXucgJZv4oQj5QE89wMtW+wTyGvv0GI+MQ18=; b=NkeqNIi7j8NIhjl56GOWHP jOu7vHwsYsRPOApzDR8DD56iq1wS4MmKa6YMpV18KW+9sm7ApIh3Gj10BFmj0kUP oHEkNjv5rEDxQYmkkm9a9Pk/kSWWWkZmVLuMAO+M34iibt6+72e05I8uXFUXH/NJ srjJn6hNW6MT7DkHTpgfBorpvS2+OKc1avge2NbiMurjUOiMkDTlQ6IHlseE3hZY iVwITwt/S9VYkwvgZK+bUI52HuF4H2EMRPB27UsVcWxaM10wZiZ2bRtbOW6yGrYr gHSg5IXLX+IFLvt/mvWiarjSHGpLkBGBuUu0AB6JtvHrnPA+NKRzrfoBChtWLA4A == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvgdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtudenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpeduvdduhfekkeehgffftefflefgffdtheffudffgeevteffheeuiedvvdejvdfg veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrg igihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 8 Nov 2021 10:58:36 -0500 (EST) Date: Mon, 8 Nov 2021 16:58:34 +0100 From: Maxime Ripard To: Ville =?utf-8?B?U3lyasOkbMOk?= Subject: Re: [PATCH 02/13] drm/connector: Add helper to check if a mode requires scrambling Message-ID: <20211108155834.6zz236ll75bxwcrk@gilmour> References: <20211102145944.259181-1-maxime@cerno.tech> <20211102145944.259181-3-maxime@cerno.tech> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xgtaknx57htu4h3l" 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: Emma Anholt , Tim Gover , Dave Stevenson , David Airlie , Thomas Zimmermann , dri-devel@lists.freedesktop.org, Jonathan Hunter , Thierry Reding , linux-tegra@vger.kernel.org, Daniel Vetter , Phil Elwell , Dom Cobley Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --xgtaknx57htu4h3l Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 05, 2021 at 08:14:04PM +0200, Ville Syrj=E4l=E4 wrote: > On Fri, Nov 05, 2021 at 07:02:30PM +0100, Daniel Vetter wrote: > > On Thu, Nov 04, 2021 at 05:37:21PM +0200, Ville Syrj=E4l=E4 wrote: > > > On Tue, Nov 02, 2021 at 03:59:33PM +0100, Maxime Ripard wrote: > > > > --- a/include/drm/drm_modes.h > > > > +++ b/include/drm/drm_modes.h > > > > @@ -424,6 +424,21 @@ static inline bool drm_mode_is_stereo(const st= ruct drm_display_mode *mode) > > > > return mode->flags & DRM_MODE_FLAG_3D_MASK; > > > > } > > > > =20 > > > > +/** > > > > + * drm_mode_hdmi_requires_scrambling - Checks if a mode requires H= DMI Scrambling > > > > + * @mode: DRM display mode > > > > + * > > > > + * Checks if a given display mode requires the scrambling to be en= abled. > > > > + * > > > > + * Returns: > > > > + * A boolean stating whether it's required or not. > > > > + */ > > > > +static inline bool > > > > +drm_mode_hdmi_requires_scrambling(const struct drm_display_mode *m= ode) > > > > +{ > > > > + return mode->clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ; > > > > +} > > >=20 > > > That's only correct for 8bpc. The actual limit is on the TMDS clock (= or > > > rather TMDS character rate as HDMI 2.0 calls it due to the 1/1 vs. 1/4 > > > magic for the actually transmitted TMDS clock). > >=20 > > Yeah we might need to add the bus format for the cable here too, to make > > this complete. >=20 > I don't think we have a usable thing for that on the drm level, so > would need to invent something. Oh, and the mode->clock vs.=20 > mode->crtc_clock funny business also limits the usability of this > approach. So probably just easiest to pass in the the driver calculated > TMDS clock instead. If we look at all (I think?) the existing users of scrambling in KMS as of 5.15, only i915 seems to use crtc_clock (which, in retrospect, seems to be the right thing to do), and only i915 and dw-hdmi use an output format, i915 rolling its own, and dw-hdmi using the mbus formats. I think using the mbus format here makes the most sense: i915 already is rolling a whole bunch of other code, and we use the mbus defines for the bridge format enumeration as well which is probably going to have some interaction. I'm not quite sure what to do next though. The whole point of that series is to streamline as much as possible the scrambling and TMDS ratio setup to avoid the duplication we already have in the drivers that support it, every one using the mostly-the-same-but-slightly-different logic to configure it. The mode is fortunately stored in generic structures so it's easy to make that decision. Having to take into account the output format however makes it mandatory to move the bus format in the drm_connector_state(?) structure too. It's already in the bridge_state though, so should we take the final bridge format as the cable format if it's tied to a bridge? Maxime --xgtaknx57htu4h3l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYYlJKgAKCRDj7w1vZxhR xdTmAQCYyR6ooj+GVU69Oh06Ug442R0aK7g89ZBZBwxfGLt8SgEA3fw21eNOtPUv orlcPTbMxfPcjs2s5i12xUsUgWY+vww= =bsEq -----END PGP SIGNATURE----- --xgtaknx57htu4h3l--