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 E73FFC02183 for ; Mon, 13 Jan 2025 16:20:23 +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:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4Ifn517rhKAK4kPblGxh958I8b7bKVL3ZD4An5S/N2s=; b=bHN0GpZPmnddpP 0wVoLutBnTUnNbC3TZZ4SvveJ4g9I2jASmRjmV5AtcdccUpOxLvvkM4CE29xB3cKlgeq1Hi1iX2lw qm5sFF6U6BklslxCkP/G/D4p9eubMzQy1XaUU6U2J/YDHY4sz+PCDuJfg02o2TN1Uhj8CGaUhwAZY 6eHlzli5yUClrNQiIIQDVt7CiPoldqnsZMJcaf8vrslvo2vHq4jSfSErJ1lS3WIR3av8DPF4hjAin fIcyaIsvE9jWgvB9++ybqEXSUaTXO/Md8oqujUtXUDi5Hseu8z0qCIj590qa+XqyBRBPXUPOkuA1z +bkhecUyNIqsDdJ3V6pQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tXNAo-00000005our-0iTo; Mon, 13 Jan 2025 16:20:18 +0000 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tXMh1-00000005iev-3D0F for linux-amlogic@lists.infradead.org; Mon, 13 Jan 2025 15:49:33 +0000 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3863494591bso2396062f8f.1 for ; Mon, 13 Jan 2025 07:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1736783370; x=1737388170; darn=lists.infradead.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=Azq+DaVA//EhU0oOCgPNA2FLamSCcJm54Ub5++OHsas=; b=xUC3oP0p8ITnNkLWxqp50l0U2D12MbtVz8iMCZwf3KTuITQhVsMRga2QYKDVkG1+z2 iJBShjTl6es7PEkjYyQXkt/9FZICjbSC8wLjlKAfOsbCP4P0sScxvvWIKxR4nGZxfyPc w5rEreOqxEKWxRLflWUfFo1IQMRVU5Y95MOjJop05U1r+sr0+W9YlSu1eIv6kY888wNL dgbGY61tCuQKeGgg3DwDi8hjgicI9sbLZDTkd1tW4tBph1rLDJmR8qxPInKtua2QrUYt LKhyTUXl2q+QLTmODRlyyujv86HOQv4uRmq8l7Izt1evdRODqnR/D1n2wI7EZ+9zW89N TgRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736783370; x=1737388170; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Azq+DaVA//EhU0oOCgPNA2FLamSCcJm54Ub5++OHsas=; b=uueRhiE18rrunaUZsjrPXcRoA6LxkAfJqvuV6Wc0yaPksu3SuRobDQKCg7VRKACrs2 FYK7UWerzq+3OPAVWxEe6TaWkRlHGVQ3Vv2GXCLD0BQCJ9a7u93auEtCwjXpgzelixYQ SxqiTupe6DpL7d1N0smF7fa+Vhvf9S6co7C77zKxn5Ebfu/LvXDEYJtY6mGolmZpZpa8 2nuGLgZymXvTQJ21Y6Qbe0GsmApepifNiSGwoRvWUhtXLj8vTxVyioCV7yn0FLZU8c90 qZ4IRwSyrWNQcj6vm2aQi6CkZEp3Qa4S7ULePW8A00ayWITw06bJkt/Z4wpKzTW19w8S wAeA== X-Forwarded-Encrypted: i=1; AJvYcCX+cqXMdXfIGFxP6duFsYU1hyyZokplQ8TLdtvsRxdv+l0K68eMAXxm2Th4ZI0UXSQF0u+vvxKvD3tTv0xY@lists.infradead.org X-Gm-Message-State: AOJu0Yzw02YY0+zVoKDgc0YjByABxllo1g9lpNHBAP6Re9bFfODScC1/ ExgBigZNbgv6IAq6plfo3QFYpsEx97R/3O6wh0EgwTJmBR4RmHw6NvqzYl/oYV0= X-Gm-Gg: ASbGnct6FWwsSn+ZjVKo8Lbd5nfZQ+NqdIsGfLObCFWCfPgEIS8CFCxsSdJDWDbYX4h SXWKzBOprCT03XnlPgMx7bQl6aeQ93huHXF61vXS+JMtSftkqnKT9F5yrJV3zs3Wo5XY2vBc5Ow TbS5hEPLKaAS5P/t790d/dJrYgDkLRGElG4iFJZMXnqFamxKTG0/A8IhMjXaiPtXSERWYSPW4hS ENYSHFVs1/riK5kTWdsmNZQa31+iOgVLXUKIHZ4OT+KTCPoOLQe0V+i X-Google-Smtp-Source: AGHT+IF09k926b51tgNC96zHwr2fNP9lLjmS+3CaIX3Evh6rq9eXJgioLCN7Rbq+LYTF7EgYPM9XXg== X-Received: by 2002:a05:6000:1446:b0:385:f47a:e9d1 with SMTP id ffacd0b85a97d-38a872dec76mr17354805f8f.17.1736783369675; Mon, 13 Jan 2025 07:49:29 -0800 (PST) Received: from localhost ([2a01:e0a:3c5:5fb1:9d2d:28cc:aafd:8429]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a8e384054sm12552709f8f.36.2025.01.13.07.49.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jan 2025 07:49:29 -0800 (PST) From: Jerome Brunet To: Neil Armstrong Cc: Chuan Liu , Chuan Liu via B4 Relay , Michael Turquette , Stephen Boyd , Kevin Hilman , Martin Blumenstingl , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/2] clk: amlogic: c3: Limit the rate boundaries of clk_hw In-Reply-To: (Neil Armstrong's message of "Mon, 13 Jan 2025 15:46:39 +0100") References: <20250110-limit-rate-range-of-clk-v1-0-dd618adc4aa8@amlogic.com> <20250110-limit-rate-range-of-clk-v1-2-dd618adc4aa8@amlogic.com> <1j34hqai39.fsf@starbuckisacylon.baylibre.com> <2578a79d-1e24-4336-9859-e384c8f69269@amlogic.com> <1jr05693nn.fsf@starbuckisacylon.baylibre.com> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Mon, 13 Jan 2025 16:49:28 +0100 Message-ID: <1ja5bu90jb.fsf@starbuckisacylon.baylibre.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250113_074931_810720_C135475F X-CRM114-Status: GOOD ( 14.69 ) X-BeenThere: linux-amlogic@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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org On Mon 13 Jan 2025 at 15:46, Neil Armstrong wrote: >>> >>> I think that the clock configuration exceeding the timing constraints >>> is a hidden danger that all chips have and face, but this hidden danger >>> is not easy to be exposed? >>> >>> For instance, if the routing of a clock network is close to the clock >>> or data bus of other modules, and this clock network is wrongly >>> configured to a frequency beyond the constraints, causing crosstalk >>> that affects the normal operation of other modules. If such a situation >>> occurs, it will be very difficult to troubleshoot. How should this >>> situation be handled more reasonably? >> Fix your consumers drivers if you need to. Set range if you must. >> Those are not clock provider constraints. Those are use-case ones. It >> does belong here and CCF already provides the necessary infra to deal >> with ranges. > > I kind of disagree here, if the vendor has the data and is willing to share > the range for each clock path of the system, I think it should be welcome! > > Usually those ranges are not disclosed, so we don't set them, but CCF will > certainly use all those range to make an even better decision on the lock > routing. I did not say you should not use them, I say that a platform use-case, which is what this is, should not be hard coded within the clock provider driver. This is no different than an assigned-rate, and like any other platform description, it belong in DT. We've already seen how these ranges may depend on what else you choose to do on the system or even what package a particular SoC variant is using. > > Neil > >> _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic