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 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B00D6C38142 for ; Thu, 19 Jan 2023 10:18:02 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id F3ADB8564E; Thu, 19 Jan 2023 11:17:59 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="VjYQ0SiX"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7DE6185650; Thu, 19 Jan 2023 11:17:58 +0100 (CET) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 77F3885606 for ; Thu, 19 Jan 2023 11:17:55 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jbx6244@gmail.com Received: by mail-ed1-x533.google.com with SMTP id w14so2257147edi.5 for ; Thu, 19 Jan 2023 02:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KJofStQ2LH19c7LSZcaDNLdexi13u8PRRG52U9SfqnQ=; b=VjYQ0SiXl6H/NI+skRgkPFBHAJhbuFqlzNWV+8e3G7vCxVTFhfd7avLEeNFm64uTOW PuxxY5xGkVY49T7v3bmFQkO38+siEXJrP0bF/ZyHUx+L4OmEvY5V+mr3UX9xWEk4uahm 9yjzxgKcLJpjCMbSog8bQuGl3L9GKYr/s/cgbTHJrv15/7koUxzBaafbPqR+EcVO3aI7 W6SeNQtDbhqul6aJ9d6Yxm9j+9wCcl7t9XM+eWkoDrHD1/14Wr5PWgp9kevpY0ZX8yYY oc6EHWco9k8nsqKIasnMjGsaoNCHy7IMba+72WJyVWJaXPKnsKVd7ioWZCxAoCTGW5FN Y9WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KJofStQ2LH19c7LSZcaDNLdexi13u8PRRG52U9SfqnQ=; b=7i7MGGjeB3jJsBOV5SUC5sA764Mop8sUbXpLG9HoJoq6aZQcMNkLxTSRCXhVu9aVAY EY3nqK4B3iZY+qGiPxGGC9+ijsF/YRzB7ToS6jIbvYzWn1YAfr8LgXdtuDoKu9x1No9B Ig3mqIiydqyhilU9YHwA85y5KyxoY3bOk6Gf2AydKU6NL0/nYsLOGAcCpr0Y1uZIea+q HX9lRowOjwhVW0XCvd0pQvWc6Ur1tlv1pKPdIExumhHOcQBZ/Va+BcH2RyGSVMuOfczf 3qkgX5fDtQ+BXePWOHSBZdBi132uWbCq7LuSdmYN4CSXOmIhG05pxds8/mNqw3Ifh8BM udrA== X-Gm-Message-State: AFqh2kohqBSAToKGSrCR4g+KKjwHBUqR1R1OlQAIVyGWkj9ed7QMq62E sfzT4uf02a9QpfcpjDSBS9nyzjB/hXA= X-Google-Smtp-Source: AMrXdXtlqDeKT8TEE85pLq3IVAkS9TZ9t20x/iBNzToCdUP6BuNukID1Z3GL2lWg6gifuHijDGqqbA== X-Received: by 2002:a05:6402:44:b0:497:233d:3ef6 with SMTP id f4-20020a056402004400b00497233d3ef6mr10233475edu.17.1674123474907; Thu, 19 Jan 2023 02:17:54 -0800 (PST) Received: from [192.168.2.1] (81-204-249-205.fixed.kpn.net. [81.204.249.205]) by smtp.gmail.com with ESMTPSA id ew7-20020a056402538700b0049b58744f93sm8940739edb.81.2023.01.19.02.17.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Jan 2023 02:17:54 -0800 (PST) Message-ID: Date: Thu, 19 Jan 2023 11:17:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH] rockchip: derive GPIO bank from alias if available Content-Language: en-US To: John Keeping Cc: u-boot@lists.denx.de, Quentin Schulz , Simon Glass , Philipp Tomsich , Kever Yang References: <20230117181508.1582478-1-john@metanate.com> <98e06ac6-511a-28a7-c659-4cd91c064ad7@gmail.com> From: Johan Jonker In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean On 1/18/23 17:13, John Keeping wrote: > On Tue, Jan 17, 2023 at 08:52:22PM +0100, Johan Jonker wrote: >> >> >> On 1/17/23 19:15, John Keeping wrote: >>> Upstream device trees now use standard node names like "gpio@ff..." but >>> the rk_gpio driver expects a name like "gpio0@ff..." (note the index >>> before the @). >>> >>> This is not a change that can be made in a -u-boot.dtsi file, so >>> updating to the latest upstream device trees requires updating the >>> driver. >>> >>> Other GPIO drivers already use the sequence number to derive the bank. >>> This can be set explicitly using an alias in the device tree (which can >>> be added in a -u-boot.dtsi file) but Rockchip GPIO banks are defined in >>> order in the device tree anyway so when no aliases are supplied the >>> indexes should still be correct. >>> >>> Note that the bank name is only used by the `gpio` command or >>> potentially by board code via dm_gpio_lookup_name() and related >>> functions; it is not used by driver code which will lookup GPIOs from >>> the device tree by phandle. No Rockchip platforms make any use of >>> dm_gpio_lookup_name() or `gpio` in the boot scripts. >>> >>> Cc: Quentin Schulz >>> Cc: Johan Jonker >>> Signed-off-by: John Keeping >>> --- >>> drivers/gpio/rk_gpio.c | 6 ++---- >>> 1 file changed, 2 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/gpio/rk_gpio.c b/drivers/gpio/rk_gpio.c >>> index 68f30157a9..8568f10cd0 100644 >>> --- a/drivers/gpio/rk_gpio.c >>> +++ b/drivers/gpio/rk_gpio.c >>> @@ -142,7 +142,6 @@ static int rockchip_gpio_probe(struct udevice *dev) >>> { >>> struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev); >>> struct rockchip_gpio_priv *priv = dev_get_priv(dev); >>> - char *end; >>> int ret; >>> >>> priv->regs = dev_read_addr_ptr(dev); >>> @@ -151,9 +150,8 @@ static int rockchip_gpio_probe(struct udevice *dev) >>> return ret; >>> >>> uc_priv->gpio_count = ROCKCHIP_GPIOS_PER_BANK; >>> - end = strrchr(dev->name, '@'); >>> - priv->bank = trailing_strtoln(dev->name, end); >>> - priv->name[0] = 'A' + priv->bank; >> >>> + >>> + priv->name[0] = 'A' + dev_seq(dev); >> >> Some comments. Have a look if it's useful. >> === >> 1: >> Tested with rk3066a mk808 in only full u-boot. >> >> The gpio banks have a number gap. >> >> aliases { >> gpio0 = &gpio0; >> gpio1 = &gpio1; >> gpio2 = &gpio2; >> gpio3 = &gpio3; >> gpio4 = &gpio4; >> >> gpio6 = &gpio6; >> }; >> >> With aliases gpio6 is called G. >> Without gpio6 is called F. >> There's no name consistency for command scripts. > > True, but those scripts are going to be board specific and already > depend on board data. The name will be consistent per board. > >> === >> 2: >> For example: rk3288-evb-u-boot.dtsi >> >> What happens in tpl or spl with only gpio3 and gpio8 in dt-plat.c. > > Is the bank name used in tpl/spl at all? There's no script support > there and it could only be used in board code. > >> Or with SPL FDT blob: >> >> [v1,01/17] rockchip: spl: fix reloc gd and FDT blob pointer >> http://patchwork.ozlabs.org/project/uboot/patch/20220508150825.21711-2-jbx6244@gmail.com/ >> >> Not in use in mainline. Just saying there's more possible in SPL/TPL. >> === >> The use of aliases is more of something of an additional thing that we not always can count on that is there. > > Again this is board specific - if a board wants this scheme of GPIO > naming it can enable aliases and rely on that. > > I have been thinking of another option which is a bigger change to the > bank name - it doesn't have to be a letter, could we use the register > address as the bank name? So the GPIO would be something like > ff750000.1 (although I don't know how the naming scheme works, so having > a separator may not work). > > What do you think of that idea? > > > Regards, > John Hi, I might changed my mind. Nothing fixed yet. It all depends on the DT maintainers. See gpio.txt Maybe we should use the gpio-ranges property parsing to derive it's ID. Adding it to all gpio nodes like rk3588s.dtsi Is that useful for other Rockchip SoCs? &gpio1 { gpio-ranges = <&pinctrl 0 32 32>; }; Bank size is 32. ID = offset / 32 === See Linux gpio-rcar.c example: struct of_phandle_args args; ret = of_parse_phandle_with_fixed_args(np, "gpio-ranges", 3, 0, &args); //*npins = ret == 0 ? args.args[2] : RCAR_MAX_GPIO_PER_BANK; //if (*npins == 0 || *npins > RCAR_MAX_GPIO_PER_BANK) { // dev_warn(p->dev, "Invalid number of gpio lines %u, using %u\n", // *npins, RCAR_MAX_GPIO_PER_BANK); // *npins = RCAR_MAX_GPIO_PER_BANK; //} === Give me a bit time for patches. Is that property suitable? Let me know what you think of that. Johan === The gpio-ranges property described below represents this with a discrete set of ranges mapping pins from the pin controller local number space to pins in the GPIO controller local number space. The format is: <[pin controller phandle], [GPIO controller offset], [pin controller offset], [number of pins]>;