04-02-2023, 04:28 AM
(04-01-2023, 07:59 AM)CounterPillow Wrote: I looked at the schematic and datasheet to figure out whether there's any way to access SPI1/SPI2 with a different pinmux, and it doesn't seem to be the case. Seems like this module sadly won't work for your use-case.
You've almost addressed my next question.
I'm now re-evaluating my own options to see if I can change my application code to use the same SPI bus but flip between slave devices using different CS (chip select) - it's messy, a little complex with timings, but possible.
As such, it is not clear to me how to define my two CS's inside the device tree overlay.
Are the pin control pinmux references preset for each CS or do I still need to add inside the device tree overlay for my spi driver? If so, where do I find this pinmux table?
I also note that there are various device tree overlay templates found on the radxa github repository page (https://github.com/radxa/overlays/) which are applicable for use with RK386x chipsets and are defined as compatible with "rockchip". I assume these are suitable for use with the Pine64 SOQuartz board.
So assuming that's the case, and as SPI3 is available on the SOQuartz, am I correct to then create an overlay fragment for <&spi3> and then use the same pinctrl-0 pin references for CS0: <&spi3m0_cs0 &spi3m0_pins>;
Then what about CS1, as I noticed that Radxa's own compute module (RK3566 CM3) uses a different pin number here. Do I then assume that you have correctly linked the reference &spi3m0_cs1 to the correct pin in the RK3566. As I don't have visibility on how this all works, it is hard to know.
I look forward to your feedback.
Thanks.