From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756021Ab0EGJrq (ORCPT ); Fri, 7 May 2010 05:47:46 -0400 Received: from out1.smtp.messagingengine.com ([66.111.4.25]:59209 "EHLO out1.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755023Ab0EGJrp (ORCPT ); Fri, 7 May 2010 05:47:45 -0400 X-Sasl-enc: dJ8U/T5wiwi+oHZ6+raLCAAICFIZtds9dvUbp4TQiB9+ 1273225660 Message-ID: <4BE3E1B9.5020602@ladisch.de> Date: Fri, 07 May 2010 11:47:37 +0200 From: Clemens Ladisch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Daniel Mack CC: 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 Subject: Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems References: <20100507074855.GF30801@buzzloop.caiaq.de> In-Reply-To: <20100507074855.GF30801@buzzloop.caiaq.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Daniel Mack wrote: > The problem is again (summarized): > > On 64bit machines, with 4GB or more, the allocated buffers for USB > transfers might be beyond the 32bit boundary. In this case, the IOMMU > should take care and install DMA bounce buffer to copy over the buffer > before the transfer actually happens. The problem is, however, that this > copy mechanism takes place when the URB with its associated buffer is > submitted, not when the EHCI will actually do the transfer. > > 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? Regards, Clemens From mboxrd@z Thu Jan 1 00:00:00 1970 From: Clemens Ladisch Subject: Re: USB transfer_buffer allocations on 64bit systems Date: Fri, 07 May 2010 11:47:37 +0200 Message-ID: <4BE3E1B9.5020602@ladisch.de> References: <20100507074855.GF30801@buzzloop.caiaq.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by alsa0.perex.cz (Postfix) with ESMTP id D1F93244E1 for ; Fri, 7 May 2010 11:47:46 +0200 (CEST) In-Reply-To: <20100507074855.GF30801@buzzloop.caiaq.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Daniel Mack Cc: alsa-devel@alsa-project.org, USB list , Konrad Rzeszutek Wilk , Takashi Iwai , Greg KH , Kernel development list , Chris Wright , iommu@lists.linux-foundation.org, Andi Kleen , Alan Stern , Pedro Ribeiro , Andrew Morton , David Woodhouse List-Id: alsa-devel@alsa-project.org Daniel Mack wrote: > The problem is again (summarized): > > On 64bit machines, with 4GB or more, the allocated buffers for USB > transfers might be beyond the 32bit boundary. In this case, the IOMMU > should take care and install DMA bounce buffer to copy over the buffer > before the transfer actually happens. The problem is, however, that this > copy mechanism takes place when the URB with its associated buffer is > submitted, not when the EHCI will actually do the transfer. > > 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? Regards, Clemens