linux-kernel - Re: [spi-devel-general] [Patch 0/4] IndustrialIO subsystem (ADCs, accelerometers etc)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48887576.1040901@cam.ac.uk>
Date:	Thu, 24 Jul 2008 13:28:38 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	"Hans J. Koch" <hjk@...utronix.de>, mgross@...ux.intel.com,
	hmh@....eng.br, Dmitry Torokhov <dtor@...l.ru>,
	LKML <linux-kernel@...r.kernel.org>,
	LM Sensors <lm-sensors@...sensors.org>,
	David Brownell <david-b@...bell.net>,
	Jonathan Cameron <Jonathan.Cameron@...il.com>,
	Ben Dooks <ben-linux@...ff.org>,
	Jean Delvare <khali@...ux-fr.org>,
	spi-devel-general@...ts.sourceforge.net,
	Ben Nizette <bn@...sdigital.com>
Subject: Re: [spi-devel-general] [Patch 0/4] IndustrialIO subsystem (ADCs,
 accelerometers etc)

Alan Cox wrote:
>> hwmon is designed for slow I/O. It won't handle an ADC that does a few
>> megasamples/sec.
> 
> At that rate I would assume you want a memory mapped ring buffer or
> similar not a sysfs style interface ?
Agreed, this isn't going to do megsamps per second either (at least not
without a fair bit faster processor  / memory than available in embedded
architectures).  If you want to go at those rates you'll need something
with a hardware ring buffer or an intermediate chip to provide said
buffering whilst not trying to run a general purpose os at the same time.

I am considering adding a 'burst' mode which would use up any available
i2c / spi hardware buffers to get somewhere nearer to those sort of speeds.

One of the most important elements of this subsystem is indeed a ring
buffer architecture, currently not mmapped. I'm still trying to work out
how to make that work without blocking the ring filling on interrupts.
Currently I can only seem to get around this by doing copies of ring
to mmapped locations and having some dirty bit type marking of regions
that don't contain valid data.  I guess suitable userspace libraries
could hide this mess though.

For the few ksps range the current chrdev interface is adequate if not
ideal.

The ring achitecture is one of the areas that probably needs most work.

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