NXP LPSPI: Move RTIO/DMA code to separate file #82750
Conversation
decsny
force-pushed
the
feature/lpspi_enhancements_2
branch
4 times, most recently
from
07e3813 to
0239d0c
Compare
Move this driver to its own subfolder to organize it since there will be new files added for this hardware. Signed-off-by: Declan Snyder <[email protected]>
There is (almost) a whole separate driver for RTIO, move this code to its own file and move shared code and definitions to a common file. Signed-off-by: Declan Snyder <[email protected]>
The DMA-based path of the lpspi driver is basically almost a driver of it's own, move it to it's own file. Signed-off-by: Declan Snyder <[email protected]>
decsny
force-pushed
the
feature/lpspi_enhancements_2
branch
from
0239d0c to
fd73aaa
Compare
zephyrbot
added
area: SPI
zephyrbot
requested review from
dbaluta,
dleach02,
manuargue,
mmahadevan108,
tbursztyka and
teburd
| @@ -0,0 +1,131 @@ | |||
| /* | |||
There was a problem hiding this comment.
What made you consider making this a data a separate header file?
Nit But what do you think about moving this into the common.c?
There was a problem hiding this comment.
it's not clear to me what you are commenting about because your comment is just at the top of the file
There was a problem hiding this comment.
I mean moving the entire file into common.c
There was a problem hiding this comment.
I'm not sure what you mean, the header files has definitions that the other 3 files need in order to compile
|
@tbursztyka can you help to review, note this would be the first spi driver with its own subfolder |
|
Another effect of this due to new kconfig structure is that RTIO will actually be tested by twister because now it takes precedence if enabled. Before, I realized the RTIO testcase was most likely causing the DMA (non-rtio) path of the driver to be tested instead of RTIO because of the convolution of having so many different orthogonal "paths"/drivers in one file, and the testcase.yaml didn't account for the convolution properly by disabling the DMA (which we dont need to do anymore since they are no longer coupled) |
Good! RTIO could be viewed as a feature superset, maybe one day we can simply say this is the right way to do things, but some caveats likely would need to be sorted first. |
|
@tbursztyka can we get your attention on this PR so we can move it along? |
|
board testing pass |
|
@tbursztyka I've added myself to the assignee to help move this along. |
There was a problem hiding this comment.
@dleach02 sure don't hesitate to do so, I am assigned by default because of maintainership. But when it comes to manufacturer specific changes, the default is not the most relevant anyway. (And I still get issues with being notified but GitHub...)
depends on:
This file is basically 3 drivers in one sharing just the device structs and the configure function, and in my opinion it is not manageable, move them to seperate files