Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp906525ybm; Tue, 21 May 2019 05:44:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqy3jESdwrmrJXFC4mpzq3FXiZR8+w2OcJdNRkeb8+UlrnGi9ico+fkiBWbQ+VhnAcbwvT/R X-Received: by 2002:a63:e50c:: with SMTP id r12mr67617665pgh.284.1558442661734; Tue, 21 May 2019 05:44:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558442661; cv=none; d=google.com; s=arc-20160816; b=pBysmCV6SaRD/3/nPEQyvleVsCVEgyXaM/MNYT1Ciru4xISk7gpHqGpcvS4apcJmgM NZki+OiTwVAx6dfXepheUMwvhNmvmkVO3moN75ytiS6xgSgFXur5yo4dVaYN+hGgt4b/ cEBTYBQWt18Et8t3MyIKdN6eflkShkQTvktKqKzzzTfPEkyswlI/pGtrWsnPoaYwnRox X+eOLdcpp8Whz9WAB45djwP7B4xNHw+1PPNKmbVOmHxEsTOb0UQv2ieCduLREMq+GEQz cb36e060GBw8/KVqj+LCGlTOujkHvJbs48M22O77EADNtGv94/jyIqebAWu4/U60JyJg gpdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject; bh=/fS2EOtbHy5crDnVhbn2+If+1ZmXEU7oD+QFZrjvq2g=; b=WD0prVhE5n96is5h9wR0F0dWNGO/MZ7LIBcowtLXzwzf4l8pePis8EvJrSyw2jZBGA igZSFQXU78/bCtKJj+ag+m9V8uTtAy8UutBDPv7FpvauR1OJgT1v4HZVYZGfpJqqfKWx 220/kuhezXEQSf1gdgS/41YEbJCMY8Gs1Uuf9gkSsDb2CnkDuxQVBouUqo/CXYyiFBaW mub0wynBsRcF1829NZjjz5yMMMLJo8QhwwcMHBFut6fNzR2b+mD6OU7t9INnT+61vGD9 4AGl4x858MYP5HfV+f6yFgXzUqLhOSi1J7LZuQDZeNelLUkdVzTMzb9ADE9sF7aZBW+l 7uVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o70si22066066pfa.33.2019.05.21.05.44.06; Tue, 21 May 2019 05:44:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728006AbfEUMl2 (ORCPT + 99 others); Tue, 21 May 2019 08:41:28 -0400 Received: from mout.kundenserver.de ([212.227.126.134]:50737 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726750AbfEUMl1 (ORCPT ); Tue, 21 May 2019 08:41:27 -0400 Received: from [192.168.178.167] ([109.104.45.223]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1Mz9lL-1gfcTu2sbL-00wEc7; Tue, 21 May 2019 14:41:01 +0200 Subject: Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb From: Stefan Wahren To: Nicolas Saenz Julienne , Florian Fainelli , Ray Jui , Scott Branden , bcm-kernel-feedback-list@broadcom.com, Eric Anholt Cc: linux-arm-kernel@lists.infradead.org, ptesarik@suse.com, sboyd@kernel.org, viresh.kumar@linaro.org, mturquette@baylibre.com, linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-clk@vger.kernel.org, mbrugger@suse.de, ssuloev@orpaltech.com References: <20190520104708.11980-1-nsaenzjulienne@suse.de> <20190520104708.11980-4-nsaenzjulienne@suse.de> Message-ID: <6383b357-3f7e-f031-f59f-61c598e44763@i2se.com> Date: Tue, 21 May 2019 14:40:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Provags-ID: V03:K1:tiKWVTmj0/g6cApKXUC8RRsZ+jzrxl/tRzq9vOMKmDYvP0avI57 S32E8AJVOWyViyljIeairozBYEi/9tS3d9Quw2v/CXkw1a6Ar/crQaVR2APWjjJGUJ60Nmz nZxhLgGefhNTSdMfJ5IvnUvMZRFoS2G0atk28i59/4Gi004Fp1AZZlWoUamsxO3xaRfcezn ZcSESHjDxbmzXOZpl4Oaw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:VAEVr3c8/0g=:H9FaA9a655WuE86lTBUiV4 2OJ0EepMNcKZDh29WOG6N+37XmL8YWraPTsNDcx7Rcf5OUR9+v1spI6wGk3DqpqMAcbBTkYXU irJhNgFzv/ehQJyoulSGeHTVIaCj/69YyDXUVPakRsvPb7fytYzSd+G/oU6+D9e+I2KQlcdBs CJqaFK1sW1UAEZQ13+kumPGYC463OkExAGsUsNvLNfw7i/a7IVT/0V5OD6zYs11hHtvV0SSIl wdjummx1yyjp5j2WYl1h9O7/QQZ1uo50V+AjtmGZx9gT//W9WmNnykfdJuAXgkCtZ6hNlXB7X F3nBUgXaNIb80nqocavO2b/2Fg+Bk2Q+bVTG47IHHKdD4hLsum7dMGUaBLs7oyJWJzXHE3/CU OX7QgcXooNyVJLSNQ649qi9KFPjYrgeg0+HK8MJKM+f9zggdSGXrdiHl34vhA30lVkJ2JT4wE gQr9/s/obESz4h4X9wyILrQf0Q8t//x1ONi9NubbHANW7XBAlGLRL9KvUdOhGrmQ2Ofl76kJi NZ0/Iu0opHBvrEUr5CQrCYE4zcOFa4ydGZSKAoPjmuCKM/3N1igCCedn6fTdp9RR6UVIVrieM 3QMxnrsaGyx4qt+BtEe1ikMK6T6EVLQGOb7jkCxsoKFPYmuLJicghwwAhW7FVaDgGHGSIGYus a+KY2w+DQWj7xERtmRI3FaqGxWQGHAc9NkezH98aiMdImPcbmDSiHr0xWsZ3HBlI27xs4GHAD 4v+WV6ijitxntnFIA4En+ZvAntlNK5t+0DuJDVlop7vKvyiX4ON55G5Lljo= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Nicolas, On 20.05.19 14:11, Stefan Wahren wrote: > Hi Nicolas, > > the following comments applies only in case Eric is fine with the whole > approach. > > On 20.05.19 12:47, Nicolas Saenz Julienne wrote: >> Raspberry Pi's firmware, which runs in a dedicated processor, keeps > maybe we should clarify that the firmware is running in the VPU >> track of the board's temperature and voltage. It's resposible for >> scaling the CPU frequency whenever it deems the device reached an unsafe >> state. On top of that the firmware provides an interface which allows >> Linux to to query the clock's state or change it's frequency. > I think this requires a separate update of the devicetree binding. >> Being the sole user of the bcm2835 clock driver, this integrates the >> firmware interface into the clock driver and adds a first user: the CPU >> pll, also known as 'pllb'. > Please verify that the kernel still works (and this clock driver probe) > under the following conditions: > > - CONFIG_RASPBERRYPI_FIRMWARE=n > - CONFIG_RASPBERRYPI_FIRMWARE=m > - older DTBs without patch #1 i thought about this and the case this driver would return -EPROBE_DEFER. The clock driver is too essential for doing such a thing. So i think the best solution would be to move these changes into a separate driver which should be register by the clock driver (similiar to vchiq). This also avoid the need of a new device tree binding.