How to correctly use spi_slave_tegra

How to correctly use spi_slave_tegra

[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.

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

Any suggestions, comments, opinions are welcome.

Thank you for your help.

-- 
Federico Vaga

Re: How to correctly use spi_slave_tegra

[Stephen Warren]

On 11/13/2012 01:08 PM, Federico Vaga wrote:
> 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?

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...

> 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

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!

Re: How to correctly use spi_slave_tegra

[Laxman Dewangan]

On 11/15/2012 01:47 PM, Stephen Warren wrote:
> On 11/13/2012 01:08 PM, Federico Vaga wrote:
>> 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.

>> 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!
>

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.

Re: How to correctly use spi_slave_tegra

[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?
> 
> 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.

I checked again. I copied the wrong version, I'm on 2.6.36.2. I wrongly 
replaced the 6 with the last 2: sorry :/

> >> 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!
> 
> 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

ok

-- 
Federico Vaga

Re: How to correctly use spi_slave_tegra

[Federico Vaga]

> 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?

Thank you

-- 
Federico Vaga

Re: How to correctly use spi_slave_tegra

[Laxman Dewangan]

On 11/15/2012 02:41 PM, Federico Vaga wrote:
>> 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.

Re: How to correctly use spi_slave_tegra

[Federico Vaga]

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

Thank you, this is a great news :)

-- 
Federico Vaga

Re: How to correctly use spi_slave_tegra

[Federico Vaga]

> 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.

Probably we can work with 3.1. But the question it is the same because both 
spi_slave_tegra drivers have few difference

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

Assuming that spi_slave_tegra is working perfectly. Nobody developed something 
with it?

> 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...

I think that it is not acceptable for upstream because spi_slave_tegra is 
using the SPI framework in the "wrong" way, because the SPI framework support 
only master controller. We should think about extending the SPI framework for 
slave support (maybe it is an easy job, I don't know). But if it is an 
unwanted features it could be an useless work. We want to use (try) the 
controller in the slave mode due to special condition on our hardware. If we 
can use the master mode we are happier :)

> > 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!

I will update you when I can test on hardware

-- 
Federico Vaga