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 2978AC7618E for ; Fri, 21 Apr 2023 11:43:59 +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=GBDBjcBU2y3CFPjQgiVAycgE9x68tXPyrhSQhES7PGM=; b=hThYBuNmc/kt0F HaZD5RFgMlpMCu2nZ0KLgBrNOj8gje3DBM7UcnkZQodHx+XAely951v32xc7hhO3J0obkiM9T1ipc 1auzngRzlD3q4HU9TU6mAisn1dGawKTiWuzGUQiHbevlhZFs5bqBvE+1uY3ChMOdmXkAjx3eF9kzu lctXfVYsxdazfI8ZakxlSzOCBLjRGx1CJmWVXa6yAp2UQ7BHxDTIko/TF69lWUipZIGDJvEEfz01r EB6DP0ol+MGL9c2bcbUfApMzPfJkzbArTBNaIabIBS5vPIgM5aSK61xt8DxdhRgJ86bhUQ17rsk7b EplY7oKC9jboowHpdGBg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pppAU-00Al6L-1O; Fri, 21 Apr 2023 11:43:10 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pppAS-00Al5i-0e for linux-arm-kernel@bombadil.infradead.org; Fri, 21 Apr 2023 11:43:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=kFgq5LRUZIFA532gL/AgX0WPJ1mKIVb9DKUT8I/fcv8=; b=BGWgmlQrwa2tNrAv/rKiPbNbQQ q86JWPWbcDkQd1JpN9Y4g78lTTgQFfMPBMUPYXuFHGh7NGfSlx3s0SF/IJflsN2MOt7wpab6MFwTK OnF6a7QS0zP0dWolUq3w2imiJA7jFb+HhOqfZlUwjRPk3ejzj9YdOoP/57wgQoQTvUDWeTsC4Rm0n Z92XnCd8JkLFz4GK9M+9AMTg7hfH6J0uEoNyAVNYPfteyvdLweNQUL59gN3wkiAJ6r1DVhLmBASVU b3X72qbqZDEf8k6E+t5KyYc2JTVuJP86PBLXhSLy+cUoGGeVOMqQqxX0xdBsUA5KUwbd901C/gOII JFfNoMVw==; Received: from foss.arm.com ([217.140.110.172]) by desiato.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ppn5z-005Eop-0H for linux-arm-kernel@lists.infradead.org; Fri, 21 Apr 2023 09:30:26 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 889A31480; Fri, 21 Apr 2023 02:31:02 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2D65B3F5A1; Fri, 21 Apr 2023 02:30:17 -0700 (PDT) Date: Fri, 21 Apr 2023 10:30:12 +0100 From: Cristian Marussi To: Oleksii Moisieiev Cc: Peng Fan , "sudeep.holla@arm.com" , Linus Walleij , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-gpio@vger.kernel.org" , "michal.simek@amd.com" , "vincent.guittot@linaro.org" , "souvik.chakravarty@arm.com" Subject: Re: [RFC v1 1/2] scmi: Introduce pinctrl SCMI protocol driver Message-ID: References: <54119b2cb43e29f69c5858a5320d3a58f23fed21.1680793130.git.oleksii_moisieiev@epam.com> <6dc456ff-7fc6-3b73-3727-dd048e9a9629@oss.nxp.com> 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-20230421_103023_907481_ADDAB281 X-CRM114-Status: GOOD ( 37.39 ) 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 Fri, Apr 21, 2023 at 08:40:47AM +0000, Oleksii Moisieiev wrote: > Hi Peng Fan, > > On 17.04.23 05:55, Peng Fan wrote: > > > > > > On 4/13/2023 6:04 AM, Cristian Marussi wrote: > >> On Fri, Apr 07, 2023 at 10:18:27AM +0000, Oleksii Moisieiev wrote: > >>> Implementation of the SCMI client driver, which implements > >>> PINCTRL_PROTOCOL. This protocol has ID 19 and is described > >>> in the latest DEN0056 document. > >> > >> Hi, > >> > >>> This protocol is part of the feature that was designed to > >>> separate the pinctrl subsystem from the SCP firmware. > >>> The idea is to separate communication of the pin control > >>> subsystem with the hardware to SCP firmware > >>> (or a similar system, such as ATF), which provides an interface > >>> to give the OS ability to control the hardware through SCMI protocol. > >>> This is a generic driver that implements SCMI protocol, > >>> independent of the platform type. > >>> > >>> DEN0056 document: > >>> https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!y2hR3PEGGxiPjVeXBcgGyV03DPDhzgUKR0uHvsTpiafKgBar8Egc6oOOs-IkFIquhSf-qBzltqEMyzRZHq8eC4g$ > >>> [developer[.]arm[.]com] > >>> > >> > >> No need to specify all of this in the commit message, just a note that > >> you are adding a new SCMIv3.2 Pincontrol protocol, highlighting anything > >> that has been left out in this patch (if any) will be enough. > > > > Is it possible to extend the spec to support multilple uint32_t for PIN > > CONFIG SET? > > > > With only one uint32_t could not satisfy i.MX requirement. > > > > Thanks, > > Peng. > > > IIUC you are expecting to have an ability to set some kind of array of > uint32_t config values to some specific ConfigType? > > I'm not sure if it's supported by pintctrl subsystem right now. I was > unable to find an example in the existing device-tree pinctrl bindings. > This makes me think that this kind of binding is OEM specific. > > Maybe it can be implemented by adding new IDs to OEM specific range > (192-255) which is reserved for OEM specific units (See Table 23 of > DEN0056E). > If I understood correctly the aim of Peng multi-valued request, I think that even if Linux does not support using this kind of multiple valued requests (as of now), if it is useful or required by some of the possibly supported hardware, it should be described and allowed by the specification and supported by the core SCMI protocol support at least, while the pinctrl SCMI driver can ignore this and keep using a one-sized array protocol_ops call internally (since it cannot do any different anyway as of now) IOW I dont think we should model too strictly the SCMI spec against only what the Linux pinctrl subsystem support today, since Linux it is just really only one of the possible SCMI agents and Linux implementation itself can possibly change: it is better to model the spec on the HW requirements or the possible usage patterns across all the possibly participating agents. As an example, for similar reasons, when the SCMI Voltage protocol was added to the spec, at the very last minute, a change was made to the spec to allow for negative voltages, even though the Linux regulator subsystem was not and still is not supporting at all negative voltages as of now; so basically the SCMI voltage protocol API now exposes a per-domain flag (negative_volts_allowed), that allows any kind of voltage domain to be enumerated and handled at the SCMI spec and core layer but that also allows any SCMI driver user, like the SCMI Regulator driver, to decide on his own if negative voltages domains can be supported: indeed the scmi-regulator driver just skips the initialization of any voltage domain that is found to be describing negative voltages. Here is a bit different, it is more of an optimization in the call path than an HW difference, but I would follow the same approach: with the SCMI spec and the core SCMI stack (the protocol) that supports a multi-uint32 call as a general case, if useful for some scenarios, and instead the SCMI pinctrl driver that just ignores this possibility and keep using a single-value array anyway....then, it will be up to the guys leveraging this multi-valued call to come up with a way to use it on their systems, possibly maybe contributing back to upstream any needed modification if general enough (not sure about the details of how this multi-vals operation should be...we'll have to discuss that about the spec all together I think.) In any case, I would definitely NOT relegate such possibility to vendor space, since it is something generic and, especially being just (as it seems to me) an optimization on the call path at the end, it will just lead to uneeded duplication of functionalities in the vendor implementation of stuff that it is already very slightly differently supported by the standard. ...just my opinion anyway, I'll happily let other guys in this thread discuss and decide about this :P Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel