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 CF8E0ECAAD5 for ; Mon, 12 Sep 2022 13:38:11 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4988910E49C; Mon, 12 Sep 2022 13:38:10 +0000 (UTC) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by gabe.freedesktop.org (Postfix) with ESMTPS id CCA6710E85F; Wed, 7 Sep 2022 19:52:14 +0000 (UTC) Received: by mail-lj1-x232.google.com with SMTP id x10so17260593ljq.4; Wed, 07 Sep 2022 12:52:14 -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=yUwzU/FoG+85Ns4JdKII1z4ExnjRnKZlkKN2lB94FG4=; b=EKndYRdVlHtxdl+2W2aMAnRcArmaEjb20S8XowRXOt1VLMMDtTJdYqxKxAlBBZXyWd beiU3DVPCWge6/5Jg6qPhE0a+1616foGXx6ccgD5um3vyJVgdOypvwX3Alfwmn0OMEv6 osBKtnVrz3Tqxmnij9JYHOmyhHrATbkkWaGS1Nd40b8MWyBfRTvw/MjsD1piSslcskUZ NRYgTDsApqjZ8j1gq4VKOeOhsZtRXmWkF7W30sVhfK9lr0b7H5IgxBJWFO7zJ5vka5fs XJpXg6LAG3ogXAWMfihP+jmbQNxYhsPHDAC71b5pHhwLgnlh9O2gkRzz2MPrwhkjteEM Axag== 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=yUwzU/FoG+85Ns4JdKII1z4ExnjRnKZlkKN2lB94FG4=; b=lU0qswS8EVCyOOsO5y3GosNIzQtlA0OYiYqO3go/wO2EmvKo2JDOG61AZyruNOMUYy E+aX+IOsU0z4VqkIQViYew7ptVqqrKvCe/gBhKY6dbfeiEKZy3+oySQC2o+vZpEF3cOR k0axqx/UrOsrMU/eTtlSPI7vV7JLBU0nuymj9tySJFrnkbCBkH0kjwWwEwxBMimg1Yd9 WR8zadEdytl110+zKvVYEJcbKkjBkAuUyA4DihlGBACG6/TNPw5f+tDFdCZL8tYxFyVV Y+ODxxLPad0Wcdm8OKX12g1GXNkoN6/Bqqqyvyz/VaBb5sByC1C5oCBpm++5gcjKgXMf Wdew== X-Gm-Message-State: ACgBeo0lOlNQo0bLQCQQB8KhtGQdufkH/+R7vnhUaCW0DzgItzx/jOiY EFA9Oa4bTz2ypxSc44ax2Tk= X-Google-Smtp-Source: AA6agR7prye+anBkusQWIezcT9fPSQhdu5CxUaHX1aDvTKI8jdwbC5l35BglvHJ8rPbpT1REMeLQag== X-Received: by 2002:a05:651c:110d:b0:269:f9c0:d155 with SMTP id e13-20020a05651c110d00b00269f9c0d155mr1430507ljo.493.1662580332833; Wed, 07 Sep 2022 12:52:12 -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 m2-20020a056512358200b004947c4dfde8sm2693435lfr.129.2022.09.07.12.52.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Sep 2022 12:52:12 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <6639fb8f-e16c-1ef5-5978-c522f76c8ded@gmail.com> Date: Wed, 7 Sep 2022 21:52:09 +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.1 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> In-Reply-To: <20220907121009.toizfolruuazcrns@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" Hi Maxime, 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. >>> +/** >>> + * 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? > Thanks! > Maxime Best regards, Mateusz Kwiatkowski From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (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 04F5889C6 for ; Wed, 7 Sep 2022 19:52:14 +0000 (UTC) Received: by mail-lj1-f182.google.com with SMTP id z23so17280521ljk.1 for ; Wed, 07 Sep 2022 12:52:14 -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=yUwzU/FoG+85Ns4JdKII1z4ExnjRnKZlkKN2lB94FG4=; b=EKndYRdVlHtxdl+2W2aMAnRcArmaEjb20S8XowRXOt1VLMMDtTJdYqxKxAlBBZXyWd beiU3DVPCWge6/5Jg6qPhE0a+1616foGXx6ccgD5um3vyJVgdOypvwX3Alfwmn0OMEv6 osBKtnVrz3Tqxmnij9JYHOmyhHrATbkkWaGS1Nd40b8MWyBfRTvw/MjsD1piSslcskUZ NRYgTDsApqjZ8j1gq4VKOeOhsZtRXmWkF7W30sVhfK9lr0b7H5IgxBJWFO7zJ5vka5fs XJpXg6LAG3ogXAWMfihP+jmbQNxYhsPHDAC71b5pHhwLgnlh9O2gkRzz2MPrwhkjteEM Axag== 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=yUwzU/FoG+85Ns4JdKII1z4ExnjRnKZlkKN2lB94FG4=; b=WzQV1TRnXOnR6aV8snjB4ArzPLSh7wWHpTP6bQ4f247UvW8uL0gr7++y9tlNc6e7y2 +B901eXOhV6yQF0N5aKorryitWw0oghsf9dWeMdlBaYKeb1wtiTHmAWzp9He0j3djVpx WQgZfyr/0cjwRJlLx8Kg7nhA62ifOI++2+Nl+ozvmO+K6iRyU8X0BGYjdIrVvOFqoeag KY/Y59m5vv3vHGOHlTWDQ6gjFHwx9zhh8r0Jh509cH4ZScKA2XRQfRoMGdgffnYhCqUB D1oorYa8qsrA7OdxZjugnKT43+ZgeQTopFgsfI9KVe1oslhUgA0sbZVHH3h088FNk5Ax S4FA== X-Gm-Message-State: ACgBeo3P36c1BSOZDnMSu9+P7kmMnFz6GjUlhTTjf961ll6LxXSyHYUU SomkBZGzv4yk5VhzVzZ/Pb4= X-Google-Smtp-Source: AA6agR7prye+anBkusQWIezcT9fPSQhdu5CxUaHX1aDvTKI8jdwbC5l35BglvHJ8rPbpT1REMeLQag== X-Received: by 2002:a05:651c:110d:b0:269:f9c0:d155 with SMTP id e13-20020a05651c110d00b00269f9c0d155mr1430507ljo.493.1662580332833; Wed, 07 Sep 2022 12:52:12 -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 m2-20020a056512358200b004947c4dfde8sm2693435lfr.129.2022.09.07.12.52.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Sep 2022 12:52:12 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <6639fb8f-e16c-1ef5-5978-c522f76c8ded@gmail.com> Date: Wed, 7 Sep 2022 21:52:09 +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.1 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> In-Reply-To: <20220907121009.toizfolruuazcrns@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Maxime, 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. >>> +/** >>> + * 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? > Thanks! > Maxime Best regards, Mateusz Kwiatkowski 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 8D81BC6FA82 for ; Wed, 7 Sep 2022 19:52:21 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9DE0B10E862; Wed, 7 Sep 2022 19:52:20 +0000 (UTC) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by gabe.freedesktop.org (Postfix) with ESMTPS id CCA6710E85F; Wed, 7 Sep 2022 19:52:14 +0000 (UTC) Received: by mail-lj1-x232.google.com with SMTP id x10so17260593ljq.4; Wed, 07 Sep 2022 12:52:14 -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=yUwzU/FoG+85Ns4JdKII1z4ExnjRnKZlkKN2lB94FG4=; b=EKndYRdVlHtxdl+2W2aMAnRcArmaEjb20S8XowRXOt1VLMMDtTJdYqxKxAlBBZXyWd beiU3DVPCWge6/5Jg6qPhE0a+1616foGXx6ccgD5um3vyJVgdOypvwX3Alfwmn0OMEv6 osBKtnVrz3Tqxmnij9JYHOmyhHrATbkkWaGS1Nd40b8MWyBfRTvw/MjsD1piSslcskUZ NRYgTDsApqjZ8j1gq4VKOeOhsZtRXmWkF7W30sVhfK9lr0b7H5IgxBJWFO7zJ5vka5fs XJpXg6LAG3ogXAWMfihP+jmbQNxYhsPHDAC71b5pHhwLgnlh9O2gkRzz2MPrwhkjteEM Axag== 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=yUwzU/FoG+85Ns4JdKII1z4ExnjRnKZlkKN2lB94FG4=; b=lU0qswS8EVCyOOsO5y3GosNIzQtlA0OYiYqO3go/wO2EmvKo2JDOG61AZyruNOMUYy E+aX+IOsU0z4VqkIQViYew7ptVqqrKvCe/gBhKY6dbfeiEKZy3+oySQC2o+vZpEF3cOR k0axqx/UrOsrMU/eTtlSPI7vV7JLBU0nuymj9tySJFrnkbCBkH0kjwWwEwxBMimg1Yd9 WR8zadEdytl110+zKvVYEJcbKkjBkAuUyA4DihlGBACG6/TNPw5f+tDFdCZL8tYxFyVV Y+ODxxLPad0Wcdm8OKX12g1GXNkoN6/Bqqqyvyz/VaBb5sByC1C5oCBpm++5gcjKgXMf Wdew== X-Gm-Message-State: ACgBeo0lOlNQo0bLQCQQB8KhtGQdufkH/+R7vnhUaCW0DzgItzx/jOiY EFA9Oa4bTz2ypxSc44ax2Tk= X-Google-Smtp-Source: AA6agR7prye+anBkusQWIezcT9fPSQhdu5CxUaHX1aDvTKI8jdwbC5l35BglvHJ8rPbpT1REMeLQag== X-Received: by 2002:a05:651c:110d:b0:269:f9c0:d155 with SMTP id e13-20020a05651c110d00b00269f9c0d155mr1430507ljo.493.1662580332833; Wed, 07 Sep 2022 12:52:12 -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 m2-20020a056512358200b004947c4dfde8sm2693435lfr.129.2022.09.07.12.52.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Sep 2022 12:52:12 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <6639fb8f-e16c-1ef5-5978-c522f76c8ded@gmail.com> Date: Wed, 7 Sep 2022 21:52:09 +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.1 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> In-Reply-To: <20220907121009.toizfolruuazcrns@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" Hi Maxime, 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. >>> +/** >>> + * 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? > Thanks! > Maxime Best regards, Mateusz Kwiatkowski 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 59600C38145 for ; Wed, 7 Sep 2022 19:53:34 +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=t4qGTwX1fYy32lTNHJ2yBTJ5qDX8JCECev8f1+vVa2A=; b=L0wyYcoQI8HBsr xdGUNvZ4DGmnCy9Pr8rTPqbt8gv2hMeLdquDrkDFsbIE8PXQdcuTF3dyMId9RgVxvqEzi0BStJJmU fT/d4lB+q77/GQlpGYBGpdWjXOKUFHOPj9p7/H8EtT/97EMPvamDuyZ3fP1VT3/rqGpCe6kvjSiFJ HUzrEGc7KSY437njAyo6WwqcsZuYsr1xxBDroZSFPMzkXFvufZlg4N1cMrO24rKJVn0prsBqWVhht bBZ7AgjAI7KrT7QixvWOBF6WpNHPtOt6sDDhg0FNJnFJ79uoERO74D/x4R9qeTYLUyhjPyBGOyE/r FZ3ykqBHLotDqC1ScD8w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oW15w-009C7s-Nj; Wed, 07 Sep 2022 19:52:20 +0000 Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oW15s-009C1Q-Fm for linux-arm-kernel@lists.infradead.org; Wed, 07 Sep 2022 19:52:18 +0000 Received: by mail-lj1-x231.google.com with SMTP id by6so17216007ljb.11 for ; Wed, 07 Sep 2022 12:52:14 -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=yUwzU/FoG+85Ns4JdKII1z4ExnjRnKZlkKN2lB94FG4=; b=EKndYRdVlHtxdl+2W2aMAnRcArmaEjb20S8XowRXOt1VLMMDtTJdYqxKxAlBBZXyWd beiU3DVPCWge6/5Jg6qPhE0a+1616foGXx6ccgD5um3vyJVgdOypvwX3Alfwmn0OMEv6 osBKtnVrz3Tqxmnij9JYHOmyhHrATbkkWaGS1Nd40b8MWyBfRTvw/MjsD1piSslcskUZ NRYgTDsApqjZ8j1gq4VKOeOhsZtRXmWkF7W30sVhfK9lr0b7H5IgxBJWFO7zJ5vka5fs XJpXg6LAG3ogXAWMfihP+jmbQNxYhsPHDAC71b5pHhwLgnlh9O2gkRzz2MPrwhkjteEM Axag== 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=yUwzU/FoG+85Ns4JdKII1z4ExnjRnKZlkKN2lB94FG4=; b=WnIuZhPqm5OxPNPgbxr120qYR0xXNiUYfnTa7TI31kSqpHjasNR9cs2ZgiFgQOVE2O rn7npXrAZR3bG/89/gTBbXz6umrlYV44f+INTzH8GRAyyKUdV5NnShdm6malca30l641 VePzA/pIDO34II85bHunkUGoopATAZ3v1l+Kv0HwFFgIDVRCvW160aoUdNkbCtFsjXhm 3i6xcYa+QBgLBoEE4zUXIZAiWOHPZmt0JnGBQu1ZoigYpV2Hun2n5N9YUtzueo9ldj7+ teCfOvB2e1fPWo3FrIaZYrHwV/9AsD1XiUCd1wV6oVEeC5Krb1Hm91rVtGknProFwDyO o6vw== X-Gm-Message-State: ACgBeo1NGHXtffISavV1wqQ/DvV+A6Pv9imSqyXsie2xSREQA2Uv7FCv TEB/teMKXcGtY2tZARImDBYswbNeU3qcIg== X-Google-Smtp-Source: AA6agR7prye+anBkusQWIezcT9fPSQhdu5CxUaHX1aDvTKI8jdwbC5l35BglvHJ8rPbpT1REMeLQag== X-Received: by 2002:a05:651c:110d:b0:269:f9c0:d155 with SMTP id e13-20020a05651c110d00b00269f9c0d155mr1430507ljo.493.1662580332833; Wed, 07 Sep 2022 12:52:12 -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 m2-20020a056512358200b004947c4dfde8sm2693435lfr.129.2022.09.07.12.52.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Sep 2022 12:52:12 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <6639fb8f-e16c-1ef5-5978-c522f76c8ded@gmail.com> Date: Wed, 7 Sep 2022 21:52:09 +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.1 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> In-Reply-To: <20220907121009.toizfolruuazcrns@houat> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220907_125216_568436_E881F2D1 X-CRM114-Status: GOOD ( 32.58 ) 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 SGkgTWF4aW1lLAoKVyBkbml1IDcuMDkuMjAyMiBvIDE0OjEwLCBNYXhpbWUgUmlwYXJkIHBpc3pl Ogo+IEhpLAo+Cj4gT24gRnJpLCBTZXAgMDIsIDIwMjIgYXQgMTI6MDA6MzNBTSArMDIwMCwgTWF0 ZXVzeiBLd2lhdGtvd3NraSB3cm90ZToKPj4gVyBkbml1IDI5LjA4LjIwMjIgbyAxNToxMSwgTWF4 aW1lIFJpcGFyZCBwaXN6ZToKPj4+IFRoZSBUViBtb2RlIHByb3BlcnR5IGhhcyBiZWVuIGFyb3Vu ZCBmb3IgYSB3aGlsZSBub3cgdG8gc2VsZWN0IGFuZCBnZXQgdGhlCj4+PiBjdXJyZW50IFRWIG1v ZGUgb3V0cHV0IG9uIGFuIGFuYWxvZyBUViBjb25uZWN0b3IuCj4+Pgo+Pj4gRGVzcGl0ZSB0aGF0 IHByb3BlcnR5IG5hbWUgYmVpbmcgZ2VuZXJpYywgaXRzIGNvbnRlbnQgaXNuJ3QgYW5kIGhhcyBi ZWVuCj4+PiBkcml2ZXItc3BlY2lmaWMgd2hpY2ggbWFrZXMgaXQgaGFyZCB0byBidWlsZCBhbnkg Z2VuZXJpYyBiZWhhdmlvdXIgb24gdG9wCj4+PiBvZiBpdCwgYm90aCBpbiBrZXJuZWwgYW5kIHVz ZXItc3BhY2UuCj4+Pgo+Pj4gTGV0J3MgY3JlYXRlIGEgbmV3IGJpdG1hc2sgdHYgbm9ybSBwcm9w ZXJ0eSwgdGhhdCBjYW4gY29udGFpbiBhbnkgb2YgdGhlCj4+PiBhbmFsb2cgVFYgc3RhbmRhcmRz IGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkga2VybmVsIGRyaXZlcnMuIEVhY2ggZHJpdmVyIGNhbgo+ Pj4gdGhlbiBwYXNzIGluIGEgYml0bWFzayBvZiB0aGUgbW9kZXMgaXQgc3VwcG9ydHMuCj4+Cj4+ IFRoaXMgaXMgbm90IGEgYml0bWFzayBwcm9wZXJ0eSBhbnltb3JlLCB5b3UndmUganVzdCBjaGFu Z2VkIGl0IHRvIGFuIGVudW0uCj4+IFRoZSBjb21taXQgbWVzc2FnZSBpcyBub3cgbWlzbGVhZGlu Zy4KPj4KPj4+ICtzdGF0aWMgY29uc3Qgc3RydWN0IGRybV9wcm9wX2VudW1fbGlzdCBkcm1fdHZf bW9kZV9lbnVtX2xpc3RbXSA9IHsKPj4+ICvCoMKgwqAgeyBEUk1fTU9ERV9UVl9NT0RFX05UU0Nf NDQzLCAiTlRTQy00NDMiIH0sCj4+PiArwqDCoMKgIHsgRFJNX01PREVfVFZfTU9ERV9OVFNDX0os ICJOVFNDLUoiIH0sCj4+PiArwqDCoMKgIHsgRFJNX01PREVfVFZfTU9ERV9OVFNDX00sICJOVFND LU0iIH0sCj4+PiArwqDCoMKgIHsgRFJNX01PREVfVFZfTU9ERV9QQUxfNjAsICJQQUwtNjAiIH0s Cj4+PiArwqDCoMKgIHsgRFJNX01PREVfVFZfTU9ERV9QQUxfQiwgIlBBTC1CIiB9LAo+Pj4gK8Kg wqDCoCB7IERSTV9NT0RFX1RWX01PREVfUEFMX0QsICJQQUwtRCIgfSwKPj4+ICvCoMKgwqAgeyBE Uk1fTU9ERV9UVl9NT0RFX1BBTF9HLCAiUEFMLUciIH0sCj4+PiArwqDCoMKgIHsgRFJNX01PREVf VFZfTU9ERV9QQUxfSCwgIlBBTC1IIiB9LAo+Pj4gK8KgwqDCoCB7IERSTV9NT0RFX1RWX01PREVf UEFMX0ksICJQQUwtSSIgfSwKPj4+ICvCoMKgwqAgeyBEUk1fTU9ERV9UVl9NT0RFX1BBTF9NLCAi UEFMLU0iIH0sCj4+PiArwqDCoMKgIHsgRFJNX01PREVfVFZfTU9ERV9QQUxfTiwgIlBBTC1OIiB9 LAo+Pj4gK8KgwqDCoCB7IERSTV9NT0RFX1RWX01PREVfUEFMX05DLCAiUEFMLU5jIiB9LAo+Pj4g K8KgwqDCoCB7IERSTV9NT0RFX1RWX01PREVfU0VDQU1fNjAsICJTRUNBTS02MCIgfSwKPj4+ICvC oMKgwqAgeyBEUk1fTU9ERV9UVl9NT0RFX1NFQ0FNX0IsICJTRUNBTS1CIiB9LAo+Pj4gK8KgwqDC oCB7IERSTV9NT0RFX1RWX01PREVfU0VDQU1fRCwgIlNFQ0FNLUQiIH0sCj4+PiArwqDCoMKgIHsg RFJNX01PREVfVFZfTU9ERV9TRUNBTV9HLCAiU0VDQU0tRyIgfSwKPj4+ICvCoMKgwqAgeyBEUk1f TU9ERV9UVl9NT0RFX1NFQ0FNX0ssICJTRUNBTS1LIiB9LAo+Pj4gK8KgwqDCoCB7IERSTV9NT0RF X1RWX01PREVfU0VDQU1fSzEsICJTRUNBTS1LMSIgfSwKPj4+ICvCoMKgwqAgeyBEUk1fTU9ERV9U Vl9NT0RFX1NFQ0FNX0wsICJTRUNBTS1MIiB9LAo+Pj4gK307Cj4+Cj4+IEkgZGlkIG5vdCBjb21t ZW50IG9uIGl0IHRoZSBsYXN0IHRpbWUsIGJ1dCB0aGlzIGxpc3QgbG9va3MgYSBsaXR0bGUgYml0 IHJhbmRvbS4KPj4KPj4gQ29tcGFyZWQgdG8gdGhlIHN0YW5kYXJkcyBkZWZpbmVkIGJ5IFY0TDIs IHlvdSBhbHNvIGRlZmluZSBTRUNBTS02MCAoYSBnb29kCj4+IHRoaW5nIHRvIGRlZmluZSwgYmVj YXVzZSB3aHkgbm90KSwgYnV0IGRvbid0IGRlZmluZSBQQUwtQjEsIFBBTC1EMSwgUEFMLUssCj4+ IFNFQ0FNLUgsIFNFQ0FNLUxDICh3aGF0ZXZlciB0aGF0IGlzIC0gcHJvYmFibHkganVzdCBhbm90 aGVyIG5hbWUgZm9yIFNFQ0FNLUwsCj4+IHNlZSBteSBjb21tZW50IGFib3V0IFBBTC1OYyBiZWxv dyksIG9yIE5UU0MtTS1LUiAoYSBLb3JlYW4gdmFyaWFudCBvZiBOVFNDKS4KPj4KPj4gTGlrZSBJ IG1lbnRpb25lZCBwcmV2aW91c2x5LCBJJ20gcGVyc29uYWxseSBub3QgYSBmYW4gb2YgaW5jbHVk aW5nIGFsbCB0aG9zZQo+PiBDQ0lSL0lUVSBzeXN0ZW0gdmFyaWFudHMsIGFzIHRoZXkgZG9uJ3Qg bWVhbiBhbnkgZGlmZmVyZW5jZSB0byB0aGUgb3V0cHV0IHVubGVzcwo+PiB0aGVyZSBpcyBhbiBS RiBtb2R1bGF0b3IgaW52b2x2ZWQuIEJ1dCBJIGdldCBpdCB0aGF0IHRoZXkgaGF2ZSBhbHJlYWR5 IGJlZW4gdXNlZAo+PiBhbmQgcmVncmVzc2luZyBwcm9iYWJseSB3b3VsZG4ndCBiZSBhIHZlcnkg Z29vZCBpZGVhLiBCdXQgaW4gdGhhdCBjYXNlIGtlZXBpbmcKPj4gaXQgY29uc2lzdGVudCB3aXRo IHRoZSBzZXQgb2YgdmFsdWVzIHVzZWQgYnkgVjRMMiB3b3VsZCBiZSB3aXNlLCBJIHRoaW5rLgo+ Cj4gQWNrLiBXaGF0IHdvdWxkIGJlIHRoZSBsaXN0IG9mIHN0YW5kYXJkcyB3ZSdkIGFic29sdXRl bHkgbmVlZD8gTlNUQy1NLAo+IE5UU0MtSiwgUEFMLTYwLCBQQUwtQiwgUEFMLU0sIFNFQ0FNLTYw IGFuZCBTRUNBTS1CPwoKVGhlICJlc3NlbnRpYWwgbGlzdCIgSU1PIGlzIE5UU0MsIE5UU0MtSiwg TlRTQy00NDMsIFBBTCwgUEFMLU0sIFBBTC1OIGFuZCBTRUNBTS4KTm90ZSB0aGF0OgoKLSBJIGlu dGVudGlvbmFsbHkgcHJvcG9zZSAiTlRTQyIsICJQQUwiIGFuZCAiU0VDQU0iIHdpdGhvdXQgYW4g SVRVIHN5c3RlbQrCoCBkZXNpZ25hdGlvbi4gSWYgd2Ugb25seSBjb25zaWRlciBjb21wb3NpdGUg c2lnbmFscywgdGhlcmUncyBubyBkaWZmZXJlbmNlCsKgIGJldHdlZW4gZS5nLiBQQUwtQiwgUEFM LUQgYW5kIFBBTC1JLCBzbyBpdCdzIGJldHRlciB0byBsYWJlbCBpdCBhcyBhIGdlbmVyaWMKwqAg bW9kZSwgSU1PLgoKwqAgKiBQQUwtTSBhbmQgUEFMLU4gYXJlIGRpZmZlcmVudCwgYmVjYXVzZSB0 aG9zZSB1bmlxdWUgY29sb3IgZW5jb2RpbmdzIHdlcmUKwqDCoMKgIG9ubHkgZXZlciB1c2VkIHdp dGggU3lzdGVtcyBNIGFuZCBOLCByZXNwZWN0aXZlbHkuCgrCoCAqIE5UU0MtSiBpcyBhbHNvIGRp ZmZlcmVudCwgYmVjYXVzZSAiU3lzdGVtIEoiIGRvZXNuJ3QgZXhpc3QgYW55d2hlcmUgaW4gSVRV CsKgwqDCoCBkb2N1bWVudHMuIEphcGFuIHRlY2huaWNhbGx5IHVzZXMgU3lzdGVtIE0gd2l0aCBh IG5vbi1zdGFuZGFyZCBibGFjayBsZXZlbC4KwqDCoMKgIEJ1dCAiTlRTQy1KIiBzdHVjayBhcyBh IHVuaXZlcnNhbGx5IHJlY29nbml6ZWQgbmFtZSBmb3IgdGhhdCB2YXJpYW50LgoKLSBJIGludGVu dGlvbmFsbHkgZGlkIG5vdCBsaXN0IFBBTC02MCBvciBTRUNBTS02MC4gVEJILi4uIFBBTC02MCBp cyBqdXN0CsKgIHJlZ3VsYXIgUEFMIHBhaXJlZCB3aXRoIDQ4MGk2MCBtb2RlbGluZS4gTW9zdCBp ZiBub3QgYWxsIGRpc3BsYXlzIHRoYXQKwqAgYWNjZXB0IFBBTC02MCBpbnB1dCB3aWxsIGp1c3Qg bGFiZWwgaXQgYXMgIlBBTCIuIElmIHdlIGFyZSBub3QgaW50cm9kdWNpbmcKwqAgc3RyaWN0IG1v ZGVsaW5lIHZhbGlkYXRpb24sIHRoZW4gbWF5YmUgc2VwYXJhdGluZyBQQUwgYW5kIFBBTC02MCBp c24ndCByZWFsbHkKwqAgbmVjZXNzYXJ5PyBTYW1lIGdvZXMgZm9yIFNFQ0FNIHZzLiBTRUNBTS02 MC4KwqAKwqAgLi4uYW5kIHNhbWUgZ29lcyBmb3IgTlRTQyB2cy4gTlRTQy01MCBhLmsuYSBOVFND LU4sIHdoaWNoIGlzIGEgdmVyeSBleG90aWMKwqAgbW9kZSwgYnV0IGtub3duIHRvIGV4aXN0IGF0 IGxlYXN0IGluIHRoZSBBdGFyaSBTVCB3b3JsZCwgc2VlIGFsc286CsKgIGh0dHBzOi8vZW4ud2lr aXBlZGlhLm9yZy93aWtpL05UU0MjTlRTQy1OL05UU0M1MAoKQ29tYmluaW5nIFBBTCBhbmQgUEFM LTYwIGludG8gYSBzaW5nbGUgc2V0dGluZyB3b3VsZCBjb21wbGljYXRlIHRoZSB2YzQgZHJpdmVy CmEgbGl0dGxlIGJpdCwgdGhvdWdoLCBhcyB0aGUgcmVnaXN0ZXJzIG5lZWQgdG8gYmUgc2V0IHVw IGRpZmZlcmVudGx5IGZvciB0aG9zZS4KCk15IGZlZWxpbmdzIGFib3V0IHRoZSBQQUwtNjAgaXNz dWUgYXJlIG5vdCB0aGF0IHN0cm9uZywgdGhvdWdoLiBNZXJnaW5nIFBBTAphbmQgUEFMLTYwIGlu IHRoaXMgY29udGV4dCBpcyBqdXN0IGEgbG9vc2Ugc3VnZ2VzdGlvbiwgSSB3b24ndCBldmVuIHRy eSB0bwphcmd1ZSBpZiB5b3UgZGlzYWdyZWUuCgo+Pj4gKy8qKgo+Pj4gKyAqIGRybV9tb2RlX2Ny ZWF0ZV90dl9wcm9wZXJ0aWVzIC0gY3JlYXRlIFRWIHNwZWNpZmljIGNvbm5lY3RvciBwcm9wZXJ0 aWVzCj4+PiArICogQGRldjogRFJNIGRldmljZQo+Pj4gKyAqIEBzdXBwb3J0ZWRfdHZfbW9kZXM6 IEJpdG1hc2sgb2YgVFYgbW9kZXMgc3VwcG9ydGVkIChTZWUgRFJNX01PREVfVFZfTU9ERV8qKQo+ Pj4gKwo+Pj4gKyAqIENhbGxlZCBieSBhIGRyaXZlcidzIFRWIGluaXRpYWxpemF0aW9uIHJvdXRp bmUsIHRoaXMgZnVuY3Rpb24gY3JlYXRlcwo+Pj4gKyAqIHRoZSBUViBzcGVjaWZpYyBjb25uZWN0 b3IgcHJvcGVydGllcyBmb3IgYSBnaXZlbiBkZXZpY2UuwqAgQ2FsbGVyIGlzCj4+PiArICogcmVz cG9uc2libGUgZm9yIGFsbG9jYXRpbmcgYSBsaXN0IG9mIGZvcm1hdCBuYW1lcyBhbmQgcGFzc2lu ZyB0aGVtIHRvCj4+PiArICogdGhpcyByb3V0aW5lLgo+Pj4gKyAqCj4+PiArICogUmV0dXJuczoK Pj4+ICsgKiAwIG9uIHN1Y2Nlc3Mgb3IgYSBuZWdhdGl2ZSBlcnJvciBjb2RlIG9uIGZhaWx1cmUu Cj4+PiArICovCj4+PiAraW50IGRybV9tb2RlX2NyZWF0ZV90dl9wcm9wZXJ0aWVzKHN0cnVjdCBk cm1fZGV2aWNlICpkZXYsCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1 bnNpZ25lZCBpbnQgc3VwcG9ydGVkX3R2X21vZGVzKQo+Pgo+PiBzdXBwb3J0ZWRfdHZfbW9kZXMg aXMgc3VwcG9zZWQgdG8gYmUgYSBiaXRtYXNrIG9mIEJJVChEUk1fTU9ERV9UVl9NT0RFXyopCj4+ IChvciAoMTw8RFJNX01PREVfVFZfTU9ERV8qKSkgcmF0aGVyIHRoYW4gRFJNX01PREVfVFZfTU9E RV8qIGRpcmVjdGx5LCBidXQgdGhpcwo+PiBpcyBub3Qgc2FpZCBleHBsaWNpdGx5IGFueXdoZXJl IGluIHRoaXMgZG9jIGNvbW1lbnQuCj4KPiBUaGUgYXJndW1lbnQgZG9jIG1lbnRpb25zIHRoYXQg aXQncyBhICJCaXRtYXNrIG9mIFRWIG1vZGVzIHN1cHBvcnRlZAo+IChTZWUgRFJNX01PREVfVFZf TU9ERV8qKSIsIGhvdyB3b3VsZCB5b3UgaW1wcm92ZSBpdD8KCk1heWJlIHNvbWV0aGluZyBsaWtl ICJCaXR3aXNlIE9SIG9mIEJJVChEUk1fTU9ERV9UVl9NT0RFXyopIHZhbHVlcyI/IE9yIG1heWJl Cmp1c3QgYWRkIGEgbGl0dGxlIHVzYWdlIGV4YW1wbGU/Cgo+IFRoYW5rcyEKPiBNYXhpbWUKCkJl c3QgcmVnYXJkcywKTWF0ZXVzeiBLd2lhdGtvd3NraQoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGlu dXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQu b3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= 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 C3F97C54EE9 for ; Wed, 7 Sep 2022 19:52:17 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 77C3310E85F; Wed, 7 Sep 2022 19:52:16 +0000 (UTC) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by gabe.freedesktop.org (Postfix) with ESMTPS id CCA6710E85F; Wed, 7 Sep 2022 19:52:14 +0000 (UTC) Received: by mail-lj1-x232.google.com with SMTP id x10so17260593ljq.4; Wed, 07 Sep 2022 12:52:14 -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=yUwzU/FoG+85Ns4JdKII1z4ExnjRnKZlkKN2lB94FG4=; b=EKndYRdVlHtxdl+2W2aMAnRcArmaEjb20S8XowRXOt1VLMMDtTJdYqxKxAlBBZXyWd beiU3DVPCWge6/5Jg6qPhE0a+1616foGXx6ccgD5um3vyJVgdOypvwX3Alfwmn0OMEv6 osBKtnVrz3Tqxmnij9JYHOmyhHrATbkkWaGS1Nd40b8MWyBfRTvw/MjsD1piSslcskUZ NRYgTDsApqjZ8j1gq4VKOeOhsZtRXmWkF7W30sVhfK9lr0b7H5IgxBJWFO7zJ5vka5fs XJpXg6LAG3ogXAWMfihP+jmbQNxYhsPHDAC71b5pHhwLgnlh9O2gkRzz2MPrwhkjteEM Axag== 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=yUwzU/FoG+85Ns4JdKII1z4ExnjRnKZlkKN2lB94FG4=; b=lU0qswS8EVCyOOsO5y3GosNIzQtlA0OYiYqO3go/wO2EmvKo2JDOG61AZyruNOMUYy E+aX+IOsU0z4VqkIQViYew7ptVqqrKvCe/gBhKY6dbfeiEKZy3+oySQC2o+vZpEF3cOR k0axqx/UrOsrMU/eTtlSPI7vV7JLBU0nuymj9tySJFrnkbCBkH0kjwWwEwxBMimg1Yd9 WR8zadEdytl110+zKvVYEJcbKkjBkAuUyA4DihlGBACG6/TNPw5f+tDFdCZL8tYxFyVV Y+ODxxLPad0Wcdm8OKX12g1GXNkoN6/Bqqqyvyz/VaBb5sByC1C5oCBpm++5gcjKgXMf Wdew== X-Gm-Message-State: ACgBeo0lOlNQo0bLQCQQB8KhtGQdufkH/+R7vnhUaCW0DzgItzx/jOiY EFA9Oa4bTz2ypxSc44ax2Tk= X-Google-Smtp-Source: AA6agR7prye+anBkusQWIezcT9fPSQhdu5CxUaHX1aDvTKI8jdwbC5l35BglvHJ8rPbpT1REMeLQag== X-Received: by 2002:a05:651c:110d:b0:269:f9c0:d155 with SMTP id e13-20020a05651c110d00b00269f9c0d155mr1430507ljo.493.1662580332833; Wed, 07 Sep 2022 12:52:12 -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 m2-20020a056512358200b004947c4dfde8sm2693435lfr.129.2022.09.07.12.52.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Sep 2022 12:52:12 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <6639fb8f-e16c-1ef5-5978-c522f76c8ded@gmail.com> Date: Wed, 7 Sep 2022 21:52:09 +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.1 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> In-Reply-To: <20220907121009.toizfolruuazcrns@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" Hi Maxime, 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. >>> +/** >>> + * 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? > Thanks! > Maxime Best regards, Mateusz Kwiatkowski