Need help with Device Tree for SPI Device
Hello all,
I'm a bit new to the embedded Linux world despite having about a decade of general embedded experience at this point. My trouble at the moment is that I'm trying to add a SPI device to an IMX7 board but for some reason it is not configuring the pads to be used for the SPI, they stay configured as GPIOs. If I use devmem, I can modify the memory location where the muxing takes place and see that it will transmit/receive data as I expect so I'm guessing it's just an issue with the device tree. I've added this to a device tree include that is added to the board's devicetree after everything else. Code:
&iomuxc { Oh, the Chip select works as it should. It's the MISO, MOSI, and Clock that don't. |
I'd double check that you really are triggering the pinmux section. (Check dmesg for errors).
Secondly, are you 100% sure that dts ecspi1 corresponds to pad ecspi1? (They sometimes start from 0/1). That would explain that cs works (as you use it as gpio) while the rest seemingly does not. Lastly, your pinmux settings of 0x2 are not really ok. Check the datasheet of the imx for more info, or at least check another dts example. Gl! |
Quote:
Quote:
Quote:
|
Quote:
I just last week saw when trying to figure out the mapping the data sheet listed spidev's 1-4, but the DTB is 0 based, so it's spidev0-3. So take that into account. Are you able to post the original DTS w/o changes? IMX7, should be relatively easy to find successful configs on the spidev dts. https://www.toradex.com/community/qu...for-imx7d.html |
Quote:
Also, I did a little experiment and changed it from using the spi-imx to spi-gpio and it worked just fine. So I'm wondering now if there's not something I fucked up with the iomux that I just don't know about. |
Your kernel was built with SPI support, right? Usually it's disabled by default.
Do you see the actual device in /dev/spidev... ? I fucking hate these DTS's. Always a pain in the ass, docs never clear & concise. |
Quote:
Quote:
Cause.. The only way that would actually work, is if the other SPI pins were in GPIO mode. Assuming you did not change the pinmux, it indeed again points to the pinmux problem. Since you manually forced the registers before, I'd guess you can do the same and just read them out? Imx also provides sysfs and debugfs entries for reading out the current pinmux settings. Also check out the "NXP imx linux user manual" datasheet or something for more info. Don't remember by heart, but there is a very easy way to just dump the current pinmux of all pins. That will in all likelyhood point to what is going wrong. |
Quote:
Quote:
|
Quote:
Quote:
Possibly, but I've had this same exact issue where the SPI won't work because of DTB options, but the same pins bitbang GPIO fine. Pinmux was fine in that case. Quote:
|
Quote:
|
Quote:
It's possible your board doesn't have any, I'm not sure, but it's what hosed me. I haven't used your family of boards though so take it with a grain of salt. EDIT: Does yours have a custom kernel (ie. something that manu tweaked, or include drivers, etc.)? If so, there's likely docs with that which describe these parameters which you can include in the DTS configuration. If there's no kernel modifications and no drivers supplied then you can ignore this possibility as obviously default Linux SPI drivers have default Linux SPI options. |
Quote:
|
Ok, so I got desperate and started looking through the spi-imx driver in spi-imx.c. I'm rather new to this so I'm probably way the hell off here but I don't understand how this driver can work since the driver never references any sort of pinctrl. Is there any other way that the driver might attempt to setup the pins?
|
Quote:
That file (or there-abouts) is where those manufacturer specific DTB parameters would get processed. So look for them in there. I think you're on the right track. Hard for me to say how it works without looking, and I'm by no means a kernel expert, but the equivalent of that file is where I go for params. There's also usually a doc by a similar name in the Documentation directory of the BSP. EDIT: Look for function: "of_property_read_bool()" in that SPI driver file, that's where it looks for the parameters given in the DTB. May not be bool, it's a whole family of functions, but look for that prefix. As I said though, look for something by a similar name in the "Documentation" directory of the source tree. Mine has a whole .txt on SPI configuration with parameters you can use, what they do, etc. |
Looks like these are the bindings for the driver:
Code:
Required properties: Am I understanding the hierarchy correctly? The spi-imx driver is the bus itself and spidev driver is what's used to actually talk to what's on the bus, right? If so then it does make sense that the spi-imx would need to know which pads/pins to use, right? |
All times are GMT -5. The time now is 02:47 PM. |