From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: Continuous streaming SPI transfer Date: Thu, 4 Oct 2012 22:13:03 +0100 Message-ID: <20121004211302.GC26755@sirena.org.uk> References: <87zk4bazje.fsf@kiiro.xen-host.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Nuutti Kotivuori Return-path: Content-Disposition: inline In-Reply-To: <87zk4bazje.fsf-Nc554NfcwGrUGg1qMAD/drNAH6kLmebB@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org On Fri, Sep 28, 2012 at 01:09:25AM +0300, Nuutti Kotivuori wrote: > There seems to be no way to prevent the deactivation and reactivation of > the clock and everything between separate transfers - and a single > transfer is bounded in size and no progress is reported for it. Even > within a single transfer, it would seem that an earlier transfer is This sounds more like you've got an IIO application (or audio) than a SPI one - the hardware is the same but you're thinking about it in a completely different way and so a separate subsystem makes sense. ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev