SPIDEV problem

[jrlitzenberger]

All,

SPIDEV PROBLEM, MUST SOLVE

I have been battling the wandboard quad C1 with kernel version 3.17.2-armv7-x3, Ubuntu 14.04 LTS, and u-boot 2014.07 dirty.  Successfully, I can rebuild the kernel with changes to the imx6qdl-wandboard.dtsi for enabling peripherial access to /dev/...  I can access spidev0.0 right now.  I also have captured some interesting waveforms:

First waveform is spi bus spidev1.0 running on the beaglebone black rev B with kernel version 3.8.13-bone30, Ubuntu 13.10, and whatever U-boot that came with armhf image.  I cannot paste a picture of the waveform apparently, but what I can say it that the spi bus acts accordingly.  I send three bytes (address, data[0], data[1]).  Chip select stays low for the entire duration of the transaction. 

Second waveform is spi bus spidev0.0 running on the wandboard that i described earlier.  With the same exact code, asside from the spidev change, I get incorrect results.  I send the exact same three bytes like I did with the beaglebone black, but what I have lacked to capture over the past few days, is the chip select line.  For every byte that goes across the spi bus, the chip select line goes low then back high.  Just to make it clear, if I send a three byte transaction across the spi bus, I would expect the chip select line to stay low for the entire transaction.  However, that is not the case.  The spi bus chip select line toggles in between each byte that is sent across the bus.  Obviously, this makes it impossible to talk to any spi device and also puts my development process in a screeching halt status. 

I have put countless hours into understanding the kernel and build process just to wiggle some spi lines.  I need guidance for solving this problem.  Below are the changes I made to imx6qdl-wandboard.dtsi

&ecspi1 {
fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio2 30 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
status = "okay";

spidev@1 {
spi-max-frequency = <24000000>;
reg = <0>;
compatible = "spidev";
};
};

AND IN IOMUX SECTION...

pinctrl_ecspi1: ecspi1grp {
fsl,pins = <
MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
MX6QDL_PAD_EIM_EB2__ECSPI1_SS0 0x000b1 /* CS0 */
>;
};

If I were a betting man, I would say this is kernel driver issue.  It seems like the big boys need to get involved in order to address this issue.  Since I do not have anything better to do until I get a response, I am going to go ahead and try a different kernel build and see if I can validate my assumption.

Thanks,

John L.

[fabio_estevam]

First you say:

cs-gpios = <&gpio2 30 0>;

So this means that GPIO2_30 will be used as the chip select.

but in the IOMUX settings you define:

MX6QDL_PAD_EIM_EB2__ECSPI1_SS0 0x000b1 /* CS0 */

You should use the GPIO as chip select instead of the native chip select of the port.

[fabio_estevam]

Try this:

MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0xb0b0 /* CS0 */

[jrlitzenberger]

Fabio,

Thank you for you response.  I will try your suggestion.  Real quick just for clarification, all other bit wise values have been 0xXXXXX, in saying that is 0xb0b0 the actual desired number or is this typo?  Also, can you direct me to the documentation that states what the bit wise values actually do as far as configuring the GPIO? 

I will post here in the next hour my results with your current suggestion. 

Thanks,

John L.

[fabio_estevam]

John,

Look at the register IOMUXC_SW_PAD_CTL_PAD_EIM_EB2_B in the Reference Manual.

The reset value is 0xb0b0. It is OK to use the reset value for a GPIO functionality.

[jrlitzenberger]

Fabio,

Following up on your original post, I was able to get the spi bus to communicate with the device I was intending to talk to. I have one issue that I would like to understand.  After capturing my waveform on my scope, I can see a considerable amount of time between chip select going low, data, and chip select going high.  in some instances almost double the amount of time necessary.  When I was using the spi bus configured as SS0 I did not see any delay at all with the chip select.  So again, documentation on gpio configuration for spi bus and some incite into why I am seeing what I'm seeing would be much appreciated. 

Thanks,

John

[fabio_estevam]

John,

Glad to know you got it working. Please mark this thread answered, by the way.

I don't have an insight as to the extra delay you are seeing, sorry.