You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
This proposes a small integration to allow codegen create a C structure to store small data about pins. The end result can be used by gpio/pinmux/pinctrl drivers.
The discussion about the API can be followed at #22748. The intention here is not solve all the problems but give perspective and maybe give a option to store the data.
Describe the solution you'd like
This will try to solve the storage information for the SAMR21 device. It have a pinmux implementation but there isn't pinctrl definitions.
At run time system need access GPIO, Pinmux and Pinctrl DT definitions. To help with that, a C structure can handle most of definitions. This proposal consists in describe a way to simple store on flash the some pins definitions.
Add <platform>-pinfunc.h file for any platform
This file include/dt-bindings/pinctrl/<platform>-pinfunc.h will store macros and definitions for codegen. A good example is stm32_pinmux.h
It will be necessary create a C structure, define pin muxing names, a prolog and an epilog.
Define a macro that will be called at codegen and will be responsible to fill up the C structure.
#define PINMUX_EMIT "\t{ %d, %d, %d, %d},\n"
epilog
Will be called by codegen to finish the C structure instance.
#define EPILOG "}\n"
Concept proof
The codegen will process normally all device tree nodes. The last step can create a new file to store the struct instance. The codegen will go through all DT nodes searching for "pinctrl-x" property. For every match, it will get the property value and store on a list to avoid duplicate and process other possible checks. For the current example, the node is "usart0_default". Codegen need then evaluate the node and emit all entries on pinmux property plus a number that will represent all GPIO flags.
Additional context
I think this structure can store the data to be used for gpio/pinmux/pinctrl in the smallest possible value. The GPIO/pinmux driver can simple run over that structure and initialize the pins. To accomplish that will be need some additional API.
device_get_binding_by_index return a device driver by the index of storage. It is very fast because is just a dereference pointer. The codegen need emit 3 new informations:
1: For any "LABEL" that exists an equivalent INDEX exists. The user can used both and may replace the label since the index is a valid info and can be used.
2/3: Any group need the START and END definition to allow loop instructions. Since we don't store "compat" string we can't dynamically discover the indexes.
Benefits
We start to store an important and indispensable information.
We can define the standard as Linux and use the Linux DT too when appropriated.
User and SoC developers can start to populate DT with all Pinmux/Pinctrl information. I like Linux idea that say "even we are not using right now we need add the information for future use". This will enable things automatically in future.
Drop all GPIO definitions on dts_fixup files
Give free option to user define and use how many pins the board really need. Ex. If we define dts_fixup for 4 pin usart but user need only 2 we will initialize that anyway. With this user can define their own pinmux definition.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
This proposes a small integration to allow codegen create a C structure to store small data about pins. The end result can be used by gpio/pinmux/pinctrl drivers.
The discussion about the API can be followed at #22748. The intention here is not solve all the problems but give perspective and maybe give a option to store the data.
Describe the solution you'd like
This will try to solve the storage information for the SAMR21 device. It have a pinmux implementation but there isn't pinctrl definitions.
At run time system need access GPIO, Pinmux and Pinctrl DT definitions. To help with that, a C structure can handle most of definitions. This proposal consists in describe a way to simple store on flash the some pins definitions.
This file include/dt-bindings/pinctrl/<platform>-pinfunc.h will store macros and definitions for codegen. A good example is stm32_pinmux.h
It will be necessary create a C structure, define pin muxing names, a prolog and an epilog.
Will be called by codegen to create basic header for the C structure instance. As an simple example it could be:
#define PROLOG "static atmel_samd21_pinmux_struct atmel_samd21_pinmux_inst[] = {\n"
Define a macro that will be called at codegen and will be responsible to fill up the C structure.
#define PINMUX_EMIT "\t{ %d, %d, %d, %d},\n"
Will be called by codegen to finish the C structure instance.
#define EPILOG "}\n"
The codegen will process normally all device tree nodes. The last step can create a new file to store the struct instance. The codegen will go through all DT nodes searching for "pinctrl-x" property. For every match, it will get the property value and store on a list to avoid duplicate and process other possible checks. For the current example, the node is "usart0_default". Codegen need then evaluate the node and emit all entries on pinmux property plus a number that will represent all GPIO flags.
For the example:
Before
Became
Additional context
I think this structure can store the data to be used for gpio/pinmux/pinctrl in the smallest possible value. The GPIO/pinmux driver can simple run over that structure and initialize the pins. To accomplish that will be need some additional API.
device_get_binding_by_index return a device driver by the index of storage. It is very fast because is just a dereference pointer. The codegen need emit 3 new informations:
1: For any "LABEL" that exists an equivalent INDEX exists. The user can used both and may replace the label since the index is a valid info and can be used.
2/3: Any group need the START and END definition to allow loop instructions. Since we don't store "compat" string we can't dynamically discover the indexes.
Benefits
The text was updated successfully, but these errors were encountered: