Hi Souvik,
thanks for looking into this!
On Mon, Nov 13, 2023 at 1:56 PM Souvik Chakravarty
<souvik.chakravarty@xxxxxxx> wrote:
> The initial assumption always was that GPIOs can be considered as a
> specific function. Note that the spec does not define the types of
> function and leaves it to the DT binding (or driver) to figure out the
> function descriptions/names.
Does this mean that each system using pinctrl-SCMI will need
to specify the available pins, groups and functions in a device tree
binding? For e.g. DT validation using schema?
This creates the problem of where to put it since
Documentation/devicetree/bindings/firmware/arm,scmi.yaml
is all we have, and for schemas to be applicable the implicit
assumption is that this is done per-compatible.
If we want to use device tree validation of the strings put into
the pinctrl node we need to allow for a per-soc compatible
under the pinctrl node like:
protocol@19 {
compatible = "vendor,soc-scmi-pinctrl";
(...)
Then a DT schema can be made to match that and check it.
I'm uncertain about that because the SCMI binding has nothing
like this at the moment, all the protocol nodes are pretty
self-describing and don't seem to need any further configuration
to be used, but pin control may be the first instance where we
have to add some per-soc configuration into the protocol nodes :/
It's easy to do:
+ protocol@19:
+ type: object
+ allOf:
+ - $ref: "#/$defs/protocol-node"
+ - $ref: "../pinctrl/pinctrl.yaml"
+ unevaluatedProperties: false
+
+ properties:
compatible:
items:
- enum:
- vendor1,soc1-scmi-pinctrl
- vendor2,soc2-scmi-pinctrl
- vendor3,soc3-scmi-pinctrl
This should be enough for just establishing the different
pin control configurations we can have in the device tree.
We are then able to put a more detailed schema for the
specific SoC pin control, such as a list of valid groups and
functions etc under the ordinary pinctrl bindings such as
Documentation/devicetree/bindings/pinctrl/vendor1,soc1-scmi-pinctrl.yaml
etc.
We should preferably put some pattern like this in place from
day 1 so developers know what is expected here. A mock
SoC is fine for the time being (we can delete it later when there
are some serious ones).
I'm uncertain because it feels like a first thing, but I can't really
think how it would work otherwise, part of me don't want to
pollute the SCMI binding with any per-soc compatibles, but
yet since these group and function strings will be per-soc I don't
see any other way, if they are supposed to be validated
with schema.
Yours,
Linus Walleij
