drivers: mipi-dbi: use string for mipi-mode property

[danieldegrasse]

Use a string for the mipi-mode property over an integer value, as this
significantly improves the readability of the MIPI DBI device binding.

Open to feedback as to whether we feel this improvement is work breaking downstream user devicetrees. Personally I think it is ok given the transition note in the migration guide, but I'm not strongly committed to this change.

[jfischer-no]

LGTM, API is considered experimental

[erwango]

Mostly a complain about usage of strings in bindings:
I won't block but I wonder if spreading use of strings is going in the right direction. I know this is used in other places and this is peanuts in the binary size of an application running display. However, if this starts to be generalized in all bindings, this will start to be visible in binaries of small applications around few 10Ks (eg sensors).
This is specially a shame as we're "bloating" binaries for bindings readability (so, not even a functional reason), while historically we've always tried to find footprint friendly solutions, even for complex functional issues.

[JarmouniA]

This is specially a shame as we're "bloating" binaries for bindings readability (so, not even a functional reason), while historically we've always tried to find footprint friendly solutions, even for complex functional issues.

@erwango unless I'm mistaken, this is not going to increase binary size as DT_INST_STRING_UPPER_TOKEN(inst, mipi_mode) is still going to be resolved to an integer value (as defined in https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/dt-bindings/mipi_dbi/mipi_dbi.h) during preprocessing.

[danieldegrasse]

This is specially a shame as we're "bloating" binaries for bindings readability (so, not even a functional reason), while historically we've always tried to find footprint friendly solutions, even for complex functional issues.

@erwango unless I'm mistaken, this is not going to increase binary size as DT_INST_STRING_UPPER_TOKEN(inst, mipi_mode) is still going to be resolved to an integer value (as defined in https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/dt-bindings/mipi_dbi/mipi_dbi.h) during preprocessing.

Yeah, this is my understanding as well. We are expanding these strings to a C token, which the preprocessor will then handle.

[faxe1008]

Hmm I kinda get the point regarding the readbility, but imo adding a comment after each enum value would make the binding also more terse.
Additionally it kinda adds some macrobatics where the end result in a dt overlay is using a " instead of <. If the stringified version was more compact I guess there would be more to gain from this change.

But yeah neither nacking or approving, just wanted to give my two cents as I had this suggestion on one of my PRs earlier as well :^)

[danieldegrasse]

Hmm I kinda get the point regarding the readbility, but imo adding a comment after each enum value would make the binding also more terse. Additionally it kinda adds some macrobatics where the end result in a dt overlay is using a " instead of <. If the stringified version was more compact I guess there would be more to gain from this change.

But yeah neither nacking or approving, just wanted to give my two cents as I had this suggestion on one of my PRs earlier as well :^)

Yeah, I guess the advantage is that the string enum is a bit more restrictive- IE it is not possible to ignore the recommendation of "please use the MIPI DBI header to get the integer value". The output devicetree generated by the build system will also be more readable.

[erwango]

@erwango unless I'm mistaken, this is not going to increase binary size as DT_INST_STRING_UPPER_TOKEN(inst, mipi_mode) is still going to be resolved to an integer value (as defined in https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/dt-bindings/mipi_dbi/mipi_dbi.h) during preprocessing.

:), perfect then!

[danieldegrasse]

Rebased to pick up CI fixes