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 74239C61DA4 for ; Sat, 11 Feb 2023 09:21:16 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=RNafyVsOK6PIlYy51rr1kY/1jpIEy1pSQ3r9gWGpQck=; b=iafHazAxtb6Zws xm+CMoalORBNYrNBdxdGh3srww6frCauNxNJhtIMgm4/puE+vduftqpL2tOZueycMzt9UHwK70Ad+ 7DcM2wzFhft3K+QgsTs+wzD4cDPxqAbCReUe7Fy5f8Q1SQVZwgZ8H5NkFf3RVjM947J/ucd5LjCNB xALruTn2/lkxiExfh/3+b7rf/PQrUp8xBRzm0Tjjk6xuVjBgVK0Nb50RVEoUhJICxJnBB3AGgj6py HaTtJkrbtG5Ca54PJnsJZgJF8qcFR1CFO2ZPAXvatOrLOERysQ0aZuVNOUlosZN0aOFu5ML/mV+z0 unvnIv/6kEgnSSIx55/g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQm3H-0097TT-0E; Sat, 11 Feb 2023 09:20:11 +0000 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQm3E-0097Sl-4T for linux-arm-kernel@lists.infradead.org; Sat, 11 Feb 2023 09:20:09 +0000 Received: by mail-ej1-x62f.google.com with SMTP id ud5so21337208ejc.4 for ; Sat, 11 Feb 2023 01:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6Ay7GopDhxpUWXvFU/Desi3ncPwaICJKEa+mMLgmlAI=; b=O7wHkho8aDQgo94UfFVY9X+XG/U+2SPSmWJ435T0PJxK0wOCnONbmuwo8viMsiCcuO buC/rLfDgF+j3xQ2VEwC1njKqtZTtDbzXNbVE3KUkhlgYxpdXWNLq62thnYyW0bTgI3V KJRwLI6WpGbUbgf2gxyHIO5uEXXwlSuiYb23U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6Ay7GopDhxpUWXvFU/Desi3ncPwaICJKEa+mMLgmlAI=; b=OceCJ+BlRr7FwMzt5w7TMbmq2IEKtITr2iy+UQ8zZsQcUf9dKeZlVkJeoD/uX3hNtd zFdk1Fcrjw6aiEpEinmH0LUAroMLLfaZ0HQgdJ3I6YPdetXEUF4HULebYh6yqZnYgB+f rMiMwrrCiw8Qk+bgwy18zTyHOfnCO20wNwi9JbgcG9tT8H28wR5/Oa2w0NZg3iYSAGz5 kJ0awkkA4Cvd26Jk3AegNy3Axn72NLxb9f/O71JOq/BGddxwpoNlRpAMlUMvKPvrITLC 47Tr2ZJGhq6MqYsd+28EgmC0KsJBSmAd3oMT+ZA5/gmm/3XhV4Hew/TMqS/8+acJ18y8 wN7g== X-Gm-Message-State: AO0yUKWqcZVeOlWUrQz7s5cXD0dfpsqf2DWKTQFAde4tSxet4JNNv+Ve 5ihu9XukFUEizCJznpmOi3q8jfO52KClMAz1jvIa4A== X-Google-Smtp-Source: AK7set+jZ705IMIDjL87PKlafwfn4leLVjN6W0uPB/ZG04XFihgIOINn7gMrXMHNl3mnPgeREDPQ8Or/gVMTa8GMDfY= X-Received: by 2002:a17:906:69d1:b0:886:4fe9:1d51 with SMTP id g17-20020a17090669d100b008864fe91d51mr2131922ejs.12.1676107203273; Sat, 11 Feb 2023 01:20:03 -0800 (PST) MIME-Version: 1.0 References: <20230101175740.1010258-1-dario.binacchi@amarulasolutions.com> <1fc8686b0b66c3b3ff80c044ecf1add6.sboyd@kernel.org> <83a3c8d0abf217369f045df0217b1f64.sboyd@kernel.org> In-Reply-To: <83a3c8d0abf217369f045df0217b1f64.sboyd@kernel.org> From: Michael Nazzareno Trimarchi Date: Sat, 11 Feb 2023 10:19:52 +0100 Message-ID: Subject: Re: [RFC PATCH v2 00/11] clk: imx8mn: setup clocks from the device tree To: Stephen Boyd Cc: Dario Binacchi , linux-kernel@vger.kernel.org, angelo@amarulasolutions.com, tommaso.merciai@amarulasolutions.com, Chen-Yu Tsai , linux-amarula@amarulasolutions.com, anthony@amarulasolutions.com, jagan@amarulasolutions.com, Abel Vesa , Adam Ford , Fabio Estevam , Krzysztof Kozlowski , Li Jun , Lucas Stach , Marek Vasut , Markus Niebel , Michael Turquette , NXP Linux Team , Pengutronix Kernel Team , Rob Herring , Sascha Hauer , Shawn Guo , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230211_012008_244947_353DAAC2 X-CRM114-Status: GOOD ( 36.67 ) X-BeenThere: linux-arm-kernel@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-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi On Fri, Feb 10, 2023 at 11:49 PM Stephen Boyd wrote: > > Quoting Michael Nazzareno Trimarchi (2023-01-26 02:49:54) > > Hi > > > > On Wed, Jan 25, 2023 at 10:11 PM Stephen Boyd wrote: > > > > > > Quoting Dario Binacchi (2023-01-01 09:57:29) > > > > The idea for this series was born back from Dublin (ELCE 2022) after > > > > having attended the talk entitled "Updating and Modernizing Clock > > > > Drivers" held by Chen-Yu Tsai and the availability of a board with > > > > imx8mn SOC. > > > > > > Interesting. I didn't see any mention of putting clks into DT in that > > > presentation. > > > > > > > > > > > This series aims to setup all imx8mn's clocks from the device tree and > > > > remove the legacy setup code with hardwired parameters. > > > > > > Please, no! We don't want one node per clk style of bindings. > > > > I think the idea behind is: > > - create a way from silicon vendor to export their clock mapping with > > automatic exportation > > I suspect silicon vendors automatically generate their clk drivers > today. > Was easy to think that creating tools for dts generation was easy to have because they don't depend on the internal linux kernel and they are formally described. Export clk drivers considering kernel internal change I don't think that can work. > > - reduce the copy and paste code across the drivers > > - avoid code duplication > > Code duplication should be avoided. Surely the clk_ops is shared? Data > duplication is the real problem here. The status quo has been to have The idea to have in dts was to have much less code by the end to handle different SoC vendors but as you pointed me seems that you are more concerned about data duplication. > data descriptions of clks in drivers so that drivers can turn them on. > If we're trying to avoid bloat then we only enable the drivers that we > care about, or make them modular so they don't waste kernel memory. > I'm not an expert of the dtc compiler but, is that possible that some optimization can happen there in the feature? > If you have ideas on how to avoid duplication there then by all means > implement them. Don't move the data duplication problem to devicetree > though. > We will sit together again ;) after your comments here > I've been wondering if we can tag drivers that are compiled into the > kernel as freeable if they aren't ever going to probe because they're > for some SoC that isn't present. That would allow us to shed various > builtin clk drivers on systems instead of forcing us to make everything > a module. This is general on the driver level but sounds like a good idea. Michael > > > > > Is the binding a way to solve this problem? > > Don't think so. > > > If you don't want one node > > per clk style bindings, did you still think that the way > > to go is totally wrong? > > Yes. -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel