From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (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 162A87480 for ; Thu, 1 Sep 2022 22:00:39 +0000 (UTC) Received: by mail-lf1-f51.google.com with SMTP id q7so686985lfu.5 for ; Thu, 01 Sep 2022 15:00:39 -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; bh=9ZOA/uLVkdbadD8sl+x2FgrUVnWNaT54IH6CMV7M0qU=; b=LHm7XQKmoioehKLe+x8wv4sg51dxY3iK7GBIf0ie+fcfdWHmpj8uhKVo1qfStRYUDt hYYwKyXLa6F8Vss8qsGXnhsSbaWjrIFZiJWH0w+6WT1drr8SW/5N5uWQUY13CtCu8RT7 XFGF/pp/ZAdp6alq7wI37+qWMkMsD15jW9A1A3zaqPv8x1Ugm06xru39RntLJn/t21Zd Io+z1YLdKsVMwCmBwJgUdIXcFGDcNDdzsiH8DINgDlhluHlE98GV0dVvSpde0N5jFpG/ 4M6RwAzfFXYpV1BXP/VnjdTCqnFT6/utQ9dJtdN/u84FrH7SItMET/4Tm6x8CjaYhOPO 0DtQ== 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; bh=9ZOA/uLVkdbadD8sl+x2FgrUVnWNaT54IH6CMV7M0qU=; b=PL97nkb79UKhR2yZbsGaDxB63vyOl2FnBo75mP7qksPyXXES1f1/tVLDIiyJU8Q5mL s3O+u8jzeehQjdEnA7UqFTJmfbWFEkjaQu5H4jUQJqrIJwuBd+tZ0LicCtqtHRHkEHvY 40VUSbj1CYuFDEBsbryP/xE11knTT9rRmTQpengLN95wLlq+6OW0OmW/Jw2UymtN7u0X Gc1cFH67uY2ybXS8Z+4ZjWTSglHF79nBWAiJ5bMF+Vujq8r8pNQWwnI9p7rcHxkJ9z++ 5RrBPFSgj6oBQqLb31R2Y8cH8bAIp3ePRQ2+KZ9gWfr3iuVo3f6RLokXmFwt11FfL4Ly u4uw== X-Gm-Message-State: ACgBeo3nIrwso6sMNCZofRuSsFJLpCYKJqBO155IRqvknhDQt9vrnY8e b7OMC7X3SipHGHtX9p2F9Vc= X-Google-Smtp-Source: AA6agR4a/l8hP1u0P8WpD1zmFedHFbGPzszs2HMqNR8fDJ9LD3T/K1IWhmRhwuymqEvOv4w8sp3YdA== X-Received: by 2002:a05:6512:3503:b0:481:4470:4134 with SMTP id h3-20020a056512350300b0048144704134mr11024002lfs.42.1662069637088; Thu, 01 Sep 2022 15:00:37 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:9c45:8fa1:8ce7:8852? ([2a02:a31a:a240:1700:9c45:8fa1:8ce7:8852]) by smtp.googlemail.com with ESMTPSA id w15-20020a2e160f000000b0025e4e7c016dsm25477ljd.16.2022.09.01.15.00.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Sep 2022 15:00:36 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <30a9d7cd-d9ff-3177-ac6c-e7c1f966d89a@gmail.com> Date: Fri, 2 Sep 2022 00:00:33 +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.0 Subject: Re: [PATCH v2 09/41] drm/connector: Add TV standard property Content-Language: pl To: Maxime Ripard , Maxime Ripard , 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 Cc: 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> In-Reply-To: <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Maxime, 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. > +/** > + * 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< +    /** > +     * @DRM_MODE_TV_MODE_PAL_NC: Seems equivalent to > +     * @DRM_MODE_TV_MODE_PAL_N. > +     */ > +    DRM_MODE_TV_MODE_PAL_NC, AFAIK, the entire reason that "PAL-Nc" is ever mentioned as something separate from PAL-N is a result of a misunderstanding or misreading of the CCIR/ITU documents. See also the posting signed as Alchaemist here: https://en.wikipedia.org/wiki/Talk:PAL#PAL-N_versus_PAL-Nc That being said, we probably want to keep it if we want to remaing compatible with the loads of software and drivers which enumerate those as separate systems. But from a technical standpoint, PAL-N and PAL-Nc (and N/PAL, PAL-CN etc.) are just different "spellings" referring to exactly the same system. > +    /** > +     * @DRM_MODE_TV_MODE_SECAM_K: CCIR System G together with the > +     * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G but > +     * with different channels. > +     */ > +    DRM_MODE_TV_MODE_SECAM_K, > + > +    /** > +     * @DRM_MODE_TV_MODE_SECAM_K1: CCIR System G together with the > +     * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G and > +     * @DRM_MODE_TV_MODE_SECAM_K but with different channels. > +     */ > +    DRM_MODE_TV_MODE_SECAM_K1, Typos: you meant CCIR Systems K and K1, not System G. 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 57092ECAAD2 for ; Thu, 1 Sep 2022 22:00:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E44DD10E348; Thu, 1 Sep 2022 22:00:43 +0000 (UTC) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2DDD610E33B; Thu, 1 Sep 2022 22:00:39 +0000 (UTC) Received: by mail-lf1-x129.google.com with SMTP id bt10so724051lfb.1; Thu, 01 Sep 2022 15:00:39 -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; bh=9ZOA/uLVkdbadD8sl+x2FgrUVnWNaT54IH6CMV7M0qU=; b=LHm7XQKmoioehKLe+x8wv4sg51dxY3iK7GBIf0ie+fcfdWHmpj8uhKVo1qfStRYUDt hYYwKyXLa6F8Vss8qsGXnhsSbaWjrIFZiJWH0w+6WT1drr8SW/5N5uWQUY13CtCu8RT7 XFGF/pp/ZAdp6alq7wI37+qWMkMsD15jW9A1A3zaqPv8x1Ugm06xru39RntLJn/t21Zd Io+z1YLdKsVMwCmBwJgUdIXcFGDcNDdzsiH8DINgDlhluHlE98GV0dVvSpde0N5jFpG/ 4M6RwAzfFXYpV1BXP/VnjdTCqnFT6/utQ9dJtdN/u84FrH7SItMET/4Tm6x8CjaYhOPO 0DtQ== 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; bh=9ZOA/uLVkdbadD8sl+x2FgrUVnWNaT54IH6CMV7M0qU=; b=gGQkfy3UtYK3mMTYfQWTCfVx/9Ze79mtVuNrVg+SoLNrcMtv/qC+b8FnzACzQWXN7/ dYn/jSOEjEhtJKRACSgXtD4gJmDPRweYdOoF04dE16pZo9oNKjTPN+h6u+OK200/lqcX bYhkmhtDZVrj13FbTyKF5ZXWHu25uSLN0evBGsITjvAoXZMdI9hICrFj7hTzHARIdfQh BWwV+g+mjBXG12WKto286WtTk9tN8vCCvmvlHaY0PJNf9g6VmPVWAPwu75KJiKyOyUxV bEoWOcboL7fxkpEQ9mFTDh3gkg+SVBYtZBnr/r7dzHlYuC0+yNhFGQPE4ef6OE5Gg1TU iC1A== X-Gm-Message-State: ACgBeo0jx+LmuBto2+1P/FjTOn/FoQa3M4YNG6cGBEPtpgj2lUfssZJd Wyil5+G/0GV6hmi3FcFmN1s= X-Google-Smtp-Source: AA6agR4a/l8hP1u0P8WpD1zmFedHFbGPzszs2HMqNR8fDJ9LD3T/K1IWhmRhwuymqEvOv4w8sp3YdA== X-Received: by 2002:a05:6512:3503:b0:481:4470:4134 with SMTP id h3-20020a056512350300b0048144704134mr11024002lfs.42.1662069637088; Thu, 01 Sep 2022 15:00:37 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:9c45:8fa1:8ce7:8852? ([2a02:a31a:a240:1700:9c45:8fa1:8ce7:8852]) by smtp.googlemail.com with ESMTPSA id w15-20020a2e160f000000b0025e4e7c016dsm25477ljd.16.2022.09.01.15.00.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Sep 2022 15:00:36 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <30a9d7cd-d9ff-3177-ac6c-e7c1f966d89a@gmail.com> Date: Fri, 2 Sep 2022 00:00:33 +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.0 Subject: Re: [PATCH v2 09/41] drm/connector: Add TV standard property Content-Language: pl To: Maxime Ripard , Maxime Ripard , 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 References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> In-Reply-To: <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> 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: Dom Cobley , Dave Stevenson , nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-sunxi@lists.linux.dev, Hans de Goede , Geert Uytterhoeven , Phil Elwell , linux-arm-kernel@lists.infradead.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Maxime, 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. > +/** > + * 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< +    /** > +     * @DRM_MODE_TV_MODE_PAL_NC: Seems equivalent to > +     * @DRM_MODE_TV_MODE_PAL_N. > +     */ > +    DRM_MODE_TV_MODE_PAL_NC, AFAIK, the entire reason that "PAL-Nc" is ever mentioned as something separate from PAL-N is a result of a misunderstanding or misreading of the CCIR/ITU documents. See also the posting signed as Alchaemist here: https://en.wikipedia.org/wiki/Talk:PAL#PAL-N_versus_PAL-Nc That being said, we probably want to keep it if we want to remaing compatible with the loads of software and drivers which enumerate those as separate systems. But from a technical standpoint, PAL-N and PAL-Nc (and N/PAL, PAL-CN etc.) are just different "spellings" referring to exactly the same system. > +    /** > +     * @DRM_MODE_TV_MODE_SECAM_K: CCIR System G together with the > +     * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G but > +     * with different channels. > +     */ > +    DRM_MODE_TV_MODE_SECAM_K, > + > +    /** > +     * @DRM_MODE_TV_MODE_SECAM_K1: CCIR System G together with the > +     * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G and > +     * @DRM_MODE_TV_MODE_SECAM_K but with different channels. > +     */ > +    DRM_MODE_TV_MODE_SECAM_K1, Typos: you meant CCIR Systems K and K1, not System G. 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 98A55C54EE9 for ; Thu, 1 Sep 2022 22:01:49 +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=ODLTsI3kNqHJJv+9BgO7HOZo+N41tDIOfDbp/h39P0U=; b=H2P1MBGpQjxZHg 4gDzQZh1OSawBDz1V9viCrW2tqUx7lHN9DJNb2iTf+PYLghgnJlw3g248SlmmTx+6GtjoknhkFahw iOjgYZmSU0F9E/wfpngO3dFkDQg5M/bwYbxUd+UoFAMXvVgT0ar6PKuXTs1TqfwB99360+zs9B4L6 j7tZrGwEXAs65QFPYZZffslcfkVAJsf7Yu9LI7EIcZ8hRLqH06qj+PAKTeQh5L5ZnczS9rzasE3pc BAxbyHvl6F8v3s5bQQd2rOhwYLBFoHjOPyBnKRYHzVuG6N8ZlUC/eiJ5134fsMWWX0X5P/oZwu4zF 61KuzSJgiqP191cFcGLQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTsEv-00F5Wp-0S; Thu, 01 Sep 2022 22:00:45 +0000 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTsEr-00F5Pt-KQ for linux-arm-kernel@lists.infradead.org; Thu, 01 Sep 2022 22:00:43 +0000 Received: by mail-lf1-x135.google.com with SMTP id j14so693568lfu.4 for ; Thu, 01 Sep 2022 15:00:38 -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; bh=9ZOA/uLVkdbadD8sl+x2FgrUVnWNaT54IH6CMV7M0qU=; b=LHm7XQKmoioehKLe+x8wv4sg51dxY3iK7GBIf0ie+fcfdWHmpj8uhKVo1qfStRYUDt hYYwKyXLa6F8Vss8qsGXnhsSbaWjrIFZiJWH0w+6WT1drr8SW/5N5uWQUY13CtCu8RT7 XFGF/pp/ZAdp6alq7wI37+qWMkMsD15jW9A1A3zaqPv8x1Ugm06xru39RntLJn/t21Zd Io+z1YLdKsVMwCmBwJgUdIXcFGDcNDdzsiH8DINgDlhluHlE98GV0dVvSpde0N5jFpG/ 4M6RwAzfFXYpV1BXP/VnjdTCqnFT6/utQ9dJtdN/u84FrH7SItMET/4Tm6x8CjaYhOPO 0DtQ== 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; bh=9ZOA/uLVkdbadD8sl+x2FgrUVnWNaT54IH6CMV7M0qU=; b=E80yQXUJIuZR4n4dZsNgfxuLFf5gjWgS5SbUnOkYsfAenDu7gL+SZ+lPF/ZLROn0N7 7C+TrY0K1FokRIrWoQdr+SEt6ZPPXWQDBFomt18lJRz92vCAgEiQ7W8hVfj5efuXzkde oyyNr8yO/dCZusUTG0wwhsM8d6CrQMA62z3L0UhwUVIvOY77n9NHhTqNvvUimPqPbE4a Y8fhegEEa60ed3CczWL5duP5Nh4rh2WNf18cYKwrriXqM6TxydtIeYiw6V0sf3EXMfOI U3nrgeA2Qo6BpN2J+yZpmvzLpp67smUwz+eA1VmgsRaRfALMIndlQYis6n1QFVt7WCmq ajSg== X-Gm-Message-State: ACgBeo0B0i4BOS8W2ObYyvHls/MF2tZlX7GSB8p7RAjaPVrbPFxnKMrt 18dABtqVoJYxxk43HX225NQ= X-Google-Smtp-Source: AA6agR4a/l8hP1u0P8WpD1zmFedHFbGPzszs2HMqNR8fDJ9LD3T/K1IWhmRhwuymqEvOv4w8sp3YdA== X-Received: by 2002:a05:6512:3503:b0:481:4470:4134 with SMTP id h3-20020a056512350300b0048144704134mr11024002lfs.42.1662069637088; Thu, 01 Sep 2022 15:00:37 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:9c45:8fa1:8ce7:8852? ([2a02:a31a:a240:1700:9c45:8fa1:8ce7:8852]) by smtp.googlemail.com with ESMTPSA id w15-20020a2e160f000000b0025e4e7c016dsm25477ljd.16.2022.09.01.15.00.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Sep 2022 15:00:36 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <30a9d7cd-d9ff-3177-ac6c-e7c1f966d89a@gmail.com> Date: Fri, 2 Sep 2022 00:00:33 +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.0 Subject: Re: [PATCH v2 09/41] drm/connector: Add TV standard property Content-Language: pl To: Maxime Ripard , Maxime Ripard , 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 Cc: 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> In-Reply-To: <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220901_150041_693429_CF455ED2 X-CRM114-Status: GOOD ( 28.54 ) 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 SGkgTWF4aW1lLAoKVyBkbml1IDI5LjA4LjIwMjIgbyAxNToxMSwgTWF4aW1lIFJpcGFyZCBwaXN6 ZToKPiBUaGUgVFYgbW9kZSBwcm9wZXJ0eSBoYXMgYmVlbiBhcm91bmQgZm9yIGEgd2hpbGUgbm93 IHRvIHNlbGVjdCBhbmQgZ2V0IHRoZQo+IGN1cnJlbnQgVFYgbW9kZSBvdXRwdXQgb24gYW4gYW5h bG9nIFRWIGNvbm5lY3Rvci4KPgo+IERlc3BpdGUgdGhhdCBwcm9wZXJ0eSBuYW1lIGJlaW5nIGdl bmVyaWMsIGl0cyBjb250ZW50IGlzbid0IGFuZCBoYXMgYmVlbgo+IGRyaXZlci1zcGVjaWZpYyB3 aGljaCBtYWtlcyBpdCBoYXJkIHRvIGJ1aWxkIGFueSBnZW5lcmljIGJlaGF2aW91ciBvbiB0b3AK PiBvZiBpdCwgYm90aCBpbiBrZXJuZWwgYW5kIHVzZXItc3BhY2UuCj4KPiBMZXQncyBjcmVhdGUg YSBuZXcgYml0bWFzayB0diBub3JtIHByb3BlcnR5LCB0aGF0IGNhbiBjb250YWluIGFueSBvZiB0 aGUKPiBhbmFsb2cgVFYgc3RhbmRhcmRzIGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkga2VybmVsIGRy aXZlcnMuIEVhY2ggZHJpdmVyIGNhbgo+IHRoZW4gcGFzcyBpbiBhIGJpdG1hc2sgb2YgdGhlIG1v ZGVzIGl0IHN1cHBvcnRzLgoKVGhpcyBpcyBub3QgYSBiaXRtYXNrIHByb3BlcnR5IGFueW1vcmUs IHlvdSd2ZSBqdXN0IGNoYW5nZWQgaXQgdG8gYW4gZW51bS4KVGhlIGNvbW1pdCBtZXNzYWdlIGlz IG5vdyBtaXNsZWFkaW5nLgoKPiArc3RhdGljIGNvbnN0IHN0cnVjdCBkcm1fcHJvcF9lbnVtX2xp c3QgZHJtX3R2X21vZGVfZW51bV9saXN0W10gPSB7Cj4gK8KgwqAgwqB7IERSTV9NT0RFX1RWX01P REVfTlRTQ180NDMsICJOVFNDLTQ0MyIgfSwKPiArwqDCoCDCoHsgRFJNX01PREVfVFZfTU9ERV9O VFNDX0osICJOVFNDLUoiIH0sCj4gK8KgwqAgwqB7IERSTV9NT0RFX1RWX01PREVfTlRTQ19NLCAi TlRTQy1NIiB9LAo+ICvCoMKgIMKgeyBEUk1fTU9ERV9UVl9NT0RFX1BBTF82MCwgIlBBTC02MCIg fSwKPiArwqDCoCDCoHsgRFJNX01PREVfVFZfTU9ERV9QQUxfQiwgIlBBTC1CIiB9LAo+ICvCoMKg IMKgeyBEUk1fTU9ERV9UVl9NT0RFX1BBTF9ELCAiUEFMLUQiIH0sCj4gK8KgwqAgwqB7IERSTV9N T0RFX1RWX01PREVfUEFMX0csICJQQUwtRyIgfSwKPiArwqDCoCDCoHsgRFJNX01PREVfVFZfTU9E RV9QQUxfSCwgIlBBTC1IIiB9LAo+ICvCoMKgIMKgeyBEUk1fTU9ERV9UVl9NT0RFX1BBTF9JLCAi UEFMLUkiIH0sCj4gK8KgwqAgwqB7IERSTV9NT0RFX1RWX01PREVfUEFMX00sICJQQUwtTSIgfSwK PiArwqDCoCDCoHsgRFJNX01PREVfVFZfTU9ERV9QQUxfTiwgIlBBTC1OIiB9LAo+ICvCoMKgIMKg eyBEUk1fTU9ERV9UVl9NT0RFX1BBTF9OQywgIlBBTC1OYyIgfSwKPiArwqDCoCDCoHsgRFJNX01P REVfVFZfTU9ERV9TRUNBTV82MCwgIlNFQ0FNLTYwIiB9LAo+ICvCoMKgIMKgeyBEUk1fTU9ERV9U Vl9NT0RFX1NFQ0FNX0IsICJTRUNBTS1CIiB9LAo+ICvCoMKgIMKgeyBEUk1fTU9ERV9UVl9NT0RF X1NFQ0FNX0QsICJTRUNBTS1EIiB9LAo+ICvCoMKgIMKgeyBEUk1fTU9ERV9UVl9NT0RFX1NFQ0FN X0csICJTRUNBTS1HIiB9LAo+ICvCoMKgIMKgeyBEUk1fTU9ERV9UVl9NT0RFX1NFQ0FNX0ssICJT RUNBTS1LIiB9LAo+ICvCoMKgIMKgeyBEUk1fTU9ERV9UVl9NT0RFX1NFQ0FNX0sxLCAiU0VDQU0t SzEiIH0sCj4gK8KgwqAgwqB7IERSTV9NT0RFX1RWX01PREVfU0VDQU1fTCwgIlNFQ0FNLUwiIH0s Cj4gK307CgpJIGRpZCBub3QgY29tbWVudCBvbiBpdCB0aGUgbGFzdCB0aW1lLCBidXQgdGhpcyBs aXN0IGxvb2tzIGEgbGl0dGxlIGJpdCByYW5kb20uCgpDb21wYXJlZCB0byB0aGUgc3RhbmRhcmRz IGRlZmluZWQgYnkgVjRMMiwgeW91IGFsc28gZGVmaW5lIFNFQ0FNLTYwIChhIGdvb2QKdGhpbmcg dG8gZGVmaW5lLCBiZWNhdXNlIHdoeSBub3QpLCBidXQgZG9uJ3QgZGVmaW5lIFBBTC1CMSwgUEFM LUQxLCBQQUwtSywKU0VDQU0tSCwgU0VDQU0tTEMgKHdoYXRldmVyIHRoYXQgaXMgLSBwcm9iYWJs eSBqdXN0IGFub3RoZXIgbmFtZSBmb3IgU0VDQU0tTCwKc2VlIG15IGNvbW1lbnQgYWJvdXQgUEFM LU5jIGJlbG93KSwgb3IgTlRTQy1NLUtSIChhIEtvcmVhbiB2YXJpYW50IG9mIE5UU0MpLgoKTGlr ZSBJIG1lbnRpb25lZCBwcmV2aW91c2x5LCBJJ20gcGVyc29uYWxseSBub3QgYSBmYW4gb2YgaW5j bHVkaW5nIGFsbCB0aG9zZQpDQ0lSL0lUVSBzeXN0ZW0gdmFyaWFudHMsIGFzIHRoZXkgZG9uJ3Qg bWVhbiBhbnkgZGlmZmVyZW5jZSB0byB0aGUgb3V0cHV0IHVubGVzcwp0aGVyZSBpcyBhbiBSRiBt b2R1bGF0b3IgaW52b2x2ZWQuIEJ1dCBJIGdldCBpdCB0aGF0IHRoZXkgaGF2ZSBhbHJlYWR5IGJl ZW4gdXNlZAphbmQgcmVncmVzc2luZyBwcm9iYWJseSB3b3VsZG4ndCBiZSBhIHZlcnkgZ29vZCBp ZGVhLiBCdXQgaW4gdGhhdCBjYXNlIGtlZXBpbmcKaXQgY29uc2lzdGVudCB3aXRoIHRoZSBzZXQg b2YgdmFsdWVzIHVzZWQgYnkgVjRMMiB3b3VsZCBiZSB3aXNlLCBJIHRoaW5rLgoKPiArLyoqCj4g KyAqIGRybV9tb2RlX2NyZWF0ZV90dl9wcm9wZXJ0aWVzIC0gY3JlYXRlIFRWIHNwZWNpZmljIGNv bm5lY3RvciBwcm9wZXJ0aWVzCj4gKyAqIEBkZXY6IERSTSBkZXZpY2UKPiArICogQHN1cHBvcnRl ZF90dl9tb2RlczogQml0bWFzayBvZiBUViBtb2RlcyBzdXBwb3J0ZWQgKFNlZSBEUk1fTU9ERV9U Vl9NT0RFXyopCj4gKwo+ICsgKiBDYWxsZWQgYnkgYSBkcml2ZXIncyBUViBpbml0aWFsaXphdGlv biByb3V0aW5lLCB0aGlzIGZ1bmN0aW9uIGNyZWF0ZXMKPiArICogdGhlIFRWIHNwZWNpZmljIGNv bm5lY3RvciBwcm9wZXJ0aWVzIGZvciBhIGdpdmVuIGRldmljZS7CoCBDYWxsZXIgaXMKPiArICog cmVzcG9uc2libGUgZm9yIGFsbG9jYXRpbmcgYSBsaXN0IG9mIGZvcm1hdCBuYW1lcyBhbmQgcGFz c2luZyB0aGVtIHRvCj4gKyAqIHRoaXMgcm91dGluZS4KPiArICoKPiArICogUmV0dXJuczoKPiAr ICogMCBvbiBzdWNjZXNzIG9yIGEgbmVnYXRpdmUgZXJyb3IgY29kZSBvbiBmYWlsdXJlLgo+ICsg Ki8KPiAraW50IGRybV9tb2RlX2NyZWF0ZV90dl9wcm9wZXJ0aWVzKHN0cnVjdCBkcm1fZGV2aWNl ICpkZXYsCj4gK8KgwqAgwqDCoMKgIMKgwqDCoCDCoMKgwqAgwqDCoCB1bnNpZ25lZCBpbnQgc3Vw cG9ydGVkX3R2X21vZGVzKQoKc3VwcG9ydGVkX3R2X21vZGVzIGlzIHN1cHBvc2VkIHRvIGJlIGEg Yml0bWFzayBvZiBCSVQoRFJNX01PREVfVFZfTU9ERV8qKQoob3IgKDE8PERSTV9NT0RFX1RWX01P REVfKikpIHJhdGhlciB0aGFuIERSTV9NT0RFX1RWX01PREVfKiBkaXJlY3RseSwgYnV0IHRoaXMK aXMgbm90IHNhaWQgZXhwbGljaXRseSBhbnl3aGVyZSBpbiB0aGlzIGRvYyBjb21tZW50LgoKPiAr wqDCoCDCoC8qKgo+ICvCoMKgIMKgICogQERSTV9NT0RFX1RWX01PREVfUEFMX05DOiBTZWVtcyBl cXVpdmFsZW50IHRvCj4gK8KgwqAgwqAgKiBARFJNX01PREVfVFZfTU9ERV9QQUxfTi4KPiArwqDC oCDCoCAqLwo+ICvCoMKgIMKgRFJNX01PREVfVFZfTU9ERV9QQUxfTkMsCgpBRkFJSywgdGhlIGVu dGlyZSByZWFzb24gdGhhdCAiUEFMLU5jIiBpcyBldmVyIG1lbnRpb25lZCBhcyBzb21ldGhpbmcg c2VwYXJhdGUKZnJvbSBQQUwtTiBpcyBhIHJlc3VsdCBvZiBhIG1pc3VuZGVyc3RhbmRpbmcgb3Ig bWlzcmVhZGluZyBvZiB0aGUgQ0NJUi9JVFUKZG9jdW1lbnRzLiBTZWUgYWxzbyB0aGUgcG9zdGlu ZyBzaWduZWQgYXMgQWxjaGFlbWlzdCBoZXJlOgpodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lr aS9UYWxrOlBBTCNQQUwtTl92ZXJzdXNfUEFMLU5jCgpUaGF0IGJlaW5nIHNhaWQsIHdlIHByb2Jh Ymx5IHdhbnQgdG8ga2VlcCBpdCBpZiB3ZSB3YW50IHRvIHJlbWFpbmcgY29tcGF0aWJsZQp3aXRo IHRoZSBsb2FkcyBvZiBzb2Z0d2FyZSBhbmQgZHJpdmVycyB3aGljaCBlbnVtZXJhdGUgdGhvc2Ug YXMgc2VwYXJhdGUKc3lzdGVtcy4gQnV0IGZyb20gYSB0ZWNobmljYWwgc3RhbmRwb2ludCwgUEFM LU4gYW5kIFBBTC1OYyAoYW5kIE4vUEFMLCBQQUwtQ04KZXRjLikgYXJlIGp1c3QgZGlmZmVyZW50 ICJzcGVsbGluZ3MiIHJlZmVycmluZyB0byBleGFjdGx5IHRoZSBzYW1lIHN5c3RlbS4KCj4gK8Kg wqAgwqAvKioKPiArwqDCoCDCoCAqIEBEUk1fTU9ERV9UVl9NT0RFX1NFQ0FNX0s6IENDSVIgU3lz dGVtIEcgdG9nZXRoZXIgd2l0aCB0aGUKPiArwqDCoCDCoCAqIFNFQ0FNIGNvbG9yIHN5c3RlbS4g U2ltaWxhciB0byBARFJNX01PREVfVFZfTU9ERV9TRUNBTV9HIGJ1dAo+ICvCoMKgIMKgICogd2l0 aCBkaWZmZXJlbnQgY2hhbm5lbHMuCj4gK8KgwqAgwqAgKi8KPiArwqDCoCDCoERSTV9NT0RFX1RW X01PREVfU0VDQU1fSywKPiArCj4gK8KgwqAgwqAvKioKPiArwqDCoCDCoCAqIEBEUk1fTU9ERV9U Vl9NT0RFX1NFQ0FNX0sxOiBDQ0lSIFN5c3RlbSBHIHRvZ2V0aGVyIHdpdGggdGhlCj4gK8KgwqAg wqAgKiBTRUNBTSBjb2xvciBzeXN0ZW0uIFNpbWlsYXIgdG8gQERSTV9NT0RFX1RWX01PREVfU0VD QU1fRyBhbmQKPiArwqDCoCDCoCAqIEBEUk1fTU9ERV9UVl9NT0RFX1NFQ0FNX0sgYnV0IHdpdGgg ZGlmZmVyZW50IGNoYW5uZWxzLgo+ICvCoMKgIMKgICovCj4gK8KgwqAgwqBEUk1fTU9ERV9UVl9N T0RFX1NFQ0FNX0sxLAoKVHlwb3M6IHlvdSBtZWFudCBDQ0lSIFN5c3RlbXMgSyBhbmQgSzEsIG5v dCBTeXN0ZW0gRy4KCkJlc3QgcmVnYXJkcywKTWF0ZXVzeiBLd2lhdGtvd3NraQoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBt YWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9s aXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= 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 6A9A6ECAAD5 for ; Tue, 6 Sep 2022 12:35:44 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 771A510E67D; Tue, 6 Sep 2022 12:35:42 +0000 (UTC) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2DDD610E33B; Thu, 1 Sep 2022 22:00:39 +0000 (UTC) Received: by mail-lf1-x129.google.com with SMTP id bt10so724051lfb.1; Thu, 01 Sep 2022 15:00:39 -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; bh=9ZOA/uLVkdbadD8sl+x2FgrUVnWNaT54IH6CMV7M0qU=; b=LHm7XQKmoioehKLe+x8wv4sg51dxY3iK7GBIf0ie+fcfdWHmpj8uhKVo1qfStRYUDt hYYwKyXLa6F8Vss8qsGXnhsSbaWjrIFZiJWH0w+6WT1drr8SW/5N5uWQUY13CtCu8RT7 XFGF/pp/ZAdp6alq7wI37+qWMkMsD15jW9A1A3zaqPv8x1Ugm06xru39RntLJn/t21Zd Io+z1YLdKsVMwCmBwJgUdIXcFGDcNDdzsiH8DINgDlhluHlE98GV0dVvSpde0N5jFpG/ 4M6RwAzfFXYpV1BXP/VnjdTCqnFT6/utQ9dJtdN/u84FrH7SItMET/4Tm6x8CjaYhOPO 0DtQ== 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; bh=9ZOA/uLVkdbadD8sl+x2FgrUVnWNaT54IH6CMV7M0qU=; b=gGQkfy3UtYK3mMTYfQWTCfVx/9Ze79mtVuNrVg+SoLNrcMtv/qC+b8FnzACzQWXN7/ dYn/jSOEjEhtJKRACSgXtD4gJmDPRweYdOoF04dE16pZo9oNKjTPN+h6u+OK200/lqcX bYhkmhtDZVrj13FbTyKF5ZXWHu25uSLN0evBGsITjvAoXZMdI9hICrFj7hTzHARIdfQh BWwV+g+mjBXG12WKto286WtTk9tN8vCCvmvlHaY0PJNf9g6VmPVWAPwu75KJiKyOyUxV bEoWOcboL7fxkpEQ9mFTDh3gkg+SVBYtZBnr/r7dzHlYuC0+yNhFGQPE4ef6OE5Gg1TU iC1A== X-Gm-Message-State: ACgBeo0jx+LmuBto2+1P/FjTOn/FoQa3M4YNG6cGBEPtpgj2lUfssZJd Wyil5+G/0GV6hmi3FcFmN1s= X-Google-Smtp-Source: AA6agR4a/l8hP1u0P8WpD1zmFedHFbGPzszs2HMqNR8fDJ9LD3T/K1IWhmRhwuymqEvOv4w8sp3YdA== X-Received: by 2002:a05:6512:3503:b0:481:4470:4134 with SMTP id h3-20020a056512350300b0048144704134mr11024002lfs.42.1662069637088; Thu, 01 Sep 2022 15:00:37 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:9c45:8fa1:8ce7:8852? ([2a02:a31a:a240:1700:9c45:8fa1:8ce7:8852]) by smtp.googlemail.com with ESMTPSA id w15-20020a2e160f000000b0025e4e7c016dsm25477ljd.16.2022.09.01.15.00.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Sep 2022 15:00:36 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <30a9d7cd-d9ff-3177-ac6c-e7c1f966d89a@gmail.com> Date: Fri, 2 Sep 2022 00:00:33 +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.0 Content-Language: pl To: Maxime Ripard , Maxime Ripard , 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 References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> In-Reply-To: <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 06 Sep 2022 12:33:45 +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: Dom Cobley , Dave Stevenson , nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-sunxi@lists.linux.dev, Geert Uytterhoeven , Phil Elwell , linux-arm-kernel@lists.infradead.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Hi Maxime, 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. > +/** > + * 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< +    /** > +     * @DRM_MODE_TV_MODE_PAL_NC: Seems equivalent to > +     * @DRM_MODE_TV_MODE_PAL_N. > +     */ > +    DRM_MODE_TV_MODE_PAL_NC, AFAIK, the entire reason that "PAL-Nc" is ever mentioned as something separate from PAL-N is a result of a misunderstanding or misreading of the CCIR/ITU documents. See also the posting signed as Alchaemist here: https://en.wikipedia.org/wiki/Talk:PAL#PAL-N_versus_PAL-Nc That being said, we probably want to keep it if we want to remaing compatible with the loads of software and drivers which enumerate those as separate systems. But from a technical standpoint, PAL-N and PAL-Nc (and N/PAL, PAL-CN etc.) are just different "spellings" referring to exactly the same system. > +    /** > +     * @DRM_MODE_TV_MODE_SECAM_K: CCIR System G together with the > +     * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G but > +     * with different channels. > +     */ > +    DRM_MODE_TV_MODE_SECAM_K, > + > +    /** > +     * @DRM_MODE_TV_MODE_SECAM_K1: CCIR System G together with the > +     * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G and > +     * @DRM_MODE_TV_MODE_SECAM_K but with different channels. > +     */ > +    DRM_MODE_TV_MODE_SECAM_K1, Typos: you meant CCIR Systems K and K1, not System G. 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 49F1EC38145 for ; Tue, 6 Sep 2022 20:32:27 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E3CC210EAB5; Tue, 6 Sep 2022 20:31:31 +0000 (UTC) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2DDD610E33B; Thu, 1 Sep 2022 22:00:39 +0000 (UTC) Received: by mail-lf1-x129.google.com with SMTP id bt10so724051lfb.1; Thu, 01 Sep 2022 15:00:39 -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; bh=9ZOA/uLVkdbadD8sl+x2FgrUVnWNaT54IH6CMV7M0qU=; b=LHm7XQKmoioehKLe+x8wv4sg51dxY3iK7GBIf0ie+fcfdWHmpj8uhKVo1qfStRYUDt hYYwKyXLa6F8Vss8qsGXnhsSbaWjrIFZiJWH0w+6WT1drr8SW/5N5uWQUY13CtCu8RT7 XFGF/pp/ZAdp6alq7wI37+qWMkMsD15jW9A1A3zaqPv8x1Ugm06xru39RntLJn/t21Zd Io+z1YLdKsVMwCmBwJgUdIXcFGDcNDdzsiH8DINgDlhluHlE98GV0dVvSpde0N5jFpG/ 4M6RwAzfFXYpV1BXP/VnjdTCqnFT6/utQ9dJtdN/u84FrH7SItMET/4Tm6x8CjaYhOPO 0DtQ== 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; bh=9ZOA/uLVkdbadD8sl+x2FgrUVnWNaT54IH6CMV7M0qU=; b=gGQkfy3UtYK3mMTYfQWTCfVx/9Ze79mtVuNrVg+SoLNrcMtv/qC+b8FnzACzQWXN7/ dYn/jSOEjEhtJKRACSgXtD4gJmDPRweYdOoF04dE16pZo9oNKjTPN+h6u+OK200/lqcX bYhkmhtDZVrj13FbTyKF5ZXWHu25uSLN0evBGsITjvAoXZMdI9hICrFj7hTzHARIdfQh BWwV+g+mjBXG12WKto286WtTk9tN8vCCvmvlHaY0PJNf9g6VmPVWAPwu75KJiKyOyUxV bEoWOcboL7fxkpEQ9mFTDh3gkg+SVBYtZBnr/r7dzHlYuC0+yNhFGQPE4ef6OE5Gg1TU iC1A== X-Gm-Message-State: ACgBeo0jx+LmuBto2+1P/FjTOn/FoQa3M4YNG6cGBEPtpgj2lUfssZJd Wyil5+G/0GV6hmi3FcFmN1s= X-Google-Smtp-Source: AA6agR4a/l8hP1u0P8WpD1zmFedHFbGPzszs2HMqNR8fDJ9LD3T/K1IWhmRhwuymqEvOv4w8sp3YdA== X-Received: by 2002:a05:6512:3503:b0:481:4470:4134 with SMTP id h3-20020a056512350300b0048144704134mr11024002lfs.42.1662069637088; Thu, 01 Sep 2022 15:00:37 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:9c45:8fa1:8ce7:8852? ([2a02:a31a:a240:1700:9c45:8fa1:8ce7:8852]) by smtp.googlemail.com with ESMTPSA id w15-20020a2e160f000000b0025e4e7c016dsm25477ljd.16.2022.09.01.15.00.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Sep 2022 15:00:36 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <30a9d7cd-d9ff-3177-ac6c-e7c1f966d89a@gmail.com> Date: Fri, 2 Sep 2022 00:00:33 +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.0 Content-Language: pl To: Maxime Ripard , Maxime Ripard , 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 References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> In-Reply-To: <20220728-rpi-analog-tv-properties-v2-9-459522d653a7@cerno.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 06 Sep 2022 20:31:03 +0000 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: Dom Cobley , nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-sunxi@lists.linux.dev, Hans de Goede , Geert Uytterhoeven , Phil Elwell , linux-arm-kernel@lists.infradead.org Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" Hi Maxime, 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. > +/** > + * 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< +    /** > +     * @DRM_MODE_TV_MODE_PAL_NC: Seems equivalent to > +     * @DRM_MODE_TV_MODE_PAL_N. > +     */ > +    DRM_MODE_TV_MODE_PAL_NC, AFAIK, the entire reason that "PAL-Nc" is ever mentioned as something separate from PAL-N is a result of a misunderstanding or misreading of the CCIR/ITU documents. See also the posting signed as Alchaemist here: https://en.wikipedia.org/wiki/Talk:PAL#PAL-N_versus_PAL-Nc That being said, we probably want to keep it if we want to remaing compatible with the loads of software and drivers which enumerate those as separate systems. But from a technical standpoint, PAL-N and PAL-Nc (and N/PAL, PAL-CN etc.) are just different "spellings" referring to exactly the same system. > +    /** > +     * @DRM_MODE_TV_MODE_SECAM_K: CCIR System G together with the > +     * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G but > +     * with different channels. > +     */ > +    DRM_MODE_TV_MODE_SECAM_K, > + > +    /** > +     * @DRM_MODE_TV_MODE_SECAM_K1: CCIR System G together with the > +     * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G and > +     * @DRM_MODE_TV_MODE_SECAM_K but with different channels. > +     */ > +    DRM_MODE_TV_MODE_SECAM_K1, Typos: you meant CCIR Systems K and K1, not System G. Best regards, Mateusz Kwiatkowski