From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F50317E6 for ; Sat, 24 Sep 2022 15:36:47 +0000 (UTC) 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=DP3zUOJkBK29CjZ1hWIKGa38wlT1g1yzlrFvDjg2ysg=; b=nxiTXcG+1m14DovcWFz7qiYOQ+ 1YsfTMoxhEjyePsnyUaogiNTaZiOu5ODbzq1GCKFP9tA314nUbYJ9GBPUpzaZ3gBJqsVkKnp3ELI3 qeHb327ypE1IoTHHSw+f7xMLdYWvvjwYjYeHnjvWMwHmh631zxx1AAN3n30dsK08rRzIXCVtPgqYu EhvEcmiD+7SxTJVnEo6soadcZlrkzvemM3Quws+gN28ItnYSWc2qNTC2EbGSH8utihaIWnDyhbi9/ xRi2Nd1S9IKuPsTav7KemdhK8UxvmeHGxfYTPBq2+9RBfgFueCq7xggL3fnYfZ0c/BTAovVV8FrYl rTvyK86w==; Received: from [2a01:799:961:d200:8cf6:761:40ec:1ff7] (port=51599) by smtp.domeneshop.no with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oc79W-0006Fk-UY; Sat, 24 Sep 2022 17:33:14 +0200 Message-ID: <1220a3ef-86cf-78ae-07b6-16eb091c7dcc@tronnes.org> Date: Sat, 24 Sep 2022 17:33:05 +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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [PATCH v2 00/41] drm: Analog TV Improvements To: Maxime Ripard Cc: Stefan Wahren , 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> <20220921140324.sbeadfr7kz4avqcr@houat> From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= In-Reply-To: <20220921140324.sbeadfr7kz4avqcr@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Den 21.09.2022 16.03, skrev Maxime Ripard: > On Wed, Sep 07, 2022 at 06:44:53PM +0200, Noralf Trønnes wrote: >> >> >> 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. > > Yeah, adding tracing to the clock framework shows that it indeed > disables PLLC_PER. So there's probably some other device that depends on > it but doesn't take a reference to it. > > I had a look, but it's not really obvious what that might be. > > This patch makes sure that the PLL*_PER are never disabled, could you > test it? It seems to work for me. > > > diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c > index 48a1eb9f2d55..3839261ee419 100644 > --- a/drivers/clk/bcm/clk-bcm2835.c > +++ b/drivers/clk/bcm/clk-bcm2835.c > @@ -1675,7 +1675,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLA_LOADPER, > .hold_mask = CM_PLLA_HOLDPER, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > [BCM2835_PLLA_DSI0] = REGISTER_PLL_DIV( > SOC_ALL, > .name = "plla_dsi0", > @@ -1784,7 +1784,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLC_LOADPER, > .hold_mask = CM_PLLC_HOLDPER, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > Yes, this worked, but it's enough to mark pllc_per as critical. Noralf. > /* > * PLLD is the display PLL, used to drive DSI display panels. > @@ -1891,7 +1891,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLH_LOADAUX, > .hold_mask = 0, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > [BCM2835_PLLH_PIX] = REGISTER_PLL_DIV( > SOC_BCM2835, > .name = "pllh_pix", > > > Maxime 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 153D9C32771 for ; Sat, 24 Sep 2022 15:33:23 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 028F110E61D; Sat, 24 Sep 2022 15:33:23 +0000 (UTC) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 12C6B10E0B6; Sat, 24 Sep 2022 15:33:18 +0000 (UTC) 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=DP3zUOJkBK29CjZ1hWIKGa38wlT1g1yzlrFvDjg2ysg=; b=nxiTXcG+1m14DovcWFz7qiYOQ+ 1YsfTMoxhEjyePsnyUaogiNTaZiOu5ODbzq1GCKFP9tA314nUbYJ9GBPUpzaZ3gBJqsVkKnp3ELI3 qeHb327ypE1IoTHHSw+f7xMLdYWvvjwYjYeHnjvWMwHmh631zxx1AAN3n30dsK08rRzIXCVtPgqYu EhvEcmiD+7SxTJVnEo6soadcZlrkzvemM3Quws+gN28ItnYSWc2qNTC2EbGSH8utihaIWnDyhbi9/ xRi2Nd1S9IKuPsTav7KemdhK8UxvmeHGxfYTPBq2+9RBfgFueCq7xggL3fnYfZ0c/BTAovVV8FrYl rTvyK86w==; Received: from [2a01:799:961:d200:8cf6:761:40ec:1ff7] (port=51599) by smtp.domeneshop.no with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oc79W-0006Fk-UY; Sat, 24 Sep 2022 17:33:14 +0200 Message-ID: <1220a3ef-86cf-78ae-07b6-16eb091c7dcc@tronnes.org> Date: Sat, 24 Sep 2022 17:33:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 To: Maxime Ripard 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> <20220921140324.sbeadfr7kz4avqcr@houat> From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= In-Reply-To: <20220921140324.sbeadfr7kz4avqcr@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Nouveau] [PATCH v2 00/41] drm: Analog TV Improvements 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 , Stefan Wahren , 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, Mateusz Kwiatkowski , =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , Philipp Zabel Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" Den 21.09.2022 16.03, skrev Maxime Ripard: > On Wed, Sep 07, 2022 at 06:44:53PM +0200, Noralf Trønnes wrote: >> >> >> 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. > > Yeah, adding tracing to the clock framework shows that it indeed > disables PLLC_PER. So there's probably some other device that depends on > it but doesn't take a reference to it. > > I had a look, but it's not really obvious what that might be. > > This patch makes sure that the PLL*_PER are never disabled, could you > test it? It seems to work for me. > > > diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c > index 48a1eb9f2d55..3839261ee419 100644 > --- a/drivers/clk/bcm/clk-bcm2835.c > +++ b/drivers/clk/bcm/clk-bcm2835.c > @@ -1675,7 +1675,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLA_LOADPER, > .hold_mask = CM_PLLA_HOLDPER, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > [BCM2835_PLLA_DSI0] = REGISTER_PLL_DIV( > SOC_ALL, > .name = "plla_dsi0", > @@ -1784,7 +1784,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLC_LOADPER, > .hold_mask = CM_PLLC_HOLDPER, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > Yes, this worked, but it's enough to mark pllc_per as critical. Noralf. > /* > * PLLD is the display PLL, used to drive DSI display panels. > @@ -1891,7 +1891,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLH_LOADAUX, > .hold_mask = 0, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > [BCM2835_PLLH_PIX] = REGISTER_PLL_DIV( > SOC_BCM2835, > .name = "pllh_pix", > > > Maxime 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 391E1C32771 for ; Sat, 24 Sep 2022 15:33:33 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 84E6A10E0B6; Sat, 24 Sep 2022 15:33:24 +0000 (UTC) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 12C6B10E0B6; Sat, 24 Sep 2022 15:33:18 +0000 (UTC) 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=DP3zUOJkBK29CjZ1hWIKGa38wlT1g1yzlrFvDjg2ysg=; b=nxiTXcG+1m14DovcWFz7qiYOQ+ 1YsfTMoxhEjyePsnyUaogiNTaZiOu5ODbzq1GCKFP9tA314nUbYJ9GBPUpzaZ3gBJqsVkKnp3ELI3 qeHb327ypE1IoTHHSw+f7xMLdYWvvjwYjYeHnjvWMwHmh631zxx1AAN3n30dsK08rRzIXCVtPgqYu EhvEcmiD+7SxTJVnEo6soadcZlrkzvemM3Quws+gN28ItnYSWc2qNTC2EbGSH8utihaIWnDyhbi9/ xRi2Nd1S9IKuPsTav7KemdhK8UxvmeHGxfYTPBq2+9RBfgFueCq7xggL3fnYfZ0c/BTAovVV8FrYl rTvyK86w==; Received: from [2a01:799:961:d200:8cf6:761:40ec:1ff7] (port=51599) by smtp.domeneshop.no with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oc79W-0006Fk-UY; Sat, 24 Sep 2022 17:33:14 +0200 Message-ID: <1220a3ef-86cf-78ae-07b6-16eb091c7dcc@tronnes.org> Date: Sat, 24 Sep 2022 17:33:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [PATCH v2 00/41] drm: Analog TV Improvements To: Maxime Ripard 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> <20220921140324.sbeadfr7kz4avqcr@houat> From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= In-Reply-To: <20220921140324.sbeadfr7kz4avqcr@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 , Stefan Wahren , 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, Mateusz Kwiatkowski , =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Den 21.09.2022 16.03, skrev Maxime Ripard: > On Wed, Sep 07, 2022 at 06:44:53PM +0200, Noralf Trønnes wrote: >> >> >> 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. > > Yeah, adding tracing to the clock framework shows that it indeed > disables PLLC_PER. So there's probably some other device that depends on > it but doesn't take a reference to it. > > I had a look, but it's not really obvious what that might be. > > This patch makes sure that the PLL*_PER are never disabled, could you > test it? It seems to work for me. > > > diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c > index 48a1eb9f2d55..3839261ee419 100644 > --- a/drivers/clk/bcm/clk-bcm2835.c > +++ b/drivers/clk/bcm/clk-bcm2835.c > @@ -1675,7 +1675,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLA_LOADPER, > .hold_mask = CM_PLLA_HOLDPER, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > [BCM2835_PLLA_DSI0] = REGISTER_PLL_DIV( > SOC_ALL, > .name = "plla_dsi0", > @@ -1784,7 +1784,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLC_LOADPER, > .hold_mask = CM_PLLC_HOLDPER, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > Yes, this worked, but it's enough to mark pllc_per as critical. Noralf. > /* > * PLLD is the display PLL, used to drive DSI display panels. > @@ -1891,7 +1891,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLH_LOADAUX, > .hold_mask = 0, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > [BCM2835_PLLH_PIX] = REGISTER_PLL_DIV( > SOC_BCM2835, > .name = "pllh_pix", > > > Maxime 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 F3F5FC07E9D for ; Sat, 24 Sep 2022 15:36: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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WUVGNsHIPn3E2q/xxGg9Y6akXOcoHwGRWmCj1ul7LM8=; b=fTSJjhyJMX0i7f BInofAuUzK/Y4oOicozGVCXaEZP99xe8cc6LzJXgEqmEBk9E6hBmMkcJcErgZtA5Ra3uvX2BZC4Vz Vc58BupS11BNkMWzjkLIy5WIJDHMA5YU8IstF8ao2/c3ir/Ier/xfSxcyK4IPLLQ2t3o34f7FHeDr pqkyMRhUM2upMx8DrgCbcKSVYdqZJ6zArR71fYcTlQFix6QGunF7/Cf6ajOI3DHkZvLSAKBXZMA7x 65cdL0zo4cf6yc7yHq4jBNnUbmtM5DKG/x8M0w4h521HxX89JvmeQhTR86W3Hw6HjJW1xiYYY3I6K t/kwpXZDG1rH+yjGFMrQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oc7Bi-007fjo-SX; Sat, 24 Sep 2022 15:35:31 +0000 Received: from smtp.domeneshop.no ([2a01:5b40:0:3005::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oc79e-007els-PL for linux-arm-kernel@lists.infradead.org; Sat, 24 Sep 2022 15:33:26 +0000 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=DP3zUOJkBK29CjZ1hWIKGa38wlT1g1yzlrFvDjg2ysg=; b=nxiTXcG+1m14DovcWFz7qiYOQ+ 1YsfTMoxhEjyePsnyUaogiNTaZiOu5ODbzq1GCKFP9tA314nUbYJ9GBPUpzaZ3gBJqsVkKnp3ELI3 qeHb327ypE1IoTHHSw+f7xMLdYWvvjwYjYeHnjvWMwHmh631zxx1AAN3n30dsK08rRzIXCVtPgqYu EhvEcmiD+7SxTJVnEo6soadcZlrkzvemM3Quws+gN28ItnYSWc2qNTC2EbGSH8utihaIWnDyhbi9/ xRi2Nd1S9IKuPsTav7KemdhK8UxvmeHGxfYTPBq2+9RBfgFueCq7xggL3fnYfZ0c/BTAovVV8FrYl rTvyK86w==; Received: from [2a01:799:961:d200:8cf6:761:40ec:1ff7] (port=51599) by smtp.domeneshop.no with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oc79W-0006Fk-UY; Sat, 24 Sep 2022 17:33:14 +0200 Message-ID: <1220a3ef-86cf-78ae-07b6-16eb091c7dcc@tronnes.org> Date: Sat, 24 Sep 2022 17:33:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [PATCH v2 00/41] drm: Analog TV Improvements To: Maxime Ripard Cc: Stefan Wahren , 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> <20220921140324.sbeadfr7kz4avqcr@houat> From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= In-Reply-To: <20220921140324.sbeadfr7kz4avqcr@houat> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220924_083322_899085_07877056 X-CRM114-Status: GOOD ( 29.01 ) 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 CgpEZW4gMjEuMDkuMjAyMiAxNi4wMywgc2tyZXYgTWF4aW1lIFJpcGFyZDoKPiBPbiBXZWQsIFNl cCAwNywgMjAyMiBhdCAwNjo0NDo1M1BNICswMjAwLCBOb3JhbGYgVHLDuG5uZXMgd3JvdGU6Cj4+ Cj4+Cj4+IERlbiAwNy4wOS4yMDIyIDEyLjM2LCBza3JldiBTdGVmYW4gV2FocmVuOgo+Pj4gSGkg TWF4aW1lLAo+Pj4KPj4+IEFtIDA1LjA5LjIyIHVtIDE2OjU3IHNjaHJpZWIgTWF4aW1lIFJpcGFy ZDoKPj4+PiBPbiBGcmksIFNlcCAwMiwgMjAyMiBhdCAwMToyODoxNlBNICswMjAwLCBOb3JhbGYg VHLDuG5uZXMgd3JvdGU6Cj4+Pj4+Cj4+Pj4+IERlbiAwMS4wOS4yMDIyIDIxLjM1LCBza3JldiBO b3JhbGYgVHLDuG5uZXM6Cj4+Pj4+Pgo+Pj4+Pj4gSSBoYXZlIGZpbmFsbHkgZm91bmQgYSB3b3Jr YXJvdW5kIGZvciBteSBrZXJuZWwgaGFuZ3MuCj4+Pj4+Pgo+Pj4+Pj4gRG9tIGhhZCBhIGxvb2sg YXQgbXkga2VybmVsIGFuZCBmb3VuZCB0aGF0IHRoZSBWaWRlb0NvcmUgd2FzIGZpbmUsIGFuZAo+ Pj4+Pj4gaGUgc2FpZCB0aGlzOgo+Pj4+Pj4KPj4+Pj4+PiBUaGF0IHN1Z2dlc3RzIGNhdXNlIG9m IGxvY2t1cCB3YXMgb24gYXJtIHNpZGUgcmF0aGVyIHRoYW4gVkMgc2lkZS4KPj4+Pj4+Pgo+Pj4+ Pj4+IEJ1dCBpdCdzIGhhcmQgdG8gZGlhZ25vc2UgZnVydGhlci4gT25jZSB5b3UndmUgaGFkIGEg cGVyaXBoZXJhbCBub3QKPj4+Pj4+PiByZXNwb25kLCB0aGUgQVhJIGJ1cyBsb2NrcyB1cCBhbmQg bm8gZnVydGhlciBvcGVyYXRpb25zIGFyZSBwb3NzaWJsZS4KPj4+Pj4+PiBVc3VhbCBjYXVzZXMg b2YgdGhpcyBhcmUgcmVxdWlyZWQgY2xvY2tzIGJlaW5nIHN0b3BwZWQgb3IgZG9tYWlucwo+Pj4+ Pj4+IGRpc2FibGVkIGFuZCB0aGVuIHRyeWluZyB0byBhY2Nlc3MgdGhlIGhhcmR3YXJlLgo+Pj4+ Pj4+Cj4+Pj4+PiBTbyB3aGVuIEkgZ290IHRoaXMgb24gbXkgNjQtYml0IGJ1aWxkOgo+Pj4+Pj4K Pj4+Pj4+IFvCoCAxNjYuNzAyMTcxXSBTRXJyb3IgSW50ZXJydXB0IG9uIENQVTEsIGNvZGUgMHgw MDAwMDAwMGJmMDAwMDAyIC0tCj4+Pj4+PiBTRXJyb3IKPj4+Pj4+IFvCoCAxNjYuNzAyMTg3XSBD UFU6IDEgUElEOiA4IENvbW06IGt3b3JrZXIvdTg6MCBUYWludGVkOiBHwqDCoMKgwqDCoMKgwqAg Vwo+Pj4+Pj4gwqDCoMKgwqAgNS4xOS4wLXJjNi0wMDA5Ni1nYmE3OTczOTc3OTc2LWRpcnR5ICMx Cj4+Pj4+PiBbwqAgMTY2LjcwMjIwMF0gSGFyZHdhcmUgbmFtZTogUmFzcGJlcnJ5IFBpIDQgTW9k ZWwgQiBSZXYgMS4xIChEVCkKPj4+Pj4+IFvCoCAxNjYuNzAyMjA2XSBXb3JrcXVldWU6IGV2ZW50 c19mcmVlemFibGVfcG93ZXJfCj4+Pj4+PiB0aGVybWFsX3pvbmVfZGV2aWNlX2NoZWNrCj4+Pj4+ PiBbwqAgMTY2LjcwMjIzMV0gcHN0YXRlOiAyMDAwMDBjNSAobnpDdiBkYUlGIC1QQU4gLVVBTyAt VENPIC1ESVQgLVNTQlMKPj4+Pj4+IEJUWVBFPS0tKQo+Pj4+Pj4gW8KgIDE2Ni43MDIyNDJdIHBj IDogcmVnbWFwX21taW9fcmVhZDMybGUrMHgxMC8weDI4Cj4+Pj4+PiBbwqAgMTY2LjcwMjI2MV0g bHIgOiByZWdtYXBfbW1pb19yZWFkKzB4NDQvMHg3MAo+Pj4+Pj4gLi4uCj4+Pj4+PiBbwqAgMTY2 LjcwMjYwNl3CoCBiY20yNzExX2dldF90ZW1wKzB4NTgvMHhiMCBbYmNtMjcxMV90aGVybWFsXQo+ Pj4+Pj4KPj4+Pj4+IEkgd29uZGVyZWQgaWYgdGhhdCByZWcgcmVhZCB3YXMgc3RhbGxlZCBkdWUg dG8gYSBjbG9jayBiZWluZyBzdG9wcGVkLgo+Pj4+Pj4KPj4+Pj4+IExvIGFuZCBiZWhvbGQsIGRp c2FibGluZyBydW50aW1lIHBtIGFuZCBrZWVwaW5nIHRoZSB2ZWMgY2xvY2sgcnVubmluZwo+Pj4+ Pj4gYWxsIHRoZSB0aW1lIGZpeGVkIGl0WzFdLgo+Pj4+Pj4KPj4+Pj4+IEkgZG9uJ3Qga25vdyB3 aGF0IHRoZSBwcm9ibGVtIGlzLCBidXQgYXQgbGVhc3QgSSBjYW4gbm93IHRlc3QgdGhpcwo+Pj4+ Pj4gcGF0Y2hzZXQuCj4+Pj4+Pgo+Pj4+Pj4gWzFdIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL25v dHJvLzIzYjk4NGU3ZmEwNWNmYmRhMmRiNTBhNDIxY2FjMDY1Cj4+Pj4+Pgo+Pj4+PiBJdCB0dXJu cyBvdXQgSSBkaWRuJ3QgaGF2ZSB0byBkaXNhYmxlIHJ1bnRpbWUgcG06Cj4+Pj4+IGh0dHBzOi8v Z2lzdC5naXRodWIuY29tL25vdHJvLzBhZGNmY2IxMjQ2MGI1NGU1NDQ1OGFmZTExZGM4ZWEyCj4+ Pj4gSWYgdGhlIGJjbTI3MTFfdGhlcm1hbCBJUCBuZWVkcyB0aGF0IGNsb2NrIHRvIGJlIGVuYWJs ZWQsIGl0IHNob3VsZCBncmFiCj4+Pj4gYSByZWZlcmVuY2UgaXRzZWxmLCBidXQgaXQgbG9va3Mg bGlrZSBldmVuIHRoZSBkZXZpY2UgdHJlZSBiaW5kaW5nCj4+Pj4gZG9lc24ndCBhc2sgZm9yIG9u ZS4KPj4+IFRoZSBtaXNzaW5nIGNsb2NrIGluIHRoZSBkZXZpY2UgdHJlZSBiaW5kaW5nIGlzIGV4 cGVjdGVkLCBiZWNhdXNlCj4+PiBkZXNwaXRlIG9mIHRoZSBjb2RlIHRoZXJlIGlzIG5vdCBtdWNo IGluZm9ybWF0aW9uIGFib3V0IHRoZSBCQ00yNzExCj4+PiBjbG9jayB0cmVlLiBCdXQgaSdtIHNr ZXB0aWNhbCB0aGF0IHRoZSBBVlMgSVAgYWN0dWFsbHkgbmVlZHMgdGhlIFZFQwo+Pj4gY2xvY2ss IGkgdGhpbmsgaXQncyBtb3JlIGxpa2VseSB0aGF0IHRoZSBWRUMgY2xvY2sgcGFyZW50IGlzIGNo YW5nZWQgYW5kCj4+PiB0aGF0IGNhdXNlIHRoaXMgaXNzdWUuIEkgY291bGQgdGFrZSBjYXJlIG9m IHRoZSBiY20yNzExIGJpbmRpbmcgJiBkcml2ZXIKPj4+IGlmIGkga25vdyB3aGljaCBjbG9jayBp cyByZWFsbHkgbmVjZXNzYXJ5Lgo+Pgo+PiBTZWVtcyB5b3UncmUgcmlnaHQsIGtlZXBpbmcgdGhl IHBhcmVudCBhbHdheXMgZW5hYmxlZCBpcyBlbm91Z2g6Cj4+Cj4+IAljbGtfcHJlcGFyZV9lbmFi bGUoY2xrX2dldF9wYXJlbnQodmVjLT5jbG9jaykpOyAvLyBwbGxjX3Blcgo+Pgo+PiBJIHRyaWVk IGVuYWJsaW5nIGp1c3QgdGhlIGdyYW5kcGFyZW50IGNsb2NrIGFzIHdlbGwsIGJ1dCB0aGF0IGRp ZG4ndCBoZWxwLgo+IAo+IFllYWgsIGFkZGluZyB0cmFjaW5nIHRvIHRoZSBjbG9jayBmcmFtZXdv cmsgc2hvd3MgdGhhdCBpdCBpbmRlZWQKPiBkaXNhYmxlcyBQTExDX1BFUi4gU28gdGhlcmUncyBw cm9iYWJseSBzb21lIG90aGVyIGRldmljZSB0aGF0IGRlcGVuZHMgb24KPiBpdCBidXQgZG9lc24n dCB0YWtlIGEgcmVmZXJlbmNlIHRvIGl0Lgo+IAo+IEkgaGFkIGEgbG9vaywgYnV0IGl0J3Mgbm90 IHJlYWxseSBvYnZpb3VzIHdoYXQgdGhhdCBtaWdodCBiZS4KPiAKPiBUaGlzIHBhdGNoIG1ha2Vz IHN1cmUgdGhhdCB0aGUgUExMKl9QRVIgYXJlIG5ldmVyIGRpc2FibGVkLCBjb3VsZCB5b3UKPiB0 ZXN0IGl0PyBJdCBzZWVtcyB0byB3b3JrIGZvciBtZS4KPiAKPiAKPiBkaWZmIC0tZ2l0IGEvZHJp dmVycy9jbGsvYmNtL2Nsay1iY20yODM1LmMgYi9kcml2ZXJzL2Nsay9iY20vY2xrLWJjbTI4MzUu Ywo+IGluZGV4IDQ4YTFlYjlmMmQ1NS4uMzgzOTI2MWVlNDE5IDEwMDY0NAo+IC0tLSBhL2RyaXZl cnMvY2xrL2JjbS9jbGstYmNtMjgzNS5jCj4gKysrIGIvZHJpdmVycy9jbGsvYmNtL2Nsay1iY20y ODM1LmMKPiBAQCAtMTY3NSw3ICsxNjc1LDcgQEAgc3RhdGljIGNvbnN0IHN0cnVjdCBiY20yODM1 X2Nsa19kZXNjIGNsa19kZXNjX2FycmF5W10gPSB7Cj4gIAkJLmxvYWRfbWFzayA9IENNX1BMTEFf TE9BRFBFUiwKPiAgCQkuaG9sZF9tYXNrID0gQ01fUExMQV9IT0xEUEVSLAo+ICAJCS5maXhlZF9k aXZpZGVyID0gMSwKPiAtCQkuZmxhZ3MgPSBDTEtfU0VUX1JBVEVfUEFSRU5UKSwKPiArCQkuZmxh Z3MgPSBDTEtfSVNfQ1JJVElDQUwgfCBDTEtfU0VUX1JBVEVfUEFSRU5UKSwKPiAgCVtCQ00yODM1 X1BMTEFfRFNJMF0JPSBSRUdJU1RFUl9QTExfRElWKAo+ICAJCVNPQ19BTEwsCj4gIAkJLm5hbWUg PSAicGxsYV9kc2kwIiwKPiBAQCAtMTc4NCw3ICsxNzg0LDcgQEAgc3RhdGljIGNvbnN0IHN0cnVj dCBiY20yODM1X2Nsa19kZXNjIGNsa19kZXNjX2FycmF5W10gPSB7Cj4gIAkJLmxvYWRfbWFzayA9 IENNX1BMTENfTE9BRFBFUiwKPiAgCQkuaG9sZF9tYXNrID0gQ01fUExMQ19IT0xEUEVSLAo+ICAJ CS5maXhlZF9kaXZpZGVyID0gMSwKPiAtCQkuZmxhZ3MgPSBDTEtfU0VUX1JBVEVfUEFSRU5UKSwK PiArCQkuZmxhZ3MgPSBDTEtfSVNfQ1JJVElDQUwgfCBDTEtfU0VUX1JBVEVfUEFSRU5UKSwKPiAK ClllcywgdGhpcyB3b3JrZWQsIGJ1dCBpdCdzIGVub3VnaCB0byBtYXJrIHBsbGNfcGVyIGFzIGNy aXRpY2FsLgoKTm9yYWxmLgoKPiAgCS8qCj4gIAkgKiBQTExEIGlzIHRoZSBkaXNwbGF5IFBMTCwg dXNlZCB0byBkcml2ZSBEU0kgZGlzcGxheSBwYW5lbHMuCj4gQEAgLTE4OTEsNyArMTg5MSw3IEBA IHN0YXRpYyBjb25zdCBzdHJ1Y3QgYmNtMjgzNV9jbGtfZGVzYyBjbGtfZGVzY19hcnJheVtdID0g ewo+ICAJCS5sb2FkX21hc2sgPSBDTV9QTExIX0xPQURBVVgsCj4gIAkJLmhvbGRfbWFzayA9IDAs Cj4gIAkJLmZpeGVkX2RpdmlkZXIgPSAxLAo+IC0JCS5mbGFncyA9IENMS19TRVRfUkFURV9QQVJF TlQpLAo+ICsJCS5mbGFncyA9IENMS19JU19DUklUSUNBTCB8IENMS19TRVRfUkFURV9QQVJFTlQp LAo+ICAJW0JDTTI4MzVfUExMSF9QSVhdCT0gUkVHSVNURVJfUExMX0RJVigKPiAgCQlTT0NfQkNN MjgzNSwKPiAgCQkubmFtZSA9ICJwbGxoX3BpeCIsCj4gCj4gCj4gTWF4aW1lCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1h aWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xp c3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== 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 0AFCAC6FA83 for ; Mon, 26 Sep 2022 10:40:41 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5927410E2CE; Mon, 26 Sep 2022 10:40:38 +0000 (UTC) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 12C6B10E0B6; Sat, 24 Sep 2022 15:33:18 +0000 (UTC) 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=DP3zUOJkBK29CjZ1hWIKGa38wlT1g1yzlrFvDjg2ysg=; b=nxiTXcG+1m14DovcWFz7qiYOQ+ 1YsfTMoxhEjyePsnyUaogiNTaZiOu5ODbzq1GCKFP9tA314nUbYJ9GBPUpzaZ3gBJqsVkKnp3ELI3 qeHb327ypE1IoTHHSw+f7xMLdYWvvjwYjYeHnjvWMwHmh631zxx1AAN3n30dsK08rRzIXCVtPgqYu EhvEcmiD+7SxTJVnEo6soadcZlrkzvemM3Quws+gN28ItnYSWc2qNTC2EbGSH8utihaIWnDyhbi9/ xRi2Nd1S9IKuPsTav7KemdhK8UxvmeHGxfYTPBq2+9RBfgFueCq7xggL3fnYfZ0c/BTAovVV8FrYl rTvyK86w==; Received: from [2a01:799:961:d200:8cf6:761:40ec:1ff7] (port=51599) by smtp.domeneshop.no with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oc79W-0006Fk-UY; Sat, 24 Sep 2022 17:33:14 +0200 Message-ID: <1220a3ef-86cf-78ae-07b6-16eb091c7dcc@tronnes.org> Date: Sat, 24 Sep 2022 17:33:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 To: Maxime Ripard 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> <20220921140324.sbeadfr7kz4avqcr@houat> From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= In-Reply-To: <20220921140324.sbeadfr7kz4avqcr@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 26 Sep 2022 10:40:33 +0000 Subject: Re: [Intel-gfx] [PATCH v2 00/41] drm: Analog TV Improvements 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 , Stefan Wahren , 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 , Daniel Vetter , linux-arm-kernel@lists.infradead.org, Dom Cobley , Dave Stevenson , linux-kernel@vger.kernel.org, Mateusz Kwiatkowski , =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , Philipp Zabel Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Den 21.09.2022 16.03, skrev Maxime Ripard: > On Wed, Sep 07, 2022 at 06:44:53PM +0200, Noralf Trønnes wrote: >> >> >> 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. > > Yeah, adding tracing to the clock framework shows that it indeed > disables PLLC_PER. So there's probably some other device that depends on > it but doesn't take a reference to it. > > I had a look, but it's not really obvious what that might be. > > This patch makes sure that the PLL*_PER are never disabled, could you > test it? It seems to work for me. > > > diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c > index 48a1eb9f2d55..3839261ee419 100644 > --- a/drivers/clk/bcm/clk-bcm2835.c > +++ b/drivers/clk/bcm/clk-bcm2835.c > @@ -1675,7 +1675,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLA_LOADPER, > .hold_mask = CM_PLLA_HOLDPER, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > [BCM2835_PLLA_DSI0] = REGISTER_PLL_DIV( > SOC_ALL, > .name = "plla_dsi0", > @@ -1784,7 +1784,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLC_LOADPER, > .hold_mask = CM_PLLC_HOLDPER, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > Yes, this worked, but it's enough to mark pllc_per as critical. Noralf. > /* > * PLLD is the display PLL, used to drive DSI display panels. > @@ -1891,7 +1891,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { > .load_mask = CM_PLLH_LOADAUX, > .hold_mask = 0, > .fixed_divider = 1, > - .flags = CLK_SET_RATE_PARENT), > + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT), > [BCM2835_PLLH_PIX] = REGISTER_PLL_DIV( > SOC_BCM2835, > .name = "pllh_pix", > > > Maxime