From: "G, Manjunath Kondaiah" <manjugk@ti.com>
To: "G, Manjunath Kondaiah" <manjugk@ti.com>
Cc: Kevin Hilman <khilman@ti.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
paul@pwsan.com
Subject: Re: [PATCH 0/3] OMAP: DMA: mstandby mode and runtime pm support
Date: Mon, 7 Mar 2011 16:36:12 +0530 [thread overview]
Message-ID: <20110307110611.GA8743@m-desktop> (raw)
In-Reply-To: <20110304041826.GA7025@m-desktop>
On Fri, Mar 04, 2011 at 09:48:26AM +0530, G, Manjunath Kondaiah wrote:
> On Thu, Mar 03, 2011 at 10:35:23AM -0800, Kevin Hilman wrote:
> > "G, Manjunath Kondaiah" <manjugk@ti.com> writes:
> >
> > > This patch series is remaining part of dma hwmod to support pm runtime
> > > and for handling mstandby mode for all applicable DMA mstandby mode errata.
> >
> > This is still not runtime-suspending when I use my DMA test in linking
> > mode.
> >
> > If I put a large enough period between transfers, it should autosuspend
> > during transfers. It seems to do auto-suspend and resume once, but then
> > it never suspends again.
> >
> > I tested with my dmatest module[1], and loaded with:
> >
> > # insmod ./dmatest.ko linking=1 forever=1 forever_period=1024
> >
> > Not only does it not auto-suspend between transfers (which I expected),
> > it also doesn't suspend after removing the module which stops all active
> > channels.
>
> The normal chaining test cases are executed and which used to show the
> proper status. Let me reproduce this issue with your test procedure.
ok. I am able to reproduce this issue and fixed _get_sync usage in
omap_start_dma if channel linking is used. Earlier it was handled for
the cases with chaining API's. If linking is done without chaining
API's, it will result in _get_sync and _put mismatch.
Thanks for the test case and I will be re posting the patches with the
above fix.
-Manjunath
WARNING: multiple messages have this Message-ID (diff)
From: manjugk@ti.com (G, Manjunath Kondaiah)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] OMAP: DMA: mstandby mode and runtime pm support
Date: Mon, 7 Mar 2011 16:36:12 +0530 [thread overview]
Message-ID: <20110307110611.GA8743@m-desktop> (raw)
In-Reply-To: <20110304041826.GA7025@m-desktop>
On Fri, Mar 04, 2011 at 09:48:26AM +0530, G, Manjunath Kondaiah wrote:
> On Thu, Mar 03, 2011 at 10:35:23AM -0800, Kevin Hilman wrote:
> > "G, Manjunath Kondaiah" <manjugk@ti.com> writes:
> >
> > > This patch series is remaining part of dma hwmod to support pm runtime
> > > and for handling mstandby mode for all applicable DMA mstandby mode errata.
> >
> > This is still not runtime-suspending when I use my DMA test in linking
> > mode.
> >
> > If I put a large enough period between transfers, it should autosuspend
> > during transfers. It seems to do auto-suspend and resume once, but then
> > it never suspends again.
> >
> > I tested with my dmatest module[1], and loaded with:
> >
> > # insmod ./dmatest.ko linking=1 forever=1 forever_period=1024
> >
> > Not only does it not auto-suspend between transfers (which I expected),
> > it also doesn't suspend after removing the module which stops all active
> > channels.
>
> The normal chaining test cases are executed and which used to show the
> proper status. Let me reproduce this issue with your test procedure.
ok. I am able to reproduce this issue and fixed _get_sync usage in
omap_start_dma if channel linking is used. Earlier it was handled for
the cases with chaining API's. If linking is done without chaining
API's, it will result in _get_sync and _put mismatch.
Thanks for the test case and I will be re posting the patches with the
above fix.
-Manjunath
next prev parent reply other threads:[~2011-03-07 11:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-24 10:14 [PATCH 0/3] OMAP: DMA: mstandby mode and runtime pm support G, Manjunath Kondaiah
2011-02-24 10:14 ` G, Manjunath Kondaiah
2011-02-24 10:14 ` [PATCH 1/3] OMAP2+: PM: omap device: API's for handling mstandby mode G, Manjunath Kondaiah
2011-02-24 10:14 ` G, Manjunath Kondaiah
2011-03-10 10:12 ` Paul Walmsley
2011-03-10 10:12 ` Paul Walmsley
2011-02-24 10:14 ` [PATCH 2/3] OMAP2+: DMA: prevent races while setting M idle mode to nostandby G, Manjunath Kondaiah
2011-02-24 10:14 ` G, Manjunath Kondaiah
2011-02-24 10:14 ` [PATCH 3/3] OMAP: PM: DMA: Enable runtime pm G, Manjunath Kondaiah
2011-02-24 10:14 ` G, Manjunath Kondaiah
2011-03-03 18:35 ` [PATCH 0/3] OMAP: DMA: mstandby mode and runtime pm support Kevin Hilman
2011-03-03 18:35 ` Kevin Hilman
2011-03-04 4:18 ` G, Manjunath Kondaiah
2011-03-04 4:18 ` G, Manjunath Kondaiah
2011-03-07 11:06 ` G, Manjunath Kondaiah [this message]
2011-03-07 11:06 ` G, Manjunath Kondaiah
2011-03-07 19:04 ` Kevin Hilman
2011-03-07 19:04 ` Kevin Hilman
2011-03-08 14:24 ` G, Manjunath Kondaiah
2011-03-08 14:24 ` G, Manjunath Kondaiah
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=20110307110611.GA8743@m-desktop \
--to=manjugk@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.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 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.