All of lore.kernel.org
 help / color / mirror / Atom feed
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver
Date: Thu, 5 Feb 2015 12:11:18 -0800	[thread overview]
Message-ID: <20150205201118.GB16547@intel.com> (raw)
In-Reply-To: <CAFd313yBS3KOdtKbnaeTKehmC_f5ZaB-nx299QoLeMm279=Jsg@mail.gmail.com>

On Thu, Feb 05, 2015 at 05:29:06PM +0530, Rameshwar Sahu wrote:
> Hi Vinod,
> 
> Thanks for reviewing this patch.
> 
> Please see inline......
Please STOP top posting

> >
> >> +}
> >> +
> >> +static void xgene_dma_issue_pending(struct dma_chan *channel)
> >> +{
> >> +     /* Nothing to do */
> >> +}
> > What do you mean by nothing to do here
> > See Documentation/dmaengine/client.txt Section 4 & 5
> This docs is only applicable on slave DMA operations, we don't support
> slave DMA, it's only master.
> Our hw engine is designed in the way that there is no scope of
> flushing pending transaction explicitly by sw.
> We have circular ring descriptor dedicated to engine. In submit
> callback  we are queuing descriptor and informing to engine, so after
> this it's internal to hw to execute descriptor one by one.
But the API expectations on this are _same_ 

No the API expects you to maintain a SW queue, then push to your ring buffer
when you get issue_pending. Issue pending is the start of data transfer, you
client will expect accordingly.

> >> +     /* Run until we are out of length */
> >> +     do {
> >> +             /* Create the largest transaction possible */
> >> +             copy = min_t(size_t, len, DMA_MAX_64BDSC_BYTE_CNT);
> >> +
> >> +             /* Prepare DMA descriptor */
> >> +             xgene_dma_prep_cpy_desc(chan, slot, dst, src, copy);
> >> +
> > This is wrong. The descriptor is supposed to be already prepared and now it
> > has to be submitted to queue
> 
> Due to the race in tx_submit call from the client, need to serialize
> the submission of H/W DMA descriptors.
>  So we are making  shadow copy in prepare DMA  routine and  preparing
> actual descriptor during tx_submit call.
Thats an abuse of API and I dont see a reason why this race should happen in
the first place.

So you get a prep call, you prepare a desc in SW. Then submit pushes it to a
queue. Finally in issue pending you push them to HW. Simple..?

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Rameshwar Sahu <rsahu-qTEPVZfXA3Y@public.gmane.org>
Cc: dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	ddutile-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	patches-qTEPVZfXA3Y@public.gmane.org,
	Loc Ho <lho-qTEPVZfXA3Y@public.gmane.org>
Subject: Re: [PATCH v5 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver
Date: Thu, 5 Feb 2015 12:11:18 -0800	[thread overview]
Message-ID: <20150205201118.GB16547@intel.com> (raw)
In-Reply-To: <CAFd313yBS3KOdtKbnaeTKehmC_f5ZaB-nx299QoLeMm279=Jsg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Thu, Feb 05, 2015 at 05:29:06PM +0530, Rameshwar Sahu wrote:
> Hi Vinod,
> 
> Thanks for reviewing this patch.
> 
> Please see inline......
Please STOP top posting

> >
> >> +}
> >> +
> >> +static void xgene_dma_issue_pending(struct dma_chan *channel)
> >> +{
> >> +     /* Nothing to do */
> >> +}
> > What do you mean by nothing to do here
> > See Documentation/dmaengine/client.txt Section 4 & 5
> This docs is only applicable on slave DMA operations, we don't support
> slave DMA, it's only master.
> Our hw engine is designed in the way that there is no scope of
> flushing pending transaction explicitly by sw.
> We have circular ring descriptor dedicated to engine. In submit
> callback  we are queuing descriptor and informing to engine, so after
> this it's internal to hw to execute descriptor one by one.
But the API expectations on this are _same_ 

No the API expects you to maintain a SW queue, then push to your ring buffer
when you get issue_pending. Issue pending is the start of data transfer, you
client will expect accordingly.

> >> +     /* Run until we are out of length */
> >> +     do {
> >> +             /* Create the largest transaction possible */
> >> +             copy = min_t(size_t, len, DMA_MAX_64BDSC_BYTE_CNT);
> >> +
> >> +             /* Prepare DMA descriptor */
> >> +             xgene_dma_prep_cpy_desc(chan, slot, dst, src, copy);
> >> +
> > This is wrong. The descriptor is supposed to be already prepared and now it
> > has to be submitted to queue
> 
> Due to the race in tx_submit call from the client, need to serialize
> the submission of H/W DMA descriptors.
>  So we are making  shadow copy in prepare DMA  routine and  preparing
> actual descriptor during tx_submit call.
Thats an abuse of API and I dont see a reason why this race should happen in
the first place.

So you get a prep call, you prepare a desc in SW. Then submit pushes it to a
queue. Finally in issue pending you push them to HW. Simple..?

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul@intel.com>
To: Rameshwar Sahu <rsahu@apm.com>
Cc: dan.j.williams@intel.com, dmaengine@vger.kernel.org,
	Arnd Bergmann <arnd@arndb.de>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, ddutile@redhat.com,
	jcm@redhat.com, patches@apm.com, Loc Ho <lho@apm.com>
Subject: Re: [PATCH v5 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver
Date: Thu, 5 Feb 2015 12:11:18 -0800	[thread overview]
Message-ID: <20150205201118.GB16547@intel.com> (raw)
In-Reply-To: <CAFd313yBS3KOdtKbnaeTKehmC_f5ZaB-nx299QoLeMm279=Jsg@mail.gmail.com>

On Thu, Feb 05, 2015 at 05:29:06PM +0530, Rameshwar Sahu wrote:
> Hi Vinod,
> 
> Thanks for reviewing this patch.
> 
> Please see inline......
Please STOP top posting

> >
> >> +}
> >> +
> >> +static void xgene_dma_issue_pending(struct dma_chan *channel)
> >> +{
> >> +     /* Nothing to do */
> >> +}
> > What do you mean by nothing to do here
> > See Documentation/dmaengine/client.txt Section 4 & 5
> This docs is only applicable on slave DMA operations, we don't support
> slave DMA, it's only master.
> Our hw engine is designed in the way that there is no scope of
> flushing pending transaction explicitly by sw.
> We have circular ring descriptor dedicated to engine. In submit
> callback  we are queuing descriptor and informing to engine, so after
> this it's internal to hw to execute descriptor one by one.
But the API expectations on this are _same_ 

No the API expects you to maintain a SW queue, then push to your ring buffer
when you get issue_pending. Issue pending is the start of data transfer, you
client will expect accordingly.

> >> +     /* Run until we are out of length */
> >> +     do {
> >> +             /* Create the largest transaction possible */
> >> +             copy = min_t(size_t, len, DMA_MAX_64BDSC_BYTE_CNT);
> >> +
> >> +             /* Prepare DMA descriptor */
> >> +             xgene_dma_prep_cpy_desc(chan, slot, dst, src, copy);
> >> +
> > This is wrong. The descriptor is supposed to be already prepared and now it
> > has to be submitted to queue
> 
> Due to the race in tx_submit call from the client, need to serialize
> the submission of H/W DMA descriptors.
>  So we are making  shadow copy in prepare DMA  routine and  preparing
> actual descriptor during tx_submit call.
Thats an abuse of API and I dont see a reason why this race should happen in
the first place.

So you get a prep call, you prepare a desc in SW. Then submit pushes it to a
queue. Finally in issue pending you push them to HW. Simple..?

-- 
~Vinod

  reply	other threads:[~2015-02-05 20:11 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-03 12:55 [PATCH v5 0/3] dmaengine: APM X-Gene SoC DMA engine driver support Rameshwar Prasad Sahu
2015-02-03 12:55 ` Rameshwar Prasad Sahu
2015-02-03 12:55 ` [PATCH v5 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver Rameshwar Prasad Sahu
2015-02-03 12:55   ` Rameshwar Prasad Sahu
2015-02-05  1:50   ` Vinod Koul
2015-02-05  1:50     ` Vinod Koul
2015-02-05  1:50     ` Vinod Koul
2015-02-05 11:59     ` Rameshwar Sahu
2015-02-05 11:59       ` Rameshwar Sahu
2015-02-05 11:59       ` Rameshwar Sahu
2015-02-05 20:11       ` Vinod Koul [this message]
2015-02-05 20:11         ` Vinod Koul
2015-02-05 20:11         ` Vinod Koul
2015-02-11  8:08         ` Rameshwar Sahu
2015-02-11  8:08           ` Rameshwar Sahu
2015-02-03 12:55 ` [PATCH v5 2/3] arm64: dts: Add APM X-Gene DMA device and DMA clock DTS nodes Rameshwar Prasad Sahu
2015-02-03 12:55   ` Rameshwar Prasad Sahu
2015-02-03 12:55 ` [PATCH v5 3/3] Documentation: dma: Add APM X-Gene SoC DMA engine driver documentation Rameshwar Prasad Sahu
2015-02-03 12:55   ` Rameshwar Prasad Sahu
2015-02-03 12:55   ` Rameshwar Prasad Sahu
2015-02-04  9:38 ` [PATCH v5 0/3] dmaengine: APM X-Gene SoC DMA engine driver support Rameshwar Sahu
2015-02-04  9:38   ` Rameshwar Sahu
2015-02-04  9:38   ` Rameshwar Sahu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150205201118.GB16547@intel.com \
    --to=vinod.koul@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.