Single SPI Protocol Driver with multiple SPI Slaves

Single SPI Protocol Driver with multiple SPI Slaves

[Léo Serre]

Hello,

I have written three SPI drivers for BMX055 sensor (accelerometer + 
gyroscope + magnetometer). It appears that in that case, it was perfect 
to write three different drivers as the different components were 
independants.

I'm now working on a driver for MRF89XA (Microchip's radio chip) that is 
composed of two SPI slaves (one for config and one for data). The device 
is attached to the driver using a Device Tree.

Is that possible to write a single driver, that works with a pair of SPI 
slaves?

Regards,

Léo Serre
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Single SPI Protocol Driver with multiple SPI Slaves

[Lars-Peter Clausen]

On 09/05/2017 11:13 AM, Léo Serre wrote:
> Hello,
> 
> I have written three SPI drivers for BMX055 sensor (accelerometer +
> gyroscope + magnetometer). It appears that in that case, it was perfect to
> write three different drivers as the different components were independants.
> 
> I'm now working on a driver for MRF89XA (Microchip's radio chip) that is
> composed of two SPI slaves (one for config and one for data). The device is
> attached to the driver using a Device Tree.
> 
> Is that possible to write a single driver, that works with a pair of SPI
> slaves?

There are currently no facilities in the kernel to do this. I've have had a
similar problem with a different driver and given this some thought.

Conceptually I think the best approach is to have something like
i2c_new_dummy() that creates a second slave device with a different address
for an existing device.

The main issue with implementing this is the global spi_add_lock mutex which
prevents a SPI device from being created from within the probe() callback of
another SPI device.

The lock is used to prevent two SPI devices with the same chip-select being
registered on the same master concurrently and overwriting each others
configuration.

One way to remove the need for the lock could be to use a per master atomic
bitmap that keeps track of the chip-selects that are in use. But this would
require some additional memory in the spi_master struct.

- Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Single SPI Protocol Driver with multiple SPI Slaves

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Wed, Sep 06, 2017 at 01:49:25PM +0200, Lars-Peter Clausen wrote:

> There are currently no facilities in the kernel to do this. I've have had a
> similar problem with a different driver and given this some thought.

The kernel really can't cope with this at all, it's got a fairly clear
idea that a device will only have one control bus.

> Conceptually I think the best approach is to have something like
> i2c_new_dummy() that creates a second slave device with a different address
> for an existing device.

> The main issue with implementing this is the global spi_add_lock mutex which
> prevents a SPI device from being created from within the probe() callback of
> another SPI device.

There's also the devices that want to use multiple buses simultaneously
that cause problems here, it's not just SPI vs SPI - there's one audio
CODEC upstream that's got mixed I2C and SPI control.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Single SPI Protocol Driver with multiple SPI Slaves

[Léo Serre]

Thanks for your answers,

It appears that the solution is to bind the driver to a unique SPI slave 
in the device-tree using a fake CS pin.

Then in the probe function, assign two GPIO pins to the control the two 
CS of the device.

I'm sure that solution will work but:
  * The driver will be written specifically to a configuration (GPIO pin 
number hard-coded)
  * Requires a unused pin (the fake CS pin, except if it is possible to 
setup the SPI bus as "no-cs" in the device-tree).
  * Requires do find the GPIO pin number, that could be quite difficult 
in iMX6 for example.

Léo

Le 06/09/2017 à 15:09, Mark Brown a écrit :
> On Wed, Sep 06, 2017 at 01:49:25PM +0200, Lars-Peter Clausen wrote:
> 
>> There are currently no facilities in the kernel to do this. I've have had a
>> similar problem with a different driver and given this some thought.
> 
> The kernel really can't cope with this at all, it's got a fairly clear
> idea that a device will only have one control bus.
> 
>> Conceptually I think the best approach is to have something like
>> i2c_new_dummy() that creates a second slave device with a different address
>> for an existing device.
> 
>> The main issue with implementing this is the global spi_add_lock mutex which
>> prevents a SPI device from being created from within the probe() callback of
>> another SPI device.
> 
> There's also the devices that want to use multiple buses simultaneously
> that cause problems here, it's not just SPI vs SPI - there's one audio
> CODEC upstream that's got mixed I2C and SPI control.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Single SPI Protocol Driver with multiple SPI Slaves

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

On Thu, Sep 07, 2017 at 09:03:59AM +0200, Léo Serre wrote:
> Thanks for your answers,

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> It appears that the solution is to bind the driver to a unique SPI slave in
> the device-tree using a fake CS pin.

> Then in the probe function, assign two GPIO pins to the control the two CS
> of the device.

> I'm sure that solution will work but:
>  * The driver will be written specifically to a configuration (GPIO pin
> number hard-coded)
>  * Requires a unused pin (the fake CS pin, except if it is possible to setup
> the SPI bus as "no-cs" in the device-tree).
>  * Requires do find the GPIO pin number, that could be quite difficult in
> iMX6 for example.

That's going into an ABI so will be difficult to support in future if we
ever do get direct support for this.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]