Message ID | 20230101175740.1010258-1-dario.binacchi@amarulasolutions.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp3857290wrt; Sun, 1 Jan 2023 09:58:37 -0800 (PST) X-Google-Smtp-Source: AMrXdXtoZhvHH1LeGt2KOS7N1kK4cICmzuO0BeDRWnX30F6iyYG7BXDG7DFoZG7r9wiPdliBdChE X-Received: by 2002:a17:906:1419:b0:84c:9016:79ae with SMTP id p25-20020a170906141900b0084c901679aemr10538249ejc.53.1672595917206; Sun, 01 Jan 2023 09:58:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672595917; cv=none; d=google.com; s=arc-20160816; b=xbLFCLI57HF79mxJRmZUZNerttfwh+0qFupxuyBM9ACt78i/IbAC2vTpUvszQ6tJPV P/3YAZmO0QpyZiqWqFAMQr2U0CJGQw88J/DxQWRMJhXkS7fui7u3Mg7/5J2COSwXyrAX pT1fEJQhznaO/UswRqMQ7bpLQn4DIiY6t5SEacBRgbexCU+FhUropJaqsLMNW4rsHRdO pqvABUO+i5QyusQlueM/wLXg7zM5wHJA7/6Xi2sXyi01YSYHKuIP8FRAr2icmL6A8/Z1 oBBq5afJgAneKL/wpoXtyDQ4lpcB38N3OZ01pTq0+CibyaCHi2Acz5/5dEZwUiTby24S QEsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=ALuH1lvp2knJtHcYW+i1s8ZvzexDo4P1ZGTmQCOOx0Q=; b=MySOHwGY4Sxg/jdKUNdqq10HwHn1jzV7jsGWb2iSrhZQocdeF5GYOq8C1aaAK+jLST CMFRLW4hC93DyiIkzS3OFQZjHfjvJzzWGeoltEeduPoa2zyhnK29yF1i0MbOYdBdo6O5 ay9lLrIV+tn9RfBeBusJx149TuvGY/S9zwyX/1x1lDSDg8SzChBZInYiS5bDYIhLgspl Z8DwKHiWeT1JmY4pFVOzfsaarUyobHQGa+SuoQpAiW0urYUvc0FrtL+7bmZBbAwY3OL8 t3Wauwk/VfxDJuCT5jS7BmWrcCtFGhdBDao9I/i0PyN9maeY/iJbgmlJjRuyBeADsz6n k8QA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=gHsBdSkn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=amarulasolutions.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cr21-20020a170906d55500b0084a52896274si21156837ejc.961.2023.01.01.09.58.13; Sun, 01 Jan 2023 09:58:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=gHsBdSkn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=amarulasolutions.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230197AbjAAR5w (ORCPT <rfc822;cscallsign@gmail.com> + 99 others); Sun, 1 Jan 2023 12:57:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229847AbjAAR5u (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 1 Jan 2023 12:57:50 -0500 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0BA2826FE for <linux-kernel@vger.kernel.org>; Sun, 1 Jan 2023 09:57:48 -0800 (PST) Received: by mail-ej1-x642.google.com with SMTP id vm8so55333182ejc.2 for <linux-kernel@vger.kernel.org>; Sun, 01 Jan 2023 09:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=ALuH1lvp2knJtHcYW+i1s8ZvzexDo4P1ZGTmQCOOx0Q=; b=gHsBdSknCJsKckxDmgjNLhkIjW0BxoYHD+AxZTIb+PS2dNuIJEZd4QJm8tJIyMCBJU XEwkcyZsEk5WCx+RKUZPFU5911LKl++VPqkPCh19NouOSUBwJkSYCCYfCvAa21cuLqDO oGo46nKNjTTqMNb169uhDu7J5qhO7AHEKeQkQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ALuH1lvp2knJtHcYW+i1s8ZvzexDo4P1ZGTmQCOOx0Q=; b=aZwackx3zybDsQyzehxSuWzGFDpFNBo5Alkbu9x8Ovv7P5fIafe6Vjm5GbNf4ioex7 enwPidvFtKdSDR2jE06oBVOF+KxYKdaXACis6vL/4l6U4sywE2N3TrR36TWiT88RseKa 6viGsYkLN9FstCRmCYeGjm3RXCm5p0SgtQeugLm33FeFV4US2umGki9YQPA9COt8dds5 7LhVPwhJJZno6ShjXuI8AlqguSQrMlhHnfoYAnSrwfaij5xnbAzlsB/El8CNtZmEXxg+ eVtvkM+OQKUE+cTcqtNFuXI3E2QXyKt8JwWKeJa1liErT5fPAKn406NnkCo4mM5fDI66 25Ag== X-Gm-Message-State: AFqh2kpfsQQXq+VDHS17vFN7RIN5vNj6vblw5TX1ZacAnsSL+XzIzgoz qcZRfdVEJxjTwO9EfktSWfmoFGPq++j+2JU5oZM= X-Received: by 2002:a17:907:d602:b0:7c1:286a:d87c with SMTP id wd2-20020a170907d60200b007c1286ad87cmr32679732ejc.65.1672595866417; Sun, 01 Jan 2023 09:57:46 -0800 (PST) Received: from dario-ThinkPad-T14s-Gen-2i.homenet.telecomitalia.it (host-80-180-23-57.retail.telecomitalia.it. [80.180.23.57]) by smtp.gmail.com with ESMTPSA id q2-20020a1709063d4200b0082ddfb47d06sm12273018ejf.148.2023.01.01.09.57.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Jan 2023 09:57:46 -0800 (PST) From: Dario Binacchi <dario.binacchi@amarulasolutions.com> To: linux-kernel@vger.kernel.org Cc: angelo@amarulasolutions.com, michael@amarulasolutions.com, tommaso.merciai@amarulasolutions.com, Chen-Yu Tsai <wenst@chromium.org>, linux-amarula@amarulasolutions.com, anthony@amarulasolutions.com, jagan@amarulasolutions.com, Dario Binacchi <dario.binacchi@amarulasolutions.com>, Abel Vesa <abelvesa@kernel.org>, Adam Ford <aford173@gmail.com>, Fabio Estevam <festevam@gmail.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Li Jun <jun.li@nxp.com>, Lucas Stach <l.stach@pengutronix.de>, Marek Vasut <marex@denx.de>, Markus Niebel <Markus.Niebel@ew.tq-group.com>, Michael Turquette <mturquette@baylibre.com>, NXP Linux Team <linux-imx@nxp.com>, Pengutronix Kernel Team <kernel@pengutronix.de>, Rob Herring <robh+dt@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Shawn Guo <shawnguo@kernel.org>, Stephen Boyd <sboyd@kernel.org>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org Subject: [RFC PATCH v2 00/11] clk: imx8mn: setup clocks from the device tree Date: Sun, 1 Jan 2023 18:57:29 +0100 Message-Id: <20230101175740.1010258-1-dario.binacchi@amarulasolutions.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753843936303509302?= X-GMAIL-MSGID: =?utf-8?q?1753843936303509302?= |
Series |
clk: imx8mn: setup clocks from the device tree
|
|
Message
Dario Binacchi
Jan. 1, 2023, 5:57 p.m. UTC
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. This series aims to setup all imx8mn's clocks from the device tree and remove the legacy setup code with hardwired parameters. I am well aware that the series lacks patches for the DT bindings. The effort up to this point has been important and so I thought I'd ask for feedback from the community before proceeding to implement them. If it is positive I will add the DT binding patches starting from version 2. The series has been tested on the BSH SystemMaster (SMM) S2 board: https://www.apertis.org/reference_hardware/imx8mn_bsh_smm_s2pro_setup Changes in v2: - Fix compiler warnings reported by kernel test robot. Dario Binacchi (11): clk: imx: add structure to extend register accesses clk: imx: add clk_hw based API imx_get_clk_hw_from_dt() clk: imx8mn: add gate driver clk: imx8mn: add mux driver clk: imx8mn: add divider driver clk: imx: pll14xx: add device tree support clk: imx: composite-8m: add device tree support clk: imx: gate2: add device tree support clk: imx: cpu: add device tree support arm64: dts: imx8mn: add dumy clock arm64: dts: imx8mn: add clocks description .../boot/dts/freescale/imx8mn-clocks.dtsi | 1885 +++++++++++++++++ arch/arm64/boot/dts/freescale/imx8mn.dtsi | 51 +- drivers/clk/imx/Makefile | 3 + drivers/clk/imx/clk-composite-8m.c | 84 + drivers/clk/imx/clk-cpu.c | 54 + drivers/clk/imx/clk-divider.c | 235 ++ drivers/clk/imx/clk-gate.c | 156 ++ drivers/clk/imx/clk-gate2.c | 86 + drivers/clk/imx/clk-imx8mn.c | 716 ++----- drivers/clk/imx/clk-mux.c | 258 +++ drivers/clk/imx/clk-pll14xx.c | 220 +- drivers/clk/imx/clk.c | 21 + drivers/clk/imx/clk.h | 15 + 13 files changed, 3177 insertions(+), 607 deletions(-) create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-clocks.dtsi create mode 100644 drivers/clk/imx/clk-divider.c create mode 100644 drivers/clk/imx/clk-gate.c create mode 100644 drivers/clk/imx/clk-mux.c
Comments
On 1/1/23 18:57, Dario Binacchi wrote: > 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. > > This series aims to setup all imx8mn's clocks from the device tree and > remove the legacy setup code with hardwired parameters. > > I am well aware that the series lacks patches for the DT bindings. The > effort up to this point has been important and so I thought I'd ask for > feedback from the community before proceeding to implement them. If it > is positive I will add the DT binding patches starting from version 2. > > The series has been tested on the BSH SystemMaster (SMM) S2 board: > https://www.apertis.org/reference_hardware/imx8mn_bsh_smm_s2pro_setup I might be wrong, but I vaguely recall AT91 (?) had this kind of massive clock tree description in DT and they then switched to much simpler clock description where the clock topology is encoded in the driver instead (like what iMX does right now). It might be worth having a look at that and the reasoning around that conversion.
Hi Marek, On Tue, Jan 3, 2023 at 12:04 AM Marek Vasut <marex@denx.de> wrote: > > On 1/1/23 18:57, Dario Binacchi wrote: > > 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. > > > > This series aims to setup all imx8mn's clocks from the device tree and > > remove the legacy setup code with hardwired parameters. > > > > I am well aware that the series lacks patches for the DT bindings. The > > effort up to this point has been important and so I thought I'd ask for > > feedback from the community before proceeding to implement them. If it > > is positive I will add the DT binding patches starting from version 2. > > > > The series has been tested on the BSH SystemMaster (SMM) S2 board: > > https://www.apertis.org/reference_hardware/imx8mn_bsh_smm_s2pro_setup > > I might be wrong, but I vaguely recall AT91 (?) had this kind of massive > clock tree description in DT and they then switched to much simpler > clock description where the clock topology is encoded in the driver > instead (like what iMX does right now). It might be worth having a look > at that and the reasoning around that conversion. I took inspiration from Tero Kristo's work on the clock subsystem for TI platforms. I think he did a great job in both device tree definition and driver implementation. IMHO, this way the drivers are more flexible and the code can be more easily re-used on more platforms. Thanks and regards, Dario
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.
Hi On Wed, Jan 25, 2023 at 10:11 PM Stephen Boyd <sboyd@kernel.org> 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 - reduce the copy and paste code across the drivers - avoid code duplication Is the binding a way to solve this problem? If you don't want one node per clk style bindings, did you still think that the way to go is totally wrong? Michael
Quoting Michael Nazzareno Trimarchi (2023-01-26 02:49:54) > Hi > > On Wed, Jan 25, 2023 at 10:11 PM Stephen Boyd <sboyd@kernel.org> 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. > - 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 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. 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. 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. > > 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.
Hi On Fri, Feb 10, 2023 at 11:49 PM Stephen Boyd <sboyd@kernel.org> wrote: > > Quoting Michael Nazzareno Trimarchi (2023-01-26 02:49:54) > > Hi > > > > On Wed, Jan 25, 2023 at 10:11 PM Stephen Boyd <sboyd@kernel.org> 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.