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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 D035DC47084 for ; Tue, 25 May 2021 17:42:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B4B33611BE for ; Tue, 25 May 2021 17:42:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231924AbhEYRnb (ORCPT ); Tue, 25 May 2021 13:43:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:60904 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229976AbhEYRn3 (ORCPT ); Tue, 25 May 2021 13:43:29 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id F1E5161400; Tue, 25 May 2021 17:41:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621964519; bh=dOArAgu7ZC4cRYJFEGVi56ncg4H0XnoVUko1P1dIZn8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kAdF+LoXT11CuF1cPHOzYW1U0M8ChNl0RIvW5F5tmBSOJ/0Zz8FrZQSY6J4Q3diHR hgaUMXW5ejvQia/hozy3hbbyrkdpjOfs3heLX61ZG8H3VgKM4ZUWsPaqrxgsivkbpC 6e6Or3oQ7/Zou9F6iMQLY2jf0rhRSOXI5O305K8jE+mEtE3w8/MOJ0tcPAzqD8ChRS D6vMfBOwJbwv4fLGvUUg3EaCwLf7WZYHYzWIw4Ng8kA/DlBVwEh7FzaB54gSSPIqUE PjOAwu+HvnsXgIcT+ihHqaCnXtTsekgnFWoNtoJKV7+QtNtOg8wDOmj+yIKibJkCMl xsWK3rPRNcNhQ== Received: by mail-ed1-f44.google.com with SMTP id r11so37180912edt.13; Tue, 25 May 2021 10:41:58 -0700 (PDT) X-Gm-Message-State: AOAM531lzpVPgtm1hl6Hmo9i2Ly9YuwuwEYWX6lI8R/QW2XwbF1duUOz rEuURmWQRXGB4a/lga33oCW4IOULXgx4zstBAw== X-Google-Smtp-Source: ABdhPJzLJeb1QNBqzEiRLC8bN1RXJUTLRhZ4rPY1kCOuA7jctny5RqRboDeLgsBZKUAq1VQNAVUj3UzKlSCwkNqwaVg= X-Received: by 2002:a05:6402:c7:: with SMTP id i7mr33618826edu.194.1621964517456; Tue, 25 May 2021 10:41:57 -0700 (PDT) MIME-Version: 1.0 References: <20210524182745.22923-1-sven@svenpeter.dev> In-Reply-To: <20210524182745.22923-1-sven@svenpeter.dev> From: Rob Herring Date: Tue, 25 May 2021 12:41:45 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] Apple M1 clock gate driver To: Sven Peter Cc: devicetree@vger.kernel.org, linux-clk , linux-arm-kernel , "linux-kernel@vger.kernel.org" , Hector Martin , Michael Turquette , Stephen Boyd , Mark Kettenis , Arnd Bergmann Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 24, 2021 at 1:28 PM Sven Peter wrote: > > > Hi, > > This series adds support for the clock gates present in Apple's SoCs such as > the M1. > > These SoCs have various clock gates for their peripherals usually located in > one or two MMIO regions. Each clock gate is a single 32 bit register which > contains bits for the requested and the actual mode. The mode is represented by > four bits. We however only care about "everything enabled" (0b1111) and > "everything disabled" (0b000) for now. The other modes are probably different > low-power states which don't even seem to be used by MacOS. The actual power > management is located in a different region (and probably handled by a separate > processor on the M1). > > Additionally, these clocks have a topology that is usually specified in Apple's > Device Tree. As far as I can tell most Linux drivers seem to encode this topology > directly in the source code though. Despite this, we would still like to encode > the topology in the device tree itself: We only define leaf clocks primarily. There's some exceptions such as if PLLs are a separate h/w block. The reason for this is because typical SoCs have 100s of just leaf clocks. If we tried to model everything, it would never be complete nor correct. Actually, we did try that at first. > Apple seems to only change HW blocks when they have a very good reason and even > then they seem to keep the changes minimal. This specific clock gate MMIO block > has already been used in the Apple A7 released in 2013. The only differences > since then are the available clocks (which can be identified by a simple offset) > and their topology. Clock gates are easy. What about muxes, dividers, etc.? > It's likely that Apple will still use this block in future SoCs as well. By > encoding the clock gate topology inside the device tree as well we can use a > single driver and only need updates to the device tree once they are released. > This might allow end users to already run their favorite distribution by just > updating the bootloader with a new device tree instead of having to wait until > the new topology is integrated into their distro kernel. > > Additionally, the driver itself can be kept very simple and not much code needs > to be duplicated and then updated for each new SoC between various consumers of > these device tree nodes (Linux, u-boot, and OpenBSD for now). > > > This series therefore creates a single device tree node for each clock gate. > This unfortunately maps a whole page out of which only a single register will > be used for each node. > > The other alternative I considered was to create a syscon/simple-mfd node > and have the clock nodes as children. The gates would then use a regmap which > would only require a single entry in the pagetable for all clocks. I decided > against this option since the clock gate MMIO region actually isn't a > multi-function device. I would do a single node per mmio region with the register offset (or offset / 4) being the clock id. This can still support new SoCs easily if you have a fallback compatible. If you want/need to get all the clocks, just walk the DT 'clocks' properties and extract all the IDs. Rob 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=-4.4 required=3.0 tests=BAYES_00,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 AAEC5C2B9F8 for ; Tue, 25 May 2021 17:55:27 +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 5CADA613F1 for ; Tue, 25 May 2021 17:55:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5CADA613F1 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+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.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=R8qncEiKozMF9poztJJCHe1wKvig5CPXVx6dC/7r+4o=; b=2Uj2IMr4dDj9gk T9BpN912b9RjZRWZb50fOorATAitctAwz9PNdkkAXruXCCWlwg/mLY6Umus2Z+feQEVByjQOX84Zj 4aD67jCt/Do2qTKZf0qzCNxz93yQCctMJBXiP7MMqredN8xXqjoNpJICIR1Y+X2VcY8S1m0xep9kq fgZYmU1FBISkxryh6GjW5t4OHvI5ewum1mkG5UoyeSiudWfeaVs67gT4sLz6/jMtg8BzRbXc/e1Xw +pgpL0MGnSvOCpyd3gUnuQ9FthTQWXATG4EonR/Fc9prAiIVF6lrztdSfonSJ9YtbWTyDpNr5u842 RedcA0M5uq3ET6BMR87w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1llbF6-0073oc-HB; Tue, 25 May 2021 17:53:26 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1llb43-006yUD-TM for linux-arm-kernel@lists.infradead.org; Tue, 25 May 2021 17:42:01 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id E5F8B61378 for ; Tue, 25 May 2021 17:41:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621964518; bh=dOArAgu7ZC4cRYJFEGVi56ncg4H0XnoVUko1P1dIZn8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dU0VtZXDDz3GLfGbDecsdbkOTKBIJp826j7E4fP5b000DWfwBUFAcWD5s3SVMUzDN JIidzRG2ktUnoS7+wNITGW1M0gnT9O8TLqbzm0AC5V+wmdIr5phzgiiFQx/rYtCnEs T7eZw9DATDRxfJuGpE3E3lFnF5sprKPzXe/IWTd2SgxwXbKSe3cPbrJII7lRoYUvaD HkBSDb2VJP2x+8BtpV9E/DCSAV1mRxcmNOrHfHgjjzFmTixiPBKKpV0HJJ2GZP5Cms kXnU6mL973Z+XR/PWyQ5qwt64Np2ZLEzMGU3EBhYq29zdCmOQpveTtglfjJMTMGTdA bzB74qqQR/Tpg== Received: by mail-ed1-f49.google.com with SMTP id t15so37268220edr.11 for ; Tue, 25 May 2021 10:41:58 -0700 (PDT) X-Gm-Message-State: AOAM531zRKexJiJBQ3M6CvWrpyIi02pAXIMGvzZ0SZdCgbDGV44abiG2 iw2Vjzg7VOCu3jZrYqQw/VTRXSSz8pRIg2/IGw== X-Google-Smtp-Source: ABdhPJzLJeb1QNBqzEiRLC8bN1RXJUTLRhZ4rPY1kCOuA7jctny5RqRboDeLgsBZKUAq1VQNAVUj3UzKlSCwkNqwaVg= X-Received: by 2002:a05:6402:c7:: with SMTP id i7mr33618826edu.194.1621964517456; Tue, 25 May 2021 10:41:57 -0700 (PDT) MIME-Version: 1.0 References: <20210524182745.22923-1-sven@svenpeter.dev> In-Reply-To: <20210524182745.22923-1-sven@svenpeter.dev> From: Rob Herring Date: Tue, 25 May 2021 12:41:45 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] Apple M1 clock gate driver To: Sven Peter Cc: devicetree@vger.kernel.org, linux-clk , linux-arm-kernel , "linux-kernel@vger.kernel.org" , Hector Martin , Michael Turquette , Stephen Boyd , Mark Kettenis , Arnd Bergmann X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210525_104200_038122_CF5C71DB X-CRM114-Status: GOOD ( 35.82 ) 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 On Mon, May 24, 2021 at 1:28 PM Sven Peter wrote: > > > Hi, > > This series adds support for the clock gates present in Apple's SoCs such as > the M1. > > These SoCs have various clock gates for their peripherals usually located in > one or two MMIO regions. Each clock gate is a single 32 bit register which > contains bits for the requested and the actual mode. The mode is represented by > four bits. We however only care about "everything enabled" (0b1111) and > "everything disabled" (0b000) for now. The other modes are probably different > low-power states which don't even seem to be used by MacOS. The actual power > management is located in a different region (and probably handled by a separate > processor on the M1). > > Additionally, these clocks have a topology that is usually specified in Apple's > Device Tree. As far as I can tell most Linux drivers seem to encode this topology > directly in the source code though. Despite this, we would still like to encode > the topology in the device tree itself: We only define leaf clocks primarily. There's some exceptions such as if PLLs are a separate h/w block. The reason for this is because typical SoCs have 100s of just leaf clocks. If we tried to model everything, it would never be complete nor correct. Actually, we did try that at first. > Apple seems to only change HW blocks when they have a very good reason and even > then they seem to keep the changes minimal. This specific clock gate MMIO block > has already been used in the Apple A7 released in 2013. The only differences > since then are the available clocks (which can be identified by a simple offset) > and their topology. Clock gates are easy. What about muxes, dividers, etc.? > It's likely that Apple will still use this block in future SoCs as well. By > encoding the clock gate topology inside the device tree as well we can use a > single driver and only need updates to the device tree once they are released. > This might allow end users to already run their favorite distribution by just > updating the bootloader with a new device tree instead of having to wait until > the new topology is integrated into their distro kernel. > > Additionally, the driver itself can be kept very simple and not much code needs > to be duplicated and then updated for each new SoC between various consumers of > these device tree nodes (Linux, u-boot, and OpenBSD for now). > > > This series therefore creates a single device tree node for each clock gate. > This unfortunately maps a whole page out of which only a single register will > be used for each node. > > The other alternative I considered was to create a syscon/simple-mfd node > and have the clock nodes as children. The gates would then use a regmap which > would only require a single entry in the pagetable for all clocks. I decided > against this option since the clock gate MMIO region actually isn't a > multi-function device. I would do a single node per mmio region with the register offset (or offset / 4) being the clock id. This can still support new SoCs easily if you have a fallback compatible. If you want/need to get all the clocks, just walk the DT 'clocks' properties and extract all the IDs. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel