[RFC] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data

[RFC] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data

[Ricardo Neri]

I would like to revive an old discussion regarding how to use a particular
idle mode for a specific use-case[1].

As per the OMAP4 documentation, audio over HDMI should be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmode uses
no-idle/force-idle settings instead of smart-idle.

However, if this flag is used, smart-idle nor smart-idle wakeup-capable
features could not be used. This would not be ideal if we want, for instance,
to wake up using a HDMI cable connect event.

Ideally, the HDMI module should be set to no-idle when transmitting audio
and then go back to whatever mode it was (e.g., smart-idle) when audio
transmission is over. I am not sure how to do that, though.

In the past, it was suggested to use an integration function through
platform_data[2], which didn't seem to be  suitable from the device tree
perspective; although there were no other alternatives[3].

It was also suggested to add functions to allow/block smart-idle
momentarily[4], but how would the driver let know omap_hwmod when to
allow/block smart-idle without using platform_data/integration function?

Thanks for your comments!

Ricardo

[1].http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60226.html
[2].http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60236.html
[3].http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60316.html
[4].http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60252.html

Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..3568b3b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -865,6 +865,11 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
 	},
 	.opt_clks	= dss_hdmi_opt_clks,
 	.opt_clks_cnt	= ARRAY_SIZE(dss_hdmi_opt_clks),
+	/*
+	 * HDMI audio requires to not rely on smart idle and
+	 * use no-idle instead. Hence, set idle mode by software.
+	 */
+	.flags          = HWMOD_SWSUP_SIDLE,
 };
 
 /*
-- 
1.7.5.4

Re: [RFC] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data

[Paul Walmsley]

Hi

On Sat, 16 Jun 2012, Ricardo Neri wrote:

> I would like to revive an old discussion regarding how to use a particular
> idle mode for a specific use-case[1].
> 
> As per the OMAP4 documentation, audio over HDMI should be transmitted in
> no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmode uses
> no-idle/force-idle settings instead of smart-idle.
> 
> However, if this flag is used, smart-idle nor smart-idle wakeup-capable
> features could not be used. This would not be ideal if we want, for instance,
> to wake up using a HDMI cable connect event.
> 
> Ideally, the HDMI module should be set to no-idle when transmitting audio
> and then go back to whatever mode it was (e.g., smart-idle) when audio
> transmission is over. I am not sure how to do that, though.
> 
> In the past, it was suggested to use an integration function through
> platform_data[2], which didn't seem to be  suitable from the device tree
> perspective; although there were no other alternatives[3].
> 
> It was also suggested to add functions to allow/block smart-idle
> momentarily[4], but how would the driver let know omap_hwmod when to
> allow/block smart-idle without using platform_data/integration function?

Yep that's indeed a good summary of the situation.

Since your patch fixes a functionality problem, maybe update the inline 
comment that you add to the data file to summarize what you wrote above: 
that this is simply a temporary workaround until the device driver has the 
ability to control the idle behavior.

Also if you want this patch to go in during the 3.5-rc fixes cycle, please 
document further in the patch description what specific problem this fixes 
(e.g., choppy/broken audio, etc.)


- Paul

Re: [RFC] ARM: OMAP4: hwmod data: add HWMOD_SWSUP_SIDLE to dss_hdmi to data

[Ricardo Neri]

On 06/18/2012 04:22 PM, Paul Walmsley wrote:
> Hi
>
> On Sat, 16 Jun 2012, Ricardo Neri wrote:
>
>> I would like to revive an old discussion regarding how to use a particular
>> idle mode for a specific use-case[1].
>>
>> As per the OMAP4 documentation, audio over HDMI should be transmitted in
>> no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmode uses
>> no-idle/force-idle settings instead of smart-idle.
>>
>> However, if this flag is used, smart-idle nor smart-idle wakeup-capable
>> features could not be used. This would not be ideal if we want, for instance,
>> to wake up using a HDMI cable connect event.
>>
>> Ideally, the HDMI module should be set to no-idle when transmitting audio
>> and then go back to whatever mode it was (e.g., smart-idle) when audio
>> transmission is over. I am not sure how to do that, though.
>>
>> In the past, it was suggested to use an integration function through
>> platform_data[2], which didn't seem to be  suitable from the device tree
>> perspective; although there were no other alternatives[3].
>>
>> It was also suggested to add functions to allow/block smart-idle
>> momentarily[4], but how would the driver let know omap_hwmod when to
>> allow/block smart-idle without using platform_data/integration function?
>
> Yep that's indeed a good summary of the situation.
>
> Since your patch fixes a functionality problem, maybe update the inline
> comment that you add to the data file to summarize what you wrote above:
> that this is simply a temporary workaround until the device driver has the
> ability to control the idle behavior.
>
> Also if you want this patch to go in during the 3.5-rc fixes cycle, please
> document further in the patch description what specific problem this fixes
> (e.g., choppy/broken audio, etc.)

Thanks Paul! I will resend the patch with the updated comments.

Ricardo
>
>
> - Paul
>