You limit the functionality, so it's not the case.However, there also are some advantages of our core compared to David's I'd like to mentionSo can David's. You can use BIOS tables in which case you must compile the SPI core into the
- it can be compiled as a module
kernel but you can also use spi_new_device which allows the SPI core to be built as a module (and
is how I am using it).
Yeah, I can agree with this statement. However, as it turns out, the latest David's core eliminates this issue.
- it is DMA-safeTo my understanding David's core is DMA-safe. Yes there is a question mark over one of the helper
functions, but the _main_ functions _are_ DMA-safe.
If there's more than one SPI controller onboard, spi_write_then_read will serialize the transfers related to two different controllers what will have significant negative impact on the transfer speed (so DMA won't help increasing the speed in this case). Moreover, if, say, two kernel threads with different priorities are working with two SPI controllers respectively *priority inversion* will happen.
- it is priority inversion-freeSorry I'm not sure what you mean here.
- it can gain more performance with multiple controllers
Nope, it's just a default policy.
- it's more adapted for use in real-time environments
- it's not so lightweight, but it leaves less effort for the bus driver developer.
But also less flexibility. A core layer shouldn't _force_ a policy
on a bus driver. I am currently developing an adapter driver for David's system and I wouldn't sayMain are
that the core is making me do things I think the core should do. Please could you provide examples
of where you think Davids SPI core requires 'effort'.