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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B7072C64990 for ; Thu, 25 Aug 2022 13:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=IPAw3pYXENhe40csqiqNZ843WtKsIqjRDPa2+2gtZY8=; b=yQlTiQQk1xB1v7gdHw1WlJY18/ DluaW204wPUC+4WPUFXXsxuhuTxloByNCgi/gMu7arHrX22bM/TM12h12PcRsQqOm4W6mts/I/L1H E1QBGsB4q2kbLAeGHDSHDngzup2CmUZrndn4Z4OE40CH8sMNjcChFwB59omxRkYN/DJ7IwYQJp3Rb F9iDojP8xjHGprEZbSCsoDK/0Yt4bDlLTE1b8bAF4myz3iSUwXh/8DcymsKHYm0aboTJaUwSeVaB1 rVKC04bRX90HBzMq4oVcjx8tQpAp6K+iFgHEWLWMD0SvHc57xPuMd4WOqkZwopGhx05z5LDFRm1U4 8xS2h93g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oRD5N-00EvC7-0V; Thu, 25 Aug 2022 13:39:53 +0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oRD5H-00Ev3G-9p; Thu, 25 Aug 2022 13:39:49 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id F18DC5802D2; Thu, 25 Aug 2022 09:39:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 25 Aug 2022 09:39:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1661434781; x=1661441981; bh=xufXNQfWsW 5YMPwr77PxDXziEf7hBPLQzvXQIo3+2+Y=; b=KRY3ZJmLUrz8S7afTCwjV+6oVP hTtlebvUk7hjY/8s8PwqdJ3R9Z0EwogT5IbBAVEgOBSZdEtrSbrxTFN7gEX61ztq cidK+o2bTLG8i+LOdAXUqS1tE4UryHbuz7CY1fbrzvsuPUUomb5r1A6txmAcTMpW dWs/kEzOME+WWG3iOdu/czo1E7VQBI0qFo5hTRu9UBxucz43OTruG8RdlfPshahK fsPYnLq/KywCkzc9uQgpaQxoFy5bDDDUOeTEipfnBiFLR4EXkGr2YTU4v/7UBKXG U6S9ryjKeoVFgO2SKJbMuuVo7c3bXNgvxwVvGAw5Ly9kTCz1DWnyeEycm7ag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1661434781; x=1661441981; bh=xufXNQfWsW5YMPwr77PxDXziEf7h BPLQzvXQIo3+2+Y=; b=RZH4Z4XZhMW0HQ0yV+K9lv2Xk6n+odMvjRg4xiem1unP y44V2lmeJSbc3J3Yf/Z58mYGcwKGkz/x4S0mRomdYq+JMe0Klp6+OpSo0D5oWp2g yQBPMbNY+RMZRW1tyrMPJp4zn+JFk4xCfVCdZVQMLnj0zMjU881wkyt0XZbxtxoM Sord2tDZWNYw4fXxTms0I7824hrZwosPGAWDWMDy+CU6/PRuutKgEcAMD5yU+pwR gq41cv3QRCbf+fp64eaTAAk32G7yPKeAyTtApBqz5HJWboB/D/pnpALfx4V6lIz2 zItw1gBXht3MnRipo0H1OztZu77gosZPc9GL6fkmIA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdejfedgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpedtleekjeeiudefvdfhieffteelhfeivdeliefgieeugffhvdelieffjeei geetjeenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggt hh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 25 Aug 2022 09:39:39 -0400 (EDT) Date: Thu, 25 Aug 2022 15:39:36 +0200 From: Maxime Ripard To: Geert Uytterhoeven Cc: Jernej Skrabec , Martin Blumenstingl , Chen-Yu Tsai , Philipp Zabel , Jerome Brunet , Samuel Holland , Thomas Zimmermann , Daniel Vetter , Emma Anholt , David Airlie , Maarten Lankhorst , Noralf =?utf-8?Q?Tr=C3=B8nnes?= , Kevin Hilman , Neil Armstrong , linux-sunxi@lists.linux.dev, Linux Kernel Mailing List , Phil Elwell , Mateusz Kwiatkowski , Linux ARM , Dave Stevenson , "open list:ARM/Amlogic Meson..." , DRI Development , Dom Cobley Subject: Re: [PATCH v1 05/35] drm/connector: Add TV standard property Message-ID: <20220825133936.gnpgdtx4jedei5a6@houat> References: <20220817074710.w4c4xwj7edly2b5p@houat> <20220817111454.pn2iltvyo2drebq7@houat> <20220817131854.jwmhqvhfhp77bbr3@houat> <20220818145436.vqojnhmvhjxdzooe@houat> <20220818153442.u4knumkfbe7j6zj3@houat> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220825_063947_903056_6785885E X-CRM114-Status: GOOD ( 45.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5821383451897391949==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============5821383451897391949== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="abetw7tfzbu2b4iz" Content-Disposition: inline --abetw7tfzbu2b4iz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Aug 19, 2022 at 11:35:42AM +0200, Geert Uytterhoeven wrote: > On Thu, Aug 18, 2022 at 5:34 PM Maxime Ripard wrote: > > On Thu, Aug 18, 2022 at 05:20:42PM +0200, Geert Uytterhoeven wrote: > > > On Thu, Aug 18, 2022 at 4:54 PM Maxime Ripard wro= te: > > > > On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote: > > > > > On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard = wrote: > > > > > > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wr= ote: > > > > > > > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wrote: > > > > > > > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeve= n wrote: > > > > > > > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard wrote: > > > > > > > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterh= oeven wrote: > > > > > > > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote: > > > > > > > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uyt= terhoeven wrote: > > > > > > > > > > > > > > > > > Either you have to add them here (e.g. "h= d720p50" and "hd720p60"), or > > > > > > > > > > > > > > > > > handle them through "@". The la= tter would impact "[PATCH v1 > > > > > > > > > > > > > > > > > 09/35] drm/modes: Move named modes parsin= g to a separate function", as > > > > > > > > > > > > > > > > > currently a named mode and a refresh rate= can't be specified both. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think the former would make more sense. I= t simplifies a bit the > > > > > > > > > > > > > > > > parser, and we're going to use a named mode= anyway. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce= the tv_mode property as a > > > > > > > > > > > > > > > > > command-line option" uses a separate "tv_= mode" option, and not the main > > > > > > > > > > > > > > > > > mode name, I think you want to add them h= ere. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It's a separate story I think, we could hav= e a named mode hd720p50, > > > > > > > > > > > > > > > > which would be equivalent to 1280x720,tv_mo= de=3Dhd720p > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So where's the field rate in "1280x720,tv_mod= e=3Dhd720p"? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=3Dhd720p > > > > > > > > > > > > > > > > > > > > > > > > > > Above you said "I think the former would make mor= e sense", so that > > > > > > > > > > > > > should be "1280x720,tv_mode=3Dhd720p50"? > > > > > > > > > > > > > > > > > > > > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x7= 20@50,tv_mode=3Dhd720p > > > > > > > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode= =3Dhd720p > > > > > > > > > > > > > > > > > > > > > > I disagree: hd720p50 and hd720p60 are different TV mo= des. > > > > > > > > > > > > > > > > > > > > I agree, and I don't see how that command-line doesn't = express that? > > > > > > > > > > > > > > > > > > Oh, I see what you mean: yes, it expresses that. > > > > > > > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576= }[ip] modes, > > > > > > > > > where the TV mode specifies both number of lines and fram= e rate. > > > > > > > > > > > > > > > > Only if we're using a named mode, and naming is hard :) > > > > > > > > > > > > > > That's not true: "640x480,tv_mode=3DPAL-N" would give me a mo= de with > > > > > > > 625 lines and 25 frames/s, "640x480,tv_mode=3DPAL-M" would gi= ve me a > > > > > > > mode with 525 lines and 30 frames/s. > > > > > > > > > > > > In that series, "640x480,tv_mode=3DPAL-N" would be rejected as = invalid: > > > > > > > > > > > > https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-proper= ties-v1-14-3d53ae722097@cerno.tech/ > > > > > > > > > > It would become supported once the ideas from thread "[PATCH v1 0= 4/35] > > > > > drm/modes: Introduce 480i and 576i modes" are implemented... > > > > > > > > Indeed, but I'm still not sure what your concern is here. > > > > "640x480,tv_mode=3DPAL-N" and "640x480,tv_mode=3DPAL-M" are both fa= irly > > > > obvious. > > > > > > > > You were initially saying that you had concern over the inconsisten= cy of > > > > NTSC/PAL/SECAM where the TV mode would specify a number of lines and > > > > frame rate, but hd720p50 also specifies a number of line and frame = rate? > > > > > > My concern is that you want to call the TV mode "hd720p", which > > > does not dictate the frame rate. > > > I would like to have both "720p50" and "720p60", as they do dictate > > > the frame rate, like all the non-hd modes. > > > > But they don't? > > > > The refresh rate is part of the drm_display_mode, whereas that property > > is metadata and entirely separate from the display mode. > > > > You can even change it without changing the mode at all >=20 > Yes, the refresh rate is part of drm_display_mode. Vdisplay also > is, but that doesn't mean you can set it to e.g. 700 when using > "tv_mode=3DPAL-B". Some (combination of) parameters in drm_display_mode > are dictated by the tv_mode. But the opposite is also true: PAL-B and SECAM-B would be two different TV mode, but (could) have the same display mode. There's no equivalence or implication in that relationship, except for a smaller set of those parameters. But it's the entire display mode that we should compare. > Perhaps the meaning of "tv_mode" should be clarified? What does it > really mean, and what parameters does it (not) constrain? As far as I'm concerned, it's only about the encoding. We can check after the fact that, say, you don't try to use a mode line with than 525 lines and some NTSC variant, but the mode has precedence over the property. > For e.g. "PAL-B", I know it's a mode with 625 lines and 30 frames/s > (60 fields/s). > For "hd720p" I know it is an analog mode with 750 lines, but it's still > ambiguous, as I don't know if it is the variant with 60 or 50 frames/s. As far as the TV mode property is concerned, it doesn't encode neither whether it has 750 lines, nor the refresh rate. If you're talking about a named mode, then yeah, it's basically an alias for a mode + a property, so it does, but we can choose names that aren't ambiguous. Maxime --abetw7tfzbu2b4iz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYwd7mAAKCRDj7w1vZxhR xZkBAQDrEXnDTiQIDw7WVDdGrymHTzA68O6aoUE0nXlp+5E0EAEAzwBa5cUcNh9j iMwk3ETvnvqMbV5kyg5f+gPHMuMLswM= =NZmB -----END PGP SIGNATURE----- --abetw7tfzbu2b4iz-- --===============5821383451897391949== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============5821383451897391949==--