Messages in this thread | | | Date | Tue, 26 Jul 2011 23:42:54 +0530 | Subject | Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id | From | Jaswinder Singh <> |
| |
On 26 July 2011 20:59, Williams, Dan J <dan.j.williams@intel.com> wrote: > On Tue, Jul 26, 2011 at 7:30 AM, Jaswinder Singh > <jaswinder.singh@linaro.org> wrote: >> On 26 July 2011 01:38, Williams, Dan J <dan.j.williams@intel.com> wrote: >>> Correct, it is meant that chan_id is only a sysfs property. Any >>> driver usage that is assuming chan_id is anything more than a >>> guaranteed unique number within a given dma_device's list of channels >>> is probably inferring too much. >> >> So you mean dmac/client drivers are wrong if they make use of chan_id. >> They shouldn't count upon it's value - which is set by DMA API for a completely >> independent purpose, i.e, creating contiguous sysfs entries. > > They can count on it being unique, and maybe the fact that it is in > the same order as dma_device.channels. The latter implies the former. And it is already the dmac driver that decides the rank of a channel in the list.
> >> >> Since "chan_id is only a sysfs property" and the fact that it is used >> only _once_ >> by the DMA API >> >> In drivers/dma/dmaengine.c >> >> chan->chan_id = chancnt++; >> dev_set_name(&chan->dev->device, "dma%dchan%d", >> device->dev_id, chan->chan_id); >> >> >> Can't we do away with chan_id altogether ? by having >> >> dev_set_name(&chan->dev->device, "dma%dchan%d", >> device->dev_id, chancnt++); >> >> I mean why make every instance of dma_chan bigger by 4bytes ? >> >> So why shouldn't we remove chan_id completely from the DMA API ? > > Good point... Let's remove chan_id from the core and push it into the > drivers that need it. > If you agree, I would preserve the chan_id in 'struct dma_chan' but remove any assignment to it in dmaengine.c and let the dmac drivers use it freely. That would:- a) Let dmac drivers decide what numbers they want to show up in sysfs. b) chan_id is easily reachable by client drivers, so it is better this way. c) It would mean lesser and simpler changes to extant users of it.
Thanks, -Jassi
-- Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog -- 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/
| |