On Tue, Apr 16, 2024 at 09:20:11PM +0300, Dan Carpenter wrote: > I'm trying to re-base AKASHI Takahiro's gpio driver on top of your scmi > pinctrl driver. > https://lore.kernel.org/all/20231005025843.508689-1-takahiro.akashi@xxxxxxxxxx/ > I need to do something like this below to save the gpio information. > > So now, great, I have the information but I'm not sure how to export it > from the scmi pinctrl driver to the gpio driver... (This is a probably > a stupid question but I am real newbie with regards to gpio). > Hi Dan, I dont think it is a stupid question, I'll try to answer your questions as much as possible, regarding the SCMI side, since I am definitely not so much familiar with the GPIO/Pinctrl subsystem either. First of all, to put things in perspective, drivers/firmware/arm_scmi/pinctrl.c is just the SCMI protocol layer, which as part of the core SCMI driver is in charge of implementing the specific protocol (i.e. building and sending appropriate messages via the SCMI core) and which, in turn, exposes a set of protocol-specific operations in scmi_protocol.h. On top of this there are the SCMI drivers (like drivers/pinctrl/pinctrl-scmi.c) that, on one side, plug into the SCMI stack, and as such can use the specific protocol_ops, and on the other side register into some custom existing Linux susbsystem like Pinctrl, so that it can relay generic Pinctrl related requests, via the above SCMI pinctrl_ops, to the platform SCMI fw (finally translated into SCMI messages at the protocol layer...) In all of this, note that the various protocol_ops in scmi_protocol.h are NOT exported symbols (would have been dozens): that is the reason why a driver willing to use an SCMI protocol via its specific ops, has to be, first, an SCMI driver so that can grab the related protocol_ops and an handle to the SCMI instance, during its probe phase. NOW, as far as I can remember (and have understood) AKASHI gpio-pinctrl driver was INSTEAD meant to be a generic GPIO driver on top of Pinctrl subsystem, so something that could work on top of any pinctrl controller, NOT necessarily an SCMI one, so, as a consequence it is NOT an SCMI driver and it cannot access directly any of the pinctrl_ops (existing or future), BUT it will have, instead, to be based on the Pinctrl subsystem API to achieve its functionalities in a generic manner. So at the end, AFAICU: - you collect any additional gpio info you need (and can get from the spec) at the SCMI Pinctrl protocol layer in drivers/firmware/arm_scmi/pinctrl.c (as you are doing) - you expose such info via pinctrl_ops: in these regards many OTHER protocols usually exposes some .get_info() ops to get a generic info descriptor including all info about a specific resource, BUT this is not the case for pinctrl_ops, which just exposes a few custom ops to get only the bits that are strictly needed (like resource names via .name_get()). Here is up to you which kind of interface to expose really, depending on the SCMI Pinctrl driver usage pattern. (is_gpio() ? .get_gpios() ? just a new out-param in an existing ops ?) - in the SCMI pinctrl-scmi driver you can finally make use of your new protocol_ops to provide to the Pinctrl subsystem the funcs needed by the Pinctrl API calls as issued by the gpio-pinctrl driver....and in these regards I really dont know what are the missing bits...I suppose something that has to work as the SCMI backend for the pinctrl_gpio_* calls inside gpio-pinctrl. > The other thing is that the SCMI spec says: > > 4.11.2.7 > PINCTRL_SETTINGS_GET > > This command can be used by an agent to get the pin or group > configuration, and the function selected to be enabled. It can also > be used to read the value of a pin when it is set to GPIO mode. > > What does that mean? Is that right, or is it something left over from a > previous revision of the spec. > My guess is that, this is a (certainly obscure) way for the spec to express the fact that using this message you can get the pin/group selected funcs AND pin/group configs, configs, that, include the settings for any OEM Config type as specified in SCMI spec Table 24, which, in turn, contains Input-mode/Output-mode/Output-value types that I suppose pertain to the GPIO world. As a consequence, I guess you neeed somehow to connect the above pinctrl_gpio_set/get_config and pinctrl_gpio_get_direction into the pinctrl_ops .setting_get_one() and .settings_conf() by using the proper GPIO-related OEM types, not sure of the details (as said I am ignorant) BUT it could be that this is already handled somehow by the current pinctrl-scmi driver if the GPIO ranges are handled correctly throughout all the chain of susbsystem involved... (looking at the internals of https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/core.c#L912) ...but I really not familiar on how GPIO ranges are supposed to work so it is better that now I shut up :D ...apologies for the long email, especially if I said something already obvious. Thanks, Cristian
