From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 6DDA325A357 for ; Wed, 1 Jul 2026 14:09:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782914956; cv=none; b=TnPFWb4tn5QMZ1I/USYC4jJfXw1V5QdNIQhVh9jpA9DpU+MEXPjKx44nLlILdayK5BUdPIgkhRzBbqj4Kf8Eo0mlhyyeQecZXe9hI/uyZv1b6KnhSfCRCsz+O1grtvtlIucONSBlHlWiSTmvtObGt9IyCMUeNC7AbB3/fr5VkjI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782914956; c=relaxed/simple; bh=Rr9nTxauw3Ld+d8F57iqszED//Wn2JjDdovTpTeRCzE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XcW4dkXC2kDgIhtw5f3PxoMCpalqPRoWnmXBfp2aBv+fhxb15g6bdS2BN98jEKQx4CwsR/EnaabAnofpKew6jWMumUGRhiPF7NpWLdeJWss95kNKxU0ZDiS+z4N4FNQDHQAG0Gn4knfnteBhgk/Q8Bhfom3KtTGLhDKVIM1e5hs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=HBlxDass; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Vgz3vSYN; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HBlxDass"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Vgz3vSYN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782914954; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Fg1jQ5xlQw7jkowSdvyp9ysqaIiouFFtIXbXuCa9asQ=; b=HBlxDasskvxV5fnvsTk4IvVN6hXzLW//XhJdOGXZorGKuOhPRTsu6IkAofmQzopqCmMapc yfLz19nuZipuUzsez9fPAQWghNo/V0o6nkWK3pmXy1U/zbfQVym3t3kKzNxL6x9vJy7+jx vzdG2j0e1xV/BaYCGvmtNIU1yDdaAxw= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-381-OYRMuWdpPuKQ2iIapKMVEg-1; Wed, 01 Jul 2026 10:09:12 -0400 X-MC-Unique: OYRMuWdpPuKQ2iIapKMVEg-1 X-Mimecast-MFC-AGG-ID: OYRMuWdpPuKQ2iIapKMVEg_1782914952 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-92e606e8f3eso65933485a.3 for ; Wed, 01 Jul 2026 07:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782914952; x=1783519752; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=Fg1jQ5xlQw7jkowSdvyp9ysqaIiouFFtIXbXuCa9asQ=; b=Vgz3vSYNbWxy6s3rUxXJOa1nsMmWKANEhpsTCmFBBZzoG69L1znoUpVqfVD+KDCokn b5yFO3glpb1Kk4AMX5VTHUQ8IgFHH9aG7+6wUr7htyywIpuLlBgfv96lY2vdAcB3QJvq 8pgW/ILDIHtP97SQ/Y/YcuEwfBJNrPVvgs8Sd/66o1PkUMk5df5zDKrGNlyTAqfihrQx Nhkq84+StkzsjYtaOY6OUUE6wNIPnIIlwgsKERGX4je4x3LeRCf491+v+VOAFNe7BiK0 XQiwW/viCO0BHN5KlmiPYwwYbl80DrdRy/ogyef0mYP1myqlmVw90NiQWHt+R4jHDnjA SWBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782914952; x=1783519752; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Fg1jQ5xlQw7jkowSdvyp9ysqaIiouFFtIXbXuCa9asQ=; b=Rcz+re6fkDJC90ykkR+1EzGd9g6/atDxtuxFm39giixmGwkSo+1uRDuC7n8xOfZEPx /nnZjqnXjpYTSPYk0/xgK/HQ0cfru/Fhdz5QW8vEcuLrdp46l2DeMzbQrBFIDOEgm3Z/ BolW10Nz67oktHWJ36FqDvhEn6VuQiHnLi7aoBM6OQWO0zjvIf+esavo8FtFgU5CXoZ9 8iuDyHWiAsD7YtiuybAJJLoYurTQgg1+QAPUwm5s4qq3uWHA409UiUa7Z++UvX4LWATK lt5Tx+dUI3RN+dianc4aE/5TPtizBEdXDP3JfaNTbR0h5P6WeXmMbSFUtYnAVzyXvNbU p7mQ== X-Forwarded-Encrypted: i=1; AFNElJ/+H/C4luGsfGHfcJMcSrjk7IM4CeyiIXGWXEZTXmn8b9RvmnufcizfFeBKgRS7LYIwxAZWYeakYz4L2kg=@vger.kernel.org X-Gm-Message-State: AOJu0YwXuqCl2UZvXEiOrcUXFKtdqTu2ZV1fOk4odMCme00PRKM+H/SI khiSWJMk1vJeIFwpf5XAna32BKpPc3hohrWa+vO9nwZL/wwfttnxV1BojT+hYr95CKQt3CSJG45 bGOyky8wmUpFKugUNZAR2vd0x6Oiir7ljguhJhjxHaWmXEHLY2A/JXGWCKr06wfYhhQ== X-Gm-Gg: AfdE7cmWldOibJdMFob4YEXy+BKiWXb6lqr5iSwu/x0l2KKYzKBrLOEH0FI6DWUVs7l ht0BtwNtBwQqSqnPMhlvlAxsJqzHWriQY7Q2iXgE7PnMPcnG6Q8JgagiCcO7Zd92WygmUzMEHXF cL21zONtTor9re87ZfPLP3LepYTaJa0E7opZ1xBtEVVOUcXeq2lMSo6thpNDc5pryDZ6vmw/j9v WcwLyQU3/hxNJP5eAg8kXwaykdHdPzfaLhOz1zmSTPv17RDSyw1GppJ+TozRlCONE99g3hZ/37I EgTPuDTwm44XRXII/Tf5YSe21n2dK7NT5oLcA33Tvggi+5nRWBFugEBUoPnI5poGImP7Xl+4MW0 PoX6WBfPQ41ylTzth0N6DZmxETlYoRuM3pg6lGcVDopmqEQ== X-Received: by 2002:a05:620a:6405:b0:92e:72cd:32f4 with SMTP id af79cd13be357-92e78504000mr245373685a.64.1782914951722; Wed, 01 Jul 2026 07:09:11 -0700 (PDT) X-Received: by 2002:a05:620a:6405:b0:92e:72cd:32f4 with SMTP id af79cd13be357-92e78504000mr245365485a.64.1782914951052; Wed, 01 Jul 2026 07:09:11 -0700 (PDT) Received: from redhat.com (c-73-183-53-213.hsd1.pa.comcast.net. [73.183.53.213]) by smtp.gmail.com with ESMTPSA id af79cd13be357-92e6234862csm564321785a.38.2026.07.01.07.09.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jul 2026 07:09:09 -0700 (PDT) Date: Wed, 1 Jul 2026 10:09:08 -0400 From: Brian Masney To: Jagadeesh Kona Cc: Konrad Dybcio , Bjorn Andersson , Michael Turquette , Stephen Boyd , Bryan O'Donoghue , linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, Taniya Das Subject: Re: [PATCH] clk: qcom: enable ALWAYS_ON for titan_top_gdsc Message-ID: References: <20260626-camcc-sc8280xp-titan-top-v1-1-2ca246886493@redhat.com> <56ebd97b-0834-41ac-8fdb-2469e2848694@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56ebd97b-0834-41ac-8fdb-2469e2848694@oss.qualcomm.com> User-Agent: Mutt/2.3.2 (2026-04-26) Hi Jagadeesh, On Wed, Jul 01, 2026 at 09:37:04AM +0530, Jagadeesh Kona wrote: > This probably could be due to camcc_gdsc_clk getting turned OFF during the > sync_state, but this clk is required for GDSC transitions. The camcc_gdsc_clk > is currently kept always ON from probe in camcc-sc8280xp, but the clock is > also modeled with clock framework, so the clock can get disabled in sync_state > callback now. > > Can you please try removing the modelling of camcc_gdsc_clk using below diff > and see if helps here? > > > diff --git a/drivers/clk/qcom/camcc-sc8280xp.c b/drivers/clk/qcom/camcc-sc8280xp.c > index e97b8d4f3c84..660d8655d391 100644 > --- a/drivers/clk/qcom/camcc-sc8280xp.c > +++ b/drivers/clk/qcom/camcc-sc8280xp.c > @@ -1753,24 +1753,6 @@ static struct clk_branch camcc_csiphy3_clk = { > }, > }; > > -static struct clk_branch camcc_gdsc_clk = { > - .halt_reg = 0xc1e4, > - .halt_check = BRANCH_HALT, > - .clkr = { > - .enable_reg = 0xc1e4, > - .enable_mask = BIT(0), > - .hw.init = &(struct clk_init_data){ > - .name = "camcc_gdsc_clk", > - .parent_hws = (const struct clk_hw*[]){ > - &camcc_xo_clk_src.clkr.hw, > - }, > - .num_parents = 1, > - .flags = CLK_SET_RATE_PARENT, > - .ops = &clk_branch2_ops, > - }, > - }, > -}; > - > static struct clk_branch camcc_icp_ahb_clk = { > .halt_reg = 0xc0d8, > .halt_check = BRANCH_HALT, > @@ -2839,7 +2821,6 @@ static struct clk_regmap *camcc_sc8280xp_clocks[] = { > [CAMCC_CSIPHY2_CLK] = &camcc_csiphy2_clk.clkr, > [CAMCC_CSIPHY3_CLK] = &camcc_csiphy3_clk.clkr, > [CAMCC_FAST_AHB_CLK_SRC] = &camcc_fast_ahb_clk_src.clkr, > - [CAMCC_GDSC_CLK] = &camcc_gdsc_clk.clkr, > [CAMCC_ICP_AHB_CLK] = &camcc_icp_ahb_clk.clkr, > [CAMCC_ICP_CLK] = &camcc_icp_clk.clkr, > [CAMCC_ICP_CLK_SRC] = &camcc_icp_clk_src.clkr, So there is the CLK_IGNORE_UNUSED flag that can be added so that we can keep the clock defined. diff --git a/drivers/clk/qcom/camcc-sc8280xp.c b/drivers/clk/qcom/camcc-sc8280xp.c index 18f5a3eb313e1..9a525347fb2a4 100644 --- a/drivers/clk/qcom/camcc-sc8280xp.c +++ b/drivers/clk/qcom/camcc-sc8280xp.c @@ -1766,7 +1766,7 @@ static struct clk_branch camcc_gdsc_clk = { &camcc_xo_clk_src.clkr.hw, }, .num_parents = 1, - .flags = CLK_SET_RATE_PARENT, + .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, .ops = &clk_branch2_ops, }, }, This patch fixes the issue for me. I see that camcc_sc8280xp_probe() has this: /* Keep some clocks always-on */ qcom_branch_set_clk_en(regmap, 0xc1e4); /* CAMCC_GDSC_CLK */ I'll submit a proper patch for this shortly. Do you by chance work on the team that deals with clocks at Qualcomm? If so, it would be really nice if your team could make the time to help review a patch set that I have to fix some scaling issues with clocks. Here's some details: https://lore.kernel.org/linux-clk/akPcgdjlDxd-JmYb@redhat.com/ This is two messages up in the same thread that has an example kunit test snippet showing the problem: https://lore.kernel.org/linux-clk/CABx5tqK3MymYQZ4owofnzFLnjt+96njw5RG2Vwxo7UJ93A-42g@mail.gmail.com/ Thanks, Brian