drivers/mfd: it8801: Implement ITE IT8801 mfd drivers

[GTLin08]

This PR Implements the ITE IT8801 IO expander multi-function device driver. The IO expander provides GPIO, PWM, and keyboard functions via the I2C bus.

[keith-zephyr]

Also consider running clang-format on all the files.

[keith-zephyr]

This driver supports multiple instances, but this this assumes that there is only one IT8801 defined.

[GTLin08]

Fixed, use multiple instances.

[keith-zephyr]

This function isn't available in this commit. Each commit should build on it's own. Add this support with the KBD driver commit.

You could have the child drivers register an alert callback. Then MFD driver doesn't need to know the type of each child.

If you wanted the alert callbacks to be configured at build time, you could define an iterable section per it8801 instance.

See INPUT_CALL_DEFINE for an example of creating an iterable section for a specific device instance.

[GTLin08]

Moved to respective driver.

Because the KBD and GPIO devices of IT8801 share the gpio irq. Consider that if IT8801 is connected to the EC, the GPIO interrupt is enabled in the interrupt configuration using irq_connect_dynamic.
Repeated registration of gpio irq will cause Assert problem, so here we only register it once in mfd_ite_it8801.

[keith-zephyr]

Nodename gpio0 is likely to conflict the the GPIO controller on the SoC.

[GTLin08]

Renamed.

[keith-zephyr]

This assumes only one KBD driver installed. This should be calculated on each KBD instance.

[GTLin08]

Fixed, use multiple instances.

[keith-zephyr]

Drivers should support multiple instances.

[GTLin08]

Fixed, use multiple instances.

[keith-zephyr]

Add a BUILD_ASSERT that the init priority is lower (higher number) than the MFD parent.

[fabiobaltieri]

I suggested in a separate comment that this could all use the same priority, then the sub priority would take care of sequencing the init correctly, I think it's a better approach, less options kicking around. Build asserts should not be needed anymore since the build priorites are checked at build time btw.

[GTLin08]

Is there anything I can refer to here? I'm encountering a build error when using CONFIG_MFD_INIT_PRIORITY + 1 in Kconfig or here.

[GTLin08]

Use CONFIG_MFD_INIT_PRIORITY on all the child devices.

[keith-zephyr]

Add a BUILD_ASSERT to check the init priority.

[GTLin08]

Use CONFIG_MFD_INIT_PRIORITY on all the child devices.

[fabiobaltieri]

Just an quick initial, pass, noticed some comments of mine overlaps with Keith.

Hey is there a board where you could add this? I'm a bit confused by the dtsi file you have in one of the commits, would be nice to have build testing in CI as well.

[fabiobaltieri]

hey can you try to initialize all the sub devices at CONFIG_MFD_INIT_PRIORITY? the sub-priority should take care of the sequencing, less priority options kicking around... you can check the output with west build -t initlevels

[GTLin08]

Is there anything I can refer to here? I'm encountering a build error when using CONFIG_MFD_INIT_PRIORITY + 1 here.

[fabiobaltieri]

yeah just use CONFIG_MFD_INIT_PRIORITY on all the child devices, then the effective initialization number is going to be a concatenation of CONFIG_MFD_INIT_PRIORITY and the ordinal that the device gets [1][2], and since the childs are under the parent the child ordinal is going to be higher than the parent which is going to result in the correct initialization sequence.

[1] https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/device.h#L1112
[2] https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/init.h#L150C43-L150C51

[GTLin08]

Thank you for the information, fixed.

[fabiobaltieri]

I suggested in a separate comment that this could all use the same priority, then the sub priority would take care of sequencing the init correctly, I think it's a better approach, less options kicking around. Build asserts should not be needed anymore since the build priorites are checked at build time btw.

[GTLin08]

Just an quick initial, pass, noticed some comments of mine overlaps with Keith.

Hey is there a board where you could add this? I'm a bit confused by the dtsi file you have in one of the commits, would be nice to have build testing in CI as well.

I have created a test program to connect with it8xxx2_evb as shown in the link

[GTLin08]

Also consider running clang-format on all the files.

This is very strange. When using ./scripts/ci/check_compliance.py locally, there is a prompt such as:

You may want to run clang-format on this change

drivers/mfd/mfd_ite_it8801.c:133 
-		DT_INST_FOREACH_CHILD_STATUS_OKAY_SEP(inst, DEVICE_DT_GET, (,))};                  \
+		DT_INST_FOREACH_CHILD_STATUS_OKAY_SEP(inst, DEVICE_DT_GET, (, ))};                 \

But after I upload the program, I get the following error:

SPACING: space prohibited before that close parenthesis ')'
File:drivers/mfd/mfd_ite_it8801.c
Line:132

[GTLin08]

Rebase and resolve conflicting files.

[GTLin08]

Hi @fabiobaltieri, @keith-zephyr, If there’s any further feedback on the updates I made. Thanks!

[keith-zephyr]

Node names should use dashes instead of underscores.

[GTLin08]

Done.

[keith-zephyr]

Is the relative path necessary? Does #include <ite/it8801-mfd-map.dtsi> work instead?

[GTLin08]

Fixed to #include <ite/it8801-mfd-map.dtsi>

[keith-zephyr]

Another option here. The children devices already have a reference to the parent mfd. The MFD driver could add an API to register an interrupt callback.

mfd_it8801_register_interrupt_callback(const struct device *mfd,
    const struct device *child,
    callback_function);

Then you could also drop sub_mfd_dev array, and you could drop the if (dev != data->gpio_dev) checks in the child drivers.

[GTLin08]

Thanks for the suggestion! It really helped simplify the code.

[keith-zephyr]

This should check that mfd_cb has been assigned.

[GTLin08]

Done.

[keith-zephyr]

Is there always a 1:1 relationship from the MFD parent to the child that needs an interrupt callback?
Or does the MFD need to maintain a list of callbacks registered?

[GTLin08]

Yes, the MFD needs to maintain a list of registered callbacks, and I have made the modifications.

[keith-zephyr]

This is still more complicated than needed. The MFD parent doesn't need to know if the child is a KBD, GPIO, or PWM.

You should create a structure that each child is responsible for allocating:

struct mfd_callback {
    it8801_callback_handler_t cb;
    const struct device *dev;
};

Then the mfd_it8801_register_interrupt_callback() routine needs to just add the mfd_callback allocated by the child to a linked list. You can use the the gpio_manage_callback() for creating the linked list.

Then when dispatching the interrupt in it8801_gpio_alert_worker, you only need to iterate over the linked list. No special checks for KBD vs GPIO are needed.

[GTLin08]

Done.

[fabiobaltieri]

cool, few more comments, sorry for the delay this fell of my radar

[GTLin08]

Rebased.

[fabiobaltieri]

cool, couple missing static qualifiers, rest is good, great job, Keith is out for the next couple of weeks I think it's fine to wait for him?

[fabiobaltieri]

static

[GTLin08]

Done.

[fabiobaltieri]

static

[GTLin08]

Done.

[fabiobaltieri]

static

[GTLin08]

Done.

[GTLin08]

cool, couple missing static qualifiers, rest is good, great job, Keith is out for the next couple of weeks I think it's fine to wait for him?

OKey, thank you for your feedback!

[keith-zephyr]

The GPISR documentation in the IT8801 datasheet indicates:
"When GPIO Direction is 0, and the state of the corresponding pin matches the interrupt triggered condition, the corresponding bit will be set to 1."

The level_high_trig and level_low_trig fields don't seem necessary. Does the driver need to track level triggered interrupts separate from the IT8801?

[GTLin08]

The IT8801 already supports level-triggered interrupts internally. Therefore, the level_high_trig and level_low_trig fields are redundant and have been removed.