LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer
User Name
Password
Linux - Embedded & Single-board computer This forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.

Notices


Reply
  Search this Thread
Old 06-11-2019, 04:14 PM   #1
T_Versicolor
LQ Newbie
 
Registered: Jun 2019
Location: Usually on fallen trees
Distribution: Whatever I've cobbled together through Yocto
Posts: 10

Rep: Reputation: 0
Unhappy 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 {
    ecspi0grp {
        pinctrl_ecspi0_0: ecspi0_pin_ctrl {
            fsl,pins = <
            MX7D_PAD_ECSPI1_SCLK__ECSPI1_SCLK 0x2
            MX7D_PAD_ECSPI1_MOSI__ECSPI1_MOSI 0x2
            MX7D_PAD_ECSPI1_MISO__ECSPI1_MISO 0x2
            >;
        };
        pinctrl_ecspi0_cs_0: ecspi0_cs_0 {
            fsl,pins = <MX7D_PAD_ECSPI1_SS0__ECSPI1_SS0 0x2>;
        };
    };
};

&ecspi1 {
    status="okay";
    cs-gpios = <&gpio4 19 0>;
    pinctrl-0 = <&pinctrl_ecspi0_0 &pinctrl_ecspi0_cs_0>;
    spidev0: spidev@0 { 
        compatible = "rohm,dh2228fv";
        #address-cells = <1>;
        #size-cells = <1>;
        reg = <0>;
        spi-max-frequency = <29000000>;
        status="okay";
    };
};
The clocks/interrupts/etc are setup elsewhere in the tree. As far as I could tell all I needed was what I've included.

Oh, the Chip select works as it should. It's the MISO, MOSI, and Clock that don't.

Last edited by T_Versicolor; 06-12-2019 at 02:13 PM. Reason: Copied from earlier file.
 
Old 06-13-2019, 01:51 PM   #2
arre
LQ Newbie
 
Registered: Nov 2005
Location: Belgium
Distribution: Slackware 10.2 & Windows 98 & Windows XP Pro & ...
Posts: 25

Rep: Reputation: 1
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!
 
Old 06-13-2019, 03:34 PM   #3
T_Versicolor
LQ Newbie
 
Registered: Jun 2019
Location: Usually on fallen trees
Distribution: Whatever I've cobbled together through Yocto
Posts: 10

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by arre View Post
I'd double check that you really are triggering the pinmux section. (Check dmesg for errors).
I've grep'ed through dmesg for just about everything I can think of and it appears to be behaving. Other pins are being setup appropriately.

Quote:
Originally Posted by arre View Post
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.
As far as I can tell it's the correct one. ecspi0 isn't used anywhere in the rest of the tree. The datasheet indexes the SPI ports starting at 1 for some reason as well.

Quote:
Originally Posted by arre View Post
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.
I've tried a ton of different configs. I lifted this from the ecspi2 which isn't really being used but seemed like it would be good to crib from.
 
Old 06-13-2019, 05:39 PM   #4
Syndacate
Member
 
Registered: Aug 2008
Location: Santa Clara, CA
Distribution: Ubuntu, mainly. Too much stuff works out of the box O.o
Posts: 61

Rep: Reputation: 52
Quote:
Originally Posted by T_Versicolor View Post
As far as I can tell it's the correct one. ecspi0 isn't used anywhere in the rest of the tree. The datasheet indexes the SPI ports starting at 1 for some reason as well.

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
 
1 members found this post helpful.
Old 06-17-2019, 10:11 AM   #5
T_Versicolor
LQ Newbie
 
Registered: Jun 2019
Location: Usually on fallen trees
Distribution: Whatever I've cobbled together through Yocto
Posts: 10

Original Poster
Rep: Reputation: 0
Quote:
Are you able to post the original DTS w/o changes?
There's not much else I've really changed from imx7d-phyboard-zeta-001.dts. I put the above lines as well as a bit to add a device to an I2C bus into a new include after the other includes.

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.
 
Old 06-19-2019, 03:09 AM   #6
Syndacate
Member
 
Registered: Aug 2008
Location: Santa Clara, CA
Distribution: Ubuntu, mainly. Too much stuff works out of the box O.o
Posts: 61

Rep: Reputation: 52
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.
 
1 members found this post helpful.
Old 06-19-2019, 03:17 AM   #7
arre
LQ Newbie
 
Registered: Nov 2005
Location: Belgium
Distribution: Slackware 10.2 & Windows 98 & Windows XP Pro & ...
Posts: 25

Rep: Reputation: 1
Quote:
I fucking hate these DTS's. Always a pain in the ass, docs never clear & concise.
Lol, you pefer the old way of actually having to recompile a different kernel for each board variation then?

Quote:
Also, I did a little experiment and changed it from using the spi-imx to spi-gpio and it worked just fine.
And how exactly did that look? Can you paste the full dts?

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.
 
1 members found this post helpful.
Old 06-19-2019, 11:01 AM   #8
T_Versicolor
LQ Newbie
 
Registered: Jun 2019
Location: Usually on fallen trees
Distribution: Whatever I've cobbled together through Yocto
Posts: 10

Original Poster
Rep: Reputation: 0
Quote:
Your kernel was built with SPI support, right? Usually it's disabled by default.

Do you see the actual device in /dev/spidev... ?
Yup, there's SPI support and the device is in the /dev folder

Quote:
And how exactly did that look? Can you paste the full dts?
Do you want like literally everything or just the part that I modified? Cause this tree seems pretty big. I made a python script to pull everything together and there's quite a bit there. I guess I could also give you a dtb or something if you wanted...
 
Old 06-20-2019, 03:37 AM   #9
Syndacate
Member
 
Registered: Aug 2008
Location: Santa Clara, CA
Distribution: Ubuntu, mainly. Too much stuff works out of the box O.o
Posts: 61

Rep: Reputation: 52
Quote:
Originally Posted by arre View Post
Lol, you pefer the old way of actually having to recompile a different kernel for each board variation then?
Well that's not picnic either but the problem I've found with DTB's is simply that every board manufacturer has a bunch of different options which need to be added to the node and they're never clear in the docs about what they are and what needs to be set; then much Google-fu later you find whatever cryptic ass options the node needs and everything works. Maybe I'd feel differently if I had different board revs.


Quote:
Originally Posted by arre View Post
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.

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:
Originally Posted by T_Versicolor View Post
Yup, there's SPI support and the device is in the /dev folder.
Yeah my bet is on DTB params. Gotta find the SPI configuration docs for that specific chip.
 
1 members found this post helpful.
Old 06-20-2019, 08:10 AM   #10
T_Versicolor
LQ Newbie
 
Registered: Jun 2019
Location: Usually on fallen trees
Distribution: Whatever I've cobbled together through Yocto
Posts: 10

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by Syndacate View Post
Yeah my bet is on DTB params. Gotta find the SPI configuration docs for that specific chip.
What are DTB params?
 
Old 06-21-2019, 05:46 AM   #11
Syndacate
Member
 
Registered: Aug 2008
Location: Santa Clara, CA
Distribution: Ubuntu, mainly. Too much stuff works out of the box O.o
Posts: 61

Rep: Reputation: 52
Quote:
Originally Posted by T_Versicolor View Post
What are DTB params?
Just some extra fields that are manu specific and are passed to the driver via the DTB.

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.

Last edited by Syndacate; 06-21-2019 at 06:01 AM.
 
1 members found this post helpful.
Old 06-21-2019, 09:28 AM   #12
T_Versicolor
LQ Newbie
 
Registered: Jun 2019
Location: Usually on fallen trees
Distribution: Whatever I've cobbled together through Yocto
Posts: 10

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by Syndacate View Post
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.
Not exactly. I'm building this via Yocto with a BSP supplied by Phytec which uses what I assume is a modified kernel since it's being pulled from their bitbucket. I'm not sure how I would check that tho. I did tweak this a little by pulling in a patch that I thought might help but didn't.
 
Old 06-21-2019, 01:11 PM   #13
T_Versicolor
LQ Newbie
 
Registered: Jun 2019
Location: Usually on fallen trees
Distribution: Whatever I've cobbled together through Yocto
Posts: 10

Original Poster
Rep: Reputation: 0
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?
 
Old 06-21-2019, 02:33 PM   #14
Syndacate
Member
 
Registered: Aug 2008
Location: Santa Clara, CA
Distribution: Ubuntu, mainly. Too much stuff works out of the box O.o
Posts: 61

Rep: Reputation: 52
Quote:
Originally Posted by T_Versicolor View Post
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?

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.

Last edited by Syndacate; 06-21-2019 at 02:44 PM.
 
1 members found this post helpful.
Old 06-21-2019, 03:15 PM   #15
T_Versicolor
LQ Newbie
 
Registered: Jun 2019
Location: Usually on fallen trees
Distribution: Whatever I've cobbled together through Yocto
Posts: 10

Original Poster
Rep: Reputation: 0
Looks like these are the bindings for the driver:

Code:
Required properties:
- compatible :
  - "fsl,imx1-cspi" for SPI compatible with the one integrated on i.MX1
  - "fsl,imx21-cspi" for SPI compatible with the one integrated on i.MX21
  - "fsl,imx27-cspi" for SPI compatible with the one integrated on i.MX27
  - "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31
  - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35
  - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51
  - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53 and later Soc
  - "fsl,imx8mq-ecspi" for SPI compatible with the one integrated on i.MX8M
- reg : Offset and length of the register set for the device
- interrupts : Should contain CSPI/eCSPI interrupt
- clocks : Clock specifiers for both ipg and per clocks.
- clock-names : Clock names should include both "ipg" and "per"
See the clock consumer binding,
	Documentation/devicetree/bindings/clock/clock-bindings.txt

Recommended properties:
- cs-gpios : GPIOs to use as chip selects, see spi-bus.txt.  While the native chip
select lines can be used, they appear to always generate a pulse between each
word of a transfer.  Most use cases will require GPIO based chip selects to
generate a valid transaction.

Optional properties:
- num-cs :  Number of total chip selects, see spi-bus.txt.
- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
Documentation/devicetree/bindings/dma/dma.txt.
- dma-names: DMA request names, if present, should include "tx" and "rx".
- fsl,spi-rdy-drctl: Integer, representing the value of DRCTL, the register
controlling the SPI_READY handling. Note that to enable the DRCTL consideration,
the SPI_READY mode-flag needs to be set too.
Valid values are: 0 (disabled), 1 (edge-triggered burst) and 2 (level-triggered burst).
However, that only lists the chipselect GPIO (which worked just fine) but makes no mention of how to supply the other pins necessary to do anything. The driver code doesn't call of_property_* directly that I've seen thus far. spi.c calls it to get a couple different properties but those are just CPOL/CPHA, register, etc.

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?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Look for duplicates in folder tree A and folder tree B, then delete the duplicates only from A. grumpyskeptic Linux - Software 7 10-27-2018 10:23 PM
what is the difference strict binary tree nad extended binary tree . tushar_pandey Programming 1 07-18-2012 11:30 AM
About use FIQ for SPI slave in device driver. jason222333 Linux - Kernel 4 10-25-2010 02:37 PM
the bible = the tree of the knowledge of good and evil () Jesus = the tree of life Michael111 General 2 04-14-2004 04:28 PM
need a P-Tree (Patricia Tree) library manaskb Programming 1 11-02-2002 06:15 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer

All times are GMT -5. The time now is 03:55 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration