From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756124Ab0EGLsN (ORCPT ); Fri, 7 May 2010 07:48:13 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45174 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754359Ab0EGLsL (ORCPT ); Fri, 7 May 2010 07:48:11 -0400 From: Oliver Neukum Organization: SUSE To: Clemens Ladisch Subject: Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems Date: Fri, 7 May 2010 13:47:56 +0200 User-Agent: KMail/1.12.4 (Linux/2.6.34-rc6-0.1-default; KDE/4.3.5; x86_64; ; ) Cc: Daniel Mack , Takashi Iwai , alsa-devel@alsa-project.org, Greg KH , Konrad Rzeszutek Wilk , USB list , Kernel development list , Chris Wright , iommu@lists.linux-foundation.org, Andi Kleen , Alan Stern , Pedro Ribeiro , Andrew Morton , David Woodhouse References: <4BE3E1B9.5020602@ladisch.de> <201005071342.34923.oneukum@suse.de> In-Reply-To: <201005071342.34923.oneukum@suse.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005071347.56993.oneukum@suse.de> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Freitag, 7. Mai 2010 13:42:34 schrieb Oliver Neukum: > Am Freitag, 7. Mai 2010 11:47:37 schrieb Clemens Ladisch: > > > In the particular case of audio drivers, though, the contents of the > > > buffers are likely to change after the submission. What we do here > > > is that we map the audio stream buffers which are used by ALSA to > > > the output URBs, so they're filled asychronously. Once the buffer is > > > actually sent out on the bus, it is believed to contain proper audio > > > date. If it doesn't, that's due to too tight audio timing or other > > > problems. This breaks once buffers are magically bounced in the > > > background. > > > > At least the audio class and ua101 drivers don't do this and fill the > > buffers before they are submitted. > > > > > So - long story short: these audio buffers need to be DMA coherent. > > > > Does the USB API actually guarantee that all controllers use DMA, i.e., > > that the buffers can be filled after submission? > > No, you must not touch buffers after submission. This does not even > work if we use DMA, because on some architectures this violates > guarantees to the dma primitives. It cannot be done. Or to be precise it could be done with coherent memory, but you'd risk transfering partially updated buffers, as you cannot know when DMA will be done and we don't guarantee that DMA will be done right as we transfer. Regards Oliver From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Neukum Subject: Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems Date: Fri, 7 May 2010 13:47:56 +0200 Message-ID: <201005071347.56993.oneukum@suse.de> References: <4BE3E1B9.5020602@ladisch.de> <201005071342.34923.oneukum@suse.de> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <201005071342.34923.oneukum-l3A5Bk7waGM@public.gmane.org> Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Clemens Ladisch Cc: Daniel Mack , Takashi Iwai , alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, Greg KH , Konrad Rzeszutek Wilk , USB list , Kernel development list , Chris Wright , iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Andi Kleen , Alan Stern , Pedro Ribeiro , Andrew Morton , David Woodhouse List-Id: alsa-devel@alsa-project.org Am Freitag, 7. Mai 2010 13:42:34 schrieb Oliver Neukum: > Am Freitag, 7. Mai 2010 11:47:37 schrieb Clemens Ladisch: > > > In the particular case of audio drivers, though, the contents of the > > > buffers are likely to change after the submission. What we do here > > > is that we map the audio stream buffers which are used by ALSA to > > > the output URBs, so they're filled asychronously. Once the buffer is > > > actually sent out on the bus, it is believed to contain proper audio > > > date. If it doesn't, that's due to too tight audio timing or other > > > problems. This breaks once buffers are magically bounced in the > > > background. > > > > At least the audio class and ua101 drivers don't do this and fill the > > buffers before they are submitted. > > > > > So - long story short: these audio buffers need to be DMA coherent. > > > > Does the USB API actually guarantee that all controllers use DMA, i.e., > > that the buffers can be filled after submission? > > No, you must not touch buffers after submission. This does not even > work if we use DMA, because on some architectures this violates > guarantees to the dma primitives. It cannot be done. Or to be precise it could be done with coherent memory, but you'd risk transfering partially updated buffers, as you cannot know when DMA will be done and we don't guarantee that DMA will be done right as we transfer. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html