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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45C72C4321A for ; Thu, 27 Jun 2019 21:15:06 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id BD745208CB for ; Thu, 27 Jun 2019 21:15:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Ye7eL3t8"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="CNMciDmG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BD745208CB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-Id:Date:Subject:From:To: References:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fm/GomdZ9AKyBayXV+4F+f9WHN3ZoJ9QNNfc8PSG8bc=; b=Ye7eL3t8obOqom NIl+280A40JxgeUVwUUZlw3Ar3PjM8nKuGP9LAGF9T01siMg8SdxdB63Y6A6EGau/AMhFkifppUZx zrzUmgenVV1rcBp3/4DjNSaG5rXZn9zrwtTdAfnxzESNTlktUUhpVbDnDB0jbZbMaz3B4wwu/aAX2 y5TR3zxwnWL+UqxX7G5SliWDv6EuIGwKix753ONHHOjWfop5t7NPfyDZ8Qg1RmuO+ofefcUtlT74X xFOqzhopxjA7brpZIuIdn0S/lCsf4BEiRhIq+/D/+KiggJMnpwFW3vEEawYG2zxJ5ICzOolU9kZKT ZApCkGtR0E4/u+yKb6yA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hgbjM-00050R-Qi; Thu, 27 Jun 2019 21:14:56 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hgbjK-0004zv-0a for linux-arm-kernel@lists.infradead.org; Thu, 27 Jun 2019 21:14:55 +0000 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 37FF4208CB; Thu, 27 Jun 2019 21:14:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561670093; bh=aF18PB9ndCbQ/0tO043NbIEQd0ErKNrDAli6X2roWq0=; h=In-Reply-To:References:To:From:Subject:Cc:Date:From; b=CNMciDmGkyUYWNkDg4WtU6vSG5PpIaJeyI1Upn0mozqwrcBTJRUhBZhl8YEV0+/Zv WN4ik+trQwPg6qycA+od0fYc9/pkYm3PLK6t//UKhFyPMmNX0+GkThhgWqnArchKwB PXUS29YhxcVR4eRS9/ga35BFDW8O+jwqMn5mUEJo= MIME-Version: 1.0 In-Reply-To: <475e0250b1e77a660c095749e78427fde318d5f6.1559200405.git.leonard.crestez@nxp.com> References: <475e0250b1e77a660c095749e78427fde318d5f6.1559200405.git.leonard.crestez@nxp.com> To: Alexandre Bailon , Jacky Bai , Leonard Crestez , Michael Turquette From: Stephen Boyd Subject: Re: [RFC] clk: imx8mm: Add dram freq switch support User-Agent: alot/0.8.1 Date: Thu, 27 Jun 2019 14:14:52 -0700 Message-Id: <20190627211453.37FF4208CB@mail.kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190627_141454_092214_85DEE775 X-CRM114-Status: GOOD ( 13.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Aisheng Dong , Peng Fan , Abel Vesa , Anson Huang , "linux-pm@vger.kernel.org" , Viresh Kumar , Nitin Garg , "Rafael J. Wysocki" , Krzysztof Kozlowski , "linux-clk@vger.kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , Cedric Neveux , Fabio Estevam , Silvano Di Ninno , Shawn Guo , Georgi Djakov , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Quoting Leonard Crestez (2019-05-30 00:13:51) > Add a wrapper clock encapsulating dram frequency switch support for > imx8m chips. This allows higher-level DVFS code to manipulate dram > frequency using standard clock framework APIs. > > Linux-side implementation is similar in principle to imx_clk_cpu or a > composite clock. Only some preparation is done inside the kernel, the > actual freq switch is performed from TF-A code which runs from an SRAM > area. Cores other than the one performing the switch are also made to > spin inside TF-A by sending each an IRQ. > > This is an early proof-of-concept which only support low/high mode on > imx8mm but NXP has secure-world dram freq switching implementations for > multiple other chips and this approach can be extended. > > This was tested using a large pile of NXP out-of-tree patches. Code for > the "busfreq core" from last release can be seen here: > https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/soc/imx/busfreq-imx8mq.c?h=imx_4.14.98_2.0.0_ga > > It can be likely made to work with interconnect RFC: > https://patchwork.kernel.org/cover/10851705/ > > This RFC effectively refactors a common part between them. > > Among the possible cleanups: > * Handle errors in low/high busfreq code and back off > * Move irq to secure world > * Try to use fewer clk parameters > * More chips and frequencies > > Many platforms handle this kind of stuff externally but cpufreq is quite > insistent that actual rates are set by clk code and that new platforms > use cpufreq-dt. > > Let me know if there are objections to handling dram freq via clk. Can it be an interconnect driver instead? I don't see how this is a clk driver. It looks more like a driver that itself manages a collection of clks, and you've put the coordination of those clks behind the clk_ops interface. We don't want to have clk_ops calling clk consumer APIs in general, so the whole approach doesn't seem correct. Hopefully this can work out as some other sort of driver that is used directly from devfreq or interconnect core instead and then have a different consumer driver of devfreq or interconnect core that knows how to drive the clk tree. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel