Messages in this thread | | | Date | Thu, 25 Mar 2010 17:05:20 -0700 | Subject | Re: [PATCH 2/2] DMAENGINE: generic channel status | From | Dan Williams <> |
| |
On Thu, Mar 25, 2010 at 3:37 PM, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote: > On Thu, 25 Mar 2010, Dan Williams wrote: > >> On Thu, Mar 25, 2010 at 1:58 PM, Guennadi Liakhovetski >> <g.liakhovetski@gmx.de> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |