kinetis: Abstraction for PORT module

[jnohlgard]

Pin configuration and alternate function handling driver for internal periph driver use, similar to stm32f0's gpio_init_af.

This PR only updates the GPIO component. I have prepared the other periph drivers as well, but need to rebase on top of the periph API changes.

@haukepetersen can we merge this first and rebase the periph changes in #4780, #4431, #4430 on top? It will save us work on the kinetis periph drivers in those PRs.

[jnohlgard]

Added PWM module changes since #4638 was merged

[haukepetersen]

Hmm, this seems still overly complicated to me, why not just make this as part of the GPIO driver, e.g. with some CPU internal function as gpio_init_af/mux or similar everything should be in order?! This is what we did for many other CPUs and I can't imagine that the kinetis are so much different...

[jnohlgard]

I don't see what is overly complicated? The only difference between this and other CPUs is that the port_init function is inside port.c instead of gpio.c and exported so that it can be used from the other periph drivers as well instead of only from inside gpio.c.

[jnohlgard]

ah, and the push/pull configuration. I built this on the premise that we'd need that parameter but depending on the outcome of #4750 and #4472 we might need to refactor port_init a little.

[haukepetersen]

But why put in i'ts own module. I think there is actually no need to export functions like '_gpio_port(gpio_t dev)' or '_gpio_port(gpio_t dev)` to the other periph drivers, as these are only needed internally in the GPIO driver. This keeps the code simpler and IMHO easier to follow.

[jnohlgard]

The idea is that the periph drivers will also use port_init to select their desired alternate functions in the mux. I don't know how to do this without exporting some new symbol or changing the current GPIO API to support an AF parameter?

[haukepetersen]

Here is how I would envision the gpio module to look like: #4830. Only thing open is the open-drain configuration, but can be put in easily... I think #4830 looks much easier (at least to me :-))

[haukepetersen]

so when using this from other peripheral drivers (e.g. spi/uart), you just call

gpio_ini(mosi_pin, GPIO_DIR_OUT, GPIO_NOPULL);  // adapt to changes when integrating OD mode...
gpio_init_af(mosi_pin, GPIO_AFx);

-> easy to use, and no need for the SPI driver to know anything about ports/gpio/pins in depth...

[jnohlgard]

Closing in favour of #4830