Support SPI_HOLD_ON_CS flag in the CPU-based driver. To do this we will
set CONTC bit to continue previous command. Technically it may not be
necessary right now, and could just not clear CONT bit...
but in the future in the lpspi driver we
will decouple the config/init of a transfer from the SDK
and therefore have more control over TCR,
and when we write the TCR, we need to take CONTC bit into account
otherwise a new command will be made. So this approach is how
it should be handled in the driver going forward in my opinion, even
if it might be possible without this bit right now, I want to introduce
it's usage now.
This commit also does a minor refactor in the ISR and adds some comments
to make the strange CS behavior and strange handling code more clear to
future readers.
Also, make the early predicted SPI xfer end code only happen for spi
versions where it is necessary, since I think that code is really the
best we can do but might have a race condition, where possible the last
word is not finished sending when we end the xfer. So limit the
potential affect to v1 lpspi where the workaround is actually required
due to stalling behavior.
Lastly, set the LPSPI into master mode at active low in init, due to
it being the most common case, we want the SPI CS lines to be
initialized at init of driver. I don't think it's worth it to make it
configurable at this time, but in the future it could be if needed.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
e71aa649b2