Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp5917960rwb; Wed, 7 Sep 2022 09:48:15 -0700 (PDT) X-Google-Smtp-Source: AA6agR7Y7PPvw++M82cr0QNv2UlDlQNsYHJ7UlR7BYMBNswlPxans9gV5BDROzeWJFzTe92/kYxw X-Received: by 2002:a05:6402:3596:b0:447:11ea:362d with SMTP id y22-20020a056402359600b0044711ea362dmr3876972edc.117.1662569295513; Wed, 07 Sep 2022 09:48:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662569295; cv=none; d=google.com; s=arc-20160816; b=r8nsmb1L9LnGszV8PPD5GmLCOqkwVEwU2cvtk8/+cZo+3rzxfDNTIQt4oCEVtW6M21 aMoWvNkz7ulGHq0tnzfEAekd9Rt0c3CwXh0jovTB1nAOTosP7ecD2lRVUfmHVvayOb/+ enF0qU+5EmbGPvyDiUsuUAaKahOmsgWj3PS7OP7mwcL32KUFL2udyarMj7rwYBfQRhoY 7O0LBAovHg3X0gquZkwq0CT/07j2TPoahxz7y32IXodY5zRqZyiKo3/nxOcUc+61vUVi /AHolfygNHg9P2ZhBNKIf0dV5wJBN1ueY9tV9dC8tY71DXXu82HtHJw/v4MIcMYiblS5 33Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id :dkim-signature; bh=9N6URuex089GHLCqcq5OwqFtSiBdOniUj0H5n1oTE7U=; b=VZFyg0WC4EIf3jF9iZ2nhwxv+/iCccqyCLSPzb8HxA2ARl2+vtdj9Js1qaQYge5+lA 00NSNf8pw84M8uU4mtnO3Ofh1s+Skv6pZaVcsYuDKbXBjUkaadtSYPNMLaKVjsxRo7bi kaFGyeNRRnWKDyRx3XIuB3WzPfF4B6LcLm0SLgZXT18DmygTt5+M2rvUGyJ0Av6u0BKf qIQEEAKfnpXX5XwpyENKF2QgBeFVjIuKd9Vb0dVduqCMEt+k0trFpg3SBdFPcW5chX94 FFDKT34WX8zagjvwcoCIRBAwnHzHRTukg2yUQhdNHBFi7WVDPBh62S9vJ3A98AwWyH4F tXNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@tronnes.org header.s=ds202112 header.b=CJU1sQi7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=tronnes.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c13-20020a170906340d00b0073099685059si10505626ejb.591.2022.09.07.09.47.49; Wed, 07 Sep 2022 09:48:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@tronnes.org header.s=ds202112 header.b=CJU1sQi7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=tronnes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229445AbiIGQpd (ORCPT + 99 others); Wed, 7 Sep 2022 12:45:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229699AbiIGQpN (ORCPT ); Wed, 7 Sep 2022 12:45:13 -0400 Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C6194B4A9 for ; Wed, 7 Sep 2022 09:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tronnes.org ; s=ds202112; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=9N6URuex089GHLCqcq5OwqFtSiBdOniUj0H5n1oTE7U=; b=CJU1sQi7bpE3/vdL5WN6zgzECp HHbmXjaIPD3FMzb3sar3e+/e26bryRNwv1KdQp0IoqozvMQr2DTCs0jssE29RdyuEJv/rK8lX2WJK w2o8NMpLEUrJk30eOPVkwTn6wxVW0kBbnnB7MtXliQTOvmqSHodwkDV+uwCs5gbOmF0eJBvZUDQ2z e2JcgdbF+68jArc56Os1nj6UK+Y6uy14uY/Jul33K5WJlLdVPkusBSWmxB8/5J+Jivi1yAAY2SqaJ uYShCgxeLJVticyfntOzrgiAdo8jbBv692avVuEnjNwP7CDEGvsUfDGMPAMFYNmIHjp8I7qWEiYf6 MKMfxSqg==; Received: from [2a01:799:961:d200:cca0:57ac:c55d:a485] (port=53589) by smtp.domeneshop.no with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVyAf-0000KB-VO; Wed, 07 Sep 2022 18:45:01 +0200 Message-ID: Date: Wed, 7 Sep 2022 18:44:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH v2 00/41] drm: Analog TV Improvements To: Stefan Wahren , 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 , Emma Anholt , Daniel Vetter , Joonas Lahtinen , Dom Cobley , Hans de Goede , linux-arm-kernel@lists.infradead.org, Phil Elwell , intel-gfx@lists.freedesktop.org, Dave Stevenson , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org, linux-sunxi@lists.linux.dev, Mateusz Kwiatkowski , Geert Uytterhoeven , =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <24e09a29-6d04-3b1e-63ce-cd3c31d350e2@tronnes.org> <020d44e6-884b-a817-8265-3461638cac71@tronnes.org> <20220905145729.ln675jko3aw6sgzs@houat> <965de5c0-bc6a-7210-c946-b916ae2219fc@i2se.com> From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= In-Reply-To: <965de5c0-bc6a-7210-c946-b916ae2219fc@i2se.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Den 07.09.2022 12.36, skrev Stefan Wahren: > Hi Maxime, > > Am 05.09.22 um 16:57 schrieb Maxime Ripard: >> On Fri, Sep 02, 2022 at 01:28:16PM +0200, Noralf Trønnes wrote: >>> >>> Den 01.09.2022 21.35, skrev Noralf Trønnes: >>>> >>>> I have finally found a workaround for my kernel hangs. >>>> >>>> Dom had a look at my kernel and found that the VideoCore was fine, and >>>> he said this: >>>> >>>>> That suggests cause of lockup was on arm side rather than VC side. >>>>> >>>>> But it's hard to diagnose further. Once you've had a peripheral not >>>>> respond, the AXI bus locks up and no further operations are possible. >>>>> Usual causes of this are required clocks being stopped or domains >>>>> disabled and then trying to access the hardware. >>>>> >>>> So when I got this on my 64-bit build: >>>> >>>> [  166.702171] SError Interrupt on CPU1, code 0x00000000bf000002 -- >>>> SError >>>> [  166.702187] CPU: 1 PID: 8 Comm: kworker/u8:0 Tainted: G        W >>>>      5.19.0-rc6-00096-gba7973977976-dirty #1 >>>> [  166.702200] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) >>>> [  166.702206] Workqueue: events_freezable_power_ >>>> thermal_zone_device_check >>>> [  166.702231] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS >>>> BTYPE=--) >>>> [  166.702242] pc : regmap_mmio_read32le+0x10/0x28 >>>> [  166.702261] lr : regmap_mmio_read+0x44/0x70 >>>> ... >>>> [  166.702606]  bcm2711_get_temp+0x58/0xb0 [bcm2711_thermal] >>>> >>>> I wondered if that reg read was stalled due to a clock being stopped. >>>> >>>> Lo and behold, disabling runtime pm and keeping the vec clock running >>>> all the time fixed it[1]. >>>> >>>> I don't know what the problem is, but at least I can now test this >>>> patchset. >>>> >>>> [1] https://gist.github.com/notro/23b984e7fa05cfbda2db50a421cac065 >>>> >>> It turns out I didn't have to disable runtime pm: >>> https://gist.github.com/notro/0adcfcb12460b54e54458afe11dc8ea2 >> If the bcm2711_thermal IP needs that clock to be enabled, it should grab >> a reference itself, but it looks like even the device tree binding >> doesn't ask for one. > The missing clock in the device tree binding is expected, because > despite of the code there is not much information about the BCM2711 > clock tree. But i'm skeptical that the AVS IP actually needs the VEC > clock, i think it's more likely that the VEC clock parent is changed and > that cause this issue. I could take care of the bcm2711 binding & driver > if i know which clock is really necessary. Seems you're right, keeping the parent always enabled is enough: clk_prepare_enable(clk_get_parent(vec->clock)); // pllc_per I tried enabling just the grandparent clock as well, but that didn't help. Without the clock hack it seems the hang occurs when switching between NTSC and PAL, at most I've been able to do that 4-5 times before it hangs. For a while it looked like fbdev/fbcon had a play in this, but then I realised that it just gave me a NTSC mode to start from and to go back to when qutting modetest. Noralf.