[PATCH 0/3] Support for SPI busses and devices

Yuli Barcohen yuli at arabellasw.com
Mon Jul 25 23:54:55 EST 2005


>>>>> Kate Alhola writes:

    Yuli> SPI is very similar to I2C IMHO. I'm not sure separate
    Yuli> infrastructure is needed. We support SPI on MPC8xx/82xx/85xx
    Yuli> using the standard I2C infrastructure. I only had to add a
    Yuli> couple of IOCTLs to control clock frequency and polarity. Due
    Yuli> to such an implementation, lm-sensors work OK with SPI
    Yuli> temperature sensors, for example.

    Kate> SPI IS wery similar than I2C and for this reason it looks a
    Kate> like that all SPI subsystems implementations are based on I2C
    Kate> code.

    Kate> The Clock frequency and polarity is not enough, as mentioned
    Kate> also then addressing target chip is completelly diferent. It
    Kate> is done with separate PIO lines instead address send in serial
    Kate> line.  The CS handling is also in HW level completelly
    Kate> independent to the srerial line driver but of cource need to
    Kate> me synchronized with it.  This means that there should be
    Kate> logic to handle this CS stuff as addition of serial code.

    Kate> I2C subsystem does not have any kind of support of CS
    Kate> handlinng and for this reason i chosen to make modified
    Kate> version of I2C subsystem with additions needed for SPI.

As you understand, CS is handled in our code: otherwise nothing would
work. Since CS handling is board-specific, only board-specific files
(platforms/xxx for PPC) can provide appropriate functions. I wanted to
preserve interfaces (otherwise I would have to rewrite all relevant
user-space applications, like lm-sensors), so SPI controllers drivers
(master_xfer method) simply call function

  int spi_cs(struct i2c_adapter *adap, u16 slave, int assert_cs)

before and after each transaction. The function is implemented for each
SPI-enabled board in that board's specific file. Slave address,
meaningless for SPI, is used to identify the peripheral. The function
asserts or negates the selected slave's chip select. Slave address is
just a unique ID, assigned by the programmer with the sole purpose of
telling the spi_cs function which peripheral is to be
selected/deselected. The function, since it's board-specific, "knows"
how to do this i.e. how to access parallel ports, FPGAs, or whatever is
necessary on that specific board to activate chip select.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================




More information about the Linuxppc-embedded mailing list