How to define an I2C-to-SPI bridge device ?

How to define an I2C-to-SPI bridge device ?

[André Schwarz]

Hi,

we're about to get new MPC8377 based hardware with various peripherals.
There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
how to define a proper dts...

Of course it's an easy thing creating 2 child nodes on the CPU's I2C
device - but how can I represent the created SPI bus ?

Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
I2C slave or an SPI host driver ?


Any help is welcome.


-- 
Mit freundlichen Grüßen / Best regards

André Schwarz

___________________________________________

MATRIX VISION GmbH
- Entwicklung / Development -
Talstraße 16
D-71570 Oppenweiler

Fon: ++49-07191-9432-420
Fax: ++49-07191-9432-288
eMail: andre.schwarz@matrix-vision.de
web: www.matrix-vision.de


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich

Re: How to define an I2C-to-SPI bridge device ?

[Anton Vorontsov]

On Fri, Sep 03, 2010 at 10:36:19AM +0200, André Schwarz wrote:
> Hi,
> 
> we're about to get new MPC8377 based hardware with various peripherals.
> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
> how to define a proper dts...
> 
> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
> device - but how can I represent the created SPI bus ?

Um.. the same as the other SPI buses? I.e.

i2c-controller {  /* SOC I2C controller */
	spi-controller {  /* The I2C-to-SPI bridge */
		spi-device@0 {
		};
		spi-device@1 {
		};
	};
};

> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
> I2C slave or an SPI host driver ?

It should be an I2C driver that registers an SPI master (i.e.
calls spi_alloc_master() and spi_register_master()).

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: How to define an I2C-to-SPI bridge device ?

[Andre Schwarz]

  Anton,

> we're about to get new MPC8377 based hardware with various peripherals.
>> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
>> how to define a proper dts...
>>
>> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
>> device - but how can I represent the created SPI bus ?
> Um.. the same as the other SPI buses? I.e.
>
> i2c-controller {  /* SOC I2C controller */
> 	spi-controller {  /* The I2C-to-SPI bridge */
> 		spi-device@0 {
> 		};
> 		spi-device@1 {
> 		};
> 	};
> };
>
ok , thanks - looks straight forward.
Is this any more than plain definition, i.e. will this trigger any I2C 
or SPI device registration/linking ?
>> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
>> I2C slave or an SPI host driver ?
> It should be an I2C driver that registers an SPI master (i.e.
> calls spi_alloc_master() and spi_register_master()).
hmm - ok. Will have to do it manually then ...

I still wonder how to make the driver arch-generic *and* of-capable.
Do we need a generic I2C slave driver that can be probed along with an 
"of glue driver" or should the of-binding be part of a single device 
driver ?

Sorry for the dumb questions - looks like I expected a little too much 
functionality already existing.


Regards,
André


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich

Re: How to define an I2C-to-SPI bridge device ?

[André Schwarz]

Anton,

looks like I should have looked at include/spi/spi.h earlier :

/*
 * INTERFACES between SPI master-side drivers and SPI infrastructure.
 * (There's no SPI slave support for Linux yet...)
 */

...this is what I've been looking for.


thanks for your help and sorry for the noise.


Regards,
André





On Mon, 2010-09-06 at 13:40 +0200, Andre Schwarz wrote:
> Anton,
> 
> > we're about to get new MPC8377 based hardware with various peripherals.
> >> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
> >> how to define a proper dts...
> >>
> >> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
> >> device - but how can I represent the created SPI bus ?
> > Um.. the same as the other SPI buses? I.e.
> >
> > i2c-controller {  /* SOC I2C controller */
> > 	spi-controller {  /* The I2C-to-SPI bridge */
> > 		spi-device@0 {
> > 		};
> > 		spi-device@1 {
> > 		};
> > 	};
> > };
> >
> ok , thanks - looks straight forward.
> Is this any more than plain definition, i.e. will this trigger any I2C 
> or SPI device registration/linking ?
> >> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
> >> I2C slave or an SPI host driver ?
> > It should be an I2C driver that registers an SPI master (i.e.
> > calls spi_alloc_master() and spi_register_master()).
> hmm - ok. Will have to do it manually then ...
> 
> I still wonder how to make the driver arch-generic *and* of-capable.
> Do we need a generic I2C slave driver that can be probed along with an 
> "of glue driver" or should the of-binding be part of a single device 
> driver ?
> 
> Sorry for the dumb questions - looks like I expected a little too much 
> functionality already existing.
> 
> 
> Regards,
> André
> 




MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich

Re: How to define an I2C-to-SPI bridge device ?

[Grant Likely]

On Fri, Sep 03, 2010 at 10:36:19AM +0200, André Schwarz wrote:
> Hi,
> 
> we're about to get new MPC8377 based hardware with various peripherals.
> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
> how to define a proper dts...
> 
> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
> device - but how can I represent the created SPI bus ?
> 
> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
> I2C slave or an SPI host driver ?

Both!  The driver would get probed from the i2c bus, and it would
create and register an spi master.  If the spi bus registration
includes a pointer to the device tree node, then the child nodes will
automatically be registered as spi_devices.

The dts is also fairly straight forward:

i2c-bus: i2c@80001000 {
	compatible = <blah>;
	#address-cells = <1>;
	#size-cells = <0>;

	spi-bus: spi@28{
		compatible = "nxp,sc18is602";
		#address-cells = <1>;
		#size-cells = <0x28>;
		reg = <0>;

		spi-device@0 {
			compatible = <blah>;
			reg = <0>;
		};
		spi-device@1 {
			compatible = <blah>;
			reg = <1>;
		};
		spi-device@2 {
			compatible = <blah>;
			reg = <2>;
		};
	};
};

Cheers,
g.

> 
> 
> Any help is welcome.
> 
> 
> -- 
> Mit freundlichen Grüßen / Best regards
> 
> André Schwarz
> 
> ___________________________________________
> 
> MATRIX VISION GmbH
> - Entwicklung / Development -
> Talstraße 16
> D-71570 Oppenweiler
> 
> Fon: ++49-07191-9432-420
> Fax: ++49-07191-9432-288
> eMail: andre.schwarz@matrix-vision.de
> web: www.matrix-vision.de
> 
> 
> MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
> Registergericht: Amtsgericht Stuttgart, HRB 271090
> Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: How to define an I2C-to-SPI bridge device ?

[Grant Likely]

"Andre Schwarz" <andre.schwarz@matrix-vision.de> wrote:

>  Anton,
>
>> we're about to get new MPC8377 based hardware with various peripherals.
>>> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
>>> how to define a proper dts...
>>>
>>> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
>>> device - but how can I represent the created SPI bus ?
>> Um.. the same as the other SPI buses? I.e.
>>
>> i2c-controller {  /* SOC I2C controller */
>> 	spi-controller {  /* The I2C-to-SPI bridge */
>> 		spi-device@0 {
>> 		};
>> 		spi-device@1 {
>> 		};
>> 	};
>> };
>>
>ok , thanks - looks straight forward.
>Is this any more than plain definition, i.e. will this trigger any I2C 
>or SPI device registration/linking ?
>>> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
>>> I2C slave or an SPI host driver ?
>> It should be an I2C driver that registers an SPI master (i.e.
>> calls spi_alloc_master() and spi_register_master()).
>hmm - ok. Will have to do it manually then ...

Yes, but this is the case for non-of drivers too.  The i2c to spi device driver must always create (and trigger population of) the spi bus instance.

>
>I still wonder how to make the driver arch-generic *and* of-capable.
>Do we need a generic I2C slave driver that can be probed along with an 
>"of glue driver" or should the of-binding be part of a single device 
>driver ?

There is no longer any need for separate of and non-of drivers for the same hardware.  Any device may have the of_node pointer in struct device set, and drivers can use the pointer as an alternative to platform_data to get information about the hardware configuration.

Just read the data out of the node in the driver's probe hook.

For i2c and (soon) spi, the core code will even register child devices for you.

g.

>
>Sorry for the dumb questions - looks like I expected a little too much 
>functionality already existing.
>
>
>Regards,
>André
>
>
>MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
>Registergericht: Amtsgericht Stuttgart, HRB 271090
>Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: How to define an I2C-to-SPI bridge device ?

[André Schwarz]

Grant, Anton,


> 
> There is no longer any need for separate of and non-of drivers for the same hardware.  Any device may have the of_node pointer in struct device set, and drivers can use the pointer as an alternative to platform_data to get information about the hardware configuration.

> Just read the data out of the node in the driver's probe hook.

ok - will do it that way.

> 
> For i2c and (soon) spi, the core code will even register child devices for you.

excellent.



Thinking about this device raises even more questions. Since there are
several possible solutions I'd like to hear your opinions :

1.
The SC18IS602 is capable of generating interrupts which is *extremely*
useful triggering on the end of the actual SPI transaction and not the
end of I2C chip access. Since we need an IRQ_ACK over I2C (which takes
loooong with IRQ being still asserted) I'm thinking about using an edge
triggered interrupt.
Since all transactions are in-order there's no risk of missing multiple
edges ... what do you think about this ? Any known issues with edge
triggered IRQs ?


2.
chips select generations is a little tricky.
The device has up to four cs# lines with their assertion being encoded
as subaddr representing a bitfield, i.e. Subaddr 0x01 generates cs0,
0x04 asserts cs3 and 0x07 asserts cs0-2.

At first I thought about registering 4 SPI busses representing the 4 cs#
lines and hide the cs# generation from the user. This would make
multiple cs# assertions for a single write impossible which is a very
useful feature.

Exposing the desired cs# setting for the next transaction via sysfs or
libGPIO requires the user to serialize cs# config and actual SPI
read/write. I also wouldn't know how to properly present the cs# lines
from multiple chips to the user in a clear and unambiguous way.


Any suggestions ?


Regards,
André


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: How to define an I2C-to-SPI bridge device ?

[Grant Likely]

On Fri, Sep 10, 2010 at 10:11:33AM +0200, André Schwarz wrote:
> Grant, Anton,
> 
> 
> > 
> > There is no longer any need for separate of and non-of drivers for the same hardware.  Any device may have the of_node pointer in struct device set, and drivers can use the pointer as an alternative to platform_data to get information about the hardware configuration.
> 
> > Just read the data out of the node in the driver's probe hook.
> 
> ok - will do it that way.
> 
> > 
> > For i2c and (soon) spi, the core code will even register child devices for you.
> 
> excellent.
> 
> 
> 
> Thinking about this device raises even more questions. Since there are
> several possible solutions I'd like to hear your opinions :
> 
> 1.
> The SC18IS602 is capable of generating interrupts which is *extremely*
> useful triggering on the end of the actual SPI transaction and not the
> end of I2C chip access. Since we need an IRQ_ACK over I2C (which takes
> loooong with IRQ being still asserted) I'm thinking about using an edge
> triggered interrupt.
> Since all transactions are in-order there's no risk of missing multiple
> edges ... what do you think about this ? Any known issues with edge
> triggered IRQs ?

Does the device actually generate edge interrupts?  Or is it a level
irq device?  If it is a level irq device, then the correct way to
handle this is to disable the irq line so that the event can be
handled at non-irq context, and then reenable it when finished.

> 2.
> chips select generations is a little tricky.
> The device has up to four cs# lines with their assertion being encoded
> as subaddr representing a bitfield, i.e. Subaddr 0x01 generates cs0,
> 0x04 asserts cs3 and 0x07 asserts cs0-2.

I'm really not sure what is tricky about this.  The spi layer handles
multiple CS lines on a single bus just fine.

To start, how the CS lines are manipulated is only a hardware
implementation detail.  The driver can and should do the work of
translate Linux CS line numbers into the format/bitfield expected by
the hardware.  Other drivers do the same thing.

> At first I thought about registering 4 SPI busses representing the 4 cs#
> lines and hide the cs# generation from the user. This would make
> multiple cs# assertions for a single write impossible which is a very
> useful feature.

The SPI subsystem doesn't directly support this use-case.  If you want
to do this, then assign another chip select number for the purpose of
enabling multiple CS lines at once... and be careful which drivers you
allow to be bound to the oddball CS number.  The in-kernel drivers
certainly don't support this use-case, and care must be taken to
ensure only one device is writing to the input line at a time.

What specific hardware do you need this feature for?

> Exposing the desired cs# setting for the next transaction via sysfs or
> libGPIO requires the user to serialize cs# config and actual SPI
> read/write. I also wouldn't know how to properly present the cs# lines
> from multiple chips to the user in a clear and unambiguous way.

Exposing via sysfs or discrete GPIO manipulations is completely the
wrong thing to do.

g.

Re: How to define an I2C-to-SPI bridge device ?

[André Schwarz]

Grant,

[snip]
> > 
> > 1.
> > The SC18IS602 is capable of generating interrupts which is *extremely*
> > useful triggering on the end of the actual SPI transaction and not the
> > end of I2C chip access. Since we need an IRQ_ACK over I2C (which takes
> > loooong with IRQ being still asserted) I'm thinking about using an edge
> > triggered interrupt.
> > Since all transactions are in-order there's no risk of missing multiple
> > edges ... what do you think about this ? Any known issues with edge
> > triggered IRQs ?
> 
> Does the device actually generate edge interrupts?  Or is it a level
> irq device?  If it is a level irq device, then the correct way to
> handle this is to disable the irq line so that the event can be
> handled at non-irq context, and then reenable it when finished.

The irq is level-low active.
Will do it via disable/re-enable then.

> 
> > 2.
> > chips select generations is a little tricky.
> > The device has up to four cs# lines with their assertion being encoded
> > as subaddr representing a bitfield, i.e. Subaddr 0x01 generates cs0,
> > 0x04 asserts cs3 and 0x07 asserts cs0-2.
> 
> I'm really not sure what is tricky about this.  The spi layer handles
> multiple CS lines on a single bus just fine.

huh - ok ... didn't know that, sorry.

> 
> To start, how the CS lines are manipulated is only a hardware
> implementation detail.  The driver can and should do the work of
> translate Linux CS line numbers into the format/bitfield expected by
> the hardware.  Other drivers do the same thing.

ok - will do it.

> 
> > At first I thought about registering 4 SPI busses representing the 4 cs#
> > lines and hide the cs# generation from the user. This would make
> > multiple cs# assertions for a single write impossible which is a very
> > useful feature.
> 
> The SPI subsystem doesn't directly support this use-case.  If you want
> to do this, then assign another chip select number for the purpose of
> enabling multiple CS lines at once... and be careful which drivers you
> allow to be bound to the oddball CS number.  The in-kernel drivers
> certainly don't support this use-case, and care must be taken to
> ensure only one device is writing to the input line at a time.
> 
> What specific hardware do you need this feature for?

We have a board with multiple parallel video transmitters connected to
an FPGA. Video timing and general parameters are always the same and
there are quite a lot of settings to write during init/mode change.

Doing this in parallel will speed things up significantly.

Of course this is a write-only scenario, i.e. no combined reads.

> 
> > Exposing the desired cs# setting for the next transaction via sysfs or
> > libGPIO requires the user to serialize cs# config and actual SPI
> > read/write. I also wouldn't know how to properly present the cs# lines
> > from multiple chips to the user in a clear and unambiguous way.
> 
> Exposing via sysfs or discrete GPIO manipulations is completely the
> wrong thing to do.

Thanks for pointing this out.


BTW: would "drivers/misc" be a proper location ?
Who's supposed to pick that driver up and on what list shall I post it
for review ?


Will try to get more spi knowledge before moving on and asking stupid
questions. Thanks for your help so far.


Regards,
André



MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: How to define an I2C-to-SPI bridge device ?

[Anton Vorontsov]

On Fri, Sep 10, 2010 at 08:14:44PM +0200, André Schwarz wrote:
[...]
> > Does the device actually generate edge interrupts?  Or is it a level
> > irq device?  If it is a level irq device, then the correct way to
> > handle this is to disable the irq line so that the event can be
> > handled at non-irq context, and then reenable it when finished.
> 
> The irq is level-low active.
> Will do it via disable/re-enable then.

FYI, In newer kernels you don't have to do it manually, there's
request_threaded_irq() for this.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: How to define an I2C-to-SPI bridge device ?

[Grant Likely]

On Fri, Sep 10, 2010 at 08:14:44PM +0200, André Schwarz wrote:
> > > At first I thought about registering 4 SPI busses representing the 4 cs#
> > > lines and hide the cs# generation from the user. This would make
> > > multiple cs# assertions for a single write impossible which is a very
> > > useful feature.
> > 
> > The SPI subsystem doesn't directly support this use-case.  If you want
> > to do this, then assign another chip select number for the purpose of
> > enabling multiple CS lines at once... and be careful which drivers you
> > allow to be bound to the oddball CS number.  The in-kernel drivers
> > certainly don't support this use-case, and care must be taken to
> > ensure only one device is writing to the input line at a time.
> > 
> > What specific hardware do you need this feature for?
> 
> We have a board with multiple parallel video transmitters connected to
> an FPGA. Video timing and general parameters are always the same and
> there are quite a lot of settings to write during init/mode change.
> 
> Doing this in parallel will speed things up significantly.

Yeah; Then I would handle it as a separate cs# and map it to enabling
multiple CS lines at a time.

> BTW: would "drivers/misc" be a proper location ?
> Who's supposed to pick that driver up and on what list shall I post it
> for review ?

You should cc spi-devel-general, and feel free to cc me.  drivers/misc
would probably be an okay place for it to live; but if it only appears
on a single machine, then it may make more sense in
arch/*/<board-directory>.  What arch or SoC is this running on?

g.

Re: How to define an I2C-to-SPI bridge device ?

[André Schwarz]

Grant, Anton,

[snip]

> > 
> > Doing this in parallel will speed things up significantly.
> 
> Yeah; Then I would handle it as a separate cs# and map it to enabling
> multiple CS lines at a time.

sounds reasonable - will do it that way.

> 
> > BTW: would "drivers/misc" be a proper location ?
> > Who's supposed to pick that driver up and on what list shall I post it
> > for review ?
> 
> You should cc spi-devel-general, and feel free to cc me.  drivers/misc
> would probably be an okay place for it to live; but if it only appears
> on a single machine, then it may make more sense in
> arch/*/<board-directory>.  What arch or SoC is this running on?


ok - currently I'm preparing bring up of a MPC8377 based system.
But we have this chips on multiple boards and also on generic PCIe
grabber cards running on any desktop PC.

Since we could use the driver directly after registering the various I2C
masters I'd prefer to go with drivers/misc. After all it's a simple I2C
slave device usable by anyone ...


Will send an initial patch for review after basic verification with real
hardware.


Thanks for your help.

Cheers,
André




MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: How to define an I2C-to-SPI bridge device ?

[Grant Likely]

On Sun, Sep 12, 2010 at 05:10:35PM +0200, André Schwarz wrote:
> > > BTW: would "drivers/misc" be a proper location ?
> > > Who's supposed to pick that driver up and on what list shall I post it
> > > for review ?
> > 
> > You should cc spi-devel-general, and feel free to cc me.  drivers/misc
> > would probably be an okay place for it to live; but if it only appears
> > on a single machine, then it may make more sense in
> > arch/*/<board-directory>.  What arch or SoC is this running on?
> 
> ok - currently I'm preparing bring up of a MPC8377 based system.
> But we have this chips on multiple boards and also on generic PCIe
> grabber cards running on any desktop PC.
> 
> Since we could use the driver directly after registering the various I2C
> masters I'd prefer to go with drivers/misc. After all it's a simple I2C
> slave device usable by anyone ...

If it is a video capture device, then wouldn't drivers/video
or drivers/media make sense?  Search for "MEDIA INPUT" in the
MAINTAINERS file.

g.

Re: How to define an I2C-to-SPI bridge device ?

[Andre Schwarz]

Grant, Anton,

>>> we're about to get new MPC8377 based hardware with various peripherals.
>>>> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
>>>> how to define a proper dts...
>>>>
>>>> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
>>>> device - but how can I represent the created SPI bus ?
>>> Um.. the same as the other SPI buses? I.e.
>>>
>>> i2c-controller {  /* SOC I2C controller */
>>> 	spi-controller {  /* The I2C-to-SPI bridge */
>>> 		spi-device@0 {
>>> 		};
>>> 		spi-device@1 {
>>> 		};
>>> 	};
>>> };
>>>
>> ok , thanks - looks straight forward.
>> Is this any more than plain definition, i.e. will this trigger any I2C
>> or SPI device registration/linking ?
>>>> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
>>>> I2C slave or an SPI host driver ?
>>> It should be an I2C driver that registers an SPI master (i.e.
>>> calls spi_alloc_master() and spi_register_master()).
>> hmm - ok. Will have to do it manually then ...
> Yes, but this is the case for non-of drivers too.  The i2c to spi device driver must always create (and trigger population of) the spi bus instance.
>

I've kicked that I2C-to-SPI stuff completely because it's been too slow.
We've connected the SPI busses to the FPGA controlling almost everything 
now.

Unfortunately there are some questions left :

Following Anton's suggestion I've had a look at /drivers/mfd (sm501.c) 
and implemented a pci driver for the FPGA using
subdevices for additional functionality it exports - besides others we 
now have 2 SPI masters.

For both SPI masters I have created and registered a platform_device.
pdev->dev is then fed into spi_alloc_master() and the resulting master 
goes into spi_register_master().

master->bus_num is set to 0 and 1, i.e. no dynamic numbering.
master->chipselect = 8;

Since I can probe the SPI device using FPGA intrinsic information I 
decided to register the client
devices on runtime using a "struct spi_board_info" which is fed into 
spi_new_device().

The current design has 2 clients on SPI-0 and 5 clients on SPI-1.

static struct spi_board_info mergerbox_spi_boardinfo[] = {
         {       .bus_num = 0,
                 .chip_select = 0,
                 .max_speed_hz = 4<<20, },
         {       .bus_num = 0,
                 .chip_select = 1,
                 .max_speed_hz = 4<<20, },
         {       .bus_num = 1,
                 .chip_select = 0,
                 .max_speed_hz = 4<<20, },
.....


After loading my module I get :

#> ls /sys/devices/platform/AlteraSPI.0/
/sys/devices/platform/AlteraSPI.0/modalias
/sys/devices/platform/AlteraSPI.0/spi0.0/
/sys/devices/platform/AlteraSPI.0/spi0.1/
/sys/devices/platform/AlteraSPI.0/spi_master/
/sys/devices/platform/AlteraSPI.0/subsystem/
/sys/devices/platform/AlteraSPI.0/uevent

#> ls /sys/devices/platform/AlteraSPI.1/
/sys/devices/platform/AlteraSPI.1/modalias
/sys/devices/platform/AlteraSPI.1/spi1.0/
/sys/devices/platform/AlteraSPI.1/spi1.1/
/sys/devices/platform/AlteraSPI.1/spi1.2/
/sys/devices/platform/AlteraSPI.1/spi1.3/
/sys/devices/platform/AlteraSPI.1/spi1.4/
/sys/devices/platform/AlteraSPI.1/spi_master/
/sys/devices/platform/AlteraSPI.1/subsystem/
/sys/devices/platform/AlteraSPI.1/uevent

What I'm missing are the /dev/spi* entries.

There's also a spi_mpc8xxx driver using the CPU's SPI controller.
It is configured by dts (2 devices) and uses dynamic bus numbering:

#> ls /sys/bus/spi/devices/
spi0.0      spi1.0      spi1.2      spi1.4      spi32766.1
spi0.1      spi1.1      spi1.3      spi32766.0

This devices are processed by spidev and proper entries are created 
ready for use :

#> ls /dev/spi*
/dev/spidev32766.0  /dev/spidev32766.1


Am I missing somehting obvious ?

Since there's no driver registration we don't have a probe function - is 
this a problem regarding device binding ?

Do I need to use the .modalias in "struct spi_board_info" ?


Any help is welcome.

Regards,
André

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: How to define an I2C-to-SPI bridge device ?

[Andre Schwarz]

On 03/25/2011 10:28 AM, Andre Schwarz wrote:
> Grant, Anton,

got it.
providing modalis = "spidev" within spi_board_info works like a charme ...

Cheers,
André

>
>>>> we're about to get new MPC8377 based hardware with various 
>>>> peripherals.
>>>>> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm 
>>>>> not sure
>>>>> how to define a proper dts...
>>>>>
>>>>> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
>>>>> device - but how can I represent the created SPI bus ?
>>>> Um.. the same as the other SPI buses? I.e.
>>>>
>>>> i2c-controller {  /* SOC I2C controller */
>>>>     spi-controller {  /* The I2C-to-SPI bridge */
>>>>         spi-device@0 {
>>>>         };
>>>>         spi-device@1 {
>>>>         };
>>>>     };
>>>> };
>>>>
>>> ok , thanks - looks straight forward.
>>> Is this any more than plain definition, i.e. will this trigger any I2C
>>> or SPI device registration/linking ?
>>>>> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to 
>>>>> be an
>>>>> I2C slave or an SPI host driver ?
>>>> It should be an I2C driver that registers an SPI master (i.e.
>>>> calls spi_alloc_master() and spi_register_master()).
>>> hmm - ok. Will have to do it manually then ...
>> Yes, but this is the case for non-of drivers too.  The i2c to spi 
>> device driver must always create (and trigger population of) the spi 
>> bus instance.
>>
>
> I've kicked that I2C-to-SPI stuff completely because it's been too slow.
> We've connected the SPI busses to the FPGA controlling almost 
> everything now.
>
> Unfortunately there are some questions left :
>
> Following Anton's suggestion I've had a look at /drivers/mfd (sm501.c) 
> and implemented a pci driver for the FPGA using
> subdevices for additional functionality it exports - besides others we 
> now have 2 SPI masters.
>
> For both SPI masters I have created and registered a platform_device.
> pdev->dev is then fed into spi_alloc_master() and the resulting master 
> goes into spi_register_master().
>
> master->bus_num is set to 0 and 1, i.e. no dynamic numbering.
> master->chipselect = 8;
>
> Since I can probe the SPI device using FPGA intrinsic information I 
> decided to register the client
> devices on runtime using a "struct spi_board_info" which is fed into 
> spi_new_device().
>
> The current design has 2 clients on SPI-0 and 5 clients on SPI-1.
>
> static struct spi_board_info mergerbox_spi_boardinfo[] = {
>         {       .bus_num = 0,
>                 .chip_select = 0,
>                 .max_speed_hz = 4<<20, },
>         {       .bus_num = 0,
>                 .chip_select = 1,
>                 .max_speed_hz = 4<<20, },
>         {       .bus_num = 1,
>                 .chip_select = 0,
>                 .max_speed_hz = 4<<20, },
> .....
>
>
> After loading my module I get :
>
> #> ls /sys/devices/platform/AlteraSPI.0/
> /sys/devices/platform/AlteraSPI.0/modalias
> /sys/devices/platform/AlteraSPI.0/spi0.0/
> /sys/devices/platform/AlteraSPI.0/spi0.1/
> /sys/devices/platform/AlteraSPI.0/spi_master/
> /sys/devices/platform/AlteraSPI.0/subsystem/
> /sys/devices/platform/AlteraSPI.0/uevent
>
> #> ls /sys/devices/platform/AlteraSPI.1/
> /sys/devices/platform/AlteraSPI.1/modalias
> /sys/devices/platform/AlteraSPI.1/spi1.0/
> /sys/devices/platform/AlteraSPI.1/spi1.1/
> /sys/devices/platform/AlteraSPI.1/spi1.2/
> /sys/devices/platform/AlteraSPI.1/spi1.3/
> /sys/devices/platform/AlteraSPI.1/spi1.4/
> /sys/devices/platform/AlteraSPI.1/spi_master/
> /sys/devices/platform/AlteraSPI.1/subsystem/
> /sys/devices/platform/AlteraSPI.1/uevent
>
> What I'm missing are the /dev/spi* entries.
>
> There's also a spi_mpc8xxx driver using the CPU's SPI controller.
> It is configured by dts (2 devices) and uses dynamic bus numbering:
>
> #> ls /sys/bus/spi/devices/
> spi0.0      spi1.0      spi1.2      spi1.4      spi32766.1
> spi0.1      spi1.1      spi1.3      spi32766.0
>
> This devices are processed by spidev and proper entries are created 
> ready for use :
>
> #> ls /dev/spi*
> /dev/spidev32766.0  /dev/spidev32766.1
>
>
> Am I missing somehting obvious ?
>
> Since there's no driver registration we don't have a probe function - 
> is this a problem regarding device binding ?
>
> Do I need to use the .modalias in "struct spi_board_info" ?
>
>
> Any help is welcome.
>
> Regards,
> André


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: How to define an I2C-to-SPI bridge device ?

[Grant Likely]

On Tue, Mar 29, 2011 at 06:21:50PM +0200, Andre Schwarz wrote:
> On 03/25/2011 10:28 AM, Andre Schwarz wrote:
> >Grant, Anton,
> 
> got it.
> providing modalis = "spidev" within spi_board_info works like a charme ...

Good.  Glad you got it sorted out.

g.