Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id
From: Williams, Dan J
Date: Fri Jul 22 2011 - 18:32:57 EST
On Fri, Jul 22, 2011 at 10:43 AM, Jaswinder Singh
> On 22 July 2011 20:57, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>> On Thu, Jul 21, 2011 at 6:01 AM, Jassi Brar <jaswinder.singh@xxxxxxxxxx> wrote:
>>> A DMAC driver might put chan_id to better use by directly
>>> mapping system-wide channel numbers on them (and not DMAC
>>> relative index).
>> Sorry, not following this, is the idea that instead of each DMAC
>> numbering its own channels [0...N] you want to establish a global
>> channel index number [0..N] that is unique across all DMACs
>> in the system, even if you have several of them?
> Something like that.
> Some DMACs 'think' they set the chan_id but it is immidiately overwritten
> by dma_async_device_register()
> So it's not clear whose job is to set it. Apparently the core is just
> "doing it for the DMAC driver".
> First of all, we need to see if we really want the dmaengine.c to
> set it's value?
> I think not, because there is no way for a DMAC driver to assign
> actually usable channel numbers to chan_id -- there might be 'holes'
> in the channel sequence of a DMAC. For ex, some channels of a DMAC
> don't reach any peripheral in a particular SoC.
> So the 'contiguous' sysfs entries 'dma%dchan%d' only depict
> mock numbering, which I am not sure is any useful.
> Also, it should be possible to map channel suitability (job of filter function)
> onto unique channel ID in a platform.
> So client drivers could simply do
> bool filter_fn(struct dma_chan *chan, void *ch)
> return chan->chan_id == ch;
> And this, imho, should be what we should strive for if we are to have
> common clients over different DMACs.
The chan_id really is just a presentation detail to sysfs. Just like
scsi host numbers they simply identify that they are distinct but the
number has no significant meaning inside the kernel to the driver
Unless you guaranteed that every id is globally unique I don't see how
they are generically usable by common clients?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/