On 31-05-18, 01:58, Wen He wrote:
> > > > > > > +static void fsl_qdma_issue_pending(struct dma_chan *chan) {
> > > > > > > + struct fsl_qdma_chan *fsl_chan = to_fsl_qdma_chan(chan);
> > > > > > > + struct fsl_qdma_queue *fsl_queue = fsl_chan->queue;
> > > > > > > + unsigned long flags;
> > > > > > > +
> > > > > > > + spin_lock_irqsave(&fsl_queue->queue_lock, flags);
> > > > > > > + spin_lock(&fsl_chan->vchan.lock);
> > > > > > > + if (vchan_issue_pending(&fsl_chan->vchan))
> > > > > > > + fsl_qdma_enqueue_desc(fsl_chan);
> > > > > > > + spin_unlock(&fsl_chan->vchan.lock);
> > > > > > > + spin_unlock_irqrestore(&fsl_queue->queue_lock, flags);
> > > > > >
> > > > > > why do we need two locks, and since you are doing vchan why
> > > > > > should you add your own lock on top
> > > > > >
> > > > >
> > > > > Yes, we need two locks.
> > > > > As you know, the QDMA support multiple virtualized blocks for
> > > > > multi-core
> > > > support.
> > > > > so we need to make sure that muliti-core access issues.
> > > >
> > > > but why cant you use vchan lock for all?
> > > >
> > >
> > > We can't only use vchan lock for all. otherwise enqueue action will be
> > interrupted.
> >
> > I think it is possible to use only vchan lock
>
> I tried that if I use only vchan lock then qdma will be can't work.
> Do you have a other good idea?
can you explain the scenario...
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
