Vinicius Costa Gomes
Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes:
It would be good to have design changes for pinmux outlined in oneGood idea, this is going to be useful to see if what I have in mind is
aligned with what other's have.
This is a rough sketch of what's I am working on:
* Code organization:
* Galileo is a special case, and to avoid copied functions in the
pinmux_dev driver, '_galileo_set_pin()' will be made available to both
the "board" driver and "dev" driver via the 'pinmux_galileo_priv.h'
The drivers in 'pinmux' will have only the equivalent of
'_pinmux_defaults()' part of the 'board/*/pinmux.c' files.
The drivers in 'pinmux_dev' will provide the pinmux reconfiguration part that
you refer below.
If we are just changing code for two SoCs, I have no problem with itAt first what comes to mind is that we could have a common header that
provides functions that are used by a family of boards. Or are you
talking about something else? (I don't know anything about FRDM k64F)
- reconfiguring pinmux from an application is not usual practice, butWe will provide the pinmux_dev driver for applications that wish to do this.
- pinmux_initialize() may and sometimes should not be implemented byThe board drivers (in 'pinmux'), in the common case, will write directly
in the registers, configuring multiple pins at the same time,
maintaining what we have right now in Zephyr.