sc598, clarification on reg property for spi in dts

Larswad

on Feb 15, 2023

Product Number: sc598

Hi!

We are trying to map a maxim mcp795 RTC device in our device tree. It's on spi1 bus, so far we've added the following with no luck:

&spi1 {
pinctrl-names = "default";
pinctrl-0 = <&spi1_default>;
cs-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
status = "okay";

mcp795: mcp795@0 { /* RTC */
compatible = "maxim,mcp795";
reg = <0>; // SPI1_SEL4 / GPIO_PE02
spi-max-frequency = <1000000>;
status = "okay";
};
};

The chip select (SS) is on pin PE02 and it is supposed active when low. According to datasheet SPI1_SEL4 is multiplexed function 1.

We have added what we feel are the correct selections in our kernel config:

CONFIG_RTC_DRV_MCP795=m
CONFIG_SPI_SPIDEV is not set (this one I assume is only for "generic" spidev functionality e.g. /dev/spidevN.N, but we have a specific peripheral).

When we modprobe we get:

modprobe rtc-mcp795
[ 32.162383] rtc-mcp795 spi1.4: registered as rtc0

But hwclock doesn't seem to communicate with it:

hwclock -s
hwclock: ioctl(RTC_RD_TIME) to /dev/rtc0 to read the time failed: Invalid argument

Now here are my questions, I've seen different explanations of how the reg property should be set, it is the chip select alright, but how is it specified properly?

I can imagine some variations of it:
* The pin number on the gpio port, that would in our case mean PORT E (offset 128) + 2 == 130

* The index into the cs-gpios array (since we have only one it would be 0)

* The SPI1_SELx number (if zero based 3 or if 1 based 4).

Also, should the pinmux configuration for this spi1 configure the chip select with the alternate function1?

e.g.

spi1_default: spi1_default_pins {

pins {

pinmux = <ADI_ADSP_PINMUX('A', 10, ADI_ADSP_PINFUNC_ALT1)>,

<ADI_ADSP_PINMUX('A', 11, ADI_ADSP_PINFUNC_ALT1)>,

<ADI_ADSP_PINMUX('A', 12, ADI_ADSP_PINFUNC_ALT1)>;

<ADI_ADSP_PINMUX('E', 2, ADI_ADSP_PINFUNC_ALT1)>;

};

Now of course there might be other problems as well, but I would be happy and grateful if anyone could shed some light on this.

I happily provide more information if needed.

Lars

0 Prasanth R
on Feb 19, 2023 11:29 PM
Hi Lars,

I don't see anything wrong in the rtc node, I suspect the pinmux might be an issue.

How the pinmux was done and selected the E group? Did you follow any documents on this?

Try to enable CONFIG_SPI_SPIDEV token and check for the /sys/class/(spi/rtc) entries.

Thanks,

Prasanth R
Cancel
Up 0 Down

Reply

Verify Answer

Cancel
0 Larswad
on Feb 22, 2023 9:49 AM in reply to Prasanth R
Hi Prasanth!

And many thanks for checking and answering.

I have come a bit further in this after having analyzed the chip select with an oscilloscope.
Before modprobing the driver the chip select is actually driven high as the spi bus is idling.

Once modprobing the driver the chip select goes into low state and is kept there (which is the wrong state when spi bus is idling, it should be held high as it is supposed to be active low).

When doing the hwclock command we can see during access that the chip select goes high which of course is the inverted behavior, and strange since I explicitly specify GPIO_ACTIVE LOW in cs-gpios.

So I tried a little "trick" by specifying the "spi-cs-high" property which indeed inverts the behavior and after that reads and writes actually seems to work fine.

Regardless, as far as i see it I shouldn't really need to specify the "spi-cs-high" property in the DTS, that is a double inversion of the expected behavior.

Using CONFIG_SPI_SPIDEV (as module and modprobing spidev) makes no functional change. I do get an empty /sys/class/spidev entry, however the /sys/class/spi_master IS properly populated with subnodes, with an spi1.3 entry with the rtc underneath it (which is good).

I compiled the "devmem2" command into the image to be able to easily read out IO registers.
I can with that see that the pinmux (PORT_FER and PORT_MUX) is not setting the gpio for using SPI1 channel 3, it remains configured as a regular gpio.

Note: If I set the pinmux explicitly for the chip select it doesn't work at all, e.g.:

<ADI_ADSP_PINMUX('E', 2, ADI_ADSP_PINFUNC_ALT1)>;

I can in that case see with devmem2 tool that the pinmux appears to be set right (in that case), both PORT_MUX and PORT_FER are correct according to what I expect for pin E/02.

Besides, if I look at the corresponding pinmux configuration for the emmc we use, it doesn't explicitly specify the chip select in the pinmux.

There must still be something I do wrong when I configure the chip select here, alternatively the ADI SPI driver v3 has some problem with configuriing the chip-select alternate function.

Best Regards,

Lars
Cancel
Up 0 Down

Reply

Verify Answer

Cancel