Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934316Ab2JXDVW (ORCPT ); Tue, 23 Oct 2012 23:21:22 -0400 Received: from casper.infradead.org ([85.118.1.10]:54280 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933960Ab2JXDVU (ORCPT ); Tue, 23 Oct 2012 23:21:20 -0400 Subject: Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps() From: Vinod Koul To: Dan Williams Cc: vinod.koul@intel.com, Matt Porter , Chris Ball , Linux DaVinci Kernel List , Linux Kernel Mailing List , Linux MMC List In-Reply-To: References: <1350615088-14562-1-git-send-email-mporter@ti.com> <1350615088-14562-2-git-send-email-mporter@ti.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 24 Oct 2012 08:39:01 +0530 Message-ID: <1351048141.5263.5.camel@vkoul-udesk3> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 904 Lines: 24 On Tue, 2012-10-23 at 15:54 -0700, Dan Williams wrote: > > +struct dmaengine_chan_caps { > > + enum dmaengine_apis ops; > > + int seg_nr; > > + int seg_len; > > +}; > > This makes sense for the potentially dynamic capability properties > that get set after configuration, but why do we need the operation > types here? They can be retrieved from the parent device. I was thinking that each channel can have different capabilities. You can assign one channel for mempcy operations exclusively and some others for slave usage exclusively. I believe some h/w do have such assignment so would help in doing that. -- Vinod Koul Intel Corp. -- 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/