From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05AA13BCD04 for ; Mon, 3 Aug 2026 09:10:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785748210; cv=none; b=ocycipr/c4RJ7WpSypKQ21c1mx6laFvKwei5Qiff8HcAtVhWAy8xP91eNdlRKXeX7+d08jqNLw7nBp/AfxqSWAwNr3CPjb25yWvztY5CBDy0GSwuK2jf9F2bFB59ULQC6R8V/uDzuzrEa3oTyGb1XfgQF0ufn/hFKfDJxxj3tsI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785748210; c=relaxed/simple; bh=zm0r4glsNOxJ03wZrKAIgQ+b1zHrFGL4ar6++8AFGQE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=D8dkIEKxyXNCmEn9S+feNmzJqftNFAbFmcZkduhF06IPlH/kFZY4x+QZ3dW7OfXurjoLcsgTosjq1KvywD3ct7DlKPIXwT8ZUOZ1vzREro+0a/iAAWSHAnxOfodeKfZSVvE+Q3zYvxqpv/mllH1ricqM6y/+YEVMZeF+JtJ8Ffo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=cBpoVkrw; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cBpoVkrw" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-490cf322ed0so9506695e9.1 for ; Mon, 03 Aug 2026 02:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785748206; x=1786353006; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=6DhqIpmeojaXcrJr0s+5N7z4n/wdaspZafaywldTd8c=; b=cBpoVkrwHvcCnEzUtQc+Xe8EeEFerXwBXfhWf1jAnNIt8l9azEenGsqjEsV/GA6wnc yasG/3uwbJa/Ub2p5ftM63sYXy67ELIve4pwdi26py6N2VXui/AHJhM2nxphVWLN37MI 6tS+ngEhhWvm1aPskAoGOslnWgdR68LREM+IZy0PXMgGDj5joc5QGRLmMkLnXxmZ+7uK b2tPfkJ4E5PV+QEGPayI+AMM9otq3UzqsYa/WgPMUhQowlIMhQeCT8FTfBNPt4uuur0C lbSHTakgyluCt7YMkuH7RFLXNwBnhdk/4leHGJ5pI63pxeyoJu3JOq0T7ccOpGXXRlG2 CmFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785748206; x=1786353006; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=6DhqIpmeojaXcrJr0s+5N7z4n/wdaspZafaywldTd8c=; b=cIKyL/nzVUdAvTTRR2PdyPc3o2buy0EU+5SR4aKyB2Zbz0INNN/pPZ5rngViNdqJYM X6bjgSRaoZt1Xcs5rAeoNbz01aFrqZ0KuDYJzt+wRHbePoFpWDkOLGAR5+u4vWSprIHX G9fg8lMM/+EbDhVBLnAxEYCwUBeMt6giGen1Rnq5SDouEuCBApbTmOJd0IyS9zSfQrPA 1uey43xoyAXVbG3J15VRD/JEC+Y0jBSFeloP7CJk6Cgduvxz8LFpx8aSNDB9CfrwpMoS 1gQq11/9KgImtKcYwvUWdYU0bh8IPgVJwwjbrSvkrj80DzFaN+Juf13wBge2Q209jOA5 RHPg== X-Forwarded-Encrypted: i=1; AHgh+RovXCzxXSFbp3q7xGCv3APSRRn196Bf8jAIl8OkTVx0wyyI3O7nxbKVJ9KQDJ8YpFX8o06jr5dFkuAcm+w=@vger.kernel.org X-Gm-Message-State: AOJu0Yy+xGHnTamocvTUvl7Y/bSLo/r4co4ujGzxPVRcE92FHI+saqc2 wZ6GzZ6pJvLvAhOH5IezFc1KGWtGM/5yMjX3lf/l459XY+oGc7rQ77XG X-Gm-Gg: AR+sD12XBvveBgluNXIYSYdoHeixGKgqUdIdAIwVMMgYfMVUP50eAwH8IVUcYVJ2lWt wskLfo5UcpTQR9ytWbm5orBl52YUjIXyq6nLDSb9XsCB1Fn71Gm1LGzbpM6ktcfOIC6GDqrt3ps 5boOPULEq29ftd0iiIDA32Nc/SK3vnx2xcvtf7ZAVE5HEaAZPFv/a5H+AeVd82TPQ41ZTu2nvlZ vgTVRNN0ehigXvvshVolTDODWlIqJYqj02SuaLWzcPiT0TeIj/ftj1+7K6a9Xo6BVhoOwOLVvQ/ RG1o9Isrxj1B8rflOm/IiBv5Z8vg1srN4QP+2vHEXl9oLn35W/Vro4SKdC5Hp1z7dVkl9hz7D19 eIHwgeYkUacnQDTSRK7hi9xnajU2o6uqEkqd5xTvfS/6nIzNMiNJVRfl2Qj7gM8boFwVd4KUlgs JOQxDx8eoZ3zzfDJN/WKwkitjSaWT5MxfRX40RRClmytWmwPXcOxbTMZUQhGAEHYfUCmqTKidIU hM3GHAa9UM= X-Received: by 2002:a05:600c:c3c1:10b0:495:63e4:7f78 with SMTP id 5b1f17b1804b1-4980c672b1cmr152028655e9.10.1785748206047; Mon, 03 Aug 2026 02:10:06 -0700 (PDT) Received: from VivoBook-ASUS-X712UA-M712UA.lan ([2a00:f44:cc3:6030:fb19:4ff1:d885:5a22]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4980878dd0asm209549375e9.14.2026.08.03.02.10.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2026 02:10:05 -0700 (PDT) From: Stanislaw Pal To: Jie Luo Cc: Bjorn Andersson , Stephen Boyd , Michael Turquette , Mieczyslaw Nalewaj , Brian Masney , linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] clk: qcom: ipq-cmn-pll: keep the CMN block bus clocks enabled Date: Mon, 3 Aug 2026 11:10:03 +0200 Message-ID: <20260803091003.15285-1-kuncy7@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: <20260730191353.557494-1-kuncy7@gmail.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=UTF-8 Content-Transfer-Encoding: 8bit On 8/3/2026 Jie Luo wrote: > The CMN PLL AHB/SYS clocks will remain enabled as long as a downstream > consumer of the CMN PLL clocks is active — this behaviour was confirmed > experimentally on the IPQ9574 platform as example. That is exactly the mechanism - and it is exactly what IPQ5018 does not have. On IPQ9574 the nsscc node consumes the CMN PLL outputs in DT: ipq9574.dtsi: nsscc: clock-controller@39b00000 { clocks = <&xo_board_clk>, <&cmn_pll NSS_1200MHZ_CLK>, <&cmn_pll PPE_353MHZ_CLK>, ... so the device link holds the supplier active, which is what your insmod/devmem experiment shows. On IPQ5018 there is no such consumer: nothing in ipq5018.dtsi references any cmn_pll output clock - the only occurrences of the phandle are the provider node itself and its own assigned-clocks. The actual users of the CMN outputs on this SoC (the internal GE PHY and the uniphy blocks) take them directly in hardware, with no DT linkage, so no device link ever holds the provider active. A few ms after probe the autosuspend gates the AHB/SYS clocks, and the box dies on the next bus access - which is the measured behaviour the patch description quotes. So I would frame the patch as: keep the usage count elevated on SoCs where the hardware consumes the CMN outputs behind Linux's back. If the preferred long-term shape is instead to describe those consumers in DT (or to make the clock ops take runtime PM references of their own), I am happy to help test either on IPQ5018 hardware - but until one of those exists, this one-liner is what makes the SoC boot reliably, which is why I kept it minimal and Cc'd stable. > The CMN_PLL_LOCKED bit offset and behavior are consistent across all > IPQ platforms — the same register layout applies to IPQ5018. Understood - but then there may be something else wrong on this SoC, because the measurement is unambiguous: on IPQ5018 the bit at offset 0x64 bit 8 never asserts. Every clk_cmn_pll_set_rate() call runs regmap_read_poll_timeout() to the full 100 ms timeout, including for the very configuration the bootloader programmed and the board demonstrably runs on (ethernet and wifi clocks all functional). The -ETIMEDOUT is then swallowed because clk_change_rate() ignores the .set_rate return value, so nothing is ever logged. If the layout is the same, is there anything that gates lock detection on this SoC (analog block state, reference selection, a status-enable bit) that the bootloader may leave in a different state than the driver expects? I can run any register dump or experiment on the board that would help pin it down. Thanks for looking at this, and thanks Mieczyslaw for the review. Stanislaw