How to correctly use spi_slave_tegra

Hi,

I'm working on the SPI bus on a Nvidia Tegra 2 system (Toradex Colibri). I'm using kernel 2.6.32 with toradex and nvidia patches.

I need to use one of the Tegra SPI controller in Slave mode. I know that the Linux kernel does not support the Slave mode for SPI controllers, but I see the drivers/spi/spi_slave_tegra.c driver which is not documented and it is not commented, also the author name is missing. The only information available is the Nvidia Copyright 2011.

Toradex does not tested the spi_slave_tegra and cannot provides an example of driver which use the spi_slave_tegra.

I read the code and I see that spi_slave_tegra use the SPI framework also if the SPI framework supports only master controller.

Anyone ever use the spi_slave_tegra? It works? Can you provide an example?

As I understand:
- obviously I must configure SPI before master start communication
- speed_hz must be the same of the master
- I must use spi_async (spi_sync can freeze the driver)
- Only messages with single transfer. If the master sends messages with multiple transfer, I must receive them with a single transfer
- I have two callback. the message->complete from the SPI framework and the spi_tegra_register_callback from the spi_slave_tegra

Quoted 4 lines · Federico Vaga

Hi,

I'm working on the SPI bus on a Nvidia Tegra 2 system (Toradex Colibri). I'm using kernel 2.6.32 with toradex and nvidia patches.

Laxman, are you able to help with these questions?

Quoted 8 lines

As I understand:
- obviously I must configure SPI before master start communication
- speed_hz must be the same of the master
- I must use spi_async (spi_sync can freeze the driver)
- Only messages with single transfer. If the master sends messages with multiple transfer, I must receive them with a single transfer
- I have two callback. the message->complete from the SPI framework and the spi_tegra_register_callback from the spi_slave_tegra

From a very very very brief look at ouor android-tegra-nv-3.1 branch,
your understanding sounds at least reasonable even if not correct!

Quoted 6 lines

Quoted 4 lines

Hi,

I'm working on the SPI bus on a Nvidia Tegra 2 system (Toradex Colibri). I'm using kernel 2.6.32 with toradex and nvidia patches.

Laxman, are you able to help with these questions?

We have the driver from K2.6.39, K3.1 and K3.4.
I suggest to use the driver from k2.6.39 rather than K2.3.36 version.

Quoted 12 lines

Quoted 10 lines

As I understand:
- obviously I must configure SPI before master start communication
- speed_hz must be the same of the master
- I must use spi_async (spi_sync can freeze the driver)
- Only messages with single transfer. If the master sends messages with multiple transfer, I must receive them with a single transfer
- I have two callback. the message->complete from the SPI framework and the
spi_tegra_register_callback from the spi_slave_tegra

From a very very very brief look at ouor android-tegra-nv-3.1 branch,

Quoted 1 line

your understanding sounds at least reasonable even if not correct!

Yes, the above are correct. The way we wrote the driver is that to support the sync and async both.
When driver configures spi controller and ready for receive data then the callback from client is called. This callback is registered through spi_tegra_register_callback(). The client code then can inform master in this callback to start transfer through some mechanism i.e. gpio

Yes, the above are correct. The way we wrote the driver is that to support the sync and async both.
When driver configures spi controller and ready for receive data then the callback from client is called. This callback is registered through spi_tegra_register_callback(). The client code then can inform master in this callback to start transfer through some mechanism i.e. gpio.

Quoted 6 lines

Yes, the above are correct. The way we wrote the driver is that to support the sync and async both.
When driver configures spi controller and ready for receive data then the callback from client is called. This callback is registered through spi_tegra_register_callback(). The client code then can inform master in this callback to start transfer through some mechanism i.e. gpio.

One more question.
From the Tegra 2 Manual, SPI slave section, I read (I cannot copy it because
of DRM and Nvidia legal stuff) that the clock signal *must* has 1 cycle delay between each word (or packet in packet mode); but I don't read from the master section that the master controller provide 1 cycle delay between each word (or packet). If I connect a Tegra 2 SPI Master with a Tegra 2 SPI slave .... it works?

Aah, it is something written incorrectly. We had internal discussion to remove this statement from TRM already. Please ignore the 1 cycle delay statement.

That's a very old kernel. I doubt anyone really remembers much about the NVIDIA custom code we applied to it. Are you sure you have 2.6.32 anyway; the only copy of NVIDIA's 2.6.32-based kernel I have doesn't include the Tegra SPI slave driver as far as I can tell.

I'd recommend at least upgrading to the most recent NVIDIA downstream kernel so that people still remember the code.

I should recommend switching to an upstream kernel, but we don't have any SPI slave driver there at all, nor yet Colibri support, so that wouldn't be much use, unless you want to upstream the support yourself...

Quoted 9 lines

As I understand:
- obviously I must configure SPI before master start communication
- speed_hz must be the same of the master
- I must use spi_async (spi_sync can freeze the driver)
- Only messages with single transfer. If the master sends messages with multiple transfer, I must receive them with a single transfer
- I have two callback. the message->complete from the SPI framework and the
spi_tegra_register_callback from the spi_slave_tegra

From a very very very brief look at ouor android-tegra-nv-3.1 branch, your understanding sounds at least reasonable even if not correct!