New unified hostmot2 SPI driver hm2_spix#3209
Conversation
Don't close ports forcefully at exit, let the driver do that on cleanup. Fix some text typos. Don't add isopen to spix_spidev driver. It can be determined from the file descriptor.
Add spi_pull_* arguments for compatibility and warn if they are used. Use rtapi_open_as_root instead of plain open.
Use variable bit-length mode in SPI1 transfers. Fix swapping words back to host-order after transfer.
Add more generic forwarding of module arguments when opening a port. Recalculate min/max frequencies for RPi3/4. Allow spidev device node path overrides.
Update comments.
Copy errno because following code can alter it. Reading a 0-byte length file is not a real error. It will lead to a fail later.
Don't fuss, sizeof(uint32_t) = 2 * sizeof(uint16_t) and will never change.
Other manufacturers will have other names, but may share the last portion.
…iver. Compensate truncated input values by adding one kHz to the rate settings.
|
Amazing work! Thank you for this, this is perfect timing for my project. |
|
Thanks. |
Actually, it only touches two files from the previous driver: hm2_rpspi.c and spi_common_rpspi.h. A backport to 2.9 would change exactly the same thing as this PR did in HEAD. Now, HEAD should evolve a bit further, where a cleanup is in order, which I mentioned in the text accompanying this PR. None of the evolution needs to be backported for the hm2_spix driver to function in 2.9. |
|
Wow Thank You Sir. |
This is the new unified SPI driver for the Mesa cards supporting hostmot2 over SPI. This driver currently supports Raspberry Pi 3, 4 and 5 natively, including compute modules 4 and 5, and will automatically fall back to the kernel's spidev interface if an unsupported board is found. The driver is written for easy addition of new native hardware drivers like future RPi boards or existing other "fruity" pi boards.
The new driver also includes fixes for SPI1 on the RPi3 and RPi4 boards, which was non-functional with the previous driver.
The new hm2_spix driver is easily back-ported if required.
The code body includes some separated source files for future de-duplicating of some routines and constants, which other HM2 drivers should make use of later on. A second PR will be created after integration of this driver to streamline and implement code de-duplication for the other drivers(s).