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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
