lkml.org 
[lkml]   [2012]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/9 v3] dmaengine: add an shdma-base library
Hi Vinod

On Fri, 25 May 2012, Vinod Koul wrote:

> On Fri, 2012-05-18 at 10:21 +0200, Guennadi Liakhovetski wrote:
> > Hi Vinod
> >
> > Thanks for your review.
> sorry for the late reply, was away for few days
> >
> > On Tue, 15 May 2012, Vinod Koul wrote:
> >
> > > On Wed, 2012-05-09 at 17:09 +0200, Guennadi Liakhovetski wrote:
> > > > This patch extracts code from shdma.c, that does not directly deal with
> > > > hardware implementation details and can be re-used with diverse DMA
> > > > controller variants, found on SH-based SoCs.
> > > Have you see recent Russell's virtual dma patches [1]? I like the idea
> > > and simplifies things for implementation in each driver.
> > > Said that, do we need this libarry. Can you see if you can use/enhance
> > > that one.
> >
> > No, I haven't seen it. I had a look at it, and it doesn't seem to provide
> > an immediate solution to our problem. It can be used as a part of one, but
> > a significant amount of work would still be required to convert shdma to a
> > virtual-channel based design.
> >
> > Let me try to describe, what such a virtual channel solution would look
> > like:
> >
> > 1. One (virtual) DMA channel is allocated per client
> > 2. As clients issue dma_request_channel(), the correct channel is selected
> > 3. The client configures the channel with a call to
> > dmaengine_slave_config()
> > 4. As transfers are prepared and issued they are queued in per-virtual
> > channel lists
> > 5. Each virtual channel links to a list of suitable DMA devices and
> > channels
> > 6. As a new transfer request on a specific virtual channel has to be
> > processed, a suitable free physical channel is picked up, configured
> > and the request is sent out
> >
> > If this my understanding is right, this should be doable, but not within
> > the current 3.5 time-frame. Further, if we first do this conversion, we'll
> > still have to split the driver similar to what is proposed by this patch
> > series, but then it would be largely a new effort, most of the work
> > invested into this so far will be lost. OTOH, if we now push the shdma
> > driver split, we enable the merge of the SUDMAC support and porting to the
> > virtual channel design should also become easier, because the hardware and
> > the software parts of the driver will already be separated and presumably
> > the hardware part will not need to be changed.
> >
> > One more thing, before going into detail and replying to your comments:
> > this split doesn't change driver's functionality, it simply splits it into
> > two parts. So, most questions, that you ask in this your review would also
> > apply to the current driver. This patch just extracts hardware-neutral
> > code from the shdma driver into a separate file. I think, any functional
> > changes should be done separately from this driver-split series.
> Yes most of my comments do apply to current driver.
> IMO update to a driver should fix existing problems, that why I pointed
> them out.
>
> Let me know if you plan to fixing them or I will queue these up for 3.6

Please, queue these patches for the next merge window, we will work on
improving the driver after this split.

Thanks
Guennadi

> > [snip]
> >
> > > > +static dma_cookie_t shdma_tx_submit(struct dma_async_tx_descriptor *tx)
> > > > +{
> > > > + struct shdma_desc *chunk, *c, *desc =
> > > > + container_of(tx, struct shdma_desc, async_tx),
> > > > + *last = desc;
> > > > + struct shdma_chan *schan = to_shdma_chan(tx->chan);
> > > > + struct shdma_slave *slave = tx->chan->private;
> > > > + dma_async_tx_callback callback = tx->callback;
> > > > + dma_cookie_t cookie;
> > > > + bool power_up;
> > > > +
> > > > + spin_lock_irq(&schan->chan_lock);
> > > > +
> > > > + power_up = list_empty(&schan->ld_queue);
> > > > +
> > > > + cookie = dma_cookie_assign(tx);
> > > > +
> > > > + /* Mark all chunks of this descriptor as submitted, move to the queue */
> > > > + list_for_each_entry_safe(chunk, c, desc->node.prev, node) {
> > > > + /*
> > > > + * All chunks are on the global ld_free, so, we have to find
> > > > + * the end of the chain ourselves
> > > > + */
> > > > + if (chunk != desc && (chunk->mark == DESC_IDLE ||
> > > > + chunk->async_tx.cookie > 0 ||
> > > > + chunk->async_tx.cookie == -EBUSY ||
> > > > + &chunk->node == &schan->ld_free))
> > > > + break;
> > > > + chunk->mark = DESC_SUBMITTED;
> > > > + /* Callback goes to the last chunk */
> > > > + chunk->async_tx.callback = NULL;
> > > > + chunk->cookie = cookie;
> > > > + list_move_tail(&chunk->node, &schan->ld_queue);
> > > > + last = chunk;
> > > > +
> > > > + dev_dbg(schan->dev, "submit #%d@%p on %d\n",
> > > > + tx->cookie, &last->async_tx, schan->id);
> > > > + }
> > > > +
> > > > + last->async_tx.callback = callback;
> > > > + last->async_tx.callback_param = tx->callback_param;
> > > > +
> > > > + if (power_up) {
> > > > + int ret;
> > > > + schan->pm_state = SHDMA_PM_BUSY;
> > > > +
> > > > + ret = pm_runtime_get(schan->dev);
> > > any reason why this is here and not in issue pending?
> >
> > Sorry, we have discussed this multiple times already. See, for example,
> >
> > http://thread.gmane.org/gmane.linux.kernel/1181989/focus=12187
> >
> > [snip]
> >
> > > > +/*
> > > > + * Drivers, using this library are expected to embed struct shdma_dev,
> > > > + * struct shdma_chan, struct shdma_desc, and struct shdma_slave
> > > > + * in their respective device, channel, descriptor and slave objects.
> > > > + */
> > > > +
> > > > +struct shdma_slave {
> > > > + unsigned int slave_id;
> > > this should be moved to struct dma_slave_config
> >
> > Again, this would be a functional change. And struct dma_slave_config
> > doesn't have a slave-ID field in it, which is the only thing we need for
> > now. Instead it has a bunch of other fields, of which none is so far used
> > by this driver.
> >
> > Thanks
> > Guennadi
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> > --
> > 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/
>
>
> --
> ~Vinod
>

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


\
 
 \ /
  Last update: 2012-05-25 10:41    [W:0.156 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site