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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 75280C6FA83 for ; Mon, 12 Sep 2022 13:38:40 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CA60110E4CB; Mon, 12 Sep 2022 13:38:14 +0000 (UTC) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by gabe.freedesktop.org (Postfix) with ESMTPS id D4D6E10E3AE; Sun, 11 Sep 2022 04:32:51 +0000 (UTC) Received: by mail-lf1-x133.google.com with SMTP id w8so9556885lft.12; Sat, 10 Sep 2022 21:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date; bh=eJ5+kSvRGx0e5DL23FMmsR32sATG84wn3pUtXfVNfJk=; b=UzwIqo7BotutKHABezU/5M4r1hFosIJShwkvIMqCyzl5TtN9VYDKXW7hFWomPhiGph Ym1yfhdW374PMwpW1PzT0+GQxyoj0se63YjLGw94N2hSZLa/vT+gtWArl6kk26PLdEw2 +SlenG2reH47juH0ULuJ70Gf02WSKtrR2KLFtjVbQ9twzPi2bgcpBZrX3OjcKYn0lwXZ 2IqDSdbK+ycclzRuVBZeW7CMnb3SVXqXzqSEH4jsllcB7PexwSKS4xCFyxDhhOsLsJgl RZ8+FTf+kdXOxVD/qjINJ/6P+5NUSOLgod5Ro4JMwXgX7O14od0BP7D0sF5hZAfjpql+ bhKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=eJ5+kSvRGx0e5DL23FMmsR32sATG84wn3pUtXfVNfJk=; b=rL0vQoyfPOBsTiILRRlJJH0qk7A4FtPuHI3Drvzl6aky+6ciQJAvtdG7OrcPazFezl bk08wnIY+1yi0ZU915gcifC2o/GftNAR6wCYdEJv6uI5z+BWdgOXtt7BIVqOasnwe8oP bU7Y41xyV/3xEuEEWkdrDRTVZg3bLk9yuU+8NV8F4mGDczus7tIZQY50Or1fBAINgfhd 3KJUxSJ564podYY9WElTxn5i0xCNheneIuXYHMQ/Ho4RPZxe23/MC5s1e7b4C3n1ZQEu LGq16NJzhiPZEUDhYIqcWJnjMpLOHNm+l8X1JQcmL0SkQHV1ZsdcGLzrhm6V52hNNTMs yWyA== X-Gm-Message-State: ACgBeo2+LUvrei1jQOabnv3IXAmN1NmUVPJmpNsu/v0PDUs6hzr9Sgyy XvLi/ScVqKCZmgYMrVwTsPY= X-Google-Smtp-Source: AA6agR5M1zbvVnaz19qs5aPClS3RbrwZxmnw+bU2659kQnERb5o7G/3kodQNdYL47ha1OqfWKOi8Kw== X-Received: by 2002:a05:6512:308d:b0:499:bd1a:d1bc with SMTP id z13-20020a056512308d00b00499bd1ad1bcmr1536967lfd.274.1662870770059; Sat, 10 Sep 2022 21:32:50 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:e929:c054:a46d:3844? ([2a02:a31a:a240:1700:e929:c054:a46d:3844]) by smtp.googlemail.com with ESMTPSA id a17-20020a2eb551000000b00261a8e56fe4sm539994ljn.55.2022.09.10.21.32.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Sep 2022 21:32:49 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: Date: Sun, 11 Sep 2022 06:32:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Content-Language: pl To: Maxime Ripard References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> <30a9d7cd-d9ff-3177-ac6c-e7c1f966d89a@gmail.com> <20220907121009.toizfolruuazcrns@houat> <6639fb8f-e16c-1ef5-5978-c522f76c8ded@gmail.com> <20220909094647.aahohiwtwbbeyzj3@houat> In-Reply-To: <20220909094647.aahohiwtwbbeyzj3@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 12 Sep 2022 13:38:08 +0000 Subject: Re: [Intel-gfx] [PATCH v2 09/41] drm/connector: Add TV standard property X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Karol Herbst , David Airlie , nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Phil Elwell , Emma Anholt , Samuel Holland , Jernej Skrabec , Chen-Yu Tsai , Geert Uytterhoeven , Ben Skeggs , linux-sunxi@lists.linux.dev, Thomas Zimmermann , intel-gfx@lists.freedesktop.org, Rodrigo Vivi , Daniel Vetter , linux-arm-kernel@lists.infradead.org, Dom Cobley , Dave Stevenson , linux-kernel@vger.kernel.org, =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , Philipp Zabel Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" W dniu 9.09.2022 o 11:46, Maxime Ripard pisze: > On Wed, Sep 07, 2022 at 09:52:09PM +0200, Mateusz Kwiatkowski wrote: >> W dniu 7.09.2022 o 14:10, Maxime Ripard pisze: >>> Hi, >>> >>> On Fri, Sep 02, 2022 at 12:00:33AM +0200, Mateusz Kwiatkowski wrote: >>>> W dniu 29.08.2022 o 15:11, Maxime Ripard pisze: >>>>> The TV mode property has been around for a while now to select and get the >>>>> current TV mode output on an analog TV connector. >>>>> >>>>> Despite that property name being generic, its content isn't and has been >>>>> driver-specific which makes it hard to build any generic behaviour on top >>>>> of it, both in kernel and user-space. >>>>> >>>>> Let's create a new bitmask tv norm property, that can contain any of the >>>>> analog TV standards currently supported by kernel drivers. Each driver can >>>>> then pass in a bitmask of the modes it supports. >>>> >>>> This is not a bitmask property anymore, you've just changed it to an enum. >>>> The commit message is now misleading. >>>> >>>>> +static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = { >>>>> +    { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" }, >>>>> +    { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" }, >>>>> +    { DRM_MODE_TV_MODE_NTSC_M, "NTSC-M" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_60, "PAL-60" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_B, "PAL-B" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_D, "PAL-D" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_G, "PAL-G" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_H, "PAL-H" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_I, "PAL-I" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_M, "PAL-M" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_N, "PAL-N" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_NC, "PAL-Nc" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_60, "SECAM-60" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_B, "SECAM-B" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_D, "SECAM-D" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_G, "SECAM-G" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_K, "SECAM-K" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_K1, "SECAM-K1" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_L, "SECAM-L" }, >>>>> +}; >>>> >>>> I did not comment on it the last time, but this list looks a little bit random. >>>> >>>> Compared to the standards defined by V4L2, you also define SECAM-60 (a good >>>> thing to define, because why not), but don't define PAL-B1, PAL-D1, PAL-K, >>>> SECAM-H, SECAM-LC (whatever that is - probably just another name for SECAM-L, >>>> see my comment about PAL-Nc below), or NTSC-M-KR (a Korean variant of NTSC). >>>> >>>> Like I mentioned previously, I'm personally not a fan of including all those >>>> CCIR/ITU system variants, as they don't mean any difference to the output unless >>>> there is an RF modulator involved. But I get it that they have already been used >>>> and regressing probably wouldn't be a very good idea. But in that case keeping >>>> it consistent with the set of values used by V4L2 would be wise, I think. >>> >>> Ack. What would be the list of standards we'd absolutely need? NSTC-M, >>> NTSC-J, PAL-60, PAL-B, PAL-M, SECAM-60 and SECAM-B? >> >> The "essential list" IMO is NTSC, NTSC-J, NTSC-443, PAL, PAL-M, PAL-N and SECAM. >> Note that: >> >> - I intentionally propose "NTSC", "PAL" and "SECAM" without an ITU system >>   designation. If we only consider composite signals, there's no difference >>   between e.g. PAL-B, PAL-D and PAL-I, so it's better to label it as a generic >>   mode, IMO. >> >>   * PAL-M and PAL-N are different, because those unique color encodings were >>     only ever used with Systems M and N, respectively. >> >>   * NTSC-J is also different, because "System J" doesn't exist anywhere in ITU >>     documents. Japan technically uses System M with a non-standard black level. >>     But "NTSC-J" stuck as a universally recognized name for that variant. >> >> - I intentionally did not list PAL-60 or SECAM-60. TBH... PAL-60 is just >>   regular PAL paired with 480i60 modeline. Most if not all displays that >>   accept PAL-60 input will just label it as "PAL". If we are not introducing >>   strict modeline validation, then maybe separating PAL and PAL-60 isn't really >>   necessary? Same goes for SECAM vs. SECAM-60. >>   >>   ...and same goes for NTSC vs. NTSC-50 a.k.a NTSC-N, which is a very exotic >>   mode, but known to exist at least in the Atari ST world, see also: >>   https://en.wikipedia.org/wiki/NTSC#NTSC-N/NTSC50 >> >> Combining PAL and PAL-60 into a single setting would complicate the vc4 driver >> a little bit, though, as the registers need to be set up differently for those. >> >> My feelings about the PAL-60 issue are not that strong, though. Merging PAL >> and PAL-60 in this context is just a loose suggestion, I won't even try to >> argue if you disagree. > > Ack > >>>>> +/** >>>>> + * drm_mode_create_tv_properties - create TV specific connector properties >>>>> + * @dev: DRM device >>>>> + * @supported_tv_modes: Bitmask of TV modes supported (See DRM_MODE_TV_MODE_*) >>>>> + >>>>> + * Called by a driver's TV initialization routine, this function creates >>>>> + * the TV specific connector properties for a given device.  Caller is >>>>> + * responsible for allocating a list of format names and passing them to >>>>> + * this routine. >>>>> + * >>>>> + * Returns: >>>>> + * 0 on success or a negative error code on failure. >>>>> + */ >>>>> +int drm_mode_create_tv_properties(struct drm_device *dev, >>>>> +                  unsigned int supported_tv_modes) >>>> >>>> supported_tv_modes is supposed to be a bitmask of BIT(DRM_MODE_TV_MODE_*) >>>> (or (1<>>> is not said explicitly anywhere in this doc comment. >>> >>> The argument doc mentions that it's a "Bitmask of TV modes supported >>> (See DRM_MODE_TV_MODE_*)", how would you improve it? >> >> Maybe something like "Bitwise OR of BIT(DRM_MODE_TV_MODE_*) values"? Or maybe >> just add a little usage example? > > This is the way we're usually documenting it in DRM: > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_plane.c#L357 > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_crtc.c#L861 > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_blend.c#L546 > > So I'd rather keep it consistent > > Maxime Ack, OK then. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0DE877F for ; Sun, 11 Sep 2022 04:32:51 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id q21so9664890lfo.0 for ; Sat, 10 Sep 2022 21:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date; bh=eJ5+kSvRGx0e5DL23FMmsR32sATG84wn3pUtXfVNfJk=; b=UzwIqo7BotutKHABezU/5M4r1hFosIJShwkvIMqCyzl5TtN9VYDKXW7hFWomPhiGph Ym1yfhdW374PMwpW1PzT0+GQxyoj0se63YjLGw94N2hSZLa/vT+gtWArl6kk26PLdEw2 +SlenG2reH47juH0ULuJ70Gf02WSKtrR2KLFtjVbQ9twzPi2bgcpBZrX3OjcKYn0lwXZ 2IqDSdbK+ycclzRuVBZeW7CMnb3SVXqXzqSEH4jsllcB7PexwSKS4xCFyxDhhOsLsJgl RZ8+FTf+kdXOxVD/qjINJ/6P+5NUSOLgod5Ro4JMwXgX7O14od0BP7D0sF5hZAfjpql+ bhKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=eJ5+kSvRGx0e5DL23FMmsR32sATG84wn3pUtXfVNfJk=; b=l9YwEf8j8xUPw29kNckdDHMwfzv3ph9VPE6qmIjkzTYwCfPVlQFWcV3VEmuyRbfFrN TTR3SLumsPjs0XFSbB7xeJ6VV9qNI03b2pW87auMiuzg74zyblUI5CT7WmqrMg911K// XloBluvRLskXQ4bM5sHyzWniwm4E5l20fYT7Yf637FXzwzgDCbCZqkuRZONVmLsJGEK5 zNFsuQ0PaVWcky3epFijRHB34kwvSnD1nMwBo8fC9M5YyP94w2ttg/WisaspDIemNt9M ZXZk7gQ2EaC/cyV4C5+uu94IpizpS9kXG/uNh718eIIBiDl+C3IzVzNl+t0Z1m24ae+U gYrA== X-Gm-Message-State: ACgBeo24ZBr32XlSJdbJWlN7gGVo9EFhL0X6RDGbBUeqiW+zYS5KBpY4 HstjSGuNwHgKO6dryu3HXQs= X-Google-Smtp-Source: AA6agR5M1zbvVnaz19qs5aPClS3RbrwZxmnw+bU2659kQnERb5o7G/3kodQNdYL47ha1OqfWKOi8Kw== X-Received: by 2002:a05:6512:308d:b0:499:bd1a:d1bc with SMTP id z13-20020a056512308d00b00499bd1ad1bcmr1536967lfd.274.1662870770059; Sat, 10 Sep 2022 21:32:50 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:e929:c054:a46d:3844? ([2a02:a31a:a240:1700:e929:c054:a46d:3844]) by smtp.googlemail.com with ESMTPSA id a17-20020a2eb551000000b00261a8e56fe4sm539994ljn.55.2022.09.10.21.32.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Sep 2022 21:32:49 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: Date: Sun, 11 Sep 2022 06:32:47 +0200 Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v2 09/41] drm/connector: Add TV standard property Content-Language: pl To: Maxime Ripard Cc: Ben Skeggs , David Airlie , Chen-Yu Tsai , Thomas Zimmermann , Jani Nikula , Lyude Paul , Philipp Zabel , Maarten Lankhorst , Rodrigo Vivi , Tvrtko Ursulin , Jernej Skrabec , Samuel Holland , Karol Herbst , =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , Emma Anholt , Daniel Vetter , Joonas Lahtinen , Hans de Goede , linux-arm-kernel@lists.infradead.org, Phil Elwell , intel-gfx@lists.freedesktop.org, Dave Stevenson , dri-devel@lists.freedesktop.org, Dom Cobley , linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org, linux-sunxi@lists.linux.dev, Geert Uytterhoeven References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> <30a9d7cd-d9ff-3177-ac6c-e7c1f966d89a@gmail.com> <20220907121009.toizfolruuazcrns@houat> <6639fb8f-e16c-1ef5-5978-c522f76c8ded@gmail.com> <20220909094647.aahohiwtwbbeyzj3@houat> In-Reply-To: <20220909094647.aahohiwtwbbeyzj3@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit W dniu 9.09.2022 o 11:46, Maxime Ripard pisze: > On Wed, Sep 07, 2022 at 09:52:09PM +0200, Mateusz Kwiatkowski wrote: >> W dniu 7.09.2022 o 14:10, Maxime Ripard pisze: >>> Hi, >>> >>> On Fri, Sep 02, 2022 at 12:00:33AM +0200, Mateusz Kwiatkowski wrote: >>>> W dniu 29.08.2022 o 15:11, Maxime Ripard pisze: >>>>> The TV mode property has been around for a while now to select and get the >>>>> current TV mode output on an analog TV connector. >>>>> >>>>> Despite that property name being generic, its content isn't and has been >>>>> driver-specific which makes it hard to build any generic behaviour on top >>>>> of it, both in kernel and user-space. >>>>> >>>>> Let's create a new bitmask tv norm property, that can contain any of the >>>>> analog TV standards currently supported by kernel drivers. Each driver can >>>>> then pass in a bitmask of the modes it supports. >>>> >>>> This is not a bitmask property anymore, you've just changed it to an enum. >>>> The commit message is now misleading. >>>> >>>>> +static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = { >>>>> +    { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" }, >>>>> +    { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" }, >>>>> +    { DRM_MODE_TV_MODE_NTSC_M, "NTSC-M" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_60, "PAL-60" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_B, "PAL-B" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_D, "PAL-D" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_G, "PAL-G" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_H, "PAL-H" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_I, "PAL-I" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_M, "PAL-M" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_N, "PAL-N" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_NC, "PAL-Nc" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_60, "SECAM-60" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_B, "SECAM-B" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_D, "SECAM-D" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_G, "SECAM-G" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_K, "SECAM-K" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_K1, "SECAM-K1" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_L, "SECAM-L" }, >>>>> +}; >>>> >>>> I did not comment on it the last time, but this list looks a little bit random. >>>> >>>> Compared to the standards defined by V4L2, you also define SECAM-60 (a good >>>> thing to define, because why not), but don't define PAL-B1, PAL-D1, PAL-K, >>>> SECAM-H, SECAM-LC (whatever that is - probably just another name for SECAM-L, >>>> see my comment about PAL-Nc below), or NTSC-M-KR (a Korean variant of NTSC). >>>> >>>> Like I mentioned previously, I'm personally not a fan of including all those >>>> CCIR/ITU system variants, as they don't mean any difference to the output unless >>>> there is an RF modulator involved. But I get it that they have already been used >>>> and regressing probably wouldn't be a very good idea. But in that case keeping >>>> it consistent with the set of values used by V4L2 would be wise, I think. >>> >>> Ack. What would be the list of standards we'd absolutely need? NSTC-M, >>> NTSC-J, PAL-60, PAL-B, PAL-M, SECAM-60 and SECAM-B? >> >> The "essential list" IMO is NTSC, NTSC-J, NTSC-443, PAL, PAL-M, PAL-N and SECAM. >> Note that: >> >> - I intentionally propose "NTSC", "PAL" and "SECAM" without an ITU system >>   designation. If we only consider composite signals, there's no difference >>   between e.g. PAL-B, PAL-D and PAL-I, so it's better to label it as a generic >>   mode, IMO. >> >>   * PAL-M and PAL-N are different, because those unique color encodings were >>     only ever used with Systems M and N, respectively. >> >>   * NTSC-J is also different, because "System J" doesn't exist anywhere in ITU >>     documents. Japan technically uses System M with a non-standard black level. >>     But "NTSC-J" stuck as a universally recognized name for that variant. >> >> - I intentionally did not list PAL-60 or SECAM-60. TBH... PAL-60 is just >>   regular PAL paired with 480i60 modeline. Most if not all displays that >>   accept PAL-60 input will just label it as "PAL". If we are not introducing >>   strict modeline validation, then maybe separating PAL and PAL-60 isn't really >>   necessary? Same goes for SECAM vs. SECAM-60. >>   >>   ...and same goes for NTSC vs. NTSC-50 a.k.a NTSC-N, which is a very exotic >>   mode, but known to exist at least in the Atari ST world, see also: >>   https://en.wikipedia.org/wiki/NTSC#NTSC-N/NTSC50 >> >> Combining PAL and PAL-60 into a single setting would complicate the vc4 driver >> a little bit, though, as the registers need to be set up differently for those. >> >> My feelings about the PAL-60 issue are not that strong, though. Merging PAL >> and PAL-60 in this context is just a loose suggestion, I won't even try to >> argue if you disagree. > > Ack > >>>>> +/** >>>>> + * drm_mode_create_tv_properties - create TV specific connector properties >>>>> + * @dev: DRM device >>>>> + * @supported_tv_modes: Bitmask of TV modes supported (See DRM_MODE_TV_MODE_*) >>>>> + >>>>> + * Called by a driver's TV initialization routine, this function creates >>>>> + * the TV specific connector properties for a given device.  Caller is >>>>> + * responsible for allocating a list of format names and passing them to >>>>> + * this routine. >>>>> + * >>>>> + * Returns: >>>>> + * 0 on success or a negative error code on failure. >>>>> + */ >>>>> +int drm_mode_create_tv_properties(struct drm_device *dev, >>>>> +                  unsigned int supported_tv_modes) >>>> >>>> supported_tv_modes is supposed to be a bitmask of BIT(DRM_MODE_TV_MODE_*) >>>> (or (1<>>> is not said explicitly anywhere in this doc comment. >>> >>> The argument doc mentions that it's a "Bitmask of TV modes supported >>> (See DRM_MODE_TV_MODE_*)", how would you improve it? >> >> Maybe something like "Bitwise OR of BIT(DRM_MODE_TV_MODE_*) values"? Or maybe >> just add a little usage example? > > This is the way we're usually documenting it in DRM: > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_plane.c#L357 > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_crtc.c#L861 > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_blend.c#L546 > > So I'd rather keep it consistent > > Maxime Ack, OK then. 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 21A43C54EE9 for ; Sun, 11 Sep 2022 04:32:55 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9ACA410E3AE; Sun, 11 Sep 2022 04:32:54 +0000 (UTC) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by gabe.freedesktop.org (Postfix) with ESMTPS id D4D6E10E3AE; Sun, 11 Sep 2022 04:32:51 +0000 (UTC) Received: by mail-lf1-x133.google.com with SMTP id w8so9556885lft.12; Sat, 10 Sep 2022 21:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date; bh=eJ5+kSvRGx0e5DL23FMmsR32sATG84wn3pUtXfVNfJk=; b=UzwIqo7BotutKHABezU/5M4r1hFosIJShwkvIMqCyzl5TtN9VYDKXW7hFWomPhiGph Ym1yfhdW374PMwpW1PzT0+GQxyoj0se63YjLGw94N2hSZLa/vT+gtWArl6kk26PLdEw2 +SlenG2reH47juH0ULuJ70Gf02WSKtrR2KLFtjVbQ9twzPi2bgcpBZrX3OjcKYn0lwXZ 2IqDSdbK+ycclzRuVBZeW7CMnb3SVXqXzqSEH4jsllcB7PexwSKS4xCFyxDhhOsLsJgl RZ8+FTf+kdXOxVD/qjINJ/6P+5NUSOLgod5Ro4JMwXgX7O14od0BP7D0sF5hZAfjpql+ bhKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=eJ5+kSvRGx0e5DL23FMmsR32sATG84wn3pUtXfVNfJk=; b=rL0vQoyfPOBsTiILRRlJJH0qk7A4FtPuHI3Drvzl6aky+6ciQJAvtdG7OrcPazFezl bk08wnIY+1yi0ZU915gcifC2o/GftNAR6wCYdEJv6uI5z+BWdgOXtt7BIVqOasnwe8oP bU7Y41xyV/3xEuEEWkdrDRTVZg3bLk9yuU+8NV8F4mGDczus7tIZQY50Or1fBAINgfhd 3KJUxSJ564podYY9WElTxn5i0xCNheneIuXYHMQ/Ho4RPZxe23/MC5s1e7b4C3n1ZQEu LGq16NJzhiPZEUDhYIqcWJnjMpLOHNm+l8X1JQcmL0SkQHV1ZsdcGLzrhm6V52hNNTMs yWyA== X-Gm-Message-State: ACgBeo2+LUvrei1jQOabnv3IXAmN1NmUVPJmpNsu/v0PDUs6hzr9Sgyy XvLi/ScVqKCZmgYMrVwTsPY= X-Google-Smtp-Source: AA6agR5M1zbvVnaz19qs5aPClS3RbrwZxmnw+bU2659kQnERb5o7G/3kodQNdYL47ha1OqfWKOi8Kw== X-Received: by 2002:a05:6512:308d:b0:499:bd1a:d1bc with SMTP id z13-20020a056512308d00b00499bd1ad1bcmr1536967lfd.274.1662870770059; Sat, 10 Sep 2022 21:32:50 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:e929:c054:a46d:3844? ([2a02:a31a:a240:1700:e929:c054:a46d:3844]) by smtp.googlemail.com with ESMTPSA id a17-20020a2eb551000000b00261a8e56fe4sm539994ljn.55.2022.09.10.21.32.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Sep 2022 21:32:49 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: Date: Sun, 11 Sep 2022 06:32:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Content-Language: pl To: Maxime Ripard References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> <30a9d7cd-d9ff-3177-ac6c-e7c1f966d89a@gmail.com> <20220907121009.toizfolruuazcrns@houat> <6639fb8f-e16c-1ef5-5978-c522f76c8ded@gmail.com> <20220909094647.aahohiwtwbbeyzj3@houat> In-Reply-To: <20220909094647.aahohiwtwbbeyzj3@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Nouveau] [PATCH v2 09/41] drm/connector: Add TV standard property X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Airlie , nouveau@lists.freedesktop.org, Joonas Lahtinen , dri-devel@lists.freedesktop.org, Phil Elwell , Emma Anholt , Samuel Holland , Jernej Skrabec , Chen-Yu Tsai , Geert Uytterhoeven , Ben Skeggs , linux-sunxi@lists.linux.dev, intel-gfx@lists.freedesktop.org, Maarten Lankhorst , Jani Nikula , Hans de Goede , Rodrigo Vivi , Daniel Vetter , linux-arm-kernel@lists.infradead.org, Tvrtko Ursulin , Dom Cobley , linux-kernel@vger.kernel.org, =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , Philipp Zabel Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" W dniu 9.09.2022 o 11:46, Maxime Ripard pisze: > On Wed, Sep 07, 2022 at 09:52:09PM +0200, Mateusz Kwiatkowski wrote: >> W dniu 7.09.2022 o 14:10, Maxime Ripard pisze: >>> Hi, >>> >>> On Fri, Sep 02, 2022 at 12:00:33AM +0200, Mateusz Kwiatkowski wrote: >>>> W dniu 29.08.2022 o 15:11, Maxime Ripard pisze: >>>>> The TV mode property has been around for a while now to select and get the >>>>> current TV mode output on an analog TV connector. >>>>> >>>>> Despite that property name being generic, its content isn't and has been >>>>> driver-specific which makes it hard to build any generic behaviour on top >>>>> of it, both in kernel and user-space. >>>>> >>>>> Let's create a new bitmask tv norm property, that can contain any of the >>>>> analog TV standards currently supported by kernel drivers. Each driver can >>>>> then pass in a bitmask of the modes it supports. >>>> >>>> This is not a bitmask property anymore, you've just changed it to an enum. >>>> The commit message is now misleading. >>>> >>>>> +static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = { >>>>> +    { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" }, >>>>> +    { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" }, >>>>> +    { DRM_MODE_TV_MODE_NTSC_M, "NTSC-M" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_60, "PAL-60" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_B, "PAL-B" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_D, "PAL-D" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_G, "PAL-G" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_H, "PAL-H" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_I, "PAL-I" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_M, "PAL-M" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_N, "PAL-N" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_NC, "PAL-Nc" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_60, "SECAM-60" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_B, "SECAM-B" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_D, "SECAM-D" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_G, "SECAM-G" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_K, "SECAM-K" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_K1, "SECAM-K1" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_L, "SECAM-L" }, >>>>> +}; >>>> >>>> I did not comment on it the last time, but this list looks a little bit random. >>>> >>>> Compared to the standards defined by V4L2, you also define SECAM-60 (a good >>>> thing to define, because why not), but don't define PAL-B1, PAL-D1, PAL-K, >>>> SECAM-H, SECAM-LC (whatever that is - probably just another name for SECAM-L, >>>> see my comment about PAL-Nc below), or NTSC-M-KR (a Korean variant of NTSC). >>>> >>>> Like I mentioned previously, I'm personally not a fan of including all those >>>> CCIR/ITU system variants, as they don't mean any difference to the output unless >>>> there is an RF modulator involved. But I get it that they have already been used >>>> and regressing probably wouldn't be a very good idea. But in that case keeping >>>> it consistent with the set of values used by V4L2 would be wise, I think. >>> >>> Ack. What would be the list of standards we'd absolutely need? NSTC-M, >>> NTSC-J, PAL-60, PAL-B, PAL-M, SECAM-60 and SECAM-B? >> >> The "essential list" IMO is NTSC, NTSC-J, NTSC-443, PAL, PAL-M, PAL-N and SECAM. >> Note that: >> >> - I intentionally propose "NTSC", "PAL" and "SECAM" without an ITU system >>   designation. If we only consider composite signals, there's no difference >>   between e.g. PAL-B, PAL-D and PAL-I, so it's better to label it as a generic >>   mode, IMO. >> >>   * PAL-M and PAL-N are different, because those unique color encodings were >>     only ever used with Systems M and N, respectively. >> >>   * NTSC-J is also different, because "System J" doesn't exist anywhere in ITU >>     documents. Japan technically uses System M with a non-standard black level. >>     But "NTSC-J" stuck as a universally recognized name for that variant. >> >> - I intentionally did not list PAL-60 or SECAM-60. TBH... PAL-60 is just >>   regular PAL paired with 480i60 modeline. Most if not all displays that >>   accept PAL-60 input will just label it as "PAL". If we are not introducing >>   strict modeline validation, then maybe separating PAL and PAL-60 isn't really >>   necessary? Same goes for SECAM vs. SECAM-60. >>   >>   ...and same goes for NTSC vs. NTSC-50 a.k.a NTSC-N, which is a very exotic >>   mode, but known to exist at least in the Atari ST world, see also: >>   https://en.wikipedia.org/wiki/NTSC#NTSC-N/NTSC50 >> >> Combining PAL and PAL-60 into a single setting would complicate the vc4 driver >> a little bit, though, as the registers need to be set up differently for those. >> >> My feelings about the PAL-60 issue are not that strong, though. Merging PAL >> and PAL-60 in this context is just a loose suggestion, I won't even try to >> argue if you disagree. > > Ack > >>>>> +/** >>>>> + * drm_mode_create_tv_properties - create TV specific connector properties >>>>> + * @dev: DRM device >>>>> + * @supported_tv_modes: Bitmask of TV modes supported (See DRM_MODE_TV_MODE_*) >>>>> + >>>>> + * Called by a driver's TV initialization routine, this function creates >>>>> + * the TV specific connector properties for a given device.  Caller is >>>>> + * responsible for allocating a list of format names and passing them to >>>>> + * this routine. >>>>> + * >>>>> + * Returns: >>>>> + * 0 on success or a negative error code on failure. >>>>> + */ >>>>> +int drm_mode_create_tv_properties(struct drm_device *dev, >>>>> +                  unsigned int supported_tv_modes) >>>> >>>> supported_tv_modes is supposed to be a bitmask of BIT(DRM_MODE_TV_MODE_*) >>>> (or (1<>>> is not said explicitly anywhere in this doc comment. >>> >>> The argument doc mentions that it's a "Bitmask of TV modes supported >>> (See DRM_MODE_TV_MODE_*)", how would you improve it? >> >> Maybe something like "Bitwise OR of BIT(DRM_MODE_TV_MODE_*) values"? Or maybe >> just add a little usage example? > > This is the way we're usually documenting it in DRM: > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_plane.c#L357 > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_crtc.c#L861 > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_blend.c#L546 > > So I'd rather keep it consistent > > Maxime Ack, OK then. 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 8483EECAAA1 for ; Sun, 11 Sep 2022 04:34:04 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:Cc:To:Subject: MIME-Version:Date:Message-ID:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=YSyRfz0tyI+d7YMvq9CoGThA92QRFTicpI3zLy6Q2QM=; b=NOZR2s6u/AvSuC CPFspiKI7ZQQYfU08ns3VtDm31E9kxwzk++n1MEVaWX43+fD1+PyBkHfrK11GrSK5bYxE/LdOF8t7 dbcMz4oj+MH/I81K+7xi+rre2Of5y19tZ6wUGc+d30xresHx5CC0vb2WbtLfvFg5xOlZYD62GNphS ykitr84GHjK2YkI90eEGfiB6bnto/X8KMkDqF92RJ3BxPf2ZgoIxAnifZsgv30J+B7rvQep3+uSn6 nbZMtZys6edaZY+FLIODro67/s6sIw3c8/KVjqrc7bYsEK2wJxsyulRH31bUJwnW9rwTYMJzD+xRc wO8/e5l8Ehc/KQgA0Z5g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oXEeP-00FuTU-CN; Sun, 11 Sep 2022 04:32:57 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oXEeL-00FuQB-Fx for linux-arm-kernel@lists.infradead.org; Sun, 11 Sep 2022 04:32:55 +0000 Received: by mail-lf1-x133.google.com with SMTP id u18so9573596lfo.8 for ; Sat, 10 Sep 2022 21:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date; bh=eJ5+kSvRGx0e5DL23FMmsR32sATG84wn3pUtXfVNfJk=; b=UzwIqo7BotutKHABezU/5M4r1hFosIJShwkvIMqCyzl5TtN9VYDKXW7hFWomPhiGph Ym1yfhdW374PMwpW1PzT0+GQxyoj0se63YjLGw94N2hSZLa/vT+gtWArl6kk26PLdEw2 +SlenG2reH47juH0ULuJ70Gf02WSKtrR2KLFtjVbQ9twzPi2bgcpBZrX3OjcKYn0lwXZ 2IqDSdbK+ycclzRuVBZeW7CMnb3SVXqXzqSEH4jsllcB7PexwSKS4xCFyxDhhOsLsJgl RZ8+FTf+kdXOxVD/qjINJ/6P+5NUSOLgod5Ro4JMwXgX7O14od0BP7D0sF5hZAfjpql+ bhKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=eJ5+kSvRGx0e5DL23FMmsR32sATG84wn3pUtXfVNfJk=; b=0PFmP6tt5G6q+1hzMLsB40eVLsJLfuHfWz18cVgj1BBui7AQ39T2pc6pE27ZG4h6SF MCsDCXa1+Lnqavx9N5hA55kegkT5PqLXrq36PnhESfz3s10tJ7b9PherchyPqpR26Vh1 kF4/73PlyQ7liXQelbeVgcg5KXEkwDZ9I52JpDuDou8LgV3VJJTaFvHu9zg65dPEHB9O kSdPqgQbpIcTYGvrZesCnF7UNG64y311oFF9WfRLA+3ntJbbJy2EwcMfG978tYtLUYfN 7lrqfmXjkGEZoLkcuUUQqHLSARiz9HtMrmV3r5FXAI+j15MAeQi0gMu5Bc8pMR4/28gT Gmsg== X-Gm-Message-State: ACgBeo2Nn4/1YDov/e8V94urjuMmLJdHp5yaZ2zhyfS58SrZCWfceUYK n72gLXgYF3oHDOlyGYujVjs= X-Google-Smtp-Source: AA6agR5M1zbvVnaz19qs5aPClS3RbrwZxmnw+bU2659kQnERb5o7G/3kodQNdYL47ha1OqfWKOi8Kw== X-Received: by 2002:a05:6512:308d:b0:499:bd1a:d1bc with SMTP id z13-20020a056512308d00b00499bd1ad1bcmr1536967lfd.274.1662870770059; Sat, 10 Sep 2022 21:32:50 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:e929:c054:a46d:3844? ([2a02:a31a:a240:1700:e929:c054:a46d:3844]) by smtp.googlemail.com with ESMTPSA id a17-20020a2eb551000000b00261a8e56fe4sm539994ljn.55.2022.09.10.21.32.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Sep 2022 21:32:49 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: Date: Sun, 11 Sep 2022 06:32:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v2 09/41] drm/connector: Add TV standard property Content-Language: pl To: Maxime Ripard Cc: Ben Skeggs , David Airlie , Chen-Yu Tsai , Thomas Zimmermann , Jani Nikula , Lyude Paul , Philipp Zabel , Maarten Lankhorst , Rodrigo Vivi , Tvrtko Ursulin , Jernej Skrabec , Samuel Holland , Karol Herbst , =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , Emma Anholt , Daniel Vetter , Joonas Lahtinen , Hans de Goede , linux-arm-kernel@lists.infradead.org, Phil Elwell , intel-gfx@lists.freedesktop.org, Dave Stevenson , dri-devel@lists.freedesktop.org, Dom Cobley , linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org, linux-sunxi@lists.linux.dev, Geert Uytterhoeven References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> <30a9d7cd-d9ff-3177-ac6c-e7c1f966d89a@gmail.com> <20220907121009.toizfolruuazcrns@houat> <6639fb8f-e16c-1ef5-5978-c522f76c8ded@gmail.com> <20220909094647.aahohiwtwbbeyzj3@houat> In-Reply-To: <20220909094647.aahohiwtwbbeyzj3@houat> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220910_213253_573734_BD2CC87D X-CRM114-Status: GOOD ( 32.03 ) 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org VyBkbml1IDkuMDkuMjAyMiBvIDExOjQ2LCBNYXhpbWUgUmlwYXJkIHBpc3plOgo+IE9uIFdlZCwg U2VwIDA3LCAyMDIyIGF0IDA5OjUyOjA5UE0gKzAyMDAsIE1hdGV1c3ogS3dpYXRrb3dza2kgd3Jv dGU6Cj4+IFcgZG5pdSA3LjA5LjIwMjIgbyAxNDoxMCwgTWF4aW1lIFJpcGFyZCBwaXN6ZToKPj4+ IEhpLAo+Pj4KPj4+IE9uIEZyaSwgU2VwIDAyLCAyMDIyIGF0IDEyOjAwOjMzQU0gKzAyMDAsIE1h dGV1c3ogS3dpYXRrb3dza2kgd3JvdGU6Cj4+Pj4gVyBkbml1IDI5LjA4LjIwMjIgbyAxNToxMSwg TWF4aW1lIFJpcGFyZCBwaXN6ZToKPj4+Pj4gVGhlIFRWIG1vZGUgcHJvcGVydHkgaGFzIGJlZW4g YXJvdW5kIGZvciBhIHdoaWxlIG5vdyB0byBzZWxlY3QgYW5kIGdldCB0aGUKPj4+Pj4gY3VycmVu dCBUViBtb2RlIG91dHB1dCBvbiBhbiBhbmFsb2cgVFYgY29ubmVjdG9yLgo+Pj4+Pgo+Pj4+PiBE ZXNwaXRlIHRoYXQgcHJvcGVydHkgbmFtZSBiZWluZyBnZW5lcmljLCBpdHMgY29udGVudCBpc24n dCBhbmQgaGFzIGJlZW4KPj4+Pj4gZHJpdmVyLXNwZWNpZmljIHdoaWNoIG1ha2VzIGl0IGhhcmQg dG8gYnVpbGQgYW55IGdlbmVyaWMgYmVoYXZpb3VyIG9uIHRvcAo+Pj4+PiBvZiBpdCwgYm90aCBp biBrZXJuZWwgYW5kIHVzZXItc3BhY2UuCj4+Pj4+Cj4+Pj4+IExldCdzIGNyZWF0ZSBhIG5ldyBi aXRtYXNrIHR2IG5vcm0gcHJvcGVydHksIHRoYXQgY2FuIGNvbnRhaW4gYW55IG9mIHRoZQo+Pj4+ PiBhbmFsb2cgVFYgc3RhbmRhcmRzIGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkga2VybmVsIGRyaXZl cnMuIEVhY2ggZHJpdmVyIGNhbgo+Pj4+PiB0aGVuIHBhc3MgaW4gYSBiaXRtYXNrIG9mIHRoZSBt b2RlcyBpdCBzdXBwb3J0cy4KPj4+Pgo+Pj4+IFRoaXMgaXMgbm90IGEgYml0bWFzayBwcm9wZXJ0 eSBhbnltb3JlLCB5b3UndmUganVzdCBjaGFuZ2VkIGl0IHRvIGFuIGVudW0uCj4+Pj4gVGhlIGNv bW1pdCBtZXNzYWdlIGlzIG5vdyBtaXNsZWFkaW5nLgo+Pj4+Cj4+Pj4+ICtzdGF0aWMgY29uc3Qg c3RydWN0IGRybV9wcm9wX2VudW1fbGlzdCBkcm1fdHZfbW9kZV9lbnVtX2xpc3RbXSA9IHsKPj4+ Pj4gK8KgwqDCoCB7IERSTV9NT0RFX1RWX01PREVfTlRTQ180NDMsICJOVFNDLTQ0MyIgfSwKPj4+ Pj4gK8KgwqDCoCB7IERSTV9NT0RFX1RWX01PREVfTlRTQ19KLCAiTlRTQy1KIiB9LAo+Pj4+PiAr wqDCoMKgIHsgRFJNX01PREVfVFZfTU9ERV9OVFNDX00sICJOVFNDLU0iIH0sCj4+Pj4+ICvCoMKg wqAgeyBEUk1fTU9ERV9UVl9NT0RFX1BBTF82MCwgIlBBTC02MCIgfSwKPj4+Pj4gK8KgwqDCoCB7 IERSTV9NT0RFX1RWX01PREVfUEFMX0IsICJQQUwtQiIgfSwKPj4+Pj4gK8KgwqDCoCB7IERSTV9N T0RFX1RWX01PREVfUEFMX0QsICJQQUwtRCIgfSwKPj4+Pj4gK8KgwqDCoCB7IERSTV9NT0RFX1RW X01PREVfUEFMX0csICJQQUwtRyIgfSwKPj4+Pj4gK8KgwqDCoCB7IERSTV9NT0RFX1RWX01PREVf UEFMX0gsICJQQUwtSCIgfSwKPj4+Pj4gK8KgwqDCoCB7IERSTV9NT0RFX1RWX01PREVfUEFMX0ks ICJQQUwtSSIgfSwKPj4+Pj4gK8KgwqDCoCB7IERSTV9NT0RFX1RWX01PREVfUEFMX00sICJQQUwt TSIgfSwKPj4+Pj4gK8KgwqDCoCB7IERSTV9NT0RFX1RWX01PREVfUEFMX04sICJQQUwtTiIgfSwK Pj4+Pj4gK8KgwqDCoCB7IERSTV9NT0RFX1RWX01PREVfUEFMX05DLCAiUEFMLU5jIiB9LAo+Pj4+ PiArwqDCoMKgIHsgRFJNX01PREVfVFZfTU9ERV9TRUNBTV82MCwgIlNFQ0FNLTYwIiB9LAo+Pj4+ PiArwqDCoMKgIHsgRFJNX01PREVfVFZfTU9ERV9TRUNBTV9CLCAiU0VDQU0tQiIgfSwKPj4+Pj4g K8KgwqDCoCB7IERSTV9NT0RFX1RWX01PREVfU0VDQU1fRCwgIlNFQ0FNLUQiIH0sCj4+Pj4+ICvC oMKgwqAgeyBEUk1fTU9ERV9UVl9NT0RFX1NFQ0FNX0csICJTRUNBTS1HIiB9LAo+Pj4+PiArwqDC oMKgIHsgRFJNX01PREVfVFZfTU9ERV9TRUNBTV9LLCAiU0VDQU0tSyIgfSwKPj4+Pj4gK8KgwqDC oCB7IERSTV9NT0RFX1RWX01PREVfU0VDQU1fSzEsICJTRUNBTS1LMSIgfSwKPj4+Pj4gK8KgwqDC oCB7IERSTV9NT0RFX1RWX01PREVfU0VDQU1fTCwgIlNFQ0FNLUwiIH0sCj4+Pj4+ICt9Owo+Pj4+ Cj4+Pj4gSSBkaWQgbm90IGNvbW1lbnQgb24gaXQgdGhlIGxhc3QgdGltZSwgYnV0IHRoaXMgbGlz dCBsb29rcyBhIGxpdHRsZSBiaXQgcmFuZG9tLgo+Pj4+Cj4+Pj4gQ29tcGFyZWQgdG8gdGhlIHN0 YW5kYXJkcyBkZWZpbmVkIGJ5IFY0TDIsIHlvdSBhbHNvIGRlZmluZSBTRUNBTS02MCAoYSBnb29k Cj4+Pj4gdGhpbmcgdG8gZGVmaW5lLCBiZWNhdXNlIHdoeSBub3QpLCBidXQgZG9uJ3QgZGVmaW5l IFBBTC1CMSwgUEFMLUQxLCBQQUwtSywKPj4+PiBTRUNBTS1ILCBTRUNBTS1MQyAod2hhdGV2ZXIg dGhhdCBpcyAtIHByb2JhYmx5IGp1c3QgYW5vdGhlciBuYW1lIGZvciBTRUNBTS1MLAo+Pj4+IHNl ZSBteSBjb21tZW50IGFib3V0IFBBTC1OYyBiZWxvdyksIG9yIE5UU0MtTS1LUiAoYSBLb3JlYW4g dmFyaWFudCBvZiBOVFNDKS4KPj4+Pgo+Pj4+IExpa2UgSSBtZW50aW9uZWQgcHJldmlvdXNseSwg SSdtIHBlcnNvbmFsbHkgbm90IGEgZmFuIG9mIGluY2x1ZGluZyBhbGwgdGhvc2UKPj4+PiBDQ0lS L0lUVSBzeXN0ZW0gdmFyaWFudHMsIGFzIHRoZXkgZG9uJ3QgbWVhbiBhbnkgZGlmZmVyZW5jZSB0 byB0aGUgb3V0cHV0IHVubGVzcwo+Pj4+IHRoZXJlIGlzIGFuIFJGIG1vZHVsYXRvciBpbnZvbHZl ZC4gQnV0IEkgZ2V0IGl0IHRoYXQgdGhleSBoYXZlIGFscmVhZHkgYmVlbiB1c2VkCj4+Pj4gYW5k IHJlZ3Jlc3NpbmcgcHJvYmFibHkgd291bGRuJ3QgYmUgYSB2ZXJ5IGdvb2QgaWRlYS4gQnV0IGlu IHRoYXQgY2FzZSBrZWVwaW5nCj4+Pj4gaXQgY29uc2lzdGVudCB3aXRoIHRoZSBzZXQgb2YgdmFs dWVzIHVzZWQgYnkgVjRMMiB3b3VsZCBiZSB3aXNlLCBJIHRoaW5rLgo+Pj4KPj4+IEFjay4gV2hh dCB3b3VsZCBiZSB0aGUgbGlzdCBvZiBzdGFuZGFyZHMgd2UnZCBhYnNvbHV0ZWx5IG5lZWQ/IE5T VEMtTSwKPj4+IE5UU0MtSiwgUEFMLTYwLCBQQUwtQiwgUEFMLU0sIFNFQ0FNLTYwIGFuZCBTRUNB TS1CPwo+Pgo+PiBUaGUgImVzc2VudGlhbCBsaXN0IiBJTU8gaXMgTlRTQywgTlRTQy1KLCBOVFND LTQ0MywgUEFMLCBQQUwtTSwgUEFMLU4gYW5kIFNFQ0FNLgo+PiBOb3RlIHRoYXQ6Cj4+Cj4+IC0g SSBpbnRlbnRpb25hbGx5IHByb3Bvc2UgIk5UU0MiLCAiUEFMIiBhbmQgIlNFQ0FNIiB3aXRob3V0 IGFuIElUVSBzeXN0ZW0KPj7CoMKgIGRlc2lnbmF0aW9uLiBJZiB3ZSBvbmx5IGNvbnNpZGVyIGNv bXBvc2l0ZSBzaWduYWxzLCB0aGVyZSdzIG5vIGRpZmZlcmVuY2UKPj7CoMKgIGJldHdlZW4gZS5n LiBQQUwtQiwgUEFMLUQgYW5kIFBBTC1JLCBzbyBpdCdzIGJldHRlciB0byBsYWJlbCBpdCBhcyBh IGdlbmVyaWMKPj7CoMKgIG1vZGUsIElNTy4KPj4KPj7CoMKgICogUEFMLU0gYW5kIFBBTC1OIGFy ZSBkaWZmZXJlbnQsIGJlY2F1c2UgdGhvc2UgdW5pcXVlIGNvbG9yIGVuY29kaW5ncyB3ZXJlCj4+ wqDCoMKgwqAgb25seSBldmVyIHVzZWQgd2l0aCBTeXN0ZW1zIE0gYW5kIE4sIHJlc3BlY3RpdmVs eS4KPj4KPj7CoMKgICogTlRTQy1KIGlzIGFsc28gZGlmZmVyZW50LCBiZWNhdXNlICJTeXN0ZW0g SiIgZG9lc24ndCBleGlzdCBhbnl3aGVyZSBpbiBJVFUKPj7CoMKgwqDCoCBkb2N1bWVudHMuIEph cGFuIHRlY2huaWNhbGx5IHVzZXMgU3lzdGVtIE0gd2l0aCBhIG5vbi1zdGFuZGFyZCBibGFjayBs ZXZlbC4KPj7CoMKgwqDCoCBCdXQgIk5UU0MtSiIgc3R1Y2sgYXMgYSB1bml2ZXJzYWxseSByZWNv Z25pemVkIG5hbWUgZm9yIHRoYXQgdmFyaWFudC4KPj4KPj4gLSBJIGludGVudGlvbmFsbHkgZGlk IG5vdCBsaXN0IFBBTC02MCBvciBTRUNBTS02MC4gVEJILi4uIFBBTC02MCBpcyBqdXN0Cj4+wqDC oCByZWd1bGFyIFBBTCBwYWlyZWQgd2l0aCA0ODBpNjAgbW9kZWxpbmUuIE1vc3QgaWYgbm90IGFs bCBkaXNwbGF5cyB0aGF0Cj4+wqDCoCBhY2NlcHQgUEFMLTYwIGlucHV0IHdpbGwganVzdCBsYWJl bCBpdCBhcyAiUEFMIi4gSWYgd2UgYXJlIG5vdCBpbnRyb2R1Y2luZwo+PsKgwqAgc3RyaWN0IG1v ZGVsaW5lIHZhbGlkYXRpb24sIHRoZW4gbWF5YmUgc2VwYXJhdGluZyBQQUwgYW5kIFBBTC02MCBp c24ndCByZWFsbHkKPj7CoMKgIG5lY2Vzc2FyeT8gU2FtZSBnb2VzIGZvciBTRUNBTSB2cy4gU0VD QU0tNjAuCj4+IMKgCj4+wqDCoCAuLi5hbmQgc2FtZSBnb2VzIGZvciBOVFNDIHZzLiBOVFNDLTUw IGEuay5hIE5UU0MtTiwgd2hpY2ggaXMgYSB2ZXJ5IGV4b3RpYwo+PsKgwqAgbW9kZSwgYnV0IGtu b3duIHRvIGV4aXN0IGF0IGxlYXN0IGluIHRoZSBBdGFyaSBTVCB3b3JsZCwgc2VlIGFsc286Cj4+ wqDCoCBodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9OVFNDI05UU0MtTi9OVFNDNTAKPj4K Pj4gQ29tYmluaW5nIFBBTCBhbmQgUEFMLTYwIGludG8gYSBzaW5nbGUgc2V0dGluZyB3b3VsZCBj b21wbGljYXRlIHRoZSB2YzQgZHJpdmVyCj4+IGEgbGl0dGxlIGJpdCwgdGhvdWdoLCBhcyB0aGUg cmVnaXN0ZXJzIG5lZWQgdG8gYmUgc2V0IHVwIGRpZmZlcmVudGx5IGZvciB0aG9zZS4KPj4KPj4g TXkgZmVlbGluZ3MgYWJvdXQgdGhlIFBBTC02MCBpc3N1ZSBhcmUgbm90IHRoYXQgc3Ryb25nLCB0 aG91Z2guIE1lcmdpbmcgUEFMCj4+IGFuZCBQQUwtNjAgaW4gdGhpcyBjb250ZXh0IGlzIGp1c3Qg YSBsb29zZSBzdWdnZXN0aW9uLCBJIHdvbid0IGV2ZW4gdHJ5IHRvCj4+IGFyZ3VlIGlmIHlvdSBk aXNhZ3JlZS4KPgo+IEFjawo+Cj4+Pj4+ICsvKioKPj4+Pj4gKyAqIGRybV9tb2RlX2NyZWF0ZV90 dl9wcm9wZXJ0aWVzIC0gY3JlYXRlIFRWIHNwZWNpZmljIGNvbm5lY3RvciBwcm9wZXJ0aWVzCj4+ Pj4+ICsgKiBAZGV2OiBEUk0gZGV2aWNlCj4+Pj4+ICsgKiBAc3VwcG9ydGVkX3R2X21vZGVzOiBC aXRtYXNrIG9mIFRWIG1vZGVzIHN1cHBvcnRlZCAoU2VlIERSTV9NT0RFX1RWX01PREVfKikKPj4+ Pj4gKwo+Pj4+PiArICogQ2FsbGVkIGJ5IGEgZHJpdmVyJ3MgVFYgaW5pdGlhbGl6YXRpb24gcm91 dGluZSwgdGhpcyBmdW5jdGlvbiBjcmVhdGVzCj4+Pj4+ICsgKiB0aGUgVFYgc3BlY2lmaWMgY29u bmVjdG9yIHByb3BlcnRpZXMgZm9yIGEgZ2l2ZW4gZGV2aWNlLsKgIENhbGxlciBpcwo+Pj4+PiAr ICogcmVzcG9uc2libGUgZm9yIGFsbG9jYXRpbmcgYSBsaXN0IG9mIGZvcm1hdCBuYW1lcyBhbmQg cGFzc2luZyB0aGVtIHRvCj4+Pj4+ICsgKiB0aGlzIHJvdXRpbmUuCj4+Pj4+ICsgKgo+Pj4+PiAr ICogUmV0dXJuczoKPj4+Pj4gKyAqIDAgb24gc3VjY2VzcyBvciBhIG5lZ2F0aXZlIGVycm9yIGNv ZGUgb24gZmFpbHVyZS4KPj4+Pj4gKyAqLwo+Pj4+PiAraW50IGRybV9tb2RlX2NyZWF0ZV90dl9w cm9wZXJ0aWVzKHN0cnVjdCBkcm1fZGV2aWNlICpkZXYsCj4+Pj4+ICvCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIHVuc2lnbmVkIGludCBzdXBwb3J0ZWRfdHZfbW9kZXMpCj4+Pj4K Pj4+PiBzdXBwb3J0ZWRfdHZfbW9kZXMgaXMgc3VwcG9zZWQgdG8gYmUgYSBiaXRtYXNrIG9mIEJJ VChEUk1fTU9ERV9UVl9NT0RFXyopCj4+Pj4gKG9yICgxPDxEUk1fTU9ERV9UVl9NT0RFXyopKSBy YXRoZXIgdGhhbiBEUk1fTU9ERV9UVl9NT0RFXyogZGlyZWN0bHksIGJ1dCB0aGlzCj4+Pj4gaXMg bm90IHNhaWQgZXhwbGljaXRseSBhbnl3aGVyZSBpbiB0aGlzIGRvYyBjb21tZW50Lgo+Pj4KPj4+ IFRoZSBhcmd1bWVudCBkb2MgbWVudGlvbnMgdGhhdCBpdCdzIGEgIkJpdG1hc2sgb2YgVFYgbW9k ZXMgc3VwcG9ydGVkCj4+PiAoU2VlIERSTV9NT0RFX1RWX01PREVfKikiLCBob3cgd291bGQgeW91 IGltcHJvdmUgaXQ/Cj4+Cj4+IE1heWJlIHNvbWV0aGluZyBsaWtlICJCaXR3aXNlIE9SIG9mIEJJ VChEUk1fTU9ERV9UVl9NT0RFXyopIHZhbHVlcyI/IE9yIG1heWJlCj4+IGp1c3QgYWRkIGEgbGl0 dGxlIHVzYWdlIGV4YW1wbGU/Cj4KPiBUaGlzIGlzIHRoZSB3YXkgd2UncmUgdXN1YWxseSBkb2N1 bWVudGluZyBpdCBpbiBEUk06Cj4gaHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5jb20vbGludXgvbGF0 ZXN0L3NvdXJjZS9kcml2ZXJzL2dwdS9kcm0vZHJtX3BsYW5lLmMjTDM1Nwo+IGh0dHBzOi8vZWxp eGlyLmJvb3RsaW4uY29tL2xpbnV4L2xhdGVzdC9zb3VyY2UvZHJpdmVycy9ncHUvZHJtL2RybV9j cnRjLmMjTDg2MQo+IGh0dHBzOi8vZWxpeGlyLmJvb3RsaW4uY29tL2xpbnV4L2xhdGVzdC9zb3Vy Y2UvZHJpdmVycy9ncHUvZHJtL2RybV9ibGVuZC5jI0w1NDYKPgo+IFNvIEknZCByYXRoZXIga2Vl cCBpdCBjb25zaXN0ZW50Cj4KPiBNYXhpbWUKCkFjaywgT0sgdGhlbi4KCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGlu ZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMu aW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 4AEA8C54EE9 for ; Sun, 11 Sep 2022 04:33:00 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 45FB810E3B0; Sun, 11 Sep 2022 04:32:57 +0000 (UTC) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by gabe.freedesktop.org (Postfix) with ESMTPS id D4D6E10E3AE; Sun, 11 Sep 2022 04:32:51 +0000 (UTC) Received: by mail-lf1-x133.google.com with SMTP id w8so9556885lft.12; Sat, 10 Sep 2022 21:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date; bh=eJ5+kSvRGx0e5DL23FMmsR32sATG84wn3pUtXfVNfJk=; b=UzwIqo7BotutKHABezU/5M4r1hFosIJShwkvIMqCyzl5TtN9VYDKXW7hFWomPhiGph Ym1yfhdW374PMwpW1PzT0+GQxyoj0se63YjLGw94N2hSZLa/vT+gtWArl6kk26PLdEw2 +SlenG2reH47juH0ULuJ70Gf02WSKtrR2KLFtjVbQ9twzPi2bgcpBZrX3OjcKYn0lwXZ 2IqDSdbK+ycclzRuVBZeW7CMnb3SVXqXzqSEH4jsllcB7PexwSKS4xCFyxDhhOsLsJgl RZ8+FTf+kdXOxVD/qjINJ/6P+5NUSOLgod5Ro4JMwXgX7O14od0BP7D0sF5hZAfjpql+ bhKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=eJ5+kSvRGx0e5DL23FMmsR32sATG84wn3pUtXfVNfJk=; b=rL0vQoyfPOBsTiILRRlJJH0qk7A4FtPuHI3Drvzl6aky+6ciQJAvtdG7OrcPazFezl bk08wnIY+1yi0ZU915gcifC2o/GftNAR6wCYdEJv6uI5z+BWdgOXtt7BIVqOasnwe8oP bU7Y41xyV/3xEuEEWkdrDRTVZg3bLk9yuU+8NV8F4mGDczus7tIZQY50Or1fBAINgfhd 3KJUxSJ564podYY9WElTxn5i0xCNheneIuXYHMQ/Ho4RPZxe23/MC5s1e7b4C3n1ZQEu LGq16NJzhiPZEUDhYIqcWJnjMpLOHNm+l8X1JQcmL0SkQHV1ZsdcGLzrhm6V52hNNTMs yWyA== X-Gm-Message-State: ACgBeo2+LUvrei1jQOabnv3IXAmN1NmUVPJmpNsu/v0PDUs6hzr9Sgyy XvLi/ScVqKCZmgYMrVwTsPY= X-Google-Smtp-Source: AA6agR5M1zbvVnaz19qs5aPClS3RbrwZxmnw+bU2659kQnERb5o7G/3kodQNdYL47ha1OqfWKOi8Kw== X-Received: by 2002:a05:6512:308d:b0:499:bd1a:d1bc with SMTP id z13-20020a056512308d00b00499bd1ad1bcmr1536967lfd.274.1662870770059; Sat, 10 Sep 2022 21:32:50 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:e929:c054:a46d:3844? ([2a02:a31a:a240:1700:e929:c054:a46d:3844]) by smtp.googlemail.com with ESMTPSA id a17-20020a2eb551000000b00261a8e56fe4sm539994ljn.55.2022.09.10.21.32.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Sep 2022 21:32:49 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: Date: Sun, 11 Sep 2022 06:32:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v2 09/41] drm/connector: Add TV standard property Content-Language: pl To: Maxime Ripard References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> <30a9d7cd-d9ff-3177-ac6c-e7c1f966d89a@gmail.com> <20220907121009.toizfolruuazcrns@houat> <6639fb8f-e16c-1ef5-5978-c522f76c8ded@gmail.com> <20220909094647.aahohiwtwbbeyzj3@houat> In-Reply-To: <20220909094647.aahohiwtwbbeyzj3@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Karol Herbst , David Airlie , nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Phil Elwell , Emma Anholt , Samuel Holland , Jernej Skrabec , Chen-Yu Tsai , Geert Uytterhoeven , Ben Skeggs , linux-sunxi@lists.linux.dev, Thomas Zimmermann , intel-gfx@lists.freedesktop.org, Hans de Goede , Rodrigo Vivi , linux-arm-kernel@lists.infradead.org, Tvrtko Ursulin , Dom Cobley , Dave Stevenson , linux-kernel@vger.kernel.org, =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" W dniu 9.09.2022 o 11:46, Maxime Ripard pisze: > On Wed, Sep 07, 2022 at 09:52:09PM +0200, Mateusz Kwiatkowski wrote: >> W dniu 7.09.2022 o 14:10, Maxime Ripard pisze: >>> Hi, >>> >>> On Fri, Sep 02, 2022 at 12:00:33AM +0200, Mateusz Kwiatkowski wrote: >>>> W dniu 29.08.2022 o 15:11, Maxime Ripard pisze: >>>>> The TV mode property has been around for a while now to select and get the >>>>> current TV mode output on an analog TV connector. >>>>> >>>>> Despite that property name being generic, its content isn't and has been >>>>> driver-specific which makes it hard to build any generic behaviour on top >>>>> of it, both in kernel and user-space. >>>>> >>>>> Let's create a new bitmask tv norm property, that can contain any of the >>>>> analog TV standards currently supported by kernel drivers. Each driver can >>>>> then pass in a bitmask of the modes it supports. >>>> >>>> This is not a bitmask property anymore, you've just changed it to an enum. >>>> The commit message is now misleading. >>>> >>>>> +static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = { >>>>> +    { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" }, >>>>> +    { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" }, >>>>> +    { DRM_MODE_TV_MODE_NTSC_M, "NTSC-M" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_60, "PAL-60" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_B, "PAL-B" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_D, "PAL-D" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_G, "PAL-G" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_H, "PAL-H" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_I, "PAL-I" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_M, "PAL-M" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_N, "PAL-N" }, >>>>> +    { DRM_MODE_TV_MODE_PAL_NC, "PAL-Nc" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_60, "SECAM-60" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_B, "SECAM-B" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_D, "SECAM-D" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_G, "SECAM-G" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_K, "SECAM-K" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_K1, "SECAM-K1" }, >>>>> +    { DRM_MODE_TV_MODE_SECAM_L, "SECAM-L" }, >>>>> +}; >>>> >>>> I did not comment on it the last time, but this list looks a little bit random. >>>> >>>> Compared to the standards defined by V4L2, you also define SECAM-60 (a good >>>> thing to define, because why not), but don't define PAL-B1, PAL-D1, PAL-K, >>>> SECAM-H, SECAM-LC (whatever that is - probably just another name for SECAM-L, >>>> see my comment about PAL-Nc below), or NTSC-M-KR (a Korean variant of NTSC). >>>> >>>> Like I mentioned previously, I'm personally not a fan of including all those >>>> CCIR/ITU system variants, as they don't mean any difference to the output unless >>>> there is an RF modulator involved. But I get it that they have already been used >>>> and regressing probably wouldn't be a very good idea. But in that case keeping >>>> it consistent with the set of values used by V4L2 would be wise, I think. >>> >>> Ack. What would be the list of standards we'd absolutely need? NSTC-M, >>> NTSC-J, PAL-60, PAL-B, PAL-M, SECAM-60 and SECAM-B? >> >> The "essential list" IMO is NTSC, NTSC-J, NTSC-443, PAL, PAL-M, PAL-N and SECAM. >> Note that: >> >> - I intentionally propose "NTSC", "PAL" and "SECAM" without an ITU system >>   designation. If we only consider composite signals, there's no difference >>   between e.g. PAL-B, PAL-D and PAL-I, so it's better to label it as a generic >>   mode, IMO. >> >>   * PAL-M and PAL-N are different, because those unique color encodings were >>     only ever used with Systems M and N, respectively. >> >>   * NTSC-J is also different, because "System J" doesn't exist anywhere in ITU >>     documents. Japan technically uses System M with a non-standard black level. >>     But "NTSC-J" stuck as a universally recognized name for that variant. >> >> - I intentionally did not list PAL-60 or SECAM-60. TBH... PAL-60 is just >>   regular PAL paired with 480i60 modeline. Most if not all displays that >>   accept PAL-60 input will just label it as "PAL". If we are not introducing >>   strict modeline validation, then maybe separating PAL and PAL-60 isn't really >>   necessary? Same goes for SECAM vs. SECAM-60. >>   >>   ...and same goes for NTSC vs. NTSC-50 a.k.a NTSC-N, which is a very exotic >>   mode, but known to exist at least in the Atari ST world, see also: >>   https://en.wikipedia.org/wiki/NTSC#NTSC-N/NTSC50 >> >> Combining PAL and PAL-60 into a single setting would complicate the vc4 driver >> a little bit, though, as the registers need to be set up differently for those. >> >> My feelings about the PAL-60 issue are not that strong, though. Merging PAL >> and PAL-60 in this context is just a loose suggestion, I won't even try to >> argue if you disagree. > > Ack > >>>>> +/** >>>>> + * drm_mode_create_tv_properties - create TV specific connector properties >>>>> + * @dev: DRM device >>>>> + * @supported_tv_modes: Bitmask of TV modes supported (See DRM_MODE_TV_MODE_*) >>>>> + >>>>> + * Called by a driver's TV initialization routine, this function creates >>>>> + * the TV specific connector properties for a given device.  Caller is >>>>> + * responsible for allocating a list of format names and passing them to >>>>> + * this routine. >>>>> + * >>>>> + * Returns: >>>>> + * 0 on success or a negative error code on failure. >>>>> + */ >>>>> +int drm_mode_create_tv_properties(struct drm_device *dev, >>>>> +                  unsigned int supported_tv_modes) >>>> >>>> supported_tv_modes is supposed to be a bitmask of BIT(DRM_MODE_TV_MODE_*) >>>> (or (1<>>> is not said explicitly anywhere in this doc comment. >>> >>> The argument doc mentions that it's a "Bitmask of TV modes supported >>> (See DRM_MODE_TV_MODE_*)", how would you improve it? >> >> Maybe something like "Bitwise OR of BIT(DRM_MODE_TV_MODE_*) values"? Or maybe >> just add a little usage example? > > This is the way we're usually documenting it in DRM: > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_plane.c#L357 > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_crtc.c#L861 > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_blend.c#L546 > > So I'd rather keep it consistent > > Maxime Ack, OK then.