SPIDEV not available on top of LS interface SPI2

hello,

I’m trying to enable spidev on top of @SPI2 (spi@888000) adding spidev@0 node on the device tree, but I cannot see /dev/spidevx.x after loading spidev module with CONFIG_SPIDEV=y or =m.

Any help please ?

Thanks.

What changes did you make and do they show up with the following command?
find /sys/firmware/devicetree/base/soc@0/geniqup@8c0000/spi@888000/

Hello @danielt ,

Yes I can see created nods in the path.
Following are the modifications I made:
compatible = “qcom,geni-spi”,“spidev”;
reg = <0 0x00888000 0 0x4000>;
clock-names = “se”;
clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
pinctrl-names = “default”;
pinctrl-0 = <&qup_spi2_default>;
interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
interconnects = <&aggre1_noc MASTER_QUP_1 0 &config_noc SLAVE_BLSP_1 0>,
<&gladiator_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_BLSP_1 0>;
interconnect-names = “qup-core”, “qup-config”;
spidev@0 {
compatible = “spidev”;
spi-max-frequency = <5000000>;
reg = <0>;
};

Hi @danielt ,

I find it surprising to not be able to have spidev up and running …
It’s a classic method that I’m using and still no results.

I noticed that if I do it manually, it’s working and I have /dev/spiX.Y :
echo spidev > /sys/bus/spi/devices/spiX.Y/driver_override
echo spiX.Y > /sys/bus/spi/drivers/spidev/bind

but it’s not what I want as it is not persistent and my goal is to have it active all the time on boot also.

Is there any hints ? Or is it a limitation on the board itself ?

I can’t see any way this would be a problem with the board, although it could be a result of newer kernel versions. Although it is a “classic method”, for the last three years the spidev driver has been issuing boot messages telling people not to do it (you should see a register dump headed “buggy DT: spidev listed directly in DT”).

I guess it is possible one of the recent changes to spidev has prevented this technique from working. In particular there’s a patch introduce in v5.15 that looks like it alters the way spidev devices are bound.

@danielt
I agree that I have this message and I fixed it by adding .compatible = “spidev” in the list but still I have the problem.
Thanks you for the clarification, do you have any hint on the way I can fixe it ?
I’m pushing the Android AOSP version in the board for my configuration.

Edit:

Alright, I found it! :slight_smile:
I had to add both {.compatible = “spidev”}, in spidev_dt_ids
and {.name = “spidev”}, in the spidev_spi_ids in spidev.c

Whithout it it is not working and the spi master is not able to load spidev correctly.

For the DT:
compatible = “qcom,geni-spi”;
reg = <0 0x00888000 0 0x4000>;
clock-names = “se”;
clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
pinctrl-names = “default”;
pinctrl-0 = <&qup_spi2_default>;
interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
interconnects = <&aggre1_noc MASTER_QUP_1 0 &config_noc SLAVE_BLSP_1 0>,
<&gladiator_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_BLSP_1 0>;
interconnect-names = “qup-core”, “qup-config”;
spidev@0 {
compatible = “spidev”;
spi-max-frequency = <5000000>;
reg = <0>;
};
Thanks

Great to hear. You are running v5.10 or v5.15?

It’s v 5.15 :slight_smile:
I will check if the signals are ok now, but at least I have my /dev/spidev2.0

Hello @danielt

I’m trying to communicate over SPI0 on LS1 interface as explained, but now I see that MISO line is always pulled down when SPI is active.
all the other lines are ok as I see data on them but not MISO.

I also tried to test spidev by doing the loop-back method, and here I see that MOSI line too is set to zero which means MISO is pulling it down.

Any idea on this? I checked pinctrl files but looks complexe to put hands in it.

Thanks

Not really… the spidev stuff is generic for all Linux systems but the pull-up/down on the pins are board specific and I have never tried out SPI on this board.

To be honest pretty much any pull down on MISO sounds broken to me: assuming you have no hardware connected to the RB3 then MISO should be HiZ. Things can get a bit confused if you have level shifters in the circuit (especially if those level shifters have long cables) but if you are just reading the voltage level on the MISO pin on the LS connecter then I’d expect even a 1Mohm resister to 1v8 or GND to be able to change the value observed on the pin.