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

[Ricardo Neri <ricardo.neri@ti.com>]

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
>