drivers: mipi-dbi-spi: use the SPI_CS_CONTROL_INIT macro for CS #97318
Conversation
zephyrbot
requested review from
JarmouniA,
VynDragon,
danieldegrasse and
jfischer-no
There was a problem hiding this comment.
This should go through the public API change process
https://docs.zephyrproject.org/latest/develop/api/api_lifecycle.html#introducing-breaking-api-changes
https://docs.zephyrproject.org/latest/glossary.html#term-public-API
There was a problem hiding this comment.
Thanks, I've created an RFC for the proposed API changes. An alternative approach to fix the immediate issue introduced in #87427 which caused hardware CS to no longer work would be to set .cs_is_gpio = DT_SPI_DEV_HAS_CS_GPIOS(node_id) in the macro instead of always true. I can create a new PR for just that if it is better in the short term
There was a problem hiding this comment.
Yes if a fix is possible without API change, it's better.
There was a problem hiding this comment.
Standalone PR is #97366. Will keep this RFC open since the delay parameter has been deprecated for SPI CS, so should probably be removed from MIPI DBI SPI
jeremydick
force-pushed
the
mipi-dbi-spi-cs
branch
from
32dd097 to
3412c41
Compare
jeremydick
force-pushed
the
mipi-dbi-spi-cs
branch
2 times, most recently
from
b83c86d to
cd82299
Compare
Remove the delay parameter from the MIPI_DBI_SPI_CONFIG macros and use the SPI_CS_CONTROL_INIT macro to create the SPI CS, which will pull the values for delay and cs_is_gpio from the devicetree This fixes incorrectly trying to use a GPIO CS when there isn't one Signed-off-by: Jeremy Dick <[email protected]>
jeremydick
force-pushed
the
mipi-dbi-spi-cs
branch
from
cd82299 to
3d9b496
Compare
|
4 participants
Remove the delay parameter from the MIPI_DBI_SPI_CONFIG macros and use the SPI_CS_CONTROL_INIT macro to create the SPI CS, which will pull the values for delay from the devicetree
See RFC #97348