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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]