Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp402685imm; Thu, 31 May 2018 02:34:39 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJNCrWZ1mYCHm1SrIm3eGLKnwSR7qEq6kNJVNal6mFr0G+2DnB3XLNzT7obYw4xQ30q47jR X-Received: by 2002:a62:1358:: with SMTP id b85-v6mr1211982pfj.238.1527759279019; Thu, 31 May 2018 02:34:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527759278; cv=none; d=google.com; s=arc-20160816; b=IyaKZJCLIgtnRdvvAYrLGHonRkkdwpmKZFndbxDoLboQlErJG0K1asPF9o2/nHzBW2 1PI7GhfMOlhQX916bEKpdGrFJFz2DFVEOhfDVmGdHp5Sf+y0ir3Gaz68GbYVfTAauGMJ 1yLdFk3fTCFKuojNpyIs+J6p4UMe8r1/LU6El1+HfE1DO5Ko+chMgxW8ykKKcfg+Bfmx +q6jzFVqxREipTlVrAcmQ4Zk9yzM4fdBGYIxSOz51nAgQEEchsnxeNn4Ue7HDn0FdtAo Tqu1pIbkieJVQ7fF2ynb7XFF1GmTw8GHmL56BU3LeSNa3h6YYSSD1FW6jM4bLOR7Fxo7 dllA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=+0sYt0SPsCFL4fbfVxcsi4uBPraSslGAD/++TodKXeY=; b=SaS3Xcg+PGOjGnP8962Cf0HL4J1IXKYozX9Lr6+gZtRFUfDjpFl915z+WC9p4O6bWo P8cedz69mM+i0tOOkQEaCYO/ZMpOxmvUfcNLpyMl4+FWcekwCvJ9rt2OABy7eU/REATd bclwEEGyVcLTlFoEdVsEyzDSBdgzxd+eA3sHC/dFfIroIN7tsbyAL+RFfMWCa6baFFuw glsUSvH80CAXk+0AJ3lns8ZXS7QLRrR7VzFn/eJ1TJ/udPg1xoua2eDLaSTjSsOiTYrI FmmZWQJix0m/8LNQGxxfw77GeYcDUr0aukkH5svAbHj7IKLSvKXYNZpAxfTXO30QLM8G 8U2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=LltwCBcS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y124-v6si8304414pgb.61.2018.05.31.02.34.24; Thu, 31 May 2018 02:34:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=LltwCBcS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754258AbeEaJc6 (ORCPT + 99 others); Thu, 31 May 2018 05:32:58 -0400 Received: from mail-ua0-f194.google.com ([209.85.217.194]:37432 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754138AbeEaJcy (ORCPT ); Thu, 31 May 2018 05:32:54 -0400 Received: by mail-ua0-f194.google.com with SMTP id i3-v6so14575835uad.4; Thu, 31 May 2018 02:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=+0sYt0SPsCFL4fbfVxcsi4uBPraSslGAD/++TodKXeY=; b=LltwCBcSFXyKLM/bWvloibBMEYz+lg0snsn7FlM3tdL4shYEUR5NrSrWap3jO3pXtV 8S3lv9zRao3B62v5gKlZ3HS3vw+KQGoPbzGaOIlItb9R4eU3Y08OgUI4Wk+us+dW2KuO yUbyKdpk7hn/ClchduI9HB41LxvK6np29Bq+nzn9/ZMZjGaii8Evpv05zWBFY3Vfo2JO iz1RozNYYI5xDIBNPimYSEfex5BQKVaN8zCGRgJoGy+/O0Hxq/tStHAoZAk30HYGhsP+ OGexRDeuputD53zGA6f2PeeeyPoBZ4ZvP8U2SYf/LUfEQ1hR5xd3SCmkJ+coSw1WA0ho /Wbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=+0sYt0SPsCFL4fbfVxcsi4uBPraSslGAD/++TodKXeY=; b=HLOq7kpwVBZWFc/X8sZmsOksqb2EgLIAjhAuB4cAPnZ0gA8AeKiCmnm7wT4g9hOdh1 IZJb2rL3r4uR08vZlL4PBK0PmgD+Rnfbst0V4SYzkEp2v2xeaWZz1NJwg8gonb2T9Ijw yoN6ulVjGayPbYh1ObxMDuDnWWeLD5/nKFMcalwXXCzFY5voAiTl/4yfnW53qiXJ4m09 Mu4iyZVfkPi80lh3Mi75f+Ll56iIf8KbPxSPVK8JuvYiqMw5FcSZKfNQ7StRMQkpN4CZ WaRs+oCUUNa0O9g8hPV9bAP0TyAqC9p8D9qvK5xU4ZcGOiApx9OkXiPt6/i0ByZ/RV8+ Iobg== X-Gm-Message-State: ALKqPwfoEGT+FKWbaAQ+xZbz4mJVoL9iR/H7w7KLIZklcKvk97dOEF11 gtFyBoP453CMYGLoG8Wzh/Pr2SkSrG0RRg9uVe39EZ97 X-Received: by 2002:a9f:2304:: with SMTP id 4-v6mr4114078uae.12.1527759173571; Thu, 31 May 2018 02:32:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:7a0a:0:0:0:0:0 with HTTP; Thu, 31 May 2018 02:32:52 -0700 (PDT) In-Reply-To: References: <1527154169-32380-1-git-send-email-michel.pollet@bp.renesas.com> <1527154169-32380-2-git-send-email-michel.pollet@bp.renesas.com> From: Geert Uytterhoeven Date: Thu, 31 May 2018 11:32:52 +0200 X-Google-Sender-Auth: rWvqnmtGrQ0ySu-XmeAAEnejdA0 Message-ID: Subject: Re: [PATCH v7 1/5] dt-bindings: Add the r9a06g032-sysctrl.h file To: M P Cc: Michel Pollet , Linux-Renesas , Simon Horman , Phil Edworthy , Michel Pollet , Michael Turquette , Stephen Boyd , Rob Herring , Mark Rutland , Geert Uytterhoeven , linux-clk , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michel, On Thu, May 31, 2018 at 11:11 AM, M P wrote: > On Fri, 25 May 2018 at 11:31, Geert Uytterhoeven > wrote: >> On Thu, May 24, 2018 at 11:28 AM, Michel Pollet >> wrote: >> > This adds the constants necessary to use the renesas,r9a06g032-sysctrl > node. >> > @@ -0,0 +1,187 @@ >> > +/* SPDX-License-Identifier: GPL-2.0 */ >> > +/* >> > + * R9A06G032 sysctrl IDs >> > + * >> > + * Copyright (C) 2018 Renesas Electronics Europe Limited >> > + * >> > + * Michel Pollet , >> > + * Derived from zx-reboot.c >> > + */ >> > + >> > +#ifndef __DT_BINDINGS_R9A06G032_SYSCTRL_H__ >> > +#define __DT_BINDINGS_R9A06G032_SYSCTRL_H__ >> > + >> > +#define R9A06G032_CLKOUT 0 >> > +#define R9A06G032_CLK_PLL_USB 1 >> > +#define R9A06G032_CLK_48 1 /* AKA CLK_PLL_USB *= / >> > +#define R9A06G032_CLKOUT_D10 2 >> > +#define R9A06G032_CLKOUT_D16 3 >> > +#define R9A06G032_MSEBIS_CLK 3 /* AKA CLKOUT_D16 */ >> > +#define R9A06G032_MSEBIM_CLK 3 /* AKA CLKOUT_D16 */ >> > +#define R9A06G032_CLKOUT_D160 4 >> > +#define R9A06G032_CLKOUT_D1OR2 5 >> > +#define R9A06G032_CLK_DDRPHY_PLLCLK 5 /* AKA CLKOUT_D1OR2 = */ > >> [...] > >> I have 3 comments: > >> 1. I had expected this list to match (both name- and order-wise) > Appendix >> C ("Clock Tree Structure") in the RZ/N1[DSL] User=E2=80=99s Manual= : System >> Introduction, Multiplexing, Electrical and Mechanical Information. >> That would make it easier to review. > > Well, that document was made a *long* time after the internal documentati= on > we used to generate the clock lists. There are a few things we had to do: > > * Renumber peripherals. We decided a long time ago that u-boot and linux > would stick to zero based peripherals, and not one based numbers. It's ne= xt > to impossible to keep mixing number based across software base, so we use > UART0 while the hardware manual mentions UART1 -- It *is* documented > extensively with out SDK, and makes life using linux a lot easier. It's > across all our SDK, u-boot, webapps readmes, howtos etc. > > * Rename some peripherals. Plenty of peripherals names made little sense > and had zero consistency, in fact, many names were different depending on > the place they were used! -- "flashnand"+"nand_flash"+"FNAND" etc, > "QUADSPI"+"QSPI" etc etc so we also re-normalized the names to match linu= x > conventions. > > * Other internal reasons I can't document here > > Also, the value here are made up anyway -- so I've decided to sort them t= o > make sure any clock that has a parent is numbered *after* the parent... Well, all of that combines makes it very hard for us to review the list. >> 2. These definitions seems to be a mix of: >> 1. Internal core clocks, >> 2. Other core clocks, >> 3. Module clocks. > >> The internal clocks do not need to be referenced from DT, so I wou= ld >> not make them part of the DT bindings. > > Why? I'm told that "Bindings aren't for linux" -- why can't I imagine > 'something' needing them? Why would I decide NOT to include them, > as they are there? I 'factored' a few of them to the same number when Just general safety w.r.t. unchangeable DT definitions: anything that is not listed here cannot be declared wrong later. > applicable. You're 100% sure they're the same? > This is all done automatically BTW -- a script takes the original clockin= g > spreadsheet, and converts it into a table, correcting 'human input' as it > goes along. So the internal spreadsheet doesn't match the public documentation neither? >> 3. It looks like the module clocks can be referred to by register off= set >> and bit position, which is similar to how this is handled on R-Car >> SoCs. >> Perhaps you can just drop the definitions for these from the heade= r >> file, and refer to them by (combined) register offset and bit > position >> instead? >> Or am I missing something? >> I believe this can also be done for the module resets (later). > > If you look in the .c file, you'll see that most gate have not just one > register/bit pair associated with them -- there are several, spread > across registers.. Also, there are clocks in there with two gates, > or none. Given that, I've decided a separate numbering > made sense. OK, fair enough. Gr{oetje,eeting}s, Geert --=20 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= .org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds