Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp5020886ybi; Sat, 20 Jul 2019 11:05:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqwpz3qLUz8MiJUEJTdbSLWBj9lLipaYDsgtDp7xhZNBKUXLK/cva9EBqTTXsqTVcLtssh73 X-Received: by 2002:a17:902:f095:: with SMTP id go21mr65486979plb.58.1563645931020; Sat, 20 Jul 2019 11:05:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563645931; cv=none; d=google.com; s=arc-20160816; b=MPlDzO7qmwnd9skBPE6iruCLfd/Z1GUXxzFszZXD+wLEnWvX+CK2bwY6Iu581v+uu2 xUKZhsCiP7o7CSqA+hs6xpxZKiBVs3b+PonCoIhQpSL7R3eCxL1UygafAiB+8TH6jhXT epxURanOBmYX+gQ7SSAy/ij4Vtv1ocwozXHokJAyIP2NKya9ENesraD/NUylvubvaSAK qDIgBT7/n9O8XZ/fcYubzPXpjciVfBsx8gA6yyRWRlZS8UVZczWZPRmgLV7SCqFswHN2 ItkCC+/2K7BBWIIHk7ZYmkAnSTRQDIUWTuEaUhIShUshkz3Vx3oEv/TYJyL+z4XcMUC/ yYug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Z0jjqiEWK8ZwPUy1E/hBEFEfeUX6fZKXUCvS400AT+E=; b=Y5bMpuOrCltX+wSZ56YfXNAwudIOsIaCzF1/G3+1hyY863Pj+8jDa7NJ0UPl0Qf52Q myYMy+YbYBrFGcAY7BwrhCXNJEKfqUUVZNL3wKr1I3geDeYDJG/QYEzTwGYYEJvksDAg WiR786UiMHRWboW+lDM0vyg1ifkzgGqDg1O2tsLJushlYQN7ooK5iwugj5XLxJBJasqK FmU7rCaQaCyCVxbjeBup+1Ut/r6X5nBKyTqbd59ShJqrFOEJCdl3ZTGuu3xNmRZU9AWv t1MENM2hmnpAUc9c1FycNZvPnKLp6MRxp2aGhaSIrg6mXamqboox3WCyj0eCcwPhK3RK Fwqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=yPSEvpAh; 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=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q4si3560418pfh.12.2019.07.20.11.05.15; Sat, 20 Jul 2019 11:05:31 -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=@linaro.org header.s=google header.b=yPSEvpAh; 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=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726905AbfGTINL (ORCPT + 99 others); Sat, 20 Jul 2019 04:13:11 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:38484 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726893AbfGTINK (ORCPT ); Sat, 20 Jul 2019 04:13:10 -0400 Received: by mail-lj1-f195.google.com with SMTP id r9so32875667ljg.5 for ; Sat, 20 Jul 2019 01:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z0jjqiEWK8ZwPUy1E/hBEFEfeUX6fZKXUCvS400AT+E=; b=yPSEvpAhtbj/j09qHG2JWZfrDA4ejU9evwOJais+pJ0lGCPO05Gns70r4+pQNpZ4xK lDKoKVvkmiGIDLP+l/FkDXc1fKJsf9Uk4CdBZeUDu+IsFD4fs/jH9Vh+YJrDGixb3HJ3 Ue7R1TwHlXHvmgyfmDJqycCgkmTCbjCHYxmEh2EdRFsmKmntYBYBfVUhRjzsgZeVPYb+ 8K4202ecZU1xhmPNMkuAY7dkNXe1ab5LPwhjlJnovA4AmK+Wz/yOz1qlHoDUXr4Yj0SC kiaxocC37eF3GwefxCq3OJiGqjz7iJVeDnWpJnKKiO4nhTokU6iSmnvj/ddVQoxSY787 XpcQ== 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; bh=Z0jjqiEWK8ZwPUy1E/hBEFEfeUX6fZKXUCvS400AT+E=; b=tL8XAyWIPwM9qfQGlSNOF2Khvk5rrSr5B3st/00MlIEyljSvE8UhVxRVgLHMlKiFn2 TU92u177Xy3Cav2yaN3Zpt7kZtaFZrCwbGmE2/R3ohVB8QKKEDZeOofiEQ2AgBfXsbAI El2ecKTXxAmq12k16lvSMg+s+omcQoYFrjSS53Y68NoqrHA8gcxvLbJNwiKNo5GdzaCj 4vmSXuXEIiil3z/YjMSDS5T7d5SjPW4BbcNuiSNpz259hEra8Fxyn9KPPl0rn8rQI7B4 KIjvDu7jL7foA5ypqlkrHDHXJ46odw02FsVoifg+c6aiuc5EzUrKE4axbYSh/9LyL3Kd AACw== X-Gm-Message-State: APjAAAV57qToIty+ojrT18jvH96+icclo2wG8v6vvye/K3J7+9xOSZkS lELc47gsHHS2YomAMEef4hFds6aWvypXK95RHalPYA== X-Received: by 2002:a2e:2c14:: with SMTP id s20mr12432277ljs.54.1563610388042; Sat, 20 Jul 2019 01:13:08 -0700 (PDT) MIME-Version: 1.0 References: <1563564291-9692-1-git-send-email-hongweiz@ami.com> <1563564291-9692-2-git-send-email-hongweiz@ami.com> In-Reply-To: <1563564291-9692-2-git-send-email-hongweiz@ami.com> From: Linus Walleij Date: Sat, 20 Jul 2019 10:12:56 +0200 Message-ID: Subject: Re: [v5 1/2] dt-bindings: gpio: aspeed: Add SGPIO support To: Hongwei Zhang Cc: Andrew Jeffery , "open list:GPIO SUBSYSTEM" , Joel Stanley , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-aspeed@lists.ozlabs.org, Bartosz Golaszewski , Rob Herring , Mark Rutland , "linux-kernel@vger.kernel.org" , Linux ARM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hongwei, after looking close at the driver and bindings I have this feeback: On Fri, Jul 19, 2019 at 9:25 PM Hongwei Zhang wrote: +- reg : Address and length of the register set for the device This 0x100 range may look simple but in the driver it looks like this: +static const struct aspeed_sgpio_bank aspeed_sgpio_banks[] = { + { + .val_regs = 0x0000, + .rdata_reg = 0x0070, + .irq_regs = 0x0004, + .names = { "A", "B", "C", "D" }, + }, + { + .val_regs = 0x001C, + .rdata_reg = 0x0074, + .irq_regs = 0x0020, + .names = { "E", "F", "G", "H" }, + }, + { + .val_regs = 0x0038, + .rdata_reg = 0x0078, + .irq_regs = 0x003C, + .names = { "I", "J" }, + }, +}; So first break this into up to 10 different instances with one device per bank instead. For each device: reg = <0x1e780200 4>, , <0x1e780270 ..>; reg-names = "val", "irq", "rdata"; This way you use the device tree features for locating the register offsets instead of hard-coding it into the driver, which will make the driver simpler. > +- ngpios : number of GPIO pins to serialise. > + (should be multiple of 8, up to 80 pins) This is wrong. This should be split into 10 different devices providing 8 GPIO lines each. The "ngpios" is not intended to subdivide banks, but for the case where you use say bits 0..11 of 32 bits in a register by setting ngpios to 12. I see that they use the same clock divider and the same interrupt, but this is better to partition into a separate clock divider driver and up to 10 instances of GPIO devices with 8 GPIOs each. I also see that they use the same interrupt. This is fine, in your driver just grab a shared IRQ and all the IRQ handlers will be traversed. This is a well known pattern for all operating systems. > +- clocks : A phandle to the APB clock for SGPM clock division > + > +- bus-frequency : SGPM CLK frequency I see that there is a common clock control register in offset 0x54. Split this out to a separate clock driver that provides a divided clock that all GPIO blocks can get, no matter if you use 1, 2 .. 10 of these blocks. The fact that these GPIO banks and the clock register is in the same memory range does not really matter. Split up the memory range in on reg = per GPIO chip and one reg for the clock. > + Example: > + sgpio: sgpio@1e780200 { > + #gpio-cells = <2>; > + compatible = "aspeed,ast2500-sgpio"; > + gpio-controller; > + interrupts = <40>; > + reg = <0x1e780200 0x0100>; > + clocks = <&syscon ASPEED_CLK_APB>; > + interrupt-controller; > + ngpios = <8>; > + bus-frequency = <12000000>; > + }; Splitting this up into a clock controller and 1-10 instances of sgpio will make things simpler, because it will closer reflect what the hardware people are doing: they have just created 10 instances of the same block, and added a clock divider. You can put the 1-10 instances and the clock divider inside a collected node "simple-bus" in the device tree: { compatible = "simple-bus"; sgpio0: sgpio { compatible = "aspeed,ast2500-sgpio"; reg = <0x1e780200 ...> ...; clk = <&sgpioclk>; }; sgpio1: sgpio { ... }; ... sgpioclk: clock { compatible = "aspeed,sgpio-clock"; reg = 0x1e780254 4>; }; }; This is a better fit with the actual hardware and will make it much easier to write drivers. Admittedly DT device partitioning of SoC devices is a grey area, but here I think the DT infrastructure helps you to break things down and make it easier, I am thinking in a divide-and-conquer way about it. Yours, Linus Walleij