Re: [RFC] SPI core

[Hinko Kocevar]

Greg KH wrote:

> The fact that the i2c drivers are not really true "drivers" in the
> driver model.  We bind them by hand to the device and then register the
> device with the core.  That isn't a nice thing to do...

And introduces alot of code do simple stuff that SPI is supposed to do. I also 
ported i2c-core,i2c-dev, i2c-bit-algo and parport bus to work with SPI device. 
Resulting SPI code base was huge and I was confused in the begining why, and 
later wondered if there is need for such a design.

I dumped evrything and created three functions : spi_access, spi_transfer and 
spi_release. First and last functions only assert/deassert CS line, 
respectevely. Spi_transfer is the core function and is more-or-less different 
on every CPU (if not using bit-banging). As every CPU has different approach in 
handling SPI interface is almost neccesary to write CPU dependent SPI part for 
each CPU out there (at least transfer function). Also you can use CPUs 
synchronous serial interface (if one supports it) or just use bit-bang algo to 
get bits in and out.

I have two devices on SPI and I drive them both by bit-banging bits in and out. 
While I was using I2C-like-SPI model I wanted to make it base for all other SPI 
devices my board would/could hold. Sad thing is that every manufacturer and/or 
device (let it be serial flash, audio codec, A/D converter, ...) has its own 
concept of accessing and transfering data to and from the SPI device. I 
experienced this a short while ago while trying to make tsc2301 audio codec and 
datakey spi serial flash to use common SPI code. I ended up duplicating the 
three aforementioned functions in the each driver and still SPI code is ~10-15 
times smaller than initial I2C-to-SPI port I did.

I would also like to see SPI core in linux driver model, but nothing like I2C 
stuff. SPI is far to simple (and yet so diverse) that much more simple concept 
could be used.

just my .2 €

regards,
hinko k

--
..because under Linux "if something is possible in principle,
then it is already implemented or somebody is working on it".

					--LKI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/