From: Peter Ujfalusi <peter.ujfalusi@nokia.com>
To: ext Kishon Vijay Abraham I <kishon@ti.com>
Cc: alsa-devel@alsa-project.org, b-cousson@ti.com,
khilman@deeprootsystems.com, broonie@opensource.wolfsonmicro.com,
paul@pwsan.com, p-basak2@ti.com, lrg@slimlogic.co.uk,
linux-omap@vger.kernel.org, shubhrajyoti@ti.com, charu@ti.com
Subject: Re: [PATCH v2 09/13] OMAP: McBSP: use omap_device APIs to modify SYSCONFIG
Date: Tue, 01 Feb 2011 14:19:03 +0200 [thread overview]
Message-ID: <4D47FA37.1060001@nokia.com> (raw)
In-Reply-To: <1296485437-12806-10-git-send-email-kishon@ti.com>
Hi,
On 01/31/2011 04:50 PM, ext Kishon Vijay Abraham I wrote:
> McBSP2/3 in OMAP3 has sidetone feature which requires autoidle
> to be disabled before starting the sidetone. Also SYSCONFIG
> register has to be set with smart idle or no idle depending on the
> dma op mode (threshold or element sync). For doing these operations
> dynamically at runtime, omap_device APIs are used to modify SYSCONFIG register.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> arch/arm/plat-omap/mcbsp.c | 66 +++++++++++++++++++++++--------------------
> 1 files changed, 35 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
...
> static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp)
> {
> + struct omap_device *od;
> +
> + od = find_omap_device_by_dev(mcbsp->dev);
> /*
> * Enable wakup behavior, smart idle and all wakeups
> * REVISIT: some wakeups may be unnecessary
> */
> if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
> - u16 syscon;
> -
> - syscon = MCBSP_READ(mcbsp, SYSCON);
> - syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
> -
> - if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
> - syscon |= (ENAWAKEUP | SIDLEMODE(0x02) |
> - CLOCKACTIVITY(0x02));
> + if (mcbsp->dma_op_mode != MCBSP_DMA_MODE_THRESHOLD)
> + omap_device_noidle(od);
> + else
Would it make sense to call here:
omap_device_smartidle(od); ?
What happens, if we configure McBSP to element mode, play a sample,
configure it to threshold?
I think we should explicitly as for smartidle, when we suppose to be in
smartidle.
> MCBSP_WRITE(mcbsp, WAKEUPEN, XRDYEN | RRDYEN);
> - } else {
> - syscon |= SIDLEMODE(0x01);
> - }
> -
> - MCBSP_WRITE(mcbsp, SYSCON, syscon);
> }
> }
>
> static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp)
> {
> + struct omap_device *od;
> +
> + od = find_omap_device_by_dev(mcbsp->dev);
> +
> /*
> * Disable wakup behavior, smart idle and all wakeups
> */
> if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
> - u16 syscon;
> -
> - syscon = MCBSP_READ(mcbsp, SYSCON);
> - syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
> /*
> * HW bug workaround - If no_idle mode is taken, we need to
> * go to smart_idle before going to always_idle, or the
> * device will not hit retention anymore.
> */
> - syscon |= SIDLEMODE(0x02);
> - MCBSP_WRITE(mcbsp, SYSCON, syscon);
> -
> - syscon &= ~(SIDLEMODE(0x03));
> - MCBSP_WRITE(mcbsp, SYSCON, syscon);
> -
> + omap_device_default_idle(od);
> MCBSP_WRITE(mcbsp, WAKEUPEN, 0);
Hrm, it would be better to do it as the comment said:
omap_device_smartidle(od);
omap_device_forceidle(od);
BTW: what is the default_idle in case of McBSP?
--
Péter
next prev parent reply other threads:[~2011-02-01 12:13 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-31 14:50 [PATCH v2 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion Kishon Vijay Abraham I
2011-01-31 14:50 ` [PATCH v2 01/13] OMAP: hwmod: Add member 'name' to omap_hwmod_addr_space struct Kishon Vijay Abraham I
2011-02-04 19:45 ` Kevin Hilman
2011-02-04 20:21 ` Cousson, Benoit
2011-02-04 22:16 ` Kevin Hilman
2011-02-07 6:02 ` ABRAHAM, KISHON VIJAY
2011-02-09 21:14 ` Paul Walmsley
2011-01-31 14:50 ` [PATCH v2 02/13] OMAP: McBSP: Convert McBSP to platform device model Kishon Vijay Abraham I
2011-02-01 12:33 ` Peter Ujfalusi
2011-01-31 14:50 ` [PATCH v2 03/13] OMAP2420: hwmod data: Add McBSP Kishon Vijay Abraham I
2011-01-31 14:50 ` [PATCH v2 04/13] OMAP2430: " Kishon Vijay Abraham I
2011-02-01 12:39 ` Peter Ujfalusi
2011-01-31 14:50 ` [PATCH v2 05/13] OMAP3: " Kishon Vijay Abraham I
2011-01-31 14:50 ` [PATCH v2 06/13] OMAP4: " Kishon Vijay Abraham I
2011-02-14 14:45 ` Cousson, Benoit
2011-01-31 14:50 ` [PATCH v2 07/13] OMAP3: hwmod: add dev_attr for McBSP sidetone Kishon Vijay Abraham I
2011-01-31 14:50 ` [PATCH v2 08/13] OMAP2+: McBSP: hwmod adaptation for McBSP Kishon Vijay Abraham I
2011-02-01 12:22 ` Peter Ujfalusi
2011-02-01 17:44 ` [alsa-devel] " Jarkko Nikula
2011-02-02 6:23 ` ABRAHAM, KISHON VIJAY
2011-02-17 23:41 ` Tony Lindgren
2011-02-18 8:08 ` Jarkko Nikula
2011-02-18 8:20 ` ABRAHAM, KISHON VIJAY
2011-01-31 14:50 ` [PATCH v2 09/13] OMAP: McBSP: use omap_device APIs to modify SYSCONFIG Kishon Vijay Abraham I
2011-02-01 12:19 ` Peter Ujfalusi [this message]
2011-02-01 13:47 ` ABRAHAM, KISHON VIJAY
2011-01-31 14:50 ` [PATCH v2 10/13] OMAP: McBSP: Add pm runtime support Kishon Vijay Abraham I
2011-01-31 14:50 ` [PATCH v2 11/13] OMAP: McBSP: APIs to pass DMA params from McBSP driver to client drivers Kishon Vijay Abraham I
2011-01-31 14:50 ` [PATCH v2 12/13] ASoC: McBSP: get hw params from McBSP driver Kishon Vijay Abraham I
2011-01-31 17:16 ` Mark Brown
2011-01-31 14:50 ` [PATCH v2 13/13] OMAP: hwmod: Removal of macros for data that is obtained from hwmod database Kishon Vijay Abraham I
2011-02-01 18:07 ` Jarkko Nikula
2011-02-02 6:15 ` ABRAHAM, KISHON VIJAY
2011-02-01 17:53 ` [PATCH v2 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion Jarkko Nikula
2011-02-01 17:58 ` [alsa-devel] " Liam Girdwood
2011-02-01 19:44 ` Peter Ujfalusi
2011-02-01 21:27 ` Mark Brown
2011-02-09 18:22 ` Tony Lindgren
2011-02-04 19:47 ` Kevin Hilman
2011-02-04 21:42 ` Kevin Hilman
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=4D47FA37.1060001@nokia.com \
--to=peter.ujfalusi@nokia.com \
--cc=alsa-devel@alsa-project.org \
--cc=b-cousson@ti.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=charu@ti.com \
--cc=khilman@deeprootsystems.com \
--cc=kishon@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=p-basak2@ti.com \
--cc=paul@pwsan.com \
--cc=shubhrajyoti@ti.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).