Limit mcux drivers to SoCs that have the associated hardware #4317
Conversation
This patch sets the correct LSI_VALUE, according to STM32F3 reference manual's (RM0316) section 9.2.5 and STM32F1 reference manual's (RM0008) section 7.2.5. Signed-off-by: Yannis Damigos <[email protected]>
Adds device tree bindings for the Kinetis System Integration Module (SIM), and defines peripheral source clocks (e.g., system clock or bus clock) and clock gates for all Kinetis SoCs. Signed-off-by: Maureen Helm <[email protected]>
Adds a new clock control driver for Kinetis SoCs that have the system integration (SIM) module. This will allow mcux shim drivers, such as uart and i2c, to abstract the call to CLOCK_GetFreq() behind the clock_control interface and thus be reused for SoCs with different clock architectures. Signed-off-by: Maureen Helm <[email protected]>
Because the mcux shim drivers will soon depend on a clock control interface, enable the mcux sim clock control driver by default on all Kinetis SoCs. Signed-off-by: Maureen Helm <[email protected]>
Use the clock control interface instead of calling CLOCK_GetFreq() directly. This will allow SoCs with different clock architectures to reuse this driver. Signed-off-by: Maureen Helm <[email protected]>
Refactors the mcux lpuart shim driver to use the clock control interface instead of calling CLOCK_GetFreq() directly. This will allow SoCs with different clock architectures to reuse this driver. Signed-off-by: Maureen Helm <[email protected]>
Refactors the mcux lpsci shim driver to use the clock control interface instead of calling CLOCK_GetFreq() directly. This will allow SoCs with different clock architectures to reuse this driver. Signed-off-by: Maureen Helm <[email protected]>
Adds a Kconfig option HAS_MCUX_DSPI to indicate if the dspi hardware is present in the SoC and conditionalizes the mcux shim driver upon it. Signed-off-by: Maureen Helm <[email protected]>
Adds a Kconfig option HAS_MCUX_ETH to indicate if the ethernet mac hardware is present in the SoC and conditionalizes the mcux shim driver upon it. Signed-off-by: Maureen Helm <[email protected]>
Adds a Kconfig option HAS_MCUX_UART to indicate if the uart hardware is present in the SoC and conditionalizes the mcux shim driver upon it. Signed-off-by: Maureen Helm <[email protected]>
Adds a Kconfig option HAS_MCUX_I2C to indicate if the i2c hardware is present in the SoC and conditionalizes the mcux shim driver upon it. Signed-off-by: Maureen Helm <[email protected]>
Adds a Kconfig option HAS_MCUX_GPIO to indicate if the gpio hardware is present in the SoC and conditionalizes the mcux shim driver upon it. Signed-off-by: Maureen Helm <[email protected]>
Adds a Kconfig option HAS_MCUX_PORT to indicate if the port hardware is present in the SoC and conditionalizes the mcux shim driver upon it. Signed-off-by: Maureen Helm <[email protected]>
There are macros in the mcux device header files (e.g., MK64F12_features.h) that define how many instances of every NXP hardware module are present on the SoC. Add these macro names to the Kconfig help so developers adding new SoCs to Zephyr know how to set the HAS_MCUX_* configs. Signed-off-by: Maureen Helm <[email protected]>
The problem is that I have different variants of the same peripheral type, and each variant has its own driver. For example, there are two types of UARTs, three types of SPIs, two types of I2Cs in the Kinetis family (not all of these variants are in Zephyr yet). So I'm trying to prevent someone from accidentally choosing the wrong variant, or enabling a peripheral that doesn't even exist on a particular SoC. |
You mean UART vs LPUART? We can define those variants globally as well if needed, might be mcux specific right now, but can be used by other vendors that might implement this in the future... |
Yes. I don't think it makes sense to define LPUART globally because it's tied to the hardware and will always be mcux/nxp-specific. |
|
Low Power UART seems to be a very generic term to me :) |
|
I believe I saw LPUART term in EFM32's ;-). |
|
also ST has that. |
|
|
Doh, I accidentally clicked "close and comment".
Presumably with a different register programming model and thus a different driver, so wouldn't overloading the Kconfig just cause confusion? |
|
Defining HAS_LPUART globally and using it in different SoCs would not affect registers and drivers, it is just a flag that any SoC can use to select the right set of hardware configuration. We do have this problem where this type of information is being repeated for every vendor and this actually causes more confusion and kconfig overload. |
galak
force-pushed
the
arm
branch
2 times, most recently
from
48d0453 to
82e648d
Compare
galak
force-pushed
the
arm
branch
2 times, most recently
from
a053cce to
457699c
Compare
galak
force-pushed
the
arm
branch
2 times, most recently
from
ee5b12f to
f95e5fd
Compare
galak
force-pushed
the
arm
branch
2 times, most recently
from
6b38c09 to
ff730a4
Compare
Before this patch series, it was possible in Kconfig to enable the mcux ethernet driver, for example, on an NXP SoC like kw41z that doesn't have ethernet hardware. This would cause compiler errors, but let's catch it earlier in Kconfig. Some newer mcux drivers already do this, so make the older mcux drivers consistent with the newer ones.