From: Archit Taneja <a0393947@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Archit Taneja <archit@ti.com>,
linux-omap@vger.kernel.org, linux@arm.linux.org.uk,
linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
Date: Fri, 10 Feb 2012 06:17:46 +0000 [thread overview]
Message-ID: <4F34B3BA.5030609@ti.com> (raw)
In-Reply-To: <1328788924.1909.67.camel@deskari>
On Thursday 09 February 2012 05:32 PM, Tomi Valkeinen wrote:
> Hi,
>
> On Thu, 2012-02-09 at 12:14 +0530, Archit Taneja wrote:
>> For DSS clock domain to transition from idle to active state, it's necessary
>> to enable the optional clock DSS_FCLK before we enable the module using the
>> MODULEMODE bits in the DSS clock domain's CM_DSS_DSS_CLKCTRL register.
>>
>> This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led
>> to DSS clock domain not getting out of idle when pm_runtime_get_sync() was
>> called for hdmi's platform device.
>>
>> Since the clock domain failed to change it's state to active, the hwmod code
>> disables any clocks it had enabled before for this hwmod. This led to the clock
>> 'dss_48mhz_clk' getting disabled.
>>
>> When hdmi's runtime_resume() op is called, the call to dss_runtime_get()
>> correctly enables the DSS clock domain this time. But the clock 'dss_48mhz_clk'
>> disabled before is needed for HDMI's PHY to function. Hence, the driver fails
>
> There's something wrong with the "But the clock..." sentence above.
>
> The patch looks good, but I think it'd be better to add brief HACK
> comments in the code also. Otherwise it's too easy to forget about this.
I'll make the changes and repost.
Archit
>
> Tomi
>
WARNING: multiple messages have this Message-ID (diff)
From: Archit Taneja <a0393947@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Archit Taneja <archit@ti.com>,
linux-omap@vger.kernel.org, linux@arm.linux.org.uk,
linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
Date: Fri, 10 Feb 2012 11:35:46 +0530 [thread overview]
Message-ID: <4F34B3BA.5030609@ti.com> (raw)
In-Reply-To: <1328788924.1909.67.camel@deskari>
On Thursday 09 February 2012 05:32 PM, Tomi Valkeinen wrote:
> Hi,
>
> On Thu, 2012-02-09 at 12:14 +0530, Archit Taneja wrote:
>> For DSS clock domain to transition from idle to active state, it's necessary
>> to enable the optional clock DSS_FCLK before we enable the module using the
>> MODULEMODE bits in the DSS clock domain's CM_DSS_DSS_CLKCTRL register.
>>
>> This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led
>> to DSS clock domain not getting out of idle when pm_runtime_get_sync() was
>> called for hdmi's platform device.
>>
>> Since the clock domain failed to change it's state to active, the hwmod code
>> disables any clocks it had enabled before for this hwmod. This led to the clock
>> 'dss_48mhz_clk' getting disabled.
>>
>> When hdmi's runtime_resume() op is called, the call to dss_runtime_get()
>> correctly enables the DSS clock domain this time. But the clock 'dss_48mhz_clk'
>> disabled before is needed for HDMI's PHY to function. Hence, the driver fails
>
> There's something wrong with the "But the clock..." sentence above.
>
> The patch looks good, but I think it'd be better to add brief HACK
> comments in the code also. Otherwise it's too easy to forget about this.
I'll make the changes and repost.
Archit
>
> Tomi
>
next prev parent reply other threads:[~2012-02-10 6:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-09 6:44 [PATCH] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled Archit Taneja
2012-02-09 6:56 ` Archit Taneja
2012-02-09 12:02 ` Tomi Valkeinen
2012-02-09 12:02 ` Tomi Valkeinen
2012-02-10 6:05 ` Archit Taneja [this message]
2012-02-10 6:17 ` Archit Taneja
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=4F34B3BA.5030609@ti.com \
--to=a0393947@ti.com \
--cc=archit@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=tomi.valkeinen@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 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.