From: Venkatraman S <svenkatr@ti.com>
To: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Chikkature Rajashekar, Madhusudhan" <madhu.cr@ti.com>,
Adrian Hunter <adrian.hunter@nokia.com>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH v8 1/2] sDMA: descriptor autoloading feature
Date: Wed, 5 May 2010 17:20:15 +0530 [thread overview]
Message-ID: <k2l618f0c911005050450t75968621m61e3ff39e90d20ad@mail.gmail.com> (raw)
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02C52D16D1@dbde02.ent.ti.com>
[Long sections have been trimmed to the context of the discussion]
On Wed, May 5, 2010 at 3:02 PM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> +static int dma_sglist_set_phy_params(struct omap_dma_sglist_node *sghead,
>> + dma_addr_t phyaddr, int nelem)
>> +{
>> + struct omap_dma_sglist_node *sgcurr, *sgprev;
>> + dma_addr_t elem_paddr = phyaddr;
>> +
>> + for (sgprev = sghead;
>> + sgprev < sghead + nelem;
>> + sgprev++) {
>> +
>> + sgcurr = sgprev + 1;
>> + sgprev->next = sgcurr;
>> + elem_paddr += (int)sizeof(*sgcurr);
>> + sgprev->next_desc_add_ptr = elem_paddr;
>> +
>> + switch (sgcurr->desc_type) {
>> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE1:
>> + omap_dma_list_set_ntype(sgprev, 1);
>> + break;
>> +
>> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2a:
>> + /* intentional no break */
>> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2b:
>> + omap_dma_list_set_ntype(sgprev, 2);
>> + break;
>> +
>> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3a:
>> + /* intentional no break */
>> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3b:
>> + omap_dma_list_set_ntype(sgprev, 3);
>> + break;
>> +
>> + default:
>> + return -EINVAL;
>> +
>> + }
> Are we supporting all the descriptor types. I think only type2a is
> supported. In that case please add FIXME, or WARN message here.
From DMA perspective, all are supported - no restrictions. Only I have
not figured
out how to use type 2b and type 3b descriptors. It's not the fault of
DMA driver or
specification :-) It's actually upto the client to select the right type.
>> +
>> + lcfg->sghead = sgparams;
>> + lcfg->num_elem = nelem;
>> + lcfg->sgheadphy = padd;
>> + lcfg->pausenode = -1;
>> +
>> +
>> + if (NULL == chparams)
> Minute point really. Better readability "ch_params"
OK
>> + dma_write(l, CDP(lch));
>> + dma_write((lcfg->sgheadphy), CNDP(lch));
>> + /**
>> + * Barrier needed as writes to the
>> + * descriptor memory needs to be flushed
>> + * before it's used by DMA controller
>> + */
> Little bit of re-wording if you can.
> Also you don't wanted the double **
> /*
> * Memory barrier is needed because data may still be
> * in the write buffer. The barrier drains write buffers and
> * ensures that DMA sees correct descriptors
> */
OK
>> + wmb();
>> + omap_start_dma(lch);
>> +
>> + /* Maintain the pause state in descriptor */
>> + omap_set_dma_sglist_pausebit(lcfg, lcfg->pausenode, 0);
>> + omap_set_dma_sglist_pausebit(lcfg, pauseafter, 1);
>> +
>> + /**
>> + * Barrier needed as writes to the
>> + * descriptor memory needs to be flushed
>> + * before it's used by DMA controller
>> + */
> Description change if possible
OK
>> + wmb();
>> +
>> + /* Errata i557 - pausebit should be cleared in no standby mode */
> This should have been
I couldn't understand this comment.
>> + sys_cf = dma_read(OCP_SYSCONFIG);
>> + l = sys_cf;
>> + /* Middle mode reg set no Standby */
>> + l &= ~(BIT(12) | BIT(13));
>> + dma_write(l, OCP_SYSCONFIG);
next prev parent reply other threads:[~2010-05-05 11:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-29 17:35 [PATCH v8 1/2] sDMA: descriptor autoloading feature Venkatraman S
2010-05-05 9:32 ` Shilimkar, Santosh
2010-05-05 11:50 ` Venkatraman S [this message]
2010-05-05 12:01 ` Shilimkar, Santosh
2010-05-05 16:25 ` Venkatraman S
2010-05-06 7:51 ` Shilimkar, Santosh
2010-05-06 8:59 ` Venkatraman S
2010-05-05 10:05 ` Adrian Hunter
2010-05-05 11:51 ` Venkatraman S
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=k2l618f0c911005050450t75968621m61e3ff39e90d20ad@mail.gmail.com \
--to=svenkatr@ti.com \
--cc=adrian.hunter@nokia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=madhu.cr@ti.com \
--cc=santosh.shilimkar@ti.com \
--cc=tony@atomide.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).