drivers: use codegen for device instantiation #10888

b0661 · 2018-10-27T17:15:10Z

Overview

Use Codegen #10885 for device instantiation.

This PR includes parts of PR #10885. It is the successor to #9163.

Motivation for or Use Case

Demonstrate the usage of Codegen and the included devicedeclare module for device instantiation.

Design Details

The following drivers are adapted to use codegen for device instantiation:

I2C: i2c_ll_stm32.c (commit: drivers: i2c: stm32: use codegen driver instantiation)
SPI: spi_ll_stm32.c (commit: drivers: spi: stm32: use codegen driver instantiation)
SERIAL: uart_stm32.c: (commit: drivers: serial: stm32: use codegen driver instantiation)
CAN: stm32_can.c: (commit: drivers: can: stm32: use codegen driver instantiation)
PWM: pwm_stm32.c (drivers: pwm: stm32: use codegen driver instantiation)
INT: exti_stm32.c (drivers: interrupt: stm32: use codegen driver instantiation)

Codegen #10885 provides two device declaration functions in it's devicedeclare module.

devicedeclare.device_declare
Provides a sophisticated device declaration API. It is transferred from @erwango 's work in Generated driver instantiation prototype #8561.
devicedeclare.device_declare_single/multi
Provides a more raw device declaration API that allows for a fine grained control of the device instantiation template. It is the basis also for devicedeclare.device_declare.

All drivers above except INT are adapted to use the devicedeclare.device_declare_multi API.

The interrupt driver uses the devicedeclare.device_declare API. It is a minimal conversion to show the feasibility. For elaborated examples of the devciedeclare.device_declare API see #8561.

Codegen's device declaration is done using a device info template with placeholders that is used for every device instance. The placeholders are replaced by the respective device tree or device instance values:

Device tree property placeholder are defined by the property path; either ${[property path]} for properties of the actual device instance or ${[device id]:[property path]} for another device instance property.
The device instance placeholders ${device-[xxx]} provide device instance specific info that is autogenerated eg. device name, driver name, name of the data structure ...

/**
 * @code{.codegen}
 * codegen.import_module('devicedeclare')
 *
 * device_configs = ['CONFIG_I2C_{}'.format(x) for x in range(0, 5)]
 * driver_names = ['I2C_{}'.format(x) for x in range(0, 5)]
 * device_inits = 'i2c_stm32_init'
 * device_levels = 'POST_KERNEL'
 * device_prios = 'CONFIG_KERNEL_INIT_PRIORITY_DEVICE'
 * device_api = 'api_funcs'
 * device_info = \
 * """
 * #if CONFIG_I2C_STM32_INTERRUPT
 * DEVICE_DECLARE(${device-name});
 * static void ${device-config-irq}(struct device *dev)
 * {
 * #ifdef CONFIG_I2C_STM32_COMBINED_INTERRUPT
 *         IRQ_CONNECT(${interrupts/combined/irq}, ${interrupts/combined/priority}, \\
 *                     stm32_i2c_combined_isr, \\
 *                     DEVICE_GET(${device-name}), 0);
 *         irq_enable(${interrupts/combined/irq});
 * #else
 *         IRQ_CONNECT(${interrupts/event/irq}, ${interrupts/event/priority}, \\
 *                     stm32_i2c_event_isr, \\
 *                     DEVICE_GET(${device-name}), 0);
 *         irq_enable(${interrupts/event/irq});
 *         IRQ_CONNECT(${interrupts/error/irq}, ${interrupts/error/priority}, \\
 *                     stm32_i2c_error_isr, \\
 *                     DEVICE_GET(${device-name}), 0);
 *         irq_enable(${interrupts/error/irq});
 * #endif
 * }
 * #endif
 * static const struct i2c_stm32_config ${device-config-info} = {
 *         .i2c = (I2C_TypeDef *)${reg/0/address/0},
 *         .pclken.bus = ${clocks/0/bus},
 *         .pclken.enr = ${clocks/0/bits},
 * #if CONFIG_I2C_STM32_INTERRUPT
 *         .irq_config_func = ${device-config-irq},
 * #endif
 *         .bitrate = ${clock-frequency},
 * #if defined(CONFIG_SOC_SERIES_STM32F3X) || defined(CONFIG_SOC_SERIES_STM32F0X)
 *         .ll_clock_source = LL_${driver-name}_CLOCKSOURCE,
 * #endif
 * };
 * static struct i2c_stm32_data ${device-data};
 * """
 *
 * devicedeclare.device_declare_multi( \
 *     device_configs,
 *     driver_names,
 *     device_inits,
 *     device_levels,
 *     device_prios,
 *     device_api,
 *     device_info)
 * @endcode{.codegen}
 */
/** @code{.codeins}@endcode */

Test Strategy

This PR extends the SPI loopback test for the NUCLEO F091RC board. It was tested using this test and some
sample applications.

Signed-off-by: Bobby Noelte [email protected]

codecov-io · 2018-10-27T17:48:14Z

Codecov Report

Merging #10888 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #10888   +/-   ##
=======================================
  Coverage   48.23%   48.23%           
=======================================
  Files         279      279           
  Lines       43291    43291           
  Branches    10359    10359           
=======================================
  Hits        20881    20881           
  Misses      18270    18270           
  Partials     4140     4140

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dbf405a...6350298. Read the comment docs.

SavinayDharmappa · 2018-10-29T09:54:25Z

@b0661 some drivers of QMSI uses DEVICE_DEFINE() instead of DEVICE_AND_API_INIT() macro to initialize drivers providing power management support via the PM control function. The codgen by default substitues DEVICE_AND_API_INIT(). Is there any way to specify codegen to substitute DEVICE_DEFINE() macro instead of DEVICE_AND_API_INIT() macro?

b0661 · 2018-10-29T11:45:38Z

@SavinayDharmappa

Is there any way to specify codegen to substitute DEVICE_DEFINE() macro instead of DEVICE_AND_API_INIT() macro?

Not implemented at the moment. But should not be a problem to switch between DEVICE_DEFINE() and DEVICE_AND_API_INIT() based on pm_control value.

device_declare_multi() may become

def device_declare_multi(device_configs,
                         driver_names,
                         device_inits,
                         device_pm_controls,
                         device_levels,
                         device_prios,
                         device_api,
                         device_info,
                         device_defaults = {}):

device_pm_controls maybe a list of pm_control functions or a single pm_control function or None.

evenl · 2018-10-30T08:36:15Z

drivers/serial/uart_stm32.c

+ *                   for x in range(1, 11)] + \
+ *                  ['CONFIG_UART_STM32_LPUART_{}'.format(x) \
+ *                   for x in range(1, 2)]
+ * driver_names = ['UART_{}'.format(x) for x in range(1, 11)] + \


I don't understand why you do this, you already have the label field that you can use? What if the order of devices in the DTS data is not from low to high? Is there any guarantee that the device order will be the same in the DTS database as in the dts file?

I don't understand why you do this, you already have the label field that you can use?

Later on I will search for device where the label value fits to the ones that I set up here.

What if the order of devices in the DTS data is not from low to high?

That does not matter. I just search for a device with the given label value.

Is there any guarantee that the device order will be the same in the DTS database as in the dts file?

This is not necessary - see above.

evenl · 2018-10-30T08:41:41Z

scripts/codegen/cmake.py

+from pathlib import Path
+
+
+class CMakeCacheEntry:


What do you need the cache information for?

For driver writing.

evenl · 2018-10-30T09:14:57Z

scripts/codegen/edts.py

+                if extract:
+                    # File produced by the DT compiler
+                    board = self.cmake_variable("BOARD")
+                    dts_compiled = Path(prj_bin_dir, '{}.dts_compiled'.format(board))


Why isn't the edts.json file containing the same information as the dts_compiled file? It should not be necessary for the code generator to aggregate information from multiple sources.

The EDTS database class that I am using has it´s own extract function. It does not depend on extract_dts_includes to fill the database. It the file is already available it just loads the json file. You comment on the etxract part if no edts.json file is available.

evenl · 2018-10-30T09:21:52Z

scripts/codegen/modules/devicedeclare.py

+                          device_api,
+                          device_info,
+                          device_defaults = {}):
+    device_configured = codegen.config_property(device_config, '<not-set>')


Isn't 'not-set' the default?

evenl · 2018-10-30T09:31:30Z

scripts/codegen/modules/devicedeclare.py

+    return irq_bootstrap_info
+
+
+def device_declare(compatibles, init_prio_flag, kernel_level, irq_func,


Wouldn't it be easier to just pass a object, for instance a dictionary? I get the chills when I see this many parameters to a function.
init_prio_flag and kernel_level can probably also default to 'CONFIG_KERNEL_INIT_PRIORITY_DEVICE' and 'POST_KERNEL' as it seems that most drivers use this values.

@erwango, can you explain. It is your device_declare variant.

evenl · 2018-10-30T10:02:23Z

scripts/codegen/modules/devicedeclare.py

+    config_struct = _device_generate_struct('config', config_struct)
+    data_struct = _device_generate_struct('data', data_struct)
+    if api is None:
+        api = "(*(const int *)0)"


Shouldn't the template trust that the target toolchain has a sane NULL value?

erwango

Pleas rebase on topic-EDTS branch.
Same comments as always on the need for higher level device_declare API

erwango · 2018-10-30T17:00:34Z

drivers/can/stm32_can.c

+ * codegen.import_module('devicedeclare')
+ *
+ * device_configs = ['CONFIG_CAN_1', ]
+ * driver_names = ['CAN_1', ]


As mentioned several times, this should not be present in API.
This information should be extracted from device tree and drivers <> EDTS binding should be done by 'compatible' property. This is literally its main and only use.
cf #8561

As mentionend several times to identify a specific driver instance the compatible is not enough. There are usual several driver instantiations for one compatible. So you need something more to identify a single one and use the 'label' property for that. But if you use the 'label' property in addition to the 'compatible' you find out that the 'label' alone is unique und you really do not need the 'compatible'. Taking the 'compatible' and the 'label' is just a waste of computing.

If you would look into the code of your device_declare variant you could easily identify that in the end only the 'label' is used.

erwango · 2018-10-30T17:01:50Z

drivers/can/stm32_can.c

+ * static void ${device-config-irq}(CAN_TypeDef *can)
+ * {
+ *         LOG_DBG("Enable ${driver-name} IRQ");
+ * #ifdef CONFIG_SOC_SERIES_STM32F0X


'compatible' should be used to identify and provide variations of the same driver.
#ifdef CONFIG_SOC_SERIES_STM32F0X should not be present in templated code.

Hey this is a proof of concept and not a full blown driver rework, I expect the CAN driver author to do the rework in the end when there is a code generation facility. My focus was the extraction of device tree data not to make that work without some ifdefs.

erwango · 2018-10-30T17:03:37Z

drivers/can/stm32_can.c

+ * device_info = \
+ * """
+ * DEVICE_DECLARE(${device-name});
+ * static void ${device-config-irq}(CAN_TypeDef *can)


This whole piece of code, IRQ configuration functions, should be extracted by API.
API should be able to detect if node specifies IRQs, and generated this code if needed, cf #8561

I know your opinion. This is just to show the principle. You can use your device_declare variant here also. Your variant will fail with STM32F0 UART drivers. A lot of shared interrupts where you definitely need a more sofisticated way to generate interrupt routines. The driver is OOT but I can tell it definitely did not work with the driver_declare interrupt configuration - your one and also not the simple one that I have here.

erwango · 2018-10-30T17:04:27Z

drivers/i2c/i2c_ll_stm32.c

@@ -20,6 +21,23 @@ LOG_MODULE_REGISTER(i2c_ll_stm32);

 #include "i2c-priv.h"

+#if defined(CONFIG_SOC_SERIES_STM32F3X) || defined(CONFIG_SOC_SERIES_STM32F0X)


This changes are not related to code generation. Remove from there

In these drivers I added changes whenever CI failed. As already mentioned it is a proof of concept. I do not claim that every driver is right but I want CI to pass. I can not demonstrate the viability of Codegen without CI to pass.

erwango · 2018-10-30T17:04:39Z

drivers/i2c/i2c_ll_stm32.c

-	 */
-	LL_RCC_GetSystemClocksFreq(&rcc_clocks);
-	clock = rcc_clocks.SYSCLK_Frequency;
+	if (cfg->ll_clock_source != LL_I2C_NO_CLOCKSOURCE) {


Remove from this change

There were compile errors in CI before !???! Is this gone?

erwango · 2018-10-30T17:04:50Z

drivers/i2c/i2c_ll_stm32.c

@@ -173,32 +197,10 @@ static int i2c_stm32_init(struct device *dev)
 	clock_control_on(clock, (clock_control_subsys_t *) &cfg->pclken);

 #if defined(CONFIG_SOC_SERIES_STM32F3X) || defined(CONFIG_SOC_SERIES_STM32F0X)
-	/*


Remove from this change

erwango · 2018-10-30T17:06:35Z

drivers/spi/spi_ll_stm32.c

@@ -338,12 +355,12 @@ static int spi_stm32_configure(struct device *dev,
 	spi_context_cs_configure(&data->ctx);

 	LOG_DBG("Installed config %p: freq %uHz (div = %u),"
-		    " mode %u/%u/%u, slave %u",


Why modifying this?

Not by intention. Seems to have happened when SYS_LOG was changed to LOG and I updated.

erwango · 2018-10-30T17:06:50Z

drivers/spi/spi_ll_stm32.c

+ * codegen.import_module('devicedeclare')
+ *
+ * device_configs = ['CONFIG_SPI_{}'.format(x) for x in range(1, 7)]
+ * driver_names = ['SPI_{}'.format(x) for x in range(1, 7)]


Cf comments on CAN driver

erwango · 2018-10-30T17:33:07Z

@b0661

We've been trying to formalize requirements for driver devices generation here: #10904 (still open for debate, if you want to).

To my view, what is missing to the various PR you've been proposing is adherence to above requirements (which were not written down until now, I hope having a formalized version makes things clearer now). This is why Iv'e been pushing #8561.

Though, I don't want to push this despite you, so if you feel interested, feel free to push your own version of a codegen solution that could work with requirements.

b0661 · 2018-10-30T19:51:56Z

@erwango

Thank you for the comments. I am not quite shure what to do with the comments that relate to driver functions and not to code generation from DTS.

If codegen does not get merged all this will not be necessary.
If codegen is merged the authors of the drivers should do the changes looking at here to have it as a starting point.

My goal for all drivers is to show Codegen works and the driver passes CI and sometimes some other tests.

carlescufi · 2018-10-31T11:07:59Z

@b0661 thanks for the PR. As mentioned by @erwango this should be rebased on top of the topic branch. During my discussions with the rest of Zephyr TSC members, most of us expressed a dislike for having the generated code embedded in the actual .c file. Instead we would prefer to have a clean separation between generated code (i.e. instantiation) and the actual driver code.
Is this something that would be possible with codegen? I assume it is, because I believe this came up before, but just double-checking here.

b0661 · 2018-11-01T09:32:33Z

@carlescufi

. ...Instead we would prefer to have a clean separation between generated code (i.e. instantiation) and the actual driver code.
Is this something that would be possible with codegen? I assume it is, because I believe this came up before, but just double-checking here.

Yes it is possible. For codegen you simply define the template file and the destination file. It the template file happens to be called my_file.h.in and the destination file my_file.h codegen will produce it the way you are expecting it.

b0661 · 2018-11-01T10:14:34Z

@carlescufi

As mentioned by @erwango this should be rebased on top of the topic branch.

Will do - but I have to finish some work yet.

Sorry - EDIT:

What about the build system integration of codegen (btw. as you asked that: I wrote that - not @SebastianBoe). @evenl somehow hijacked the codegen build system integration - will that be changed?

EDIT2:

Just saw - already done. Thank you @evenl.

b0661 · 2018-11-03T20:27:22Z

@erwango, @galak, @carlescufi, @evenl

Codegen now supports inlined template "snippets" written in Python or Jinja2. Also files that are one template snippet as a whole (without snippet markers) are supported.

@evenl, for Jinja2 I copied the device_declare.jinja2 file but renamed it to devicedeclare.jinja2 (no underscore) to make it distinct from jinja2gen. This way codegen and jinja2gen can coexist.

The STM32 SPI driver is (mis-)used to show all the different ways to generate code that are supported by codegen:

inline template: the template snippets are inlined in the source code that works as a template file. Codegen and Jinja2 snippets are inlined one after the other to be able to compare the generated code.
Jinja2 template: A header file is generated from the respective Jinja2 template
Codegen Python template: Also a header file is generated from the codegen Python template.

Compilation is done for the SPI source file that includes the codegen Python generated header file. The generated code (from Python and Jinja2 snippets) in the source file is guarded by #if 0 and not compiled.
This is equivalent to the preferred scenario of having an unmodified driver.c and a generated driver_device.h file.

Both Jinja2 and Python templates have access to the same codegen functions using codegen.funcX() function signatures.

Codegen is now also made (hopefully) completely independent from Zephyr. It integrates the EDTS database and can extract from the DTS compiled file and bindings. All relevant info and data can now be provided by options specified on invocation. Codegen should now be usable also standalone. The integration into the Zephyr build system is changed accordingly.

The Jinja2 and codegen Python templates used for header creation generate the same code !-) with slightly different indentation. The templates are:

Jinja2:

{% import 'devicedeclare.jinja2' as spi_stm32 %}

{% set config_struct_body = """
       .spi = (SPI_TypeDef *)0x{{ '%x'|format(data['device'].get_property('reg/0/address/0')) }}U,
       .pclken.bus = {{ data['device'].get_property('clocks/0/bus') }},
       .pclken.enr = {{ data['device'].get_property('clocks/0/bits') }},
#ifdef CONFIG_SPI_STM32_INTERRUPT
       .irq_config = {{ irq_config_function_name }},
#endif """
%}

{% set data_struct_body = """
    SPI_CONTEXT_INIT_LOCK({{ data_struct_name }}, ctx),
    SPI_CONTEXT_INIT_SYNC({{ data_struct_name }}, ctx), """
%}

{% set params = {    'irq_flag'           : 'CONFIG_SPI_STM32_INTERRUPT',
		     'irq_func'           : 'spi_stm32_isr',
                     'config_struct'      : 'spi_stm32_config',
                     'data_struct'        : 'spi_stm32_data',
                     'api_struct'         : 'api_funcs',
                     'init_function'      : 'spi_stm32_init',
		     'config_struct_body' : config_struct_body,
		     'data_struct_body'   : data_struct_body } %}

{{ spi_stm32.device(data, ['st,stm32-spi', 'st,stm32-spi-fifo'], params) }}

Codegen Python:

codegen.import_module('devicedeclare')

device_configs = ['CONFIG_SPI_{}'.format(x) for x in range(1, 7)]
driver_names = ['SPI_{}'.format(x) for x in range(1, 7)]
device_inits = 'spi_stm32_init'
device_levels = 'POST_KERNEL'
device_prios = 'CONFIG_SPI_INIT_PRIORITY'
device_api = 'spi_stm32_driver_api'
device_info = \
"""
#if CONFIG_SPI_STM32_INTERRUPT
DEVICE_DECLARE(${device-name});
static void ${device-config-irq}(struct device *dev)
{
        IRQ_CONNECT(${interrupts/0/irq}, ${interrupts/0/priority}, \\
                    spi_stm32_isr, \\
                    DEVICE_GET(${device-name}), 0);
        irq_enable(${interrupts/0/irq});
}
#endif
static const struct spi_stm32_config ${device-config-info} = {
        .spi = (SPI_TypeDef *)${reg/0/address/0},
        .pclken.bus = ${clocks/0/bus},
        .pclken.enr = ${clocks/0/bits},
#if CONFIG_SPI_STM32_INTERRUPT
        .config_irq = ${device-config-irq},
#endif
};
static struct spi_stm32_data ${device-data} = {
        SPI_CONTEXT_INIT_LOCK(${device-data}, ctx),
        SPI_CONTEXT_INIT_SYNC(${device-data}, ctx),
};
"""

devicedeclare.device_declare_multi( \
    device_configs,
    driver_names,
    device_inits,
    device_levels,
    device_prios,
    device_api,
    device_info)

These are generic bindings that the extraction function of the EDTS database can work with. The bindings can be overriden by providing a same named file to cogeno within a directory that is given in the --bindings option. Signed-off-by: Bobby Noelte <[email protected]>

Modules and templates for Zephyr device declaration using code generation by cogeno. devicedeclare.py: a python module to support codegen python templates and cogeno inline templates devicedeclare.jinja2: a jinja2 template to support cogeno jinja2 templates and codegen inline templates Signed-off-by: Bobby Noelte <[email protected]>

Integrate code generation by cogeno into Zephyr build system. If a source file is added by zephyr_sources_codegen(..) or zephyr_sources_codegen_ifdef(..) cogeno will be executed and the generated file stored to the build directory. Compilation will run on the generated file only. Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by codegen solution. Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by code generation solution. For testing purposes all different ways of code generation are done for this driver: - inline template - cogeno and Jinja2 snippets - generates a source file - Jinja2 template - generates a header file - codegen template - generates a header file Compilation is done for the unmodified source file including the codegen generated header file. Additionally the following adaptations are done: - Extend bindings to allow DTS extract for device info. - Correct DTS to be used in SPI driver. Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by code generation solution. Extend binding to allow DTS extraction for device info. Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by code generation solution. Extend binding to allow DTS extract for device info. Correct DTS to be used in CAN driver. Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by code generation solution. Extend binding to allow DTS extraction for device info. Adapt samples. Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by code generation solution. Add binding to allow DTS extract for device info. Add DTS to be used in EXTI driver. Signed-off-by: Bobby Noelte <[email protected]>

The NUCLEO FO91RC, F070RB, F030R8 boards use SPI_1 for loopback test. Signed-off-by: Bobby Noelte <[email protected]>

Incorrect naming prevents compilation. Change names: - CONFIG_xx_NAME -> DT_xx_NAME - spi_sam0_xx -> spi_sam_xx Signed-off-by: Bobby Noelte <[email protected]>

b0661 requested review from andrewboie, erwango, nashif, SebastianBoe, superna9999, tbursztyka and ydamigos as code owners October 27, 2018 17:15

b0661 mentioned this pull request Oct 27, 2018

scripts: inline code generation with cogeno (and edts) #10885

Closed

b0661 force-pushed the pr_codegen_drivers branch 2 times, most recently from 5ef6ec1 to 603140f Compare October 28, 2018 08:44

galak added the area: Devicetree label Oct 28, 2018

b0661 force-pushed the pr_codegen_drivers branch 2 times, most recently from fb1031c to 45746f3 Compare October 28, 2018 17:54

carlescufi requested a review from evenl October 29, 2018 12:51

evenl reviewed Oct 30, 2018

View reviewed changes

erwango requested changes Oct 30, 2018

View reviewed changes

b0661 force-pushed the pr_codegen_drivers branch 2 times, most recently from f62ec73 to 953c4b5 Compare November 3, 2018 18:26

SebastianBoe removed their request for review November 13, 2018 13:49

carlescufi mentioned this pull request Nov 13, 2018

Device Tree support overhaul #8499

Closed

6 tasks

b0661 force-pushed the pr_codegen_drivers branch from 953c4b5 to 861ee96 Compare November 18, 2018 10:36

b0661 added 11 commits November 27, 2018 09:43

drivers: i2c: stm32: use code generation for driver instantiation

fee96d1

Replace device instances code by codegen solution. Signed-off-by: Bobby Noelte <[email protected]>

drivers: serial: stm32: use code generation for driver instantiation

14efbdc

Replace device instances code by code generation solution. Extend binding to allow DTS extraction for device info. Signed-off-by: Bobby Noelte <[email protected]>

drivers: can: stm32: use code generation for driver instantiation

67ad920

Replace device instances code by code generation solution. Extend binding to allow DTS extract for device info. Correct DTS to be used in CAN driver. Signed-off-by: Bobby Noelte <[email protected]>

drivers: pwm: stm32: use code generation for driver instantiation

08fb2e9

Replace device instances code by code generation solution. Extend binding to allow DTS extraction for device info. Adapt samples. Signed-off-by: Bobby Noelte <[email protected]>

drivers: interrupt: stm32: use code generation for driver instantiation

3cebfd3

Replace device instances code by code generation solution. Add binding to allow DTS extract for device info. Add DTS to be used in EXTI driver. Signed-off-by: Bobby Noelte <[email protected]>

tests: drivers: spi: support NUCLEO F0x boards

be75e68

The NUCLEO FO91RC, F070RB, F030R8 boards use SPI_1 for loopback test. Signed-off-by: Bobby Noelte <[email protected]>

spi: sam: fix function and config naming

6350298

Incorrect naming prevents compilation. Change names: - CONFIG_xx_NAME -> DT_xx_NAME - spi_sam0_xx -> spi_sam_xx Signed-off-by: Bobby Noelte <[email protected]>

b0661 force-pushed the pr_codegen_drivers branch from 78c6a1e to 6350298 Compare November 27, 2018 08:47

galak added area: Devicetree Tooling PR modifies or adds a Device Tree tooling and removed area: Devicetree labels Jan 30, 2020

github-actions bot added area: Devicetree has-conflicts Issue/PR has conflicts with another issue/PR area: Device Tree labels Jun 29, 2020

galak removed the area: Device Tree label Jul 1, 2020

github-actions bot added has-conflicts Issue/PR has conflicts with another issue/PR platform: STM32 ST Micro STM32 and removed has-conflicts Issue/PR has conflicts with another issue/PR labels Jul 2, 2020

b0661 mentioned this pull request Sep 2, 2020

edtlib: support inferring binding from node content #27937

Merged

nashif added the Stale label Sep 7, 2020

github-actions bot closed this Sep 22, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

drivers: use codegen for device instantiation #10888

drivers: use codegen for device instantiation #10888

b0661 commented Oct 27, 2018 •

edited

Loading

codecov-io commented Oct 27, 2018 •

edited

Loading

SavinayDharmappa commented Oct 29, 2018

b0661 commented Oct 29, 2018

evenl Oct 30, 2018

b0661 Oct 30, 2018

evenl Oct 30, 2018

b0661 Oct 30, 2018

evenl Oct 30, 2018

b0661 Oct 30, 2018

evenl Oct 30, 2018

evenl Oct 30, 2018

b0661 Oct 30, 2018

evenl Oct 30, 2018 •

edited

Loading

erwango left a comment

erwango Oct 30, 2018

b0661 Oct 30, 2018 •

edited

Loading

erwango Oct 30, 2018

b0661 Oct 30, 2018

erwango Oct 30, 2018

b0661 Oct 30, 2018

erwango Oct 30, 2018

b0661 Oct 30, 2018

erwango Oct 30, 2018

b0661 Oct 30, 2018

erwango Oct 30, 2018

erwango Oct 30, 2018

b0661 Oct 30, 2018

erwango Oct 30, 2018

erwango commented Oct 30, 2018

b0661 commented Oct 30, 2018

carlescufi commented Oct 31, 2018 •

edited

Loading

b0661 commented Nov 1, 2018 •

edited

Loading

b0661 commented Nov 1, 2018 •

edited

Loading

b0661 commented Nov 3, 2018

		return irq_bootstrap_info


		def device_declare(compatibles, init_prio_flag, kernel_level, irq_func,

		@@ -20,6 +21,23 @@ LOG_MODULE_REGISTER(i2c_ll_stm32);

		#include "i2c-priv.h"

		#if defined(CONFIG_SOC_SERIES_STM32F3X) \|\| defined(CONFIG_SOC_SERIES_STM32F0X)

drivers: use codegen for device instantiation #10888

drivers: use codegen for device instantiation #10888

Conversation

b0661 commented Oct 27, 2018 • edited Loading

Overview

Motivation for or Use Case

Design Details

Test Strategy

codecov-io commented Oct 27, 2018 • edited Loading

Codecov Report

SavinayDharmappa commented Oct 29, 2018

b0661 commented Oct 29, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

evenl Oct 30, 2018 • edited Loading

Choose a reason for hiding this comment

erwango left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

b0661 Oct 30, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erwango commented Oct 30, 2018

b0661 commented Oct 30, 2018

carlescufi commented Oct 31, 2018 • edited Loading

b0661 commented Nov 1, 2018 • edited Loading

b0661 commented Nov 1, 2018 • edited Loading

b0661 commented Nov 3, 2018

b0661 commented Oct 27, 2018 •

edited

Loading

codecov-io commented Oct 27, 2018 •

edited

Loading

evenl Oct 30, 2018 •

edited

Loading

b0661 Oct 30, 2018 •

edited

Loading

carlescufi commented Oct 31, 2018 •

edited

Loading

b0661 commented Nov 1, 2018 •

edited

Loading

b0661 commented Nov 1, 2018 •

edited

Loading