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

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

[Grant Likely]

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.

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

[Matt Porter]

On Sat, Jul 23, 2005 at 10:04:07AM -0400, Grant Likely wrote:
> 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 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

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

[Yuli Barcohen]

>>>>> Grant Likely writes:

    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
 yuli@arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

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

[Kate Alhola]

>
> 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.

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

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

[Yuli Barcohen]

>>>>> 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@arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

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

[Grant Likely]

On 7/25/05, Yuli Barcohen <yuli@arabellasw.com> wrote:
> >>>>> Kate Alhola writes:
>=20
>     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.
>=20
>     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.

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:

>From http://lkml.org/lkml/2005/5/31/251
"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.

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

[Yuli Barcohen]

>>>>> Grant Likely 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.

    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
 yuli@arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

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

[Kate Alhola]

> 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).

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

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

[Yuli Barcohen]

>>>>> Kate Alhola writes:

    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
 yuli@arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================