Re: How to define an I2C-to-SPI bridge device ?
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. ___ 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 ?
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 = 420, },
{ .bus_num = 0,
.chip_select = 1,
.max_speed_hz = 420, },
{ .bus_num = 1,
.chip_select = 0,
.max_speed_hz = 420, },
.
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
___
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, 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 = 420, },
{ .bus_num = 0,
.chip_select = 1,
.max_speed_hz = 420, },
{ .bus_num = 1,
.chip_select = 0,
.max_speed_hz = 420, },
.
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
___
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, 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 ___ 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 ?
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. ___ 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 ?
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 lng 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. ___ 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, [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 lng 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 ___ 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 ?
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: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ 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 ?
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. ___ 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 ?
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: i...@80001000 {
compatible = blah;
#address-cells = 1;
#size-cells = 0;
spi-bus: s...@28{
compatible = nxp,sc18is602;
#address-cells = 1;
#size-cells = 0x28;
reg = 0;
spi-dev...@0 {
compatible = blah;
reg = 0;
};
spi-dev...@1 {
compatible = blah;
reg = 1;
};
spi-dev...@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.schw...@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
___
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 ?
Andre Schwarz andre.schw...@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-dev...@0 {
};
spi-dev...@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.
___
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 ?
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-dev...@0 {
};
spi-dev...@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
___
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 ?
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-dev...@0 {
};
spi-dev...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
How to define an I2C-to-SPI bridge device ?
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.schw...@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 ?
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-dev...@0 {
};
spi-dev...@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: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
