| Message ID | 1374487277-26099-4-git-send-email-rnayak@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi On Mon, 22 Jul 2013, Rajendra Nayak wrote: > Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with > HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup. > > Even if they have drivers missing, avoid idling them as part of > omap_device_late_idle() Since this patch is intended for the -rc series, it's best if you explain here what effects this patch will fix. i.e., does this fix a crash, a warning, etc? Also maybe update your series description message? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 22 July 2013 11:18 PM, Paul Walmsley wrote: > Hi > > On Mon, 22 Jul 2013, Rajendra Nayak wrote: > >> Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with >> HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup. >> >> Even if they have drivers missing, avoid idling them as part of >> omap_device_late_idle() > > Since this patch is intended for the -rc series, it's best if you explain > here what effects this patch will fix. i.e., does this fix a crash, a > warning, etc? Also maybe update your series description message? This patch infact is needed because of 'PATCH 4/4' in the series which makes sure the omap_device and pm_runtime state are in sync with the hwmod state. Without that we always had gpmc and emif having the hwmod state as enabled but omap_device state as disabled and we never hit the issue of omap_device_late_idle() trying to disable gpmc and emif. So in short, this does not fix anything in the existing code, but something that was uncovered by syncing the states across hwmod and omap_device. regards, Rajendra > > > - Paul > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c index 5cc9287..1c82cde 100644 --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -842,6 +842,7 @@ static int __init omap_device_late_idle(struct device *dev, void *data) { struct platform_device *pdev = to_platform_device(dev); struct omap_device *od = to_omap_device(pdev); + int i; if (!od) return 0; @@ -850,6 +851,15 @@ static int __init omap_device_late_idle(struct device *dev, void *data) * If omap_device state is enabled, but has no driver bound, * idle it. */ + + /* + * Some devices (like memory controllers) are always kept + * enabled, and should not be idled even with no drivers. + */ + for (i = 0; i < od->hwmods_cnt; i++) + if (od->hwmods[i]->flags & HWMOD_INIT_NO_IDLE) + return 0; + if (od->_driver_status != BUS_NOTIFY_BOUND_DRIVER) { if (od->_state == OMAP_DEVICE_STATE_ENABLED) { dev_warn(dev, "%s: enabled but no driver. Idling\n",
Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup. Even if they have drivers missing, avoid idling them as part of omap_device_late_idle() Signed-off-by: Rajendra Nayak <rnayak@ti.com> --- arch/arm/mach-omap2/omap_device.c | 10 ++++++++++ 1 file changed, 10 insertions(+)