That's certainly interesting and I guess one of the easiest ways of getting data
from spi to a desktop machine. I'll admit my interest is more with embedded
machines.
Yes, and that means we would use the delights of platform data and the generic
gpio subsystem. Although I believe generic gpio isn't available on every
platform as yet, it is getting there and is certainly in place for ARM (and
cleans up an awful lot of hardware interfaces!)
Yes, the intention would not be to generalize the hardware comms, but rather the
interface on the user side. This is similar to a number of other subsystems
such as hwmon, where you share functionality as much as possible, but allow very
different approaches to things like actual hardware register reads as and when
they are necessary.
Definitely. Obviously the accuracy of this time stamp is going to be limited by
the variable nature of when an interrupt handler picks it up, but knowledge of
the device specs can allow filtering of this timing data. This is certainly
something we would want to consider at a later date although it may well be more
sensible to leave this to userspace applications.
Indeed. This is well handled by the SPI subsystem. I've spent far too much time
with a scope recently fiddling with these parameters for badly documented chips!
Agreed. With this sort of device two modes would be needed (and are supported
by the hardware). The first gives direct data access and the second uses the
ring buffer. Which you use would obviously be dependent on the application.
Some applications want the most recent data on all occasions, whilst some will
be more interested in ensuring that all data is captured.
The question here is concerned with standardising mainly the userspace
interfaces (and hardware interfaces only when appropriate). Some of these
devices (the ST accel above for example) support multiple hardware interfaces
specs (I2C and SPI for that one). So in a similar way to it making sense to
group all TV adapters irrespective of how they are interfaced to the computer,
in order to ensure a consistent interface to user space, it makes sense to share
these interfaces amongst drivers talking to these devices irrespective of what
their hardware interface is.
Thanks,
--
Jonathan Cameron
--
