Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1232626pxu; Mon, 23 Nov 2020 15:26:03 -0800 (PST) X-Google-Smtp-Source: ABdhPJz5ikTaebBIV1itlYY9BaAM6CfdEheAuWblADq0qvW/T9n2hGyXsPnNgHqmuNGfHWcjVVwz X-Received: by 2002:a17:907:4186:: with SMTP id mz6mr1852337ejb.175.1606173963381; Mon, 23 Nov 2020 15:26:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606173963; cv=none; d=google.com; s=arc-20160816; b=Oorx/jsZYoT4Xbus4Q/uYmYAxeIfdK4nQ/EhXU7IYCv/bGWBdFYKf5omIDekfC+RfN zvj6DsNfJgX1aUz6gZ/JeO5K+7S1GGVKCfsd4VAiagAcXjyLTXxNKi/98osJY/WyfMdk Nly1TZpkLz3riwH8cn4kzI/n1bD2X0m6QOZx2F7vQzP3d0v6wdgwfU7ivB3e0j6flbU2 2UkP7ucCKakHW44EMcfZacqygz9IGf/Sbmk+/k7ZqY7tguwsA+HWOhL3fonupTAM7Sdn SxGU4kRFbElfVx93g4KUWanxt/YSIZ6vlp40hq12jHYBSHGXSi/V+cppsmFVlAeqaX5k tiCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=tx/OnqiRrP8VUoD4DkDXg2C0ft4COyUxzNFZzDMJFZE=; b=oMSxQ9TiVlEoclrOankENbfGjByC5hnjQ+qV+wabvW9fKVAMLNstbly4VC+8mxshPA ntWr8tsCecqW7e2pN6+ZPiLzNEEB4RpvhWHPBwb0giPmKzTXMLzggOUiIsRDSP5OA8C3 /PXIfKOMCQaMTQtKtt+y9BJhU3q67MNHySEiP27v11hKmEf4v9ZFMSOfmu4m5kToct50 9NlF7W3Q5GjA9WnvuZ6iLAjY6rK1YiQHasxvaWQv2ZBBfYjwlPtyFc0J2Wn3SkWyb5mE E9jq1FpK2vBp5fd38EQSyt8fTfu8EcIIvIPSWJ8BfQ7GDp7SoWKZMo4569QM0K3/texp QQHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="dtSFegw/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j15si7379398ejv.71.2020.11.23.15.25.40; Mon, 23 Nov 2020 15:26:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="dtSFegw/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727116AbgKWKUP (ORCPT + 99 others); Mon, 23 Nov 2020 05:20:15 -0500 Received: from mail.kernel.org ([198.145.29.99]:36858 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725806AbgKWKUO (ORCPT ); Mon, 23 Nov 2020 05:20:14 -0500 Received: from [192.168.0.50] (89-70-52-201.dynamic.chello.pl [89.70.52.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 94F212072C; Mon, 23 Nov 2020 10:20:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606126813; bh=lKWIE0xfvLNVmwvlh6n8fLQGdMFXyaSAl3QgCRzu1aM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dtSFegw/Yhyq993hTtZSIfwSEuFsrCkk8L8Ekyc64C6f+3eXL5ZdJfnp8MNcnRnf+ qVLtmjb3lzgK9UHDQn+ywMqprnd+d9JgRyXdsdDNFGF7PHG8EEgXEnTJtU9L8xZO4B ToqlflHQBOvDoo8cluinH9R7YTJ9giRMO6VIrFQk= Subject: Re: [PATCH v5] clk: samsung: Prevent potential endless loop in the PLL ops To: Krzysztof Kozlowski Cc: Sylwester Nawrocki , linux-clk@vger.kernel.org, tomasz.figa@gmail.com, cw00.choi@samsung.com, m.szyprowski@samsung.com, sboyd@kernel.org, mturquette@baylibre.com, b.zolnierkie@samsung.com, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org References: <20201120155731.26898-1-s.nawrocki@samsung.com> <20201122151602.GA5346@kozik-lap> From: Sylwester Nawrocki Message-ID: Date: Mon, 23 Nov 2020 11:20:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201122151602.GA5346@kozik-lap> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/22/20 16:16, Krzysztof Kozlowski wrote: > On Fri, Nov 20, 2020 at 04:57:31PM +0100, Sylwester Nawrocki wrote: >> The PLL status polling loops in the set_rate callbacks of some PLLs >> have no timeout detection and may become endless loops when something >> goes wrong with the PLL. >> >> For some PLLs there is already the ktime API based timeout detection, >> but it will not work in all conditions when .set_rate gets called. >> In particular, before the clocksource is initialized or when the >> timekeeping is suspended. >> >> This patch adds a common helper with the PLL status bit polling and >> timeout detection. For conditions where the timekeeping API should not >> be used a simple readl_relaxed/cpu_relax() busy loop is added with the >> iterations limit derived from measurements of readl_relaxed() execution >> time for various PLL types and Exynos SoCs variants. >> >> Actual PLL lock time depends on the P divider value, the VCO frequency >> and a constant PLL type specific LOCK_FACTOR and can be calculated as >> >> lock_time = Pdiv * LOCK_FACTOR / VCO_freq >> >> For the ktime API use cases a common timeout value of 20 ms is applied >> for all the PLLs with an assumption that maximum possible value of Pdiv >> is 64, maximum possible LOCK_FACTOR value is 3000 and minimum VCO >> frequency is 24 MHz. >> >> Signed-off-by: Sylwester Nawrocki > Reviewed-by: Krzysztof Kozlowski Thanks, patch applied. -- Regards, Sylwester