Re: How to define an I2C-to-SPI bridge device ?
From: Andre Schwarz <hidden>
Date: 2011-03-29 16:27:31
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é
quoted
quoted
quoted
we're about to get new MPC8377 based hardware with various peripherals.quoted
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 ?quoted
quoted
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