Messages in this thread | | | Date | Thu, 18 Sep 2008 21:20:56 -0700 | From | "Dan Williams" <> | Subject | Re: dmaengine.c: question about device_alloc_chan_resources |
| |
On Thu, Sep 18, 2008 at 7:45 AM, Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote: > Timur Tabi <timur@freescale.com> wrote: >> Haavard Skinnemoen wrote: >> >> > Wouldn't it be better if the dmaengine layer made sure it didn't pass >> > the same channel several times to a client? >> >> Wouldn't that require it to keep track of which clients have already seen which >> channels? It might make more sense, but it's probably easier the current way. > > I guess so. What would be even more simple is to simply prevent other > clients from taking a channel once someone has acked it, which would be > perfect for my purposes, but perhaps not everyone else's...
Does not seem too bad to have something like a DMA_EXCL flag in dma_chan to tell the core not to show this channel to any other clients.
> > How common is for several clients to use the same channel anyway > though? Wouldn't you risk stalling the network stack if the md subsystem > has submitted a large xor operation on the same channel that the > network stack was about to use?
It's analogous to running the network stack on the same cpu as md. Yes, they effect each other but the operations are short-lived and can interleave. One potential problem could be bouncing the channel lock across multiple cpu's. This is mitigated if net_dma is changed to use async_memcpy(), but it's not a priority. iop_adma and mv_xor live on single cpu platforms where net_dma is already turned off due to the expense of get_user_pages().
-- Dan
| |