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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 10578C07545 for ; Tue, 24 Oct 2023 13:43:52 +0000 (UTC) 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xAI/LLdQwK93auusihvgefm6zRf9Vb2ZWqyT/vPS938=; b=gh3c/qWpxZnKGt 2vsVoRlivco/WbBPcrfSXtHmrgyIoSYYP6JOP31LIhfHTlsdhP0r9RHGNd1roz88ynUjUBr3E8o6O edNuntDSWHFcf1+gLvLXxKaTZLc+yS7UobE4cVVY243VfbruHhALQ2pLZ5vyTj9S6rCeeyGrxP4o8 5i4kRHUmizfZpQ/CotGba0qlXRhezeoYNHVyjFrFnoBv+VHMo62O3HERdItVlwpOwYZ2gI0fezR6K ib5I6Q0vHkzr14v4AK4MZXQX2+TAetIzWvd2SGpOZ6cKxO4q3KZrb+T8hqaqR5D92TrwWLy9P0bL3 QdeQo0euIIcqU5ClO/xw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qvHgj-009yh6-2g; Tue, 24 Oct 2023 13:43:17 +0000 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qvHgg-009yeq-2Y for linux-arm-kernel@lists.infradead.org; Tue, 24 Oct 2023 13:43:16 +0000 Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1ca85ff26afso8521685ad.1 for ; Tue, 24 Oct 2023 06:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1698154983; x=1698759783; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=llE/A+xwdvnmuUTq+C1r2sdJnt3pwBP1QiuNoEB548A=; b=abd7bz21Dd0P9J/ob6UxHEQCPMcSw2XR9+rg3x3LSw6r26WLRQpuEiLTS72yG8uAdP knx8LmOYyZknT+UM+LPUgRsH67AmDOWGcG5u/zi/qNGRH+ma1kRhWVxJkjs+8axvJhMz CV8gPrmJ4HPMHnzjABo4k+0cRLyDMmedxGCCedjOOw/ZGFOx0P+eWVlfSf7of8YsflsD /s3l3RwtiKb1/e4f+Jcge2IIMSwmcnCZOaGEWueGnkZXFIuboVx3CSrtnLer+XNkdtC4 RD+pELB/i3a0V3u86ScKmZ34s9AJylLLX1w0aR+SPluKw7Dyd/hU/7nVDHXmZWfi81pZ iiJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698154983; x=1698759783; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=llE/A+xwdvnmuUTq+C1r2sdJnt3pwBP1QiuNoEB548A=; b=UP915e96M5DVFjGZGlRIqyv1/Q3xVDPxeZ/XM1dqk+XeYpgJKg6+g8Ew7+DzCiWBOC xCEFn6ofHw/cqmCbsAiR+L9sDSV3OcmtwpvR310vmT4suPMP+IPtJtdHUhAMkEEXlwZM WHlEsnROkgg4n54fxhDWxWEYcP2axG0h5/0BxvIR05FtNMLSVdQkkcvOzR+cn1uO1WI7 1nA4DhK8v63fdUe3CCuLolQhIBwIBvvLoiHM341jbaA7zTwbq8pT+YeF2E7HLIHj5KIV anW/GSEe5kvI0hTW/1vuA4wSdE4967gB6S3Y0MLtivD4iYrPOEtz6lBPFMZxLqbVjsFF HD7w== X-Gm-Message-State: AOJu0YyxtTZajRdbTiDBsjTaUOV7qryfnXJvAD01glpVkquugTYg3ayv R+zL4as8EVRNx/wIOtK6X5rfJw== X-Google-Smtp-Source: AGHT+IGO3UGtt2ntifIx9N2oGOGvNFeTOoA1Q+nxYUjFjDT1CwynHW+luQG8rzi0DgBIyG+IUHTKdg== X-Received: by 2002:a17:903:6c7:b0:1ca:85b4:b962 with SMTP id kj7-20020a17090306c700b001ca85b4b962mr11793079plb.4.1698154982724; Tue, 24 Oct 2023 06:43:02 -0700 (PDT) Received: from octopus ([2400:4050:c3e1:100:7c15:610f:1205:f10c]) by smtp.gmail.com with ESMTPSA id q12-20020a170902dacc00b001c71ec1866fsm7416507plx.258.2023.10.24.06.42.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Oct 2023 06:43:02 -0700 (PDT) Date: Tue, 24 Oct 2023 22:42:57 +0900 From: AKASHI Takahiro To: Linus Walleij Cc: Rob Herring , sudeep.holla@arm.com, cristian.marussi@arm.com, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, Oleksii_Moisieiev@epam.com, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org Subject: Re: [RFC v2 5/5] dt-bindings: gpio: Add bindings for pinctrl based generic gpio driver Message-ID: Mail-Followup-To: AKASHI Takahiro , Linus Walleij , Rob Herring , sudeep.holla@arm.com, cristian.marussi@arm.com, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, Oleksii_Moisieiev@epam.com, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org References: <20231006132346.GA3426353-robh@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231024_064314_828373_129F3BE6 X-CRM114-Status: GOOD ( 39.68 ) 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 Tue, Oct 24, 2023 at 03:12:51PM +0200, Linus Walleij wrote: > On Tue, Oct 24, 2023 at 1:10???PM AKASHI Takahiro > wrote: > > > As far as I understand, there is only one way for SCMI gpio driver > > to know which pins are actually GPIO pins; Calling PINCNTRL_CONFIG_GET > > command with "Input-mode" or "Output-mode" configuration type > > against *every* pin-controller's pins. > > (Here I assume that the command would fail with INVALID_PARAMETERS or > > NOT_SUPPORTED if configuring the given pin as a GPIO input or output > > is not possible. But the specification seems to be a bit ambiguous.) > > As I also wrote in the reply to Christian, I expect the SCMI firmware > to consider GPIO a function on the pins, and either individual pins > (groups with just one pin in it) or entire groups of pins can be switched > to perform the "gpio function". ("gpio function" is akin to "i2c function" > or "HDMI function" etc.) First of all, there is no pre-defined naming convention either for pins, groups or functions. SCMI firmware can give them any names. Secondly, What you said in the above is already implemented in my RFC patch. Please remember the example that I gave: > gpio-ranges = <&scmi_pinctrl 6 0 0>; > gpio-ranges-group-names = "pinmux_gpio"; > > means that SCMI *group*, "pinmux_gpio", are mapped to this driver's > gpio range which starts with 5. If "pinmux_gpio" indicates SCMI *pin* > range [20..24], > > baa-gpios = <&gpio0 7>; > will refer to gpio pin#7 that is actually SCMI's 22 (=20 + (7-5)). Given the fact there is no naming convention, we need to explicitly specify an associated group name in "gpio-ranges-group-names" in any way. What my driver doesn't care for now is the case where a group of GPIO pins are multiplexed with other functions (UART, I2C or whatever else). In this case, we need to configure "pinconf" setup prior to using those pins as GPIO anyway. Simply, it is out of scope of my driver. (We can still use existing generic GPIO interfaces to operate them once set up, though.) After all, I still believe we need "gpio-ranges" property in most of all use cases (The only exception is, as I mentioned, to unconditionally map all pinctrl's pins to GPIO (if possible) when SCMI firmware provides only GPIO function for all pins. I think it is a simple and yet likely use case. Thanks, -Takahiro Akashi > > If the SCMI protocol considers GPIO usage to be something else > than a function of a pin, that is going to be a problem. Then the SCMI > protocol need some other way of determining that the pin is in > GPIO mode, and perhaps something would need to be added to > the protocol for that. > > The reason is that in practice a lot of hardware has to decouple > the pin from any internal function in order to use it as GPIO, and > connect it to the GPIO block that can drive the line high and low. > And we don't select that as a function, how is the firmware going > to know that it needs to do this? Implicitly from the call requesting > the line to be output perhaps. But if the firmware can be altered > to do that, the firmware can just as well be altered to present > GPIO as a proper function. > > Using a function makes most sense, because the board firmware > knows which pins are GPIO lines and what they are used for > (such as a LED or camera flash) and at boot certainly put them > into GPIO function and drive them high/low or set them as > input (high impedance). > > > It means that, if SCMI firmware has 100 pinctrl pins, the driver needs > > to call the command 200 times in order to get the answer. > > I think we should only need to check which function each pin > has and those that are in the GPIO function we put into the ranges. > > Yours, > Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel