From patchwork Thu May 16 22:10:30 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lukasz Majewski X-Patchwork-Id: 1100758 X-Patchwork-Delegate: sbabic@denx.de Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.denx.de (client-ip=81.169.180.215; helo=lists.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=denx.de Received: from lists.denx.de (dione.denx.de [81.169.180.215]) by ozlabs.org (Postfix) with ESMTP id 454lxc5LjNz9s4Y for ; Fri, 17 May 2019 08:11:14 +1000 (AEST) Received: by lists.denx.de (Postfix, from userid 105) id 476A8C21E13; Thu, 16 May 2019 22:11:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=KHOP_BIG_TO_CC autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lists.denx.de (localhost [IPv6:::1]) by lists.denx.de (Postfix) with ESMTP id 1E44FC21C3F; Thu, 16 May 2019 22:11:04 +0000 (UTC) Received: by lists.denx.de (Postfix, from userid 105) id 99DF2C21C4A; Thu, 16 May 2019 22:11:02 +0000 (UTC) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by lists.denx.de (Postfix) with ESMTPS id 62AC0C21C3F for ; Thu, 16 May 2019 22:11:02 +0000 (UTC) Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 454lxL08Sxz1rbLn; Fri, 17 May 2019 00:11:02 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 454lxK6Kq1z1qqkh; Fri, 17 May 2019 00:11:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id hh-GeyvsftSj; Fri, 17 May 2019 00:11:00 +0200 (CEST) X-Auth-Info: 1BRnDNWrf+JYBU6kKyibvWXPv4MEodz8Z6Aez5aKppc= Received: from localhost.localdomain (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 17 May 2019 00:11:00 +0200 (CEST) From: Lukasz Majewski To: Stefano Babic , Fabio Estevam , Marek Vasut , Simon Glass , Tom Rini , u-boot@lists.denx.de, Jagan Teki , Peng Fan , Marcel Ziswiler , Adam Ford Date: Fri, 17 May 2019 00:10:30 +0200 Message-Id: <20190516221042.3583-2-lukma@denx.de> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20190516221042.3583-1-lukma@denx.de> References: <20190516221042.3583-1-lukma@denx.de> Subject: [U-Boot] [PATCH v4 01/13] clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX) X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.18 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" This patch describes the design decisions considerations and taken approach for porting in a separate documentation entry. Signed-off-by: Lukasz Majewski --- Changes in v4: - New patch Changes in v3: None doc/imx/clk/ccf.txt | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 doc/imx/clk/ccf.txt diff --git a/doc/imx/clk/ccf.txt b/doc/imx/clk/ccf.txt new file mode 100644 index 0000000000..cc167095f7 --- /dev/null +++ b/doc/imx/clk/ccf.txt @@ -0,0 +1,83 @@ +Introduction: +============= + +This documentation entry describes the Common Clock Framework [CCF] +port from Linux kernel (5.0-rc3) to U-Boot. + +This code is supposed to bring CCF to IMX based devices (imx6q, imx7 +imx8). Moreover, it also provides some common clock code, which would +allow easy porting of CCF Linux code to other platforms. + +Design decisions: +================= + +* U-boot's DM for clk differs from Linux CCF. The most notably difference + is the lack of support for hierarchical clocks and "clock as a manager + driver" (single clock DTS node acts as a starting point for all other + clocks). + +* The clk_get_rate() caches the previously read data if CLK_GET_RATE_NOCACHE + is not set (no need for recursive access). + +* On purpose the "manager" clk driver (clk-imx6q.c) is not using large + table to store pointers to clocks - e.g. clk[IMX6QDL_CLK_USDHC2_SEL] = .... + Instead we use udevice's linked list for the same class (UCLASS_CLK). + + Rationale: + ---------- + When porting the code as is from Linux, one would need ~1KiB of RAM to + store it. This is way too much if we do plan to use this driver in SPL. + +* The "central" structure of this patch series is struct udevice and its + driver_data field contains the struct clk pointer (to the originally created + one). + +* Up till now U-boot's driver model's CLK operates on udevice (main access to + clock is by udevice ops) + In the CCF the access to struct clk (comprising pointer to *dev) is + possible via dev_get_driver_data() + + Storing back pointer (from udevice to struct clk) as driver_data is a + convention for CCF. + +* I could use *private_alloc_size to allocate driver's 'private" + structures (dev->priv) for e.g. divider (struct clk_divider *divider) + for IMX6Q clock, but this would change the original structure of the CCF code. + + Question: + --------- + + Would it be better to use private_alloc_size (and dev->private) or stay with + driver_data to store struct clk pointer? + + The former requires some rewritting in CCF original code (to remove + (c)malloc, etc), but comply with u-boot DM. The latter allows re-using the + CCF code as is, but introduces some convention special for CCF (I'm not + sure thought if dev->priv is NOT another convention as well). + + This port uses the former approach with driver_data storing pointer to + struct clk. + +* I've added the clk_get_parent(), which reads parent's dev->driver_data to + provide parent's struct clk pointer. This seems the easiest way to get + child/parent relationship for struct clk in U-boot's udevice + based clocks. + +* For tests I had to "emulate" CCF code structure to test functionality of + clk_get_parent_rate() and clk_get_by_id(). Those functions will not work + properly with "standard" (i.e. non CCF) clock setup (with not set + dev->driver_data to struct clk). + +* Linux's CCF 'struct clk_core' corresponds to u-boot's udevice in 'struct clk'. + Clock IP block agnostic flags from 'struct clk_core' (e.g. NOCACHE) have been + moved from this struct one level up to 'struct clk'. + +To do: +------ + +* Use of OF_PLATDATA in the SPL setup for CCF - as it is now - the SPL grows + considerably and using CCF in boards with tiny resources (OCRAM) is + problematic. + +* On demand port other parts of CCF to U-Boot - as now only features _really_ + needed by DM/DTS converted drivers are used.