From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752174Ab0CZAFW (ORCPT ); Thu, 25 Mar 2010 20:05:22 -0400 Received: from mail-pw0-f46.google.com ([209.85.160.46]:56587 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751577Ab0CZAFV convert rfc822-to-8bit (ORCPT ); Thu, 25 Mar 2010 20:05:21 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WI98K7HsGjX/sJ0ocZvB6eGIaLfbOedlwKGIPWCVyFWxKbSC5kwSBEbJlp58hMTdVN 1PGWkYJk8k7MIMP4rTgQJKhRrZGs7LJZ3elEw6upKet0vUZfS7Rd9hBf0UarFgAXvO3B Poj+Sbb/6ska2Q0gZuJEDFeY6rJpdV0xXmGXo= MIME-Version: 1.0 In-Reply-To: References: <1269529381-16914-1-git-send-email-linus.walleij@stericsson.com> Date: Thu, 25 Mar 2010 17:05:20 -0700 X-Google-Sender-Auth: b3f84d18b33fe75c Message-ID: Subject: Re: [PATCH 2/2] DMAENGINE: generic channel status From: Dan Williams To: Guennadi Liakhovetski Cc: Linus Walleij , linux-kernel@vger.kernel.org, Maciej Sosnowski , Nicolas Ferre , Pavel Machek , Li Yang , Paul Mundt , Ralf Baechle , Haavard Skinnemoen , Magnus Damm , Liam Girdwood , Mark Brown , Joe Perches , Roland Dreier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 25, 2010 at 3:37 PM, Guennadi Liakhovetski wrote: > On Thu, 25 Mar 2010, Dan Williams wrote: > >> On Thu, Mar 25, 2010 at 1:58 PM, Guennadi Liakhovetski >> wrote: >> > On Thu, 25 Mar 2010, Linus Walleij wrote: >> > >> >> Convert the device_is_tx_complete() operation on the >> >> DMA engine to a generic device_tx_status()operation which >> >> can return three states, DMA_TX_RUNNING, DMA_TX_COMPLETE, >> >> DMA_TX_PAUSED. >> >> >> [..] >> > General: you converted all drivers to the new .device_tx_status() API, but >> > since they don't implement "residue," you left it uninitialised >> > everywhere. Wouldn't it be better to set it to 0 or total length, >> > depending on the complete / not complete status? >> >> Agree that it should not be uninitialized.  At the same time I do not >> want to require drivers that don't need it to go through the hassle of >> looking up a byte count, so perhaps all but the drivers that want this >> support can return a 'max byte count'?? > > Why not assign one of the two - 0 if the transfer is complete (DMA_SUCCESS > status returned) or whatever max count otherwise? Except I do think this > might confuse some users - seeing a residue larger than the total transfer > length... > 0 if complete makes sense and then the actual residue or all 0xf's to indicate "I don't support inflight residue reporting". -- Dan