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 33065C4332F for ; Tue, 18 Oct 2022 20:58:41 +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:Reply-To: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:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kc6XcmZ6Pb6dGa5lWb1jf+CQc00yWKLz2sbMbdROFyc=; b=dOP59RmmfSGHOD gBKkBXe8yMs4I7ksuY6mRISHWlKhe75ETX1GF/R6CkMOkGrGqkZtUxUUhpRYoXNz9Nos82I5qA0Zn sPYfH2GmGso1Hg2VPQWUULv8x2I+sIRhdgPEuIoBLhrk36fdacT7WJwlV8eBbtpwbicVQ4vlnil/b HkbY5bptqU0jePDzIiTp3UjdYoisxgH48aHTSTcVPhteJO3hxIjCJK9ifue27gHqmsBXTWimgGedP HF9V1++uUK2R7GHKX3VGmKRJQJyYjSfmN1tWa/Idg1rvdzvZVUraqToXJE/BWZqqNAQsB5AtZeq8a aciG2HFlcXA9SN6WVXVQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1okteG-00ARGi-Sq; Tue, 18 Oct 2022 20:57:17 +0000 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1okteD-00ARG5-CF for linux-arm-kernel@lists.infradead.org; Tue, 18 Oct 2022 20:57:14 +0000 Received: by mail-lf1-x12a.google.com with SMTP id bp15so24736816lfb.13 for ; Tue, 18 Oct 2022 13:57:12 -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:reply-to:user-agent:mime-version:date :message-id:from:from:to:cc:subject:date:message-id:reply-to; bh=4q8+ZZXGKoh6iTQurAmJvf03RKoxifLtlwxrMQru1hE=; b=kt8lC+lO4gSY3YG0906oJiNdGLU7GhkVYc9H88KhNuvwjumuuchbdPapkO7dxBf/Qy BoDMNcubA39QyDexTULFTiZaU7aDUsPZdwQojRw+xlCeZ2FP/rlSY9fvBGCEeu5NgYE1 zVoh9LYbcej1ow4N6cLbaE+lDZeOB1v/1BSRHabYjz6zOJf2NcUenT+Ap/6lzQwSiK/I mlfYogp/zJo5VBiA1eANhCvnKdKTUeB/E4rMC8r+poPJuWlQldvWIkta/4sPXBwuMnDH 8xdUvhBvP4s3zBZV8Ig0pbp7QaiLgQRGGd2Qn8+rLaxzbul2vaXrnjy/QMa5jir9u/45 pCvg== 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:reply-to:user-agent:mime-version:date :message-id:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4q8+ZZXGKoh6iTQurAmJvf03RKoxifLtlwxrMQru1hE=; b=abFmZTUD1Q6MmlsT0u6nZex2bjWJmZv2TcEfs7YjbIj6HtS6NlESXnMVhoHWvN3fzt Ede4aEm6XNV5F7TLozP9+3M0vfFU2NgmOuWB3MWPE6JZYqnbNMkDcUm6tLP5Z9m5ZFop rkXFJ2OfCg00FotoTWgK+fjR5WjGje+XWehYvsWavKcAm0CORC47Sj9hlWUhwOrY4/H/ lSfPnhRJXl2wKLZb453kq9+3N4yh5EEbUK8gJ+RPXdoBRi0MG1aJ5VaFg3hfP0RISjcO AkuON9iAZhAvNEI2sAJLxduBlGVfJTADwiMuDDojWPLgMa+7ZkDhaQWWAH1cNx5moigI p7DA== X-Gm-Message-State: ACrzQf1hz1EWxmTOFhDG7XoXsLO7Ht4sBOR2NrxPBHp2wWGfccZbkPWs yyFwVNFW7nDAEwH2Q1IGeAg= X-Google-Smtp-Source: AMsMyM43gEnq7ci5pkLxJm4400YhMYoE1+4aaJJ/DU7cyGERdBh2fCJRUyqe3H9D3aDzTea6EsoYiQ== X-Received: by 2002:a05:6512:114a:b0:4a2:58a3:95f2 with SMTP id m10-20020a056512114a00b004a258a395f2mr1687359lfg.7.1666126629466; Tue, 18 Oct 2022 13:57:09 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:ade4:dc4:81f3:286b? ([2a02:a31a:a240:1700:ade4:dc4:81f3:286b]) by smtp.googlemail.com with ESMTPSA id u13-20020a05651220cd00b0049d83646ce7sm2002435lfr.110.2022.10.18.13.57.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Oct 2022 13:57:08 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <0afdeda7-558e-647f-ef28-1fcd80807c1b@gmail.com> Date: Tue, 18 Oct 2022 22:57:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Subject: Re: [PATCH] drm/vc4: vec: Add support for PAL-60 Content-Language: pl To: Maxime Ripard Cc: Karol Herbst , Jani Nikula , Tvrtko Ursulin , Daniel Vetter , Maarten Lankhorst , David Airlie , Joonas Lahtinen , Lyude Paul , Emma Anholt , Chen-Yu Tsai , Samuel Holland , Ben Skeggs , Thomas Zimmermann , Rodrigo Vivi , Jernej Skrabec , Dom Cobley , linux-sunxi@lists.linux.dev, Dave Stevenson , =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org, Geert Uytterhoeven , linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, Hans de Goede , Phil Elwell References: <20220728-rpi-analog-tv-properties-v5-0-d841cc64fe4b@cerno.tech> <20220728-rpi-analog-tv-properties-v5-21-d841cc64fe4b@cerno.tech> <93bf9fcc-c645-b042-011f-8f1fc957af48@gmail.com> <20221018083153.okkqpd5ccfrnwdj3@houat> In-Reply-To: <20221018083153.okkqpd5ccfrnwdj3@houat> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221018_135713_492018_3E671C90 X-CRM114-Status: GOOD ( 24.22 ) 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: , Reply-To: kfyatek+publicgit@gmail.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Maxime, W dniu 18.10.2022 o 10:31, Maxime Ripard pisze: > Hi, > > On Sun, Oct 16, 2022 at 09:46:49PM +0200, Mateusz Kwiatkowski wrote: >> @@ -308,14 +324,15 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = { >> }; >> >> static inline const struct vc4_vec_tv_mode * >> -vc4_vec_tv_mode_lookup(unsigned int mode) >> +vc4_vec_tv_mode_lookup(unsigned int mode, u16 htotal) >> { >> unsigned int i; >> >> for (i = 0; i < ARRAY_SIZE(vc4_vec_tv_modes); i++) { >> const struct vc4_vec_tv_mode *tv_mode = &vc4_vec_tv_modes[i]; >> >> - if (tv_mode->mode == mode) >> + if (tv_mode->mode == mode && >> + tv_mode->expected_htotal == htotal) >> return tv_mode; > > Is there any reason we're not using the refresh rate to filter this? It > seems more natural to me. Let me give you an example first. There are actually two ways to configure PAL-60-ish mode on VC4/VEC: a) Modeline 13.5 720 734 798 858 480 487 493 525 Interlace, standard registers set to VEC_CONFIG0_PAL_M_STD, custom frequency enabled and set to 0x2a098acb; Setting the standard registers to "PAL-M" puts the VEC in true 59.94 Hz mode, so the video timings are identical as for NTSC (or PAL-M), and the custom frequency makes the color subcarrier compatible with regular PAL receivers. This is the "true" PAL-60, thanks to the true System M timings. a) Modeline 13.5 720 740 804 864 480 486 492 525 Interlace, standards registers set to VEC_CONFIG0_PAL with standard frequency; This is a "fake" PAL-60 mode, the refresh rate is actually ~59.524 Hz. Most "NTSC" sets will be able to sync with this mode no problem, but the VEC is actually operating in its 50 Hz mode - it's just the "premature" vertical sync signal causes it to output something that is similar to the 525-line system, however strictly speaking non-standard due to lower horizontal sync frequency. This comes down to the fact that: - When VEC's standard registers are set to VEC_CONFIG0_NTSC_STD or VEC_CONFIG0_PAL_M_STD, it operates in the "CCIR System M" mode, expects htotal to be exactly 858 pixels (and it will generate horizontal sync pulse every 858 pixels on its own regardless of what comes out of the PV - so there will be garbage on screen if you set it to anything else), and vtotal to be 525 lines. It will not accept vtotal that's any higher (it will generate its own vertical sync as demanded by System M if not triggered by the PV), but it can be lower - resulting in modes that are non-standard, but otherwise valid. - Likewise, when the registers are set to VEC_CONFIG0_PAL_BDGHI_STD, VEC_CONFIG0_PAL_N_STD or VEC_CONFIG0_SECAM_STD (SECAM is a bit special, but that's irrelevant here), it operates in the "CCIR System B/D/G/H/I/N" mode, and likewise, expects htotal to be exactly 864 pixels (garbage on screen otherwise), vtotal limit is 625 lines, etc. Checking for the refresh rate would only work for standard-compliant modes and have the potential of completely breaking on any custom modes. Conversely, checking for htotal aligns perfectly with the limitations of the hardware, and allows the user to set any modeline that the hardware is able to output with any level of sanity. Footnote: all this information on VEC's behavior comes from my own experimentation, messing around with its registers and seeing what happens (both on screen and on an oscilloscope). I've never seen any Broadcom docs on this chip, so it's by no means official. Best regards, Mateusz Kwiatkowski _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel