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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3A30C7618E for ; Fri, 21 Apr 2023 09:49:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232072AbjDUJtB (ORCPT ); Fri, 21 Apr 2023 05:49:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232120AbjDUJsZ (ORCPT ); Fri, 21 Apr 2023 05:48:25 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 85D46C14B; Fri, 21 Apr 2023 02:47:53 -0700 (PDT) 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 105401480; Fri, 21 Apr 2023 02:48:37 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C85133F5A1; Fri, 21 Apr 2023 02:47:51 -0700 (PDT) Date: Fri, 21 Apr 2023 10:47:49 +0100 From: Cristian Marussi To: Linus Walleij Cc: Oleksii Moisieiev , Peng Fan , "sudeep.holla@arm.com" , "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-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, Apr 21, 2023 at 11:28:38AM +0200, Linus Walleij wrote: > On Fri, Apr 21, 2023 at 10:40 AM Oleksii Moisieiev > wrote: > > On 17.04.23 05:55, Peng Fan wrote: > > > On 4/13/2023 6:04 AM, Cristian Marussi wrote: > > > > 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). > Hi Linus, > From a pinctrl point of view I do not understand this requirement. > > The pinctrl subsystem in the Linux kernel certainly does not support > an array of u32 for the pin config, we only support passing a single > u32 value along with the enumerator (config type), or well it is > actually 24 bits in Linux, the uppermost 8 bits is for the config type: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/pinctrl/pinconf-generic.h > > /* > * Helpful configuration macro to be used in tables etc. > */ > #define PIN_CONF_PACKED(p, a) ((a << 8) | ((unsigned long) p & 0xffUL)) > > p = parameter (PIN_CONFIG_DRIVE_STRENGTH etc) > a = argument (value such as in mA) > My (possibly wrong) reasoning on the other reply, is based on the (possibly equally wrong :D) understanding that what Peng wants is just the possibility at the spec and the SCMI protocol layer (exposed in protocol operations) to issue PINCTRL_SET requests containing optionally an array of multiple ConfigType/Value pairs (which is anyway not supported by PinCtrl as I understand) instead of a single pair. ... but I can divine (:D)....that soon a new SCMI spec review/comment/amend cycle will be coming for people reading this... Thanks, Cristian