Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp387433imm; Thu, 31 May 2018 02:12:54 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLcY8M8FT2vyM046aeZ7KZ328ZQnKkkTP2Vysh3eX3/TtYvyAomcecgqt8ddLm0WduuuzUJ X-Received: by 2002:a62:428f:: with SMTP id h15-v6mr6069758pfd.156.1527757974347; Thu, 31 May 2018 02:12:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527757974; cv=none; d=google.com; s=arc-20160816; b=lVN8iN5DOf2lIQGIEYs/8OGdM54nDutG75mM6Zs74sp30vCBJZ1uPYe9Z7/5QQ8PrS PzDsY2XKSWbb4aEAzNRcCryNuya0P/Rj5slZHvLxtFVdnfrUkfCdxh9YuKLnTNrHoNNC u5CkaWuSm3heTVCEv4L2ZdDAh44jeSMtO/TkwBDxq8AvnfDh44y/hSxd+KbJGcq0H3WS SjIpy2wxnpVG0X1tDQz5vWzyFR/rIiuJk+kHG+N4Cm/EsvKz7e+IpfnuRgBOaWIDkHD2 vjO8X1XV61icqz+LjC9/OyRCU0s7uKQg3E0e/ZUEe6RheXYs7TDeVNwxL7eUIeSgV/DX U2Jg== 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:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=ghwYuUwyVjCRqRM8qyu8KEElJIkUQRYtj02pywRnB0c=; b=ZcjN5MomeFXe7QyZzmJD0sd8waH6kWsz0G7FKwkc1yxdA6OGosgnTxe/sJIOCvOMhv uLRUUlusuV16HfslVafkBxDQ0FFWM4SPPrlzJ2RlAKYOg3RBjDyQu3p/XKJhFmtQxZUV hkZigphNcIgNywDs1K7/r7cOQNMvG9DH2Cno28ZeklQgkr2k4XyFttcW+/mSb44V0CQn RJ0RYbvZjD6XSWpo52zufdFKUHnTdNcUHlLXUgf0CeXRBnPR2kRZWNLDygaG1TyBIjOq q+P8SFBpyb6nZN7B68/6jCxOeCCEvuAIWTV0GasKuR25i2C25YubC1jJBQZK4ff7VAsl l1CQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Yj7h/E1V; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q4-v6si36103473plb.312.2018.05.31.02.12.40; Thu, 31 May 2018 02:12:54 -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=pass header.i=@gmail.com header.s=20161025 header.b=Yj7h/E1V; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754295AbeEaJLu (ORCPT + 99 others); Thu, 31 May 2018 05:11:50 -0400 Received: from mail-pg0-f68.google.com ([74.125.83.68]:38781 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754147AbeEaJLq (ORCPT ); Thu, 31 May 2018 05:11:46 -0400 Received: by mail-pg0-f68.google.com with SMTP id c9-v6so6618825pgf.5; Thu, 31 May 2018 02:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ghwYuUwyVjCRqRM8qyu8KEElJIkUQRYtj02pywRnB0c=; b=Yj7h/E1Vqztxpy+2JRgx1WuWvZtmHCqgx6xu9EtDrVL+dVfo+uwSz4dhaybnnupv9m ibDyDZCP2dLQKI3Z+OSOU7vyRHInYt/fZpl4OLOWiVRcw3gWqR2pyKYqQehPiaRDjjkO 4BTeekYJEcKVJfV/uWRAvs3eWR34pmqdYX5ESXSmoItrCtFEopwVoMMHFUCvUXdMYg01 KEg32diKinr5HtgF9BFhNMQEX9AL8g21HvQyL9sPPF25v9e1wQMDSRyY1kpzN5SP8J1w 3utec9nBN0zExa2egl5gLmgB4o/Ko1PhFLdf3DsJ7IVh3t3x8MYoAxibAj+I6dhlsSON 6dew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ghwYuUwyVjCRqRM8qyu8KEElJIkUQRYtj02pywRnB0c=; b=hSoeseEuqhnXT92m8T1vWa3fwkMceCihVhu9GLpjaMmWB6qjI+RTr0wtlEkIZ8G6mY vH5okU6u2ppVoYOm0aQ6RNq1I1Wlir4+D9+1yfQ2HmRPH+vPpyEvrVuXeDLRcxVsizPs HONoKnMtnu+Gqf34mzYqFShDBvBMM3FXkF4rqsZQId/f+Q1EMgsawA2mAt0HymtlItDn vt5toU81Iypf4eegYiiVbeejZ5IehV7GWhOxPI79GRkDnwrJVI8TZEa3FpPLuV50EOOl aKcaonHv4tUeUQIbAhF6s8At+krFsy9gJXhhYSZSrEWxC9r9DkJn7drl/3Z1sfVFD568 XuUg== X-Gm-Message-State: ALKqPwd2sDoIuesxDTfyyqHR1KbRqxrnuH/xgYLzeKc+Ch2JOBN0u31L 7UHalTkZ3CHwadpbakJ6Xu/bk7ANVNJWrqCp6kg= X-Received: by 2002:a62:2043:: with SMTP id g64-v6mr6085673pfg.12.1527757905760; Thu, 31 May 2018 02:11:45 -0700 (PDT) MIME-Version: 1.0 References: <1527154169-32380-1-git-send-email-michel.pollet@bp.renesas.com> <1527154169-32380-2-git-send-email-michel.pollet@bp.renesas.com> In-Reply-To: From: M P Date: Thu, 31 May 2018 10:11:34 +0100 Message-ID: Subject: Re: [PATCH v7 1/5] dt-bindings: Add the r9a06g032-sysctrl.h file To: Geert Uytterhoeven Cc: michel.pollet@bp.renesas.com, linux-renesas-soc@vger.kernel.org, Simon Horman , Phil Edworthy , buserror+upstream@gmail.com, Michael Turquette , sboyd@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, geert+renesas@glider.be, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org 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 On Fri, 25 May 2018 at 11:31, Geert Uytterhoeven wrote: > Hi Michel, Hi Geert, > On Thu, May 24, 2018 at 11:28 AM, Michel Pollet > wrote: > > This adds the constants necessary to use the renesas,r9a06g032-sysctrl node. > > > > Signed-off-by: Michel Pollet > Thanks for your patch! > > --- /dev/null > > +++ b/include/dt-bindings/clock/r9a06g032-sysctrl.h > You can still call this file r9a06g032-clocks.h, if you want, as it > contains clock definitions only. Well, having renamed the node, I thought it made sense to keep the naming consistent. Any further #define could be added to here instead of having to add another file... > > @@ -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 documentation 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 next 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 linux conventions. * Other internal reasons I can't document here Also, the value here are made up anyway -- so I've decided to sort them to make sure any clock that has a parent is numbered *after* the parent... > 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 woul= d > 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 applicable. This is all done automatically BTW -- a script takes the original clocking spreadsheet, and converts it into a table, correcting 'human input' as it goes along. > 3. It looks like the module clocks can be referred to by register offs= et > 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 header > 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. As mentioned, it's arbitrary, with 'root' clocks numbered lowered than sub-clocks. Thank you! Michel