RFC: extension of libi2c to support SPI aswell

[Till Straumann]

Thomas Doerfler wrote:
> Hi,
>
> some weeks ago, I have implemented a I2C driver based on cpukit/libi2c.
> This library is an elegant solution to handle multiple serial (I2C)
> devices connected to a I2C bus.
>
> Now I have the task to support an SPI bus as well and I think libi2c
> only needs few extensions to also support SPI devices. The differences
> are rather small, so I want to avoid copying the code into a separate
> libspi.c. Before I really start, I would like to get some feedback from
> the list.
>
> Here are the things that should be added to libi2c and its APIs.
> Everything can be implemented without breaking the existing API:
>
> API between libi2c and low level driver:
>
> - An optional "readwrite_op" call should be added to allow simultaneous
> read/write transfers (since SPI is basically a full duplex interface)
>   
sounds acceptable.
> - An optional "setmode_op" call should be added to allow the setting of
> baudrate and clock/data relationship (which may differ between different
> attached devices)
>   
How about a  'ioctl_op'? Performing a ioctl() on a fd would
  a) call the high-level driver's ioctl() (just as it does now).
  b) call the low-level/bus driver's ioctl_op if the ioctl was not
      handled by a).
This seems generic, flexible and in sync with common semantics.
> API between libi2c and high level driver:
>
> - An additional ioctl should be defined to implement a combined
> "read_write" call.
>   
Sounds reasonable.
> - An addition ioctl should be defined to allow the high level driver to
> select the proper baudrate and clock/data relationship.
>   
Would already be covered by 'ioctl_op'. libi2c could just define
standardized ioctl command symbols for this purpose for sake of
portability. For SPI you probably also want to set the word length
and other things, too.
> Internals of libi2c:
>
> - libi2c should store the baudrate and clock/data relationship
> separately for each high-level driver and apply it to the low level
> driver whenever the device is adressed.
>   
It seems that if the low-level ioctl handles these then they would be 
stored in the
low-level driver and used appropriately already. Unless I miss something...

-- Till
> - The SPI extension should be documented properly :-)
>
> Any comments concerning my plans?
>
> wkr,
> Thomas.
>
>
>