>
> Ok, say the HW SPI is pushed down to some lower level driver. These
> things send streaming data, and sometimes signals (free-fall detect) out
> of band WRT the SPI comms.
Indeed. This would have to handled using interrupts based on the
generic gpio interface. (see the LIS3L02DQ driver on t
On Tuesday 27 May 2008, mark gross wrote:
>
> > > Another problem area is around SPI itself. There are variations of
> > > device implementations around chip select polarity, clock biasing
> > > (rising,falling, or midpoint) sampling from one SPI part to the next.
> >
> > Midpoint? That's not o
Hi Ben,
On Tue, May 27, 2008 at 06:16:56PM +0100, Ben Dooks wrote:
> >
> > I don't think that input subsystem woudl be the best choice. While we
> > do support the event-driven mechanism for delivering information to
> > userspace input is mostly oriented for human interface devices, not
> > gene
On Tue, May 27, 2008 at 07:00:56PM +0100, Jonathan Cameron wrote:
>
> >
> > The two drivers i've seen so far use the input subsystem to report
> > their data to the user. I'm working on an driver for the SMB380 which
> > can be both i2c and spi.
> Yes, the ST accel I'm using (LIS3L02DQ) is like th
>
> The two drivers i've seen so far use the input subsystem to report
> their data to the user. I'm working on an driver for the SMB380 which
> can be both i2c and spi.
Yes, the ST accel I'm using (LIS3L02DQ) is like that as well, so we
definitely need
to implement the ability to do this cleanly
Hi Anton
>> Typical requirements within an application include simply polling for
>> current
>> readings, and using device triggered interrupts to grab data
>> continuously to a
>> ring buffer, for collection by suitable userspace code. Obviously it
>> would be
>> desirable to standardize sysfs
On Wed, May 21, 2008 at 09:49:42AM -0400, Dmitry Torokhov wrote:
> On Tue, May 20, 2008 at 01:28:17PM +0200, Jean Delvare wrote:
> > Hi Jonathan,
> >
> > On Tue, 20 May 2008 11:04:01 +0100, Jonathan Cameron wrote:
> > > This email is basically a request for opinions on how and where such
> > > se
Hi David,
> On Tuesday 20 May 2008, Jean Delvare wrote:
>> This all sounds quite different from our hwmon drivers. Our hwmon
>> drivers read all the sensor values at once and cache the readings for a
>> couple seconds, so you can't get an instant reading at any time, and
>> they also don't support
On Tuesday 20 May 2008, Jean Delvare wrote:
> This all sounds quite different from our hwmon drivers. Our hwmon
> drivers read all the sensor values at once and cache the readings for a
> couple seconds, so you can't get an instant reading at any time, and
> they also don't support interrupts in ge
On Tuesday 20 May 2008, mark gross wrote:
> > ST Micro LIS3L02DQ 3D accelerometer. ...
>
> FWIW: I have this device talking to a PIC-18 and pushing the results
> over the serial port.
Jonathan neglected to mention that he's already sent a driver
for this to the SPI list. ;)
Which is part of th
On Wed, 21 May 2008, Dmitry Torokhov wrote:
> I don't think that input subsystem woudl be the best choice. While we
> do support the event-driven mechanism for delivering information to
> userspace input is mostly oriented for human interface devices, not
> general data acquisition. If anything inp
On Tue, May 20, 2008 at 01:28:17PM +0200, Jean Delvare wrote:
> Hi Jonathan,
>
> On Tue, 20 May 2008 11:04:01 +0100, Jonathan Cameron wrote:
> > This email is basically a request for opinions on how and where such sensors
> > should be integrated into the kernel.
> >
> > To set the scene...
> >
On Wed, 21 May 2008 11:04:38 +0100, Jonathan Cameron wrote:
> Definitely agreed that it makes sense to put DACs and ADCs in the same
> general place and obviously there are plenty of devices out there that do
> both.
Note that hardware monitoring chips can include ADCs and DACs: the
former to mon
Hi Hans and Jean,
Thanks for your responses.
> On Tue, May 20, 2008 at 01:28:17PM +0200, Jean Delvare wrote:
>
>> Hi Jonathan,
>>
>> On Tue, 20 May 2008 11:04:01 +0100, Jonathan Cameron wrote:
>>
>>> This email is basically a request for opinions on how and where such sensors
>>> should b
Hi Mark,
>> ST Micro LIS3L02DQ 3D accelerometer. SPI device, no buffering, interrupt
>> pin
>> raised high on new data being available. Currently the driver assumes, if
>> interrupts are enabled, that this is connected to a specified gpio.
>> (http://www.st.com/stonline/books/pdf/docs/10175.pdf)
On Tue, May 20, 2008 at 01:28:17PM +0200, Jean Delvare wrote:
> Hi Jonathan,
>
> On Tue, 20 May 2008 11:04:01 +0100, Jonathan Cameron wrote:
> > This email is basically a request for opinions on how and where such sensors
> > should be integrated into the kernel.
> >
> > To set the scene...
> >
On Tue, May 20, 2008 at 11:04:01AM +0100, Jonathan Cameron wrote:
> This email is basically a request for opinions on how and where such
> sensors
> should be integrated into the kernel.
>
> To set the scene...
>
> Increasing numbers of embedded devices are being supplied attached MEMS
> devices (
Hi Jonathan,
On Tue, 20 May 2008 11:04:01 +0100, Jonathan Cameron wrote:
> This email is basically a request for opinions on how and where such sensors
> should be integrated into the kernel.
>
> To set the scene...
>
> Increasing numbers of embedded devices are being supplied attached MEMS
> de
This email is basically a request for opinions on how and where such sensors
should be integrated into the kernel.
To set the scene...
Increasing numbers of embedded devices are being supplied attached MEMS
devices (www.xbow.com imote2 etc). Along with more traditional sensors such
as ADC's not b
19 matches
Mail list logo
