Support for SPI busses and devices

Request for Comment:

Here is a set of patches that adds SPI support to linux. I'm looking for feedback on these and I'd like to eventually get the SPI infrastructure into mainline

There are three patches. The first patch creates a new bus type 'spi'. The second adds support for using a PSC on the MPC52xx as an SPI bus master. The third is a driver for an ks8995m managed switch from Micrel.

Patch generated from 2.6.12

Cheers,
g.

There is also another attempt at an SPI subsystem (not based on the RMK code) that was posted to lkml. You might want to check out
http://lkml.org/lkml/2005/5/31/162 for the original posting and then an updated version at http://lkml.org/lkml/2005/6/23/161

-Matt

Grant> Request for Comment: Here is a set of patches that adds SPI Grant> support to linux. I'm looking for feedback on these and I'd Grant> like to eventually get the SPI infrastructure into mainline

[...deleted...]

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

========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 [email protected] | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

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

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

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

Kate

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
 [email protected] | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

Thanks for the comments everyone. I had seen the first cut at an SPI subsystem on the lkml, but I hadn't seen the revised patch. My understanding from GregKH's comments on the first patch is that i2c is a bit of a mess:

"The i2c dev interface is a mess, please don't duplicate it, there is no need to do so."

What is current opinion on the i2c subsystem? Did I misunderstand Greg's I2C comments? I put together the SPI patch as an alternative implementation that matches the current coding conventions (as I understand them).

Yuli, are there any plans to submit your i2c changes to support SPI back to mainline?

I've now got to go back and review the revised SPI patch on the LKML.

Thanks again,
g.

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.

Grant> Thanks for the comments everyone. I had seen the first cut Grant> at an SPI subsystem on the lkml, but I hadn't seen the Grant> revised patch. My understanding from GregKH's comments on Grant> the first patch is that i2c is a bit of a mess:

Grant> From http://lkml.org/lkml/2005/5/31/251
Grant> "The i2c dev interface is a mess, please don't duplicate it, Grant> there is no need to do so."

Grant> What is current opinion on the i2c subsystem? Did I Grant> misunderstand Greg's I2C comments? I put together the SPI Grant> patch as an alternative implementation that matches the Grant> current coding conventions (as I understand them).

The current I2C subsystem is not perfect but it's well established and used by different user-space applications. Changing the interfaces for SPI means that all the applications for SPI-connected peripherals must be developed more or less from scratch. Almost every serial EEPROM or temperature sensor exists in both I2C and SPI versions, and I don't think we'd like to have separate applications for these two versions. The I2C subsystem will be updated sooner or later to match current coding conventions, etc. If SPI will be part of this subsystem, it will get all that updates. My changes work well for our customers with a range of SPI devices (EEPROMs, temperature sensors, RTC, I even wrote driver for MMC card in SPI mode).

Grant> Yuli, are there any plans to submit your i2c changes to Grant> support SPI back to mainline?

I have no problem to submit the changes though I'm not sure to what list to send them. All the changes in fact are just a couple of defines. Unfortunately, I've got no enough time to follow all the relevant lists.

Grant> I've now got to go back and review the revised SPI patch on Grant> the LKML.

========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 [email protected] | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

At the first, implementation that i used, has same interface as I2C because it is based on I2C but with some extensions needed for SPI. The idea is not to make it as incompatible with I2C. There are here are some devices that can be used exactly same API but also some others that are needing extended API. The CS logic is mostly one that needs extensions, not. The converting I2C address to just one HW defined CS signal that goes low in beginning of transaction and raises up in end is clearly not sufficent in many cases.

Other cases may be devices that need to have CS active continuously during multiple short transactions ( like MMC card Statuc polling ), some that needs diferent behavior like CS is just latch pulse issued after transaction etc. Some devices transfer like 16 bits word where first 4 bits are send and 12 recive so there is not byte bordered send/receive transfer etc.

I think that the good solition should preserve existing I2C API but should also have enough extensions to support all kind of SPI devices.

Kate

Yuli> The current I2C subsystem is not perfect but it's well Yuli> established and used by different user-space
Yuli> applications. Changing the interfaces for SPI means that all Yuli> the applications for SPI-connected peripherals must be Yuli> developed more or less from scratch. Almost every serial Yuli> EEPROM or temperature sensor exists in both I2C and SPI Yuli> versions, and I don't think we'd like to have separate Yuli> applications for these two versions. The I2C subsystem will be Yuli> updated sooner or later to match current coding conventions, Yuli> etc. If SPI will be part of this subsystem, it will get all Yuli> that updates. My changes work well for our customers with a Yuli> range of SPI devices (EEPROMs, temperature sensors, RTC, I Yuli> even wrote driver for MMC card in SPI mode).

Kate> At the first, implementation that i used, has same interface Kate> as I2C because it is based on I2C but with some extensions Kate> needed for SPI. The idea is not to make it as incompatible Kate> with I2C. There are here are some devices that can be used Kate> exactly same API but also some others that are needing Kate> extended API. The CS logic is mostly one that needs Kate> extensions, not.

Mostly yes. Another useful extension is clock frequency control and this extension would be useful for I2C too because there are I2C controllers which allow for variable clock settings, not only 100/400KHz (PowerQUICCs, for example). All this IMHO does not justify developing of a separate SPI subsystem.

Kate> The converting I2C address to just one HW defined CS signal Kate> that goes low in beginning of transaction and raises up in end

I didn't say this. I said that the CS handling function is called in the beginning and in the end. What it does is board-dependent in any case because even CS implementation itself is board-specific (processor GPIO, FPGA, external register, etc.).

Kate> is clearly not sufficent in many cases.

It's not so clear to me and some examples of such cases would help.

Kate> Other cases may be devices that need to have CS active Kate> continuously during multiple short transactions ( like MMC Kate> card Statuc polling ),

For the MMC case, this simply is not true. You don't have to assert CS continuously but only during the status read. After the read, you can de-assert CS, and assert it again on next poll. Between the polls, you can assert other CSs to work with other chips connected to the same bus. For me, the fact that my MMC driver works OK is a good proof that CS handling is not a problem in case of MMC card. This does not mean, of course, that there can't be peripherals which require keeping CS asserted during several transactions. This case is not different from I2C peripherals which require no START condition between transactions. As you know, there is a flag in I2C (I2C_M_NOSTART) which means "do not generate start condition". There are also flags for handling other special conditions (I2C_M_NO_RD_ACK, I2C_M_IGNORE_ACK, etc.). The same approach is good for SPI IMHO - flags in the message header which alters CS behaviour.

Kate> some that needs diferent behavior like CS is just latch pulse Kate> issued after transaction etc. Some devices transfer like 16 Kate> bits word where first 4 bits are send and 12 recive so there Kate> is not byte bordered send/receive transfer etc.

How is this connected to the CS issue? There is only one clock for both receive and transmit so the number of received and transmitted bits is identical though some of these bits should be ignored.

Kate> I think that the good solition should preserve existing I2C Kate> API but should also have enough extensions to support all kind Kate> of SPI devices.

Yes. Does this mean that we have to clone entire I2C subsystem and slightly modify it or it's enough to extend the I2C to handle SPI too?

========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 [email protected] | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================