From: b-cousson@ti•com (Cousson, Benoit)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/2] ARM: OMAP4: DSS hwmods: Add OCPIF_SWSUP_IDLE to all DSS L3 slave interfaces
Date: Fri, 13 Apr 2012 10:43:22 +0200 [thread overview]
Message-ID: <4F87E72A.2050104@ti.com> (raw)
In-Reply-To: <1334304116-18872-3-git-send-email-archit@ti.com>
On 4/13/2012 10:01 AM, Archit Taneja wrote:
> The clock for all DSS L3 slave interfaces had been recently changed to
> "dss_fck" from "l3_div_ck". "dss_fck" is an optional clock in DSS clock domain
> which can't autoidle when enabled.
>
> Add OCPIF_SWSUP_IDLE flag to all the L3 slave interfaces used by DSS hwmods so
> that clock is explicitly enabled and disabled by software. Without this,
> "dss_fck" would be left as enabled and the OMAP4 device won't idle even when
> DSS is not in use.
Yeah, that was done on purpose with Tomi knowning well that limitation.
The issue was mainly due to the lack of proper parent / child
relationship between the DSS (the whole subsystem) and the DSS children
at that time.
I think that Tomi posted a series to fix that for 3.4. So if we ensure
that every DSS IPs are children of the DSS, then pm_runtime will always
ensure that the DSS will be enabled each time a submodule is used.
So the right fix is to put back the proper iclk (l3_div) to the DSS
instead of the dss_fck.
The current OMAP4 DSS clock setup is clearly a hack that should be fixed.
Regards,
Benoit
next prev parent reply other threads:[~2012-04-13 8:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-13 8:01 [PATCH 0/2] ARM: OMAP2PLUS: DSS hwmod fixes Archit Taneja
2012-04-13 8:01 ` [PATCH 1/2] ARM: OMAP2/3: VENC hwmods: Remove OCPIF_SWSUP_IDLE flag from VENC slave interface Archit Taneja
2012-04-13 11:20 ` Paul Walmsley
2012-04-13 11:24 ` Paul Walmsley
2012-04-13 11:37 ` Archit Taneja
2012-04-13 8:01 ` [PATCH 2/2] ARM: OMAP4: DSS hwmods: Add OCPIF_SWSUP_IDLE to all DSS L3 slave interfaces Archit Taneja
2012-04-13 8:43 ` Cousson, Benoit [this message]
2012-04-13 8:51 ` Archit Taneja
2012-05-04 6:39 ` Paul Walmsley
2012-05-04 7:03 ` Archit Taneja
2012-05-04 8:51 ` Tomi Valkeinen
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=4F87E72A.2050104@ti.com \
--to=b-cousson@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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