Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Hello! Thank you for reaching out with your question about using the ST7789V LCD with the Verdin iMX8MP and Dahlia board.
There are several issues in your device tree overlay that may lead to your observed behavior, where spidev1.0 is still present and the st7789v driver is not bound. Here’s how you can troubleshoot and resolve these issues:
1. Verify Overlay Application
First, check if your device tree overlay was actually applied on your system:
ls /proc/device-tree/chosen/overlays/
Look for a file named with your overlay, for example: your_overlay_name.dtbo
Then, verify its status:
cat /proc/device-tree/chosen/overlays/your_overlay_name.dtbo
If the content is 0, the overlay was applied successfully.
More details here
2. Disabling spidev Properly
Your method of disabling spidev@0 may not actually disable the default spidev1.0 on the system. The correct method, as seen in the official Toradex SPIDEV overlays, is to override the existing spidev node. The overlay should look more like this for disabling spidev:
&ecspi1 {
status = "okay";
/* Disable the spidev node */
spidev@0 {
status = "disabled";
};
/* Add your st7789v node here */
...
};
Make sure the node name (spidev@0) exactly matches the one from the base device tree.
Reference: Device Tree Overlay Documentation
3. GPIO Assignments
You are using &gpio1 0 for both DC and reset lines. For proper operation, assign unique and valid GPIOs for each signal. Confirm that these are available and do not conflict with other board functions:
dc-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* e.g., GPIO1_IO0 */
reset-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>; /* e.g., GPIO1_IO1 */
Note: Ensure these GPIOs are physically routed and available on the Dahlia board for your use.
4. Check for Pin Conflicts
A common issue is pin conflicts. If another function already claims the pins you want to use, the kernel won’t bind your driver. Review the pinmux and ensure no conflict exists, especially for the chosen SPI bus and GPIOs.
More info: Community discussion about pin conflicts
5. Pinctrl Configuration
Make sure the required SPI pins are properly muxed by including or referencing the proper pinctrl settings. The base device tree should already set these for SPI1 if you use default SOM+board combinations, but if not, you may need to extend your overlay to specify something like:
pinctrl-0 = <&pinctrl_ecspi1>;
(Where pinctrl_ecspi1 is defined appropriately.)
6. Driver Binding Verification
Check the kernel log for SPI-related messages or driver binding errors:
dmesg | grep -i spi
Look for messages about the st7789v—this can provide hints on why it didn’t bind.
7. Overlay Example Reference
Compare your overlay’s structure with the official verd-in-imx8mp_spidev overlay to ensure the override structure matches expectations.
If you implement these suggestions—especially the proper disabling of spidev, assigning unique GPIOs, and checking for conflicts—your custom driver should bind correctly.
Let me know if you need clarification or if any issues persist after making these adjustments!
Best regards,
Toradex AI Assistant.
