linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Thu, 6 May 2010 14:29:51 +0530	[thread overview]
Message-ID: <s2y618f0c911005060159v4be26a14y85a7548a080ae380@mail.gmail.com> (raw)
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02C538737A@dbde02.ent.ti.com>

Shilimkar, Santosh <santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: svenkatr@gmail.com [mailto:svenkatr@gmail.com] On Behalf Of Venkatraman S
>> Sent: Wednesday, May 05, 2010 9:56 PM
>> To: Shilimkar, Santosh
>> Cc: linux-omap@vger.kernel.org; linux-mmc@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>> Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Tony Lindgren
>> Subject: Re: [PATCH v8 1/2] sDMA: descriptor autoloading feature
>>
>> On Wed, May 5, 2010 at 5:31 PM, Shilimkar, Santosh
>> <santosh.shilimkar@ti.com> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: svenkatr@gmail.com [mailto:svenkatr@gmail.com] On Behalf Of Venkatraman S
>> >> Sent: Wednesday, May 05, 2010 5:20 PM
>> >> To: Shilimkar, Santosh
>> >> Cc: linux-omap@vger.kernel.org; linux-mmc@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>> >> Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Tony Lindgren
>> >> Subject: Re: [PATCH v8 1/2] sDMA: descriptor autoloading feature
>> >>
>> >> [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.
>> > OK. Then the question which I wanted to ask.
>> > For TX, 2b should have been better choice than 2a isn't it?
>>
>> Not much of a difference (as the space allocation is common), but I
>> couldn't get 2b working correctly.
>> Will try that once I get some clarification from hardware team.
> Add a FIXME then with description in the code so that it's not forgotten once the code
> is merged.
OK. I am assuming the FIXME has to be in MMC driver, not here.

  reply	other threads:[~2010-05-06  8:59 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
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 [this message]
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=s2y618f0c911005060159v4be26a14y85a7548a080ae380@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).