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 B8A3510F9318 for ; Wed, 1 Apr 2026 02:59:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:To:Subject:Cc: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=P9bx0JSQN5urEQ0kGf5GT9ZdgXv8ZZPvBz0eFEf+7pA=; b=IYPlUAlfXHqf2ETnGYW1wykkAc SzcPkaZsvMeMA/9AcOGCTOhYJp238iLH/55OXRsulRXX8QSa7Weu+H05MOmvAanMn7VoklInzmod7 phLc4PPYU8BOvmyFXzlEBM9fjO12qCZkL/4tMb/MFFdkLWSfm/MouG+inU6I7GsqqWvy8IXPOzXu8 kfD4tZkiIv8gIXDtHfzFadGb7Or5oB4xlXoOgiBmfe17T2XhI9PM0dUNyrk26Ec01Bp7A80xZo6l6 ApVDZjJPi0FZPr/QnvORzkfIwLzlZds0Q25f9ldxS5V84iz8P7HdVoaxGrtvoQd0T3HE+yBxTgyTW 1sWtKjTQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w7lnk-0000000Ds5e-42JI; Wed, 01 Apr 2026 02:59:28 +0000 Received: from mail-m15594.qiye.163.com ([101.71.155.94]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w7lnh-0000000Ds53-3bgJ; Wed, 01 Apr 2026 02:59:27 +0000 Received: from [172.16.12.17] (unknown [58.22.7.114]) by smtp.qiye.163.com (Hmail) with ESMTP id 39142f724; Wed, 1 Apr 2026 10:54:14 +0800 (GMT+08:00) Message-ID: Date: Wed, 1 Apr 2026 10:54:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Cc: shawn.lin@rock-chips.com, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, heiko@sntech.de Subject: Re: [PATCH 1/2] pmdomain/rockchip: skip QoS operations for idle-only domains To: Daniel Bozeman References: <20260331180223.1682283-1-daniel@orb.net> <5c8732a3-6cc9-5d02-f56b-fc7ba29c7ce0@rock-chips.com> From: Shawn Lin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Tid: 0a9d46f6852f09cckunm2fad582df958e2 X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFDSUNOT01LS0k3V1ktWUFJV1kPCRoVCBIfWUFZGkNPTVYdT08aHk8YQh5PHUlWFRQJFh oXVRMBExYaEhckFA4PWVdZGBILWUFZTkNVSUlVTFVKSk9ZV1kWGg8SFR0UWUFZT0tIVUpLSU9PT0 hVSktLVUpCS0tZBg++ DKIM-Signature: a=rsa-sha256; b=ZtfglWvVHDfRtUw1SGTqDQJJHeX/aurreDJr4KQff0OoDgR89JsUrhEFc8FCjs5g8RPp27wEGrwnqmNg0IRiYMUTxB4r9R++FGmn7rUDODjd+KScvBb8+3N5Wgfcz9rBpYzs1gcGfPI5Ia8uZTJTw/AMZD3Tm8Gf5Nt4C2LveZ0=; s=default; c=relaxed/relaxed; d=rock-chips.com; v=1; bh=P9bx0JSQN5urEQ0kGf5GT9ZdgXv8ZZPvBz0eFEf+7pA=; h=date:mime-version:subject:message-id:from; X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260331_195926_100868_FD64E549 X-CRM114-Status: GOOD ( 30.27 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 在 2026/04/01 星期三 10:34, Daniel Bozeman 写道: > The NanoPi Zero2 (RK3528) kernel panics during boot when a > GPIO-controlled USB VBUS regulator is defined on GPIO4 (which > is in PD_RKVENC). The goal of this series is to make USB host > power work on boards that use GPIO4 for regulator control. > > The root cause is a probe ordering issue. On RK3528, the power > domain controller's first probe attempt fails because PD_GPU's > clock lookup returns -EPROBE_DEFER (CRU hasn't probed yet). > The driver then tears down all domains, including PD_RKVENC > which would have registered successfully (it has no clock > requirements). During this window, the USB regulator driver > probes and requests GPIO4, which is in the now-unregistered > PD_RKVENC. This triggers a synchronous external abort. > > With patch 2 alone (skipping deferred domains), the idle-only > domains register successfully. But the genpd framework then > attempts to power them off via genpd_power_off_work_fn. This > calls rockchip_pd_power(), which does QoS save and idle > requests on domains with pwr_mask == 0 that cannot actually > be powered off. > > To your question about why QoS registers become inaccessible > on idle-only domains: I have not root-caused that specifically. > What I can confirm is the crash trace below, which occurs when > patch 2 is applied without patch 1. The abort happens during This sounds like a parent-child dependency which hasn't been sorted out. My another question will be: with patch 1 applied, how to save- restore qos registers during normal S2R usage? > rockchip_pmu_set_idle_request on an idle-only domain: > >   Internal error: synchronous external abort: 0000000096000010 >   CPU: 2 PID: 60 Comm: kworker/2:3 >   Workqueue: pm genpd_power_off_work_fn >   pc : regmap_mmio_read32le+0x8/0x20 >   lr : regmap_mmio_read+0x44/0x70 >   Call trace: >    regmap_mmio_read32le+0x8/0x20 >    _regmap_bus_reg_read+0x6c/0xac >    _regmap_read+0x60/0xd8 >    regmap_read+0x4c/0x7c >    rockchip_pmu_set_idle_request.isra.0+0x94/0x1b4 >    rockchip_pd_power+0x37c/0x608 >    rockchip_pd_power_off+0x14/0x38 >    genpd_power_off.isra.0+0x1f0/0x2f0 >    genpd_power_off_work_fn+0x34/0x54 > > The two patches work together: patch 1 prevents QoS access > on idle-only domains, and patch 2 prevents the full probe > teardown when a single domain defers. > > Tested on NanoPi Zero2 (fixes panic) and Radxa E20C (no > regression). > > On Tue, Mar 31, 2026 at 6:17 PM Shawn Lin > wrote: > > Hi Daniel, > > 在 2026/04/01 星期三 2:02, Daniel Bozeman 写道: > > Idle-only power domains (pwr_mask == 0) cannot actually be powered > > on or off. rockchip_do_pmu_set_power_domain() already returns early > > for these domains, but rockchip_pd_power() still attempts QoS save > > and idle requests before reaching that check. > > > > On RK3528, the idle-only domains (PD_RKVENC, PD_VO, PD_VPU) have > > QoS registers that may be inaccessible when the generic power domain > > framework attempts to power them off, leading to synchronous external > > aborts. > > > > Is it the real abort happened on your RK3528 board? I am trying to > understand the problem first. Even with idle-only powerdomain, the code > also save the QoS registers before set idle to the powerdomain, so > how the QoS registers become inaccessible? > > > Return early from rockchip_pd_power() when pwr_mask is zero, matching > > the existing guard in rockchip_do_pmu_set_power_domain(). > > > > Fixes: 1fe767a56c32 ("soc: rockchip: power-domain: allow domains > only handling idle requests") > > Signed-off-by: Daniel Bozeman > > > --- > >   drivers/pmdomain/rockchip/pm-domains.c | 3 +++ > >   1 file changed, 3 insertions(+) > > > > diff --git a/drivers/pmdomain/rockchip/pm-domains.c > b/drivers/pmdomain/rockchip/pm-domains.c > > index 490bbb1d1d..2eecae092a 100644 > > --- a/drivers/pmdomain/rockchip/pm-domains.c > > +++ b/drivers/pmdomain/rockchip/pm-domains.c > > @@ -640,6 +640,9 @@ static int rockchip_pd_power(struct > rockchip_pm_domain *pd, bool power_on) > >       if (rockchip_pmu_domain_is_on(pd) == power_on) > >               return 0; > > > > +     if (pd->info->pwr_mask == 0) > > +             return 0; > > + > >       ret = clk_bulk_enable(pd->num_clks, pd->clks); > >       if (ret < 0) { > >               dev_err(pmu->dev, "failed to enable clocks\n"); > > > > base-commit: bc330699801d3b4f99110365512caed5adcfaca3 >